HQMF, CDS and Health Registries for HealtheDecisions in response to @Farzad_ONC

This tweet crossed my stream yesterday...

#hitpolicy can #HITstandards for unambiguously expressing quality measures be re-used for decision support and registry? #healthedecisions
— Farzad Mostashari (@Farzad_ONC) November 7, 2012

---

I promised a followup this morning, and here it is...

At the end of Gozinta and Gozouta, I briefly identify an IHE profile that takes advantage of clinical content found in guidelines to communicate to a clinical decision support solution.  The Care Management profile used a infrequently-implemented (especially in the US) HL7 Version 3 standard for communicating and querying care information to exchange clinical data to a clinical decision support system.

One of the key features of this profile was the way that it allowed an interface to be automatically generated from data contained within a machine-readable clinical guideline. The challenge for this profile was two-fold.  One was the scarcity of implementations of the underlying HL7 Version 3 standard, and the other was the dearth of machine-readable clinical guidelines.  IHE briefly considered rewriting the profile this year to see if using different standards would enable more uptake.  IHE chose not too, mainly because of overlaps with other projects.  We felt that it would be better to engage with projects like Health eDecisions and the HL7 ballots resulting from that effort, rather than starting an uncoordinated third effort on clinical decision support.

I've been quite behind on tracking and providing feedback on the Healthy Decisions projects.  In part this is because it's calls overlap with other regularly scheduled activities, and in part, it is because I have two or three other rather consuming projects going on in various places.  In developing HQMF Release 1, I insisted that HQMF needed a place to describe the data of interest for a quality measure.  This was a direct outcome of some of the struggles I had  trying to find good ways to describe data elements that needed to be communicated in the Care Management profile.  In HQMF Release 2, this became further refined as a result of the Query Health initiative.

The data criteria section in HQMF is a way to unambiguously defining data of interest for a quality measure.  That same section structure can also be used to unambiguously defining data of interest to a clinical decision support solution, or for a registry of clinical data.  Today, systems are being developed which will read the HQMF, and will generate QRDA documents supporting quality measures.  It's equally feasible to develop similar solutions that generate other kinds of CDA documents (QRDA is  an implementation guide on CDA) which could be used to support CDS or a registry.

In developing a solution using HQMF for Query Health, one of the things that I added to the HQMF Release 2 model was the ability to reference the definition of the information model into the Data criteria section.  This, combined with the existing capabilities of the data criteria section to unambiguously define the data of interest, allows you to automatically generate a specification for a CDA Document that would include the data of interest.  The intent of the care management profile was to automate the generation of the data from the EHR to the Care Manager.  Such a system could support Clinical Decision Support, a clinical data registry, or a host of other HealthIT solutions.

A properly constructed Data Criteria section, with references to applicable CDA templates (e.g., from the Consolidated CDA specification), could easily be used to automate the construction of a document that could be sent to a patient registry.  The same document could be used, for example, as input into a Clinical Decision Support solution.  Partners Healthcare and the Clinical Decision Support Consortium (members of the Health eDecisions Workgroup) are already developing CDS solutions that accept a CCD document, and generates as a result, a response describing care activities that should occur for the patient.

Interestingly enough, the definition of both the Gozinta (the CCD Document) and the Gozouta of that CDS solution could be described using the Data Criteria Section of HQMF.  So, the answer to Farzad's question, which he asked on behalf of the HIT Policy FACA, is a resounding yes.

While I may have been late in getting feedback to the Health eDecisions Workgroup, I won't be late in providing this as ballot feedback to the HL7 CDS Implementation Guide Project that came out of the Health eDecisions activity.

Real Time Quality Measurement as Clinical Decision Support

The topic of "Real Time Quality Measurement" as "Clinical Decision Support" has come up recently in three different forums.  In the AHRQ RFI which I mentioned earlier today, in a previous face-to-face meeting of the HIT Standards Committee, and just now in the agenda for the Clinical Quality Workgroup for tomorrow's montly call.  I'm a member of that workgroup, but won't be able to attend the meeting, given that I'm in an all-day training teaching about standards for quality measurement.  As always in cases where I cannot attend the call, I read the materials and respond ahead of time to the workgroup, so that at least they have my input.  After rereading, I decided to share it as this post:

On the topic of conceptualizing CDS as real-time quality measurement, you’ve hit one of my favorite discussion topics.

Quality measurement is intended for process improvement. One of the first steps in process improvement is documentation of quality processes. The second step is to build measurement into those processes so that progress against quality can be measured as early as possible. In clinical care, the process is a care guideline, and when that guideline is instrumented to that it can be measured, it can also be instrumented so that it can be executable. An executable clinical guideline operating against measurable inputs is clinical decision support in a very real sense.

My post on Gozinta and Gozouta is nearly three years old, yet most of what I have to say in it still applies in the current day.

What has changed in the past three years is that HQMF is now in its second release cycle, and there are significant initiatives using it, including the Measure Authoring Tool, and Query Health. There are yet more opportunities to use it to define not just how a quality measure is computed, but also to define the inputs (and possibly even outputs) of a clinical decision support process. Just being able to describe the inputs to a CDS process in a way that would allow Health IT systems to automatically generate an appropriate interface to a CDS implementation would be a tremendous game changer.

This should be a consideration of the ONC S&I Framework Health eDecisions project. I have some ballot comments on HQMF Release 2.0 that HL7 will soon be publishing that will enable this kind of use, based on some earlier standards work that IHE did. That never got adopted, I think in part because a standard like HQMF was missing from the protocol. There is emerging work in the CDS space from the Clinical Decision Support Consortium (an active participant in the Health eDecisions project) that could readily take advantage of synergies between it, and HQMF as a description of the inputs it is expecting. The CDSC work takes a CCD document from an EHR and develops from it, a list of needed interventions for a patient, which it returns to the sending EHR.

The Data Criteria section of HQMF owes its existence in part to some of that early IHE work on Care Management. The idea was that the “data of interest” to the system (in the case of HQMF, data of interest to the measure) needs to be well defined. And having defined it well, and in a computer readable format, it could be used to automatically generate an input for a clinical decision support system. That input could be a CDA Document, implemented using the CCD specification, or one of the documents specified in the CCDA specifications. It need not contain all of the specified data of interest, just that data of interest that is available to the provider, in order to be useful.

Knowing what data is of interest can also be used on the EHR side to prompt the provider to ask good questions. This is yet another form of Clinical Decision Support.

One of the missing points will be trying to figure out how to specify what the outputs of the Clinical Decision Support system would look like. Here, I believe we need to do more work on care planning. The output of the CDS system can be a care plan that specifies further diagnostics, interventions or goals which might be appropriate for the patient. Specifying what the outputs look like in a way that is actionable is important. But it need not be so detailed as to suggest exactly what needs to take place and in what order, as that is a case where systems might innovate.

  -- Keith

HealthIT Standards Predictions for 2013

Yesterday I talked about where I'd been last year.  Today I'm going to cover where I think things are headed in the US (at least for me).

1. We'll likely see a new S&I Project on Patient Generated Data.
2. eMeasures will make significant headway in transition to HQMF Release 2
3. Clinical Decision Support standards will become more important.
4. EHR adoption through Meaningful Use will slow down
5. Plans of Care, Care Plans, and Patient Plan of Care will attempt harmonization

S&I Framework Project on Patient Generated Data

This should be fairly obvious.  HL7 is balloting a specification for Patient Authored Docuements.  The HIT Policy Committee has held a public hearing on the topic.  There have been a few rumblings internally within S&I Framework staff and ONC.

The key challenge for this project will be differentiating between information coming from patients directly, and data coming from home health monitoring devices.  My advice is to attack these as separate use cases, but from the same project.  The data coming from home health monitoring devices is rather different from self-reported information on symptoms, allergies, social and family history, et cetera.

The HL7 FHIR Protocols that I've been using for ABBI also have a simplified method by which patients (or devices) can post data to a PHR.  The key issue is not transport protocols, but rather content.  I suspect that we could use the CCD 1.1 in C-CDA to record patient generated content just as readily as it is used for provider generated content, and we could also use the HL7 Patient Authored Documents specification being balloted now.   As for medical device data, I suspect we could look at the HL7 Personal Health Monitoring Report, and work from IHE Patient Care Devices and Continua for possible content solutions.

eMeasures in HQMF Release 2

I know the folks at MITRE have already been looking at transforms from HQMF Release 1 format to Release 2.  There's some interest in specifying HQMF R2 for Quality Measures in MU Stage 3.  A long term result of this effort would be to propose HQMF R2 as a required standard for the 2016 Edition EHR certification criteria.

We've done quite a bit of work on HQMF Release 2, and I suspect it's "nearly ready" for prime time.  However, the most critical effort at this point will be to deliver eMeasure specifications in HQMF R2 for use by pilots, get implementer feedback, and either tweak it, or develop an IG that makes it ready for use in the 2016 criteria.  Without that, I expect ONC will be scrambling to make it happen anyway, and the quality of our quality measurement tools will suffer.

Clinical Decision Support Standards

If you've been paying attention, you are already aware of the Health eDecisions work going on in S&I Framework.  Use Case 1 is finishing up, dealing with content formats for CDS rules, forms and order sets.  This is now being balloted in HL7.  They will soon be moving on to Use Case 2 (of much greater interest to me), which is how to integrate CDS web services with an EHR.  You can see that they haven't gotten very far on this use case.  Again, looking at Stage 3 proposals, it seems obvious that its about time for this work to really heat up.

My goal here will be to make sure that the proposed standards link up well with HQMF, and C-CDA specifications for content.  The link between quality measurement and CDS has already been made.

EHR Adoption Slows

Logistic Growth Curve (courtesy of Wikipedia)

Also easy to guess if you've been paying attention.  As I show in this post, there are three stages to technology adoption, exponential growth, linear growth, and saturation.  I think we are about halfway done.

If you look at the current data on the HealthIT Dashboard, you can see a logistic curve (shown to the right) embedded in the data.  There are some outliers for sure, but I suspect this has more to due with seasonal (i.e., Fiscal year-end) adjustments.  I'm not enough of a data analyst to figure out what those should be, but the pattern seems clear enough.

Care Planning

The topic of Care Plans, Plans of Care, and meeting the needs of the patient via patient centered medical homes, patient centered care planning, et cetera is heating up.  Something has to shake this loose.  We've had a care plan section in CCD (and now in C-CDA), and their predecessors since 2005.  HL7 has a workgroup named Patient Care, and in IHE, I'm planning chair for the Patient Care Coordination domain.  We've been working on this for several years in the SDO community, but it has yet to take hold.  

The content of a care plan is fractal and interlinked.  Certain kinds of care for this condition affects goals and activities for that one.  Tracking that sort of linkage in what we have today is certainly feasible, but little is, I think, really known about what is needed to do that.

The real challenge with care plans is not so much what to put in them (as far as I can see), but rather how to organize and manage them.  In other words, it's not a content issue, but rather one of governance.  And that governance is created by multiple care providers: doctors, nurses, and allied health professionals; covering general practice and specialties; in the home, and in acute and long-term care settings; by payers, ACOs and PCMHs.  Everyone has a use case to address, and frequently, an axe to grind.

I expect to see some motion on Care Plans next year, but it may be sideways.  I'm not sure if we'll see real progress until 2014 or later.  Perhaps ACOs and Medical Homes will help this along, and perhaps not.  Current drivers right now in S&I Framework are coming out of the long-term care community, but their use cases don't address everyone else's requirements.

I think we will need to assess and prioritize the need for care plans by the various axes [pun intended]. I think it likely that there is more value in some kinds care plans for a given type of healthcare provider, specialty, care setting or stakeholder.  We should be looking at working on the high value (in terms of costs of care) care planning activities.

We should also start using what we have today in C-CDA to report the basics (goals and interventions linked to conditions), and see where that takes us.  We can figure out how to move beyond that limited level of detail when we have more implementation experience.  After all, the key point of standardization is to standardize what works or what is best practice, and as far as care plans go, I don't think we know the answer to either of those questions.

---

So there you have it, my predictions for 2013.  It seems pretty obvious to me, but that may also be from knowing where to look for the trends.

Gozinta and Gozouta meets Query Health to revolutionize CDS

I spent this morning in the S&I Framework project leads meeting.  This afternoon I walked across the hall to another S&I Framework project that was having a meeting at the same time, skipping most of the introductory material at the kick-off session (although I did stay long enough to tweet one of Farzad's statements completely out of context).

Across the hall, several ONC funded Clinical Decision support project teams were meeting to discuss what was needed to standardize CDS for the 2016 Standards and Certification Criteria (which as Doug Fridsma reminds us, is really only 18 months away).  There was quite a bit of back and forth at this session, led by Jacob Reider, and I certainly stirred up the pot in the afternoon session.  But then again, I think they know what they were getting when I walked into the room.

Jacob had a great slide he was dynamically updating during the presentation that identified the various components of clinical decision support for which standards would need to be selected.  Surrounding the various boxes in which the components were listed was a box which described the scope of this particular ONC (and soon to be S&I) effort with respect to standards.  That box shrank and grew (and shrank again) as the discussion went on.

Blackford Middleton described five different kinds of CDS Interventions:

• Alerts
  Think of this as the typical black-box or question/answer approach that most people not really familiar with CDS go to first.  An alert is a notification that something is needed, not needed, appropriate, inappropriate, et cetera, based on some set of clinical data.  It need not be a pop-up (in fact, shouldn't be in most cases).
• Order Sets
  A way to represent common things that need to be done under particular circumstances.
• Info Buttons
  Places where someone can ask for more information about a particular data item (or set of data items)  being accessed.
• Data Display
A way to represent information that provides value (e.g., overlaying a plot of weight vs. Blood pressure)
• Documents
  "Smart forms" is how Blackford describes this.  Templates appropriate to a particular type of encounter or activity is a way that I might describe this.

In my thinking, the first three items are where we should focus our attention for Stage 3/2016 Standards and Certification Criteria.  There's a lot more work done on these three than on the latter two, and given that we have only 18 months, we need to bite off a useful and meaningful chunk (pun intended), without trying to solve every last CDS problem there is.  After all, anything left over we can address in stage 4 (only half joking here -- there's enough talk about stage 4 in policy circles that it could happen).

A lot of input to the discussions happened in the morning, and I missed most of it.  Thankfully, I might add.  In part, it was because most of what they discussed fell "above the line" on Jacob's chart (outside of scope).  The chunk above the line talked about standards important to implement a modular, standards-based clinical decision support service, but did not standards that would be used to integrated that with an EHR.

My thoughts on this are very strong:  I really don't care what language you use to represent knowledge, or how you implement your clinical decision support rules.  What I want to know are three (or maybe four) things:

• At what points the CDS intervention wants to be triggered,
• What the gozinta's are (what data it wants to see),
• What the gozouta's are (how do I interpret what it sends back),
• What the (XML) format is for communicating items 2 and 3 above.

Gozinta and Gozouta refers to a previous post I made about process improvement and building measurement into a process, and its intricately tied into my thinking in this space.  If you can tell me in a machine readable way (and NO, I do not mean an Excel spreadsheet), what data elements you are interested in, and how to represent that, then I can automate the outbound interface to the CDS service.

If you can tell me when to trigger it, then I can generate the message at the appropriate time.  Finally, if you can tell me the list of different kinds of responses (proposals for or against this screening, diagnostic test, diagnoses, treatment, or suggested care, ask these additional questions), how they are to be interpreted, and the format in which they are represented, then I can provide appropriate feedback in an EHR.

One of the cooler things that HL7 implemented in the HQMF standard was the data criteria section.  As currently being implemented in the Query Health project, this section identifies just the data elements of interest for a query.  In this context, it is a machine readable representation of a list of those data elements that could either be returned by the query, or used to identify specific items of interest.

In Query Health, we have a way to represent a description of problems, medications, allergies, encounters, procedures, demographics, et cetera, where we can specify the data element, and the specific code or value set, or range of relevant values associated with it.  It is only those elements that are later used to evaluate the query.

I strongly recommended the content of the HQMF DataCriteria section to this CDS workgroup as being the way to represent the information requested in an exchange.  In fact, I've even asked for the CCD requirements for the Partners CDS service that they are developing so that I can show them how to represent those requirements in a machine readable, unambiguous fashion.

I would also strongly recommend coordination with the other ONC S&I Framework efforts, including the Clinical Element Data Dictionary (CEDD or is it HDD now?) efforts coming out of Transitions of Care, Query Health and other workgroups.

Finally, just as IHE applied CCD templates to HL7 Version 3 messages, I would apply the Consolidated CDA templates to those data elements in a VMR implementation (presently a UML model in HL7) that used the HL7 Care Record messages as a concrete representation for exchange (now being reballoted as a standard).

On the gozouta side, I need to dig up the past work IHE did on Request for Clinical Guidance.  Essentially what we did is describe how you would make suggestions in the Care Plan.  So gozinta is essentially a message representation of the machine readable data in a Consolidated CDA document, gozouta is the same thing back, with suggested additions in the Care Plan (e.g., as suggested options for screening, treatment or diagnosis).

This could readily address both "Alerts" and "Order Sets", as the care plan could describe "alert" type responses, or suggested things that could be ordered.  It simply depends on how the EHR expects to use those things as to whether the CDS intervention becomes an "Alert", or an "Order Set", as described in Blackford's classification above.

In the InfoButton space, IHE is already working on a profile.  Join up, let's not duplicate effort.

This meeting was quite an interesting diversion for me.  I might have to find a way to get to AMIA this year, just so I can be a fly in the ointment again.

-- Keith

P.S.  Reminder to self: Finish reading Jerry's book on CDS and write a review.

---

I assigned myself an experiment after while the first part of this post this afternoon.  How would I use the data criteria section of HQMF to represent a data set used for Clinical Decision Support.  While I had asked someone to supply me with a set of data elements, and was going to follow up on this post, I realized about two hours ago (it's Oh-dark-thirty or so now) that it just so happens that I have a ready made list of data elements already created in this post (on what the summary care record should be for Meaningful Use Stage 2).

Here's the list of data elements:
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3).
(1) Race and ethnicity. The standard specified in § 170.207(f)
(2) Preferred language. The standard specified in § 170.207(j)
(3) Smoking status. The standard specified in § 170.207(l)
(4) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(5) Encounter diagnoses. The standard specified in § 170.207(m)
(6) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(7) Reserved (For Allergies)
(8) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(9) Immunizations. The standard specified in § 170.207(i)
(9) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)

Now, let's represent that list in a data criteria section.  This first chunk defines model elements which will be referenced later.  These model elements are simply handles onto different kinds of data, such as demographics, problems, allergies, et cetera.  No matter what the Data Criteria, these definitions are the same and could readily be replaced by one line of XML directing you to a publicly available resource that could be "inserted" at that point using <xi:include>.


<dataCriteriaSection 
  xmlns="urn:hl7-org:v3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:type="POQM_MT000001UV.DataCriteriaSection"
  >
  <code codeSystem="2.16.840.1.113883.6.1" code="57025-9"/>
  <title>Data Criteria Section</title>
  <text>This section describes the data criteria.</text>
  <definition>
    <observationDefinition>
      <id extension="Demographics"
        root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <encounterDefinition>
      <id extension="Encounters" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </encounterDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Problems" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>

  <definition>
    <observationDefinition>
      <id extension="SocialHistory" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>

  <definition>
    <observationDefinition>
      <id extension="Allergies" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <procedureDefinition>
      <id extension="Procedures" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </procedureDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Vitals" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <substanceAdministrationDefinition>
      <id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </substanceAdministrationDefinition>
  </definition>
  <definition>
    <substanceAdministrationDefinition>
      <id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </substanceAdministrationDefinition>
  </definition>
  <definition>
    <supplyDefinition>
      <id extension="RX" root="2.16.840.1.113883.3.1619.5148.1"/>
    </supplyDefinition>
  </definition>


OK, so now we have some demographics that we are interested in.  I show how we'd specify that we are interested in the race, ethnicity, and preferred language of the patient, which are listed in my data set of things I need to know in order to perform some kind of CDS.  Arguably, preferred language is not useful in this context, but age or gender might be.  Take it as a given that I have SNOMED CT codes that allow you to specify those as well.


  <entry>
    <localVariableName>Race</localVariableName>
    <observationCriteria>
      <id extension="Race"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Race"
        codeSystem="2.16.840.1.113883.6.96" code="103579009"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
  <entry>
    <localVariableName>Ethnicity</localVariableName>
    <observationCriteria>
      <id extension="Ethnicity"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Ethnic Group"
        codeSystem="2.16.840.1.113883.6.96" code="364699009"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
  <entry>
    <localVariableName>PreferredLanguage</localVariableName>
    <observationCriteria>
      <id extension="PreferredLanguage"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Language Finding"
        codeSystem="2.16.840.1.113883.6.96" code="106133000"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.10'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>

This next criterion says that I'm interested in smoking status, and that  it comes from the Social History part of the model.

  <entry>
    <localVariableName>SmokingStatus</localVariableName>
    <observationCriteria>
      <id extension="SmokingStatus"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="tobacco smoking behavior - finding"
        codeSystem="2.16.840.1.113883.6.96" code="365981007"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.12'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="SocialHistory"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>



This next criterion says that I'm interested in problems, and that  it comes from the Problems part of the model.


  <entry>
    <localVariableName>Problems</localVariableName>
    <observationCriteria>
      <id extension="Problems"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <value valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.1.3' xsi:type="CD"/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Problems"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>


I'll handle medications and immunizations together.  The next part says that I'm interested in these and that they come from the medications and immunizations part of the model.

  <entry>
    <localVariableName>Medications</localVariableName>
    <substanceAdministrationCriteria>
      <id extension="Medications"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
      <participant typeCode="CSM">
        <roleParticipant classCode="THER">
          <code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.8"/>
        </roleParticipant>
      </participant>
      <definition>
        <substanceAdministrationReference moodCode="DEF">
          <id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </substanceAdministrationReference>
      </definition>
    </substanceAdministrationCriteria>
  </entry>
  <entry>
    <localVariableName>Immunizations</localVariableName>
    <substanceAdministrationCriteria>
      <id extension="Immunizations"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
      <participant typeCode="CSM">
        <roleParticipant classCode="THER">
          <code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.9"/>
        </roleParticipant>
      </participant>
      <definition>
        <substanceAdministrationReference moodCode="DEF">
          <id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </substanceAdministrationReference>
      </definition>
    </substanceAdministrationCriteria>
  </entry>

Now procedures: 

  <entry>
    <localVariableName>Procedures</localVariableName>
    <procedureCriteria>
      <id extension="Procedures"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226985"/>
      <code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.2'/>
      <definition>
        <procedureReference moodCode="DEF">
          <id extension="Procedures"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </procedureReference>
      </definition>
    </procedureCriteria>
  </entry>


And labs:



  <entry>
    <localVariableName>LabResults</localVariableName>
    <observationCriteria>
      <id extension="LabResults"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.7'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
</dataCriteriaSection>


This XML took me all of 15 minutes to craft (the remaining time has been spend writing the rest of this post).  One of the reasons it went so fast is that there's a lot of repetition in this content, given the breadth of what stage 2 asks for in a summary record. So, while it's clear than for this data set you could simplify the XML, you may want the expressive power that I didn't show in this example for other CDS use cases (e.g., to limit the data element to the first/last of a series of identical measures, or within a given date range, et cetera).

Long time readers probably get it that I've already shown these data criteria as being sufficient to execute queries against a patient population in query health to compute counts of patients matching the measure criteria (another section of HQMF).  Given a population of ONE patient this data criteria identifies the clinical data that a CDS system needs to compute with, and can be used by the EHR to locate it.

Once we've located the data, it's (as a former colleague liked to say), a simple matter of code to turn it into an XML message in some format.  For CDS, I happen to like the HL7 Version 3 Care Provision message.  In the HL7 V3 world these are almost equivalent to CDA documents (and I've even got a specification for how to transform from one to the other and back), except that they usually contain no narrative.  So now I have a standard message format, a way to dynamically tell a system how to determine what goes in it, and from there, how to populate the content in the message.

What I've just described is a way, given a list of standardized data elements, to automate interface generation to a specialized CDS system, because it tells me (in that list of data criteria), how the interface should look.

What should I get back?

Well, I'd really like to see some proposals for screening, further diagnostics, new diagnoses, treatment that might be suggested, and references to the evidence supporting any of those.  I use the term proposal quite advisedly.  CDS systems propose, and depending on the implementation, either a provider or the systems decides what to do with this proposals.  Proposal is a special mood in HL7 Version 3.  Identifying something as a proposal is as easy as setting moodCode='PRP' on the acts returned by the CDS system.  So, anything that shows up as PRP on output is what the CDS system proposes for the patient in response to the given data inputs.

There is something else that's pretty interesting that could be done.  You could take the data in that message format, and the type of encounter, pick the appropriate document type from the CDA Consolidation guide, and populate it.

Oh my.

Models of Clinical Decision Support

This is mostly a thinking out loud piece for me to wrap my head around some thoughts related to the work that I've done on Clinical Decision Support, and how that relates to work done recently for the SANER Project, and how to connect that to ECR, and other public health reporting efforts. My first step in this journey is to review what I've already written to see how my approach to CDS, and that of standards has evolved over time.

Some of the more interesting articles I've written on this topic include:

• Clinical Decision Support (2008)
• Gozinta and Gozouta (2009)
• Declarative vs Procedural and Query Health (2011)
• Real Time Quality Measurement as Clinical Decision Support (2012)
• Gozinta and Gozouta meets Query Health  (2012)
• CDS on FHIR (2015)
• Hello CQL (2018)
• FluentQuery for FHIRPath (2020)

Most relevant to this discussion is the three legged stool of instance data, world knowledge, and computational algorithms from my first article.

The biggest difference in most implementations of clinical decision support is in where the algorithm gets executed, and quite a bit of effort has been expended in this arena.  I originally described this by referencing the "curly brace" problem of ARDEN Syntax, and it describes a challenge of integrating the algorithm for computing a response with a way of accessing instance data.

Here are the key principles:

1. Separate data collection from computation. (Instance Data from Algorithms)
2. Use declarative forms that can be turned into efficient computation (Algorithms).
3. Separate inputs from outputs (Instance Data, Actions and Alerts).

The tricky bit, for which I don't HAVE a principle is in how to identify the essential instance data, which honestly is largely driven by domain knowledge, and this is where MUCH of the nuance about implementing clinical decision support comes into play.  

There are two main approaches to clinical decision support: Integrating it "inside" an information system that has access to the essential data, or moving the data to an information system that can efficiently compute a result.

The former operates on the assumption that if you have efficient access to data, then compute locally (where the data results), and you can thus skip the need to separate instance data from algorithms that implement knowledge.  The latter requires the separation of instance data from the algorithm to facilitate data movement.

A large distinction between what SANER and Clinical Quality Measurement does from the rest of Clinical Decision Support is largely based on the distinctions between the needs for systems supported decision support based upon population data (data in bulk), and systems making decisions at the level of an individual.

It largely boils down to a question of how to access data efficiently. Different approaches to clinical decision support each approach this in a slightly different way.

• Quality Reporting Data Architecture (QRDA) defines a format to move data needed for quality measurement to a service that can evaluate measures.
• Query Health used Health Quality Measure Format (HQMF) to move a query described in declarative to a data source for local execution, and then results back to a service that can aggregate them across multiple sources.
• HQMF itself has evolved from an HL7 Version 3 declarative form to one that is now largely based on the Clinical Quality Language (CQL) which is also a declarative language (and a lot easier to read).
• Electronic Case Reporting (eCR) uses a trigger condition defined using the Reportable Condition Mapping Table (RCMT) value set to move a defined collection of data (as described in eICR) from a data source to the Reportable Condition Knowledge Management Service (RCKMS) which can provide a reportability response including alerts, actions and information.  RCKMS is a clinical decision support service.
• CDS Hooks defines hooks that can be triggered by an EHR to move prefetch data to a decision support service using SMART on FHIR, which can then report back alerts, actions and other information as FHIR Resources.
• SANER defines an example measure in a form which is represented by an initial query, and then filtering of that, using FHIRPath, which may result in subsequent queries and filtering.

One of the patterns that appears in many CDS specifications is about optimization of data flow.  There's an initial signal executed locally, which is used to selectively identify the need for CDS computation.  That signal is represented by a trigger event or condition, driven by either workflow, or a combination of workflow and instance data.  One example of a trigger event is the creation of a resource (row, database record, chart entry, FHIR resource, et cetera) matching a coded criterion (e.g., as in RCMT used with RCKMS for ECR). 

The trigger/collect/compute pattern is pervasive not just in clinical decision support, but in other complex (non-clinical) decision support problems that deal with complex domain knowledge.  It has uses in natural language processing software, where it has been used for grammar correction, e.g., to detect a linguistic pattern, evaluate it against domain (and language) specific rules, and then suggest alternatives (or verify correctness).  The goal of this approach is multi-fold: optimization of integration and data flow, and separation of CDS logic (and management thereof) from system implementation.

Population based clinical decision support is often expensive because it may require evaluation of thousands (or hundreds of thousands) of data records, and the more than can be done to reduce the number of records that need to be moved, the more efficiently and quickly such evaluations can be performed.  FHIR Bulk Data Access (a.k.a., Flat FHIR) is an approach to moving large quantities of data to support population health management activities.  It further accentuates the need for optimization of data movement to support population management.

As I think again through all of what has gone before, one of the things missing from my three legged model is the notion of "triggers", and I think these deserve further exploration.  What is a trigger event?  In standards this is nominally a workflow state.  From a CDS perspective, it's the combination of a workflow state, associated with resource matching a specific criteria.  The criteria is generally pretty straightfoward: This kind of thing, with that kind of value, having a measurement in this range, in this time frame.  And in fact, the workflow state is almost irrelevant -- but is usually essential for determining the best time to evaluate a trigger event.  Consider ECR for example, you probably don't want to trigger a reportability request until after the clinician has entered all essential data that you might want to compute with, at the same time, you don't want to wait until after the visit is over to provide a response.  Commonly this sort of thing might be triggered "prior to signing the chart", given that you want to make sure that the data is complete.  However, given that the results may influence the course of treatment or management, a more ideal time might be just before creation of the plan of care for the patient.

A few years back I worked on a project demonstrating the use of "Public Health Alerts" using the Infobutton profile and a web services created by John's Hopkins APL that integrated with an EHR system that was developed by my then employer.  We actually used two different trigger events, the first one being after "Reason for Visit" was known, and the second one just before physical exam, after all symptoms and vital signs had been recorded (if I remember correctly).  This was helpful, b/c the first query was relatively thin on data, but could guide data collection efforts if there was a positive hit, and the second one could pick up with a better data set to capture anything that the first might have missed.

I'm not done thinking all this through, but at least I've got a first start, I'm sure to write more on this later.

Summer is for Standards

Over the past two weeks we've heard about at least five different new S&I Framework projects:  Health eDecisions, Closed Loop Referrals (see Scenario 1), HREx, Auto BlueButton,  and Patient Generated Health data. Not all of these are yet "officially" announced projects on the S&I Framework site.

On top of that, there are a half dozen HL7 projects that are being worked on concurrently that support some of the existing projects (e.g., Query Health), and others which could support new projects.  This is a recent set of project scope statements that were recently approved by the Structure and Semantic Design Steering Division for the HL7 Structured Documents Workgroup (which had already approved them).

Some of these projects (such as HQMF Release 2) are already well under way.  I've been spending about 8 hours a week in meetings on them due to some extremely tight deadlines.  Just to give you an idea, anything like the Consolidated CDA revisions for patient assessments and QRDA Release 2, already in ballot, which might need to get into Meaningful Use stage 2 final rules, would needs to get published by the middle of next month, if it were to show up in a rule published at the end of August.  That early deadline is really good, because after that, I'm off to IHE meetings to finish up just a few other small things ;-)

HL7/IHE Health Story Implementation Guide Consolidation – additional templates for patient assessment data, at Project Insight # 728 for SDWG and TSC Tracker # 2305. The Patient Assessment Summary Work group (PAS WG), a work group within the ONC Standards and Interoperability (S&I) framework, identified a subset of data elements from patient assessment instruments for exchange in a summary document. This project will review and map the PAS WG identified clinically relevant elements to templates in the Consolidated CDA Templates DSTU. When existing templates are unavailable, or underspecified, this project will update, or add new templates to the Consolidated CDA Templates DSTU as specified by SDWG. The new CDA templates can be derived from the source instruments automatically. An appropriate document-level title, template, and document type code will be determined under this project. The project will be scoped to elements in the PAS SWG identified subset. The ballot will be scoped to these new and updated templates, and the SDWG agreed upon errata. The project will not introduce a review of content of existing document-level templates. The entire DSTU will not be re-balloted. Scope Statement is at http://gforge.hl7.org/gf/download/trackeritem/2305/9448/2012Sept_StucDoc_Patient_Assessment_SummaryPSSv201220120615.doc.

CDA Implementation Guide for Patient Assessments, at Project Insight ID# 381 and TSC Tracker # 2304 for SDWG. The scope of the project is to update the CDA Implementation Guide for Patient Assessments DSTU to conform to the new Consolidated CDA US Realm Header, and IG format. The DSTU will continue to include a universal header and body. Add guidance for communicating elements in the CMS Continuity Assessment Record and Evaluation (CARE) assessment tool. Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2304/9447/2012Sept_StucDoc_Update_Questionnaire_AssessmentsPSSv201220120615.doc.

QDM-based Health Quality Measure Format (HQMF) Implementation Guide at Project Insight # 756 and TSC Tracker # 2302 for SDWG cosponsored by CDS. This project is intended to create a domain analysis model to describe the content required within EHRs to measure quality and performance and maintain safety standards.  The information model content will be derived from the Quality Data Model (QDM) established in a public consensus process by National Quality Forum (NQF) in the United States.  QDM is a model of information based on the needs of quality measure developers and clinical decision support rule creators. It has now been tested in the retooling of 113 existing quality measures into HQMF format and in a number of CDS rules in an eRecommendations project funded by the Agency for Healthcare Research and Quality (AHRQ). Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2303/9446/2012Sept_StucDocs_HQMFQDMIGSpecR2_PSSv201220120615.doc.

Health Quality Measure Format (HQMF) Specification, Release 2, at Project Insight ID#508 and TSC Tracker # 2302. The DSTU will be updated to address new requirements identified through testing/implementation. Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2302/9445/2012Sept_StucDocs_HQMFSpecR2_PSSv201220120615.doc.

QRDA Draft Standard for Trial Use, Release 3, at Project Insight # 210 and TSC Tracker # 2301, for SDWG. This project will further enhance the QRDA Category I DSTU following updates to the HQMF specification to support alignment. Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2301/9444/2012Sept_StucDocs_QRDACatI_R3_PSSv201220120615.doc.

Patient Authored Documents, for Structured Documents WG at PI# 900, and TSC Tracker # 2300. In the “era of patient empowerment”, we want to define a specification for patient-authored clinical documents.  Medical practices are looking for ways to allow patients to electronically complete certain tasks online such as filling out registration forms, health history forms, consenting to certain practice policies, and other types of clinical documents yet to be defined. As electronic document interchange increases, we see a growing need to communicate documents created by patients (including those needed by providers and/or those document types defined by patients). Often, this is done through a secure web interface controlled by the patient such as a patient portal or a personal health record. As more and more practices incorporate EMR  technology into their practice workflow, they want to be able to import patient provided structured information into their EMR’s. This is being driven by the need to meet Meaning Use 2 requirements for patient engagement as well as other needs to reduce manual processes managing patient-provided data. Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2300/9443/HL7ProjectScopeStatementv2012_Patientauthorednotes20120615.docx.

HL7/S&I Framework QRDA II/III Draft Standard for Trial Use, Release 3, for SDWG at PI# 896 and TSC tracker # 2299. This project will define and bring to ballot a set of specifications for reporting quality data representing query results. The queries themselves use the Health Quality Measure Format (HQMF). This work effort will include a U.S. Realm QRDA Category II (QDM-based) and Category III Implementation Guide to direct implementers on how to construct QRDA Category II and III instances in conformance with HITECH eMeasures to represent the query results obtained from the distributed queries. This work effort will further align with the work taking place in HL7 to update the Health Quality Measure Format (HQMF) Implementation Guide. In addition, this project will leverage and harmonize with similar activities within and outside HL7 to avoid duplication of existing efforts. Scope statement is at http://gforge.hl7.org/gf/download/trackeritem/2299/9442/2012Sept_StrucDocs_QRDACatII_III_R3_PSSv201220120615.doc. 

The Model is the Standard

In HL7 Version 3, with one significant exception, the information model derived from the RIM is the normative expression of the standard.  The significant exception is of course CDA, which has the normative requirement that a CDA instance must validate according to the XML Schema produced from the model (once all extension elements and attributes are removed).

In HeD and HQMF, we want the overlapping concepts (the data to be used, and the operations that can be performed over them) to be drawn from the same model.  The model thus provides consistent semantics, and we can trace from clinical guidance to both the measures of implementation and the clinical decision support that implements it.

We had a long discussion today between myself, and members of the HeD development team to figure out how to move forward.  We have, as a result a proposal that stems from the fact that the V3 schemas are not normative.  Here is a quick summary of the proposal from my perspective:

1. The current HeD guide is treated as an implementation guide of a to be developed standard model, and is altered somewhat, but not substantially so, to be published by HL7 as an informative document or DSTU.  The alterations to be made stem from current ballot comments, and include harmonization with the HQMF header structure, metadata, and outline.  This does not include changes to its use of VMR, representations of logic or expressions.
2. A new HeD standard model will be produced subsequently that is compatible with this implementation guide.  It will use the same model elements as HQMF where there is overlap.  The VMR/QDM data access layers and the logic/expression evaluation will be separate components.
3. In that standard, the necessary logic and expression evaluation capabilities will be described functionally based on the capabilities of the existing HeD expression language.  These will be aligned with the simple expression language (based on simple math) that the SD and CDS workgroups agreed to in our joint session as being an implementation feature of the QDM-based HQMF guides.  Thus, you could map from something like simple math to the HeD XML expression representation if you wanted.  The capabilities would be the same (or very nearly so).
4. Adjuncts can be produced which transform from the HL7 V3 schemas generated automatically by our existing tooling, into the language specified in the HeD implementation guide.
5. We can also look at alternative ITS representations that allow the separation of models (e.g., VMR/QDM) from schema representations, to better support implementation flexibility.

This proposal keeps existing HeD pilots on their existing timelines as if my major ballot comments had not been made, aligns the current guide with the HQMF header and outline, allows HQMF to move forward on roughly the expected timelines we expect, and still harmonizes the efforts of both groups.

This was an exercise in making things possible, not in making them perfect, but I think we have a perfectly possible solution.

A Theory of Everything

Within HL7 we have produced or are producing numerous specifications dealing with Quality Improvement:

• VMR for CDS Logical Model
• VMR for CDS Templates
• VMR for CDS XML Implementation Guide
• HED Knowledge Artifact Implementation Guide
• Decision Support Service Implementation Guide
• HQMF Specification
• HQMF QDM-Based Implementation Guide
• CCDA Specification
• QRDA Specification
• Arden Syntax
• GELLO
• InfoButton
• QDM

Each of these addresses a variety of things, some things in the same way, and others in different ways, sometimes for really good reasons, and at others for reasons we perhaps don't yet understand.

We didn't know (and still don't yet in full detail, but we've at least gathered the data), where these specifications overlapped, and what was missing.  Today, Clinical Quality Improvement, Clinical Decision Support, Structured Documents and Templates members met to talk about what is our Theory of Everything, or more specifically, our Quality Improvement Architecture.  I presented the following slide deck to help us figure this out (the magic is on slide 5).

We took the list of specifications above, and parceled out the pieces into slide 5, and put it on a white board [this picture is after we cleaned it up].

As you can see, there is plenty of overlap.  We also noted quite a bit of gap, because we are missing (actually, it exists, but it's lore rather than publication) a lot of specifications where we agree (at the conceptual level). 

In fact, we agreed that at the conceptual level, we are almost in complete agreement.  The one place where we have some variation is between QDM and HL7 Clinical Statements, where there are some disconnects.  There is also a great deal of consistency at the platform independent information model level.

One of the realizations that I came away with was that in the RIM, the rules for interpretations for how to deal with certain structures in the RIM are behavioral/interpretation models ion the computation viewpoint space, rather than logical models in the information viewpoint (e.g., joinCondition has implied behaviors).

There's plenty of work to turn this diagram into an Architecture, and that's what I'll be spending the rest of my week on (when I'm not doing other things).

I was extremely pleased with how this workout went.  We had a room filled to the brim (nearly 50 people) who were writing on post-its and pasting them up on this diagram.  We came to an agreement on where we agree and disagree, and we have some plans for how to move forward.  And I totally was making this up as the week was proceeding, but it worked really well.

We still disagree on some things, but now at least, we have a much better idea about where.  There was a point in the meeting where someone was talking about one thing, and I disagreed, and then we clarified what boxes we were both talking about, and were instantly back in agreement.

‹xi:include href="wheel.xml"/›

The topic of incorporating components from one HQMF in another came up today in an SD/CQI discussion today at the HL7 Working Group Meeting.  On a related note, one observer pointed out that if we are successful, we should also be able to use decision logic from one resource, such as a CDS Intervention, in another, such as a quality measure.

Fortunately, we really don't have to reinvent this wheel in HL7, because W3C already foresaw the need to include parts of one resource within another resource.  It's defined in the XInclude specification, and it provides a way to reference an entire file, or component of a file within another XML resource.  All you need is an XML processor that is capable of performing the inclusions.  Even if you don't have such an animal, you can create one quite readily through an XSLT transform on an XML resource, provided you limit the features of xi:include element that you use (and you can probably implement the whole thing with the right XSLT processor).

If you are familiar with the #include preprocessor directive of C (and C++), then you already have a good idea of how this works.  You name the resource to include (e.g., the file), and can even specify the [fragment] identifer (or other expression) to select the appropriate content.

The reason I like this approach is because no matter how you slice it, an HQMF instance, or a CDS intervention is still defined in code.  You may not look at it as a piece of software, but I certainly do.  And you'll want to manage that software in ways that allow you to reuse components over and over again.  HL7 doesn't need to define this capability, it already exists as part of the base XML standards which we are all using.  We might just have to get a little bit smarter though about how we load XML resources in order to take advantage of that capability.

However, if you are having to interpret HQMF (or HeD), or any other complex XML component, it's surely worthwhile building support for xi:include into your code base.

MeaningfulUse 2015 Certification Rule

A quick summary of what is new and different in the recently published Voluntary 2015 Edition Electronic Health Record Certification Criteria: Interoperability Updates and Regulatory Improvements.  You can also find the Word version here, and I recommend it to you for making comments.  Kudos to ONC for making that version available, as it helps both them and us review the material and effectively make comments.

This is but a summary of what I ready between 5:30pm Friday afternoon, and finished reviewing sometime Sunday morning.  It's amazing that I've already had three deep discussions about this content with three other people who've also read it through, and it has yet to be officially published in the Federal Register (but will be there by the time most of you are reading this post).  Note that I started reading this document in Virginia returning from "vacation", and finished my first pass Sunday morning around 9:30am before taking off for HIMSS 2015.  I spent around 90 minutes on this Friday, 15 on Saturday, and about two hours Sunday morning.  While I read, I tweeted the highlights using the hashtag #mu2015 as a way to keep notes.

Some tips when reading NPRM's.  I read them through several times.  The first time, to get the gist of it, I start after the boilerplate and history and regulatory authority, and stop as soon as it gets to the financial impact statement.  So, I don't actually read the proposed regulation, just all of the commentary around what they proposed and considered.  That's the essential stuff you need to know for commenting, while all else is useful, the meat is in that chunk.  It cuts about 25 pages from the front half, and another 75 from the back, so I only had to read 150 pages, not all 252.  Normally, I'd go through 150 pages in about 2.5 hours, but remember that I'm also taking notes while doing this, so not bad for four hours.  I know people who've already put 8 hours into this thing.  So what you are getting is just the gist from that first read through.  Note that in the following, all page numbers are in the pre-publication public inspection version of the rule (and the ONC Word Version), not the prettily formatted Federal Register version that will be published Monday.

• Many criteria have been split to better support modular certification, which is the only form expected to be supported henceforth.  It makes sense because not everyone needs a "Complete EHR" or has one from a single source.
• The first of these to be split out is CPOE, separately for labs, imaging and medications. (p26-29)
• The standard to use for transmitting orders to labs will be the S&I Framework LRO Guide balloted through HL7.
• Additional criteria has been added for labs, and the NPRM strongly hints at future ramifications regarding CLIA requirements for labs interfacing with 2015 Certified EHR technology.  This was my second predicted standard back in December.  I also made some points about possible CLIA ramifications almost a year ago that got some attention, and may be in the works if I read between the lines correctly.
• I complained quite loudly about how ONC messed up the selection of the standard for language codes by selecting a different standard than was already in CDA.  It appears they are considering how to fix this problem now.  I'm all for using RFC 5646 which is what the Internet understands (and so does CDA).
• P38 of the rule offers explanation of how AHA recommends BP be taken. Have you ever had you BP done this way?  Me neither.  Lets use LOINC for the vocabulary as suggested in the NPRM.
• Note, many criteria are unchanged, for example, the need to record current problems, medication allergies and medications.  I skip a lot of this, as well as minor version updates of standards.  The point is that a summary should only address those things that are pertinent and relevant.
• P39-44 explains rationale for use of #HL7 Health eDecisions and DSS guides.  There's a lot of explaining here, and probably for good reason.  That standard needs quite a bit of work still to harmonize with everything else already in the MeaningfulUse architecture.  Prediction #3 came mostly true.  I'll count this one in full because the key was HeD, and not VMR.  DSS implies VMR in any case.
• P44 searching across electronic notes added.  This is a pretty significant change.  Dare I say, they want to be able to Google within a patient record?
• P48 smoking status unchanged.  This is one of the unchanged things that really matters to people.
• P49 access image results unchanged.  And another one.
• P49-50 covers changes to family history, and this is going to be a whole blog post.  Family health history to be recorded using HL7 Pedigree standard, as SNOMED CT dropped.  The key challenge here is that the Pedigree standard is a model, not an XML expression.  How do you test conformance to a model?
• From P25 to page 51 there are at least four references to FAQs which have adopted into regulation thus far.  I see a pattern developing.  Check the FAQs
• In the HL7 InfoButton standard, there's no real way to do a patient education or CDS based information request based on a lab result value, only the lab result code.  Thus, I can request information on A1C, but not on a value of 7% in an A1C result.
• If the patient has a device that has a GUDID, then it appears in their record.  I missed that in my predictions, and it should have been obvious in retrospect given the big splash back in the September HL7 meeting that the FDA and others were trying to make.  I don't know that missed predictions count against me though ;-)
• P62 begins the discussion of splitting the create and transmit to be separate criteria.  I know a few interface engine vendors who cobbled together a CCDA just to get certified to support create and transmit because you couldn't separate them in order to meet their customer's needs to be able to use that engine to support transmit.  You needn't show create to certify for transmit & versa visa! +1 for @johnmoehrke
• P65 "would no longer require testing and certification to the primary Direct Project specification" supports more flexible approach, which simply involves demonstrating that you can get your message to a Direct address.
• In my tweet I said OMG, but I really wanted to say something much stronger when I realized they actually named CCDA Release 2.0.  As that standard presently stands during reconciliation in HL7, the template identifiers are completely different and it will be largely incompatible with MU 2014 certified systems.  So only 2015 certified systems will understand it, and that will cause a HEAP of hurt because 2015 is an optional criteria, which now means we are back to two standards, CCDA 1.1 and CCDA 2.0, and the two at present don't have a backwards compatible path for 2014 Certified EHR products.  Another prediction right (although I later withdrew it thinking, or perhaps hoping they wouldn't make that mistake.  Then again, it's still correctable because 2.0 is still in surgery right now (ballot reconciliation).
• ONC added a performance measure that "EHR technology would need to be able to receive no less than 95% of all" valid CCDA documents.  This is pretty significant, especially since ONC never really defines what "receive" means.  To me, that means successfully import. This is where I hoped they would name the TOC Guide instead of CCDA 2.0, and they didn't.  So, I think between CCDA and TOC, I get a half a point.
• P74-75 discusses name matching criteria that includes first, middle, last, dob, place of birth, maiden name, sex, and current & historical address.  For name matching purposes, some of these are good confirmatory elements, and others are good elements to confirm or reject a match, but the criteria doesn't say how to use which ones.
• Note that the above criteria, and the addition of GUDID means that the Common MU Data Set will likely be changing to support those additional data elements.
• P78 In one place, two requirements were merged: The requirements for reconciliation and incorporation requirements were combined.  I keep telling people that the IHE Reconciliation profile is a good profile to adopt for these requirements.  IHE is going to be updating it this year to simplify the requirements and make it easier for systems to declare conformance.  Maybe ONC could adopt it?  They did ask.
• P83-86 discusses #HL7's #HQMF release 2 standard, proposed for EHRs to interpret Clinical Quality Measures.  Another prediction right.
• P88 CEHRT must be able to filter populations by several criteria before producing measures.  This one seems kind of silly, since a measure already has a population criteria which filters the population to which the measure applies.  It may well be that some don't understand how measures or HQMF really work.
• P90 They asked for feedback on support for two factor authentication for ePrescribing of controlled substances and remote EHR access.
• P97 Contains a spoiler alert "given our proposal to discontiinue the Complete EHR concept ..."
• P101 WCAG level AA proposed instead of level A for View capability
• P103 Imaging is back into play for patients. This was proposed for 2014 but later dropped.  Shouldn't patients be able to get diagnostic quality images?
• P109-113 Both CDA and QRDA standards were proposed for syndromic surveillance in ambulatory space.  Both might work.  The former would be used as specified and the surveillance would occur by simple inspection of that appeared without a lot of net new exchange requirements.  However, we'd be utilizing QRDA instead of using it for this purpose.
• P129 ONC provides a 2014 to 2015 equivalency table that will save many of us a lot of work understanding the rule.  Thanks!
• P149 Finally Meaningful Use gets meaningful brand identification with introduction of a certification mark 
• Questions about 2017 criteria start at p154, and so I stopped reading there, since my review was strictly to address 2015 criteria.

Of significant note, BlueButtonPlus didn't make it into the proposed criteria, and was barely discussed in such as way as it could be included.  However, there's a way forward.  But first some discussion about regulations.

There's rules about regulations, not surprising.  One of those rules is that if it wasn't discussed or asked in the proposed regulation, it cannot be done in the final rule.  So if there is no discussion about Blue Button + in the regulation, it couldn't be in the final rule, right?  Except there is a big hole in the second paragraph of Page 100 which says: "We seek comment on whether we should require another transmission method as part of this certification criterion in addition to the one just discussed."

There's the opening for Blue Button +, which is after all, a transmission protocol.  So, if you want Blue Button + to be part of the 2015 criteria, that appears to be your opening.  It is such a close thing to what is already required in VDT, couldn't we just go there?

As a summary, this is pretty long.  Let me make a long story short.  My grade on predicting appears to be 3.5 right out of 5, with one major missed prediction (GUDID).  I can live with that score, especially since I don't know many others who were willing to go out on such a limb.

     Keith

P.S.  I proposed in my Project Management class to take on planning a project to do an assessment of the 2015 criteria.  Now that we have half a clue what it is, my team can proceed to the next step.