ecGroup Inc. 1

MHD = SMS + XDW + XDS

Commentary and proposed modifications regarding the IHE MHD Profile.July 5th, 2012

ecGroup Inc. 2

RESTful XDS Façade

RESTfulXDS Façade

RESTful HTTP/S

RESTful HTTP/S

Mobile Access to Health Documents (MHD)

*

* Note: Should indicate 2-way communication.

*

*

Existing Use Case

Smartphone or Tablet device

ecGroup Inc. 3

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.

ecGroup Inc. 4

XDSFaçade

XDSFaçade

Text (SMS)

Text (SMS)

Proposed SMS-based Use CaseMobile Access to Health Documents (MHD)

ecGroup Inc. 5

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.

ecGroup Inc. 6

XDS Document Consumer

XDW Cross-enterprise document workflow Engine

MHD Document Responder

MHD Document Consumer

Text (SMS) Text (SMS)

Proposed XDW-centric ConfigurationMobile Access to Health Documents (MHD)

XDS Document

Source

MHD Document Recipient

MHD Document

Source

ecGroup Inc. 7

XDS Document Consumer

XDW Cross-enterprise document workflow Engine

MHD Document Responder

MHD Document Consumer

Text (SMS) Text (SMS)

Proposed ConfigurationMobile Access to Health Documents (MHD)

XDS Document

Source

MHD Document Recipient

MHD Document

Source

31 Construct and post an XDS-compliant document containing results of the text-based “conversation”.

Retrieve a workflow-centric document containing care

guidelines which can drive a poll/response interaction. (e.g. basic antenatal care

assessment)

2Conduct 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)?.

ecGroup Inc. 8

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.

ecGroup Inc. 9

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