Information processing system and control method

Abstract

To provide information processing systems and control methods suitable for fields such as patient care. [Solution] The information processing system includes a converter unit that acquires first data containing sleep information about a patient's sleep from equipment related to patient care, and outputs second data in an IHE-compliant data format that includes sleep information in the field values ​​of the OBX (Observation Result) segment in HL7 (Health Level Seven) used in IHE (Integrating the Healthcare Enterprise), and a manager unit that acquires the second data from the converter unit and manages the second data.

Description

Technical Field

[0001] The present invention relates to an information processing system, a control method, and the like.

Background Art

[0002] Conventionally, a method of presenting patient information has been disclosed in a system including a terminal provided near a bed. Also, IHE (Integrating the Healthcare Enterprise), which promotes the interoperability of medical information systems, is known.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] To provide an information processing system, a control method, and the like suitable for the field of patient care and the like.

Means for Solving the Problems

[0005] One aspect of the present disclosure relates to an information processing system including: a converter unit that acquires first data including sleep information regarding the sleep of a patient from a device related to patient care, and outputs second data obtained by transforming the first data into a data format according to IHE (Integrating the Healthcare Enterprise) in which the sleep information is included in a field value of an OBX (Observation Result) segment in HL7 (Health Level Seven) used in IHE; and a manager unit that acquires the second data from the converter unit and manages the second data.​​​Another aspect of this disclosure relates to a control method in which an information processing system acquires first data, including sleep information relating to a patient's sleep, from equipment related to patient care; transforms the first data into second data in a data format compliant with IHE (Integrating the Healthcare Enterprise), which includes the sleep information in the field values ​​of the OBX (Observation Result) segment in HL7 (Health Level Seven) used in IHE; and manages the second data. [Brief explanation of the drawing]

[0007] [Figure 1] This diagram illustrates an example configuration of the information processing system according to this embodiment. [Figure 2] This diagram illustrates an example of a medical system configuration used in a medical facility. [Figure 3] This figure shows an example of the structure of an ORU message. [Figure 4] This figure shows specific examples of inspection items included in the field values ​​of an OBX segment. [Figure 5A] This figure shows an example of the OBX segment configuration in an ORU message. [Figure 5B] This figure shows an example of the OBX segment configuration in an ORU message. [Figure 5C] This figure shows an example of the OBX segment configuration in an ORU message. [Figure 6A] This figure shows an example of the OBX segment configuration in an ORU message. [Figure 6B] This figure shows an example of the OBX segment configuration in an ORU message. [Figure 7] This is a sequence diagram explaining the message sorting process. [Figure 8] This figure shows an example of a forward table. [Figure 9] This diagram illustrates the flow of the distribution process based on the forward table. [Figure 10A]An example of a display screen used when updating the forward table. [Figure 10B] An example of a display screen used when updating the forward table. [Figure 11] A sequence diagram explaining the activation process of a message. [Figure 12] A diagram showing an example of an activation table. [Figure 13] A diagram explaining the flow of the process for activating an ADT message. [Figure 14] A diagram explaining the flow of the process for activating an OMP message. [Figure 15] A diagram explaining the flow of the process for activating an OSQ message. [Figure 16] A diagram explaining the system configuration around an electronic bed. [Figure 17] An example of the configuration of a system including an electronic medical record system. [Figure 18] A diagram explaining the flow of the distribution process in the system shown in FIG. 17. [Figure 19] A diagram showing an example of a forward table.

Mode for Carrying Out the Invention

[0008] Hereinafter, this embodiment will be described with reference to the drawings. For the drawings, the same or equivalent elements are denoted by the same reference numerals, and redundant explanations are omitted. Note that the embodiment described below does not unduly limit the content described in the claims. Also, not all of the configurations described in this embodiment are essential constituent elements of the present disclosure.

[0009] 1. System Configuration FIG. 1 is a diagram showing a configuration example of an information processing system 10 according to the present embodiment. The information processing system 10 includes a converter unit 11 and a manager unit 12. The information processing system 10 may further include a storage 13, a patient RFID (Radio Frequency Identification) 21, a patient beacon 22, a staff RFID 23, a staff beacon 24, an electric bed 31, an air mattress 32, a peripheral device 41, a medical device 42, a mobile terminal device 43, an electronic medical record system (EMR) 51, a vital sign monitoring system 52, an infusion pump 53, and a BMAS (Barcode Medication Administration System) / BCMA (Bar Code Medication Administration) 54. Note that the configuration of the information processing system 10 is not limited to the example shown in FIG. 1, and various modifications such as omitting some configurations or adding other configurations are possible. For example, the configurations other than the converter unit 11 and the manager unit 12 in FIG. 1 may not be included in the information processing system 10 of the present embodiment and may be provided as an external device / external system that communicates with the information processing system 10.

[0010] The information processing system 10 according to the present embodiment is a system used in a medical facility such as a hospital. In such a system, as shown in FIG. 1, various configurations (devices, systems) are used, so it is necessary to share information regarding a patient's disease and treatment among these configurations. At this time, if each device or system uses a vendor-specific data format, data sharing becomes difficult in a multi-vendor environment in which devices and systems of different vendors are combined.

[0011] Therefore, the IHE (Integrating the Healthcare Enterprise) standard, which promotes the interoperability of medical information systems, is well known. IHE uses "DICOM" (Digital Imaging and Communications in Medicine), a standard in the medical imaging field, and "HL7" (Health Level Seven), a standard for medical text information such as electronic medical records. IHE also defines several areas, including radiology, cardiology, and endoscopy, and one of these areas is known as PCD (Patient Care Device). In the PCD area, standardization is carried out for devices related to patient care, such as improving inter-device connectivity, standardizing data formats, managing and communicating patient alarms, managing equipment, ensuring the accuracy of instructions for treatment and care such as intravenous fluids, and managing implanted devices.

[0012] However, because sleep information representing a patient's sleep state is not standardized by IHE, it has been difficult to appropriately share this sleep information in a multi-vendor environment. Furthermore, when a medical bed with adjustable height and angle of the mattress base (e.g., the electronic bed 31 in Figure 1) is used, bed information, including the height, back angle, and knee angle of the medical bed, is useful for patient care because it relates to the patient's posture and ease of movement. However, conventionally, bed information has not been standardized by IHE, making it difficult to appropriately share this bed information in a multi-vendor environment.

[0013] Furthermore, in environments where various devices are used, it is considered efficient to distribute information output from one device / system to various other devices / systems. For example, if information detected by device A is to be used in processing by device B, then a distribution process that sends that information to device B is useful. However, in conventional systems that apply IHE, efficient information distribution was not easy, as information was first aggregated into electronic medical records (EMR).

[0014] Furthermore, as will be described later, HL7, used in IHE, defines various messages, and each message has different characteristics because it includes information such as message codes and trigger events. Therefore, HL7 messages are used selectively depending on the situation. However, in conventional systems that apply IHE, when data is received using a given message, there is no process to spontaneously activate a different message in order to output that data.

[0015] Therefore, in this embodiment, we propose an information processing system 10 that extends IHE to include sleep information and bed information. In addition, in this embodiment, we propose an information processing system 10 that appropriately distributes information, and an information processing system 10 that appropriately activates messages according to conditions.

[0016] The following describes the various components of the information processing system 10 shown in Figure 1. Furthermore, Figure 2, which shows specific examples of devices / systems used in medical facilities, will be used to explain specific examples of the components of the information processing system 10.

[0017] As shown in Figure 1, the information processing system 10 includes a converter unit 11, a manager unit 12, and storage 13. It is assumed that the converter unit 11 and the manager unit 12 are implemented as separate devices. In this case, the storage 13 may be provided in the device that includes the manager unit 12, or it may be provided in a device different from the manager unit 12. Furthermore, there is no prejudice that a single device includes both the converter unit 11 and the manager unit 12.

[0018] For example, the information processing system 10 may include a first device including a converter unit 11 and a second device including a manager unit 12 and storage 13. The first device includes a communication unit that communicates with, for example, a patient RFID 21 and the second device, and a processing unit. The first device may be, for example, a small computer including a communication interface and a processor, and in a narrow sense, a single-board computer (SBC). For example, the first device may be attached to the electronic bed 31 from the viewpoint of collecting patient information using the electronic bed 31 in the vicinity of the electronic bed 31.

[0019] The second device includes, for example, a communication unit that communicates with the first device and with the electronic medical record system 51 described later, a processing unit, and a storage unit which is the storage 13. The second device is, for example, a PC (Personal Computer) or a server, but a device with a different configuration may be used. The second device may also be included in other configurations shown in Figure 1. For example, the manager unit 12 may be included in the electronic bed 31 as described later using Figure 16, or it may be included in the electronic medical record system 51 as described later using Figure 17. The manager unit 12 may also be provided in multiple devices, and both the electronic bed 31 and the electronic medical record system 51 may include the manager unit 12.

[0020] The converter unit 11 and manager unit 12 of this embodiment may be composed of the following hardware. The hardware may include at least one of a circuit that processes digital signals and a circuit that processes analog signals. For example, the hardware may consist of one or more circuit devices or one or more circuit elements mounted on a circuit board. One or more circuit devices may be, for example, an IC (Integrated Circuit), an FPGA (field-programmable gate array), etc. One or more circuit elements may be, for example, a resistor, a capacitor, etc.

[0021] Furthermore, the converter unit 11 and the manager unit 12 may be implemented by the following processor. The device including the converter unit 11 and the device including the manager unit 12 include a memory for storing information and a processor that operates based on the information stored in the memory. The information is, for example, a program and various types of data. The memory may be storage 13 or other types of memory. The processor includes hardware. Various types of processors can be used, such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), and DSP (Digital Signal Processor). The memory may be semiconductor memory such as SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), or flash memory, or it may be a register, or it may be a magnetic storage device such as a hard disk drive (HDD), or it may be an optical storage device such as an optical disk drive. For example, the memory stores instructions that can be read by a computer, and the functions of the converter unit 11 and the manager unit 12 are realized as processing when the processor executes these instructions. The instructions referred to here may be instructions from the instruction set that makes up the program, or they may be instructions that instruct the processor's hardware circuits to perform actions.

[0022] Patient RFID 21 is an RFID tag (wireless IC tag) worn by the patient. Staff RFID 23 is an RFID tag worn by healthcare staff. For example, an RFID reader may be installed at a designated location within the medical facility, and the RFID reader may read RFID tags located within a predetermined range. The RFID tag includes, for example, ID information, and this ID information is pre-associated with information that identifies the wearer, whether a patient or staff member. In this way, it becomes possible to estimate the location of patients and staff. Patient RFID 21 and staff RFID 23 are RFID readers, and RFID tags may be placed at designated locations within the medical facility.

[0023] The patient beacon 22 is a terminal worn by the patient that periodically emits a beacon signal. The staff beacon 24 is a terminal worn by the staff that periodically emits a beacon signal. For example, a beacon receiving device may be installed at a predetermined location within the medical facility, and the receiving device may receive beacon signals located within a predetermined range. The beacon signal includes the ID information of the terminal, and this ID information is associated in advance with information that identifies the wearer, whether a patient or staff member. In this way, it becomes possible to estimate the location of patients and staff. Note that the patient beacon 22 and the staff beacon 24 are beacon signal receiving devices, and terminals that emit beacon signals may be placed at predetermined locations within the medical facility.

[0024] In this context, "staff" primarily refers to nurses. However, the term "staff" may also include other healthcare professionals such as doctors, caregivers, occupational therapists, and physical therapists.

[0025] The electronic bed 31 is a bed used by a patient, and its height and angle can be changed by electronic control. The air mattress 32 is a mattress used by a patient and placed on the electronic bed 31. The air mattress 32 may be a bed in which the amount of air injected can be changed by electronic control. For example, the air mattress 32 may be a mattress divided into multiple areas, with the height of each area adjustable. The air mattress 32 may also include a load sensor and be a mattress capable of detecting pressure values.

[0026] Peripheral devices 41 include various devices placed around the patient or the electronic bed 31. Medical devices 42 may be devices used for medical procedures on the patient, devices used for detecting the patient's vital information, or both. Portable terminal devices 43 are devices carried by staff and are implemented as smartphones or tablet devices.

[0027] The electronic medical record system 51 is, for example, an EMR (Electronic Medical Record) and is a system that stores the patient's electronic medical record. The vital signs monitoring system 52 is a system that continuously monitors the patient's vital signs. The vital signs monitoring system 52 acquires detection results from a device that detects vital signs and performs analysis processing of the detection results. The device that detects vital signs may include the medical device 42 described above.

[0028] The infusion pump 53 is a device that controls the flow rate per unit time of infusion or drug administration. The BMAS / BCMA 54 is a system that adjusts the control parameters of the infusion pump 53. The infusion pump 53 may also be included in the medical device 42.

[0029] Figure 2 shows an example of the configuration of a medical system used in medical facilities such as hospitals. Below, we will explain an example of a medical system using Figure 2, and also explain an example of the implementation of the device / system of the information processing system 10 shown in Figure 1.

[0030] The medical system shown in Figure 2 includes a bed 100, a bedside terminal device 200, a server system 300, an electronic medical record server 400, a station terminal device 500, a terminal device 600, an imaging device 700, a detection device 810, a measuring device 820, an authentication card 830, and an IC tag 840. Note that the medical system is not limited to the example in Figure 2, and various modifications are possible, such as omitting some components or adding other components.

[0031] The bed 100 is bedding used by a patient. For example, a mattress 170 is placed on the bed 100, and the patient lies on the mattress 170. An imaging device 700 and a detection device 810 are provided near the bed 100. The imaging device 700 is a camera fixed to, for example, the frame of the bed 100, but it may also be fixed to the wall of the patient's room. The detection device 810 is a sheet-like or plate-like device provided between, for example, the bed 100 and the mattress 170.

[0032] The imaging device 700 outputs captured images using sensors such as a CCD (Charge-Coupled Device) image sensor or a CMOS (Complementary Metal-Oxide-Semiconductor) image sensor. The captured images here may be moving images or still images. The imaging device 700 is installed near the bed 100 and, for example, captures images of a patient in a hospital room.

[0033] The detection device 810 is a device that senses information related to the patient's sleep. The detection device 810 includes a pressure sensor (e.g., a pneumatic sensor) that outputs a pressure value. When the user lies down, the detection device 810 detects the user's body vibrations (body movement, vibration) via the mattress 170. Based on the detected body vibrations, the detection device 810 obtains information related to respiratory rate, heart rate, activity level, posture, wakefulness / sleep, and getting out of bed / staying in bed. The detection device 810 may output sensor data representing body vibrations, and other devices such as the server system 300 may perform processing to obtain information such as respiratory rate based on this sensor data. The following describes an example in which the detection device 810 outputs information such as respiratory rate.

[0034] For example, the detection device 810 may analyze the periodicity of body movement and calculate the respiratory rate and heart rate from the peak frequency. The periodicity analysis may be performed using, for example, a Fourier transform. The respiratory rate is the number of breaths per unit time. The heart rate is the number of heartbeats per unit time. The unit time is, for example, one minute. The detection device 810 may also detect body vibrations per sampling unit time and output the number of detected body vibrations as the activity level. Furthermore, when the user gets out of bed, the detected pressure value decreases compared to when the user is in bed, so the detection device 810 may determine whether the user is in bed or out of bed based on the pressure value and its time-series changes. However, the method for determining whether the user is in bed or out of bed is not limited to this, and various modifications such as detecting vibrations can be implemented. The detection device 810 may also determine non-REM sleep and REM sleep, and determine the depth of sleep. The sleep-related determination may be performed based on the respiratory rate and heart rate, based on the amount of body movement (e.g., activity level), or using both.

[0035] The detection device 810 outputs biological information (such as respiration and heart rate) representing the patient's biological activity status, and sleep information (such as sleep / wake status, sleep depth, and whether the patient is out of bed or in bed) to the server system 300. The detection device 810 may output the sensing results to the server system 300 via the bedside terminal device 200, or it may output the sensing results to the server system 300 without going through the bedside terminal device 200.

[0036] A device equipped with a load sensor may be used as the bed 100. In this case, the bed 100 may output at least one of the patient's biological information and sleep information. The bed 100 may also output information representing changes in the patient's center of gravity and information representing their sleeping posture. Furthermore, the detection device 810 and the bed 100 with a load sensor may be used in combination.

[0037] The bedside terminal device 200 is a device that has a patient status notification function (notification function) and may be connected to the detection device 810 or to other devices included in the information processing system 10 via a network.

[0038] For example, the bedside terminal device 200 may include a display device and a connection device. The display device is, for example, a tablet-type display terminal that displays various information and accepts input for various operations. The connection device is a hub device for connecting the display device and the various devices. For example, the connection device may be connected to a detection device 810 to continuously acquire the patient's biometric information. The connection device may also receive biometric information from various measuring devices 820 (e.g., a thermometer) or from a device worn by the patient (e.g., a wristwatch-type wearable measuring device). The connection device may also perform authentication processing (e.g., patient authentication or login processing for nurses, etc.) by reading an authentication card 830 or an IC tag 840. The connection device may perform authentication processing using NFC (Near Field Communication), which is an example of short-range wireless communication, or it may perform authentication processing using other methods such as barcodes or infrared. For example, a user (nurse, doctor, care staff) can check the values ​​of biometric information and notification content by logging in, and can register that information in the electronic medical record as needed.

[0039] Furthermore, the reader for the IC tag 840 is not limited to the bedside terminal device 200, but may be other devices such as the terminal device 600. Also, the reader may be placed in designated locations within the hospital, such as patient rooms, dining rooms, and restrooms.

[0040] The network is connected to, for example, a server system 300, an electronic medical record server 400, a station terminal device 500, and a terminal device 600.

[0041] The server system 300 is a server that provides various services and may be connected to the LAN within the hospital or facility, or it may be located externally via the internet.

[0042] The server system 300 may consist of one server or may include multiple servers. For example, the server system 300 may include a database server and an application server. The database server stores various data such as biological information and sleep information. The application server performs management processing for patients and various devices / systems. The multiple servers here may be physical servers or virtual servers. If virtual servers are used, the virtual servers may be located on a single physical server or distributed across multiple physical servers. As described above, the specific configuration of the server system 300 in this embodiment can be modified in various ways.

[0043] The electronic medical record server 400 is a server that stores electronic medical record information about patients. The electronic medical record server 400 is typically a server connected to a network within the hospital or facility, but it may also be an external cloud server, for example. Electronic medical records can contain various types of information. Electronic medical records include, for example, basic information, medical history, diagnostic information, medication information, test results, consultation information, treatment information, rehabilitation history, vaccination history, lifestyle information, family history, consent forms and signatures, insurance and medical information, medical team information, social background, mental health, emergency response plan, medical resource history, communication with family, infection control, risk assessment, physician's instructions, measurement results, response history, nurse call history, rehabilitation care history, transfer / referral letter history, therapeutic guidance history, patient complaint / chief complaint history, patient behavior information, blood glucose information, diet therapy information, water intake information, electrocardiogram information, pulse information, information on visits to multiple departments, interdepartmental coordination information, behavioral video recordings, video file storage information, physician / nurse responses based on videos, respiratory rate information, arterial blood oxygen saturation information, excretion information, room temperature and humidity information, etc. However, the above are specific examples of information included in electronic medical records, and various modifications are possible, such as omitting some information or adding other information.

[0044] The electronic medical record system of this embodiment may include other systems. Examples of other systems include nursing support systems, rehabilitation department systems, critical care department systems, and nutrition department systems.

[0045] The station terminal device 500 is a terminal device installed in the nurses' station or management room. By using the station terminal device 500, users such as nurses can check the status of the bedside terminal device 200 (i.e., the status of the patient corresponding to the bedside terminal device 200) from a location other than the patient's room.

[0046] The terminal device 600 is a portable device used by medical staff, such as doctors and nurses. The terminal device 600 for medical staff connects to a network (e.g., LAN) via a wireless connection. By using the terminal device 600, medical staff can check information from the bedside terminal device 200 from various locations within the hospital.

[0047] The patient RFID 21 shown in Figure 1 corresponds to the IC tag 840 in Figure 2. The patient RFID 21 is attached to the patient's clothing, for example, as shown in Figure 2. Although the patient beacon 22 is omitted in Figure 2, a beacon signal transmitter may be attached to the patient instead of the IC tag 840. Also, although the staff RFID 23 and staff beacon 24 are omitted in Figure 2, these devices may be attached to the staff's clothing, or a terminal device 600 carried by the staff may have the corresponding functions.

[0048] The electronic bed 31 in Figure 1 corresponds to the bed 100 in Figure 2. The air mattress 32 corresponds to the mattress 170.

[0049] The peripheral device 41 in Figure 1 corresponds to the bedside terminal device 200 and imaging device 700 shown in Figure 2. The peripheral device 41 may also include various devices not shown in Figure 2, such as a smart speaker and a drive device for automatically opening and closing curtains. The medical device 42 in Figure 1 corresponds to the detection device 810 and measuring device 820 in Figure 2. Furthermore, if the bed 100 includes a load sensor and can detect vital information such as respiratory rate and heart rate based on the load sensor, the medical device 42 may also include the bed 100. The portable terminal device 43 in Figure 1 corresponds to the terminal device 600 in Figure 2.

[0050] The electronic medical record system 51 in Figure 1 corresponds to the electronic medical record server 400 in Figure 2. The vital signs monitoring system 52 corresponds to a server system 300 that collects and analyzes information output by, for example, a detection device 810. However, the vital signs monitoring system 52 may be a device installed around the bed 100 that displays monitoring results, or the bedside terminal device 200 may also function as the vital signs monitoring system 52. The infusion pump 53 in Figure 1 is not shown in Figure 2. The infusion pump 53 may be installed on a stand with casters, for example, and moved along with the patient's movement. The BMAS / BCMA 54 may be implemented in a configuration not shown in Figure 2, or it may be implemented by the server system 300.

[0051] As described above, the information processing system 10 according to this embodiment may be extended to handle sleep information. Specifically, the converter unit 11 acquires first data from equipment related to patient care and outputs second data which is the first data transformed into a format conforming to IHE (Integrating the Healthcare Enterprise). Specifically, the converter unit 11 acquires first data which includes sleep information about the patient's sleep, converts the first data into data conforming to the IHE format which includes sleep information in the field values ​​of the OBX (Observation Result) segment in HL7 used in IHE, and outputs the converted data, the second data, to the manager unit. The manager unit 12 then acquires the second data from the converter unit 11 and manages the second data. Management of the second data may, for example, be the management of the output destination of the second data, as will be described later, or it may be the management of the HL7 message used for outputting the second data, or both.

[0052] Here, the equipment related to patient care includes, for example, the patient RFID 21, patient beacon 22, staff RFID 23, staff beacon 24, electronic bed 31, air mattress 32, peripheral equipment 41, and medical device 42 shown in Figure 1. The equipment related to patient care may also include an infusion pump 53. The equipment related to patient care may also be equipment that acquires sleep information, for example, the detection device 810 in Figure 2, or a bed 100 including a load sensor.

[0053] According to the method of this embodiment, the converter unit 11 can output sleep information in accordance with the specifications of HL7, a standard used by IHE. As a result, sleep information is appropriately shared even in a multi-vendor environment, making it possible to appropriately perform patient care using sleep information. Details of the OBX segment will be described later using Figures 4-6B, etc.

[0054] Similarly, the converter unit 11 outputs data containing bed information in the field values ​​of the OBX segments in HL7 to the manager unit 12 as second data. This makes it possible to properly share bed information even in a multi-vendor environment.

[0055] As described above, the information processing system 10 according to this embodiment may also perform sorting of acquired information. Specifically, the manager unit 12, which has acquired second data from the converter unit 11, may output the second data to one or more systems, including the electronic medical record system (EMR) 51. In this case, the manager unit 12 may perform sorting processing to determine the destination of the second data according to the content of the second data. Specific processing will be described later using Figures 7-10B. The manager unit 12 may also activate a message based on the second data. The message here refers to a message defined in HL7. Specific processing will be described later using Figures 11-15.

[0056] Furthermore, some or all of the processing performed by the information processing system 10 in this embodiment may be implemented by a program. The processing performed by the information processing system 10 refers, in a narrow sense, to the processing performed by the converter unit 11 and the manager unit 12, but it may also include processing performed by other devices shown in Figure 1.

[0057] The program according to this embodiment can be stored in a non-temporary information storage medium (information storage device), which is a medium readable by a computer. The information storage medium can be implemented as, for example, an optical disc, a memory card, an HDD, or a semiconductor memory. The semiconductor memory is, for example, a ROM. The converter unit 11 and the manager unit 12, etc., perform various processing according to this embodiment based on the program stored in the information storage medium. That is, the information storage medium stores a program that causes the computer to function as the converter unit 11 and the manager unit 12, etc. of the information processing system 10. The computer is a device that includes an input device, a processing unit, a storage unit, and an output unit. Specifically, the program according to this embodiment is a program that causes the computer to execute each of the steps described later using Figures 7, 11, etc.

[0058] Furthermore, the method of this embodiment can be applied to a control method for an information processing system. In this control method, the information processing system acquires first data, which includes sleep information about a patient's sleep, from equipment related to patient care, transforms the first data into second data in a data format compliant with IHE (Integrating the Healthcare Enterprise), which includes sleep information in the field values ​​of the OBX (Observation Result) segment in HL7 (Health Level Seven) used in IHE, and manages the second data.

[0059] 2. IHE Standards and Sleep Information First, I will briefly explain IHE, and then I will describe a method for sharing sleep information between devices in a format that conforms to IHE.

[0060] As mentioned above, IHE promotes the interoperability of medical information systems, and in the PCD (Patient Care Development) domain, it standardizes communication and management between medical devices and medical information systems that provide patient care. IHE defines and standardizes communication between devices as an integrated profile. For example, DEC (Device Enterprise Communication) is a well-known profile in the PCD domain. DEC is a basic profile for interoperability between devices.

[0061] A profile defines actors and transactions between actors. In DEC, actors include a DOR (Device Observation Reporter) that outputs test results and a DOC (Device Observation Consumer) that acquires the output of the DOR. When DEC is applied to data sharing between the converter unit 11 and the manager unit 12, the converter unit 11 becomes the DOR and the manager unit 12 becomes the DOC. Components that function as a DOR may include, for example, the infusion pump 53 and the vital signs monitoring system 52 in Figure 1. Components that function as a DOC may include, for example, the electronic medical record system 51 in Figure 1.

[0062] In DEC, a transaction between DOR and DOC is defined, for example, PCD-01. Transactions are expressed using messages defined in HL7, for example. For example, in a transaction called PCD-01, an ORU message of HL7 may be sent.

[0063] Furthermore, HL7 messages are identified by their message code, trigger event, and message structure. For example, a message with message code ORU, trigger event R01, and message structure ORU_R01 is represented as "ORU^R01^ORU_R01". HL7 messages consist of multiple segments, each containing one or more field values.

[0064] Figure 3 shows an example of the structure of the ORU^R01^ORU_R01 message, which is part of the ORU message. MSH, SFT, PID, etc., shown in Figure 3 are segments included in the ORU^R01^ORU_R01 message. Also, in Figure 3, segments enclosed in [] can be omitted. Segments enclosed in {} can be repeated two or more times. Since the ORU^R01^ORU_R01 message is publicly known, only a brief explanation of some of its segments follows.

[0065] MSH is a segment that represents the message header. The field values ​​of the MSH segment may include the message type, which includes information that identifies the type of message, such as the message code, trigger event, and message structure. Thus, a component that receives the message can determine what trigger sent the message and what structure the message has.

[0066] A PID is a segment used to identify a patient. A PID includes field values ​​such as patient ID, patient name, date of birth, and gender.

[0067] An OBR is a segment used to send orders such as inspections. An OBR includes field values ​​such as an ID that identifies the order, priority, order date and time, and inspection start / end date and time.

[0068] OBX is a segment for transmitting test results. OBX contains field values ​​such as test items, test result values, and abnormality flags. Test items include, for example, an ID representing the test item, text representing the test item name, and a coding scheme. The coding scheme here may be the MDC (Medical Device Communications) code specified in ISO / IEEE 11073-10101. Since MDC is publicly known, a detailed explanation is omitted.

[0069] Figure 4 shows a specific example of an inspection item included in the field value of the OBX segment. For example, in the method of this embodiment, information on respiration and heart rate can be obtained using a detection device 810, etc. Therefore, for example, between devices included in the information processing system 10, data is transmitted and received in which an ID, text, and coding scheme indicating the respiratory rate are stored as field values ​​of the inspection item in the OBX segment, and the actually measured respiratory rate is stored as a field value of the inspection result. In MDC, ID=20490 is assigned as the ID indicating the respiratory rate. The text indicating the respiratory rate is MDC_RESP_RATE, and the coding scheme is MDC as described above. Therefore, as shown in Figure 4, the inspection item representing the respiratory rate (respiratory status) is expressed as "20490^MDC_RESP_RATE^MDC".

[0070] Furthermore, the "Panic Upper Limit" and "Warning Upper Limit" items for respiration indicate the detection of an abnormality where the respiratory rate is excessively high. In particular, "Panic Upper Limit" indicates a higher degree of abnormality than "Warning Upper Limit." For example, considering two thresholds where the first upper limit threshold is less than the second upper limit threshold, "Panic Upper Limit" indicates whether the respiratory rate value exceeds the second upper limit threshold, while "Warning Upper Limit" indicates whether the respiratory rate value exceeds the first upper limit threshold. Test items that indicate the test value has exceeded the upper limit threshold are expressed as "196648^MDC_MDC_EVT_HI^MDC".

[0071] Similarly, "Warning - Lower Limit" and "Panic - Lower Limit" are items that indicate the detection of an abnormality where the respiratory rate is excessively low. In particular, "Panic - Lower Limit" indicates a higher degree of abnormality than "Warning - Lower Limit". For example, considering two thresholds where the first lower limit threshold > the second lower limit threshold, "Panic - Lower Limit" indicates whether the respiratory rate value fell below the second lower limit threshold, and "Warning - Lower Limit" indicates whether the respiratory rate value fell below the first lower limit threshold. A test item that indicates the test value has exceeded the lower limit threshold is expressed as "196670^MDC_MDC_EVT_LO^MDC".

[0072] Similarly, it is possible to send and receive information regarding heart rate, such as "Status (heart rate)," "Panic - Upper Limit," "Warning - Upper Limit," "Warning - Lower Limit," and "Panic - Lower Limit."

[0073] On the other hand, sleep information and bed information are not defined in the MDC. Therefore, the converter unit 11 may extend the MDC to include sleep information and bed information as inspection items for the OBX segment.

[0074] For example, the sleep information may include information representing the sleep status. Here, status may include information indicating whether or not the user is asleep, or information indicating the depth of sleep. The sleep information may also include information regarding the user's movements on the electronic bed 31. For example, the sleep information may include information such as "out of bed" indicating whether or not the user is out of bed on the electronic bed 31, "sitting up" indicating whether or not the user is sitting up on the electronic bed 31, and "awake" indicating whether or not the user is awake on the electronic bed 31. This information is detected using the bed 100, which includes the detection device 810 and load sensors described above.

[0075] The converter unit 11 assigns an ID, text, and coding scheme to each of these items to represent the test item. Specifically, the converter unit 11 may use the same MDC as for respiration and heart rate as the coding scheme, and then assign text that includes MDCX to indicate that the MDC has been extended. In the example in Figure 4, the text "MDCX_SLEEP" is assigned to the sleep status. The converter unit 11 also performs a process to assign a value that does not overlap with existing items as the ID to represent the test item. In the example in Figure 4, ID=0 is assigned, but other values ​​may be used as the ID. As a result, the converter unit 11 can assign the value "0^MDCX_SLEEP^MDC" to represent the test item for the sleep status. Similar to the examples of respiration and heart rate described above, this is information in a format that matches the field value of the OBX segment, so it becomes possible to send and receive the sleep status in an IHE-compliant format using a message that includes the OBX segment.

[0076] Furthermore, the converter unit 11 may assign the following information to the test items representing getting out of bed, getting up, and waking up, respectively: "0^MDCX_EVT_LEAVE_FROM_BED^MDC", "0^MDCX_EVT_GET_UP_ON_BED^MDC", and "0^MDCX_EVT_WAKE_UP_ON_BED^MDC". This makes it possible to send and receive various sleep information in a format compliant with IHE.

[0077] The bed information may also include information such as "status" indicating whether the electronic bed 31 is normal or abnormal, "operation button" indicating the operating status of the operation interface, "low-floor display" indicating whether the bottom height is low-floor or not, "back angle" indicating the value of the back angle, "knee angle" indicating the value of the knee angle, "height" indicating the value of the bottom height, and "tilt angle" indicating the value of the bottom tilt angle. This information is output from the controller (control box) of the electronic bed 31. The bottom height and angle information may also be determined based on the captured image from the imaging device 700.

[0078] The converter unit 11 assigns an ID, text, and coding scheme representing the inspection item to each piece of information included in the bed information. The coding scheme is MDC, the text includes MDCX to indicate that it is an extension of MDC, and the ID is a value such as 0 that does not overlap with existing items, which is the same as in the example of sleep information. For example, the converter unit 11 assigns "0^MDCX_BED_STATUS^MDC" as the inspection item representing the bed status. As other bed information is as shown in Figure 4, a detailed explanation is omitted. According to the method of this embodiment, it becomes possible to send and receive bed information in a format compliant with IHE.

[0079] The converter unit 11 may also transmit air mattress information regarding the air mattress 32 in a format compliant with IHE. The specific method is the same as for sleep information and bed information. The air mattress information may include information such as "status" indicating whether the air mattress 32 is normal or abnormal, and "pressure" indicating the pressure value detected by the load sensor included in the air mattress 32. The converter unit 11 may assign "0^MDCX_AIRMAT_STATUS^MDC" as an inspection item representing the status of the air mattress 32, and "0^MDCX_AIRMAT_PRESSURE^MDC" as an inspection item representing the pressure. According to the method of this embodiment, it becomes possible to send and receive air mattress information in a format compliant with IHE.

[0080] Furthermore, the above describes DEC as an example of an integrated profile for IHE. However, integrated profiles are not limited to this. For example, ACM (Alarm Communication Management) is known as an integrated profile for the PCD area of ​​IHE. In the method of this embodiment, communication may be performed in accordance with ACM. Specifically, the converter unit 11 according to this embodiment may output a message including sleep information, etc., to the manager unit 12 using the transaction of at least one of the ACM and DEC profiles in HL7. As described above, DEC is a profile that supports basic communication between devices.

[0081] ACM is a profile that manages alarm-related communications between devices. The actors in ACM include an AR (Alert Reporter) that outputs alarms, an AM (Alarm Manager) that manages alarms, an AC (Alarm Communicator) that transmits alarms, and an AA (Alarm Archiver) that manages history, etc. When ACM is applied to data sharing between the converter unit 11 and the manager unit 12, the converter unit 11 becomes the AR and the manager unit 12 becomes the AC. Components that realize the AR may also include, for example, an infusion pump 53 and a vital signs monitoring system 52.

[0082] For example, the converter unit 11 outputs the second data under normal conditions using communication in accordance with DEC, and outputs the second data when an anomaly is detected using communication in accordance with ACM. In this way, it becomes possible to output the second data using an appropriate profile according to the characteristics of the second data.

[0083] For example, as shown in Figure 4, the status (respiratory rate, heart rate) for respiration and heart rate is information that is acquired even in a normal state, so it is subject to output using DEC. In DEC, as mentioned above, ORU^R01^ORU_R01 may be used as the message. On the other hand, "Panic - Upper Limit", "Warning - Upper Limit", "Warning - Lower Limit", and "Panic - Lower Limit" correspond to abnormal states that exceed a given upper limit threshold or abnormal states that fall below a lower limit threshold. Therefore, the converter unit 11 outputs information regarding these inspection items using ACM. In ACM, ORU^R40^ORU_R40, which is an ORU message with a different message type than ORU^R01^ORU_R01, may be used.

[0084] Furthermore, the converter unit 11 may output the status of sleep information using DEC and transmit information on getting out of bed, sitting up, and waking up using ACM. Since getting out of bed, sitting up, and waking up represent information indicating when the patient starts moving, outputting this information using ACM makes it possible to suppress falls and other accidents around the electronic bed 31.

[0085] Furthermore, the converter unit 11 may output bed information such as status, operation buttons, low-floor indicator, back angle, knee angle, and height inclination angle using DEC, and may also output the status using ACM. As can be seen from this example, a given inspection item may be subject to both DEC output and ACM output.

[0086] Furthermore, the converter unit 11 may output status and pressure for air mattress information using DEC, and may also output status using ACM.

[0087] Next, Figures 5A-6B will be used to explain specific examples of the configuration of OBX segments included in ORU messages. Figures 5A-5C show examples of OBX segment configurations in ORU^R01^ORU_R01, which is used in DEC profiles, for example.

[0088] As shown in Figures 5A-5C, the OBX segment includes the set ID, result value type, test item, test sub-ID, result value, unit, standard value, abnormal flag, test result status, test date and time, and equipment stage item. Since the OBX segment itself is publicly known, the following will explain the field values ​​for the test item, test sub-ID, result value, unit, and abnormal flag related to sleep information, and will omit explanations for other items.

[0089] As described above, the ORU^R01^ORU_R01 message transmits respiratory and heart rate status, sleep status, bed information, and air mattress information as test items. Therefore, the candidate values ​​for the third field of the OXB field include values ​​consisting of IDs, text, and coding schemes corresponding to this information. Note that Figure 5A shows an example in which information corresponding to getting out of bed, sitting up, and waking up from sleep information is transmitted, unlike the example in Figure 4. Thus, the classification of DEC and ACM in Figure 4 is just one example, and various variations are possible in which profile each test item is transmitted in.

[0090] As shown in Figure 5A, the bed information may also include items such as side rails, brake locks, and side rail locks. Side rails indicate whether or not side rails are installed. Brake locks indicate the state of the brakes that lock the casters of the electronic bed 31. Side rail locks indicate the state of the locks that secure the side rails to the bed body.

[0091] As shown in Figure 5A, the field value of the inspection sub-ID of the OBX segment may include identification information to specify detailed items of the inspection item. For example, the side rails can be attached to both the left and right sides, and their attachment positions can be changed between the head and foot sides. Therefore, when specifying the attachment status of the side rails, the inspection sub-ID may include information to specify which side rail is being targeted: the right side of the head, the left side of the head, the right side of the foot, or the left side of the foot.

[0092] Similarly, the air mattress 32 may include multiple systems, such as a first system for controlling the height of a first region and a second system for controlling the height of a second region. In this case, the inspection sub-ID may include information that identifies a specific system.

[0093] As shown in Figure 5B, the field values ​​of the OBX segment result values ​​are defined for each test item. For example, the result values ​​corresponding to the respiratory and heart rate status are the measured values ​​of respiratory rate and heart rate.

[0094] Furthermore, regarding sleep information, the result value may be information (e.g., flag information) indicating whether or not the user is in the state of getting out of bed, sitting up, awake, or asleep. Also, the sleep result value may be a value indicating one of three or more stages of sleep depth.

[0095] Among the bed information, the status result value indicates that the bed is normal or is a fail code indicating the nature of the abnormality. The operation button result value indicates that no button was pressed or identifies the button that was pressed. The low-floor display result value indicates whether the bed is at a normal height or low-floor. The back angle, waist angle, height, and incline value result values ​​are the respective measured values. The side rail result value indicates the mounting status. The brake lock and side rail lock result values ​​indicate whether the bed is locked or unlocked.

[0096] In the air mattress information, the status result value indicates whether the mattress is functioning normally or is a fail code indicating the nature of the abnormality. The pressure result value is a measurement taken by a load sensor.

[0097] As shown in Figure 5C, the unit field value of the OBX segment indicates the unit of the test result value. For example, the unit of the respiratory status (respiratory rate) is rpm. The value representing rpm is defined in MDC, for example, "264928^MDC_DIM_RESP_PER_MIN^MDC". Similarly, the unit of the heart rate status (heart rate) is bpm, and is expressed using the same definition as in MDC.

[0098] Furthermore, since sleep information does not represent specific measured values, units are unnecessary.

[0099] Regarding the bed information status, operation buttons, low-floor indicator, side rails, brake locks, and side rail locks, units are unnecessary because the inspection results do not represent specific measured values.

[0100] The units for bed information such as back angle, knee angle, and incline angle are, for example, radians (rad). Since the units for bed back angle, etc., are not defined in MDC, MDC may be extended in the same way as the examination items. For example, the converter unit 11 may use "********^MDCX_DIM_BED_BACK_ANGLE_CURRENT^MDC", which is a combination of ID, text, and coding scheme, as the field value representing the unit of back angle. Although the value of ID is not specifically determined here, a value that does not overlap with existing IDs will be set, as in the example above. The converter unit 11 also expresses the units for knee angle and incline angle in the same way using a combination of ID, text, and coding scheme. Height is also the same as back angle, etc., except that the unit is millimeters (mm).

[0101] Furthermore, since the status of the air mattress information does not represent specific measured values, units are unnecessary. Pressure, for example, is expressed in kilopascals (kPa) and is represented by the combination of ID, text, and coding scheme "*****^MDCX_DIM_AIRMAT_PRESSURE_CURRENT^MDC".

[0102] As shown in Figure 5C, the field value of the abnormal flag in the OBX segment indicates whether an abnormal flag has been set for the test item. For example, in the example shown in Figure 5C, four flags are set as abnormal flags for respiration: "Panic Upper Limit," "Warning Upper Limit," "Warning Lower Limit," and "Panic Lower Limit." These abnormal flags are as described above. In specific values, "H" indicates that the value exceeds the upper limit of the standard range, and "HH" indicates that the value exceeds the panic upper limit. As mentioned above, the panic upper limit has a larger value than the upper limit of the standard range. Similarly, "L" indicates that the value is below the lower limit of the standard range, and "LL" indicates that the value is below the panic lower limit. The same applies to the abnormal flags for heart rate.

[0103] Furthermore, as shown in Figure 5C, sleep information may also be set as abnormality flags for getting out of bed, sitting up, and waking up. In the specific values, "A" represents an abnormality that is different from a numerical value.

[0104] Figures 6A and 6B show examples of OBX segment configurations in ORU^R40^ORU_R40, which is used, for example, in ACM profiles.

[0105] As shown in Figures 6A and 6B, the OBX segment includes the set ID, result value type, test item, test sub-ID, result value, abnormal flag, test result status, and test date and time. Since the OBX segment itself is publicly known, the following will explain the field values ​​of the test item, test sub-ID, result value, and abnormal flag that are related to sleep information, and will omit explanations of other items.

[0106] As described above, the ORU^R40^ORU_R40 message transmits the following test items: "Panic Upper Limit," "Warning Upper Limit," "Warning Lower Limit," and "Panic Lower Limit" for respiration and heart rate, as well as sleep information such as getting out of bed, sitting up, and waking up. Therefore, the candidate values ​​for the third field of the OXB field include values ​​consisting of IDs, text, and coding schemes corresponding to this information. Note that in Figure 6A, unlike the example in Figure 4, the status of the bed information and the status of the air mattress information are omitted.

[0107] Furthermore, it is not necessary to use sub-IDs to specify each of the above inspection items. Therefore, in the example shown in Figure 6A, the field value of the inspection sub-ID for the OBX segment may be omitted.

[0108] As shown in Figure 6A, the field values ​​of the OBX segment result values ​​are defined for each test item. For example, the result values ​​corresponding to the panic upper limit, warning upper limit, warning lower limit, and panic lower limit for respiration and heart rate are information (alarm information, flag information) indicating whether the corresponding state is occurring or not. For sleep information, the result values ​​indicate whether the patient is awake, alert, or asleep.

[0109] As shown in Figure 6B, the field value of the abnormal flag for the OBX segment is the same as in the example described above using Figure 5C, so a detailed explanation is omitted.

[0110] As described above, in this embodiment, by extending MDC, it becomes possible to handle sleep information, bed information, and air mattress information in a format compliant with IHE and HL7.

[0111] In the above, DEC and ACM were used as examples of IHE profiles, but the profiles used in this embodiment are not limited to these. For example, at least one of the converter unit 11 and the manager unit 12 may transmit and / or receive second data using information such as MEMLS (Medical Equipment Management Location Services) and MEMDMC (Medical Equipment Management Data Management Communication). IHE also defines various integrated profiles, and these integrated profiles may be used in this embodiment. For example, the converter unit 11 may be a device linked to a location. In this case, the converter unit 11 can output information about the location where the converter unit 11 is located to the manager unit 12 by using the MEMLS profile. For example, the converter unit 11 may be a device on which locations are registered based on the operation of a staff member's mobile terminal device 43. Alternatively, the converter unit 11 may acquire location information by performing communication such as Bluetooth.

[0112] 3. Manager Operation Next, we will explain the operation of the manager unit 12. Specifically, we will explain the process of distributing messages to their destinations and the process of activating messages.

[0113] 3.1 Message sorting Figure 7 is a sequence diagram illustrating the message distribution process among the processes of the manager unit 12 according to this embodiment. The measuring device in Figure 7 is, for example, the peripheral device 41 in Figure 2. However, the measuring device may be any of the following: patient RFID 21, patient beacon 22, staff RFID 23, staff beacon 24, electronic bed 31, air mattress 32, medical device 42, mobile terminal device 43, or infusion pump 53. The first system is, for example, an electronic medical record system 51, a vital signs monitoring system 52, or BMAS / BCMA 54. The second system is a different system from the first system among the electronic medical record system 51, vital signs monitoring system 52, and BMAS / BCMA 54.

[0114] In step S101, the manager unit 12 obtains a forward table. The forward table is data that associates the conditions for the second data with the destination to which the second data will be sent if those conditions are met. For example, the storage 13 stores the forward table, and the manager unit 12 reads the forward table from the storage 13.

[0115] Figure 8 shows an example of a forward table. The forward table may include information on the conditions for the second data, the destination, and the priority. In Figure 8, the data type is used as an example of the conditions for the second data, but other conditions may be used. For example, in Figure 8, if the condition that the second data includes sleep information is met, BMAS / BCMA54 is determined as the destination. The priority for sending sleep information to BMAS / BCMA54 is then set to "low". Naturally, the forward table is not limited to one record, and may contain multiple records. Also, if multiple converter units 11 send data to one manager unit 12, a forward table may be provided for each converter unit 11.

[0116] In step S102, the measuring device acquires the first data. In step S103, the measuring device transmits the first data to the converter unit 11. For example, if the measuring device is the detection device 810 in Figure 2, the detection device 810 acquires respiration, heart rate, and sleep information and outputs this information to the converter unit 11. The data format here may not be in a format compliant with IHE.

[0117] In step S104, the converter unit 11 performs a process to convert the acquired first data into second data in an IHE-compliant format. Specifically, as described above, the converter unit 11 identifies the integrated profile and message according to the content of the first data and stores field values ​​in each segment of the message. As described above, the converter unit 11 may store values ​​according to MDC or extended values ​​of MDC in the field values ​​of the inspection items in the OBX segment, and may also store values ​​based on the first data (measured values, etc.) in the field values ​​of the result value. The converter unit 11 may also perform a process to store field values ​​in accordance with the content of the first data for the inspection sub-ID, unit, and abnormal flag, as described above.

[0118] In step S105, the converter unit 11 sends the second data, an HL7 message, to the manager unit 12. As described above, the converter unit 11 may send an ORU^R01^ORU_R01 message according to the DEC profile, or an ORU^R40^ORU_R40 message according to the ACM profile. The converter unit 11 may also send messages of different message types according to other profiles.

[0119] In step S106, the manager unit 12 determines whether the received second data satisfies a given condition. For example, the manager unit 12 determines the type of data based on the field value of the inspection item of the OBX segment included in the second data, and determines whether the type of data matches any record in the forward table. As described above, if a forward table is provided for each converter unit 11, the manager unit 12 may identify the forward table to be used for processing from among the multiple forward tables by identifying the device that sent the second data.

[0120] If the second data satisfies the conditions, in step S107, the manager unit 12 identifies the destination of the second data based on the forward table. In the example of the forward table in Figure 8, if the second data includes sleep information, the manager unit 12 identifies BMAS / BCMA54 as the destination of the second data.

[0121] The manager unit 12 outputs the second data. For example, suppose that the converter unit 11 has specified the first system as the destination for the second data, and in the process of step 107, a second system different from the first system is identified as the destination. In this case, the manager unit 12 sends the second data to the first system and the second system in steps S108 and S109.

[0122] Furthermore, if the second data does not meet the conditions, the process of identifying the destination based on the forward table is omitted. In this case, in step S110, the manager unit 12 sends the second data to the first system, which is the destination specified by the converter unit 11.

[0123] As described above, the manager unit 12 acquires mapping data that associates conditions related to the second data with the output destination when the conditions are met (step S101), identifies the output destination associated with the first condition in the mapping data when the second data satisfies the first condition (step S107), and may output the second data to the identified output destination and the destination specified by the converter unit (steps S107, S108). The mapping data here is specifically a forward table, but the data format is not limited to this. In this way, the manager unit 12 can flexibly distribute the second data according to the content of the second data it has acquired.

[0124] For example, when the manager unit 12 obtains second data destined for the electronic medical record system 51 from the converter unit 11, it may output the second data to the electronic medical record system 51 or to any other system. In this way, if there is a system that requires specific data, that system can directly obtain the data without querying the electronic medical record system 51. Therefore, compared to the case where all data is first aggregated in the electronic medical record system 51, it becomes possible to share data more efficiently.

[0125] As illustrated in the forward table of Figure 8, if the second data includes sleep information, the manager unit 12 may output the second data to the setting system for setting the parameters of the infusion pump 53, even if the setting system is not included in the destination specified by the converter unit 11. Specifically, the setting system here is BMAS / BCMA 54.

[0126] Figure 9 is a diagram illustrating the flow of the distribution process based on the forward table in Figure 8. In this case, sleep information is acquired in step S11 of Figure 9. Specifically, the detection device 810, which is a peripheral device 41, detects the sleep information and outputs it to the converter unit 11. The converter unit 11 converts the sleep information into a format compliant with IHE and outputs it to the manager unit 12 using a DEC profile. For example, from the viewpoint of managing sleep information in association with patients, the converter unit 11 may specify the electronic medical record system 51 as the destination representing the destination to which the sleep information is sent.

[0127] In step S12, the manager unit 12 performs data distribution processing based on the acquired data and the forward table. Specifically, the manager unit 12 determines the data type by referring to the forward table. Since the sleep information matches the record in the forward table shown in Figure 8, the manager unit 12 identifies BMAS / BCMA 54 as the destination. Therefore, the manager unit 12 adds BMAS / BCMA 54 as a destination in addition to the electronic medical record system 51 originally specified to the converter unit 11. Based on the destination after the additional processing, the manager unit 12 outputs the sleep information to the electronic medical record system 51 and BMAS / BCMA 54.

[0128] In this way, for example, when sleep information is used in the control of the infusion pump 53, it becomes possible to efficiently implement such control. For example, the BMAS / BCMA 54 may perform control that automatically switches the flow rate supplied by the infusion pump 53 between sleep and non-sleep states. Specifically, the BMAS / BCMA 54 may administer infusion only when the patient is sleeping and stop the infusion when the patient is awake. According to the method of this embodiment, the BMAS / BCMA 54 can acquire sleep information without going through the electronic medical record system 51, so the above control can be implemented efficiently. For example, when a state change occurs between a sleep state and an awake state, it becomes possible to quickly reflect that change in the control of the infusion pump 53.

[0129] Furthermore, the forward table described above may contain data that can be edited by the user. In this case, the user is, for example, a staff member such as a nurse. For example, as shown in Figure 9, the mobile terminal device 43 (terminal device 600 in Figure 2) may perform the process of updating the forward table by communicating with the manager unit 12.

[0130] Figures 10A and 10B show examples of display screens used when updating the forward table. The screens shown in Figures 10A and 10B are displayed, for example, on the display unit of a mobile terminal device 43.

[0131] Figure 10A is a screen for selecting the target converter unit 11. As described above, a forward table may be provided for each converter unit 11. In this case, the processor of the mobile terminal device 43 identifies the forward table to be updated by receiving the selection operation of the converter unit 11 on the screen shown in Figure 10A. The mobile terminal device 43 transmits the identification result to the manager unit 12.

[0132] In the example shown in Figure 10A, four converter units 11 are exemplified as converter units 11 that communicate with the manager unit 12. The display unit of the portable terminal device 43 may display the name of the converter unit 11, as shown in "IHE converter 101-1" in Figure 10A. Alternatively, the display unit of the portable terminal device 43 may display the location where the converter unit 11 is located, as shown in "Room 102" in Figure 10A. The display unit of the portable terminal device 43 may display information that identifies the electronic bed 31 corresponding to the converter unit 11, as shown in "Bed name: 1372" in Figure 10A. The display unit of the portable terminal device 43 may display the name of the patient corresponding to the converter unit 11, as shown in "Patient name: AAAA" in Figure 10A. Furthermore, for a single converter unit 11, displays for multiple items such as the device name, location, bed, and patient may be performed in parallel. For example, in Figure 10A, "Bed name: 1372" and "Patient name: AAAA" may represent the same converter unit 11.

[0133] In a medical system, since one bed is assumed to be used by one patient, it is useful to manage data measured around the bed in association with one patient. From this perspective, the converter unit 11 of this embodiment may be provided in association with the electronic bed 31, or it may be provided in association with the patient using the electronic bed 31. In this case, as shown in Figure 10A, by displaying the converter unit 11 in association with the electronic bed 31 or the patient, it becomes possible to support selection by staff such as nurses. For example, a nurse receives instructions from a doctor that patient AAAA is a candidate for intravenous fluid administration, and that this fluid administration should be performed during sleep. In this case, the nurse determines that the desired control can be achieved by providing patient AAAA's sleep information to the BMAS / BCMA 54, and performs the task of updating the forward table. For a nurse, it is considered relatively easy to identify a patient or the electronic bed 31 used by that patient compared to identifying the name of the converter unit 11. The information that identifies the electronic bed 31, or the patient information that identifies the patient, is stored in a memory (not shown) of the converter unit 11. As mentioned above, the converter unit 11 is a device linked to a location, and information representing the location where the converter unit 11 is placed may be stored in memory (not shown). The display unit of the mobile terminal device 43 displays the bed name, patient name, and placement location (e.g., room number) corresponding to the converter unit 11 when information about the electronic bed 31, patient information, and location information is acquired. If none of this information is acquired, the display unit of the mobile terminal device 43 displays the device name (device ID) of the converter unit 11. In addition, devices such as the manager unit 12 and the electronic medical record system 51 may store information representing the correspondence between the converter unit 11 and the electronic bed 31, the correspondence between the converter unit 11 and the patient, and the correspondence between the converter unit 11 and the location.

[0134] Figure 10B is an example of a screen displayed when one of the converter units 11 is selected in Figure 10A. The screen shown in Figure 10B displays information identifying the converter unit 11 and the forward table associated with that converter unit 11. Here, in Figure 10A, "Bed name: 1372" and "Patient name: AAAA" represent the same converter unit 11, and this example illustrates the case when the user selects one of them.

[0135] In Figure 10B, when the "Edit" operation shown at the right end of the record is performed, the display unit of the mobile terminal device 43 displays a screen (not shown) for inputting modifications to the data type, destination, and priority of the existing record. This screen may be a separate screen from Figure 10B, or it may be a pop-up screen superimposed on Figure 10B. When the "Add Record" operation is performed, the display unit of the mobile terminal device 43 displays a screen (not shown) for inputting the data type, destination, and priority of the new record. After editing an existing record and / or adding a new record, when the "Update Table" operation is performed, the mobile terminal device 43 sends an update instruction to the manager unit 12 for the forward table. The manager unit 12 updates the forward table based on the update instruction and stores the updated forward table in the storage 13.

[0136] According to the method of this embodiment, the user can flexibly change the data distribution rules set by the manager unit 12. While the above describes an example where the forward table is set by communicating with the manager unit 12 using the mobile terminal device 43, the method is not limited to this. For example, a memory (not shown) of the converter unit 11 may hold a forward table corresponding to the converter unit 11, and the manager unit 12 may perform data distribution by obtaining the forward table from the converter unit 11. In this case, the mobile terminal device 43 may set the forward table of the converter unit 11 by communicating with the converter unit 11. Furthermore, if multiple converter units 11 can communicate, the mobile terminal device 43 may set the forward table of the second converter unit 11 via the first converter unit 11. In this case, the first converter unit 11 functions as a device that instructs the second converter unit 11 to set the forward table.

[0137] 3.2 Activating Messages As described above, in HL7, a message is identified by its message code, trigger event, and message structure. The device receiving the message can determine, based on the message code and trigger event, what trigger caused the transmission and what characteristics the message has.

[0138] In this embodiment, when the manager unit 12 acquires first data from the converter unit 11 using a first message, which is one of the messages in HL7, it may output second data to one or more systems using a second message, which is a message in HL7 but different from the first message.

[0139] In other words, the manager unit 12 is not limited to transferring the second data obtained from the converter unit 11 using the same message as when it was received, but may also output the second data using a message triggered by some kind of event. In other words, when the manager unit 12 receives the second data, it may activate a message different from the message used when it was received. As described above, if the message is different, the system that receives the message will determine that the event that triggered the message or the meaning of the message is different. Therefore, by switching messages according to the situation, it becomes possible to appropriately change the operation of the system that receives the message. As a result, it becomes possible to operate the entire medical system efficiently based on the processing of the manager unit 12. This will be explained in detail below.

[0140] Figure 11 is a sequence diagram illustrating the message activation process. In step S201, the manager unit 12 obtains the activation table. The activation table is data that associates the conditions of the second data with the messages that are activated when those conditions are met. For example, storage 13 stores the activation table, and the manager unit 12 reads the activation table from storage 13.

[0141] Figure 12 shows an example of an activation table. The activation table may include information that identifies the conditions for the second data and the type of message. In Figure 12, the conditions for the second data are shown to be the type of data and the converter that is the source of the data, but other conditions may be used. For example, in Figure 12, the ADT^A01 message is activated when the condition that the patient information and bed information, which are the second data, are received from the same converter is met. Also, as shown in Figure 12, the activation table may contain multiple records. Furthermore, when multiple converter units 11 send data to one manager unit 12, the activation table may be common to the multiple converter units 11, or it may be provided for each converter unit 11.

[0142] In step S202, the measuring device acquires the first data. In step S203, the measuring device transmits the first data to the converter unit 11. The processing in steps S202-S203 is similar to, for example, steps S102-S103 in Figure 7.

[0143] In step S204, the converter unit 11 performs a process to convert the acquired first data into second data in an IHE-compliant format. Specifically, as described above, the converter unit 11 identifies the integration profile and message according to the content of the first data and stores field values ​​in each segment of the message. In step S205, the converter unit 11 sends the HL7 message, which is the second data, to the manager unit 12. This message is referred to as the first message. The first message may be the ORU^R01^ORU_R01 message or the ORU^R40^ORU_R40 message described above. The integration profile may also be MEMLS or MEMDMC, and the first message may be another message used in the transaction of that profile.

[0144] In step S206, the manager unit 12 determines whether the received second data satisfies a given condition. For example, the manager unit 12 determines the type of data based on the field value of the inspection item in the OBX segment of the second data, and also identifies the converter unit 11 which is the source of the second data. The manager unit 12 then determines whether the data type and source match the conditions included in any record of the activate table.

[0145] If the second data satisfies the conditions, in step S207, the manager unit 12 identifies the message to activate based on the activate table. Hereinafter, the activated message will be referred to as the second message. If it is the first row record of the forward table in Figure 12, the manager unit 12 activates the message whose message code is ADT and whose trigger event is A01.

[0146] In step S208, the manager unit 12 outputs the second data using the second message. The output destination here may be, for example, the first system designated as the destination of the second data by the converter unit 11. In other words, the converter unit 11 does not need to change the destination. However, the processing in this embodiment is not limited to this. For example, by combining the distribution processing described above using Figures 7-10B, the manager unit 12 may output the second data to a second system different from the first system using the second message. Furthermore, there is no preclude the activate table from containing destination data. An embodiment involving destination distribution will be described later using Figure 14.

[0147] In this way, the manager unit 12 acquires second mapping data that associates conditions related to the second data with the type of second message when the conditions are met (step S201). If the second data satisfies the second condition, the manager unit 12 identifies the second message associated with the second condition in the second mapping data (step S207) and outputs the second data to one or more systems using the second message (step S208). In this way, the manager unit 12 can determine whether a specific trigger event has occurred based on the second data, and if it determines that a trigger event has occurred, it can notify the destination system of the trigger event using the corresponding message. As a result, the system that receives the second message can perform appropriate actions according to the trigger. Specific examples will be described later using Figures 13-15. Note that the second mapping data here is strictly an activate table, but data in a different format from table data may be used. Also, the second mapping data (activate table) may be updateable by users such as nurses, similar to the forward table. For example, records in the activate table can be updated and added using a device such as a mobile terminal 43. The interface in this case may be the same as the screens shown in Figures 10A and 10B, for example. This makes it possible to flexibly set the message to be activated and the activation conditions (the second condition mentioned above).

[0148] Furthermore, if the second data does not satisfy the second condition, in step S209, the manager unit 12 outputs the second data to one or more systems using the first message. In this way, it becomes possible to appropriately switch the HL7 message depending on whether the condition is met or not.

[0149] Next, the processing flow corresponding to each record in the Activate Table shown in Figure 12 will be explained in detail. For example, if the Manager Unit 12 obtains a first message containing patient information from a first device via the Converter Unit 11, and also obtains a first message containing bed information from the electronic bed 31 via the same Converter Unit 11, it outputs an ADT message containing patient information and bed information as a second message. The first device here is, for example, a patient RFID 21, but other devices capable of obtaining patient information may be used. The ADT message is a message related to the patient's admission, discharge, and transfer as defined in HL7.

[0150] In this embodiment, the method allows notification to the receiving system that an event such as hospitalization has occurred by outputting an ADT message. As a result, it becomes possible to have the system perform appropriate processing related to the patient's hospitalization.

[0151] Figure 13 is a diagram illustrating the process flow for activating an ADT message, and shows the process flow for the first row record of the activation table shown in Figure 12. As shown in step S21 of Figure 13, the manager unit 21 acquires bed information. Specifically, the electronic bed 31 acquires the various bed information described above using Figure 4 and outputs the bed information to the converter unit 11. The converter unit 11 transmits the bed information to the manager unit 12 as second data in the format compliant with IHE. The integration profile used for data transmission from the converter unit 11 to the manager unit 12 may be DEC or ACM, as described above. Furthermore, considering the case where the electronic bed 31 is located at a specific location and the bed information includes location information representing that location, MEMLS may be used as the integration profile. In this case, the converter unit 11 corresponds to the LOR (Location Object Repository), which is an actor of MEMLS. The manager unit 12 corresponds to the LOC (Location Consumer), which is an actor of MEMLS.

[0152] As shown in step S22, the manager unit 12 acquires patient information. Specifically, the patient RFID 21 acquires patient information and outputs it to the converter unit 11. The patient information here may include patient attributes such as the patient's name, age, gender, height, weight, medical history, and medication history. The patient information may also include location information representing the patient's location. As described above, the location information can be obtained from the reading result of the patient RFID 21. The converter unit 11 transmits the patient information to the manager unit 12 using a profile such as DEC, ACM, or MEMLS.

[0153] Note that the bed information acquisition process shown in step S21 and the patient information acquisition process shown in step S22 do not need to be executed in this order, and the timing of their execution is arbitrary. The manager unit 12 may also acquire information different from either patient information or bed information from other devices via the converter unit 11. When data is received from the converter unit 11, in step S23, the manager unit 12 determines whether the conditions of the activate table are met based on the received information. For example, consider the case where both the processes in steps S21 and S22 are executed, and the manager unit 21 acquires patient information and bed information from the same converter unit 11. This could be the case where bed information has already been acquired, and then the process in step S22 is executed to acquire patient information, or the case where patient information has already been acquired, and then the process in step S21 is executed to acquire bed information. As described above, if we consider the case where the converter unit 11 is provided on a bed-by-bed or patient-by-patient basis, it can be seen that the patient identified by the patient information here is highly likely to be the patient using the electronic bed 31 identified by the bed information. Immediately after a patient is admitted to the hospital, or immediately after a patient is transferred to another department or ward within the hospital, the correspondence between the patient and the electronic bed 31 may not be finalized. Therefore, it is useful to register the correspondence between the patient and the electronic bed 31 based on the patient information and bed information described above.

[0154] Therefore, as shown in Figure 12, the manager unit 12 may activate a message regarding patient registration on the condition that it has received patient information and bed information from the same converter unit 11. The message here is the HL7 ADT message described above. The following are examples of trigger events related to the ADT message. Note that the following are examples of trigger events, and trigger events not listed below may also be used. A01: Notification of hospital admission / visit A02: Department / Building Transfer A03: Discharge / End of Hospital Stay A04: Patient Registration A05: Patient pre-registration A06: Change outpatient to inpatient A07: Change inpatient to outpatient A08: Updating patient information

[0155] For example, the manager unit 12 activates the ADT^A01 message, which has the message code ADT and the trigger event A01, as the second message. In this way, it becomes possible to prompt the system that receives the second message to execute the registration process that links patient information and bed information.

[0156] For example, if it is determined in step S23 that the conditions of the activate table are met, in step S24, the manager unit 12 stores patient information in the PID segment of the ADT^A01 message and bed information in the accompanying information PV1 and PV2. The manager unit 12 then sends the ADT^A01 message to the electronic medical record system 51. In this way, the electronic medical record system 51, upon receiving the message, can understand that a patient has been admitted, and can register the patient information and bed information in association.

[0157] Furthermore, if the linking of patient information and bed information has already been completed, there is little benefit in registering the same linking again. Therefore, as shown in the activation table in Figure 12, the manager unit 12 may use the condition that, in addition to obtaining patient information and bed information from the same converter unit 11, a patient has not been linked to the electronic bed 31. For example, in step S23, the manager unit 12 may determine whether a patient has been linked to the electronic bed 31 based on the past communication history stored in the storage 13. For example, it is thought that the linking of patient information and bed information is performed using ADT messages as described above. Therefore, the manager unit 12 may determine whether a patient has been linked to the electronic bed 31 by searching for ADT messages that include the patient ID of the target patient in the PID segment. Alternatively, as described above, it is thought that the electronic medical record system 51 stores the correspondence between patients and electronic beds 31. Therefore, the manager unit 12 may determine whether a patient has been linked to the electronic bed 31 by querying the electronic medical record system 51.

[0158] The above example showed an ADT message triggered by A01. However, as mentioned above, various trigger events are defined, so messages containing other trigger events may also be activated.

[0159] For example, if the manager unit 12 has previously sent and received an ADT^A05 message regarding the patient in question, it can determine that the patient's pre-registration is complete. In this situation, if the manager unit 12 receives patient information and bed information from the same converter unit 11, it can infer that the patient, who was pre-registered as an outpatient, has changed to an inpatient and is now using a specific electronic bed 31. In this case, the manager unit 12 may activate an ADT^A06 message as a second message, indicating that the outpatient has been changed to an inpatient. Thus, the records included in the activate table are not limited to the example shown in Figure 12, and various variations are possible.

[0160] On the other hand, if the conditions in the activate table are not met in step S23 of Figure 13, the manager unit 12 may forward the received data as is in step S24. For example, if the manager unit 12 receives patient information from the converter unit 11 via a MEMLS profile message but does not receive bed information from the same converter unit 11, it sends the patient information to the electronic medical record system 51 via a MEMLS profile message, the same as when it was received. Similarly, if the manager unit 12 receives bed information from the converter unit 11 via a MEMLS profile message but does not receive patient information from the same converter unit 11, it sends the bed information to the electronic medical record system 51 via a MEMLS profile message, the same as when it was received. Furthermore, if the manager unit 12 receives information that is different from both patient information and bed information using a given message, it may send that information to the electronic medical record system 51 using the same message as when it was received. In addition, if the manager unit 12 receives information from the converter unit 11 but the conditions included in the activate table are not met, it may send that information to a given system (in a narrow sense, the electronic medical record system 51) via the same message as when it was received.

[0161] Furthermore, if the manager unit 12 obtains a first message containing patient information from the first device via the converter unit 11, and also obtains a first message containing pump information from the infusion pump 53 via the same converter unit 11, it may output an OMP message containing an order for medication using the infusion pump 53 as a second message. The first device here is, for example, a patient RFID 21, but other devices capable of obtaining patient information may be used. The OMP message is a message concerning an order for medication / treatment as defined in HL7.

[0162] In this embodiment, by outputting an OMP message, the receiving system can be notified that an event has occurred requiring a prescription or treatment order for a patient. As a result, it becomes possible to prompt appropriate action from prescribing physicians and pharmacists, as well as nurses and other personnel who manage the actual medication administration.

[0163] Figure 14 is a diagram illustrating the process flow for activating an OMP message, and shows the process flow for the second row record of the activation table shown in Figure 12. In step S31 of Figure 14, the manager unit 12 acquires pump information. Specifically, the infusion pump 53 outputs pump information, including position information representing the location of the infusion pump 53, to the converter unit 11. The converter unit 11 transmits the pump information to the manager unit 12 as second data in a format compliant with IHE. The integrated profile used for data transmission from the converter unit 11 to the manager unit 12 may be DEC, ACM, or MEMLS.

[0164] In step S32, the manager unit 12 acquires patient information. Specifically, the patient RFID 21 acquires patient information and outputs it to the converter unit 11. The converter unit 11 transmits the patient information to the manager unit 12 using profiles such as DEC, ACM, and MEMLS.

[0165] In step S33, the manager unit 12 determines whether the conditions in the activate table are met based on the received information. In this example, patient information and pump information are obtained from the same converter unit 11. Therefore, it is highly probable that the patient identified by the patient information is the patient who uses the infusion pump 53 identified by the pump information.

[0166] Furthermore, in step S33, the manager unit 12 determines whether an order for medication / treatment has been placed for the target patient. More specifically, the manager unit 12 may determine whether an order has been placed for the target patient requiring an infusion pump 53. This determination may be made based on message history such as OMP messages stored in storage 13, or by querying the electronic medical record system 51. If an order has been placed, it is presumed that the infusion pump 53 identified by the pump information can be used to fulfill the order. Although not explained here, the manager unit 12 may also activate an OSQ message to query the electronic medical record system 51. An example of activating an OSQ message will be described later using Figure 15.

[0167] If the manager unit 12 determines in step S33 that the conditions in the activate table are met, then in step S34, it activates the message corresponding to those conditions. Specifically, if the manager unit 12 determines that the above-mentioned conditions are met, it activates the OMP^O09 message identified in the activate table. O09 is a trigger event indicating a drug / treatment order. For example, the manager unit 12 outputs the OMP^O09 message to the electronic medical record system 51 and BMAS / BCMA 54. Here, BMAS / BCMA 54 may be a destination added by the manager unit 12 through a distribution process. Also, as shown in Figure 12, the manager unit 12 may perform a process to change the message structure according to the user attributes of the target device / system.

[0168] The electronic medical record system 51 registers an order based on the OMP^O09 message. The electronic medical record system 51 may also output information to the corresponding system instructing it to execute the order, if necessary.

[0169] Furthermore, if an OMP^O09 message is sent to the BMAS / BCMA 54 in step S34, in step S35, the BMAS / BCMA 54 controls the infusion pump 53 based on the OMP^O09 message. For example, the OMP^O09 message may include information about specific drugs or flow rate per unit time. Also in step S35, the BMAS / BCMA 54 outputs information to the infusion pump 53 to set parameters determined based on the OMP^O09 message. Note that communication between the BMAS / BCMA 54 and the infusion pump 53 may be performed based on a PIV (Point-of-Care infusion Verification) profile. In this case, the BMAS / BCMA 54 corresponds to the IOP (Infusion Order Programmer), which is an actor in the PIV profile, and the infusion pump 53 corresponds to the IOC (Infusion Order Consumer).

[0170] On the other hand, if it is determined in step S33 that the conditions in the activate table are not met, the manager unit 12 may forward the received data as is in step S34. This is the same as in the example in Figure 13. For example, if the manager unit 12 receives patient information from the converter unit 11 via a MEMLS profile message but has not received pump information from the same converter unit 11, it sends the patient information to the electronic medical record system 51 via a MEMLS profile message, the same as when it was received. Similarly, if the manager unit 12 receives pump information from the converter unit 11 via a MEMLS profile message but has not received patient information from the same converter unit 11, it sends the pump information to the electronic medical record system 51 via a MEMLS profile message, the same as when it was received. In addition, if the manager unit 12 receives information from the converter unit 11 but the conditions included in the activate table are not met, it may send the information to a given system (in a narrow sense, the electronic medical record system 51) via a MEMLS profile message, the same as when it was received.

[0171] The manager unit 12 may also obtain a first message containing patient sleep information from the first device via the converter unit 11, and if it determines that the patient has transitioned from a sleep state to a wakeful state based on the sleep information, it may output an OSQ message as a second message to inquire about an order regarding the patient's prescription. The first device here is, for example, the detection device 810, but other devices capable of acquiring sleep information may be used. The OSQ message is a message regarding an order inquiry as defined in HL7.

[0172] Alternatively, the manager unit 12 may obtain a first message containing the patient's vital information (specifically, body temperature information) from the first device via the converter unit 11, and if it determines that the patient has a fever based on the vital information, it may output an OSQ message as a second message to confirm the order regarding the patient's prescription. The first device here is, for example, a measuring device 820, but other devices capable of acquiring vital information may be used.

[0173] In this embodiment, the status of prescription orders for patients can be checked against the electronic medical record system 51, etc., by outputting OSQ messages. As a result, medication instructions can be executed smoothly. For example, instructions for medication administration that are conditional on the patient being awake, or medication administration that is conditional on the detection of fever, can be executed smoothly. As will be described in detail later, these instructions may be output to the BMAS / BCMA 54 or to a portable terminal device 43 used by a nurse.

[0174] Figure 15 is a diagram illustrating the process flow for activating an OSQ message, and shows the process flow for the records in rows 3-4 of the activation table shown in Figure 12. In step S41 of Figure 15, the manager unit 12 acquires sleep information. Specifically, the detection device 810 outputs sleep information for a given patient to the converter unit 11. The converter unit 11 transmits the sleep information to the manager unit 12 as second data in a format compliant with IHE. The integrated profile used for data transmission from the converter unit 11 to the manager unit 12 is, for example, DEC, but other profiles may be used. Also, although Figure 15 shows that peripheral device 41 outputs sleep information, the device that outputs sleep information may be a medical device 42.

[0175] In step S42, the manager unit 12 determines whether the conditions in the activate table are met based on the received information. For example, if the manager unit 12 has acquired sleep information, it determines whether the patient has transitioned from a sleep state to an awake state based on that sleep information. Furthermore, in step S42, if the target patient is a registered patient, the manager unit 12 determines whether an order for treatment for that patient has been reserved (see the record in the third row of Figure 12). Order reservations are made using HL7 RDE messages. Therefore, the manager unit 12 determines whether an RDE message for the target patient is stored in the storage 13.

[0176] If no RDE message for the patient in question is stored in storage 13, the manager unit 12 needs to query the electronic medical record system 51 to determine whether a prescription order for that patient is reserved. Therefore, if the manager unit 12 determines that the above conditions are met, it activates the OSQ^Q06 message identified in the activate table. The OSQ^Q06 message is a message related to the inquiry of order information. For example, the manager unit 12 outputs the OSQ^Q06 message to the electronic medical record system 51.

[0177] The electronic medical record system 51 responds to inquiries via OSQ^Q06 messages with a message indicating the order reservation status of the patient in question. This message is, for example, an OSR message.

[0178] If the manager unit 12 determines that an order reservation has been made based on the response from the electronic medical record system 51, it instructs the reservation to be carried out. Specifically, if the reserved order is for medication administered by injection, in step S44A, the manager unit 12 sends a message to the BMAS / BCMA 54 instructing it to carry out the reservation. Based on the receipt of this message, in step S45A, the BMAS / BCMA 54 outputs an RGV message to the infusion pump 53. The RGV message is a message indicating that the reservation has been carried out. The RGV message here may be, for example, an RGV^O15 message. If the reserved order is for medication administered by means other than injection, in step S44B, the manager unit 12 sends a message to the portable terminal device 43 used by the nurse instructing it to carry out the reservation. Based on this message, the nurse, for example, manages the administration of oral medication.

[0179] Furthermore, in the condition determination in step S42, if the patient's RDE message is stored in storage 13, the query to the electronic medical record system 51 can be omitted. Therefore, the manager unit 12 omits the processing in step S43 and executes the processing shown in step S44A or S44B depending on the medication content. Also, if the query to the electronic medical record system 51 reveals that no order reservation has been made for the target patient, the processing shown in steps S44A, S44B, and S45A is omitted.

[0180] Furthermore, if it is determined in step S42 that the conditions of the activate table are not met, the manager unit 12 may transfer the received data as is in step S43. For example, if sleep information is obtained but it is determined that the patient has not transitioned from a sleep state to a wakeful state, the manager unit 12 may transfer the sleep information received from the converter unit 11 to the electronic medical record system 51 using the same message as when it was received.

[0181] Furthermore, as shown in step S41 of Figure 15, the manager unit 12 may acquire vital information. Specifically, the measuring device 810 outputs vital information of a given patient to the converter unit 11. The converter unit 11 transmits the vital information to the manager unit 12 as second data in a format compliant with IHE. The integrated profile used for data transmission from the converter unit 11 to the manager unit 12 is, for example, ACM, but other profiles may be used.

[0182] In this case as well, the processing flow is the same, except that the content of the conditional judgment based on the activation table is different. Specifically, the manager unit 12 activates the OSQ^Q06 message when a fever is detected based on vital information and the RDE for the patient corresponding to the storage 13 is not stored, and uses this message to inquire about order reservations with the electronic medical record system 51 (steps S42, S43). Based on the inquiry result, the manager unit 12 switches between instructing the BMAS / BCMA 54 to make a reservation (step S44A) or instructing the mobile terminal device 43 to make a reservation (step S44A). The processing in step S43 can be omitted if the RDE is stored in the storage 13, and the processing in steps S44A, S44B, and S45A can be omitted if it is determined based on the inquiry result that an order reservation has not been made.

[0183] 4. Other System Configuration Examples The above does not limit the specific placement of the manager unit 12; for example, the manager unit 12 may be included in a second device independent of other devices / systems. The second device may be a PC or server, as described above. However, the method of this embodiment is not limited to this, and the manager unit 12 may be included in any of the above devices / systems. Furthermore, multiple manager units 12 may be provided. For example, it is possible to manage data around the electronic bed 31 with a manager unit 12 provided in the electronic bed 31, while managing data related to other medical devices and medical systems with a manager unit 12 provided in the electronic medical record system 51. The following describes specific variations of the system configuration.

[0184] Figure 16 is a diagram illustrating the system configuration around the electronic bed 31. For example, the electronic bed 31 may include a control box. Here, the control box includes, for example, a processor and memory, and controls the height and angle of the bottom. As shown in Figure 16, the manager unit 12 according to this embodiment may be included in the control box. For example, the processor that performs the bottom adjustment may correspond to the manager unit 12. Alternatively, the control box may include a second processor different from the processor for bottom adjustment, and this second processor may correspond to the manager unit 12. The storage 13 may also be included in the control box. Similarly, the storage 13 may be implemented by the memory for bottom adjustment, or by a second memory different from that memory.

[0185] The electronic bed 31 is connected to a patient RFID 21, a staff RFID 23, an air mattress 32, peripheral devices 41, and medical devices 42. The air mattress 32, peripheral devices 41, and medical devices 42 may operate according to the control of the peripheral device management system 55. In Figure 16, CNT indicates the control signal used by the peripheral device management system 55 to control each device. Although the converter unit 11 is omitted in Figure 16, the converter unit 11 may be provided for each device, or only one may be provided for each electronic bed 31, or an intermediate number may be provided.

[0186] Figure 16 shows which actor of IHE each device / system operates as. For example, patient RFID 21 and staff RFID 23 operate as LOR. Air mattress 32, peripheral device 41, and medical device 42 operate as DOR, LOR, or DMIR.

[0187] The manager unit 12 of the electronic bed 31 operates as DOC, LOC, and DMIC, communicating with DOR, LOR, and DMIR respectively.

[0188] Furthermore, the electronic bed 31 may communicate with systems other than the bed-related systems, such as the electronic medical record system 51. In this case, the manager unit 12 of the electronic bed 31 operates as DOR, LOR, DMIR, or AR. The manager unit 12 may also operate as AC.

[0189] As shown in Figure 16, the mobile terminal device 43 may also include a manager unit 12. For example, the mobile terminal device 43 includes a processor and memory. The processor corresponds to the manager unit 12. The memory of the mobile terminal device 43 may also correspond to the storage 13.

[0190] The portable terminal device 43 may communicate with, for example, a medical device 42. For example, if a measuring device 820 such as a thermometer is used as the medical device 42 as shown in Figure 2, the measurement results of the measuring device 820 used around the electronic bed 31 may be collected on the nurse's portable terminal device 43 (terminal device 600).

[0191] In this case, the medical device 42 may operate as DOR, LOR, or DMIR. The manager unit 12 of the portable terminal device 43 operates as DOC, LOC, and DMIC, communicating with DOR, LOR, and DMIR respectively. The portable terminal device 43 may also communicate with systems such as the electronic medical record system 51, similar to the electronic bed 31. In that case, the manager unit 12 of the portable terminal device 43 operates as DOR, LOR, DMIR, and AR. Furthermore, as shown in Figure 16, communication may occur between the electronic bed 31 and the portable terminal device 43.

[0192] Figure 17 shows an example of a system configuration including an electronic medical record system 51. In Figure 17, the electronic bed 31, air mattress 32, mobile terminal device 43, other devices 44, and peripheral device management system 55 shown at the bottom correspond to the bed-side system shown in Figure 16. Note that the other devices 44 may be peripheral devices 41, medical devices 42, or other devices placed around the electronic bed 31.

[0193] The system shown in Figure 17 includes, in addition to the system around the electronic bed 31, an electronic medical record system 51, a vital signs monitoring system 52, an infusion pump 53, a BMAS / BCMA 54, and a ventilator / anesthesia system 56. The ventilator / anesthesia system 56 is a system that manages the patient's respiratory and anesthesia during surgery and other procedures.

[0194] The electronic medical record system 51 may also include a manager unit 12 and storage 13. For example, the electronic medical record system 51 is implemented by a server system including a processor and memory, as shown in the electronic medical record server 400 in Figure 2. The processor corresponds to the manager unit 12, and the memory corresponds to the storage 13.

[0195] As described above, among the systems surrounding the electronic bed 31, the electronic bed 31 and the portable terminal device 43 communicate with the electronic medical record system 51. The integrated profiles used for this communication include ADM, DEC, MEMLS, MEMDMC, etc. Although not required, communication between the air mattress 32 and the electronic medical record system 51, and communication between other devices 44 and the electronic medical record system 51 may also be possible.

[0196] The electronic medical record system 51 may also communicate with the infusion pump 53. The integrated profile used for this communication is ACM or DEC. As mentioned above, the BMAS / BCMA 54 may also control the parameters of the infusion pump 53 by communicating with the infusion pump 53. The integrated profile used for communication between the BMAS / BCMA 54 and the infusion pump 53 is PIV.

[0197] The electronic medical record system 51 may also communicate with the ventilator / anesthesia system 56. The integrated profile used for this communication is ACM, DEC, or WCM (Waveform Content Module). WCM is an integrated profile used for managing waveform data. The ventilator / anesthesia system 56 may also communicate with the vital signs monitoring system 52. The integrated profile used for this communication is ACM, DEC, or WCM.

[0198] The system shown in Figures 16-17 can also perform the processing according to the embodiment described above. Specifically, the converter unit 11 (not shown) is extended to handle sleep information, etc., and the manager unit 12 performs destination sorting and message activation processing. The manager unit 12 here may be the manager unit 12 included in the electronic bed 31, the manager unit 12 included in the mobile terminal device 43, the manager unit 12 included in the electronic medical record system 51, or a combination of two or more of these.

[0199] Figure 18 is a diagram illustrating the processing flow when the manager unit 12 performs distribution processing in the system shown in Figure 17. The manager unit 12 included in the electronic medical record system 51 will be described below.

[0200] For example, if BMAS / BCMA54 performs a setting to administer intravenous fluids while the patient is sleeping, as shown in step S51 of Figure 18, BMAS / BCMA54 sends a request to the manager unit 12 to transfer sleep information of patient X1. For example, BMAS / BCMA54 may identify the target patient and the required data type based on user operation. Alternatively, BMAS / BCMA54 may identify the target patient and the required data type based on IHE,HL7 compliant messages such as OMP messages.

[0201] Upon receiving the transfer request, in step S52, the manager unit 12 updates the forward table. Specifically, the manager unit 12 adds a record to the forward table where the condition value is "Receive sleep information for patient X1" and the destination value is "BMAS / BCMA".

[0202] Figure 19 shows a specific example of the updated forward table. For example, the forward table may include fields for patient ID, data type, destination, and priority to identify the target patient. In the example above, a record is created where the patient ID value is "Patient X1", the data type value is "Sleep Information", and the destination value is "BMAS / BCMA". In the example in Figure 19, the priority is set to "low". Also, as shown in Figure 19, the forward table may include information to identify the trigger device. In this case, the trigger is the receipt of sleep information by the manager unit 12, so the value is set to "Manager".

[0203] Let's return to Figure 18 and continue the explanation. In step S53 of Figure 18, the electronic bed 31 transmits the patient's sleep information to the electronic medical record system 51. Here, the electronic bed 31 shown is associated with patient X1, and the sleep information transmitted to the electronic medical record system 51 is the information of patient X1. The sleep information output by the electronic bed 31 may be data acquired by the electronic bed 31 having a load sensor, or it may be data received from peripheral devices 41 such as a detection device 810 via the converter unit 11.

[0204] In step S54, the manager unit 12 registers the sleep information of patient X1, acquired from the electronic bed 31 in step S53, into the electronic medical record system 51. In step S55, it determines whether the conditions of the forward table are met based on the acquired information, and performs data distribution based on the determination result. If the processes in steps S51 and S53 have been performed, the received data is the sleep information of patient X1, so the manager unit 12 determines that the conditions of the record in the forward table shown in Figure 19 are met and identifies BMAS / BCMA 54 as the destination. The manager unit 12 then transfers the sleep information of patient X1 to BMAS / BCMA 54. The profile in this case is, for example, DEC. Through the above process, BMAS / BCMA 54 can acquire the requested sleep information of patient X1 without actively querying it, making it possible to efficiently control the infusion pump 53 according to the sleep state of patient X1. Note that in step S55, if it is determined that the acquired information does not meet the conditions of the forward table, data distribution is not performed. For example, the manager unit 12 only registers data to the electronic medical record system 51 as shown in step S54, and does not perform data transfer.

[0205] Although details of the message activation process are omitted here, those skilled in the art will understand that it can be implemented in the system shown in Figures 16-17 using the same flow as described above, based on Figures 11-15.

[0206] Furthermore, in the system shown in Figure 17, the electronic medical record system 51 (manager unit 12) may also perform automatic control of devices such as the electronic bed 31. For example, the electronic medical record system 51 acquires vital information from peripheral devices 41 or medical devices 42. Here, vital information refers to information such as heart rate and respiration. The electronic medical record system 51 can use various profiles such as DEC, ACM, MEMLS, and MEMDMC as profiles for acquiring vital information. Based on the vital information, the electronic medical record system 51 performs automatic control of the peripheral devices 41.

[0207] For example, when performing cardiopulmonary resuscitation (CPR), the electronic bed 31 and air mattress 32 need to be flattened. The electronic bed 31 may be equipped with an operating interface (such as a CPR button) to transition it to a state suitable for CPR, but when there is no time to spare, automatic control offers significant advantages. Similarly, the air mattress 32 can also transition to a state suitable for CPR by accepting specific user input, but automatic control eliminates the need for such user input, which is advantageous.

[0208] Therefore, the electronic medical record system 51 may acquire vital information and, if the vital information is an abnormal value that meets predetermined conditions, output a message to the peripheral devices 41 instructing them to perform automatic control. For example, the manager unit 12 included in the electronic medical record system 51 acquires heart rate information as vital information for a given patient, and if the heart rate is below a given threshold, outputs a message in accordance with ACM to the electronic bed 31 and air mattress 32 corresponding to the patient. For example, the electronic medical record system 51 may use the condition that the heart rate is at the "panic lower limit" as described above using Figures 4-5C.

[0209] When the electronic bed 31 receives a message from the electronic medical record system 51 in accordance with ACM, it performs automatic control based on that message. Specifically, if the message in accordance with ACM concerns the heart rate and the heart rate is in a "panic lower limit" state, the electronic bed 31 performs control to change the bottom angle and height to values ​​appropriate for CPR.

[0210] Similarly, when the air mattress 32 receives a message from the electronic medical record system 51 in accordance with ACM, it performs automatic control based on that message. Specifically, if the message in accordance with ACM concerns heart rate and the heart rate is in a "panic lower limit" state, the air mattress 32 performs control to change the amount of air to a state suitable for CPR.

[0211] The automatic control described above may be implemented, for example, using at least one of the message distribution and activation described above. For example, the manager unit 12 of the electronic medical record system 51 may distribute the vital information to the electronic bed 31 and air mattress 32 even if the destination specified by the source of the vital information does not include the electronic bed 31 and air mattress 32. In this case, the conditions included in the forward table are that the data type is vital information and the value is a given abnormal value. The destination associated with these conditions is the electronic bed 31 and air mattress 32 used by the patient corresponding to the vital information. The vital information here may also be information related to respiration. Furthermore, if the electronic medical record system 51 receives an abnormality in vital information using a message other than those used in ACM, it may perform a message activation process according to the ACM profile.

[0212] The above describes an example of automatically controlling the electronic bed 31 and air mattress 32 based on abnormal vital signs, but the execution conditions for automatic control and the equipment to be controlled can be modified in various ways.

[0213] Although this embodiment has been described in detail above, it will be readily apparent to those skilled in the art that many modifications are possible without substantially departing from the novel aspects and effects of this embodiment. Therefore, all such modifications are included within the scope of this disclosure. For example, any term that appears at least once in the specification or drawings together with a broader or synonymous term may be replaced with that different term anywhere in the specification or drawings. Furthermore, all combinations of this embodiment and its modifications are also included within the scope of this disclosure. In addition, the configuration and operation of the information processing system, converter unit, manager unit, etc., are not limited to those described in this embodiment, and various modifications are possible. [Explanation of Symbols]

[0214] 10... Information processing system, 11... Converter unit, 12... Manager unit, 13... Storage, 21... Patient RFID, 22... Patient beacon, 23... Staff RFID, 24... Staff beacon, 31... Electronic bed, 32... Air mattress, 41... Peripheral equipment, 42... Medical equipment, 43... Mobile terminal device, 44... Other equipment, 51... Electronic medical record system (EMR), 52... Biometric information monitoring system M, 53...Infusion pump, 54...BMAS / BCMA, 55...Peripheral device management system, 56...Artificial respiration / anesthesia system, 100...Bed, 170...Mattress, 200...Bedside terminal device, 300...Server system, 400...Electronic medical record server, 500...Station terminal device, 600...Terminal device, 700...Imaging device, 810...Detection device, 820...Measurement device, 830...Authentication card, 840...IC tag

Claims

1. A converter unit that acquires first data including sleep information about the patient from equipment related to patient care, and outputs second data in a data format according to IHE (Integrating the Healthcare Enterprise), in which the first data is transformed into a data format according to IHE, in which the field value of the OBX (Observation Result) segment in HL7 (Health Level Seven) used in IHE includes the sleep information. A manager unit that acquires the second data from the converter unit and manages the second data, An information processing system that includes this.

2. In the information processing system described in claim 1, The aforementioned manager unit, An information processing system that outputs the second data to one or more systems, including an electronic medical record system.

3. In the information processing system described in claim 2, The aforementioned manager unit, An information processing system that, when it obtains the second data destined for the electronic medical record system from the converter unit, outputs the second data to the electronic medical record system and to any system other than the electronic medical record system.

4. In the information processing system described in claim 2, The aforementioned manager unit, Obtain correspondence data that associates the conditions related to the second data with the output destination when the conditions are met. If the second data satisfies the first condition, the corresponding output destination is identified in the corresponding data. An information processing system that outputs the second data to the identified output destination and the destination specified by the converter unit, respectively, among the multiple systems mentioned above.

5. In the information processing system described in claim 2, The aforementioned manager unit, If the second data includes the sleep information, an information processing system that outputs the second data to the setting system even if the destination specified by the converter does not include a setting system for setting parameters of an infusion pump.

6. In the information processing system described in claim 2, The aforementioned manager unit, An information processing system that, when it obtains the second data from the converter unit using the first message which is one of the messages in HL7, outputs the second data to one or more systems using the second message which is a message in HL7 and is different from the first message.

7. In the information processing system described in claim 6, The aforementioned manager unit, A second correspondence data is obtained that associates the conditions relating to the second data with the type of second message when the conditions are met. An information processing system that, when the second data satisfies the second condition, identifies the second message associated with the second condition in the second correspondence data, and outputs the second data to one or more systems using the second message.

8. In the information processing system described in claim 7, The aforementioned manager unit, An information processing system that, if the second data does not satisfy the second condition, outputs the second data to one or more systems using the first message.

9. In the information processing system described in claim 7, The aforementioned manager unit, An information processing system that, when it obtains the first message containing patient information relating to the patient from a first device via the converter unit, and obtains the first message containing bed information relating to the electronic bed from an electronic bed via the same converter unit, outputs an ADT message containing the patient information and the bed information as the second message.

10. In the information processing system described in claim 7, The aforementioned manager unit, An information processing system that, when it obtains a first message containing patient information relating to the patient from a first device via the converter unit, and obtains a first message containing pump information relating to the infusion pump from an infusion pump via the same converter unit, outputs an OMP message containing an order for medication administration using the infusion pump as the second message.

11. In the information processing system according to any one of claims 1 to 10, The converter section is An information processing system that outputs a message containing the sleep information to the manager unit using transactions from at least one of the ACM (Alarm Communication Management) and DEC (Device Enterprise Communication) profiles in the IHE.

12. Information processing system, First data, including sleep information about the patient's sleep, is acquired from equipment related to patient care, and the first data is transformed into second data in a data format according to IHE (Integrating the Healthcare Enterprise), in which the sleep information is included in the field values ​​of the Observation Result (OBX) segment in HL7 (Health Level Seven) used in IHE (Integrating the Healthcare Enterprise). The management of the second data mentioned above is performed by Control method.

Images