90 likes | 240 Vues
MHD = SMS + XDW + XDS. Commentary and proposed modifications regarding the IHE MHD Profile. July 5 th , 2012. Mobile Access to Health Documents (MHD). Existing Use Case. RESTful XDS Façade . *. RESTful XDS Façade . *. RESTful HTTP/S. RESTful HTTP/S. *. Smartphone or Tablet device.
E N D
MHD = SMS + XDW + XDS Commentary and proposed modifications regarding the IHE MHD Profile. July 5th, 2012
Mobile Access to Health Documents (MHD) Existing Use Case RESTful XDS Façade * RESTful XDS Façade * RESTful HTTP/S RESTful HTTP/S * Smartphone or Tablet device * Note: Should indicate 2-way communication.
Current MHD Proposal • The proposed MHD profile is not addressing mobile access, per se; rather, it is providing a simplified RESTful façade to a constrained XDS specification. • A simplified XDS interface is a good thing, however: • A modern smartphone or tablet has sufficient processing power to do XDS natively and to abide necessary security and privacy legislation such as HIPAA . • Only half of US mobile phone subscribers have smartphones (as of March, 2012)… which means half don’t. To support broad, consumer-focused access to health data, rudimentary SMS must be supported. • In most developing countries, fewer than 5% of mobile phone subscribers have smartphones.
Mobile Access to Health Documents (MHD) Proposed SMS-based Use Case XDS Façade XDS Façade Text (SMS) Text (SMS)
SMS Use Case • To support broad consumer access to mobile health data, SMS support is needed. • However, SMS severely constrains the size and type of data interactions: • Limited to 140 characters • No formatting; plain text only • Numeric input is MUCH simpler than alphanumeric input on basic (non-QWERTY) mobile phone handsets • Supporting 140-character, numeric “document” exchange is a trivial use case. The proposed profile is actually intended to enable simple content exchange which may support subsequent document construction by the XDS façade. This implies a workflow capability.
Mobile Access to Health Documents (MHD) Proposed XDW-centric Configuration XDS Document Consumer XDS Document Source XDW Cross-enterprise document workflow Engine MHD Document Responder MHD Document Recipient Text (SMS) Text (SMS) MHD Document Consumer MHD Document Source
Mobile Access to Health Documents (MHD) Proposed Configuration XDS Document Consumer XDS Document Source Retrieve a workflow-centric document containing care guidelines which can drive a poll/response interaction. (e.g. basic antenatal care assessment) Construct and post an XDS-compliant document containing results of the text-based “conversation”. 1 3 XDW Cross-enterprise document workflow Engine MHD Document Responder MHD Document Recipient Text (SMS) Text (SMS) MHD Document Consumer MHD Document Source 2 Conduct a text-message based “conversation”; prompt for answers to specific questions based on the care guidelines. e.g. What is the systolic BP (in mm Hg)?.
Value of an SMS “Conversation” Pairing text/SMS messages with XDW plus an XDS façade supports rich and clinically relevant interactions using basic mobile phone handsets. The proposed profile supports the “push” of information to a mobile phone. Such interactions are useful for alerts/reminders and may be used to initiate SMS conversations that capture basic information (e.g. What is your current blood sugar (mmol/L)?) A rudimentary, text-based poll/response pattern supports interactions with the many legacy, network-connected medical devices that do not natively support HTTP.
Defining the Profile • In the face of the proposed configuration, the interaction will be a simple text exchange • The “conformance” of the profile will depend on the façade plus the workflow engine • Possible normative statements might include: • MHD Document Sources must be authenticated using 2-factor authentication (e.g. SIM card plus PIN) • Responder/Source messages must be less than 140 plain text characters • A Responder/Recipient must be able to maintain state for the duration of a conversation and drop the session after an appropriate timeout • A Responder must be able to construct “questions” based on the workflow specified in the XDW-based document • A Recipient must raise and communicate an exception to Source “responses” that violate underlying XDW-specified datatype or value range constraints related to the “question” • A Recipient must be able to construct a valid XDS document conformant with the XDW-specified workflow