IHE and PCHA Join Forces to advance mHealth

If I've said it once, I've said it a hundred times, I need another SDO to pay attention to like I need another hole in the head.  The number of organizations and "projects" and partnerships seems to have exploded over the last decade.

Here are some of the activities on my current radar screen:

• Argonaut Project
• CARIN Alliance
• Continua Health Alliance
• DaVinci Project
• Gravity Project
• Health Level 7
• IEEE P1752 Working Group
• Integrating the Healthcare Enterprise

There's a lot of great work going on in these spaces, but it's rather difficult to track it all, and it takes a rather large standards development team, membership and travel budget to be deep into where the important action is.  Some of these projects and alliances and SDO's charge significant membership fees in order to influence the activities that are being selected for future development.

Thankfully, I can now skip one of these, as the Continua specifications are now moving into the IHE Devices (formerly Patient Care Devices) domain as of last week.  

Quoting from the Press Release:

To further align and integrate specifications and test tools – and accelerate the adoption of remote patient monitoring -- PCHAlliance and IHE International are meeting in Boston this week during the Connected Health Conference to formally launch the Personal Connected Health subdomain within the IHE Patient Care Device Domain. Over the coming year, this group will develop IHE profiles that leverage and build upon the Continua Design Guidelines. Once complete, IHE will apply its established process for industry stakeholders to implement globally recognized, consensus-based approaches to connect and test both personal and clinical devices and integrate them into health information systems. Additionally, the Joint Task Force will explore and address how the specification supports both medical devices and mainstream consumer facing apps to enable scalable interoperability of the rapidly expanding connected health ecosystem.

Furthermore, the workgroup will be chartering a Mobile Health Apps domain to be:

A singular domain in which to coordinate the development of implementation guidelines to help patient and consumer facing application developers employ IHE profiles to apply the HL7 FHIR and other standards for the purpose of moving data between personal mobile devices and applications, and health information systems and exchanges.

It's long been the vision of PCHA and the Continua Health Alliance to enable patients and consumers to take advantage of personal health devices, and I think the Mobile Health Apps workgroup will help greatly as we expand the use of healthcare standards into health and wellness related apps and services.

If you are interested in learning more about the Mobile Health Apps domain, and want to learn more, just send me an e-mail.  We're still in the very early stages of formation, and hope to have a meeting in early Q1 2020 to kick things off.

Getting FHIR Data from mHealth devices and applications

I've been spending a good bit of my time working on understanding health data in mobile apps and devices.  Most of my research tells me we need to look at what the problems really are, rather than to assert that ___ will solve the problem.

There's not really a good collection of FHIR data coming from mobile apps and devices that could be used for any sort of analysis.  To address this problem, the Mobile Health Workgroup in HL7 is sponsoring a track at the HL7 September FHIR Connectathon to explore what kind of FHIR resources come out of these devices, and produce that collection for analysis.

The workgroup is hosting a meeting on August 23rd at 11am Eastern to discuss this track if you would like to learn more.  Coordinates are below:

 Web Meeting :

Dial-in Number (US): (515) 604-9930

Access Code: 836039

International Dial-in Numbers: https://fccdl.in/i/mhealth

Join the Online Meeting: https://join.freeconferencecall.com/mhealth

For 24/7 Customer Care, call (844) 844-1322

Sailing to RHIO: The mHealth Value Proposition

Today I presented at the Sailing to RHIO Conference organized by Arsenál.IT in Treviso.  The aim of this meeting was to review eHealth Issues and Telemedicine problems important to develop a RHIO for the Veneto region.  John Moehrke also presented at this event on Security and Privacy.

While John covered IHE profiles, I discussed the standards that emerging from HL7, IHE, OMG, and Continua Health Alliance related to Mobile Health.  If you attended my presentation at the mHealth Summit last year, you might recognized some of the content, but I did make several updates and trims for this audience.

You can find the presentation below:

An mHealth Value Model

I spent a couple of days at the mHealthSummit 2012 in DC this last week.  A short summary of my impressions have already been posted.  What I want to do this morning is talk a little bit about the definition of Mobile Health (or as some like to call it, mHealth).

My definition is short and tweetable:  #mHealth is Connecting Healthcare without wires.

What I found at the summit was that while this definition clearly describes what vendors were offering, there was wide variety in the value mobile access provided. There are two ways in which you can look at it, the first is the barrier removed by mobile access, and the second is by what it connects.  The two are quite related:

Value	Barrier Removed	Connecting
▂	Wires	People to Devices
	A lot of what I saw simply exchanged wires for a radio and a mobile power source. This removes physical barriers, but not much else.  Some of the wire removal allows activities to be monitored outside the healthcare environment, which also eliminates the distance barrier. This leads to the next level.  At some point, I think we'll stop calling this "mHealth".
▂ ▃	Platform Variation	Developers to Mobile Devices
	One barrier introduced by Mobile is variation in platform.  We have Apple, Android, and basic Web (with HTML5+CSS) on the mobile device as different ways to create your application.  A number of vendors are working on making it possible to build one app for multiple platforms.  The audience for these tools is pretty limited.  Little of this is related to specifically to healthcare.  The few offerings I did see with any focused attention to healthcare in this spaced touted their "HIPAA" qualifications.  A reminder to you all:  HIPAA compliance is a property of an organization, not a product.
▂ ▃ ▅	Distance/Time	People to People
	Instant/unwired communication, including text, audio and video eliminates barriers related to time and/or distance. A good bit of this is simply a matter of hooking up a keyboard, speaker or camera to a radio, sometimes with a design intended for use in the healthcare environment. Some of what I saw didn't take the last step.  The more Healthcare oriented design that goes in, the more I feel comfortable fitting these offerings into the "mHealth" space.
▂ ▃ ▅ ▆	Ignorance	People to Information
	There are several levels in here. Web application that have a mobile friendly input/output is the most basic level. SMS access to information is very big in emerging markets where smart phones aren't ubiquitous. This has more value, I think, than simply mobile enabling a web site. One site connects your phone's camera (via an eTag) to a map of nearby an automated external defibrillator, which begins to move into level 4.
▂ ▃ ▅ ▆ ▇	Silos	Information to Information
	This is the highest level, and few mobile applications are there yet. Many are just creating new silos (e.g., Like my FitBit, which uploads to a website where I have to pay an annual fee to get access to the analyzed data, and have no access to the raw data). There are some PHR applications which connect your data with other data sources (e.g., MedLine Plus Connect), but these are still pretty limited.  This level has the highest potential value to both patients and providers.  BTW: If you make me type it in, you aren't thinking about my error rate on phone keypads, and I hardly count it in this space.

These "levels of value" shouldn't have any ramifications of "good" or "bad".  Removing wires can be very useful, especially when doing so eliminates significant risk for patients, enables care that couldn't be provided previously, et cetera.  My purpose in building this classification system is to understand the impacts of mobile health on the "cost curve" of healthcare.  I don't see offerings at level 1 having as much an impact on the cost/quality of the care that I get, as offerings at level 5.  Your mileage may vary.

Automate the BlueButton PULL Proposal

I managed to attend the second #ABBI call yesterday.  It's pretty clear that there will be at least three workgroups (and possibly a fourth) for this S&I Framework project.

1.  PUSH: Direct + CCD/CCDA
2.  PULL: They don't have an outline yet, but see below
3.  Content: Meaningful Use required content and possibly other stuff.

The "possible" fourth item deals with security/privacy.  However, on the call, it was pretty clear they were focused on the first three, while the WIKI page adds the fourth.  It's pretty clear that security/privacy is already being dealt with on many levels in S&I, and I'd hope that we simply reuse that work.

A lot of discussion was around the wording for the scope of the project, and focused on the differentiation between access to data, and control of it.  Rather than give you my rant about this, I'd rather you read this excellent post by Fred Trotter.

On PULL, what I think is needed is the following:

1. Transport:  IHE mHealth Profile
2. Privacy/Security:  TLS, OAuth and OpenId (see the RHEx Project)
3. Content:  CCD [MU Stage 1] and/or CCDA [MU Stage 2]

It should be pretty easy to create a connector between an XDS registry and repository (or an XCA Gateway) to support access to content via the IHE mHealth profile.  It looks like I'm going to be creating a prototype to demonstrate that capability.  I guess I'm going to have to find some OAuth/OpenID Server side code to reuse for this.

The benefit of this approach is that the XCA Query is already included in the Exchange specifications and in CONNECT.  So, if I can adapt an IHE mHealth request into an XCA Query, this should provide a great deal of compatibility with many existing NwHIN nodes for the PULL capability.

The IHE mHealth profile DOESN'T require an underlying XDS/XCA infrastructure.  The point of developing this prototype is simply to demonstrate what the mHealth profile can do to support patient access.  I've found through the Query Health project that demonstrating is much more convincing than talking about it.

I'm planning on starting with the Open Health Tools IHE Project (ppt), and perhaps contributing the code to support the IHE mHealth profile.

Are Documents Dead?

I asked Gary Thomson over at CLOUD to take a look at the IHE mHealth profile.  He response asked "What if there aren't Documents?"  He then goes on to say

A piece of information does not know if it is medical, financial or educational. It also doesn't know if it is in an EHR or a PHR. It is just data, and if we wait to combine that information/data into a document until the last possible moment, then suddenly, the whole problem takes on a different view.

So even though he says, what if there are no documents, guess what?  There are.  They are just crafted dynamically.  IHE IT Infrastructure developed a "On-Demand Documents" variant of XDS/XCA that does just the sort of thing that Gary asks for, waiting to combine the data until it is requested.  The challenge later is that systems may need to reproduce exactly that content in the future.  So, we save it as a document.

The IHE mHealth Profile can interact and integrate with this "futuristic" concept of "document" just as readily as it can with today's concept.

About 4 years ago, the HL7 Structured Documents Workgroup developed a Structured Documents specification.  Now overtaken by events (CDA R3), this specification asserted that there five characteristics of documents that were generalized from the 6 characteristics of CDA documents:

1. Human Readable
2. Persistent
3. Managed
4. Contextualized
5. Wholeness

Looking at this from the CLOUD perspective of "it's just data", I can see where three of these attributes apply.  A datum is readable, persistent, and managed.  By itself, it has no context.  In fact, as Gary says, it doesn't know if it's medical, financial or educational, or where it is.  That is all about context.  Google data without context and see what you get: Dirt.  Noise.  Meaningless.

To give data context, you must put it together and organize it.  And when you organize it as whole, you give it meaning.  And now that you have a whole, organized collection of data, what do you want to call it?  I'd like to continue calling it a document.

There's nothing about documents that says you cannot extract data from them to create new documents.  We do that every day.  This blog post did that from at least eight different documents.

My take-away from Gary's comments (which are good ones), is that the organizing principles used to obtain the "documents", or set the context, that the IHE mHealth Profile is asking about are where we need to focus.  Setting the context provides "data about data", otherwise known as metadata.  John Moehrke has a great post about healthcare metadata.

So, my one question about the IHE mHealth profile that is prompted by Gary's post is this:  Did we get the metadata right in the queries?  As I look through the query parameters, I see that we have John's six different metadata categories covered.  Where the profile is weakest is on "Exchange metadata", and I think that's a forgivable weakness.  Patients and providers aren't interested in organizing content around exchange metadata except for some rare cases (e.g., operational metrics).

I think we are in a broad sense, in good shape with this profile.

And to answer my question"  Nah, documents aren't dead.  In fact, in the new world order, they just might be a bit more "living".

IHE Publishes 9 Supplements for Public Comment

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following supplement to the IHE IT Infrastructure Technical Framework for public comment in the period from June 5 to July 5, 2012. Mobile Access to Health Documents (MHD) This document is available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 5, 2012 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement. Comments should be submitted at http://www.ihe.net/iti/iticomments.cfm.   IHE Patient Care Coordination Technical Framework Supplements Published for Public Comment The IHE Patient Care Coordination Technical Committee has published the following supplements to the IHE Patient Care Coordination Technical Framework for public comment in the period from June 5 to July 5, 2012. Cross Enterprise Basic eReferral Workflow Definition (XBeR-WD) Cross Enterprise TeleHomeMonitoring Workflow Definition (XTHM-WD) Retrieve Clinical Knowledge (RCK) These documents are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 5, 2012 will be considered by the Patient Care Coordination Technical Committee in developing the trial implementation version of the supplements. Comments should be submitted at http://www.ihe.net/pcc/pcccomments.cfm. IHE Quality, Research and Public Health Technical Framework Supplements Published for Public Comment The IHE Quality, Research and Public Health Technical Committee has published the following supplements to the IHE Quality, Research and Public Health Technical Framework for public comment in the period from June 5 to July 5, 2012. Birth and Fetal Death Reporting (BFDR) Clinical Research Document (CRD) Clinical Research Process Content (CRPC) Newborn Admission Notification Information (NANI) Quality Measure Execution - Early Hearing (QME-EH) These document are available for download at http://www.ihe.net/Technical_Framework/public_comment.cfm. Comments submitted by July 5, 2012 will be considered by the Quality, Research and Public Health Technical Committee in developing the trial implementation version of the supplements. Comments should be submitted at http://www.ihe.net/qrph/qrphcomments.cfm.

Status Update, HL7 Working Group Meeting

HL7 created a new membership category for care givers that was announced this week.

Meetings on FHIR have been getting standing room only attendance throughout the week.

Structured documents will be balloting several items related to quality measures:

1. An update to the HQMF based on Query Health
2. An implementation guide on HQMF used with the Quality Data Model from NQF
3. An update on QRDA to support aggregated quality reporting (QRDA category II and III)

The first draft of CDA R3 will go out in a for comment only ballot.

A project scope statement for patient authored CDA documents has been developed and will likely also be balloted.

Canada Health InfoWay might be looking to develop a CDA implementation guide for the CDA Header, much like the General header in CCDA and the French DMP.

We may yet see a separation of presentation from the modeled data in CDA R3 which paves the way to use of XHTML for narrative (without microdata).

Templates is moving forward, and I've provided input on an exchange XML format based on a metamodel.

Mobile health is in the forming stages, but also getting traction.

The HL7 policy advisory committe is working on an HL7 response to the NwHIN RFI.

HL7 will be putting on a special education track for meaningful use at the September WGM.

HL7 mHealth Workgroup Meeting

The newly forming HL7 Mobile Health Workgroup met this afternoon in Vancouver to discuss the workgroup charter.  I went to the meeting today, and there's another one tomorrow.  I won't be able to attend tomorrow because I'm teaching about Templated CDA.

What follows are a few high points of the discussion.  There's probably a lot more discussion that the workgroup needs to have before they are able to develop a charter and start getting to work.

One of the challenges that the group faces is defining the scope of their activities.  The discussion led me to tweet about the distinction between healthcare devices that are mobile, and mobile devices that are used for healthcare.  From my own perspective, healthcare devices that are mobile is not where the challenge lies.  Instead, it is the mobile devices that are being used to support Healthcare.  To explain one problem, I whipped out my iPad, showed my blood pressure results in one app, and then my weight in another.  Those two chunks of data are so much more powerful together, but even though they reside on the same device, I have to do some serious hacking to make the data appear in one place.


We have hundreds of thousands of apps, but no mobile apps that can put the data together from these separate mobile apps in meaningful ways (except in proprietary clouds).  We have the ability to put all that data into the cloud, but I'm still stuck with the device maker's web interface to access and combine the data in meaningful ways.  There out to be an app for that, but the problem is that there are no standards that enable that capability.  And the cloud isn't helpful either if everyone has to have their own cloud, and the various clouds don't talk to each other.  After all, a cloud that cannot interact with other clouds is nothing more than a fancy way to put a silo in the sky.


Someone asked what the distinction is between mobile and distributed.  Again, from my perspective, mobile means it moves with me.  Distributed can be a part of mobile, especially when the device interacts with the cloud, but in my case, there's no cloud.  All the data is on my device.  But distributed can be "bigger iron" with more capabilities than the mobile devices have.

Someone pointed out that mobile devices are getting more capable, with better technology stacks, et cetera.  But, we cannot simply wait until they have the world's best technology stack before we address the need for standards.  If we do, someone else will have already solved the interoperability problem, and that is part of HL7's mission.  If we fail to solve it, we fail ourselves and our industry.  It was well put by one observer who said:  We need to foster a community of exchange and accessibility.

In order to define what the scope of the Mobile Health Workgroup is, we need to understand what the scope of mobile devices is.  We have devices with simple bluetooth, GPS and simple accellerometer capabilities, more complex apps that fit into a smart phone platform, or connect to it (e.g., to capture blood sugar results), and other apps that work in a tablet platform.  Each of these devices has certain capabilities.  Ideally, we'd find a taxonomy of mobile device types and related capabilities that could help us understand the space.

One of the issues that the workgroup discussed was the issue of security.  Mobile devices have a much different risk profile than other systems.  They are easier (and more desirable) to steal, harder to protect, et cetera.  It's much easier to lock down and manage laptops and servers than it is to deal with mobile devices, as John Halamka points out here.  Someone suggested that the Mobile Health Workgroup should perform an assessment using John Moehrke's Risk Assessment white paper.  John and I will both point out that was a collaborative effort, and that a lot of the content came from a Canadian Ad Hoc Harley winner.  It is very nice to see John's efforts to promote that effort pay off.

Once we have found (or created if really necessary) the taxonomy of devices and capabilities, we can perform a risk assessment that will help inform future mHealth efforts.

There's still quite a bit of forming and storming that needs to occur.  I don't expect a charter by the end of this week, but certainly before the next Working Group Meeting.  This is another place I'll need to pay attention.

HL7 mHealth Follow Up

This crossed my desk recently. HL7 really wants to be engaged in the mHealth space and is encouraging its members to participate.

---

HL7 Mobile Health Follow Up Join us for a Webinar on April 23 Space is limited. Reserve your Webinar seat now at: https://www2.gotomeeting.com/register/870359434 HL7 will hold its second Mobile Health Webinar on Monday, April 23, at 3 pm ET.  Chuck Jaffe, HL7’s CEO, and Austin Kreisler, Chair of HL7’s Technical Steering Committee, provide the introductory remarks on process and then will turn the call over to a small group of volunteer leaders who have been working on a draft mission and charter for this proposed new Work Group.  The draft mission and charter statement will be presented for review and comment, and time will be allotted for questions and answers. Those HL7 members interested and able to attend the call must register using the "Register Now" link above.  You must register for the call to receive the dial in and passcode.  Please refer to the Notes section below for important tips on successfully connecting to this HL7 Webinar. NOTES: When connecting to GoToWebinar, please remember the following: • Do not use Skype to access the Webinar audio • 15 minutes prior to the Webinar, it’s recommended that you connect to the Webinar so as to provide ample time for Citrix software to download.  The software download should only take a minute or two.  If it takes longer, cancel the session and reconnect • Remember to enter your Audio PIN, otherwise you will be in 'listen only' mode • If you do NOT log into the Webinar, you will be in 'listen only' audio mode (GoToWebinar does not allow a 'talking mode' unless you enter an Audio PIN, which is only shown after joining the Webinar) • To avoid creating feedback, do not use a speaker phone, especially if you'll be talking during the presentation • If you have issues connecting to the Webinar or with audio during the Webinar, contact GoToWebinar Customer Support at 1-866-962-6492 Title: HL7 Mobile Health Follow Up Date: Monday, April 23, 2012 Time: 3:00 PM - 4:00 PM EDT After registering you will receive a confirmation email containing information about joining the Webinar. System Requirements PC-based attendees Required: Windows® 7, Vista, XP or 2003 Server Macintosh®-based attendees Required: Mac OS® X 10.5 or newer

Join HL7 for a Webinar on mHealth

If you cannot figure what this is about, just consider that up until now, HL7 hasn't had a Mobile Health work group.  I strongly suspect that is about to change.  This call is limited to HL7 members only, so if you aren't a member, it might just be time to join ...

Keith

---

HL7 Mobile Health Join us for a Webinar on March 19, 2pm EDT Space is limited. Reserve your Webinar seat now at: https://www2.gotomeeting.com/register/775041466 HL7 members who are interested in mobile health are invited to an organization-wide Webinar call on Monday, March 19, at 2:00 pm ET.  The call will be chaired by Chuck Jaffe, John Quinn and Austin Kreisler. Those HL7 members interested and able to attend the call must register using the "Register Now" link above.  You must register for the call to receive the dial in and passcode.  Please refer to the Notes section below for important tips on successfully connecting to this HL7 Webinar. Those HL7 members who are interested in mobile health but unable to attend the March 19 Webinar are invited to register their interest using the link below: http://www.surveymonkey.com/s/78Y637K Any outcomes from the March 19 Webinar will be distributed to those who register for the Webinar or register their interest through the survey. NOTES: When connecting to GoToWebinar, please remember the following: • Do not use Skype to access the Webinar audio • 15 minutes prior to the Webinar, it’s recommended that you connect to the Webinar so as to provide ample time for Citrix software to download.  The software download should only take a minute or two.  If it takes longer, cancel the session and reconnect • Remember to enter your Audio PIN, otherwise you will be in 'listen only' mode • If you do NOT log into the Webinar, you will be in 'listen only' audio mode (GoToWebinar does not allow a 'talking mode' unless you enter an Audio PIN, which is only shown after joining the Webinar) • If you have issues connecting to the Webinar or with audio during the Webinar, contact GoToWebinar Customer Support at 1-866-962-6492 Title: HL7 Mobile Health Date: Monday, March 19, 2012 Time: 2:00 PM - 3:00 PM EDT After registering you will receive a confirmation email containing information about joining the Webinar. System Requirements PC-based attendees Required: Windows® 7, Vista, XP or 2003 Server Macintosh®-based attendees Required: Mac OS® X 10.5 or newer

---

Give it to ME

I've been reading quite a bit about all of the consumer oriented mobile health apps that have shown up lately.  There's been a lot of buzz around this especially given the recent Consumer Electronics Show that just concluded (thankfully).  There's also been quite a bit of discussion about a recent mobile health app that works with Health Vault.

All these apps are simply creating new mobile silos of information, or worse yet, requiring us to go through some third party cloud storage in order to manage and view it.  I want my damn data and I want you to give it to ME so that I can analyze it.  It's my health.  Let me do with the data what I want easily, without having to hack my tablet, or use your website.  At the very least, give me the ability to export the data to a spreadsheet.

Patients (and consumers) want to use a variety of different applications.  We want to be able to collect that data and do stuff with it.  Right now, I've got two separate apps, one to track my weight, and the other to track my blood pressure.  In order to see the impact of one on the other, I've got to go through quite a bit of gyration just to put it together in one place.

Role Reversal

He walked over the where the man was pointing at the screen, looked and asked to see the data.  The two of them reviewed the blood pressure results for the last month, looking at the overall pattern, and individual measure results.  They compared this month's average on a beta-blocker against the prior month's without it.  Scrolling through the months, clearly they could see there were no statistically significant results between the two.  Then they looked at the heart rate data.  That showed a clear, nearly 10 bpm average drop, so the drug was doing something.  Next the two of them looked at weight data for the last 30 days.  It's November, and the patient definitely followed the "thanksgiving" pattern of gaining several pounds.  Looking back to Halloween, they could even see a bit of a gain trend starting there.

It was pretty clear what was needed.  The patient has to drop a few pounds gained over the holidays.

This wasn't fiction, it was real.  I was at the doctor's office yesterday, and the guy with the computer was me.  Next year, I'll be able to send him that data so he can look at it ahead of time.  Have I said recently that I love my doctor?

Update from IHE

Three IHE Domains meet this week to discuss work items to move forward:  IT Infrastructure, Patient Care Coordination, and Quality, Research and Public Health.

I put together a profile proposal now named "Documents for Mobile Health" which was submitted to IT Infrastructure.  I wrote about this back in September.  The updated detailed proposal (ftp to word document) is more simplified than the original proposal, and was recommended to move forward as a work item by that committee.

Patient Care Coordination reviewed four work items:

1. Cross Enterprise eReferral Workflow
2. Cross Enterprise Telehealth Monitoring Workflow
3. Retrieve Clinical Knowledge (see this post)
4. Nursing Whitepaper

The two workflow proposals overlap (they both require eReferral), and involve developing content profiles for Cross Enterprise Document Workflow (XDW) to support workflows.  One of the committee members pointed us to a great paper on Case Handling  (pdf) that seems to be really well aligned with the XDW Profile itself.  We (PCC) plans on producing a white paper for public comment in the February time frame to document how we plan on approaching XDW based workflow profiles.

Tomorrow I'll be teaching a customized CDA class to a number of IHE profile authors.  It covers the same material as I usually teach, but then adds in the IHE specific "how we do things", and references the IHE templates that are already developed.  I'm looking forward to it.

IHE XDS for mHealth access to HIE

I submitted (late) a proposal to the IHE IT Infrastructure workgroup a proposal for an IHE Profile titled XDS for mHealth.  I was graciously given time by the planning co-chair to present it even though it was submitted late, to allow the committee to understand it, and determine whether or not to accept it as a late submission.

The committee did agree to accept the proposal through the process, and so now I'll explain it a bit using the same presentation materials I used this morning, just reformatted for this blog.  The next step is to see if it makes the prioritization cut at the October 11-12 IHE ITI Face to Face meeting.  There are 3 other profile submissions and documentation maintenance work to consider.  Ensuring that the committee has identified resources who are willing to work on it is very important in this next step.  After that, it has to make the technical committee cut with respect to "do-ability".  I'll shortly be working on a prototype to show that it is in fact feasible.

If you aren't an IHE member, but want to support this project, join now (it's free).  If you are a member, please show up to the face to face meeting I mentioned above.  I expect there will be T-con access for members who cannot be present at the face to face (there usually is).

  -- Keith

---

Support for XDS in mHealth Evironment

The Problem

•  mHealth platforms are resource constrained
•  SOAP Stack missing or buggy (e.g., WSDL support for Objective C)
• Bandwidth constrained (10Kbps to 10Mbps)
• Limited resources (e.g., memory), often no “back-end” server
• Increasing proliferation of unconnected apps
•  ~9,000 consumer health apps¹ in Apple’s App store
•  ~13,000 by 2012
• mHealth is an emerging market, failure to support this space could reduce relevance of IHE
• Difficult to use XMLHttpRequest for browser-based, multi-platform mHealth apps.

¹Source: MobiHealthNews http://shar.es/HMlff

Use Case

1. Patient sees a specialist for a particular condition.
2. The specialist asks for detailed information from the patient.
3. The patient, not remembering their list of medications, pulls out their mobile device and activates an application.
4. The application queries the HIE and retrieves a list of clinical summaries in date order, from most to least recent (or on-demand medication list document).
5. They select the most relevant document, and it is downloaded to the device.  The application extracts and displays their medication list.

Proposed Standards & Systems

Standards

• XML
• XDS Metadata
• ebXML
• XSLT
• JSON, JSON Schema
• XMLHttpRequest
• OHT APIs (not really a standard, but a place to start from)

Systems

• EHR
• PHR
• Patient Portal
• HIE
• Mobile Device (iPhone/iPad/iPod, Tablet, Android, Smart Phone, Windows Phone, etc.)

Discussion

• There has been substantial work already in simplifying the XML in OHT, that could be used as one basis for the effort.
• Metadata could be transformed from a simplified representation to ebXML representation using XSLT.
• Transactions could be optimized to use W3C standard XMLHttpRequest object.
• Below is one example of how the actors and transactions could be organized:

Rambling from the HL7WGM

Lots of new irons in the fire this week.  Like Grahame's Resources for Healthcare proposal, the HTML5 + Microdata proposal is gaining traction.  Not overwhelming support like Grahame's work, but significant forward momentum.  I'm working on updating a Project Scope statement for ITS to review in a subsequent meeting.  I now need to reach out to my former standards community (HTML and XML geeks), and start really coming up to speed on what is going on in that space.  I just finished writing a position paper I hope to present next month at a W3C Workshop in the Boston area comparing HTML5 + Microdata with CDA Release 2.0, noting the gaps and opportunities.

I will also be presenting an EHR Functional Profile proposal to the EHR TC next week to rapidly develop a functional profile supporting metadata expression requirements for exchange with HIEs.  This is an action item that the HL7 Policy Advisory Committee (PAC) will put into their response to the ONC Metadata ANPRM that I've written about several times over the last few weeks.  Many committees have provided input to the PAC's proposed response to that ANPRM, some were working on it even before the committee requested feedback.

One very quick and easy win this week from the PAC perspective was the recent HL7 announcement that it has taken ONC's Pledge for Non-Data Holders, and its encouragement for members to do the same. There will be an HL7 newsletter article going out on that soon as well.  This happened relatively quickly, the time between ONC announcement of the pledge, my presentation of the proposal to the board, their response and announcement through a press release was under 48 hours.

On other notes, I will never live down the time we spent talking about a real problem implementers have raised, and which I commented on in the CDA Consolidation ballot, about how to deal with people with only one name (now dubbed the "Rock Star" problem).  I don't mind, we now have sufficient guidance I can point to.  One time might be an oddity, but this was a question I have seen from three different sources in as many weeks.  The answer is pretty straightforward.  Put the single name where your organization requires it to go, and use a nullFlavor for the other components.  Doug Fridsma even had HL7 staff print up a badge with name and organizational details all saying "Not Applicable".  I can deal with it.  In fact, I have a "Rock Star" ribbon for him to place under that badge.  I don't need them any more as I will probably never wear one on my own badge again (at least at an HL7 meeting) ;-)

I taught the CCD class again this meeting.  I've used pretty much the same material for the last 4 years.  I'll need to update it for January, and again for May to address changes in CCD 1.1.  Yes, CCD 1.1 is part of the CDA Consolidation Guide activity.

There are yet more irons in the fire.  I have a mobile-health profile proposal to present in a couple weeks to a very hard audience, the IHE IT Infrastructure workgroup.  It addresses a use case for software stack constrained platforms often used for mHealth applications that want to access information from a Health Information exchange.  I expect lively discussion.

Having just finished teaching CCD to a group of students, I have to prepare for my next teaching event.  IHE will be offering a day of CDA training (limited seating) to members after the November Face-to-Face.  This will be a new class because my goal will be to teach members how to create CDA-based IHE profiles.  That should prove to be an interesting combination.  By offering members this opportunity to enhance their skills, I'm hoping to scale up.

Hacking my data

This post was spurred on by @NateOsit's comments about QS apps earlier today.  The conversation ended with this tweet (you can see the whole conversation in reverse order by clicking on the time/date of the prior tweet that each was in reply to).

One of my recent acquisitions was an iPad 2.  I purchased it from proceeds of my advance for The CDA Book.  I also got another toy, an iHealth Blood Pressure Monitor (I'm at risk for hypertension), and an app that lets let track my weight. These are both problems my father suffered from, and in part they contributed to his death, so I'm paying attention to them.  And, because like my father, I also have white coat syndrome, my BP is higher in the office than the rest of the time.  Having the BP monitor and a record to show my doctor has kept me off BP meds thus far.  But it's also made me more aware of my blood pressure.

One of the things that I don't like about the iPad, or most of the apps for it, is how difficult it is to get data out of them.  But then I ran across this article by Adam Crosby.  It explains how to find the files that are on my PC that correspond to files on my iPad.  It also suggests that many of them are easy to hack.  So, I went digging.

If you have an iPad and a Windows PC (like me), you can find the backup folder in a place something like C:\Documents and Settings\YourUserName\Application Data\Apple Computer\MobileSync\Backup\SomeLongHexString

That folder contains a file for every data store on your device.  For me, that folder contained more than 100,000 files, and took about 30 seconds just to list the directory.  Almost all of the files are named using a hexadecimal string.  Trying to find your data in all of this for any given app would seem to be a nightmare, but it really isn't that hard.  It took me about an hour.  Most of that was waiting time.

1. Close all of your iPad apps, or shut down and restart your iPad.  This step makes sure that only files you want are changed.
2. Sync your iPad with your PC
3. Make a copy of your backup folder somewhere else.
4. Twiddle your thumbs, or catch up on your RSS Feed while the disk churns.
5. Open the one app whose data files you want to find.
6. Change some data in it, and close the app.  Know what data you had and what you changed it to.  This could be important later when trying to decode the data.
7. Resync your iPad.
8. Make a copy of your backup folder again, in yet another location.
9. More thumb twiddling.
10. Using WinDIFF or other directory comparison tool, locate the files that have changed.
11. Reread war and peace.  This takes a while. (Don't really worry about the time, it took me longer to write this post than this whole process, and that was less than an hour).
12. Copy those files (there should only be a few) to another folder.
13. Do it again!  There's a reason for this, because you are going to modify some of them.
14. Now, go find plutil.exe on your computer.  I found it in C:\Program Files\Common Files\Apple\Apple Application Support.  This is a utility that lets you unpack binary PLIST files.  PLIST is an XML format for property lists, somewhat like the Windows Registry, but in an XML format (I mentioned it briefly in this post).  Binary PLIST is a compressed format that the plutil application can make readable for you.
15. Next, download a tool that will allow you to access SQLite databases.  This one worked just fine for me.
16. Now, dig through the files that you found that changed.
1. Some of them will likely be in PLIST format.
2. Others will be in binary PLIST format.  These can be detected by the presence of "bplist" at the type of the file.
3. Others might be in SQLite format.  These can be detected by the presence of "SQLite format" followed by a version number.

The files in PLIST format you can just decode yourself.

The files in BPLIST format you need to unpack using plutil.  Assuming you've added PLUTIL.EXE to your path, the command to "unpack" is PLUTIL -convert xml1 FILENAME

The files in SQLite format you will need to export to a CSV or other file format.

Once you've found your files, remember those nasty hex strings for them.  They'll be in the same place the next time.  So now you can start dumping data.

For my iHealth, the data file I wanted was in PLIST format.  It looked something like this:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<array>

 ...

<string>34</string>

<string>07-07-2011</string>

<string>08:10</string>

<string>117</string>

<string>79</string>

<string>65</string>

<string>6</string>

<string>1</string>

<string>0</string>

<string>0</string>

...

</array>

</plist>

The format is a big array of strings.  Each measurement has 10 strings.  The first is the measurement number.  The next two are date and time.  The next is systolic, followed by diastolic, then heart rate.  I haven't figured out the next four, but they don't much matter to me yet.  I can create an XSLT to reformat this into an HTML table, which I can then import into a spreadsheet and start graphing.

For the weight measuring app, it tracks four numbers in a SQLite database.  The userid (it can be used with multiple users), the date (recorded as the number of days since January 1, 2000), the weight, and something they call my "true weight" which appears to be a formula used to generate some sort of weighted moving average.  My weight is clearly recorded in grams (the app displays weight in lbs, stone or kg).

So, now I need a command line tool which will automate the export of the SQLite table file.  Another quick web search finds this collection of utilities.  The shell is what I want.  I can easily script that to load the file and dump its contents.

So now I can hack my data.  While I hate the iPad's closed architecture, one thing I do love is how easy it is to hack the data from it.  I think I'll turn this into an app to generate a table of values in HTML 5.  Then I'll add microdata tags based on my CDA R3 proposal.  Next I'll write some Javascript to plot the data  on a canvas with some pretty colors by getting at the raw figures in the Microdata.

If I can find a browser that supports the microdata DOM, I could have this app ready in time for next week's HL7 Working Group meeting.

IHE Week and FDA announces mHealth regulatory approach

Another IHE Week, this time preparing Trial Implementation Profiles. I'm on the hook for Reconciliation, and we have another couple dozen comments to go.  One of the surprising responses from commenters is that the profile should REQUIRE that external identifiers for problems, medications and allergies be preserved.  That is going to result in a quite a bit of new text (now I have to explain what changes the identity of an entry).  I'm pleased with this response.  We made it a strong recommendation, but not a requirement because I felt that many EHR vendors would not implement the profile if it were required.  Most systems would need to alter their basic tables to record the external identifier.  But experience with prior implementations indicates that this really is the best way to handle it, and I certainly agree with the sentiment.

I spent a good bit of time with IT Infrastructure on Monday discussing Cross Enterprise Document Workflow (pdf).  This profile is critical for Patient Care Coordination, even though it is coming out of IT Infrastructure.  Here's a brief pitch I'm giving on it tomorrow for another group:

• In Ambulatory Care, providers are desperate for Workflow Management to track referrals, orders, and manage quality of care.
• But their workflows are loosely coupled and ill-defined.
• These need to integrate with well defined, tightly coupled workflows in a departmental system (e.g., imaging).
• XDW uses industry workflow standards to describe Human Tasks that can be well integrated across both settings.

The replacement of CDA with Human Task as the standard to manage the tasks is more than appropriate, and @rjhorniii has done a great job leading the discussion, and getting me and one of my colleagues to agree on an approach.  You can expect some significant changes to the public comment version to come out of this meeting.

---

While at the meeting, the FDA came out with a proposed regulatory approach for mHealth devices and applications.  I haven't had a change to do more than skim it once.  I'll look over it in greater detail later.  One of the tweople I follow expressed surprise at the exclusion of Mobile devices being used as an EHR.  His interpretation was that EHRs were not medical devices.  In case you are curious, they also excluded EHRs from the Medical Device Data System rule.  It's not that EHRs aren't medical devices.  It's that FDA carefully classifies things so that something doesn't fall into competing classifications.  They may be issuing separate guidance on EHR systems, so they exclude anything that can be viewed as an EHR from the other rules and guidelines.  That way, when the EHR rule comes out, it will be clear WHICH regulations and procedures apply.