A Review of ONC Proposed Initiatives for HealthIT Standards and Interoperability

General Comments
ONC needs to read  The Standards Value Chain: Where Health IT Standards Come From before assigning timelines.  Their timelines are very aggressive for going from availability of implementation guides to deployment in software.  Without an external driver (like Meaningful Use), there is little to increase demand, especially when other things (such as Meaningful Use) demand work in other areas.  But also, ONC needs to take into account what the healthcare Industry has the capacity to adopt.  There are 12 initiatives listed below, and 11 of them are supposed to be operational at some level somewhere between 2011 to 2013.  Given Meaningful Use 2012 is right around the corner (from an implementer perspective), I think there needs to be a wider spread.  Sure, I'd like it sooner, but capacity is hard to increase without changes in process.  Few of these projects speak specifically to how they address that issue.


Clinical Summary
The scope of this effort is unclear given that the challenge is very poorly stated.  The definitions of the data elements for the HITSP C32 Version 2.5 appear in HITSP C154.  C154 follows best practices for data element definition that is rarely followed anywhere else (HL7 Vocabulary does some of it, but few others).  Every data element is uniquely identified, named, AND defined, and includes data element constraints on values.  Further detail on vocabulary is completely aligned with vocabularies SELECTED by ONC for Meaningful Use.  Complaints about ambiguity in vocabulary should be addressed, but please recall that it was ONC and not HITSP which created the ambiguity.

Realistically, the challenge is getting at the requirements from the available documentation, and that requires collaboration between HL7, IHE and ONC, along with tooling such as MDHT's CDA Tools work.  That collaboration has been started and should be continued.  This initiative should be combined with the Templated Clinical Documents because the two are quite overlapping in scope.  CCD is but one of many possible clinical summaries, as I've mentioned previously.  Any challenges in using CCD would be experienced with any other clinical summary developed in that effort unless both are resolved.

Templated Clinical Documents
The challenge and scope statements here clearly describe the problems and a way forward.  This is highly relevant, and work already in progress.  Most of the templates can be found in the CDA Tools work today, and appear in the HITSP C83 specification, which implementors of CCD/C32 will be readily familiar with.

Lab Interface Improvement
Been there, done that.  Hopefully this project will write the guide and not spend yet more time reevaluating vocabularies.  HL7 2.5.1 (because it meet CLIA requirements), LOINC for orders (300 codes cover 95+% of orders) and results (another set being developed by Regenstrief), SNOMED CT for body parts and pathogens, and RxNORM for drugs.  Write the guide, and get the labs to conform.

Medication Reconciliation Improvement
This is a really good idea, but the scope statement is not very clear.  IHE is working on the Reconciliation profile and I'd love to get some help on that from ONC.  We've already had some discussion on problems and our scope includes medications if we can fit it in.  Additional resources would help.

Provider Directories
I testified on provider directories to the HIT Policy committee a few months back, and there is as they note, an IHE Healthcare Provider Directory profile (pdf) on this.  This might focus on open source implementations of the IHE profile in support of The Direct Project and others like it.

Syndromic Surveillance
ISDS just sent around another version of the document for review, as I reported earlier this month.  I think they just write the guide in HL7, as recommended.

Quality Measures
They got it right about linkage between standards, vocabulary and measures.  The REAL challenge is making sure that evidence based medicine is linked to measures to start off with.  I've talked about how quality processes need to have measurement built in previously.  Previous work on quality measure specifications in HL7 was rushed due to contract deadlines, but will be taken up again in a new project that SDWG and CDS workgroups are expected to be collaborating upon again.  It's goint to take TIME to do this right. 

Population Health Query
There are two big challenges here.  The first is addressing privacy and security concerns on third parties being able to query institutional data.  The second one (partially addressing the first) would be describing aggregate queries in an appropriate form; so that results are not just deidentified, but also aggregated in the responses.  2012 is very aggressive for this.

Clinical Decision Support
My most and least favorite topic.  It's my most favorite because the opportunity to improve care is almost boundless.  It's my least favorite topic because it attracts quite a bit of academic interest, many of whom have been locked in ivory towers.  Theres so much going on in this space it's hard to keep track of.  It's completely wrong to try to exchange rules first, but that's the holy grail so everyone starts there.  The FIRST step is to identify the data needed to be exchanged to support evidence based medicine, including clinical decision support and quality measurement.  The SECOND step automates interfacing to ensure such information can be exchanged without creating new interfaces manually.  The THIRD step involves standardizing how the information is used computationally, and is what academics seem to have gotten hung up on.   But computation is programming, and you need to use the right tool for the job, and that includes programming languages.  Some problems could be pattern matching, others rule based, and other intensely computational.  Few languages support all paradigms equally, which is why I avoid the temptation to create another language for CDS.

IHE's Patient Care Coordination domain developed the Query for Existing Data (QED pdf), Care Management (CM pdf) and Request for Clinical Guidance (RCG pdf) profiles to support this kind of exchange.  It is still ahead of its time mostly because it addresses the SECOND step without strongly addressing the FIRST.  QED may finally have gained enough implementors to go final this year.

Blue Button
Blue button is a much discussed initiative developed originally by Markle and implemented by VA and DoD.  The chief problem with blue button is its fixation on human readable text.  I'd prefer to see more work to take standards based XML and make it human readable, rather than generate text versions of the standards.  The self-displaying CDA project in HL7 is one such effort.

Green Button
This is the weakest of all of the proposals.  The value to providers is pretty good for that once every 5-10 year period that they consider replacing there EMR system with something from a different vendor, but it does nearly nothing to address day-to-day value in healthcare.  Yes, it would open up the EMR market and prevent lock-in, and that has value, but I think the cost savings possible here are really quite a bit smaller than for any of the other initiatives.

Value Set Development
Value set development on lab orders is done and similar work on results is in process by LOINC.  Other necessary value sets might include anatomy and pathogens.  HITSP C80 described the value set for anatomy as: Shall contain a value descending from the SNOMED CT® Anatomical Structure (91723000) hierarchy or Acquired body structure (body structure) (280115004) or Anatomical site notations for tumor staging (body structure) (258331007) or Body structure, altered from its original anatomical structure (morphologic abnormality) (118956008) or Physical anatomical entity (body structure) (91722005).  Pathogens could also come from SNOMED CT.

The real challenge is not in defining the value sets, but rather making them deployable and publically available.  IHE has developed the Sharing Values Sets profile (SVS pdf) that could support exchanging standardized value sets in XML.