Joint Recommendation on base standards for HITSP RMON Interface #2 > IHE Ambassadors > Continua Wide Area Network (WAN) Team

Transcription

1 Joint Recommendation on base standards for HITSP RMON Interface #2 > IHE Ambassadors > Continua Wide Area Network (WAN) Team

2 The Landscape Interface #2 Nomenclature: ISO/IEEE PHD Aligns with Continua Device Interface What about transport and payload? (proposed in this presentation) Interface #4 Data: PHM Specification (HL7 CDA based) Transport: IHE XDR Aligns with Continua EHR Interface

3 Goals Minimal Payload Translation Keep the device readings in /-104xx MDC nomenclature No code translation to SNOMED or LOINC No unit translation to UCUM Minimal Payload Transformation Device Intermediary (i.e., Manager) devices should not be forced to deal with the complexity of transformations from one payload model to another Limited transformation from WAN to EHR another goal Support for all 3 Continua Domains Health and Fitness, Aging Independently, and Disease Management Extensibility Capable of supporting new devices without flash, update, or in field maintenance Minimize divergence of standards (re-use existing IHE standard if requirements met) IHE and Continua WAN and HITSP RMON Interface #2 3

4 Recommendations HL7 v2.6 messages using IHE PCD-01 Initially constrained to IEEE and 104xx nomenclature for personal health devices Can be extended to support IEEE terminologies and core components of the information model for clinical devices Web Services transport based on WS-I Basic Profile Work with HL7, WS-I, and IHE ITI on further Web Service Profiles Define placeholder for alarm, alert, control, and command messages but defer message contents for later versions IHE and Continua WAN and HITSP RMON Interface #2 4

5 Proposed Protocol Stack Device Intermediary Remote Monitoring Management System IHE and Continua WAN and HITSP RMON Interface #2 5

6 Payload Options Considered ASN.1 Model (based on Appendix A) Possible change encoding to XER XSD Model (based on DIM) Possibly work with NIST IHE PCD-01 Constrained HL7 v2.6 Unsolicited Observation Result HL7 v3 Messaging Observations and Results Domain Therapeutic Devices Domain IHE and Continua WAN and HITSP RMON Interface #2 6

7 PCD-01 Constrained HL7 v2.6 - Technical Reasoning Self-contained, self-describing, concrete definition of an observation Simple mapping from IEEE Personal Health Devices to PCD-01 Observation Results PCD-01 is extensible to future use cases via its dotted-notation hierarchy Availability of open-source tooling HL7 Messaging Workbench NIST test tooling Compact messages IHE and Continua WAN and HITSP RMON Interface #2 7

8 PCD-01 Constrained HL7 v2.6 Other Reasoning Provides a unified solution for all Continua domains and clinical information HL7 v2 is a mature standard that is widely deployed Integrating the Healthcare Enterprise (IHE) aligns well with Continua s vision of profiling existing standards and constraining them for interoperability IHE and Continua WAN and HITSP RMON Interface #2 8

9 Transport Options Considered Minimum Lower Layer Protocol (MLLP w/ TLS) MQ Telemetry Transport (MQTT) HyperText Transfer Protocol (HTTP) WS-I Simple SOAP Profile (SOAP/HTTP) WS-I Basic Profile (BP) WS-Addressing and other guidelines WS-I Reliable Secure Profile (RSP) WS-ReliableMessaging, WS-MakeConnection, WS- SecureConversation IHE and Continua WAN and HITSP RMON Interface #2 9

10 WS-Basic Profile Transport Technical Reasoning Built on HTTP Firewall Well-adopted usage of Transport Level Security Composable standards to deliver additional QoS Possible application-level security requirement Allows scaling of WAN device receiver IHE and Continua WAN and HITSP RMON Interface #2 10

11 WS-Basic Profile Transport Other Reasoning Consistent with wider industry directions WS-I Basic widely adopted Use existing standards Consistent with health industry standards IHE ITI Technical Framework Vol 2 Appendix V IHE and Continua WAN and HITSP RMON Interface #2 11

12 Why not MLLP? Less suitable for in-home endpoints Firewall issues Less suitable for mobile networks Intermittent connections Lower layer / fewer features means we would be left writing our own custom mechanisms for any additional Quality of Service required Contrast this with the vast body of these standards in the Web Service space: WS- ReliableMessaging, WS-Security, WS-Policy, etc IHE and Continua WAN and HITSP RMON Interface #2 12

13 Current WAN Strawman Transport Level Security (TLS) with guidance from WS-I Basic Security Profile (BSP) Required Mutual Authentication Security Assumptions Point-to-point Fully trusted WAN device receiver Level of trust assigned to AHD based on local policy Configuration/Enrollment performed out-ofband IHE and Continua WAN and HITSP RMON Interface #2 13

14 Initial WAN Use Cases Upload Measurement Data Cell Phones, PCs, Laptops, PDAs, Set Top Boxes Architypal AHDs Dedicated/Trusted Embedded box provisioned by care provider Consumer/Untrusted User installs program on PC or Smart Phone and enrolls in service(s) IHE and Continua WAN and HITSP RMON Interface #2 14

15 HITSP Coordination The HITSP Device Intermediary described in the RMON use case best fits the dedicated/trusted model (IHE ATNA Secure Node ) HITSP/T17 Secure Communication Channel HITSP/T15 Collect and Communicate Security Audit Trail HITSP/C19 Entity Identity Assertion HITSP/C26 Non-repudiation of Origin HITSP/TP30 Manage Consent Directive HITSP/TP20 Access Control Plan: Attempt to define a simple interface with a base level of interoperability but can also be used in conjunction with various security and privacy constructs. If this approach proves intractable, would it be sufficient to define a preliminary version of the WAN interface that is not directly applicable for the RMON Interface #2 Messages could still be re-used in transaction T73: Aggregate Device Information Communication IHE and Continua WAN and HITSP RMON Interface #2 15

16 Open Tasks Reliability discussions Message flow diagrams WSDL and message examples (Lee) Investigate validation and robustness (Paul) Gap: HL7 V2 EDI over WS* Alarm/Alert placeholder Investigate IHE PCD Alarm Communication Management (ACM) profile? Command/Control placeholder IHE and Continua WAN and HITSP RMON Interface #2 16

17 Backup

18 Messaging Example MSH ^~\& HL7^080019FFFF4F6AC0^EUI- 64 MMS ORU^R01 a4e2e3:11036b5cdbb:- P NE AL 8859/1 PID 6O008D^^^A^PI DAVIDSON^DAVID^^^^^L PV1 E 3WICU^305^305 OBR FFFF4F6AFE FFFF4F6AC ^2000^MDC OBX 1 NM ^MDC_MASS_BODY_ACTUAL^MDC ^MDC_DIM_KI LO_G^MDC R Z OBX 2 NM ^MDC_LEN_BODY_ACTUAL^MDC ^MDC_DIM_CE NTI_M^MDC R Z IHE and Continua WAN and HITSP RMON Interface #2 18

19 Consensus Building Capable of near real-time content Latency down to 5 seconds for subset of patients Providers want up-to-date information Well-defined observation concept Provide an abstraction on top the DIM Patient, Device, and Observation(s) Independence from the PAN protocol No synchronizing DIM state on the WAN Device Scalability Once-and-only-once delivery of messages Message Queueing and In-Order delivery require the use of a Session concept which lives across multiple TCP/IP connection sessions for the same patient-agent association IHE and Continua WAN and HITSP RMON Interface #2 19