- Email: [email protected]
Application of HL7® FHIR for device and health information system interoperability
Chapter 85
Application of HL7® FHIR for device and health information system interoperability Ricardo J. Silvaa,b, Elliot B. Sloaneb,c, Todd Cooperd a
Foundation for Living, Wellness, and Health, Orlando, FL, United States, bComputing Sciences, Villanova University, Villanova, PA, United States, cFoundation for Living, Wellness, and Health, Osprey, FL, United States, dTrue Health Trust, San Diego, CA, United States
What is “Devices on FHIR (DoF)®”? “Devices on FHIR (Fast Healthcare Interoperability Resources) (DoF)” is a collaborative effort that unites activities underway in HL7, Continua, IHE USA, and Integrating the Healthcare Enterprise (IHE) International (www.IHE.net, www.IHEUSA.org, www.HL7.org, www.PCHAlliance.org) (IHE USA, 2018). DoF is intended to ensure semantically consistent device information exchange whether achieved using current IHE Patient Care Devices (IHE-PCD) HL7 Version 2-based messaging or new, emerging IHE-PCD, and Continua® integration profiles that embrace the HL7 FHIR®-based resources and profiles. HL7 FHIR (https://www.hl7.org/fhir/) is a standard that defines resources, including content definitions, architectural models, and health information exchange (HIE) paradigms. The FHIR standard uses web-based technologies (e.g., HTTP or XML) to exchange standardized device data (HL7, 2018; HL7 2019; IHE USA, 2018; IHE International, 2019). FHIR® (https://www.hl7.org/fhir/)—is a next generation standards framework created by HL7. FHIR combines the best features of HL7s v2, HL7 v3, and Clinical Document Architecture (CDA) standards families while leveraging the latest web standards and applying a tight focus on implementability. Briefly, HL7 v2 relies on very carefully defined purpose- specific text-based messages with “fixed field” data, in which data elements like date, time, or physiologic parameters like systolic blood pressure are assigned very rigid-field locations and content specifications in a stream of data. By contrast, HL7 v3 and CDA rely on a foundational reference information model (RIM) and very precisely structured XML data definitions, which include hierarchical structures Clinical Engineering Handbook. https://doi.org/10.1016/B978-0-12-813467-2.00086-9 Copyright © 2020 Elsevier Inc. All rights reserved.
plus explicit beginning and end “tags” of the form10101990 to organize patient data. The hierarchical structure provides a roadmap to the data, as in PatientRecord has sub-records of DemographicData, Insurance Data, and Vital Signs Data, and Vital Signs Data has sub-records of time-stamped, tagged records for blood pressure, temperature, and/or heart rate. Clearly, for any system of medical devices, apps, and/or electronic medical recordkeeping software, all components of the system would need clear, complete, and precisely synchronized a priori programming with the specific HL7 v2 or v3 standards in order to reliably, safely, and securely exchange patient data. With the rapid proliferation of inexpensive, wearable, IoT, and other wireless mobile health devices and apps [personal health devices (PHDs), in the IHE vernacular], the cost and complexity of constantly updating every device to ensure a priori consistency is significant (IHE-PCD, 2019). Also, the HL7 v3 XML can make a simple message very “verbose,” which can consume wireless bandwidth, storage, and processing resources. For example, a blood pressure reading of September 1, 2 PM blood pressure 70/120 mmHg can balloon into 09012019 1400 EST 70 mmHg …
612 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
conventions. FHIR is built on the foundation established by HL7 V2 and V3, but keeps the complex details “under the hood.” The receiving device or software does not need a priori knowledge of the content or structure, because the sending device includes the necessary instructions to unpack the contents. Granularity is important for lightweight devices and applications. That is, for a home-bound elder patient with chronic heart disease, e.g., a home care aid probably only wants the latest blood pressure, or the highest and lowest blood pressures in the past 3 h. The nurse does NOT need or want a flood of all blood pressure readings for the past week! Therefore my application can request a specific granular quantity of data, and if the device or system has such data, it will be sent back along with instructions on decoding. FHIR was designed to be suitable for use in a wide variety of contexts—mobile phone apps, cloud communications, electronic health record (EHR)-based data sharing, server communication in large institutional healthcare providers, and much more. According to HL7, the current FHIR Release 4 (R4) of this standard is the first “normative” version that includes core content that is now frozen, enabling increased product use without the fear of major
FIG. 1 Structure of an HL7 FHIR “patient” resource.
changes in the underlying specifications. R4 is undergoing thorough ongoing testing and validation for connecting medical devices to each other and EHR systems. Devices from hospitals (e.g., physiological monitors or infusion pumps) and PCDs (e.g., thermometer, weight scale, pulse oximeter or ECG monitor) are also a part of the DoF effort.
How does FHIR® work? FHIR solutions are built from a set of modular components called “Resources” (Fig. 1). These resources can easily be assembled into working systems that solve real-world clinical and administrative problems at a fraction of the price of existing alternatives. “Resources” are ● ● ● ● ●
small logically discrete units of exchange define behavior and meaning known identity/location smallest unit of transaction “of interest” to health care V2: Sort of like Segments. V3: Sort of like CMETs.
Application of HL7 FHIR® Chapter | 85 613
FHIR supports four interoperability paradigms: REST, Documents, Messages, and Services (see also “First Time Here” section of: www.HL7.org/FHIR): ●
●
●
●
REST is a simple, out-of-the-box interoperability solution that leverages HTTP: GET, POST, etc. Using predefined operations such as Create, Read, Update, Delete, History, Read Version, Search, Updates, Validate, Conformance, and Batch. The RESTful interface comes from years of use in APIs from tech companies like Google, Twitter, and Facebook, and now is finally in health care. Documents are bundles similar to HL7 v3 CDA. The biggest difference is that atomic data access provided by FHIR, meaning that instead of transmitting and parsing a huge file composed of all records of a patient’s life, you can make a specific request for a specific observation and get that only. Documents are a collection of resources bound together. Root is a “Composition” resource, just like CDA header. Documents can be signed, authenticated, etc. Messages are similar to HL7 v2 and v3 messaging. It can also be also a collection of resources as a Bundle. This specification assumes that content will be delivered from one application to another by some mechanism, and that one or more responses will be returned to the source application. It is event-driven allowing request/response behavior with bundles and can be asynchronous, for example, Send lab order, get back result. Services are cohesive sets of functions that maintain responsibility for both data and “state” for the scope of their responsibility. Service-oriented architecture (SOA) is an architecture pattern using services to encapsulate and provide discrete pieces of application functionality to each other. Services communicate by invoking public interfaces and exchanging information (as parameters and outputs) in accordance with a well-defined service contract (FHIR Release 4, 2018).
Devices on FHIR Today, devices use hundreds of proprietary or “semi- standard” protocols. For example, the ISO/IEEE 11073 family of standards is intended to enable vendor-agnostic semantic interoperability point-of-care medical device communication. Each ISO/IEEE 11073-x standard specifies the structure of medical information objects. This standard also defines an abstract communication model to support the exchange of medical information objects. FHIR has been proposed to become a more modern, mobile-friendly, and agile common interoperable architectural base aligned with the ISO/IEEE 11073 semantic content specifications (terminology and information model).
The evolution of DoF has been the following: HL7 healthcare devices (WG) started a project to support device informatics in FHIR. Later IHE-PCDs published a white paper to investigate how FHIR might be used and created a few FHIR profiles (MHD & mACM). NIST has supported FHIR-based conformity testing, and Continua Health Alliance started to work on FHIR support for PHDs. Regarding implementation, OR.net/OpenSDC created— WS* for FHIR prototypes, and MDPnP (Goldman) prototyped/demonstrated FHIR-based interfaces. DoF support two types of transactions: A “complete” FHIR transaction Bundle that contains all the information supporting the reported measurement. By “complete” it is meant that the bundle has all the information content related to the measurement; no references to data outside of the bundle is required (IHE International, 2019). A “discrete” data transaction or RESTFul FHIR transaction, used to place data on a RESTFul FHIR server for consumption by a Content Consumer (IHE International, 2019). These transactions contain time stamped data from the remote PHD, such as device identification data, data related to the settings and calibration of the device, and the sensor data itself over at least one of several local transport options (IHE International, 2019). The new Draft IHE FHIR Observation Upload (IHEFOU) Profile is a set of standardized means to transmit measurements obtained by PHDs in a remote setting, including home care, subacute therapy devices, and wearable technologies (IHE-PCD, 2019). This profile is, for all practical purposes, an expression of the already existing set of Continua Design Guideline standards (https://www.pchalliance. org/continua-design-guidelines) and interfaces defined by Personal Connected Health Alliance (PCHA) for exchange of remote patient data from PHDs (IHE-PCD, 2019). The FOU Profile uses transport of data content based on IEEE 11073 terminologies (IHE Technical Framework—Volume 3: Semantic Content, 2018). The typical technology used to support remote patient monitoring includes one or more of the following (IHEPCD, 2019): ●
●
●
●
“A Personal Health Device (PHD) which produces various health-related measurements through different kinds of sensors, and A collector that gathers data from one or more PHDs and forwards the information to a health information exchange or directly to the healthcare provider’s electronic health record or care management system, and/or The health information exchange that makes the data accessible to healthcare providers such as the physician or care coordinator, and An electronic health record or care management system that provides healthcare providers or coordinators with access to the patient’s health record and monitoring data.”
614 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
PHDs such as weight scale, SpO2 sensors, blood pressure cuffs, etc., connect to a data collector using a variety of networking protocols, such as Bluetooth®, ZigBee®, and USB. PHDs tend to use embedded systems to handle data communication and have limited capabilities (they may not be able to keep track of the date and time) (IHE-PCD, 2019). Collectors are applications built into local area network, or a mobile device such as a cellphone, tablet, or personal computer. These applications collect data from one or more PHDs and send them to the healthcare provider either directly or via a HIE (IHE-PCD, 2019). The IHE-FOU Profile allows standardization of device observations and transactions, which ensure plug and play operation for each component participating in the FOU. This allows for seamless integration from the sensor device (Sensor Data Source) used by the Patient to the EHR document reader used by the Physician (IHE-PCD, 2019). Fig. 2 taken from IHE-PCD (2019), shows the end-to-end implementation for the FOU. The figure also indicates a “workflow” though all the stages of the FOU. The Content Creator generates a FHIR resources and makes that Content available to a Content Consumer. The Device Observation Reporter generates a complete FHIR Bundle from the PCHA data. The Device Observation Consumer receives the complete FHIR Bundle from the Device Observation Reporter. In the FOU, the Device Observation Consumer is typically grouped with a Content Creator Actor that creates FHIR resource content from the complete FHIR Bundle data. The Sensor Data Consumer receives the data from the sensor device. The data is a ugmented
FIG. 2 FOU end-to-end “flow” diagram. (Taken from IHE-PCD, 2019.)
with personal information and any timing issues are corrected and coordinated. The data is subsequently forwarded to the healthcare provider. In this profile, the Sensor Data Consumer must be grouped with either a Device Observation Reporter or Content Creator Actor to handle the forwarding of the information (IHE International, 2019). PHD sensors typically can be used by multiple patients (e.g., a weight scale), and so the Sensor Data Consumer may need to distinguish which patient the device is currently measuring. Sensors may not keep track of time and date when sending data in real time, so the Sensor Data Consumer must time stamp the measurements (IHE International, 2019). The Content Creator Actor formats sensor data as FHIR resources and transmits to a FHIR server as specified by Continua Design Guideline (IHE International, 2019).
FHIR is NOT solely for devices, nor does it replace IHE profiles or ISO/IEEE 11073-x standards It is important to mention that HL7’s FHIR standards are being designed, tested, validated, and implemented for all aspects of medical recordkeeping, reporting, and analysis. That is, DoF is simply one important branch of FHIR standards development and implementation life cycle. Other large initiatives are under way to ensure that FHIR standards can appropriately handle multimedia objects like X-ray, pathology, and 3D modeling. Still other FHIR initiatives are focusing on HIE applications, which tackle the problem of
Application of HL7 FHIR® Chapter | 85 615
sending and receiving data across departmental, enterprise, state, regional, national, and international boundaries (e.g., dealing with international date line, time zone, language, and medication/clinical variations, nomenclatures, and regulations.) The IEEE 11073.x semantic interoperability standards were designed to align physiologic data measurements/observations across a wide range of manufacturers and devices/modalities. https://ieeexplore.ieee.org/document/1389298. Regardless of data communication architecture or resources, one still needs to reliably identify, for example, a pulse oximetry or blood pressure value and the units of measurement, which IEEE 11073.x standards were designed to address. Further, in order to bridge various vendors’ localized or proprietary nomenclatures for “meta” variables such as Average Heart Rate, an IHE Rosetta Terminology Management Project has emerged to organize such information https://wiki.ihe.net/index.php/ PCD_Profile_Rosetta_Terminology_Mapping_Overview. Also FHIR does not replace IHE Profiles, because those profiles address many additional critical business- and mission- critical health information system requirements such as time synchronization, patient identification, and clinical workflow planning, tracking, and management. Where appropriate, many well-proven existing IHE profiles that are currently based on HL7 v2 and v3 are being revised to also support FHIR-based HIE. On the devices front, it is also worth noting that over the past 20 years the range of medical device applications has expanded dramatically. After World War II, medical device innovations led to the modern ED, ICU, and OR where large numbers of medical devices can be found at many patient bedsides. Beginning in the 1990s, some of these same devices began to be sent home with patients in order to better support chronic disease care. Since the mid-to-late 2000s, rapid innovations of smart phones, apps, wearable sensors, and broadband wireless and cloud communication and resources, combined with plunging product prices, have inspired a dramatic growth in PHDs that can be worn, and/ or Software as a Medical Device instances that are primarily app based. Most recently, “smart” systems that use AI, ML, or other methods to automate repetitive healthcare tasks (think self-driving cars) have opened a gateway and market for new, high-acuity medical devices that can interoperate safely and reliably. All of these device innovations are expected to deploy and leverage the FHIR standards (IHE SPDi, 2019). HL7, IHE, and many government and industry groups are working together to assure that emerging next- generation FHIR-based health information solutions allow ever-greater technical convergence, health information
system interoperability, and more efficient, effective, affordable, accessible, and safe clinical care.
Conclusion Connected medical devices are benefitting the medical field at an unprecedented rate. Connected devices, however, have not entirely lived up to their potential. A major limitation is the need of interoperability standards that permit technological solutions to enhance care and bring the profession into a truly patient-cared and value-based system. In the United States, the interoperability goals set by the 21st Century Cures Act and implemented through the “Trusted Exchange Framework and Common Agreement” (TEFCA) is expected to regulate the exchange of healthcare information nationwide. The adoption of FHIR as interoperability standard should accelerate the innovation and development of medical products and advances and bring them to the public effectively. This should eliminate or significantly reduce malpractice claims resulting from a deficiency in handing off device observations, both by providers and patients. DoF have the potential of becoming the interoperable solution that health care needs!
References FHIR Release 4, 2018. Using Resources With Services and Serviceoriented Architecture. Retrieved from HL7.org, https://www.hl7.org/ fhir/services.html. IHE International, 2019. Technical Framework Supplement, FHIR Observation Upload (FOU), Public Comment Draft (Sept, 2019). IHE, Oak Brook, IL. IHE USA, 2018. Devices on FHIR. Retrieved from IHE USA, https:// www.iheusa.org/devices-fhir.
Additional references and text ANSI HITSP IS 77—Remote Monitoring (RMON) Interoperability Specification, 2008, http://hitsp.org/ConstructSet_Details.aspx?&Pre fixAlpha=1&PrefixNumeric=77. (Accessed 13 October 2019). ANSI HITSP Technical Note TN 905—Device Connectivity, 2010, http:// hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=5&PrefixNumer ic=905. (Accessed 13 October 2019). HL7, 2018. FHIR Point of Care Device (PoCD) Implementation Guide. Last Accessed 9/11/2019, http://build.fhir.org/ig/devices-on-fhir/PoCD-IG/. HL7, 2019. FHIR Personal Health Device (PHD) Implementation Guide. Last Accessed 9/12/19, http://build.fhir.org/ig/HL7/PHD/. IHE-PCD, 2019. IHE Patient Care Device Domain Profiles. Last Accessed 9/11/2019, https://wiki.ihe.net/index.php/Profiles#IHE_ Patient_Care_Device_Profiles. IHE SPDi, 2019. Service-Oriented Device Point-of-Care Interoperability (SDPi) White Paper w/FHIR References. Last Accessed 9/11/2019, https://wiki.ihe.net/index.php/SDC@IHE_White_Paper.
Application of HL7® FHIR for device and health information system interoperability Ricardo J. Silvaa,b, Elliot B. Sloaneb,c, Todd Cooperd a
Foundation for Living, Wellness, and Health, Orlando, FL, United States, bComputing Sciences, Villanova University, Villanova, PA, United States, cFoundation for Living, Wellness, and Health, Osprey, FL, United States, dTrue Health Trust, San Diego, CA, United States
What is “Devices on FHIR (DoF)®”? “Devices on FHIR (Fast Healthcare Interoperability Resources) (DoF)” is a collaborative effort that unites activities underway in HL7, Continua, IHE USA, and Integrating the Healthcare Enterprise (IHE) International (www.IHE.net, www.IHEUSA.org, www.HL7.org, www.PCHAlliance.org) (IHE USA, 2018). DoF is intended to ensure semantically consistent device information exchange whether achieved using current IHE Patient Care Devices (IHE-PCD) HL7 Version 2-based messaging or new, emerging IHE-PCD, and Continua® integration profiles that embrace the HL7 FHIR®-based resources and profiles. HL7 FHIR (https://www.hl7.org/fhir/) is a standard that defines resources, including content definitions, architectural models, and health information exchange (HIE) paradigms. The FHIR standard uses web-based technologies (e.g., HTTP or XML) to exchange standardized device data (HL7, 2018; HL7 2019; IHE USA, 2018; IHE International, 2019). FHIR® (https://www.hl7.org/fhir/)—is a next generation standards framework created by HL7. FHIR combines the best features of HL7s v2, HL7 v3, and Clinical Document Architecture (CDA) standards families while leveraging the latest web standards and applying a tight focus on implementability. Briefly, HL7 v2 relies on very carefully defined purpose- specific text-based messages with “fixed field” data, in which data elements like date, time, or physiologic parameters like systolic blood pressure are assigned very rigid-field locations and content specifications in a stream of data. By contrast, HL7 v3 and CDA rely on a foundational reference information model (RIM) and very precisely structured XML data definitions, which include hierarchical structures Clinical Engineering Handbook. https://doi.org/10.1016/B978-0-12-813467-2.00086-9 Copyright © 2020 Elsevier Inc. All rights reserved.
plus explicit beginning and end “tags” of the form
612 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
conventions. FHIR is built on the foundation established by HL7 V2 and V3, but keeps the complex details “under the hood.” The receiving device or software does not need a priori knowledge of the content or structure, because the sending device includes the necessary instructions to unpack the contents. Granularity is important for lightweight devices and applications. That is, for a home-bound elder patient with chronic heart disease, e.g., a home care aid probably only wants the latest blood pressure, or the highest and lowest blood pressures in the past 3 h. The nurse does NOT need or want a flood of all blood pressure readings for the past week! Therefore my application can request a specific granular quantity of data, and if the device or system has such data, it will be sent back along with instructions on decoding. FHIR was designed to be suitable for use in a wide variety of contexts—mobile phone apps, cloud communications, electronic health record (EHR)-based data sharing, server communication in large institutional healthcare providers, and much more. According to HL7, the current FHIR Release 4 (R4) of this standard is the first “normative” version that includes core content that is now frozen, enabling increased product use without the fear of major
FIG. 1 Structure of an HL7 FHIR “patient” resource.
changes in the underlying specifications. R4 is undergoing thorough ongoing testing and validation for connecting medical devices to each other and EHR systems. Devices from hospitals (e.g., physiological monitors or infusion pumps) and PCDs (e.g., thermometer, weight scale, pulse oximeter or ECG monitor) are also a part of the DoF effort.
How does FHIR® work? FHIR solutions are built from a set of modular components called “Resources” (Fig. 1). These resources can easily be assembled into working systems that solve real-world clinical and administrative problems at a fraction of the price of existing alternatives. “Resources” are ● ● ● ● ●
small logically discrete units of exchange define behavior and meaning known identity/location smallest unit of transaction “of interest” to health care V2: Sort of like Segments. V3: Sort of like CMETs.
Application of HL7 FHIR® Chapter | 85 613
FHIR supports four interoperability paradigms: REST, Documents, Messages, and Services (see also “First Time Here” section of: www.HL7.org/FHIR): ●
●
●
●
REST is a simple, out-of-the-box interoperability solution that leverages HTTP: GET, POST, etc. Using predefined operations such as Create, Read, Update, Delete, History, Read Version, Search, Updates, Validate, Conformance, and Batch. The RESTful interface comes from years of use in APIs from tech companies like Google, Twitter, and Facebook, and now is finally in health care. Documents are bundles similar to HL7 v3 CDA. The biggest difference is that atomic data access provided by FHIR, meaning that instead of transmitting and parsing a huge file composed of all records of a patient’s life, you can make a specific request for a specific observation and get that only. Documents are a collection of resources bound together. Root is a “Composition” resource, just like CDA header. Documents can be signed, authenticated, etc. Messages are similar to HL7 v2 and v3 messaging. It can also be also a collection of resources as a Bundle. This specification assumes that content will be delivered from one application to another by some mechanism, and that one or more responses will be returned to the source application. It is event-driven allowing request/response behavior with bundles and can be asynchronous, for example, Send lab order, get back result. Services are cohesive sets of functions that maintain responsibility for both data and “state” for the scope of their responsibility. Service-oriented architecture (SOA) is an architecture pattern using services to encapsulate and provide discrete pieces of application functionality to each other. Services communicate by invoking public interfaces and exchanging information (as parameters and outputs) in accordance with a well-defined service contract (FHIR Release 4, 2018).
Devices on FHIR Today, devices use hundreds of proprietary or “semi- standard” protocols. For example, the ISO/IEEE 11073 family of standards is intended to enable vendor-agnostic semantic interoperability point-of-care medical device communication. Each ISO/IEEE 11073-x standard specifies the structure of medical information objects. This standard also defines an abstract communication model to support the exchange of medical information objects. FHIR has been proposed to become a more modern, mobile-friendly, and agile common interoperable architectural base aligned with the ISO/IEEE 11073 semantic content specifications (terminology and information model).
The evolution of DoF has been the following: HL7 healthcare devices (WG) started a project to support device informatics in FHIR. Later IHE-PCDs published a white paper to investigate how FHIR might be used and created a few FHIR profiles (MHD & mACM). NIST has supported FHIR-based conformity testing, and Continua Health Alliance started to work on FHIR support for PHDs. Regarding implementation, OR.net/OpenSDC created— WS* for FHIR prototypes, and MDPnP (Goldman) prototyped/demonstrated FHIR-based interfaces. DoF support two types of transactions: A “complete” FHIR transaction Bundle that contains all the information supporting the reported measurement. By “complete” it is meant that the bundle has all the information content related to the measurement; no references to data outside of the bundle is required (IHE International, 2019). A “discrete” data transaction or RESTFul FHIR transaction, used to place data on a RESTFul FHIR server for consumption by a Content Consumer (IHE International, 2019). These transactions contain time stamped data from the remote PHD, such as device identification data, data related to the settings and calibration of the device, and the sensor data itself over at least one of several local transport options (IHE International, 2019). The new Draft IHE FHIR Observation Upload (IHEFOU) Profile is a set of standardized means to transmit measurements obtained by PHDs in a remote setting, including home care, subacute therapy devices, and wearable technologies (IHE-PCD, 2019). This profile is, for all practical purposes, an expression of the already existing set of Continua Design Guideline standards (https://www.pchalliance. org/continua-design-guidelines) and interfaces defined by Personal Connected Health Alliance (PCHA) for exchange of remote patient data from PHDs (IHE-PCD, 2019). The FOU Profile uses transport of data content based on IEEE 11073 terminologies (IHE Technical Framework—Volume 3: Semantic Content, 2018). The typical technology used to support remote patient monitoring includes one or more of the following (IHEPCD, 2019): ●
●
●
●
“A Personal Health Device (PHD) which produces various health-related measurements through different kinds of sensors, and A collector that gathers data from one or more PHDs and forwards the information to a health information exchange or directly to the healthcare provider’s electronic health record or care management system, and/or The health information exchange that makes the data accessible to healthcare providers such as the physician or care coordinator, and An electronic health record or care management system that provides healthcare providers or coordinators with access to the patient’s health record and monitoring data.”
614 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
PHDs such as weight scale, SpO2 sensors, blood pressure cuffs, etc., connect to a data collector using a variety of networking protocols, such as Bluetooth®, ZigBee®, and USB. PHDs tend to use embedded systems to handle data communication and have limited capabilities (they may not be able to keep track of the date and time) (IHE-PCD, 2019). Collectors are applications built into local area network, or a mobile device such as a cellphone, tablet, or personal computer. These applications collect data from one or more PHDs and send them to the healthcare provider either directly or via a HIE (IHE-PCD, 2019). The IHE-FOU Profile allows standardization of device observations and transactions, which ensure plug and play operation for each component participating in the FOU. This allows for seamless integration from the sensor device (Sensor Data Source) used by the Patient to the EHR document reader used by the Physician (IHE-PCD, 2019). Fig. 2 taken from IHE-PCD (2019), shows the end-to-end implementation for the FOU. The figure also indicates a “workflow” though all the stages of the FOU. The Content Creator generates a FHIR resources and makes that Content available to a Content Consumer. The Device Observation Reporter generates a complete FHIR Bundle from the PCHA data. The Device Observation Consumer receives the complete FHIR Bundle from the Device Observation Reporter. In the FOU, the Device Observation Consumer is typically grouped with a Content Creator Actor that creates FHIR resource content from the complete FHIR Bundle data. The Sensor Data Consumer receives the data from the sensor device. The data is a ugmented
FIG. 2 FOU end-to-end “flow” diagram. (Taken from IHE-PCD, 2019.)
with personal information and any timing issues are corrected and coordinated. The data is subsequently forwarded to the healthcare provider. In this profile, the Sensor Data Consumer must be grouped with either a Device Observation Reporter or Content Creator Actor to handle the forwarding of the information (IHE International, 2019). PHD sensors typically can be used by multiple patients (e.g., a weight scale), and so the Sensor Data Consumer may need to distinguish which patient the device is currently measuring. Sensors may not keep track of time and date when sending data in real time, so the Sensor Data Consumer must time stamp the measurements (IHE International, 2019). The Content Creator Actor formats sensor data as FHIR resources and transmits to a FHIR server as specified by Continua Design Guideline (IHE International, 2019).
FHIR is NOT solely for devices, nor does it replace IHE profiles or ISO/IEEE 11073-x standards It is important to mention that HL7’s FHIR standards are being designed, tested, validated, and implemented for all aspects of medical recordkeeping, reporting, and analysis. That is, DoF is simply one important branch of FHIR standards development and implementation life cycle. Other large initiatives are under way to ensure that FHIR standards can appropriately handle multimedia objects like X-ray, pathology, and 3D modeling. Still other FHIR initiatives are focusing on HIE applications, which tackle the problem of
Application of HL7 FHIR® Chapter | 85 615
sending and receiving data across departmental, enterprise, state, regional, national, and international boundaries (e.g., dealing with international date line, time zone, language, and medication/clinical variations, nomenclatures, and regulations.) The IEEE 11073.x semantic interoperability standards were designed to align physiologic data measurements/observations across a wide range of manufacturers and devices/modalities. https://ieeexplore.ieee.org/document/1389298. Regardless of data communication architecture or resources, one still needs to reliably identify, for example, a pulse oximetry or blood pressure value and the units of measurement, which IEEE 11073.x standards were designed to address. Further, in order to bridge various vendors’ localized or proprietary nomenclatures for “meta” variables such as Average Heart Rate, an IHE Rosetta Terminology Management Project has emerged to organize such information https://wiki.ihe.net/index.php/ PCD_Profile_Rosetta_Terminology_Mapping_Overview. Also FHIR does not replace IHE Profiles, because those profiles address many additional critical business- and mission- critical health information system requirements such as time synchronization, patient identification, and clinical workflow planning, tracking, and management. Where appropriate, many well-proven existing IHE profiles that are currently based on HL7 v2 and v3 are being revised to also support FHIR-based HIE. On the devices front, it is also worth noting that over the past 20 years the range of medical device applications has expanded dramatically. After World War II, medical device innovations led to the modern ED, ICU, and OR where large numbers of medical devices can be found at many patient bedsides. Beginning in the 1990s, some of these same devices began to be sent home with patients in order to better support chronic disease care. Since the mid-to-late 2000s, rapid innovations of smart phones, apps, wearable sensors, and broadband wireless and cloud communication and resources, combined with plunging product prices, have inspired a dramatic growth in PHDs that can be worn, and/ or Software as a Medical Device instances that are primarily app based. Most recently, “smart” systems that use AI, ML, or other methods to automate repetitive healthcare tasks (think self-driving cars) have opened a gateway and market for new, high-acuity medical devices that can interoperate safely and reliably. All of these device innovations are expected to deploy and leverage the FHIR standards (IHE SPDi, 2019). HL7, IHE, and many government and industry groups are working together to assure that emerging next- generation FHIR-based health information solutions allow ever-greater technical convergence, health information
system interoperability, and more efficient, effective, affordable, accessible, and safe clinical care.
Conclusion Connected medical devices are benefitting the medical field at an unprecedented rate. Connected devices, however, have not entirely lived up to their potential. A major limitation is the need of interoperability standards that permit technological solutions to enhance care and bring the profession into a truly patient-cared and value-based system. In the United States, the interoperability goals set by the 21st Century Cures Act and implemented through the “Trusted Exchange Framework and Common Agreement” (TEFCA) is expected to regulate the exchange of healthcare information nationwide. The adoption of FHIR as interoperability standard should accelerate the innovation and development of medical products and advances and bring them to the public effectively. This should eliminate or significantly reduce malpractice claims resulting from a deficiency in handing off device observations, both by providers and patients. DoF have the potential of becoming the interoperable solution that health care needs!
References FHIR Release 4, 2018. Using Resources With Services and Serviceoriented Architecture. Retrieved from HL7.org, https://www.hl7.org/ fhir/services.html. IHE International, 2019. Technical Framework Supplement, FHIR Observation Upload (FOU), Public Comment Draft (Sept, 2019). IHE, Oak Brook, IL. IHE USA, 2018. Devices on FHIR. Retrieved from IHE USA, https:// www.iheusa.org/devices-fhir.
Additional references and text ANSI HITSP IS 77—Remote Monitoring (RMON) Interoperability Specification, 2008, http://hitsp.org/ConstructSet_Details.aspx?&Pre fixAlpha=1&PrefixNumeric=77. (Accessed 13 October 2019). ANSI HITSP Technical Note TN 905—Device Connectivity, 2010, http:// hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=5&PrefixNumer ic=905. (Accessed 13 October 2019). HL7, 2018. FHIR Point of Care Device (PoCD) Implementation Guide. Last Accessed 9/11/2019, http://build.fhir.org/ig/devices-on-fhir/PoCD-IG/. HL7, 2019. FHIR Personal Health Device (PHD) Implementation Guide. Last Accessed 9/12/19, http://build.fhir.org/ig/HL7/PHD/. IHE-PCD, 2019. IHE Patient Care Device Domain Profiles. Last Accessed 9/11/2019, https://wiki.ihe.net/index.php/Profiles#IHE_ Patient_Care_Device_Profiles. IHE SPDi, 2019. Service-Oriented Device Point-of-Care Interoperability (SDPi) White Paper w/FHIR References. Last Accessed 9/11/2019, https://wiki.ihe.net/index.php/SDC@IHE_White_Paper.