Difference between revisions of "Direct-to-Cloud-Constrained Devices - Detailed Proposal"
| (7 intermediate revisions by 2 users not shown) | |||
| Line 9: | Line 9: | ||
===Summary=== | ===Summary=== | ||
| − | + | To simplify and improve the remote patient monitoring user experience, it is desirable to enable medical sensor to communicate directly to a health server in the cloud. The use of a gateway device is not practical in many scenarios. | |
The D2C solution leverages to the maximum extend practical existing industry standards covering cellular Internet of Things communications, IEEE Personal Health Devices, FHIR and transport security. Uniform implementation of these standards are essential to achieve interoperability. | The D2C solution leverages to the maximum extend practical existing industry standards covering cellular Internet of Things communications, IEEE Personal Health Devices, FHIR and transport security. Uniform implementation of these standards are essential to achieve interoperability. | ||
| + | |||
A simplified protocol is required to accommodate the compute and power limitations of such sensors. It is envisioned that the actors defined in the POU profile would be employed. However, the transactions would be materially different and therefore warrant a separate Implementation Guide. | A simplified protocol is required to accommodate the compute and power limitations of such sensors. It is envisioned that the actors defined in the POU profile would be employed. However, the transactions would be materially different and therefore warrant a separate Implementation Guide. | ||
| + | |||
The COVID-19 pandemic has been the global defining event that has thrust remote patient monitoring into the minds of mainstream users. This IG will enable a collection of companies large and small from all corners of the globe to bring to market the billions of devices that must communicate universally understood health data critical to treating patients of pandemics. | The COVID-19 pandemic has been the global defining event that has thrust remote patient monitoring into the minds of mainstream users. This IG will enable a collection of companies large and small from all corners of the globe to bring to market the billions of devices that must communicate universally understood health data critical to treating patients of pandemics. | ||
IHE Devices Domain expertise is uniquely suited to guide medical device manufacturers and Healthcare & Life Sciences software vendors leverage Patient Generated Health Data that is provided directly from a health sensor to health information system via cellular Internet of Things where WiFi may not be available. | IHE Devices Domain expertise is uniquely suited to guide medical device manufacturers and Healthcare & Life Sciences software vendors leverage Patient Generated Health Data that is provided directly from a health sensor to health information system via cellular Internet of Things where WiFi may not be available. | ||
| − | |||
==2. The Problem== | ==2. The Problem== | ||
| − | + | With WiFi and Bluetooth connectivity the end-user is either restricted to transferring data wherever a hub is located, or would need to carry a hub device wherever they go. Furthermore, pairing and configuration is an additional obstacle. It is desired that medical sensors are small and long-life battery powered - which puts “constraints” on their communication capability, requiring the data communicated to be lightweight to reduce on-time of the device. Therefore it is desired to define a lightweight approach for secure direct data transfer from such a constrained device to cloud. | |
==3. Key Use Case== | ==3. Key Use Case== | ||
| Line 38: | Line 39: | ||
Healthcare Interoperability Standards | Healthcare Interoperability Standards | ||
| − | IEEE 11073-10206 | + | IEEE 11073-10206 - Health informatics -- Device interoperability -- Personal health device communication -- Abstract information content model. It is intended to use the information model in this standard as a basis for defining a communication protocol to transfer the healthcare device data extracted from that information model from DOR to DOC. |
HL7 FHIR: FHIR stands for Fast Healthcare Interoperability Resources. Developed by Health Level Seven International (commonly known as HL7), it's an interoperability specification for the exchange of healthcare information electronically. It is intended for the DOC to translate received healthcare device data into a FHIR Resource. | HL7 FHIR: FHIR stands for Fast Healthcare Interoperability Resources. Developed by Health Level Seven International (commonly known as HL7), it's an interoperability specification for the exchange of healthcare information electronically. It is intended for the DOC to translate received healthcare device data into a FHIR Resource. | ||
| Line 57: | Line 58: | ||
Device Observation Reporter: The Device Observation Reporter is an actor that reports PHD Data (sensor device observations) to a Device Observation Consumer. | Device Observation Reporter: The Device Observation Reporter is an actor that reports PHD Data (sensor device observations) to a Device Observation Consumer. | ||
| − | Device Observation Consumer: The Device Observation Consumer is an actor that receives PHD Data (sensor device observations) from a Device Observation | + | Device Observation Consumer: The Device Observation Consumer is an actor that receives PHD Data (sensor device observations) from a Device Observation Reporter. |
Transactions [(IHE ITI2) – see section 9 of the POU profile doc.] | Transactions [(IHE ITI2) – see section 9 of the POU profile doc.] | ||
| Line 64: | Line 65: | ||
Profile | Profile | ||
| + | |||
The main aspects that need to be defined are: | The main aspects that need to be defined are: | ||
| − | The relationship with the existing Continua Reference Architecture | + | The relationship with the existing Continua Reference Architecture. |
The requirements for provisioning the personal health device Device Observation Reporter (DOR). | The requirements for provisioning the personal health device Device Observation Reporter (DOR). | ||
The referencing of 11073-10206, and specific requirements for communication of the 10206 Resource Model information from DOR to DOC using a direct-to-cloud topology. | The referencing of 11073-10206, and specific requirements for communication of the 10206 Resource Model information from DOR to DOC using a direct-to-cloud topology. | ||
The definition of the underlying transport protocol stack for performing the transaction between Device Observation Reporter (PHD) and Device Observation Consumer (HFS), including the standards that shall be used within that protocol stack, and any specific requirements on usage of specific options within those standards. | The definition of the underlying transport protocol stack for performing the transaction between Device Observation Reporter (PHD) and Device Observation Consumer (HFS), including the standards that shall be used within that protocol stack, and any specific requirements on usage of specific options within those standards. | ||
| − | A new protocol layer for encapsulating 11073 data into underlying protocols, and adding a unique device identity. | + | A new protocol layer for encapsulating 11073-10206 data into underlying protocols, and adding a unique device identity. |
Decisions/Topics/Uncertainties | Decisions/Topics/Uncertainties | ||
| + | |||
Analysis and decision on the type of communication method required to minimise battery consumption of the Device Observation Reporter (catering for the constrained device requirement). | Analysis and decision on the type of communication method required to minimise battery consumption of the Device Observation Reporter (catering for the constrained device requirement). | ||
Includes analysis of the problem with using FHIR directly. | Includes analysis of the problem with using FHIR directly. | ||
| Line 80: | Line 83: | ||
==6. Support & Resources== | ==6. Support & Resources== | ||
| − | + | ||
| + | Support and resources that will help drive the success of this project include members of the PCHAlliance, IHE USA and IHE International, HIMSS, IEEE, FDA, ONC, HL7 FHIR and the general telehealth and remote patient monitoring industries and health communities. | ||
==7. Risks== | ==7. Risks== | ||
| − | + | ||
| + | Critical to the adoption of this proposed IG is to clearly articulate to key stakeholders how remote patient monitoring solves real-world challenges in a very practical sense. | ||
In the age of surveillance capitalism, it may be even more challenging to convince vendors to employ open standards-based solutions essential to interoperability. | In the age of surveillance capitalism, it may be even more challenging to convince vendors to employ open standards-based solutions essential to interoperability. | ||
Although beyond the scope of IHE, streamlining regulatory approvals across multiple markets will be important as sensor hardware has become commoditized. | Although beyond the scope of IHE, streamlining regulatory approvals across multiple markets will be important as sensor hardware has become commoditized. | ||
| Line 90: | Line 95: | ||
Level of adoption due to potential preference from device vendor stakeholders in single vendor e2e solutions, and/or preference for using their own proprietary protocols. | Level of adoption due to potential preference from device vendor stakeholders in single vendor e2e solutions, and/or preference for using their own proprietary protocols. | ||
Other potential competing solutions being developed by other industry players outside of IHE. | Other potential competing solutions being developed by other industry players outside of IHE. | ||
| − | |||
==8. Tech Cmte Evaluation== | ==8. Tech Cmte Evaluation== | ||
Latest revision as of 06:19, 1 December 2020
1. Proposed Work Item: Direct-to-Cloud-Constrained Devices
- Proposal Editor: Michael J. Kirwan
- Proposal Contributors: Tim Frost, Thom Erickson, Horst Merkle, Erik Moll, Jacob Andersen, Barry Reinhold, Michael J. Kirwan
- Profile Editor: Tim Frost
- Profile Contributors: Thom Erickson, Horst Merkle, Tim Frost, Jacob Andersen, Erik Moll, Barry Reinhold, Michael J. Kirwan
- Domain: DEVices
Summary
To simplify and improve the remote patient monitoring user experience, it is desirable to enable medical sensor to communicate directly to a health server in the cloud. The use of a gateway device is not practical in many scenarios. The D2C solution leverages to the maximum extend practical existing industry standards covering cellular Internet of Things communications, IEEE Personal Health Devices, FHIR and transport security. Uniform implementation of these standards are essential to achieve interoperability.
A simplified protocol is required to accommodate the compute and power limitations of such sensors. It is envisioned that the actors defined in the POU profile would be employed. However, the transactions would be materially different and therefore warrant a separate Implementation Guide.
The COVID-19 pandemic has been the global defining event that has thrust remote patient monitoring into the minds of mainstream users. This IG will enable a collection of companies large and small from all corners of the globe to bring to market the billions of devices that must communicate universally understood health data critical to treating patients of pandemics. IHE Devices Domain expertise is uniquely suited to guide medical device manufacturers and Healthcare & Life Sciences software vendors leverage Patient Generated Health Data that is provided directly from a health sensor to health information system via cellular Internet of Things where WiFi may not be available.
2. The Problem
With WiFi and Bluetooth connectivity the end-user is either restricted to transferring data wherever a hub is located, or would need to carry a hub device wherever they go. Furthermore, pairing and configuration is an additional obstacle. It is desired that medical sensors are small and long-life battery powered - which puts “constraints” on their communication capability, requiring the data communicated to be lightweight to reduce on-time of the device. Therefore it is desired to define a lightweight approach for secure direct data transfer from such a constrained device to cloud.
3. Key Use Case
Sarah has tested positive for Covid-19. While in quarantine, her physician suggests she monitor her temperature and blood saturation. The device provided to Sarah is a wearable sensor(s). Sarah's has no fixed broadband connectivity in her home; however, her wide area connectivity (a.k.a. cellular) is good, which means that her physician can receive and monitor her condition while she is at home without any extra work for Sarah or her physician as long as the devices Sarah is using have connectivity.
Johnny is in the 6th grade and a child with Type 1 diabetes. He is required to monitor his glucose levels continuously. The device provided to Johnny is a wearable continuous glucose monitoring (CGM) sensor. It is not feasible/convenient to expect Johnny to be carrying/managing a secondary hub device with him. The wide area connectivity (a.k.a. cellular) allows Johnny's caregivers (e.g. parents, school nurse) to monitor Johnny's glucose levels and receive alerts (e.g. approaching hypoglycemic events) throughout his school day for fast intervention when needed.
4. Standards & Systems
Mobile Communications
It is intended that the recommended communication protocol and protocol stack, by which DOR communicates with DOC, is applicable for transfer via 3GPP LPWA (Low Power Wide Area) technologies such NB-IoT and eMTC. 3GPP: The 3rd Generation Partnership Project (3GPP) unites [Seven] telecommunications standard development organizations (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC), known as “Organizational Partners” to produce the Reports and Specifications that define 3GPP technologies covering all components of the mobile telecommunications system. (SDOs).
NB-IoT: NarrowBand-Internet of Things (NB-IoT) is a technology standardised by 3GPP in their Release 13 specification. NB-IoT is a low power wide area (LPWA) technology which supports IoT through lower device complexity, and providing extended coverage, and long battery life, whilst leveraging a mobile carrier’s licensed spectrum and sites. eMTC: eMTC (enhanced Machine Type Communication) is a technology standardised by 3GPP in their Release 13 specification. eMTC is a low power wide area (LPWA) technology which supports IoT through lower device complexity, providing extended coverage, and long battery life, whilst leveraging a mobile carrier’s licensed spectrum and sites.
Healthcare Interoperability Standards
IEEE 11073-10206 - Health informatics -- Device interoperability -- Personal health device communication -- Abstract information content model. It is intended to use the information model in this standard as a basis for defining a communication protocol to transfer the healthcare device data extracted from that information model from DOR to DOC. HL7 FHIR: FHIR stands for Fast Healthcare Interoperability Resources. Developed by Health Level Seven International (commonly known as HL7), it's an interoperability specification for the exchange of healthcare information electronically. It is intended for the DOC to translate received healthcare device data into a FHIR Resource.
Transport and Transport Security Standards
In recommending a transport protocol stack over which to carry the healthcare data, at least the following standards will be considered: CoAP (Constrained Application Protocol) as defined in IETF RFC 7252. UDP (User Datagram Protocol) as defined in IETF RFC 768. IPv4 as defined in IETF RFC 791. DTLS (Datagram Transport Layer Security) with version 2 as defined in IETF RFC 6347 OSCORE (Object Security for Constrained RESTful Environments) as defined in IETF RFC 8613.
5. Technical Approach
Actors
Note: The below Actor names are subject to change to ensure they are unique from other IHE Profile Actors.
Device Observation Reporter: The Device Observation Reporter is an actor that reports PHD Data (sensor device observations) to a Device Observation Consumer.
Device Observation Consumer: The Device Observation Consumer is an actor that receives PHD Data (sensor device observations) from a Device Observation Reporter.
Transactions [(IHE ITI2) – see section 9 of the POU profile doc.]
Profile
The main aspects that need to be defined are: The relationship with the existing Continua Reference Architecture. The requirements for provisioning the personal health device Device Observation Reporter (DOR). The referencing of 11073-10206, and specific requirements for communication of the 10206 Resource Model information from DOR to DOC using a direct-to-cloud topology. The definition of the underlying transport protocol stack for performing the transaction between Device Observation Reporter (PHD) and Device Observation Consumer (HFS), including the standards that shall be used within that protocol stack, and any specific requirements on usage of specific options within those standards. A new protocol layer for encapsulating 11073-10206 data into underlying protocols, and adding a unique device identity.
Decisions/Topics/Uncertainties
Analysis and decision on the type of communication method required to minimise battery consumption of the Device Observation Reporter (catering for the constrained device requirement). Includes analysis of the problem with using FHIR directly. Review of the IEEE 11073-10206 specification to identify any specific requirements required to support that communication method. Analysis and selection of the underlying protocol standards and ensuring e2e security for patient data – including whether it makes sense from an industry perspective to allow some protocol options or to specify purely a single interoperable stack. Practical implementation and resourcing for that.
6. Support & Resources
Support and resources that will help drive the success of this project include members of the PCHAlliance, IHE USA and IHE International, HIMSS, IEEE, FDA, ONC, HL7 FHIR and the general telehealth and remote patient monitoring industries and health communities.
7. Risks
Critical to the adoption of this proposed IG is to clearly articulate to key stakeholders how remote patient monitoring solves real-world challenges in a very practical sense. In the age of surveillance capitalism, it may be even more challenging to convince vendors to employ open standards-based solutions essential to interoperability. Although beyond the scope of IHE, streamlining regulatory approvals across multiple markets will be important as sensor hardware has become commoditized.
The reference to a specification that is not yet complete (e.g., IEEE 11073-10206). Level of adoption due to potential preference from device vendor stakeholders in single vendor e2e solutions, and/or preference for using their own proprietary protocols. Other potential competing solutions being developed by other industry players outside of IHE.
8. Tech Cmte Evaluation
<The technical committee will use this area to record details of the effort estimation, etc.>
Effort Evaluation (as a % of Tech Cmte Bandwidth):
- xx% for MUE
- yy% for MUE + optional
Editor:
- TBA
<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>