mHealthSummit 2012

I'm in DC for IHE meetings tomorrow and Wednesday, and giving a session at the 2012 mHealthSummit Wednesday afternoon on Trends on Mobile Interoperability and Standards.  I scheduled my travel to attend the IHE educational session being held today, but decide to take advantage of by mHealthSummit badge today to take look at the conference instead.  I can listen to Charles talk about XDW any day of the week, after all, I work with him.

The keynote presentation was kicked off by Steve Lieber of HIMSS.  HIMSS acquired the summit from The Foundation for the National Institutes of Health early this year, so having Steve Lieber give the opening remarks made sense.  Following him were Mark Bertolini of Aetna and then Harry Totonis of SureScripts.  Frankly, both speakers were good, but they also spent so much time patting themselves on the back that I thought they were going to break their arms.  Next year I hope we see Keynote speakers that are more innovative in this space.

Mr. Bertolini had quite a bit to say about Aetna's efforts on their CarePass™ Application Platform. He touted the fact that it is freely available and therefore "non-proprietary".  It's a good thing they don't let the audience ask questions of the keynote speakers, because I'd have had one about where he got his definition of non-proprietary from (not protected by trademark or copyright).  Then again, standards aren't his business, so maybe I need to give him a break.

I suppose too, that I also need to give Mr. Totonis a break for bringing up the inevitable comparison to the financial industry, as that reflects his prior business experience.  I've heard this comparison far too often.  He talked quite a bit about how many transactions that SureScripts does, and how it has saved tons of money for prescribers and pharmacies, and improved health.  My challenge here is what this has to do with mHealth.  mHealth is, after all, the use of mobile technology to deliver healthcare services.  While I can see the CarePass connection, I was a little lost on what SureScripts had to deliver for mHealth.

The exhibit floor took up about an acre.  I made my first visit to booth #1224 to see Regina Holliday live painting jackets for The Walking Gallery.  Unfortunately, she was still caught in DC traffic, so we connected up later.  Unfortunately, if you didn't see her today, she's not here tomorrow and Wednesday.

The exhibit floor was an interesting collection of vendors and exhibitors.  It included:

1. Startups so raw they had the smallest space possible, no fancy graphics and one or two people hawking their concept,
2. Consultants on registering medical devices with the FDA, 
3. Educational institutions doing mHealth research,
4. Organizations making any sort of small, wireless devices,
5. Consumer facing device manufacturers,
6. Companies pitching mobile app development frameworks,
7. Companies pitching mobile app development,
8. Organizations pitching their "open source platforms" for mobile apps,
9. So many organizations pitching their "HIPAA compliant" secure messaging solutions that I later just had to tweet:  "Until providers understand that HIPAA compliance is a property of an organization, not a product, we won't have adequate security"
10. Almost anything medical with a wireless radio,
11. Wireless radios (designed for the healthcare environment),
12. Security and provisioning solutions for wireless environments, devices ... (see HIPAA Compliant discussion above).
13. Disease specific programs that used SMS texting, apps, tablets, or anything with a wireless radio,
14. At least two mHealth vendor association wannabees,

It was such a cornucopia of stuff, and it seemed that the only thing holding it all together was that it had to somehow be connected (or powered) without wires.  In fact, it was all connected by not having to be connected...

I was intrigued by one poster at the poster session, on tracking patient safety events as reported through twitter.

I attended the session titled "Can you understand me?  Interoperability and Standards", and sat in the front of the room (in case any of the presenters needed to be heckled).  Aaron Goldmuntz (West Health) made my day by saying that we had enough standards, and simply needed more implementation.  I have to agree (and did at length here).  Charles Parker gave a great overview of Continua without any slides (due to AV operator challenges), Erik Pupo (Delloite) did quite a creditable job describing Direct, Consolidated CDA, and IHE's Mobile Access to Health Documents (even if he decoded the acronym incorrectly), and Dennis Seymour (Ellumen) explained quite well the purpose of MDS2.  

Deborah Estrin (Open mHealth) attracted my one difficult question.  She presented on Open mHealth, which is an architectural framework for building mHealth Apps.  It was pretty clear from her presentation that she probably couldn't name any mHealth standards if I quizzed her.  I asked her if Open mHealth was an SDO, and if not what relationships the organization had with other SDOs.  It was an either/or question, so she gave the geek answer: Yes. When I further queried her, she made it clear that Open mHealth didn't have any formal connection to any standards organizations.

I need another SDO wannabe like I need another hole in my head, so I made a point to follow up with her later.  When I showed up at the Open mHealth booth, Deborah made a point to let me know she was kicking herself with how badly she'd handled my question, but was deep in conversation with someone else.  So I quizzed the booth folks, and her colleague Ida Sim showed a remarkable awareness of what was going on in the Healthcare standards space.  She made me much more comfortable with where Open mHealth is headed.  There are some good ideas worth watching here.   I pointed Ida to the FHIR workgroup mailing list (see fhir under Technical Steering Committee), because while she knew what it was, she didn't know where to go to get more information.  I may have to follow up on that group later.  I still need another group to follow like I need a another hole in my head, but at least this one is not likely to reinvent a square wheel...

I did catch up with Regina later, and got to be a booth babe (at least I have the hair for it) for a bit with Regina and @ctorgan (photo by @ElinSilveous).

I dropped by the IHE Interoperability Showcase, but couldn't stay through a demo (I had to run off to an HL7 call).  I did catch up with some of my IHE buddies, and they have an exciting announcement that I'll talk about later this week.   

How to I tell you this? It may be what you do, not your software

One of the biggest challenges of a technologist like myself is trying to explain to a physician that there may be a better way to do things.  This came up on the #HITsm tweetchat today in Question 3:

#HITsm T3: How important is understanding culture and organizational workflows to achieve coordinated, seamless care?
— HL7 Standards (@HealthStandards) November 30, 2012

And my response was: Sometimes you need to understand the workflows just to tell providers what is wrong with them.

A perfect example of this showed up the other day as I listened to members of a House Subcommittee talk about Health IT and the Meaningful Use program.

If you list to this video around 1:11:35, you can hear an anesthesiologist explain how he cannot do med/med/allergy interaction checking on his patients in the operating room.

I'm not a Doctor, but I do know that most surgeries are scheduled well ahead of time.  I also know that the anesthesiologist has a pretty good idea of what medications he or she may be using.  It isn't Health IT that is broken here.  It's the workflow that's broken, and perhaps even the culture. If you can identify the problem, surely, you can figure out a solution.  The first thing that comes to my mind is to check for interactions using the EHR pre-operatively.

When your workflow doesn't work with your technology, perhaps it's not your technology, but rather your workflow that's broken.

Standards REMIX

In response to a comment on this morning's post elsewhere, I just HAD to do this REMIX of a popular XKCD strip:

Thanks to Randall Monroe (creator of XKCD) for being so free (and so clever) with his content.

Changing the Way Standards are Developed

ONC has been arguing for some time that we need to change the way that standards are developed.  From their perspective, the process takes too long, and doesn't result in sufficient implementation.  I have to agree that standards development processes that JUST focus on producing the standards aren't as successful as those which produce working code.

Most standards bodies recognize this.  For example, W3C requires at least one and prefers two implementations of each feature to advance to publication as a W3C Recommendation (standard).  OASIS requires three statements of use before advancement to an OASIS standard.  IETF requires two implementations to move to draft standard level.  IHE requires successful Connectathon testing of three separate implementations, in two different regions, with tests covering all actors at at least one Connectathon.  HL7 has a requirement to identify at least two implementers for projects on the Standards track, but doesn't have formal evaluation of implementations process that is consistently applied by work groups before advancing to DSTU or Standard.

The Direct Project started by ONC was intended to change that model, and became the pattern for what the S&I Framework does today.  There's a lot more focus on working code, pilots and implementation at the same time as specifications are being developed. But there are some limitations to these initiatives as well.

Neither the Direct Project, nor the S&I Framework is a Standards Development Organization.  These are simply ONC funded and coordinated projects.  To be successful, they need to work with organizations like HL7, IHE, IETF, WEDI and X12 to further develop the specifications as Voluntary Consensus Standards.  While Direct worked with IHE (see Support for Metadata Limited Document Sources) and used some IHE specifications (XDR and XDM), the core Direct Applicability Statement still needs to go through the IETF process (which it was targeted for) to ensure continued maintenance, and validate the consensus achieved.  At present, the "owner" of that document is still the "Direct Project" as far as I can tell, and I've heard nothing about advancement of it through IETF as was intended.

In S&I Framework, there has been more cooperation with SDO's, and key specifications like the Consolidated CDA (which was rolled into the Transitions of Care initiative), HQMF Release 2 and QRDA Release 2 (used by Query Health), Health eDecisions, Laboratory Ordering and Reporting and others being coordinated with an HL7 Ballot.  Other initiatives, such as the ABBI project, have yet to develop any sort of formalized relationship with IHE or HL7.  Members of both of those organizations have done significant work and are planning more which could advance the goals of the ABBI project.

The much celebrated success of the Direct Project is often overstated, both in terms of time and number of implementations.  Overall, the Direct Project was "completed" in the same time frame as an IHE profile, or an HL7 DSTU.  What it did result in that IHE and HL7 don't always succeed in is the development several implementations very quickly.  There's at least one open-source, and several commercial offerings.

What is missing from the celebrated successes are two factors.  The first is the time ONC spent in advance of the project setting things up.  Because most of us never saw it, ONC gets away with not reporting it when they talk about timelines.  Add 3-6 months to each ONC project before it ever gets off the ground in a public way, and you'll have a better idea about time spent.  This same kind of time is also spent in HL7 and IHE advancing new projects.  We have a much better record of what happens, because it is all done openly and transparently.  Yes, you do have to be a member to see all of the detail, but much of it is freely available to the public in both IHE and HL7.  To be part of starting a project in S&I, you need to be invited to the table (or a White House Meeting) , and even then, the agenda is often pretty well established before you arrive.

With regard to implementations, well, ONC has a few levers that SDOs don't.  The first of these is that it is a regulatory agency.  Anyone who is paying attention is aware that standards that go through the S&I Process are likely to be cited in regulation.  And once cited, well, that pretty much creates the demand and a market for implementations.  The other lever is money.  ONC had plenty of money invested in State HIEs (more than $500M).  Through these they were able to control WHAT the state would implement with respect to HIE technology.  Several Directors of State HIE programs told me about the pressure that ONC was placing on them to implement the Direct Project specifications, to the exclusion even of other plans, some of which had substantial development investments.

The S&I Framework itself evolved out of something like 11 different contracts.  Given the time and staffing involved, I estimate that ONC spent between $10M and 20M over two years, and I've probably undershot.  Some of that was spent on development, implementation and testing resources.  When you have that kind of leverage, it makes for a very responsive market with respect to implementations.

The "big money" [the initial $2B given to ONC] ran out in September of this year, so any continuing work on S&I Framework comes from ONC's operating budget.  We'll see how well S&I succeeds in the coming year since it's no longer possible for ONC to trade money for time.  There has been lots of great work developed through S&I, and I even include Direct in that, but there are some things where it could be greatly improved.

1. More transparency and openness in the governance of what projects are done, and how they are selected and initiated.  This is ONE of the key failings of S&I (and Direct) in openness.  SDOs have an open and transparent process NOT just to create standards, but also in selecting what standards to go forward with.
2. Greater collaboration with MORE standards bodies.  I love some of the activity that is going on with HL7, but ONC has yet to establish a relationship with IHE International, which has the lowest cost membership model of any of they SDOs they've worked with thus far (it's free).  My hope is that ONC will join us next week (they've been invited) to discuss profiling of OAuth 2.0 for Healthcare uses.
3. Documentation  of project procedures and greater consistency across initiatives.  There's too little documentation of process, and too much inconsistency across projects.  As someone who's been involved in numerous S&I Projects, I'm still confused about process when I join a new project.

As a final note, just in case you think that outputs of the S&I Framework are standards (without the assistance of an SDO), or that it is itself an SDO, the Federal Government wouldn't.  See OMB Circular A-119 on the definition of Voluntary, Consensus standards.  ONC is a Federal agency, not a private sector organization.  And the process they use, while it includes consensus in some parts, doesn't in the selection of projects to move forward.

S&I Framework will need the ongoing assistance of SDOs like HL7, IHE, WEDI and others to continue to move forward in creating standards.  Without them, what ONC will create is what Direct is today, "A Government Unique Standard".

  -- Keith

Ack, Nak and MAC

ACK is short for Acknowledgment.  There's even an ASCII code for it (6).  Along with ACKs, there are also NAKs (ASCII 15), or Negative Acknowledgments.  Related to ACK and NAK these are MACs.  ACK and NAK are used in messaging to communicate understanding (or lack of it) to messages that have been send.

Message Authentication Codes (MACs) are used to ensure that the message sent between two systems is communicated ungarbled.  A MAC is usually a computation over the message that produces a short code.  When the same computation is performed over the data on the receiver side, if they don't get the same code, they know the message didn't come over correctly.  The simplest of these is an XOR over all data bytes.  Other more complex computations include CRC, and cryptographic algorithms such as SHA-1.  These all operate pretty much at the syntactic or even lower levels of granularity in the transmission.

When messages are sent by computer, the MAC is computed and sent by the originator.  If the message is good from the receiver's perspective, it sends back an ACK.  If not, it sends back a NAK.  In early communications protocols, these messages used the ACK and NAK ASCII characters, but these days they are a bit more complex.

Humans use ACKs, NAKs, and MACs too, but differently.  It's fairly common in various leadership training classes to hear experts talk about listening skills.  One skill that is often taught is reflecting: Responding back to the speaker in your own words your understanding of what they just said.  It's also a skill taught to messengers and other communicators.  While it requires some level of practice, this is still pretty easy to do between humans.

The protocol goes something like this:
MSG: Speaker: "..."
ACK: Responder: So, [MAC = essential points from ... above], right?
ACK: Speaker: Right.

OR

MSG 1: Speaker: "..."
ACK: Responder: So, [MAC = essential points from ... above], right?
NAK: Speaker: Wrong.

Communication could stop here, but more typically, we fall back to a different level of communication:

MSG 2: Speaker: re-explains ... in a different way
ACK: Responder: Ah, so [MAC = essential points from ... WITH correction].
ACK: Speaker: Right.

The point of reflective listening is that the essential semantics are conveyed back to the speaker, but the definition of essential is focused on the original speakers point of view.  The MAC is never communicated, because we leave it up to the responder to figure it out, and the speaker to evaluate whether they got it right.

This isn't very easy at all to do between computers.  IEEE originally defined interoperability as:

... the ability of two or more systems or components to exchange information and to use the information that has been exchanged.

(NOTE: The new definition is slightly different):

A key point in this definition is that the information being used by the receiver may not be what the sender considers to be essential.  [This leads to an interesting correspondence to the term "secondary use", which describes cases in which how the receiver uses or considers data varies from how the sender was designed to use or communicate it.]

It is fairly common in messaging environments to reflect back the original content received, perhaps (in a few cases) removing that content that wasn't stored or acted upon by the receiver.  This becomes a "Semantic MAC", indicating what parts of the message were successfully communicated.  But often, we don't ever get that feedback, or as many implementations do, we just get copy the content received without any evaluation of it.

Of what use would a semantic MAC be in Healthcare IT?  Consider my youngest daughter's story (starting at 1'25'')  about getting her ear drops.  If the receiver of the e-prescribing message had sent back a "semantic MAC" that indicated what would be given to my daughter, the sender would have known that it didn't understand what ear drops should be given.

Doing this would be very complicated.  The problem is that the final receiver of the message is often several systems removed from the sender, and the content of the message wouldn't even be inspected until after the sender had moved on to other things (possibly long after).  The original message sender may not even be accessible to the final receiver (and vice versa).  This is why HL7 supports both message acknowledgments and application acknowledgments to messages.  The former validates syntax, the latter semantics.

The challenge with application acknowledgment is that in order for it to be effective, it has to be communicated to the originating system, not to the message deliverer, and the sooner the better to avoid the need to retain the sender's context.

When you receive a nice gift through the mail or UPS, do you thank the driver or mail carrier?  No, you write a thank you letter (or e-mail) to the original message sender.  And if you receive a package you didn't expect, the most effective thing to do is contact the sender to ask what it is and why you are receiving it.  Asking the delivery driver why it showed up won't help you.  If you receive a package at 5:00pm on the west coast from a business on the east coast that closes at 6:00pm (EST), trying to call them to find out what happened won't succeed until the next day, when they open up again.  This reflects another challenge of application acknowledgments, which is that the message originator may not always be available when the receiver is ready to acknowledge the message.


You might think it would be easier if every system was always on and always accessible over the interwebs so that we could avoid the need for store and forward.  But few store and forward systems do just that.  Often they add value to the communications, reducing costs and increasing effectiveness in other ways.


There is no guarantee of immediacy in the communication between the message originator and the final receiver of the message.  To resolve this issue, we  take additional steps to ensure that communications are not garbled semantically when the standard is developed.  When a standard is designed, we decide which parts of the content are essential by marking them as being required, recommended or optional.   These terms describe the "essentialness" of the elements in the communication.


I get numerous questions about whether a given component of a CDA document, or XDS message, or other standard HAS to be present, or if it can be null.  There's no amount of documentation in the standards that will eliminate these questions.  The reason for that is because even though these standards are developed through consensus, some systems just won't be able to support them without being changed.  Change is hard, and has costs, and many would like to avoid it.

If you are a message sender, try to put yourself in the receivers shoes.  They need to be able to clearly understand what you've communicated.  If you omit stuff because it is hard, you make the job of the receiver even harder.  Most of the Health IT communications today are not really dialogues, but rather a sequence of monologues.  So you have to make sure your communication is clear, the first time.

Hashtag Soup: Relating QDM, HQMF, eMeasures, QueryHealth, QRDA, SIFramework and MeaningfulUse Stage2

This showed up in my inbox yesterday:

Hello Keith, 

I am trying to figure out how the following abbreviations are connected - NQF's QDM, HQMF, eMeasures, Query Health, QRDA, QDM based QRDAs, others.
Rather than individual definitions, I am a bit in the dark around how each of these are interconnected.

Appreciate your help.

Warm Regards, Shyam 

It's a question worthy of a full post, rather than a brief answer, so here goes.

---

QDM is the National Quality Forum's (NQF) Quality Data Model.  It is an information model representing the essential data needed to generate quality measures.  Because it is an information model, it doesn't necessarily go into the level of detail needed in an implementation, but it certainly describes the high level structures that an implementation needs to compute quality measures.

eMeasures is a term describing the electronic representation of quality measures.  In common use, it often refers to the electronic measures that NQF developed to represent the quality measures required under the ONC & CMS Meaningful Use regulations.  It is also used to refer to the HL7 HQMF.

HQMF stands for Health Quality Measure Format.  This is an HL7 Draft Standard for Trial Use (DSTU).  The DSTU is presently being reballoted by HL7 for a second release.  This is an electronic format for the representation of quality measures.  Release 1 is currently used by NQF to deliver eMeasures for Meaningful Use.  Release 2 was developed in large part based on pilot work being developed by Query Health.

Query Health is an ONC Standards and Interoperability Framework project whose purpose is to develop standards to enable sending the questions to the data.  Its key goal is to enable clinical research.  We used HQMF in query health because the kinds of questions that Quality Measures need answers too are often the same kinds of questions that show up in Clinical Research.  HQMF is a declarative format for expressing those questions.  We revised and prototyped a new schema for HQMF that is simpler, easier to read, and able to be computed in a variety of programming environments.  I've written quite a bit about Query Health on this blog.

QRDA stands for Quality Reporting Data Architecture.  If HQMF/Query Health/eMeasures represent the question, then QRDA represents the answers.  QRDA is an HL7 implementation guide on CDA Release 2 that describes the format for reporting quality data on a single patient (Category I), or aggregate results on multiple patients (Category III).  The former is a DSTU, the latter nearly so.  There is also an implementation guide showing how data modeled using the QDM can be represented in a QRDA.  Both Category I and Category III specifications have been identified as being required standard formats for reporting quality measures under the Meaningful Use 2014 Certification Criteria.

MAT is the Measure Authoring Tool.  This is a tool for creating eMeasures currently being maintained by NQF, but which will be transitioned to a new maintainer in early 2013.

VSAC is the NLM Value Set Authority Center, where value sets used for eMeasures and other standards used in Meaningful Use regulation are published.

If you want a poster-sized PDF of the content, you can get it via Google Drive:

What-duhl?

WADL stands for Web Application Description Language.  It is a member submission to the W3C by Sun Microsystems (now Oracle), written by Marc Hadley (now at MITRE).  WADL is to REST as WSDL is to SOAP, which interestingly enough, makes it both a useful documentation and code generation tool for RESTful web service development, and anathema to the RESTful in-crowd (of which, I'm apparently not a member).  I'd also note that you can use WSDL for the same purpose (which is apparently even worse).

WADL isn't a standard, but it was certainly meant to fill a gap in standards for RESTful web services.  I've been playing around with WADL a bit to define and document the ABBI protocol.  What I found useful about WADL is that it makes me think about (and document) all the necessary  aspects of services that an implementer needs.  The advantages of using WADL are pretty significant.  I can get a lot of documentation out of WADL that would be difficult to create in the same way using a word processor.

There are several tools available that will take a WADL description and turn it into documentation of a RESTful API, others that will turn it into code, and yet others that will generate WADL from code.  All-in-all, useful stuff when you have a small team (as I do).  Sure, I don't need any tools to do this by hand, but why not use them if they make my job easier.  One of the things I like about WADL is that it helps me to order my thinking, and to make it easier to understand the API.  I can still read the XML and understand what it is doing.

One of my experiments in playing with WADL was to restructure the OAuth 2.0 RFC in WADL form, since we are also talking about using OAuth 2.0 for ABBI.  OAuth 2.0 doesn't define the resource URLs, it just defines what they need to do, which makes them a <resource_type> in WADL instead of a <resource> proper.  The tool I was using to generate documentation didn't support <resource_type> so I fixed it to do so (and made some other tweaks to it).

I haven't finished documenting either the ABBI API or the OAuth 2.0 specification in WADL, but the results are promising enough that I've posted them both to my prototype implementation site.  You can find them at the links above.