IHE's Mobile Access to Health Documents (MHD) Profile

IHE has just closed (July 5^th, 2012) the public comment period on a new profile designed to support health information exchange using “mobile” technologies: MHD - Mobile access to Health Documents. IHE (Integrating the Healthcare Enterprise) is an international industry association dedicated to interoperability. I must admit, I really like IHE. I like the fact that they don’t write new standards; I like that all of their work product is centred around implementation guides; I like that a vendor can definitively establish that its products are interoperable and adhere to a particular set of IHE Profiles; and (perhaps most of all) I really like the way that IHE governs the introduction of new candidate profiles.

I must admit, however, that I wasn’t a huge fan of the draft-for-comment of the new MHD profile. It felt, to me, that it is a bit mis-named. MHD purports to be a profile to support “mobile” access to health information. In reality, however, over 85% of the world’s mobile devices could not use this profile, as it is currently designed.

My eldest son, Harrison, has a turn of phrase that he sometimes (and occasionally sarcastically) uses. When his sister or brother is complaining about something such as: “oh no – I left my iPod charger at school and I’ve only got 4 hrs of music listening left before I’m out of juice”, Harrison will roll his eyes and mutter: “first-world problems!”. His comment underlines the simple truth that, really, how big an issue could this possibly be?

I fear that the focus of the new IHE mobile profile (MHD), suffers a bit from an analogous issue. The profile purports to be designed to support mobile access to health information. However, as designed, the profile only supports access using a smartphone or tablet, with an internet connection, that is able to generate and consume well-formed JSON content exchanged using a RESTful API. One of the diagrams from the for-public-comment draft profile is shown below (the annotations, in blue and in red, are mine and were included in the comment document I posted to the IHE feedback site).

In my feedback comments on the candidate MHD profile, I suggested that a tablet or smartphone already has the necessary processing power to do native XDS-based document exchange – so the MHD profile is simply a new interaction mechanism (REST) for a device that could already execute the existing data exchange methods. I went on to point out that, even in the US, only half of mobile phone subscribers have smartphones… which means that half don’t. And worldwide, smartphone adoption drops to less than 13%. As was recently reported by Business Insider, 5.6 billion worldwide mobile phone subscribers are Dumbphone users.

Now, I’ve never been a fan of mere nay-sayers and pot-shotters. In my submission on the draft-for-comment I didn’t diss the hard work that has been done by the IHE technical committee on the MHD profile. In point of fact, I like it and think it adds a very useful alternate method to the existing XDS document exchange specifications. What I don’t think the draft profile did, however, was define a way to draw in the 5.6 billion mobile Dumbphone users – a group which includes fully half of US mobile phone subscribers. So, in my submission, I proposed an alternative.

I illustrated my alternative using a one-to-one pictorial analogy to the original MHD diagram (shown above). Basically, my suggestion is that a mobile access to health documents profile should support simple, boring, basic SMS (text messaging) data exchange. In this way, the profile would be usable by all 6.4 billion of the world’s mobile phone users.

Now, let’s be serious with each other for a moment. We all know that there are some severe limitations to information exchange over SMS:

• Limited to 140 characters
• No formatting; plain text only
• Numeric input is much simpler than alphanumeric input on basic (non-QWERTY) mobile phone handsets.

Clearly, a 140-character, largely numeric healthcare “document” exchange is a pretty trivial use case! In fact, that isn’t at all what I was proposing. What I proposed was a content exchange pattern – a text-based conversation – that could, subsequently, be constructed into an XDS-conformant healthcare document. To work, such a pattern would need to rely upon a workflow capability.

To illustrate how I think this alternative might work, I included in my comments submission the graphic shown above. The premise of my proposed alternative pattern for MHD is that a workflow-centric document (using the IHE’s XDW specification, for instance) be employed to enable a guideline-based conversation. The process steps might go something like this:

Step 1: A structured CDA document is retrieved which outlines the healthcare information which is to be obtained from a pregnant mum during an antenatal care visit. This outline might be based on, for instance, the WHO’s Every Woman Every Child care guidelines for maternal care.

Step 2: A workflow engine steps through each of the elements in the document and constructs simple “questions” which are sent via SMS to the mobile phone, such as:

What is the mum’s weight (in kg)?

What is the mum’s temperature (in degrees C)?

What is the mum’s systolic blood pressure (in mm Hg)?

For each of these questions, a simple numeric answer may be provided. Rudimentary error-checking can even be done to ensure that answers are within realistic parameters set for each data element (and which may have been expressed as part of the document’s data structure as allowed datatypes and ranges, etc.).

Step 3: After the conversation has been concluded, a conformant CDA document is constructed and saved to the pregnant mum's shared health record using the XDS profile. Optionally, if some of the mum's readings are concerning in some way, a new conversation might be launched to escalate her care to a referral centre.

I will readily admit that this scenario is definitely not focused on trying to solve “first-world problems”. Quite to the contrary, this particular example illustrates how such a pattern may be used to help community health workers (CHWs) use basic mobile phones to deliver guideline-based maternal care in rural settings in the developing world. In fact, just such a project is underway, right now, in Rwanda.

To be fair, though, this same pattern of workflow-guided SMS conversations could be used in all kinds of useful ways in the developed world, too. Here in Canada, as in many other countries, we are presently very focused on ways to improve chronic disease management. The "conversational" pattern could be readily employed to provide consumer health support to a diabetic patient at home in downtown Toronto.
“What is your blood sugar (in mmol/L)?”
"What is your weight (in LBS)?"
"How much exercise have you got over the last 3 days (in minutes)?"

The key message is this: To support broad, everywhere-access to shared health information, we should be looking for ways to support data exchange using mobile devices. To do this at scale, we need to find a way to usefully draw in and embrace the most pervasive mobile device on earth, the mobile phone, using the one exchange method every single phone supports: SMS. 

I have high hopes for IHE; I am, as indicated at the outset of this blog, a real fan of the organization. Selfishly, because I’m currently working in global eHealth, I’m very keenly interested and the ways IHE can potentially help support meHealth interoperability in the developing world. I will follow the evolution of this new candidate MHD profile with interest and, if I’m able to, will work to help it evolve to become more broadly embracing of existing mobile phone technologies.

Why can’t eHealth be like Facebook?

Some things just make you wanna scream. For the last year or so, the thing that most often makes me want to let out a real rebel yell is when I hear people say things like: “why can’t we have an eHealth system that works like Facebook?” Honestly, I’ve heard some VERY clever people ask this; people whose intelligence I know to be extremely high and whose opinions and views I genuinely respect. But seriously – any time I’ve heard this it just makes me want to scream… until today.

Today I had an epiphany. Today I found myself thinking: “we need eHealth to be like Facebook.” 

I thought this as I was posting a response on LinkedIn. My friend Paul Gallant had referenced an article on a forum I follow. This article quoted Will Falk, Donald Drummond and Dominic Covvey opining that there was nothing cutting edge about Canada’s eHealth strategy (or more precisely, Canada HealthInfoway’s eHealth strategy). These experts thought the strategy was obsolete; that it was too top-heavy, too “big iron” and that it was already being lapped by mHealth and tablet technologies. I don’t at all agree with that assertion, and in fact said in my post that “it is infrastructure in the middle of the network that does the job of resolving person and provider identity, that stores shared health information in a coded way, and that is able to provide care plan alerts and triggers -- and this mundane middle bit is what creates the "network effect" needed for person-centred health to become a reality.”

And that’s when I had my epiphany. I concluded my post by saying: “We had PCs and mobile phones before Facebook. It was the middle bit that created such an astounding network effect.” 

Why would I say something like that? I’m on the record as having made some pretty unequivocal statements about how different eHealth is from Facebook and what a mistake I think it is to compare the two. Have I got some apologies to extend? Perhaps some public retractions to make?

Well… let’s not jump to Googling recipes for crow just yet… there are still some important reasons to expect eHealth to be very different from Facebook. But there are some similarities, too, and these are worth exploring.

I’ve been doing work the last couple of years in the area of mHealth – the use of mobile technologies, including mobile phones, to do eHealth. The work I’ve been involved in has been in sub-Saharan Africa. The reason mHealth is a big deal there, and elsewhere in the developing world, is quite simple: in these regions the mobile phone is the pervasive computing device. 

ICT Adoption in African Countries -- ITU 2009

 The problem, though, is that on its own mHealth doesn’t really do anything. I’m a bit uncomfortable with how unkind that sounds – but the truth is, healthcare is an information-intensive domain and mobile phones or tablets or PDAs are generally lightweights when it comes to data management or computational muscle. Their real advantage is their ability to provide a network connection.

So… that’s why we need a set of powerful applications and services that can do useful work on the other end of that network connection. We need cloud-based computing and data management muscle so that our lightly powered edge devices can leverage it. We need eHealth infrastructure that is like Facebook; we need a central service that will deliver the important “network effect” that will support continuity of person-centred care over time and across multiple delivery sites. We need a timeline that provides a longitudinal record of our health related interactions and we need standards-based interfaces so that trusted actors and applications can access and work with that information to support care delivery on our behalf.

I heard Infoway’s CTO, Dennis Giokas, articulating a strategy much like this one at the Infoway Partnership meetings in Halifax last November. This isn’t an obsolete strategy – it is the only strategy that will lead to the kind of healthcare ecosystem we all want. Indeed, I believe it is the only strategy that will let us leverage the technological advances in tablets and smartphones that are the subject of so much hype lately (and which Falk, Drummond and Covvey are so keen on). The challenge is, it is a strategy that relies on us finishing the work we’ve started. Yeah – that boring work that no one seems to see the value in. We need to finish the work of building our cloud-resident, service oriented, standards-based eHealth middle bit. Without it, there is no mHealth… or none that does anything important anyway.

I’ve come to believe that we need a new catch-phrase, a new marketectural description that really captures the essence of the value in this middle bit. We need a concise moniker that will evoke the important ways that individual care will be supported by this infrastructure. I have one that I like. I think that a person-centric, mHealth plus eHealth infrastructure should be called… wait for it: meHealth.