WO2023171334A1

WO2023171334A1 - Information processing method, information processing system, and program

Info

Publication number: WO2023171334A1
Application number: PCT/JP2023/005918
Authority: WO
Inventors: 淳浅井
Original assignee: ソニーグループ株式会社
Priority date: 2022-03-08
Filing date: 2023-02-20
Publication date: 2023-09-14

Abstract

The present technology relates to an information processing method, an information processing system, and a program which make it possible to easily allocate calculation resources according to the details of a service to be provided, when the service using a server (a server computer) is provided. Provided is an image network system for a hospital, wherein the details of a service used in an individual hospital are generated as service definition data, the service definition data is converted to cluster requirement definition data according to a predetermined conversion rule, the cluster requirement definition data is input to an orchestration tool, and the orchestration tool is operated, according to the cluster requirement definition data, on the server computer in which individual image network systems for a hospital are clustered.

Description

Information processing method, information processing system, and program

This technology relates to information processing methods, information processing systems, and programs, and particularly when providing services using a server (server computer), it is possible to easily allocate computing resources according to the content of the service to be provided. The present invention relates to an information processing method, an information processing system, and a program.

Patent Document 1 discloses a system that stores test results and diagnosis results of disease severity in the cloud.

Patent No. 6747529

When providing a service using a server (server computer), by allocating computing resources according to the content of the service provided, it is possible to make effective use of the server computer and reduce server usage costs. Settings are not easy when there is an increase or decrease in the number of services or changes in service content.

This technology was created in view of this situation, and when providing services using a server (server computer), it makes it possible to easily allocate computing resources according to the content of the service to be provided. .

The information processing method according to the first aspect of the present technology includes, in a video network system for hospitals, a generation step of generating service contents used by each hospital as service definition data, and a step of generating service definition data for each hospital according to predetermined conversion rules. a conversion step of converting definition data into cluster requirement definition data; an input step of inputting the cluster requirement definition data into an orchestration tool; and the orchestration tool converts the individual hospital video network system according to the cluster requirement definition data. This information processing method includes an operation step of operating the computer on clustered server computers.

In the information processing method of the first aspect of the present technology, in a video network system for hospitals, service contents used by individual hospitals are generated as service definition data, and the service definition data is converted according to predetermined conversion rules. The data is converted into cluster requirement definition data, the cluster requirement definition data is input to an orchestration tool, and the orchestration tool operates the individual hospital video network systems on the clustered server computers according to the cluster requirement definition data.

The information processing system or program according to the second aspect of the present technology orchestrates service definition data indicating service content used by individual hospitals in accordance with predetermined conversion rules in a video network system for hospitals. The information processing system is an information processing system that has a conversion unit that converts into cluster requirement definition data that is input to a conversion tool, or a program for operating such an information processing system or computer.

In the information processing system and program according to the second aspect of the present technology, in a video network system for hospitals, service definition data indicating service content used by individual hospitals is converted according to predetermined conversion rules. Converted into cluster requirements definition data that is input to the orchestration tool.

FIG. 2 is a block diagram showing an example of the configuration of an in-hospital network when the hospital system is configured as a closed network within the hospital. FIG. 1 is a block diagram showing an example of the configuration of a hospital system using the cloud. FIG. 1 is a block diagram showing an example of the configuration of a first complex system including a plurality of hospital systems. FIG. 2 is a block diagram showing a configuration example of a second complex system including a plurality of hospital systems. FIG. 1 is a block diagram showing a configuration example of a hospital system in which an in-hospital network includes storage. 5 is a diagram illustrating the flow and configuration of processing at the control terminal 50 in the second complex system of FIG. 4. FIG. 7 is a diagram showing a specific example of the service definition data, conversion rules, and cluster requirement definition data of FIG. 6. FIG. FIG. 2 is a diagram illustrating a GUI that supports input and editing of service definition data. FIG. 2 is a diagram illustrating a GUI that supports input and editing of service definition data. 1 is a block diagram showing a configuration example of an embodiment of a computer to which the present technology is applied.

Hereinafter, embodiments of the present technology will be described with reference to the drawings.

<<Video network system for hospitals according to this embodiment>>
Various medical imaging devices (modalities) are used in hospital operating rooms, and images output from these medical imaging devices are displayed on display devices such as monitors, or are stored on external devices such as HDDs (Hard Disk Drives). It may be recorded on a storage device. At this time, instead of directly connecting a medical imaging device and a display device or an external storage device, it is becoming common to connect them via a video network in an operating room or hospital. One of the reasons for this is that images of any modality such as an endoscope (modality images) can be displayed or switched on any display device. Such a video network system for a hospital is generally configured as a closed network within the hospital, so it is configured as an in-hospital network system (in-hospital network). Note that this technology is mainly referred to as a hospital system because it can be applied not only to video (images) but also to a network system that enables the sharing and management of data other than video. Further, in the embodiment of the present technology, a network system related to a hospital (medical care) will be described as an example, but the present technology can be applied to a network system not related to a hospital (medical care).

<Standard hospital system>
FIG. 1 is a block diagram showing an example of the configuration of an in-hospital network when the hospital system is configured as a closed network within the hospital. In FIG. 1, an in-hospital network 10' is constructed as a closed IP (Internet Protocol) network within the hospital. Modalities 11-1 and 11-2 in the figure are images of endoscopes, ultrasound diagnostic equipment, MRI (magnetic resonance equipment), CT (computed tomography equipment), biological information monitors, surgical robots, etc. Refers to all medical devices that send out Although only two modalities 11-1 and 11-2 are illustrated in FIG. 1, the number of modalities is not limited thereto. When there is no need to limit the modality to a specific one, it is called modality 11.

The image data sent from the modalities 11-1 and 11-2 are sent to the in-hospital IP network via IPCs (IP converters) 13-1 and 13-2, respectively. The destination of the image data sent to the IP network is selected by the switch 14 and sent to the monitors 12-1 and 12-2 connected to the IPCs 13-3 and 13-4 for display, or to the storage 16. It may be sent and recorded. Note that IPC13-1 to IPC13-4 convert signals output from these connected devices into signals that comply with the communication protocol of the IP network, or convert signals from the IP network into signals input to the device. It has a protocol conversion function. IPC is not necessary if the device connected to the IP network has a built-in IPC protocol conversion function. Further, in FIG. 1, two monitors 12-1 and 12-2 and one storage 16 are illustrated, but the number of monitors and storage is not limited to this. When there is no need to limit the monitor and storage to specific ones, they will be referred to as a monitor 12 and a storage 16, respectively. IPC is also connected to devices that are not equipped with a protocol conversion function among the devices connected to the IP network, and the number of IPCs is not limited to four as shown in FIG. 1. When there is no need to limit the IPC to a specific one, it is called IPC13.

The server application running on the server computers 15-1 and 15-2 controls the routing such as which monitor 12 or storage 16 receives images from which modality 11 connected to the IP network. In addition, on the server computers 15-1 and 15-2, there are server applications that manage images recorded in the storage 16 and convert formats, and server applications that analyze images using AI etc. to assist in diagnosis and surgery. , and a server application that controls the entire system. Note that although two server computers 15-1 and 15-2 are illustrated in FIG. 1, the number of server computers is not limited to this. If there is no need to limit the server computer to a specific one, it will be referred to as a server computer 15.

These server applications are operated from a client terminal 17 such as a PC (Personal Computer) or tablet connected to the IP network. Further, functions such as streaming viewing of live or modality images on the storage 16 and annotation (a function of drawing figures and text on images in real time) on live modality images can be used from the client terminal 18. Similarly, system control and maintenance of the server computer 15 (system startup, system setting changes, operating status monitoring, recovery in the event of a failure, software updates, etc.) can also be performed from the client terminal 19. . Note that although three client terminals 17 to 19 are illustrated in FIG. 1, the number of client terminals is not limited to three.

<Hospital system using cloud>
In the hospital network 10' in FIG. 1, the hospital system (also simply referred to as the system) was configured as a closed network within the hospital, but some functions of the system, mainly the functions of the server computer 15, have been migrated to the cloud. It is thought that this format will become popular.

FIG. 2 is a block diagram showing an example of the configuration of a hospital system using the cloud. Note that in the figure, parts common to those in FIG. In the hospital system 1 in FIG. 2, the in-hospital network 10 is a network system configured within the hospital, and corresponds to the in-hospital network 10' in FIG. However, the hospital network 10 of FIG. 2 differs from the hospital network 10' of FIG. 1 in that the server computers 15-1 and 15-2, the storage 16, and the client terminal 19 are not provided. Note that some of the functions of the server computers 15-1 and 15-2 in FIG. 1 or the functions of the server computers not shown in FIG. 1 may be included in the hospital network 10 in FIG. A server computer 15-A has been newly added to the hospital network 10 of No. 2.

Further, the hospital system 1 in FIG. 2 is configured as the hospital network 10' in FIG. 1 in that a cloud 20, a management company network 30, and a VPN (virtual private network) 40 are added. differs from the system.

The cloud 20 includes the server computers 15-1 and 15-2 and the storage 16 shown in FIG. Note that the numbers of server computers 15 and storages 16 correspond to those in FIG. 1 for the sake of explanation, and are not limited thereto. The server computers 15-1 and 15-2 and the storage 16 of the cloud 20 are connected to the VPN 40 through the network within the cloud 20, and are connected to the IP network of the hospital network 10 via the VPN 40. By communicating between the hospital network 10 and the cloud 20 via the VPN 40, security risks such as information leakage are reduced, and mutual communication between multiple locations becomes possible. Note that the VPN 40 may be constructed mainly using the Internet line or using a closed network provided by a telecommunications carrier, but in this embodiment, the type does not matter, and it may be constructed using a network other than the VPN. It may also be a communication line. Furthermore, some applications executed by the server computers 15-1 and 15-2 need to be executed with low latency. In that case, in order to avoid delays caused by communication via the VPN 40, the application may be executed on the server computer 15-A of the hospital network 10 (on-premises). Additionally, if you try to control/maintain the system from within the hospital network 10' as shown in Figure 1, it would be necessary to have a person in charge at each hospital, or a service engineer would have to travel around. , is very inefficient. On the other hand, in the system configuration shown in FIG. 2 that uses the cloud 20, the management provider can connect the client terminal 19 of the management provider network 30 managed by the management provider to the cloud 20 through the VPN 40. It becomes possible to undertake control/maintenance and remotely control and maintain the system from the management company's base.

<First complex system in which the hospital system shown in Figure 2 is individually introduced into multiple hospitals>
Next, assume that the hospital system 1 of FIG. 2 is individually introduced and operated in a plurality of hospitals. FIG. 3 is a block diagram showing an example of the configuration of a first complex system comprising a plurality of hospital systems in a case where each hospital individually contracts with a cloud provider and rents a server computer. In FIG. 3, in-hospital networks 10-A to 10-E indicated by hospitals A to E correspond to the in-hospital networks 10 in FIG. 2 configured within hospitals A to E, respectively. Note that the in-hospital networks 10-A to 10-E are referred to as in-hospital networks 10 when there is no need to limit them to specific ones. Six server computers 15-1 to 15-6 and five storages 16-1 to 16-5 of the cloud 20 to which the hospital networks 10-A to 10-E are connected are server computers included in the cloud 20 in FIG. 2, respectively. 15 and storage 16. Note that the configuration of data transmission paths such as the VPN 40 that connects the in-hospital networks 10-A to 10-E and the cloud 20 is omitted. Control terminals 50-1 to 50-5 are terminals that perform system control/maintenance of the hospital systems of each hospital A to E, respectively. According to the first complex system shown in FIG. 3, contracts are individually concluded with cloud providers of the cloud 20 for hospitals A to E, and server computers 15-1 to 15-6 and storages 16-1 to 16- 5 will be rented and a hospital system will be constructed individually. That is, the first complex system in FIG. 3 has a configuration in which a plurality of hospital systems 1 in FIG. 2 are assembled for each hospital A to E.

A server application (hereinafter simply referred to as "server") operates on each of the server computers 15-1 to 15-6. In the explanation of this technology, the following four types of servers #1 to #4 exist, and the contract for server #1 is mandatory, but the contracts for other servers #2 to #4 are optional, and any combination can be used. Assume that a contract is possible. Note that the services provided by servers #1 to #4 are just examples, and any one or more of the services of servers #1 to #4 may be provided, or the services provided by servers #1 to #4 may be There may also be a case where other services different from services #1 to #4 are provided.

1. Server #1: Basic (overall control/routing) service Server #1 controls the entire hospital system. The server #1 also controls routing, such as which monitor 12 or storage 16 receives images from which modality 11 connected to the IP network within the hospital network 10.

2. Server #2: Recording service (optional)
Server #2 records the image sent by modality 11 in storage 16. Additionally, server #2 manages recorded images.

3. Server #3: Streaming service (optional)
The server #3 streams images recorded in the storage 16 or images being transmitted live by the modality 11 to the client terminal 18.

4. Server #4: Diagnostic support service (optional)
Diagnostic support is provided by analyzing images recorded in the storage 16 or images sent live by the modality using AI.

The specific combination of services to be provided differs depending on the hospital that uses the hospital system 1. For example, in the hospital system of hospital A in FIG. 3, only server #1 (basic service) operates on server computer 15-1 of cloud 20. In the hospital system of hospital B, server #1 (basic service) and server #2 (recording service) operate on server computer 15-2 of cloud 20, and one storage 16-1 is used. In the hospital system of Hospital C, four types of servers #1 to #4 operate on two server computers 15-3 and 15-4 of cloud 20, and two storages 16-2 and 16-3 are used. be done. Note that the calculation resources of one server computer 15 are insufficient for the operation of four types of servers #1 to #4, so in the hospital system of hospital C, two server computers 15-3 and 15 are used. -4 is used. In the hospital systems of hospitals D and E, similar to the configuration of hospital B, one server computer 15-5 and one server computer 15-6 of the cloud 20 provide server #1 (basic service) and server #2 (recording service). ) operates, and one storage unit 16-4 and one storage unit 16-5 are used. Note that the server computer 15-1 of the hospital system of hospital A is not connected to the storage 16 because hospital A does not use services that require the storage 16. In addition, the first complex system in Figure 3 assumes that one server provides one service, but in reality, multiple servers may be combined to provide one service, or one server may provide one service. may provide multiple services.

In the first complex system in Figure 3, the computing resources (number of CPU (Central Processing Unit) cores/memory capacity/storage capacity/GPU (Graphics Processing Unit) number, etc.) of each server computer 15-1 to 15-6 are the same. Assuming this, for example, Hospital B's hospital system would be running two servers, while Hospital A's hospital system would be running only one server, which would mean that there would be surplus computing resources. Therefore, there is waste from the perspective of cloud (server) usage cost (usage fee for the server computer 15 paid to the cloud provider). Depending on the cloud provider, it may be possible to set computing resources in detail to minimize costs, but it is necessary to make such settings for each hospital and review the settings each time services are increased or decreased. This affects management costs. In addition, if you want to prepare a spare server computer in case a failure occurs in the server computer 15 and continue operating the server there in the event of a failure, each hospital must also rent a spare server computer, which increases the cost. This is a disadvantage.

Therefore, instead of operating the system by renting server computers 15 individually for each hospital as in the first complex system shown in FIG. 3, multiple server computers 15 are clustered and virtualized, and each Operate the hospital system at once.

<Second complex system in which the hospital system shown in Figure 2 is introduced into multiple hospitals and clustered>
FIG. 4 is a block diagram showing an example of the configuration of a second complex system made up of a plurality of hospital systems when the cloud 20 is clustered with respect to the first complex system of FIG. In FIG. 4, servers for the hospital systems of all hospitals A to E are executed using two server computers 15-1 and 15-2. Although the computing resources per server computer 15-1 and 15-2 are higher performance in terms of the number of CPU cores, memory size, etc. compared to the first complex system in FIG. 3, Overall, by efficiently allocating computer resources and reducing the number of server computers 15, cloud usage costs can be reduced compared to the first complex system shown in FIG. 3.

In FIG. 4, each of servers #1 to #4 of server computers 15-1 and 15-2 is executed on containers 80-1 to 80-11. Note that if there is no need to limit the container to a specific one, it will be referred to as a container 80. The container 80 is an operating environment for an application, and appears to virtually occupy the server computer 15 from the application's perspective. Thereby, a plurality of servers #1 to #4 can be executed in isolation from each other on the same server computer 15. Docker is a typical software that provides containers 80. Although one server is running on one container 80 in FIG. 4, multiple servers may also be run on one container 80, such as when realizing one service by combining multiple servers. It is possible.

On the other hand, the servers included in each hospital system of hospitals A to E need to communicate with each other and share data. Therefore, container groups 70-1 to 70-5 are formed by grouping a plurality of containers 80 for each hospital system of hospitals A to E, and only containers 80 forming the same container group can communicate with each other. and share data. Note that when there is no need to limit the container group to a specific one, it is referred to as a container group 70.

In the case of the second complex system of FIG. 4, in the hospital systems of hospitals B, D, and E, server #1 and server #2 form container groups 70-2, 70-4, and 70-5, respectively. are doing. On the other hand, in the hospital system of hospital A, only the server #1 forms a container group 70-1 since only basic services are provided, and in the hospital C, servers #1 to #4 form a container group 70-3. Note that in the system of Hospital C, servers #1 and #2 and servers #3 and #4 are running on different server computers 15-1 and 15-2, but the operating environment can be changed by using containers. This kind of configuration is also possible because it is virtualized.

Storage #1 (storage 16-1) and storage #2 (storage 16-2) in FIG. 4 are storages in which the server saves data. The data stored in the hospital systems of each hospital A to E needs to be made inaccessible from the intra-hospital network 10 of other hospitals, especially from the viewpoint of personal information protection. In the second complex system in FIG. 4, in order to accommodate this, the physical storages 16-1 and 16-2 are partitioned to divide the storage into logical storages and are allocated to each container group 70. . Containers within each container group 70 can access only the assigned logical storage.

As an exception to this rule, suppose, for example, Hospital C and Hospital D are affiliated with the same hospital. At this time, there may be a need for hospitals C and D to share the saved images, although they each operate their own hospital systems individually. To cope with this, logical storage can be shared among a plurality of container groups 70. As an example, in FIG. 4, logical storage #2 of storage #1 (16-1) is shared by both hospital systems of hospital C and hospital D. In the hospital system of hospital B, only logical storage #1 of storage #1 (16-1) can be accessed, and logical storage #2 cannot be accessed. The same is true vice versa.

By dividing logical partitions in this way, it is possible to prevent each hospital's hospital systems from accessing data from each other, but as mentioned above, the data handled by hospitals often includes personal information. There may be cases where hospital policy requires data to be stored in physically independent storage. To accommodate this, hospitals will be allocated separate physical storage. In the example of FIG. 4, physically independent storage #2 (storage 16-2) is allocated to the hospital system of hospital E.

Furthermore, there may be cases in which it is not permissible to place personal information on a network outside the hospital in the first place. To accommodate this, data containing personal information can be stored in storage installed on the hospital network (on-premises). FIG. 5 is a block diagram showing a configuration example of a hospital system in which an in-hospital network includes storage. In the figure, parts common to those in FIG. 2 are denoted by the same reference numerals, and explanations thereof will be omitted. In the hospital system 2 in FIG. 5, a storage 101 is connected to an IP network (switch 14) in an in-hospital network 100 corresponding to the in-hospital network 10 in FIG. According to the in-hospital network 100 of FIG. 5, data including personal information can be stored in the storage 101 of the in-hospital network 100 instead of in the storage 16 of the cloud 20.

<Effect of clustering in the second complex system>
In the case where the cloud 20 is clustered like the second complex system shown in FIG. 4 which is made up of a plurality of hospital systems, the effects from the viewpoint of system control/maintenance will be explained. In the first complex system shown in FIG. 3, it is necessary to individually connect the control terminals 50-1 to 50-5 to the server group for each hospital system to perform system control/maintenance. Depending on the configuration of the VPN 40, the control terminals 50-1 to 50-5 themselves may be shared, but they still need to be managed individually.

On the other hand, in the second composite system of FIG. 4 in which the cloud 20 is clustered, it is possible to control the entire cluster 60 from a single control terminal 50 at once. Software that provides such functionality is generally called an orchestration tool, and examples include Kubernetes and Apache Mesos.

By specifying the computer resources required for each server configuring each hospital system, the orchestration tool determines the configuration of the cluster 60, deploys the necessary servers on the server computer 15, and provides computer resources for each server. Automatically allocate and control access. Orchestration tools also have a variety of other features, such as load balancing, automatic disaster recovery, and rolling updates. By utilizing these, management costs can be significantly lowered compared to managing individual hospital systems.

The expected benefits of clustering the cloud 20 are summarized below.

1. Reduce cloud usage costs by making efficient use of computing resources (number of CPU cores/memory capacity/storage capacity/number of GPUs, etc.).
2. Management costs are reduced by being able to manage fault monitoring, software updates, etc. all at once.

<Assignment>
In the second complex system in Figure 4, the hospital systems of each hospital have many functions that require a high processing load, such as video streaming and storage, and diagnostic support using AI, so the services used in each hospital's hospital system are It is assumed that the required computational resources (number of CPU cores/memory size used/whether or not GPU is used, etc.) will vary greatly depending on the content (features provided, number of clients, etc.). Further, as described above, in a hospital system, it is expected that the arrangement of the storage 16 and access control will become complicated from the viewpoint of protecting personal information.

On the other hand, for orchestration tools, it is necessary to specifically specify the required computational resources for each server. Therefore, it is necessary to calculate this calculation resource from the specifications of the services used in the hospital system of each hospital, but there are the following problems in doing this.

1. For the reasons mentioned above, calculation and management of required computational resources may become complicated and cumbersome.
2. Since the content of the service is expected to be changed one by one for each hospital, it is necessary to recalculate the calculation resources each time.

These issues lead to risks such as increased management costs, increased lead time required for system changes, and system failures due to incorrect settings.

To solve these issues, this technology automatically converts the service content (service definition data) used by individual hospital systems into computational resource requirements (cluster requirement definition data) that are input to the orchestration tool. As a result, even if the number of hospitals introducing the hospital system increases or the service content changes, the clustering configuration can be updated quickly, easily, and reliably (without mistakes) and the orchestration tool can be used efficiently. This allows for consistent and stable service operation. As a result, server usage costs and management costs can be reduced.

<Processing of control terminal 50>
FIG. 6 is a diagram illustrating the flow and configuration of processing at the control terminal 50 in the second complex system of FIG. 4. First, the control terminal 50 generates the service content used in the hospital system of each hospital as service definition data D1 (step S11). The service definition data D1 is generated by a generation unit (not shown) of the control terminal 50 based on information such as specifications exchanged with a company that develops and sells the system when the hospital introduces the hospital system. It is assumed that The case may be such that the operator inputs the service definition data D1 from an input device.

Next, the conversion unit (SW) 131 of the control terminal 50 automatically converts the service definition data D1 generated in step S11 into cluster requirement definition data D3 according to a predetermined conversion rule D2, and converts the service definition data D1 generated in step S11 into cluster requirement definition data D3. is generated (output) (step S12). The cluster requirement definition data D3 generated by the conversion unit 131 is input to the orchestration tool 132 through an input unit (not shown) (step S13).

The orchestration tool 132 operates as an operation unit, determines the clustering configuration of the servers of the hospital systems of all hospitals based on the input cluster requirement definition data D3, and operates the system group accordingly (step S14). . Even when the content of services used at each hospital is changed, the clustering configuration is updated using the same process flow (steps S11 to S14). Note that any software such as Kubernetes or Apache Mesos may be used as the orchestration tool 132, and in that case, the format of the cluster requirement definition data D3 differs depending on the type of the orchestration tool 132. Therefore, the converting unit 131 may generate the cluster requirement definition data D3 in a format that corresponds to the type of the orchestration tool 132, or the converting unit 131 may generate cluster requirement definition data D3 in a predetermined format. It may further include a conversion unit that converts the data D3 into cluster requirement definition data D3 in a format depending on the type of orchestration tool 132.

FIG. 7 is a diagram showing a specific example of the service definition data D1, conversion rule D2, and cluster requirement definition data D3 in FIG. 6. In this example, the service definition data D1 is an individual table for each customer. New tables are added when a new contract is entered into and a hospital system is introduced to a customer hospital. Further, when the content of the service is changed after introduction, the service definition data D1 is also updated.

The service definition data D1 in FIG. 7 includes data regarding the following items.
1. Customer ID
2. Hospital ID
3. The name of the hospital
Four. Basic service
4-1. number of clients
Five. Recording service
5-1. Number of simultaneous recordings
5-2. Storage time (h)
5-3. Destination
5-4. Intra-customer sharing
6. streaming service
6-1. number of clients
6-2. Number of simultaneous distributions (playbacks)
7. Diagnostic support service
7-1. number of clients

The customer ID in item 1 is the identification information of the customer who uses (contracts) the hospital system. Item 2, Hospital ID, is identification information that identifies the hospital that introduces the hospital system. Item 3, hospital name, is the name of the hospital that will introduce the hospital system. Item 4, Basic Service, indicates that the requirements regarding the basic service provided by the server #1 described above are described in sub-item 4-1. The number of clients in sub-item 4-1 is the number of devices connected to the in-hospital network (IP network) of the hospital where the hospital system is installed. Item 5, Recording Service, indicates that the requirements regarding the recording service provided by the server #2 described above are described in sub-items 5-1 to 5-4. The number of simultaneous recordings in sub-item 5-1 is the number of videos that can be recorded simultaneously. The storable time (h) in sub-item 5-2 is the total storable video time. The storage destination in sub-item 5-3 specifies whether the video is to be stored in the storage 16 of the cloud 20 or the storage 101 in the hospital network 100 (see FIG. 5). Item 6, Streaming Service, indicates that the requirements regarding the streaming service provided by the server #3 described above are described in sub-items 6-1 and 6-2. The number of clients in sub-item 6-1 is the number of devices that provide images (video) through streaming services. The number of simultaneous distributions (playbacks) in sub-item 6-2 is the number of videos that are simultaneously distributed by the streaming service. Item 7, Diagnosis Support Service, indicates that the requirements regarding the diagnosis support service provided by the server #4 described above are described in sub-item 7-1. The number of clients in sub-item 7-1 is the number of devices that acquire diagnostic support service information in the hospital's in-hospital network (IP network).

For example, in the example in Figure 3, the customer ID (001) and hospital A have a one-to-one relationship, but the customer ID (003) has a one-to-one relationship with hospital C and hospital D, which are affiliated hospitals. There will be many relationships. Hospital C uses basic services, recording services, streaming services, and diagnostic support services, and the requirements are described in the service definition data. Hospital D only uses basic services and recording services. Mutual sharing of recorded data between Hospitals C and D is enabled by stating "Yes" in item 5-4, data for intra-customer sharing. It is assumed that services are defined in the same format for hospitals A, B, and E.

As mentioned above, the service definition data D1 is assumed to be based on information such as specifications exchanged between the hospital that is the customer of the hospital system and the company that develops and sells the system. A text-based, highly readable format such as 7 should be used. Alternatively, a GUI (Graphical User Interface) as exemplified in FIGS. 8 and 9 may be displayed on the display unit (not shown) of the control terminal 50 to support input and editing of service definition data. FIG. 8 shows a list of customers, and by pressing the "edit" button, customer attributes can be changed and hospital systems included in the list can be added or deleted. Furthermore, when the items included in the customer list in FIG. 8 are expanded, the hospital systems included in the customer are displayed. When the "details button" of the hospital system is pressed, the screen changes to a detailed screen of the specifications of the individual hospital system as shown in FIG. The example in FIG. 9 shows the details of hospital D, and the specifications of the basic service and recording service to be used are set. On the other hand, streaming services and diagnostic support services are disabled on the GUI because they are not used.

Also, by setting the "storage" item of the recording service in Figure 9, you can select whether to save data to cloud storage or to storage installed on the hospital network (on-premises). be able to. In the service definition data D1 of FIG. 7, hospital D uses cloud-side storage, so this is reflected in FIG. 9 as well. Note that the contents described in the service definition data D1 vary depending on the contents of the services that the hospital can use, and are not limited to the contents related to the basic service/recording service/streaming service/diagnosis support service assumed in this example.

The conversion rule D2 in FIG. 7 defines the computer resources required for each service. For example, the following data is recorded:

"
Basic service -Up to 10 clients CPU core x1, Memory 2G
-CPU core x1 Memory 0.5G for every 20 clients after that
Recording service - Number of simultaneous recordings: CPU core x1, Memory 0.5G for each record
-Number of simultaneous recordings: GPUx1 for every 4
-Storage 2T for every 500h of storage time
Streaming service - CPUx1, Memory 0.5G for every 10 clients
-GPUx1 for every 4 simultaneous distribution (playback)
Diagnostic support service
- 2 CPU cores, 1G Memory, 1 GPU per client
”

For example, for basic services, the number of CPU cores required to support 10 client terminals (IPCs and server computers in the hospital network) connected to the hospital system is 1, the memory used is 2 GB, and additional 1 CPU core and 0.5 GB of memory are required for every 20 clients.

In this embodiment, the codec function supported by the GPU is assumed to be used when recording or playing back a video. The number of videos that can be simultaneously encoded or decoded per GPU is often determined for each GPU. For example, if the number of videos that can be supported simultaneously by one GPU is 4, the conversion as described in "Number of simultaneous recordings" for recording services and "Number of simultaneous distribution (playback)" of streaming services in Figure 7 It becomes a rule.

Furthermore, diagnostic support services generally involve heavy parallel calculations such as AI and image processing, and it is conceivable to utilize GPUs to perform such processing at high speed. Therefore, the "diagnosis support service" of conversion rule D2 in FIG. 7 also includes rules regarding the use of GPU. In general, the GPU cores used for AI and image processing are often different from the GPU cores used for video encoding and decoding as described above. In other words, it may be possible to support recording and streaming services and diagnostic support services in parallel on the same GPU. Although not included in the conversion rule D2 shown in FIG. 7, there is a possibility that the number of GPUs used can be reduced by adding such knowledge to the conversion rule.

The cluster requirement definition data D3 in FIG. 7 is generated by inputting the service definition data D1 and the conversion rule D2 to the conversion unit 131 of the control terminal 50. Since the cluster requirement definition data D3 is to be passed between software, it is preferable that the format is binary or text, such as JSON, which is highly compatible with program processing. In the example of FIG. 7, the description of the cluster requirement definition data D3 is written in a json style, but readability is prioritized and it does not conform to the json format.

In the cluster requirement definition data D3, ContainerGroup with ID 003-01 corresponds to hospital C (hospital ID: 003-01). ContainerGroup with ID 003-01 is described as follows.

"
ContainerGroup : {
Id: 003-01,
Address:
“https://sis.00301/”,
Container : {
BasicService : {
CpuCore: 2,
Memory: 2.5G
}
},
Container : {
RecorderService {
CpuCore: 8,
Memory: 4G,
GPU: 2,
Storage:
“sg://01/002/”
}
},
Container : {
StreamingService : {
CpuCore: 4,
Memory: 2G,
GPU: 2,
Storage:
“sg://01/002/”
}
},
Container : {
AnalysisService : {
CpuCore: 4,
memory: 2G,
GPU: 2
}
}
}
”

ContainerGroup corresponds to the container group in Figure 4. The Address of ContainerGroup is the address used when accessing the cloud server from a device within the hospital that connects to the hospital network of Hospital C. In this example, the protocol is HTTPS, but the protocol is not limited to this. Furthermore, ContainerGroup includes four Containers, each of which includes descriptions regarding BasicService (basic service), RecorderService (recording service), StreamingService (streaming service), and AnalysisService (diagnosis support service). This is because in Figure 4, the hospital system of Hospital C consists of four containers, each with server #1 (basic service), server #2 (recording service), server #3 (streaming service), and server #4 (diagnosis support). service) is hosted. Of these, for BasicService, CpuCore is 2 and Mmeory is 2.5G, but this is because the basic service requirement of Hospital C is 30 clients in the service definition data D1, so the conversion rule is 10 clients + Considering the additional 20 clients, the number of required CPU cores is 1 + 1 = 2, and the memory used is equivalent to 2G + 0.5G = 2.5G. Also, the reason why the recording service has 2 GPUs is because the requirement for Hospital C's recording service is 8 simultaneous recordings, and the conversion rule requires 1 GPU for every 4 videos. This corresponds to the number of units being 8/4 = 2 units. The same applies below.

Storage in the cluster requirement definition data D3 is storage supported by the cluster. Storage is described as follows.

"
Storage : {
Id: s01,
Address: “01”,
Partition : {
Name: “001”,
Size: 2T,
Member: { 002-01 }
},
Partition : {
Name: “002”,
Size: 6T,
Member: {
003-01, 003-02
}
}
},
Storage {
Id: s02,
Address: “02”,
Partition : {
Name: “001”,
Size: 2T,
Member: { 004-01 }
}
}
”

Storage #1 (storage 16-1) and storage #2 (storage 16-2) in FIG. 4 correspond to Storage with Id s01 and Storage with Id s02, respectively. Storage with ID s01 has two Partitions. This corresponds to logical storage #1 and logical storage #2 in FIG. 4, and is identified by Name (001/002). The member of the partition with ID s01 and storage name 001 is 002-01. This specifies the ContainerGroup that can access this partition (logical storage #1, hereinafter also referred to as partition #1), and in Figure 4, partition #1 is assigned to hospital B (Id:002-01). It corresponds to being there. When the RecorderService of ContainerGroup with ID 002-01 saves video, the storage destination is the address sg://01/001, which is a combination of the partition Id and Name above.

Similarly, due to the Member settings of the partition with Id s01 and Name 002, this partition can be accessed from ContainerGroup with Id 003-01 and ContainerGroup with Id 003-02. This corresponds to partition #2 (logical storage #2) being shared by hospital C and hospital D in FIG. The address of this storage destination will be sg://01/002 as above.

In addition, the storage capacity required by Hospital C is 1000h/500h x 2T = 4T from the service definition data D1 (storable time 1000h) and conversion rule D2 (storage 2T for every 500h storage time). The storage capacity is also 2T, so the total is 6T. Accordingly, the capacity of the partition whose ID is s01 and whose Name is 002 in the cluster requirement definition data D3 is set to 6 TB.

There is only one Partition for Storage with Id s02, and it can only be accessed from ContainerGroup with Id 004-01. This corresponds to hospital E being allocated physically independent storage #2 (storage 16-2) in FIG. The address of this storage destination will be sg://02/001. Note that when using the storage 101 (see Figure 5) connected to the IP network of the hospital network 10, it is described as cluster requirement definition data D3 like storage #1 and storage #2, but the details are as follows. explain.

According to the control terminal 50 in the second complex system shown in FIG. 4, the service content (service definition data) used by each hospital is automatically converted into computational resource requirements (cluster requirement definition data) and orchestrated. Since the data is entered into the orchestration tool, even if the number of hospitals that introduce the hospital system increases or the services used change, the clustering configuration can be updated quickly, easily, and reliably (without mistakes) and the orchestration tool can be used. You will be able to do this. Furthermore, it becomes possible to perform efficient and stable system operation. As a result, server usage costs and management costs are reduced.

<Computer configuration example>
Next, the series of processes of the control terminal 50 described above can be performed by hardware or software. When a series of processes is performed using software, the programs that make up the software are installed on a general-purpose computer or the like.

FIG. 10 is a block diagram showing a configuration example of an embodiment of a computer in which a program that executes the series of processes described above is installed.

The program can be recorded in advance on the hard disk 205 or ROM 203 as a recording medium built into the computer.

Alternatively, the program can be stored (recorded) in a removable recording medium 211 driven by the drive 209. Such a removable recording medium 211 can be provided as so-called package software. Here, the removable recording medium 211 includes, for example, a flexible disk, a CD-ROM (Compact Disc Read Only Memory), an MO (Magneto Optical) disk, a DVD (Digital Versatile Disc), a magnetic disk, and a semiconductor memory.

In addition to being installed on the computer from the removable recording medium 211 as described above, the program can also be downloaded to the computer via a communication network or broadcasting network and installed on the built-in hard disk 205. In other words, a program can be transferred wirelessly from a download site to a computer via an artificial satellite for digital satellite broadcasting, or transferred to a computer by wire via a network such as a LAN (Local Area Network) or the Internet. be able to.

The computer has a built-in CPU (Central Processing Unit) 202, and an input/output interface 120 is connected to the CPU 202 via a bus 201.

When a user inputs a command through an input/output interface 210 by operating an input unit 207, the CPU 202 executes a program stored in a ROM (Read Only Memory) 203 in accordance with the command. . Alternatively, the CPU 202 loads the program stored in the hard disk 205 into the RAM (Random Access Memory) 204 and executes it.

Thereby, the CPU 202 performs processing according to the above-described flowchart or processing performed according to the configuration of the above-described block diagram. Then, the CPU 202 outputs the processing result from the output unit 206 or transmits it from the communication unit 208 via the input/output interface 210, or records it on the hard disk 205, as necessary.

Note that the input unit 207 is composed of a keyboard, a mouse, a microphone, etc. Further, the output unit 206 includes an LCD (Liquid Crystal Display), a speaker, and the like.

Here, in this specification, the processing that a computer performs according to a program does not necessarily have to be performed chronologically in the order described as a flowchart. That is, the processing that a computer performs according to a program includes processing that is performed in parallel or individually (for example, parallel processing or processing using objects).

Further, the program may be processed by one computer (processor) or may be processed in a distributed manner by multiple computers. Furthermore, the program may be transferred to a remote computer and executed.

Furthermore, in this specification, a system refers to a collection of multiple components (devices, modules (components), etc.), regardless of whether all the components are located in the same casing. Therefore, multiple devices housed in separate casings and connected via a network, and a single device with multiple modules housed in one casing are both systems. .

Furthermore, for example, the configuration described as one device (or processing section) may be divided and configured as a plurality of devices (or processing sections). Conversely, the configurations described above as a plurality of devices (or processing units) may be configured as one device (or processing unit). Furthermore, it is of course possible to add configurations other than those described above to the configuration of each device (or each processing section). Furthermore, part of the configuration of one device (or processing unit) may be included in the configuration of another device (or other processing unit) as long as the configuration and operation of the entire system are substantially the same. .

Furthermore, for example, the present technology can take a cloud computing configuration in which one function is shared and jointly processed by multiple devices via a network.

Also, for example, the above-mentioned program can be executed on any device. In that case, it is only necessary that the device has the necessary functions (functional blocks, etc.) and can obtain the necessary information.

Note that in a program executed by a computer, the processing of the steps described in the program may be executed in chronological order according to the order described in this specification, in parallel, or in a manner in which calls are made. It may also be configured to be executed individually at necessary timings such as at certain times. In other words, the processing of each step may be executed in a different order from the order described above, unless a contradiction occurs. Furthermore, the processing of the step of writing this program may be executed in parallel with the processing of other programs, or may be executed in combination with the processing of other programs.

Note that the present technology described multiple times in this specification can be independently implemented as a single unit unless a contradiction occurs. Of course, it is also possible to implement any plurality of the present techniques in combination. For example, part or all of the present technology described in any embodiment can be implemented in combination with part or all of the present technology described in other embodiments. Furthermore, part or all of any of the present techniques described above can be implemented in combination with other techniques not described above.

<Example of configuration combinations>
Note that the present technology can also have the following configuration.
(1)
In a video network system for hospitals, a generation step of generating service contents used by individual hospitals as service definition data;
a conversion step of converting the service definition data into cluster requirement definition data according to predetermined conversion rules;
an input step of inputting the cluster requirement definition data into an orchestration tool;
An information processing method comprising: an operation step in which the orchestration tool operates the individual hospital video network systems on clustered server computers according to the cluster requirement definition data.
(2)
The information processing method according to (1) above, wherein the generation step acquires data of the service content using a GUI.
(3)
The information processing method according to (1) or (2), wherein the generation step includes requirements regarding control of routing of transferred images in the service definition data.
(4)
The information processing method according to any one of (1) to (3), wherein the generation step includes requirements regarding any one of a recording service, a streaming service, and a diagnostic support service in the service definition data.
(5)
The information processing method according to any one of (1) to (4), wherein the generation step includes customer identification information and hospital identification information in the service definition data.
(6)
In the generation step, the requirements regarding the recording service are included in the service definition data, and as the requirements regarding the recording service, images recorded by the recording service in the video network system for one hospital are included in the image recording service for another hospital. The information processing method according to any one of (1) to (5) above, wherein information about whether or not it can be accessed from the video network system is included in the service definition data.
(7)
The converting step converts the service definition data into the cluster requirement definition data according to data regarding calculation resources required according to the service content as the conversion rule, according to any one of (1) to (6) above. information processing methods.
(8)
The information processing method according to (7), wherein the conversion rule includes data regarding the number of CPU cores, memory size used, and whether GPU is used or not, as data regarding the calculation resources.
(9)
The information processing method according to any one of (1) to (8), wherein the input step inputs the cluster requirement definition data to Kubernetes as an orchestration tool.
(10)
The information processing method according to any one of (1) to (9), wherein the operation step allocates computer resources to server applications that execute respective services of the individual hospital video network systems.
(11)
The information processing method according to any one of (1) to (10), wherein the operation step controls access to computer resources for server applications that execute respective services of the individual hospital video network systems.
(12)
A video network system for hospitals includes a conversion unit that converts service definition data indicating service content used by individual hospitals into cluster requirement definition data that is input to an orchestration tool according to predetermined conversion rules. Information processing system.
(13)
The information processing system according to (12), further comprising: a generation unit that generates the service definition data.
(14)
The information processing system according to (12) or (13), further comprising: an operation unit that operates the individual hospital video network systems on clustered servers according to the cluster requirement definition data.
(15)
computer,
In a video network system for hospitals, it functions as a conversion unit that converts service definition data indicating the service content used by individual hospitals into cluster requirement definition data that is input to the orchestration tool according to predetermined conversion rules. A program to do this.

Note that this embodiment is not limited to the embodiment described above, and various changes can be made without departing from the gist of the present disclosure. Moreover, the effects described in this specification are merely examples and are not limited, and other effects may also be present.

1, 2 hospital system, 10, 10', 100 hospital network, 11 modality, 12 monitor, 14 switch, 15 server computer, 16, 101 storage, 17 client terminal, 18 client terminal, 19 client terminal , 20 Cloud, 30 Management Operator network, 50 control terminal, 60 cluster, 70 container group, 80 container

Claims

In a video network system for hospitals, a generation step of generating service contents used by individual hospitals as service definition data;
a conversion step of converting the service definition data into cluster requirement definition data according to predetermined conversion rules;
an input step of inputting the cluster requirement definition data into an orchestration tool;
An information processing method comprising: an operation step in which the orchestration tool operates the individual hospital video network systems on clustered server computers according to the cluster requirement definition data.
The information processing method according to claim 1, wherein the generation step acquires data of the service content using a GUI.
The information processing method according to claim 1, wherein the generation step includes requirements regarding control of routing of transferred images in the service definition data.
The information processing method according to claim 1, wherein the generation step includes requirements regarding any one of a recording service, a streaming service, and a diagnostic support service in the service definition data.
The information processing method according to claim 1, wherein the generation step includes customer identification information and hospital identification information in the service definition data.
In the generation step, the requirements regarding the recording service are included in the service definition data, and as the requirements regarding the recording service, images recorded by the recording service in the video network system for one hospital are included in the image recording service for another hospital. The information processing method according to claim 1, wherein the service definition data includes whether or not it can be accessed from the video network system.
The information processing method according to claim 1, wherein the conversion step converts the service definition data into the cluster requirement definition data according to data regarding calculation resources required according to the service content as the conversion rule.
The information processing method according to claim 7, wherein the conversion rule includes data regarding the number of CPU cores, memory size used, and whether or not GPU is used as data regarding the calculation resource.
The information processing method according to claim 1, wherein the input step inputs the cluster requirement definition data to Kubernetes as an orchestration tool.
The information processing method according to claim 1, wherein the operation step allocates computer resources to server applications that execute services of each of the individual hospital video network systems.
The information processing method according to claim 1, wherein the operation step controls access to computer resources for server applications that execute services of each of the individual hospital video network systems.
A video network system for hospitals includes a conversion unit that converts service definition data indicating service content used by individual hospitals into cluster requirement definition data that is input to an orchestration tool according to predetermined conversion rules. Information processing system.
The information processing system according to claim 12, further comprising: a generation unit that generates the service definition data.
The information processing system according to claim 12, further comprising: an operation unit that operates the individual hospital video network systems on clustered servers according to the cluster requirement definition data.
computer,
In a video network system for hospitals, it functions as a conversion unit that converts service definition data indicating the service content used by individual hospitals into cluster requirement definition data that is input to the orchestration tool according to predetermined conversion rules. A program to do this.