KR102043678B1 - Personal Medical Device Information Model System Using CoAP-based FHIR Resources - Google Patents

Abstract

The present invention relates to a personal medical device information model system using a CoApp-based fire resource, as an IEEE 11073 DIM (Domain Information Model) -based device agent, and exchanges measured biometric information with a healthcare sensor device and measures measured biometrics. It supports protocol conversion between IEEE 11073 DIM and FHIR for transmitting information, and provides FHIR message based on CoAP based to support low power / wideband technology, and collects IEEE 11073 DIM data from the device. It is an IEEE 11073 / FHIR gateway that generates FHIR resources, maps IEEE 11073 DIM data to FHIR resource content, and is a FHIR protocol stack mounted as a healthcare server. It supports CoAP and HTTP-based FHIR message processing. A Fire (FHIR) server that manages devices and communicates with the IEEE 11073 / FHIR gateway, the pi And a communication with the server, and the hospital notified the information on the information from the device information to the server system.

Description

Personal Medical Device Information Model System Using CoAP-based FHIR Resources}

The present invention relates to a personal medical device information model system using a Coapp-based Fire resource, and more particularly, to select a CoAP (CoAP) as a transmission protocol to implement IEEE protocol (IEEE 11073 DIM) communication, Integrated architecture of Fire (FHIR) and IEEE Protocol (IEEE 11073 DIM) using CoAP (CoAP) by monitoring personal health information to address low battery life issues of limited devices (such as PHD or smartphones) due to data traffic This paper relates to a personal medical device information model system that designs and implements a web application but uses a co-app-based fire resource.

Recently, with the development of the Internet of Things (IoT), it has been applied to various fields of our lives. As it is applied to various fields such as healthcare, smart home, and smart city, it brings us convenience and is undergoing many changes. Among them, the rapid development of the Internet of Things technology in the field of healthcare has produced a variety of services using this technology to emerge a new concept of IoT healthcare. The Internet of Things refers to physical networks such as electronics, software, sensors, and connected vehicles or buildings, which are connected to the network to allow these objects to collect and exchange data. Implementation of the IoT requires a variety of protocols and domain applications (see Platform Standards for the Internet of Things, see Sand Hill, January 2015, U. Muligan and R. Brennan, “The Platform Standard for the Internet of Things” Sand Hill). , Jan, 2015).

In today's world, it is important for more and more people to care for and maintain their own health, and the Internet of Things is becoming an important field for good health care. As a result, more and more personal health devices are produced by many manufacturers. Most of these devices, however, provide interoperability by measuring signals using each manufacturer's own application or by exchanging and sharing measured data using their own transport protocol. This is one of the major issues affecting healthcare services. In order to solve these problems of interoperability, compatibility and reliability, many researchers have proposed unified international standards.

One of the most important standards in terms of PHD is the IEEE 11073 PHD standard, which addresses PHD interoperability issues. The IEEE 11073 PHD standard supports three areas of agent devices: disease management, health and fitness, and independent living, making it widely applicable to oxygen saturation meters, blood pressure monitors, and drug monitors. The IEEE 11073 PHD family of standards is based on a single "framework" standard and "device specialization" standard. Called IEEE 11073-20601, this framework standard defines common data types, message types, and communication models to support device specialization. Device specialization standards only define data models for certain types of personal health devices, such as IEEE 11073-10404 (blood pressure monitors). This particular personal healthcare device encodes measurement parameters using an IEEE 11073-20601 optimized exchange protocol transmitted over existing transmission technologies such as Bluetooth or Zigbee.

IEEE 11073 PHD modeling includes a domain information model (DIM), a service model (SM), and a communication model (CM). DIM describes healthcare devices and physiological data, and SM defines interactions with healthcare devices and data. The CM manages the link state system and communication characteristics. IEEE 1107 P defines two roles, an agent and a manager. An agent is a node that collects personal healthcare data and transmits it to a related manager. A manager is a node that receives data from one or more agent systems.

From the perspective of healthcare providers, there is a set of international standards called the HL7 standard for the transfer of clinical and management data between software applications used by various healthcare providers. The HL7 standard establishes the language, structure, and data format required for smooth communication between systems and defines how to communicate between parties. The HL7 standard supports the management, delivery and evaluation of clinical practice and health services and is the most commonly used in the world.

In the past, the HL7 CDA, a clinical data exchange model based on HL7 v2.x and v3 and HL7 v3, the interoperability specification for healthcare data communication and exchange, was widely used. In recent years, Fast Health Interoperable Resources (FHIR) have emerged to improve the interoperability of clinical data, and APIs to describe data formats and elements (resources) and to exchange electronic healthcare records with standards. Programming Interface). FHIR builds on the previous data format standards of HL7 and combines the advantages of HL7 v2, HL7 v3, and CDA by leveraging the latest web standards and focusing on their feasibility. FHIR uses the latest web-based API technologies, including HTTP-based RESTful protocols, HTML and Cascading Style Sheets for user interface integration, JSON or XML for data representation, and Atom for results. FHIR makes it easy to provide healthcare data to healthcare service providers and users across devices, including computers, tablet PCs, and smartphones, and provides applications that third-party application developers can easily integrate into existing systems. can do.

It is easy to see that the IEEE 11073 PHD is independent of the transport layer. Most PHDs are resource constrained devices with limited battery, limited processing and storage capabilities, requiring low energy consumption protocols. As a response to this need, the IETF CoRE Working Group designed the CoAP (Constrained Application Protocol) protocol for Machine-to-Machine (M2M) applications.

CoAP is a special web transport protocol for use in limited nodes and limited networks of the Internet of Things. In addition, based on the REST model, users can easily observe the resource directory that contains the smart device.

[Preceding technical literature]

Korea Patent Registration No. 10-1623389 (May 17, 2016)

The present invention selects CoAP as a transport protocol to implement IEEE protocol (IEEE 11073 DIM) communication, and also solves the problem of low battery life of limited devices (such as PHD or smartphone) due to high data traffic. By monitoring personal health information, we design and implement an integrated architecture of Fire (FHIR) and IEEE Protocol (IEEE 11073 DIM) using CoAP, and provide a personal medical device information model system using CoApp-based Fire resources. Its purpose is.

According to a preferred embodiment of the present invention for achieving the above object,
As an IEEE 11073 DIM (Domain Information Model) based agent, a device for exchanging measured biometric information with a healthcare sensor device and transmitting measured biometric information,
It supports protocol conversion between IEEE 11073 DIM and FHIR and provides additional FHIR messages based on CoAP to support low power / wideband technology.
An IEEE 11073 / FHIR gateway that collects IEEE 11073 DIM data from the device, maps IEEE 11073 DIM data to FHIR resource content, and generates FHIR resources;
A FHIR protocol stack mounted as a healthcare server that supports CoAP and HTTP-based FHIR message processing, manages personal healthcare information and devices, and communicates with the IEEE 11073 / FHIR gateway (FHIR) server, and
A hospital information system server in communication with the fire server and notified of information about information from a device,
The IEEE 11073 / FHIR gateway maps the IEEE 11073 DIM-based biometric information collected and analyzed to the device to a FHIR specification-based resource standard model and delivers the information to the FHIR server, but collects the IEEE 11073 DIM data from the healthcare sensor device agent. A FHIR resource content mapper for mapping IEEE 11073 DIM data to FHIR resource content and generating FHIR resources;
A FHIR resource sender providing a FHIR header and a body generation function for communication through a mapped resource delivered from the FHIR resource content mapper,
The FHIR resource content mapper includes an IEEE 11073 data collector for collecting IEEE 11073 data, an FHIR structure analyzer for analyzing the collected data structure, and an FHIR resource generator for generating resources. Including,
The FHIR resource sender includes a FHIR header generator for generating a header, a FHIR body generator for generating a body, and a FHIR validator checker for checking the generated data. A personal medical device information model system is provided that uses the underlying fire resources.
Preferably, the device collects and analyzes the biometric information measured by the healthcare device in the IEEE 11073 DIM specification-based data standard model, and forwards it to the IEEE 11073 / FHIR gateway,
A DIM analyzer (Analyzer) that analyzes the IEEE 11073 DIM data model for exchanging biometric information between the healthcare sensor device agent and the healthcare sensor device and constructs a data model for the requested biometric information; ,
A service message generator that composes a message required for data exchange between the healthcare sensor device agent and the healthcare sensor device or parses the received message, and which corresponds to the service model defined by IEEE 11073;
And an IEEE 11073 Transport Manager that communicates between the healthcare sensor device agent and the healthcare sensor device or supports communication between the healthcare sensor device agent and the gateway.
According to another aspect of the present invention, a coapp-based fire resource including a device, a gateway connected to the device to process data, a Fire (FHIR) server connected to the gateway to process data, and a hospital information system In the device measurement data upload method of a personal medical device information model system to be used,
The device creates an observation resource to the IEEE 11073 / FHIR gateway,
The IEEE 11073 / FHIR gateway creates an observation resource corresponding to the FHIR server to the FHIR server and uploads measurement data from the FHIR.
The hospital information system (HIS) uses the CoAP to obtain a list of FHIR resources, initiates a GET request to the FHIR server, and registers for FHIR resources (Patient, Device Component, DeviceMetric and Obsevation).
When the device uploads an Obsrvation Resource request to the IEEE 11073 / FHIR gateway and uploads the measured data, it also uploads the device status information defined in the FHIR specification. It can indicate the current operating status of the device (ON / OFF, etc.), and Observation.code can indicate the battery status using the corresponding MDS attribute MDC_ATTR_VAL_BAT T_CHARGE defined in IEEE 11073 DIM, and upload the data to the hospital information system (HIS). Provided is a device measurement data upload method of a personal medical device information model system using a CoApp-based Fire resource, characterized in that the notification.

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

delete

As described above, according to the personal medical device information model system using the coapp-based fire resource according to the present invention, in the present invention, CoAP is selected as a transmission protocol to implement IEEE protocol (IEEE 11073 DIM) communication. It also monitors personal health information to cope with low battery life issues of limited devices (such as PHD or smartphones) due to high data traffic, using CoAP (FHIR) and IEEE protocols (IEEE 11073 DIM). By designing / implementing a unified architecture, the data is collected separately and the existing data processing process, which is inconvenient due to conversion by other protocols, is integrated and processed to realize the integration between the PHD device and the system to expand the data processing efficiency. There is.

In addition, the restful foundation makes it easy to connect with existing Internet services, thereby securing the diversity and expandability of services.

In addition, CoAP support ensures power efficiency, and CoAP support makes it easy to apply to critical small IoT healthcare devices that require reliable communication, and Internet-based collaboration between devices / sensors such as Social Health Web of Things (WoT) There is a possible effect.

In addition, the present invention is a Fire / Co-app based IEEE 11073 DIM converged healthcare communication technology, there is an effect that can secure a healthcare service standard technology through the convergence of the latest IoT standard (CoAP) and healthcare standard (FHIR). .

In addition, in preparation for future growth of the health service industry, there is an effect of preemptively developing and distributing open healthcare communication technology based on international standards based on FHIR.

1 is a diagram illustrating a layer structure of CoAP.
2 is a diagram illustrating a signal flow of CoAP.
3 is a diagram showing the architecture of the integrated IEEE 11073 DIM and FHIR using CoAP.
FIG. 4 is a diagram illustrating a result of defining mapping of some elements in a Personal Connected Health Alliance (PCHA) resource for mapping between IEEE 11073 and FHIR documents using CoAP.
5 is a diagram illustrating a method of registering a personal healthcare device with an FHIR server.
6 is a diagram illustrating a process of uploading measurement data through a device.
7 is a diagram illustrating a sample environment in which a CoAP-based healthcare management system is implemented.
8 is a sample of the FHIR data generated by the FHIR server in the CoAP-based healthcare management system and is a view showing the FHIR resource directory of the FHIR server.
9 shows round trip times for CoAP and HTTP-Restful messages.
10 is a conceptual diagram schematically illustrating a personal medical device information model system using a co-app-based fire resource according to the present invention.
11 illustrates an IEEE 11073 DIM-based device agent.
12 is a diagram showing a device agent component configuration in the present invention.
13 is a diagram illustrating an FHIR gateway in the present invention.
FIG. 14 is a diagram illustrating an interrelationship for mapping to an ISO / IEEE 11073 DIM and an FHIR specification based resource standard model.
FIG. 15 is a diagram illustrating a method for registering a personal healthcare device with an FHIR server in the present invention.
16 is a diagram illustrating a process of uploading measurement data through a device according to the present invention.
17 is a view illustrating a real-time alarm notification technique using the event flow engine in the present invention.
FIG. 18 is a diagram for developing an international standard linkage module based on Fast Healthcare Interoperability Resources that can be easily interlocked in a medical institution, a public institution, or a heterogeneous healthcare platform.

As the inventive concept allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description.

However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Hereinafter, with reference to the accompanying drawings, it will be described in detail a preferred embodiment of the present invention. In the following description of the present invention, the same reference numerals are used for the same elements in the drawings and redundant descriptions of the same elements will be omitted.

The following is a brief description of recent trends in IoT healthcare standardization. The Open Connectivity Foundation (OCF) is an industry organization that provides interoperability guidance and certification programs for IoT.In July 2014, it developed standards and certifications for IoT devices based on CoAP.

oneM2M is an international standard for M2M communications and IoT, providing a framework for interoperability between M2M and IoT technologies to eight countries and more than 200 member companies in ICT.

The IETF is an Internet standardization organization formed in 1986 and standardized on the CoAP standard in 2014. CoAP is an application protocol that provides functions similar to the Internet HTTP that enables low-power sensors and restricted objects to communicate over the Internet.

HL7 International defines several standards, guidelines, and methods by which healthcare systems can communicate with each other, including the Exchange standards (HL7 v.2, HL7 v.3 messaging, CDA, DICOM), and the technical standards (TCP / IP, encryption, security). )

FHIR combines the advantages of HL7 v.2, HL7 v.3, and CDA by focusing on leveraging and implementing the latest web standards based on pre-HL7 data format standards. Dedicated to FHIR's integrated research.

IEEE 11073 PHD is a IEEE 11073-20601 defines a data model for personal health devices, and consists of Domain Information Model (DIM) Service Model (SM), Communication Model (CM).

Hereinafter, a personal medical device information model system using a CoApp-based fire resource according to the present invention will be described in detail with reference to the accompanying drawings.

The present invention selects CoAP as the transport protocol to implement IEEE protocol (IEEE 11073 DIM) communication, and also personal health information to solve the problem of low battery life of limited devices (such as PHD or smartphone) due to high data traffic. We designed and implemented the integrated architecture of FHIR and IEEE 11073 DIM using CoAP.

First, an overview of international medical standards such as the ISO / IEEE 11073 PHD standard, the HL7 standard, and the FHIR for communication between healthcare devices and service providers is introduced. It also introduces the architecture for CoAP-based FHIR, introducing the functionality of the protocol (CoAP) for use on restricted nodes.

International healthcare standards

ISO / IEEE 11073 PHD  Standard

The IEEE 11073 personal healthcare device standard is based on a single “framework” standard and “device specialization” standard.

IEEE 11073-20601 is a framework standard that defines common data types, message types, and communication models. It supports the “device specialization” standard, which defines a data model only for certain types of personal healthcare devices. This particular healthcare device is optimized for IEEE 11073-20601 transmitted through existing transmission technologies such as Bluetooth, Zigbee, etc. and encoded via a protocol.

The IEEE 11073 PHD standard consists of a Domain Information Model (DIM), a Service Model (SM), and a Communication Model (CM). This standard presents the concepts of "agent" and "manager". An agent is a node that collects personal healthcare data and sends it to a manager, and a manager is a node that receives data from one or more agent systems. Examples of managers are cell phones, healthcare devices, set-top boxes, or personal PCs.

DIM represents an agent as a set of objects with one or more attributes. Attributes refer to measurement and status data that are passed to the administrator. Represents the DIM of the ISO / IEEE 11073 PHD standard.

Each personal healthcare device is associated with a Medical Device System (MDS) object. This object is each unique agent and is used to report the agent's status. The agent uses the internal properties of the MDS to provide some information to the administrator.

MDS includes objects that belong to classes such as the Metric class, the Numeric class, and so on. The Numeric class represents a single measurement in 32-bit or 16-bit floating point format. The real time sample array class represents continuous waveform samples. When enumerating, status information (code) or comment (text) is displayed. Each PM-segment object processes meta information (data about the data) and one or more entries, each item consisting of one or more items containing measurements.

CM supports one or more agent topologies that communicate over a one-to-one connection with a single manager. The IEEE 11073 standard assumes that a transport layer (eg Bluetooth, Zigbee) can be established between the agent and the manager through some mechanism that is independent of the transport and beyond the scope of the standard. For each point-to-point connection, the dynamic system behavior is defined by the link state machine. The link state system contains states related to connections and operations and defines the states and substates that pass through agents and managers. The CM also defined the entry, exit, and error conditions for each state in detail, along with various procedures for transmitting measured data. Another function of CM is to convert the abstract data modeling used in DIM into transmission syntax. The conversion process, known as MDER (Medical Device Encoding Rules), takes the data contained in an object and encodes it into a binary message for transmission using a CM. Upon receipt of the message, it can be clearly decrypted and the object and its data extracted.

The MDER rule is a subset of the BER rule. The representation of an MSN-encoded ASN.1 object is conceptually similar to using XML as an independent way of exchanging data. In fact, the XER transfer syntax also sends ASN.1 objects as XML. However, there are some differences: MDER messages are much smaller than equivalent XML messages and are much simpler to convert to and from internal data structures.

The ISO / IEEE 11073-104xx standard defines the specific device of a particular device in the higher ISO / IEEE 11073-20601 standard. This standard defines a communication method for interoperable personal healthcare devices.

HL7 (Health Level Seven) standard

Health Level 7 (HL7) provides a framework (and related standards) for the exchange, integration, sharing and retrieval of electronic healthcare information. HL7 International has defined a number of standards and guidelines that enable various healthcare systems to communicate with each other. The HL7 standard is a set of international standards focused on the application layer of the OSI 7 layer model for data transfer and management between software applications used by various healthcare service providers. As a result, various healthcare providers using independent systems can follow the HL7 standard for providing international healthcare.

To support interoperability, HL7 can be divided into three parts: healthcare standards, semantic standards, and syntactic standards. The syntax standards can be divided into two parts: exchange standards and technical standards. Exchange standards include HL7 v.2 messaging, HL7 v.3 messaging, HL7 CDA, and DICOM. Technical standards include TCP / IP, Encryption, and Security. It can also be divided into two parts, the message exchange standard and the document exchange standard.

The purpose of the message exchange standard is to specify the format of the data exchange. There are standards such as HL7 v.2x, HL7 v.3, DICOM, and NCPDP.

The HL7 Version 2.x (V2) messaging standard is the focus of electronic data exchange and the world's most widely implemented medical standard. This messaging standard allows the exchange of clinical data between systems. HL7 Version 2.x is designed to support a central patient care system as well as a distributed environment rather than having the data reside on the system.

HL7 CDA is an electronic standard used for the exchange of clinical documents developed by HL7. Because it uses the XML language, it is unique in that it can be read with the naked eye or machined. Essential freeform parts enable human interpretation of the documented part, and optional structured parts enable electronic processing. A signed document is a document that can be executed by the CDA. Examples include diagnostic reports, clinical summaries, introductions, and healthcare reports. Due to the non-specified transport mechanism, CDA can transfer HL7 V2, HL7 V3, DICOM, MIME encoded attachments using FTP or HTTP. CDAs are flexible enough to be compatible in a variety of environments and can be stored on computer systems as documents or transmitted as message content.

HL7 FHIR Fast Health Interoperable  Resources

Fast Healthcare Interoperability Resources (FHIR) is the standard technology for healthcare data communications currently under development in HL7. FHIR is designed to serve documents and messages through a RESTful interface.

FHIR is a standard framework that defines multiple methods for solving problems in healthcare communications and provides resource specifications that can be used in a variety of environments. Its purpose is to support a path to interact with the standards of existing transport models. Developed. FHIR is the next-generation medical standard under development at HL7 to ensure healthcare data communications or interoperability. It was first proposed in July 2011 to address changes in information and communications technologies such as mobile and the Internet of Things. The Draft Standard for Trial Use (DSTU3) is underway to increase the maturity by accommodating the needs of various healthcare providers that are currently available.

FHIR can implement various types of information in the form of resources that can be simplified and recycled to communicate healthcare data, and can process documents and message services required for data communication using a simplified interface. In addition, this data communication, document, and message service can be expressed using a combination of various types of resources, making the resources easy to recycle. In order to increase the recyclability of these resources, by combining the resources, items that can be referred to by different resources are provided so that they can be combined with each other to form a resource.

Resources are based on a set of modular components that can be combined, referenced, and broken down to address the diverse needs of different healthcare environments.

Different healthcare environments are different, and 20% of the resources provided in the FHIR specification can be extended and constrained to reflect the needs of different healthcare services. This process is called profiling.

Healthcare  Internet Protocol for Services

CoAP (Constrained Application Protocol)

The CoAP protocol is a special web transport protocol that can be used for low power networks and low capacity small nodes. The Constrained RESTful Environment (CoRE) organization within the IETF acquired the international standard in 2014 as the upper application layer protocol of the 6LoWPAN (Low-power Wireless Personal Area Network). In addition, various standardization organizations, such as oneM2M and OMA, have adopted CoAP and are in the process of standardization. CoAP follows the RESTful (Representational State Transfer) idea, so it can be easily converted and interworked with the existing HTTP web protocol.

The structure of CoAP basically supports unicast and multicast using UDP protocol as a transport layer of a lower protocol stack as shown in FIG. Because it operates asynchronously, REST message and timer management are included as an option for reliable delivery. It is divided into Request / Response layer and Message layer.

CoAP consists of a default header and an optional header of up to 8 bytes, and performs binary encoding to have a message size less than 1/10 of an HTTP message. Each CoAP message contains a message ID that is used for detecting duplicates and for optional reliability. By supporting the RESTful structure, all resources are represented by URI and the behavior for the resource is defined by using basic and observe methods of GET, PUT, POST, and DELETE. This has the advantage of easy interoperability with existing HTTP.

CoAP supports CON (Confirmable) and NON (Non-confirmable) message transmission for the reliability of message transmission. Referring to Figure 2, a reliable message is retransmitted using the default timeout and exponential backoff between being retransmitted until the receiver sends an ACK message using the same message ID at that endpoint. Untrusted messages can be sent as NON messages, which are not acknowledged.

In addition to the advantages mentioned above, CoAP has the advantages of security using DTLS, cross-protocol proxying between CoAP and HTTP, and discovery, which can be very useful in the IoT environment.

In the present invention, the FHIR-based healthcare application service structure is implemented using CoAP to provide IoT healthcare services.

Integrated architecture

An integrated architecture of IEEE 11073 DIM and FHIR using CoAP is described and a method of implementing a transaction between a PHD and a healthcare provider is shown in FIG. 2. The integrated architecture consists of a personal health device adapter, a personal health device observer (PHDOR) and a personal health device observer (PHDOC) to implement a communication process as shown in FIG.

System Architecture

The Device Observation Reporter (DOR) actor receives data from the PHD, including based on the proprietary format between the 11073 DIM and the FHIR, and maps the received data to transactions that provide a consistent syntax and semantics, such as PHDOR.

DOC (Device Observation Consumer) is responsible for receiving FHIR data from Device Observation Reporter, Device Observation Filter or both like PHDOC.

Device Obsevation Filter (DOF) actors provide an optional FHIR data filtering service based on publish / subscribe conditions negotiated with client applications that implement device observation consumers, such as FHIR servers.

IEEE 11073 with DIM CoAP  Used Of FHIR  Integrated Architecture

* Personal Health Device Adapter

The Personal Health Device Adapter is defined to collect data measured in the PHD for PHD data standardization and to communicate with the personal healthcare device observation reporter in accordance with IEEE 11073 DIM. The adapter consists of PHDAS Adapter Software (PHDAS) and IEEE 11073 DIM Translator.

- PHDAS ( PHDs  Adaptor Software)

PHDAS is defined to collect device data via Bluetooth or USB from the PHD and communicate with a personal healthcare device observation reporter. In this way, the CoAP client was designed to complete the process. After registration, periodic or non-periodic measurement data is generated using the CoAP POST method and sent to the personal healthcare device observation reporter using the CoAP PUT method.

IEEE 11073 DIM Translator

The IEEE 11073 DIM Translator is defined to standardize personal healthcare device data according to the IEEE 11073 DIM. As mentioned earlier, each personal healthcare device is associated with a Medical Device System (MDS) object defined by DIM. MDS objects include Metric (Numeric, Real-Time Sample Array (RT-SA), Enumeration), PM-Store, PM-Segment (Persistent Metric Segment), scanner, and so on. The IEEE 11073 standard defines Medical Device Encoding Rules (MEDR) according to the Abstract Syntax Notation One (ASN.1) language that describes device data, but selects Java Script Object Notation (JSON) to compile the DIM in this document.

* PHDOR (Personal Health Device Observation Reporter)

Personal Health Device Observation Reporter (PHDOR) is defined to receive PHD data, map the data between IEEE 11073 DIM and FHIR documents, and then deliver it to the FHIR server or directly to the healthcare service provider. PHDOR consists of Device Observation Reporter Communicator (DORC) and IEEE 11073 / FHIR Translator.

- DORC (Device Observation Reporter Communicator)

DORC is defined as a middleware platform that provides a common function for interconnecting personal healthcare devices and includes registration, monitor and device management functions. In the present invention, the DORC platform is implemented in a smartphone application and a CoAP client and a CoAP server are designed in this application. CoAP server is used to connect with PHDA and CoAP client is used to communicate with FHIR server. In the designed application, there are five resources based on CoAP for communication with the FHIR server, Patient, Device, DeviceComponent, DeviceMetric, Observation, and four types of resource registers: Device, DeviceComponent, DeivceMetric, and Observation To provide.

IEEE 11073 / FHIR  Translator

The designed IEEE 11073 DIM / FHIR Translator maps data between IEEE 11073 DIM data and FHIR document according to FHIR standard and IEEE 11073 PHD DIM.

Follows the rules of the FHIR standard for mapping IEEE 11073 DIM / Nomenclature to FHIR documents and mapping IEEE 11073 data types to FHIR document types. As we know, the FHIR specification has defined four resources to support the reporting of device acquisition information. Device resources are resources for all connected devices. The DeviceComponent resource is used to support modeling 11073 with nodes named MDS, VMD or Channel. DeviceMetric resources are used to support 11073 metadata, Observation is used to represent instancedata, and these resources are used to represent PHD information. For the mapping between IEEE 11073 and FHIR documents, the mapping of some elements is defined in the Personal Connected Health Alliance (PCHA) resource. The diagram is shown in FIG. The gateway then uses the information encoded in 11073 DIM data to implement MDC code mapping. For example, using a device such as SpO2, a personal healthcare device, the reference ID is MDC_PULS_OXIM_SAT_O2, code 19384, and partition number 2. The MDC code used in the FHIR data can be calculated as follows.

* PHDOC Personal Health Device Observation Comsumer )

Personal Health Device Observation Users are implemented as smartphone applications using CoAP clients for remote monitoring, such as doctors and private medical institutions via FHIR servers.

Signal flow chart

This section shows some signal flows for device registration and device upload measurement data for healthcare device provider monitoring.

- device  Enrollment

5 shows how a personal healthcare device is registered with the FHIR server. First, the Personal Health Device Observation Reporter creates a Patient resource for registering patient information with the FHIR server. Secondly, PHDA maps device data to IEEE 1103 DIM data and then creates device resources in the PHD observation reporter. The PHD observation reporter creates Device Resources, DeviceCompoent Resources, and DeviceMetric Resources on the FHIR server for the PHD information register.

Device upload measurement data

In FIG. 6, the device domain generates an observation reousrce to the PHD observation reporter, and the PHD observation brings measurement data by creating an observation resource corresponding to the FHIR server by the device observation consumer. After PHDOC obtains FHIR resource list using CoAP, PHDOC applies GAP request to FHIR server by using CoAP observae method and registers for FHIR resources (Patient, Device Component, DeviceMetric and Obsevation). In addition to returning a representation of the target resource, this request also causes the server to add the client to the client observer list. When certain device-related resources change, the FHIR server informs each client of the list of observers of these resources.

When the PHDOR uploads the measured data, it also uploads the device status information defined in the FHIR specification. For example, DeviceMetric.operationalStatus can use the corresponding MDS property MDC_ATTR_POWER_STAT to indicate the current operational status of the device (such as ON / OFF) and Observation.code can use the corresponding MDS property MDC_ATTR_VAL_BAT T_CHARGE defined in IEEE 11073 / DIM. Can indicate status.

IoT  base Healthcare  Implementation of management system

Implementation environment

Table 1 shows the implementation environment for the integrated architecture and the sample shown in FIG. It shows how the data measured by Spo2 sensor generates and transmits the message according to the IEEE 11073-10404 standard. We design a PHD Observation application to collect measured data based on CoAP and upload it to the FHIR server. At the same time, the reporter exchanges data between personal healthcare devices and healthcare service providers in accordance with IEEE 11073 and FHIR standards. We then simulated a condition monitoring application that could obtain health data for a specific patient measured with a specific PHD.

In this simulation experiment, we used a Raspberry Pi, a SpO2 sensor, and an Android smartphone desktop PC, and the Raspberry Pi acts as a personal healthcare device adapter. Desktop PCs play the role of PHDOF running CoAP-based FHIR servers, while Android smartphones play the role of PHDOR. In order to show the FHIR resource and communication result more intuitively, Coppor CoAP Firefox Plugin was used to derive the result.

In addition, I selected Signove's open source Antidote to write FHIR-based data and implement CoAP-based FHIR server to use ISO / IEEE 11073 DIM, CoAP server and client to use California CoAP library and HAPI FHIR library.

8 is a sample of the FHIR data generated by the FHIR server and the FHIR resource directory of the FHIR server. Two registered users can access the FHIR resource directory belonging to a specific user's ID by using the CoAP search method. The healthcare service provider can then use the Coppoe Agent plug-in to retrieve data from the PHD registered by the user using the user's ID through the FHIR server. When PHD measures the data to upload to the FHIR server, you can check the Observation document based on the FHIR message format in the Combined Payload box.

Performance analysis

Communication protocol comparison

9 shows round trip times for CoAP and HTTP-Restful messages. As shown in the figure, it can be clearly seen that the communication speed of CoAP is faster than HTTP-Restful when sending the same FHIR message to the FHIR server. This is because CoAP is based on UDP, which does not require a three-way handshake. Since the NON request is not a "verifiable" message, the CoAP NON request is faster than the CON request and chooses to use the CON request. To save resources on both the network and both client and server, the CoAP server applies the piggyback response of CON as much as possible. This request is sent directly from the Acknowledgment message acknowledging the request. The RTT per message for HTTP is about 10 times longer than that of CoAP. This means that the data collection nodes of the transceiver and server require higher CPU power using the HTTP protocol, resulting in higher power losses. Therefore, CoAP chose CoAP to better fit the resource constraints applied to the IoT domain and to work well with the communication protocol of the proposed integrated architecture.

Compare data

For data comparison, select PCD data to be compared with FHIR data, and transmit the measured SpO2 data to FHIR server and PCD server about 100 times. PCD data is 2.59 times faster than FHIR data. In addition, PCD uses the syntax and conventions of HL7 v2 to represent information, creating barriers to patients and lacking interoperability. The difference is that FHIR data can be represented using XML and JSON, which improves interoperability in information exchange and readability. Thus, FHIR is a better choice than EHR's PCD data and is faster and lighter.

In the present invention, CoAP is used to design and implement an integrated architecture of IEEE 11073 DIM and FHIR. The use of CoAP meets the needs of personal healthcare devices based on IoT. This integrated architecture enables data transfer between the patient and the healthcare provider and makes it easy for the healthcare provider to know the EHR. IEEE 11073 DIM Translator also addresses interoperability issues by standardizing information from nonstandard healthcare devices.

The IEEE 11073 / FHIR Translator enables healthcare service providers to obtain measured data after verification and improves interoperability between personal healthcare devices and applications from healthcare service providers. In the case of electronic healthcare records, the use of FHIR documents can reduce human recording errors in everyday life, and the present invention mainly focuses on the device-related resources of the FHIR standard. In the future, various FHIR resources will be expanded to provide more healthcare services between healthcare devices and healthcare service providers.

10 is a conceptual diagram schematically illustrating a personal medical device information model system using a co-app-based fire resource according to the present invention.

In other words, it builds a FHIR-based healthcare service platform that supports international standards, and the healthcare device collects various data through the gateway and provides visualized information to the user app.

Referring to FIG. 10, a personal medical device information model system using a CoApp-based Fire resource is schematically connected with a healthcare device 10 having a biosignal measurement sensor 12 and a healthcare device 10. The healthcare gateway 20 is configured to process data, and is connected to the healthcare gateway 20, and is configured with a fire-based (FHIR) healthcare service system 20 and a user app 50.

The FHIR-based healthcare service system 20 includes standard data 22 which stores standard data on data integration model, data integration, information type analysis engine, and bio-signal comprehensive analysis, event editing, performance index, Portal (24) including functions such as resource monitoring, administrator setting,

Interface consisting of common functions (registration, retrieval, device management, data transmission) and data collection / conversion / management including remote control, communication protocol, authentication, A & E, trend, and QoS,

A data hub consisting of message brokers including DB I / F, FILE I / F, streaming I / F, and databases including distributed, real-time, relational, and file systems;

Analysis, including algorithms, predictions, optimizations, statistical analysis,

Visualization, including medical care, HMI, GIS, infographics,

A healthcare platform comprising a development framework, a software development tool, a development tool including a software testing tool,

It includes IaaS interfaces, including container management, SW platform resource management, and application management, and includes CLoud, including PasS and laaS, which include virtualization of servers, storage, and networks.

The user app is a health care monitoring service, a general user app (52) for performing dry pregnancy management services for pregnant women, medical professionals such as medical specialists, medical professionals, hospital officials (54), the Ministry of Health and Welfare, Health Insurance Corporation, local governments, etc. Includes an agency app 56.

Referring to FIG. 11, the device 10 is an IEEE 11073 DIM-based device agent, which exchanges measured biometric information with a healthcare sensor device, transmits measured biometric information to an IEEE 11073 / FHIR gateway, and implements in C language. The operating environment is Linux, and the communication method is BLE / WiFi, 3G / LTE, or Ethernet.

The healthcare gateway 20 supports protocol conversion of IEEE 11073 DIM and FHIR and additionally provides FHIR messages based on CoAP to support low power / wideband technology.

The healthcare gateway 20 collects 11073 DIM data from the healthcare device, maps 11073 DIM data to FHIR resource content, creates FHIR resources and communicates with the FHIR server, reads, creates, retrieves, updates, deletes and records It provides a method, supports JSON, and is implemented in JAVA. The operating environment is Android, and the communication method is BLE / WiFi, 3G / LTE, or Ethernet.

FHIR server 30 is a FHIR protocol stack mounted as a healthcare server supports CoAP and HTTP-based FHIR message processing.

The FHIR server 30 manages personal healthcare information and devices, communicates with the IEEE 11073 / FHIR gateway 20, communicates with the hospital information system 40, and reads, creates, retrieves, updates, deletes and records methods. It supports, supports JSON, and is implemented in JAVA. The operating environment is Linux, and the communication method is BLE / WiFi, 3G / LTE, or Ethernet.

Referring to FIG. 12, a device agent component configuration will be described. The biometric information measured by the healthcare device is collected and analyzed by the IEEE 11073 DIM specification-based data standard model, and then transmitted to the IEEE 11073 / FHIR gateway.

The DIM analyzer 110 analyzes the IEEE 11073 DIM data model for exchanging biometric information between the healthcare sensor device agent and the healthcare sensor device to extract the requested biometric information or to construct a data model for the biometric information to be requested. Play a role.

The service message builder 120 composes a message required for data exchange between the healthcare sensor device agent and the healthcare sensor device or parses the received message and corresponds to the service model defined in IEEE 11073.

The IEEE 11073 transport manager supports communication between the healthcare sensor device agent and the healthcare sensor device or supports communication between the healthcare sensor device agent and the gateway.

Referring to FIG. 13, the FHIR gateway relates to IEEE 11073 DIM-based biometric information collected and analyzed by a device agent, and maps the FHIR specification-based resource standard model to the FHIR server 30.

FHIR Resource Content Mapper 220 collects 11073 DIM data from the healthcare sensor device agent, maps IEEE 11073 DIM data to FHIR resource content, and generates FHIR resources (JSON support).

An IEEE 11073 data collector for collecting IEEE 11073 data, an FHIR structure analyzer for analyzing the collected data structure, and an FHIR resource generator for generating resources.

The mapped resources are delivered from the FHIR resource content mapper, and the FHIR resource sender 240 provides an FHIR header and body generation function for communication. It provides read, create, retrieve, update, delete, and record methods for managing personal healthcare information, namely FHIR resources on EHRs, communicates with FHIR servers, and supports CoAP and HTTP.

The FHIR resource sender 240 includes a FHIR header generator for generating a header, a FHIR body generator for generating a body, and an FHIR validator checker for checking generated data.

Referring to FIG. 14, an interrelationship for mapping to an ISO / IEEE 11073 DIM and an FHIR specification-based resource standard model is illustrated.

The DeviceMetric Resource applies only to describing a single metric node created by the context scanner in a healthcare device that implements the IEEE 11073 standard. The DeviceComponent resource describes the characteristics, operational status, and functionality of the healthcare-related components of the healthcare device. do.

Referring to the DeviceComponent resource, attributes in the DeviceComponent include MDS and Virtual Medical Device (VMD) Channel. MDS is a physical device that communicates with external systems, VMD is a healthcare related subsystem and physical hardware plug-in component of a healthcare device, and Channel is a non-physical component that can group healthcare data and its derived data. to be.

Several signal flow diagrams for device registration and device upload measurement data are shown for healthcare device provider monitoring. It is almost the same as the existing FIGS. 5 and 6.

- device  Enrollment

15 shows how a personal healthcare device is registered with the FHIR server. First, the IEEE 11073 / FHIR gateway creates a Patient resource for registering patient information with the FHIR server (S1). Secondly, the device maps the device data to the IEEE 1103 DIM data, and then creates a device resource to the IEEE 11073 / FHIR gateway (S2). The IEEE 11073 / FHIR gateway creates a Device resource, a DeviceCompoent resource, and a DeviceMetric resource in the FHIR server for the device information register (S3, S4, S5).

Device upload measurement data

In FIG. 16, the device generates an observation resource to the IEEE 11073 / FHIR gateway (S11), and the IEEE 11073 / FHIR gateway creates an observation resource corresponding to the FHIR server to the FHIR server and uploads measurement data from the FHIR server (S12). .

The hospital information system (HIS) uses the CoAP to obtain a list of FHIR resources and then initiates a GET request to the FHIR server and registers the FHIR resources (Patient, Device Component, DeviceMetric and Obsevation) (S13, S14). In addition to returning a representation of the target resource, this request also causes the server to add the client to the client observer list. When certain device-related resources change, the FHIR server informs each client of the list of observers of these resources.

When the device uploads the Obsrvation Resource request to the IEEE 11073 / FHIR gateway (S15), and uploads the measured data, it also uploads the device status information defined in the FHIR standard. For example, DeviceMetric.operationalStatus can use the corresponding MDS property MDC_ATTR_POWER_STAT to indicate the current operational status of the device (ON / OFF, etc.) and Observation.code can use the corresponding MDS property MDC_ATTR_VAL_BAT T_CHARGE, as defined in IEEE 11073 DIM. Can be represented. The data upload is notified to the hospital information system (HIS) (S16).

A real time alarm notification technique using an event flow engine will be described with reference to FIG. 17.

An event flow refers to a workflow that executes specific actions by a specific state of a service terminal or a request of a user. You can perform multiple actions in one event.

In FIG. 17, a real time alarm notification function, an event processing rule setting for each user, and a control function of a biosignal sensing device are provided according to a rule registered through an event flow engine in the system.

The biosignal data information is transmitted from the device 10 to the FHIR server 30, and the FHIR server 30 controls the biosignal device and transmits a control command such as changing a measurement cycle when a biosignal error occurs.

The FHIR server 30 includes an event flow engine 310 and the event flow engine 310 detects abnormality of biosignal information (eg, detects abnormality of information on EMG intensity abnormal rule storage). The event processing rule (Rule) is registered and stored in the event flow information 320 DB. This processing rule information is changeable and managed. The FHIR server detects abnormality of the biosignal information (analysis / detection process), notifies the occurrence of an event, and transmits the biosignal sensing information to an email, a push, a short text message, or a service server. Alternatively, the guardian terminal (or the app of the terminal) is notified of a biosignal abnormality.

FIG. 18 is a diagram for developing an international standard linkage module based on Fast Healthcare Interoperability Resources that can be easily interlocked in a medical institution, a public institution, or a heterogeneous healthcare platform. The linkage system includes a hospital linkage system, a public health care linkage system, and a heterogeneous healthcare system, which are linked to the FHIR-based healthcare service system through the FHIR. In other words, the FHIR-based healthcare service system has FHIR resources such as membership, service, model information, device information (INDENFICATION) and measurement information, and CLINICAL information of standard codes, and includes operation data and health data. The same standard data information may be processed in conjunction with each other through the FHIR data broker.

As described above, the best embodiment has been disclosed in the drawings and the specification. Although specific terms have been used herein, they are used only for the purpose of illustrating the present invention and are not intended to limit the scope of the invention as defined in the meaning or claims. Therefore, those skilled in the art will understand that various modifications and equivalent other embodiments are possible from this. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

10: (healthcare) devices
20: (Healthcare) Gateway
30: FHIR Server
40: Hospital Information System

Claims (8)

As an IEEE 11073 DIM (Domain Information Model) based agent, a device for exchanging measured biometric information with a healthcare sensor device and transmitting measured biometric information,
It supports protocol conversion between IEEE 11073 DIM and FHIR and provides additional FHIR messages based on CoAP to support low power / wideband technology.
An IEEE 11073 / FHIR gateway that collects IEEE 11073 DIM data from the device, maps IEEE 11073 DIM data to FHIR resource content, and generates FHIR resources;
A FHIR protocol stack mounted as a healthcare server that supports CoAP and HTTP-based FHIR message processing, manages personal healthcare information and devices, and communicates with the IEEE 11073 / FHIR gateway (FHIR) server, and
A hospital information system server in communication with the fire server and notified of information about information from a device,
The IEEE 11073 / FHIR gateway maps the IEEE 11073 DIM-based biometric information collected and analyzed to the device to a FHIR specification-based resource standard model and delivers the information to the FHIR server, but collects the IEEE 11073 DIM data from the healthcare sensor device agent. A FHIR resource content mapper for mapping IEEE 11073 DIM data to FHIR resource content and generating FHIR resources;
A FHIR resource sender providing a FHIR header and a body generation function for communication through a mapped resource delivered from the FHIR resource content mapper,
The FHIR resource content mapper includes an IEEE 11073 data collector for collecting IEEE 11073 data, an FHIR structure analyzer for analyzing the collected data structure, and an FHIR resource generator for generating resources. Including,
The FHIR resource sender includes a FHIR header generator for generating a header, a FHIR body generator for generating a body, and a FHIR validator checker for checking the generated data. Personal Medical Device Information Model System Using Fire-based Resources. The method of claim 1, wherein the device collects and analyzes the biometric information measured by the healthcare device in an IEEE 11073 DIM specification-based data standard model, and transmits the biometric information to the IEEE 11073 / FHIR gateway.
A DIM analyzer (Analyzer) that analyzes the IEEE 11073 DIM data model for exchanging biometric information between the healthcare sensor device agent and the healthcare sensor device and constructs a data model for the requested biometric information; ,
A service message generator that composes a message required for data exchange between the healthcare sensor device agent and the healthcare sensor device or parses the received message, and which corresponds to the service model defined by IEEE 11073;
Personal medical device information model system using COApp-based Fire resource including IEEE 11073 Transport Manager to communicate between the healthcare sensor device agent and the healthcare sensor device or to support communication between the healthcare sensor device agent and the gateway . delete delete delete delete A personal medical device information model system using a CoApp-based Fire resource, which includes a device, a gateway connected to the device to process data, a Fire (FHIR) server connected to the gateway to process data, and a hospital information system. In the device measurement data upload method of
The device creates an observation resource to the IEEE 11073 / FHIR gateway,
The IEEE 11073 / FHIR gateway creates an observation resource corresponding to the FHIR server to the FHIR server and uploads measurement data from the FHIR.
The hospital information system (HIS) uses the CoAP to obtain a list of FHIR resources, initiates a GET request to the FHIR server, and registers for FHIR resources (Patient, Device Component, DeviceMetric and Obsevation).
When the device uploads an Obsrvation Resource request to the IEEE 11073 / FHIR gateway and uploads the measured data, it also uploads the device status information defined in the FHIR specification. It can indicate the current operating status of the device (ON / OFF, etc.), and Observation.code can indicate the battery status using the corresponding MDS attribute MDC_ATTR_VAL_BAT T_CHARGE defined in IEEE 11073 DIM, and upload the data to the hospital information system (HIS). Device measurement data upload method of a personal medical device information model system using a CoApp-based Fire resource, characterized in that the notification. delete

Images