• Print

Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Individuals and Systems


Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Individuals and Systems

Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Individuals and Systems

Type

Standard/Implementation Specification

Standards Process Maturity

Implementation Maturity

Adoption Level

Federally Required

Cost

Test Tool Availability

1- Standard Applicability Statement for Secure Health Transport v1.1 (“Direct”) Final Production rating 5 Yes Free Yes
2 - Emerging Standard Applicability Statement for Secure Health Transport v1.2 Final Production rating 3 Yes Free Yes
1, 2, 3 - Implementation Specification IG for Direct Edge Protocols Final Production rating 2 Yes Free Yes
1, 2 - Implementation Specification IG for Delivery Notification in Direct Final Production rating 3 Yes Free Yes
1, 2, 3 - Implementation Specification XDR and XDM for Direct Messaging Specification Final Production rating 4 Yes Free Yes
3 – Standard IHE-XDR (Cross-Enterprise Document Reliable Interchange) Final Production rating 5 Yes Free Yes
4 - Emerging Standard Fast Healthcare Interoperability Resources (FHIR) DSTU 2 Balloted Draft Pilot rating 1 No Free No
3, 4 - Emerging Implementation Specification IHE-MHD (Mobile Access to Health Documents Balloted Draft Pilot rating 1 No Free No
Limitations, Dependencies, and Preconditions for Consideration: Applicable Security Patterns for Consideration:
  • “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).
  • The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API
  • The MHD supplement is based on FHIR DSTU1.1. The IHE MHD committee is currently working to update the MHD profile and planning to release it to implementers in first quarter calendar year 2016.
  • See Direct, FHIR, and IHE projects in the Interoperability Proving Ground.
  • System Authentication - The information and process necessary to authenticate the systems involved
  • Recipient Encryption - the message and health information are encrypted for the intended user
  • Sender Signature – details that are necessary to identity of the individual sending the message
  • Secure Communication – create a secure channel for client-to- serve and server-to-server communication.
  • Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.
alice borrelli
Intel Corporation

October 24, 2016
Mr. Steven Posnack
Director Office of Standards and Technology
Office of the National Coordinator for Health Information Technology
U.S. Department of Health and Human Services
330 C St SW
Floor 7
Washington, DC 20024Re: Comments on the Draft 2017 Interoperability Standards Advisory

Dear Mr. Posnack:

For a decade, Intel has worked with many in the industry and government agencies to create the Continua Design Guidelines which are based on specific standards now adopted by the ITU and other government agencies worldwide. We are submitting these comments to invite the US to participate in a growing acknowledgment of the value that this suite of standards brings to personal connected devices. Through voluntary certification testing, these standards have demonstrated that they provide interoperability to ensure that personal physiological data is incorporated into the record as structured actionable data.
Intel appreciates the opportunity to comment on the 2017 Interoperability Standards Advisory (Draft 2017 ISA). Your work to develop the ISA is essential to advancing health information interoperability. We make the following request to improve interoperability and to support the meaningful use stage 3 objective of incorporating patient generated health data into the health record.
Please add ITU H.810, H.811, H.812, and H.813 - a suite ITU standards for end-to-end, plug-and-play connectivity of personal connected health devices such as wireless blood pressure cuffs, weight scales, glucometers, and activity trackers that play a critical role in prevention and improved management of chronic condition – as an implementation specification for:
1) "III-A: “Push” Exchange: Interoperability Need: An unsolicited “push” of clinical health information to a known destination between individuals and systems" (page 60 of the Draft 2017 Interoperability Standards Advisory.)
2) "III-A: “Push” Exchange: Interoperability Need: Push Communication of Vital Signs from Medical Devices” (page 62 of the Draft 2017 Interoperability Standards Advisory.)
Together, ITU's H.810, H.811, H.812, and H.813 lay-out implementation specifications to support interoperability of personal health devices (blood press cuffs, weight scales, and glucometers) with clinical data systems and clinical decision making. These implementation specifications make it possible for clinicians to monitor their patients chronic conditions and bio-physical measures that indicate need for medication modifications, lifestyle changes, or a clinical intervention.
ITU H.810, H,811, H.812, and H.813 identify a range of open industry standards that will support the three key functions essential to interoperability of patient health data/physiologic measure collected from/by devices: a) Collection of data from a personal health device and subsequent transmission to a gateway or cloud intermediate system. This is the collection of a physiologic measurement (for example, a blood pressure reading) and sending it to a phone or personal computer (gateway device). b) Re-transmission of personal health data (physiologic measures) from a gateway device or system to a cloud or other data repository or intermediate system. This is the transmission of data from a cellphone to a cloud system for example. Data aggregation usually happens at this level. c) Re-transmission of data from a cloud or aggregation system to a Healthcare Information System (The HRN or more recently the “Healthcare Information System” interface). This is the final specification for data to be sent to a clinical or other healthcare information system (an EHR for instance) in a clinically useful way.
Additionally, we request that a footnote or asterisk note to explain that these ITU standards are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that enable several options to achieve end-to-end interoperability between personal medical devices and health information systems.
Finally, we ask that ONC add the following interoperability need to CREATE a NEW Interoperability Need - to support chronic condition management, care coordination and care management: Remote Patient Monitoring to Support Chronic Condition Management, Patient Education, and Patient Engagement and list ITU H.810, H.811, H.812, and H.813 as an implementation specification for remote patient monitoring interoperability.
Thank you for your consideration to include these standards into the ISA, a critical step towards integrating patient generated data into the clinical EHR.
Sincerely,

Alice B. Borrelli
Global Director for Healthcare Policy
Intel Corporation
202-202-0963 (c)
202-626-4393 (o)

Matthew Greene
Department of Veterans Affairs

Instead of “Fast Healthcare Interoperability Resources (FHIR) DSTU 2” we need to refer either to “the latest FHIR release” and/or list specific resources applicable “Push Exchanges” (e.g. “Bundle”, “Composition”?)