Device Interoperability using SDPi+FHIR

What is "SDPi"?

IHE SDPi - Service-oriented Device Point-of-care Interoperability -  is a set of IHE profiles under development in the IHE Devices DPI (Device Point-of-care Interoperability) Program.  As summarized in the proposal slide deck below, they leverage the ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards that provide for SOA-based device-to-device plug-and-play interoperability at high acuity points of care (e.g., surgery, ICU or emergency).  The four IHE SDPi profiles in development map to four ISO/IEEE 11073 SDC  key interoperability purposes KIP) standards  tailored for medical technology:  Plug-and-play Connectivity (SDPi-P), Reporting (SDPi-R), Alerting (SDPi-A) & external Control (SDPi-xC).   Note that the IHE SDPi profiles include defined "gateway" actors for integrating an SDC-based environment with both HL7 V2 and FHIR connected environments.

Did you say "SDC"?!

CAUTION!  Don't go down the rabbit hole ...   Though in the health IT world "SDC" typically means Structured Data Capture, in the device informatics world it stands for Service-oriented Device Connectivity and specifically refers to a set of ISO/IEEE 11073 standards.  Parallel universes to be sure ... one community totally oblivious to the other communities use of the TLA "SDC."  

Why SDPi+FHIR?  

Why FHIR?

The HL7 Devices on FHIR (DoF) work began in the summer of 2016, building on work that had been pursued during the preceding years, has been a very active collaboration with  HIMSS/PCHAlliance "Continua" and IHE Devices, resulting in the development of two implementation guides (one for Point-of-Care Devices (PoCD) and one for Personal Health Devices (PHD)).  The DoF team is actively working to expand the IGs to support both device alerting, as well as device SDC inter-connection.  There is also consideration of a 3rd IG focused not on helping device technologists send granular device data using FHIR - which can quickly get very complicated even with PHDs - but on the applications community that wants to integrate device-sourced information.  All of this work is included in the initial set of projects identified below.

Why SDPi?

After arguably 40 years of various initiatives struggling to achieve plug-and-play medical device interoperability (PnP MDI), "from the device interface", the reality remains that devices support proprietary protocols to their gateway servers and all exchange is achieve with "my server will talk with your server" connectivity.  After 15 years of development, though, a core set of IEEE standards are in place, products coming to the market and used on high-acuity patients, and international recognition and interest is taking root.  Applying IHE's highly successful approach to developing, testing and showcasing standards-based technical solutions, to this challenging area of PnP MDI, using the proven ISO/IEEE 11073 SDC standards as a base, positions SDPi to finally achieve what has to date been an elusive dream.   

Note:  Review the IHE SDPi paper for more detailed background and rationale, as well as the Stacks of Useful Stuff for presentations, articles and other useful information.

Why joining SDPi+FHIR?

The Gemini program focus on "SDPi+FHIR" brings together two core specification areas, IHE's SDPi and HL7's FHIR, that can cover the three main use contexts:  High-acuity Point-of-Care, Healthcare enterprise, and home/mobile.   Yes, there may be other alternative standards and technical approaches, but much of this work is being actively pursued in the various organizations, by many of the same people but with ad hoc coordination and collaboration, a sub-optimal mix of tools, and with work artifacts spread across various locations using different formats.

The Gemini SDPi+FHIR objectives stated above can be pulling together the efforts described above under one simple, consolidated joint HL7-IHE program.

Is this limited to IHE and HL7, the Gemini initiative partners?

No, it includes active engagement of other standards groups including the IEEE 11073 standards community, ISO/TC 215 & IEC/SC 62A Joint Working Group 7 (JWG7) standards for safe, effective and secure medical device and health software.  That said, the primary focus of effort related to PnP MDI is in the IHE Devices and HL7 Devices groups.

SDPi+FHIR Narratives

See the IHE Compendium of Medical Device Oriented Use Cases that was developed in conjunction with the IHE SDPi Paper.   

The Gemini program proposal identified a starter set of use case narratives that together span the use contexts comprised by SDPi & FHIR:

1. Functional Endoscopic Sinus Surgery (FESS) / Operating Room Integration
   
   • SDC/SDPi's primary focus is to support PnP MDI ... device-to-device ... around a high-acuity point-of-care, including the operating room.  This FESS narrative includes not only the integration of traditional acute care devices (e.g., physiologic monitors, ventilators, anesthesia systems, infusion pumps) but also technology that is specialized for endoscopic surgery, as well as other environmental controls.  
   • Narrative includes integration with enterprise systems outside of the OR (e.g., EHR or PACS) that use FHIR-based exchange.
2. Quiet Hospital / Silent Bed
   
   • Focus is on addressing the well established challenges of clinician "alert fatigue" and the noise that pollutes the patient point-of-care environment
   • Includes consideration of 
   • IEEE 11073 SDC concept of "alert delegation" is considered - where a device can contract with another system to safely and securely manage its alert annunciation;  This is a crucial feature for achieving a "silent" point-of-care.
3. JHU/APL MDIRA/ICE for Military & Disaster Casualty Care
   
   • Focus is on a set of use cases that not only look at achieving medical device interoperability (MDI) but closed-loop apps, intelligent autonomous / semi-autonomous systems, and even medical robotics (e.g., autonomous intubation)
   • Based on the Johns Hopkins University / Applied Physics Lab (JHU/APL) Medical Device Interoperability Reference Architecture (MDIRA) project funded by the U.S. Defense Agency.
   • The reference architecture also leverages the Integrated Clinical Environment (ICE) conceptual model
   • Software as a Medical Device (SAMD) is also a key component of these use cases, especially in regard to integrating information from both networked devices as well as FHIR-based enterprise systems.
4. Preeclampsia During Pregnancy – Home to Clinic to Hospital
   
   • Focus is the monitoring and coordinated care of an expecting mother who has been diagnosed with preeclampsia (hypertension) 
   • Includes integration of devices and cloud-based technologies from inside a hospital, to a pregnancy care clinic to the mothers home; before, during and after delivery
   • In addition to devices, the narrative includes care coordination, decision support and other intelligent care system
5. “Loopers” Type 1 Diabetes – Person-crafted Closed-Loop Control 
   • Focus is on how to use SDPi+FHIR solutions to support closed loop control applications (e.g., on a mobile) to retrieve continuous glucose monitor (CGM) information and control an individual's insulin pump delivery
   • Today the components of this solution are "hacked" from open source solutions and devices by the Type 1 diabetic themselves
   • This is a perfect example of how technology that is purpose built for the hardest medical challenges in OR and ICU might be adapted for use by individuals in their own personal care

Note:  The above narratives encompass a set of component use cases that ultimately drive requirements specification and ultimately conformity assessment testing of interoperable systems.  

Standards Framework Models ... never enough!

The SDPi+FHIR project builds upon the multi-decades of work in various organizations.  Not only IHE and HL7, but IEEE, ISO, IEC and others.  Many of these efforts have developed frameworks or models to help the community (internal and external) understand how the various elements of the specifications relate to each other.  In the case of this project, a "Hanging Gardens" of Interoperability model has been crafted to organize the various standards "layers" that are being created or leveraged and integrated, but this model is closely aligned with those of other standards families, including the IEEE 11073 SDC "Cathedral" model and the ISO/IEC JWG7 SES "Temple" model.  Understanding these three models is ... time well spent!

A more detailed explanation is provided on the SDPi+FHIR Hanging Gardens Framework page.

SDPi+FHIR Projects

This Gemini program initiative includes a set of projects coordinated and in some cases jointly developed between the two organizations:

HL7 Devices on FHIR Implementation Guides

Build on the success of the Devices on FHIR IGs to add support for FHIR-based device alerting and IEEE 11073 SDC integration, and ensure tight integration with the IHE SDPi profile specifications. 

IHE DEV Technical Framework SDPi Supplement

Advance the development of the IHE SDPi supplement, prototype and test tooling, including definition of "gateway" actors for seamless integration with HL7 V2 and FHIR connections and IGs.  

Joint papers and technical reports:

“What is a device?” Report

“What is a device?” - including AI/ML SAMD, across use context geographies; intent is not to answer the question definitively but to examine how the term's meaning has changed over the last 10+ years and the various ways that it is being used within the health informatics community today.  This is especially the case with the rapid changes in technologies in recent years and the blurring of the traditional lines of demarcation such as medical (regulated) or non-medical, Point-of-Care Device (PoCD) or Personal Health Device (PHD), etc.  This is especially important now that both the IHE and HL7 work groups are simply labeled "Devices" - what does THAT mean?!

“Safe, Effective & Secure MDI Using SDC/SDPi + FHIR” Technical Report 

Examine how standards for establishing medical device and health software safety, effectiveness and security (SES), typically developed in ISO/IEC JWG7 (see above) might be applied to ISO/IEEE 11073 SDC, IHE SDPi and HL7 FHIR technologies to achieve SES solutions.  The primary target audiences are quality system experts, regulatory affairs stakeholders, and legal / liability managers.  This paper will not only provide direct guidance to the specifications developed within the SDPi+FHIR program, but will also make recommendations for standards for other organizations such as ISO/IEC JWG7.

"Accelerating Safe, Effective and Secure Remote Connected Care and Mobile Health Interoperable Solutions" Technical Report

Addressing the immediate and future needs and gaps exposed by the Pandemic focusing on: in-patient, outpatient, post-acute-care & patient home care scenarios.  This includes considerations not only of how to rapidly identify interoperable health technology solutions especially during times of crisis response, but how to answer the  questions "Is this safe enough?  Effective enough? and Secure enough?" and understand the potential risks / benefits for advancing innovative technologies to address pressing needs.   This paper will not only provide direct guidance to the specifications developed within the SDPi+FHIR program for the IHE and HL7 Devices work groups, but will also integrate discussions with other working groups such as HL7 Mobile Health, IHE ITI, and related work at ISO/TC 215 WG2 and ISO/IEC JWG7.

NOTE about project governance:  Each project in the Gemini SDPi+FHIR program will be jointly developed, but will also have a primary "home" in either IHE Devices or HL7 Devices.  The consensus standards processes will be determined based on that "home".  In some cases, projects will be be jointly governed (e.g., technical reports) and will then require coordination of formal project approvals, development processes, etc.  

SDPi+FHIR Development Support

Resources to supporting the development, adoption, implementation and use of SDPi+FHIR solutions include:

• Community  (including collaborative discussions, presentations, papers, etc.)
  • Meetings (logs and notes for weekly and other meetings)
• Stacks (collections of interesting stuff ... think Library piles way in the back)
• Tools (including open source, testing)
• Topics (subjects that have resulted in extended discussions that impact the SDPi+FHIR specifications, tooling, etc.)

SDPi+FHIR Documents

The following documents are of general interest to the overall program:

What is "SDPi"?

IHE SDPi - Service-oriented Device Point-of-care Interoperability -  is a set of IHE profiles under development in the IHE Devices DPI (Device Point-of-care Interoperability) Program.  As summarized in the proposal slide deck below, they leverage the ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards that provide for SOA-based device-to-device plug-and-play interoperability at high acuity points of care (e.g., surgery, ICU or emergency).  The four IHE SDPi profiles in development map to four ISO/IEEE 11073 SDC  key interoperability purposes KIP) standards  tailored for medical technology:  Plug-and-play Connectivity (SDPi-P), Reporting (SDPi-R), Alerting (SDPi-A) & external Control (SDPi-xC).   Note that the IHE SDPi profiles include defined "gateway" actors for integrating an SDC-based environment with both HL7 V2 and FHIR connected environments.

Did you say "SDC"?!

CAUTION!  Don't go down the rabbit hole ...   Though in the health IT world "SDC" typically means Structured Data Capture, in the device informatics world it stands for Service-oriented Device Connectivity and specifically refers to a set of ISO/IEEE 11073 standards.  Parallel universes to be sure ... one community totally oblivious to the other communities use of the TLA "SDC."  

Why SDPi+FHIR?  

Why FHIR?

The HL7 Devices on FHIR (DoF) work began in the summer of 2016, building on work that had been pursued during the preceding years, has been a very active collaboration with  HIMSS/PCHAlliance "Continua" and IHE Devices, resulting in the development of two implementation guides (one for Point-of-Care Devices (PoCD) and one for Personal Health Devices (PHD)).  The DoF team is actively working to expand the IGs to support both device alerting, as well as device SDC inter-connection.  There is also consideration of a 3rd IG focused not on helping device technologists send granular device data using FHIR - which can quickly get very complicated even with PHDs - but on the applications community that wants to integrate device-sourced information.  All of this work is included in the initial set of projects identified below.

Why SDPi?

After arguably 40 years of various initiatives struggling to achieve plug-and-play medical device interoperability (PnP MDI), "from the device interface", the reality remains that devices support proprietary protocols to their gateway servers and all exchange is achieve with "my server will talk with your server" connectivity.  After 15 years of development, though, a core set of IEEE standards are in place, products coming to the market and used on high-acuity patients, and international recognition and interest is taking root.  Applying IHE's highly successful approach to developing, testing and showcasing standards-based technical solutions, to this challenging area of PnP MDI, using the proven ISO/IEEE 11073 SDC standards as a base, positions SDPi to finally achieve what has to date been an elusive dream.   

Note:  Review the IHE SDPi paper for more detailed background and rationale, as well as the Stacks of Useful Stuff for presentations, articles and other useful information.

Why joining SDPi+FHIR?

The Gemini program focus on "SDPi+FHIR" brings together two core specification areas, IHE's SDPi and HL7's FHIR, that can cover the three main use contexts:  High-acuity Point-of-Care, Healthcare enterprise, and home/mobile.   Yes, there may be other alternative standards and technical approaches, but much of this work is being actively pursued in the various organizations, by many of the same people but with ad hoc coordination and collaboration, a sub-optimal mix of tools, and with work artifacts spread across various locations using different formats.

The Gemini SDPi+FHIR objectives stated above can be pulling together the efforts described above under one simple, consolidated joint HL7-IHE program.

Is this limited to IHE and HL7, the Gemini initiative partners?

No, it includes active engagement of other standards groups including the IEEE 11073 standards community, ISO/TC 215 & IEC/SC 62A Joint Working Group 7 (JWG7) standards for safe, effective and secure medical device and health software.  That said, the primary focus of effort related to PnP MDI is in the IHE Devices and HL7 Devices groups.

SDPi+FHIR Narratives

See the IHE Compendium of Medical Device Oriented Use Cases that was developed in conjunction with the IHE SDPi Paper.   

The Gemini program proposal identified a starter set of use case narratives that together span the use contexts comprised by SDPi & FHIR:

1. Functional Endoscopic Sinus Surgery (FESS) / Operating Room Integration
   
   • SDC/SDPi's primary focus is to support PnP MDI ... device-to-device ... around a high-acuity point-of-care, including the operating room.  This FESS narrative includes not only the integration of traditional acute care devices (e.g., physiologic monitors, ventilators, anesthesia systems, infusion pumps) but also technology that is specialized for endoscopic surgery, as well as other environmental controls.  
   • Narrative includes integration with enterprise systems outside of the OR (e.g., EHR or PACS) that use FHIR-based exchange.
2. Quiet Hospital / Silent Bed
   
   • Focus is on addressing the well established challenges of clinician "alert fatigue" and the noise that pollutes the patient point-of-care environment
   • Includes consideration of 
   • IEEE 11073 SDC concept of "alert delegation" is considered - where a device can contract with another system to safely and securely manage its alert annunciation;  This is a crucial feature for achieving a "silent" point-of-care.
3. JHU/APL MDIRA/ICE for Military & Disaster Casualty Care
   
   • Focus is on a set of use cases that not only look at achieving medical device interoperability (MDI) but closed-loop apps, intelligent autonomous / semi-autonomous systems, and even medical robotics (e.g., autonomous intubation)
   • Based on the Johns Hopkins University / Applied Physics Lab (JHU/APL) Medical Device Interoperability Reference Architecture (MDIRA) project funded by the U.S. Defense Agency.
   • The reference architecture also leverages the Integrated Clinical Environment (ICE) conceptual model
   • Software as a Medical Device (SAMD) is also a key component of these use cases, especially in regard to integrating information from both networked devices as well as FHIR-based enterprise systems.
4. Preeclampsia During Pregnancy – Home to Clinic to Hospital
   
   • Focus is the monitoring and coordinated care of an expecting mother who has been diagnosed with preeclampsia (hypertension) 
   • Includes integration of devices and cloud-based technologies from inside a hospital, to a pregnancy care clinic to the mothers home; before, during and after delivery
   • In addition to devices, the narrative includes care coordination, decision support and other intelligent care system
5. “Loopers” Type 1 Diabetes – Person-crafted Closed-Loop Control 
   • Focus is on how to use SDPi+FHIR solutions to support closed loop control applications (e.g., on a mobile) to retrieve continuous glucose monitor (CGM) information and control an individual's insulin pump delivery
   • Today the components of this solution are "hacked" from open source solutions and devices by the Type 1 diabetic themselves
   • This is a perfect example of how technology that is purpose built for the hardest medical challenges in OR and ICU might be adapted for use by individuals in their own personal care

Note:  The above narratives encompass a set of component use cases that ultimately drive requirements specification and ultimately conformity assessment testing of interoperable systems.  

Standards Framework Models ... never enough!

The SDPi+FHIR project builds upon the multi-decades of work in various organizations.  Not only IHE and HL7, but IEEE, ISO, IEC and others.  Many of these efforts have developed frameworks or models to help the community (internal and external) understand how the various elements of the specifications relate to each other.  In the case of this project, a "Hanging Gardens" of Interoperability model has been crafted to organize the various standards "layers" that are being created or leveraged and integrated, but this model is closely aligned with those of other standards families, including the IEEE 11073 SDC "Cathedral" model and the ISO/IEC JWG7 SES "Temple" model.  Understanding these three models is ... time well spent!

A more detailed explanation is provided on the SDPi+FHIR Hanging Gardens Framework page.

SDPi+FHIR Projects

This Gemini program initiative includes a set of projects coordinated and in some cases jointly developed between the two organizations:

HL7 Devices on FHIR Implementation Guides

Build on the success of the Devices on FHIR IGs to add support for FHIR-based device alerting and IEEE 11073 SDC integration, and ensure tight integration with the IHE SDPi profile specifications. 

IHE DEV Technical Framework SDPi Supplement

Advance the development of the IHE SDPi supplement, prototype and test tooling, including definition of "gateway" actors for seamless integration with HL7 V2 and FHIR connections and IGs.  

Joint papers and technical reports:

“What is a device?” Report

“What is a device?” - including AI/ML SAMD, across use context geographies; intent is not to answer the question definitively but to examine how the term's meaning has changed over the last 10+ years and the various ways that it is being used within the health informatics community today.  This is especially the case with the rapid changes in technologies in recent years and the blurring of the traditional lines of demarcation such as medical (regulated) or non-medical, Point-of-Care Device (PoCD) or Personal Health Device (PHD), etc.  This is especially important now that both the IHE and HL7 work groups are simply labeled "Devices" - what does THAT mean?!

“Safe, Effective & Secure MDI Using SDC/SDPi + FHIR” Technical Report 

Examine how standards for establishing medical device and health software safety, effectiveness and security (SES), typically developed in ISO/IEC JWG7 (see above) might be applied to ISO/IEEE 11073 SDC, IHE SDPi and HL7 FHIR technologies to achieve SES solutions.  The primary target audiences are quality system experts, regulatory affairs stakeholders, and legal / liability managers.  This paper will not only provide direct guidance to the specifications developed within the SDPi+FHIR program, but will also make recommendations for standards for other organizations such as ISO/IEC JWG7.

"Accelerating Safe, Effective and Secure Remote Connected Care and Mobile Health Interoperable Solutions" Technical Report

Addressing the immediate and future needs and gaps exposed by the Pandemic focusing on: in-patient, outpatient, post-acute-care & patient home care scenarios.  This includes considerations not only of how to rapidly identify interoperable health technology solutions especially during times of crisis response, but how to answer the  questions "Is this safe enough?  Effective enough? and Secure enough?" and understand the potential risks / benefits for advancing innovative technologies to address pressing needs.   This paper will not only provide direct guidance to the specifications developed within the SDPi+FHIR program for the IHE and HL7 Devices work groups, but will also integrate discussions with other working groups such as HL7 Mobile Health, IHE ITI, and related work at ISO/TC 215 WG2 and ISO/IEC JWG7.

NOTE about project governance:  Each project in the Gemini SDPi+FHIR program will be jointly developed, but will also have a primary "home" in either IHE Devices or HL7 Devices.  The consensus standards processes will be determined based on that "home".  In some cases, projects will be be jointly governed (e.g., technical reports) and will then require coordination of formal project approvals, development processes, etc.  

SDPi+FHIR Development Support

Resources to supporting the development, adoption, implementation and use of SDPi+FHIR solutions include:

• Community  (including collaborative discussions, presentations, papers, etc.)
  • Meetings (logs and notes for weekly and other meetings)
• Stacks (collections of interesting stuff ... think Library piles way in the back)
• Tools (including open source, testing)
• Topics (subjects that have resulted in extended discussions that impact the SDPi+FHIR specifications, tooling, etc.)

SDPi+FHIR Documents

The following documents are of general interest to the overall program: