Friday, September 19, 2014

The HL7 September Plenary

I spent a good bit of time at the recent HL7 September Working Group Plenary meeting over the past five days with a lot of different workgroups.

While my home is usually Structured Documents, I only spent two quarters with them, first on forward planning and next hearing about the DAF FHIR project (which I'll talk about a bit more later).  We also talked briefly about ONC's HIT Standards and Policy FACA's feedback on C-CDA and also recent issues regarding the quality of CCDA documents being produced.  I agreed to bring this up in the HL7 Policy Advisory Committee meeting later on Wednesday.

I spent a good quarter with InM and ITS talking about the Data Access Framework PSS to create Query and Response profiles, in part satisfying one of the gaps identified in IHE's white paper on the Data Access Framework (this is the link to the public comment version, the Final is to be published soon).  One of the challenges here is that DAF wants to develop profiles that eventually will take advantage of the C-CDA on FHIR project, but they want to do things sooner than that project will be ready so that people can take advantage of the Query and Response profiles to test them.  I made the point that this needs to be coordinated across the other HL7 CDA/FHIR projects and the feedback I got was that "That isn't our project".  This is a common misconception that happens quite a bit when folks bring projects to HL7 is that they think they own the project.  The reality is, this becomes an HL7 project, and HL7 needs to do what it must to manage and coordinate ALL of the projects in its portfolio.  So, there will be some coordination there, and hopefully, we'll figure out how to do that properly.

Another good quarter was spent on QUICK, in which we talked quite a bit about my ONE negative comment on QUICK, which was the "Bad" ballot you can read more about in this post.  We traded a lot of thinking about what QUICK is trying to do.  One of the challenges of this work is that they think some of the names of things in FHIR are actually misnamed when approached from a quality and/or clinical decision support perspective,  I think there are probably three or four things that QUICK needs to do to address these mismatches, including getting some change proposals on the FHIR agenda to address some of these naming issues.  After all, if FHIR is truly EHR focused, we need to recall that at least in one market (the US), both Clinical Decision Support and Quality Measurement are key features that have to be present.

I spent a quarter with the HL7 Policy Advisory Committee, in which we spent about half the time planning the Policy Summit to be held in early December, and the other half discussion how to respond to concerns raised by the HIT FACAs on C-CDA.  We already have many processes within HL7 to address such feedback, and HL7 members use these to get improvements into the standards pipeline.  For example, the Examples task force headed by by Brett Marquard has already begun work on some of the examples that had been identified by the FACA.  Fortunately, we've been tracking these issues, but it might be nice if someone actually fed them more directly into HL7.  We'll be working on how to streamline that.

I spent a quarter with the Attachments workgroup, and we resolved some issues with esMD, but more importantly, Paul Knapp, chair of the HL7 Financial Management workgroup showed up to report on what he has been doing with FHIR in the Financial sector.  A while back I wrote a post about how Blue Button Plus and EOB data might be used to help reduce costs, but one of the outstanding issues has been the missing content standard for an EOB.  Building from the work that Paul has already completed with Claims and Remittances, we believe that FM could (and Attachments would support) the creation of an EOB resource that could be used with Direct, Blue Button Plus, or any other transport.

Thursday morning I spent with at the Payer Summit, giving payers a very high level view of HL7 Standards, along with many other HL7 luminaries.  It wasn't the largest room, but it was certainly chock full of some very interested payers.  I wasn't able to stay for the full summit, but I heard many good things.  Also speaking at the Summit was Brian Ahier (@ahier on twitter).

Finally, I spent my last quarter at the Working Group meeting with a number of HL7 and IHE members discussing the formation of a joint workgroup between IHE and HL7, preliminarily known as the Healthcare Standards Integration workgroup.  The IHE board has already approved this in principle, and we are following the HL7 Governance process to finalize the new workgroup, with the expectancy of final IHE board approval. Hopefully it will be in place before we complete the 2015/2016 Profile Selection process with several IHE Domains in October/November.

All in all, it was a pretty busy week, and I was quite happy to get home to finish packing for my big move to the country, a week from tomorrow.


Thursday, September 18, 2014

That takes guts

Normally I do this post Wednesday morning, but quite honestly had day job and personal distractions (I'm moving in about a week) this week, so I'm doing it today.  Wednesday morning at the HL7 Plenary the God Father of Health Level 7, Ed Hammond gives out the Ed Hammond awards, and I traditionally also give out an ad hoc award.  I do that not so much to compete with Ed (I hope I can do what he does when I reach that degree of tenure)., but to continue the tradition.

Tuesday morning I saw a combination of ribbons on an HL7 Member's badge that I found stunning. They were "First Time Attendee" and "Co-chair".  When I asked further, I discovered that this person was a new co-chair of perhaps the most technically challenging, and also difficult collection (which is a compliment, not a critique) of people to manage.  The Security Workgroup is relatively small, but contains some of the top names in Health IT Security, and has always been a very challenging place to engage.  I leave that to my colleague John Moehrke, who has much more experience in this area.  I know enough about security to know that I'd rather defer to seasoned experts that to try to do it myself.

So this combination of badges deserves special recognition, because while it takes guts as an HL7 first-timer to join the Security workgroup, it takes even more than that be willing to co-chair the group.  An extra special thanks and here we go ...


This certifies that 
Alexander Mense of HL7 Austria 


Has hereby been recognized for for having the guts to take on a role as cochair of the HL7 Security Workgroup

The FHIR Code

A guest post from one of the FHIR Chief's: Lloyd McKensie

A little over three years ago, when Grahame introduced the concept thFHIR(TM) standard, he didn’t just have set of technical ideas for how to better share healthcare information. He also had some fairly strong ideas about what we needed to hold as “important” as we pursued that new approach. The technical approach has evolved, in some places quite a lot. However, the underlying priorities have remained pretty consistent.
at would become

Principles are actually important core to FHIR – or any standards effort. They drive what gets produced. They also guide the community. If the principles aren’t well understood or clearly expressed, it’s easy for a standard to drift and lose focus. It’s also easy for it to deliver the wrong thing. V3 had a really strong focus on “semantic” interoperability. We made great strides in that space. However, we sort of lost track of the fact we still needed technical interoperability underneath that. (And that ease of use was sort of relevant too . . .)

Some of those principles such as “the 80%” have been widely shared (though not always well understood) . Others have found their way into presentations in slides such as the FHIR Manifesto. However, we’d never really sat down as a project and written down exactly what the fundamental principles of FHIR were or why we felt those principles were central to what FHIR was.

So the FHIR Governance Board (with review from the FHIR Management Group) has written down what we see as the “core principles” of FHIR – the FHIR Code, if you will. These are the underlying drivers that we feel should guide every design decision, every methodology rule, every step we take in deciding on scope, ballot timelines, etc. They can be found on the HL7 wiki.

I don’t think any of these principles will be a surprise to those who have been following the FHIR project. They pretty much all stem from the first principle:

FHIR prioritizes implementation 

Note that these aren’t hard and fast rules, but guidelines. You can’t say “I’m an implementer, I don’t like what you’re doing – therefore you’re violating FHIR core principles”. But they do reflect the spirit of what we’re trying to do and we’ll try to adhere to them as much as we can. (As well, we interpret “implementer in the broad sense – we don’t only care about those who write code but about all those who use FHIR.)

The FHIR code isn’t done though, because FHIR isn’t a top-down process. It’s about community (Grahame’s been re-enforcing that a lot this week.) And as I write this, I realize we may have missed a principle that should be added to the list. In any case, we want the principles to be reflective of the desires of the community – so we’re throwing them out to implementers and the broader FHIR community:

Do these principles reflect your vision for FHIR? Is this what should be guiding our decisions? Will this help us to keep our focus on the right things? Are they clear enough?

We’ll take your feedback (here, on the FHIR list, implementer’s Skype chat or any other means you choose). Then we’ll seek feedback as part of the next FHIR DSTU.

Tuesday, September 16, 2014

In what ways does it make sense to extend DirectProject beyond those already defined by MeaningfulUse?

The question above comes from 20 questions for HealthIT posted over on the HL7 Standards blog. You can probably guess my short answer, which is NO.  What you may not know are my reasons.

The Purpose of Direct

Let's start with the purpose of the Direct Project which you can find in the project overview:
The Direct project specifies a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet.
Direct was promoted as being the on-ramp to Health Information Exchange.  As an on-ramp, Direct technically has succeeded.  It is certainly technically possible to use direct to exchange information between providers, or to patients.  In execution, it has pretty much failed to deliver to those expectations.  These challenges aren't technical, they are organizational and related to the Healthcare provider. Until we solve those issues, I don't want to rely on Direct (or anything else) until we have resolved the exchange issues between providers.

We need more than an On-Ramp

We need more than a on-ramp for exchange.  Direct as it stands is a one-way push.  As a push specification, it can only address known, trusted entities.  It cannot deal with exchange with unknown entities, and the developing trust framework does not have any way at present to deal with establishing trust in a near real-time way.  

Another challenge with the Direct Project is that there's no real way to do dynamic almost-real-time queries, and it is NOT ideal for handling other sorts of queries, even though it is feasible.  There is a small group of people who have promoted it for this purpose, but several attempts at creating a consensus body to further develop Direct to support query has not yet succeeded.

Meaningful Innovation

Direct was supposed to resolve a short term problem which, as it turns out is much bigger than the technical issues it was supposed to solve.  At present, there are other innovative activities which are more promising than Direct (e.g., FHIR), which require attention.  I really want to stop trying to catch the train that's already left the station (e.g., the next stage of Meaningful Use), and spend more time on meaningful innovations in Healthcare IT.  

If you had a choice to advance yesterday's compromise solution (and to be sure, Direct was exactly that), or to work on more forward looking forms of Health information exchange, which would you do?

Monday, September 15, 2014

HL7WGM Plenary

The HL7 Plenary session is an annual event in which HL7 members hear from folks outside the standards development space.  This year the topic this year was around data, with focus on analytics, privacy and ethics.  First up was Dr. Richard Platt, who talked about the value of Mini-Sentinel and PCORnet, and the value of a standard data model to support the benfits of a learning healt system.  His talk was good, but what I found unfortunate was that we still focus on claims data.  One of his key points was that clinical data used in the EHR is designed to meet the neds of clinicians, not computers.  And so we get the problem below, which physicians resolve quite readily, but computers do not.

Next up was Zoi Kolitsi, Ph.D. Who talked about the balance between data protection and innovation.  The key points in her presentation were:
* Health and health data is special, even in the EU it receives an exception in legislation.
* Everytime that eHealth comes up, the legal aspects are also brought up.
* Governance, identity, and privacy are important principles to build into data sharing.

After the break, Marc Overhage gave a great presentation the challenge given to JASON (find the Golden Fleece).  He was quite quotable in his presentation.  For example, "if Interoperability is the problem, then architecture was the answer... not that anyone had ever thought of that before."  Or "the simple fix is to change the Universal Gravitational Constant..."

Here are his key challenges for interoperability:
* Maintaining privacy
* Misaligned incentives
* Competing priorities
* Same old problems
 - semantic variation
 - patient, provider and location matching
* Missing events model

Note that only one of these is technical (missing event model is one worth a whole blog post).

While Mike Jennings from Walgreens made a good start talking about how Walgreens use HL7 standards like CDA, Version 2 and Version 3, the rest of his presentation was little more than either an advertisement, or a rehash of all the reasons (which we well understood) for using health data.

Last up was Ken Goodman who talked about ethics in interoperability.  His presentation was very thought provoking.  Fitting ethics into the process of standards development and software development is something that he thinks is critical.  I need to digest his slides a bit more.

All in all, it was a useful plenary.  I'd give it an 8.5 out of ten.  Next time, I think we should probably provide the speakers with the same warning about "advertising" that HL7 tutorial speakers get.  That might have made it a 9 or 10.


Friday, September 12, 2014

Stages of Standards Development

One of the most amusing things (because if I didn't laugh I might cry) about the Meaningful Use program is the way that executives who have never paid anything more but lip service to standards are now reporting as experts on their effectiveness (or lack thereof) and the related causes.  Reports out of the HIT Standards committee about the need for improvement of CCDA are a perfect example of this.  However, the problems being reported almost certainly aren't the real problems that need to be addressed.

I have a theory about Stages of Standards Development that is fairly similar to Lohlberg's stages of development, but applied to standards and interoperability.

  1. We used this standard because we would get punished (or not rewarded) if we didn't.
  2. We used this standard because you told us too.
  3. We used this standard because everyone else is using it too for this problem.
  4. We used this standard because we are actually paying attention to interoperability.

In the first stage, the use of the standard is to avoid punishment.  Application and understanding of the standard is low.  The minimum work is done to pass the tests, and no thought or effort is put into the use of the standard to do anything more than to comply with the requirement.

The second stage is no much different, other than the user of the standard now recognizes authority, and may actually understand that there is a reason for being granted the authority.  So they may pay a little bit more attention to the standard, but don't really yet understand it.

The third stage is when the user of the standard looks around and sees that lots of other folks are using the same standard, and they could benefit from it as well.  In this stage, there are some they can learn from who are at more advanced stages and others who are not.  At this stage, they pay quite a bit of attention to learning as much as they can about the standard to make it work.

In the final stage, they stop worrying so much about the standard, and really start focusing on the intent and purpose of it, which is to enable interoperability between systems.  They stop looking at all the slavish ways the standard can magically solve the interoperability problem for them, and start realizing that standards are a major component of interoperability, but that other things are needed to support it as well.

Meaningful Use will only take us so far over time.  Stage 1 and the 2011 criteria only enabled level 1 and 2 adoption behaviors.  Stage 2 and the 2014 (Release 1 and 2) criteria starts to enable level 3 adoption behaviors, and creates an environment where level 4 behaviors can emerge.  But they do nothing to support level 4 behaviors.  The REC program supported some higher level behaviors, but it too really only stopped at level 3.  The workforce education program may have contributed a bit more to higher levels.  The Beacon program certainly tried to support level 4.  However, most of the money for these programs is well past gone.

Interoperability is a journey.  Standards are an important tool along that journey that are necessary. But most don't even know how long that journey really takes.  We had RFC-822 and before that RFC-561, and even today, after more than 4 decades, e-mail is still not perfectly interoperable. Remember Lao-Tzu: The journey of a thousand miles begins with a single step.  We've taken a few so far, let's keep going.



Thursday, September 11, 2014

ONC 2014 Edition Release 2

ONC figured out that it had a versioning problem with it's third release of the Certification and Standards rule.  This one (original entitled the 2015 edition) has been renamed to the 2014 Edition, Release 2.

What's new?  Not a lot actually.  As originally envisioned, there were plenty of changes coming to EHR vendors and users.  As written, it's a much smaller list of changes for everyone, which I summarize below.  A lot of what I complained about in the proposed rule is gone from the final rule. Other issues have simply been put off until stage 3 and 2017. In their own words ONC has "not adopted the Proposed Voluntary Edition. Rather, we have only  adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange."

  • Split CPOE into separate criteria for ordering Medications, labs and imaging.
  • Decoupled content and transport capabilities for transitions of care
  • Shifting the “incorporation” into an updated “clinical information reconciliation and incorporation” (CIRI) criterion.
  • Adopted Version 1.1 of Direct Edge Protocols
  • Decoupled the transport and content capabilities of the VDT certification criterion.
  • Allowed "any method or standard" to be used to "electronically create syndrome-based public health surveillance information for electronic transmission" for ambulatory use.  The net effect here is to enable meaningful users to claim the capability for the purpose of incentives if they electronically transmit surveillance data to public health.
  • Included an optional set of data elements (patient demographics, provider specialty, provider address, problem list, vital signs, laboratory results, procedures, medications, and insurance) to support surveillance.  This optional list on an optional criteria, basically serves the purpose of telling people the eventual direction they might go in a couple of years.
  • Discontinued use of the Complete EHR concept and Complete EHR certification
  • Created an ONC Certification Mark
There you have it, an even shorter summary of the short list of what ONC has added to certification in 2014.

I forgot to include Table 3 from the rule, which lists the differences between the various editions. It is quite useful
Table 3. Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria

2014 Edition Release 2
2014 Edition

2011 Edition

Regulation Section
Title of Regulation Paragraph
Regulation Section
Title of Regulation Paragraph
Regulation Section
Title of Regulation Paragraph
314(a)(18)
Optional – computerized physician order entry -medications
314(a)(1)

Computerized
physician order
entry

304(a)
306(a)

Computerized physician
order entry

314(a)(19)

Optional –
computerized
physician order
entry - laboratory

314(a)(20)

Optional –
computerized
physician order
entry – diagnostic
imaging

314(f)(7)*
Optional – ambulatory setting only – transmission to public health agencies – syndromic surveillance
 314(f)(3)
Transmission to public health agencies— syndromic surveillance (ambulatory setting only)
302(1)
Public health surveillance (ambulatory setting only)
314(h)(1)
Optional – Applicability Statement for Secure Health 
314(b)(1)(i)(A) and 314(b)(2)(ii)(A)
Transitions of care—receive, display, and incorporate transition of
care/referral summaries. Transitions of care—create and transmit
transition of care/referral summaries.
N/A
N/A
314(h)(2)
Optional – Applicability Statement for Secure Health Transport and XDR/XDM for Direct
Messaging
314(b)(1)(i)(B) and 314(b)(2)(ii)(B)
Transitions of care—receive, display, and incorporate transition of care/referral summaries. Transitions of care—create and transmit transition of  care/referral summaries.
N/A
N/A
314(h)(3)
Optional –SOAP Transport and   Security Specification and XDR/XDM for Direct Messaging
314(b)(1)(i)(C) and 314(b)(2)(ii)(C)
Transitions of care—create and transmit transition of care/referral summaries.
N/A
N/A
* Gap certification does not apply for the optional data elements listed in 314(f)(7).