Public Workshop on ONC HIT Certification Program and 2014 Edition Test Methods

Crossed my desk this morning, good to know... wish they'd given a registration link or something so that we'd know where to get the additional details. Oh well.

---

Save the Date: Public Workshop on ONC HIT Certification Program and 2014 Edition Test Methods The Office of the National Coordinator (ONC) will hold a public workshop on the ONC HIT Certification Program and 2014 Edition Test Methods on Tuesday, November 13th, 9AM-4:30PM EST. The topics to be covered include 2014 Test Procedures, Test Tools, Test Data, ONC Timeline, and the Certified Health IT Product List (CHPL). This will be a virtual workshop. Additional details regarding access and agenda are forthcoming.

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.

Continuous Variable Measures and QueryHealth

If you thought I was done with Query Health, clearly I'm not.  I've been spending the last three days reviewing the HL7 Ballot for HQMF, reissued because the R-MIM Diagram hadn't been included during the previous ballot.  Today, BTW, is the last day to register to vote on this reissued ballot.  Voting closes in a week.

One of the challenges I knew I would face is continuous variable measures.  The challenge of continuous variable measures is being able to compute with more than one value.  I though I was done with this, but it appears that I'm not yet.

The first challenge is average wait time.  Suppose that for each visit, I have captured the patient arrival time, and the time that they are seen by the physician.  Suppose that each of these is a separate observation.  Say we label one observation with "Arrival", and the other with "Seen" (i.e., using localVariableName).  What I'd like to compute is the difference, for each visit, between Seen and Arrival.

The DataCriteriaSection identifies the data of interest.  Each criterion describes a set of acts that might be computed from (and can be labeled with a localVariableName).  

<entry>

  <localVariableName>Arrival</localVariableName>

  <actCriteria>

    ...

     <code code="441968004" codeSystem="2.16.840.1.113883.6.96"

      displayName="time of arrival at healthcare facility" />

  </actCriteria>

</entry>

<entry>

  <localVariableName>Seen</localVariableName>

  <actCriteria>

    ...

    <code code="308930007" codeSystem="2.16.840.1.113883.6.96"

      displayName="seen by health professional" />

  </actCriteria>

</entry>

So, what I'd think should work would be something like:

<measureObservation...>

  ...

  <derivationExpr>Seen.effectiveTime - Arrival.effectiveTime</derivationExpr>

  ...

</measureObservation>

Where it gets complicated is that there's an implicit JOIN here on Arrival and Seen.  Each of these observations is related to the same visit.  It wouldn't make any sense to subtract the Seen of one visit from the Arrival of another.

As specified, the measureObservation above doesn't express the implicit join.  I'm still struggling with how this needs to work.  I can see a way to introduce a higher level criterion that would rectify this case, but it doesn't work for other cases where the JOIN criteria isn't as simple.  For example, in the case where the measure is the time from placing an order for something, to the time that order was fulfilled.  I could also see expressing the JOIN as a precondition on the measureObservation, but that gets into other challenges when dealing with relationships between acts and representing them in an expression.

While I know what is wrong, what I'd like to do in my ballot comment is identify what's right.

Progress Update on ABBI PULL

The ABBI PULL Workgroup met today, after a brief weather inspired hiatus.  We addressed 4 questions which were presented by Pierce and Ryan (ONC Coordinator and Presidential Fellow for this project).

1. Will the same REST Endpoints and Return Objects be used across the industry?
   The point of this question was to address whether there would be different endpoints and data objects for providers, payers or patient controlled health records.  We agreed that in general, the endpoints would be applicable to everyone, and that you could negotiate what kind of content you'd get back (e.g., C-CDA or EOB statement), and that the end-point would be able to send what it had available, or nothing if it didn't have what you were asking for.  This is similar to the Search API that I prototyped.  Another end-point would give you the most recent document containing what is known about the paitent.
2. What industries does ABBI need to describe endpoints and objects for?
   The basic API would support providers, payers or PCHR systems.  If you wanted to go deeper, you might get into industry specific end-points (but see the next question).
3. How specific and deep will the endpoints be?
   We could go into detail, but the basic level of the API should support the "Download" capability and requirements for Meaningful Use Stage 2.  We should keep it simple, but be able to extend to other kinds of end-points consistent with the overall approach.  Keeping it simple will increase adoption, because it will meet provider needs for Stage 2.
4. How can we encourage consistency?
   A well-documented API, with open source and reference implementation

There were a lot of side-bars and more details in all of these questions, but Pierce and Ryan kept great notes.

Meanwhile, I'm still writing code, but have got the dull-drums.  The next batch of code needs to deal with user and client registrations, and I just don't want to deal with it.  Neither do my customers.  So I'm looking for a different way to address it.  Part of the solution may be related to the next bit we'll be looking at next week.

For that, we'll be examining what I've referred to as the million registrations problem in OAuth, and some possible solutions.

Following that, I hope we can address the XML vs. HTML issue for content.  I think the answer to that problem is content negotiation via end-point API parameters, rather than something like an embedded stylesheet.  That just didn't work when I tried it. After all, content negotiation is what the HTTP Accept header is for.

-- Keith

Healthcare Dealers

Most computer salesman hate me.  They've been trained to a certain way to size up a customer, ask them questions about what they want in a computer, show them a few tricks on the units they've been told to sell, and pitch it. They never sell me anything.  I know too much, and drive them off.  No thanks, I don't need any assistance, I'm just looking, I tell them.  Then I buy what I need with confidence.

My cable company auto-routes me to level 2 support because by the time I'm calling them, I've already rebooted the modem, the router, et cetera, and I've don't tracert, ping and a few packet traces and network captures.  Yes, I tell them, I'm certain this is a problem at your end.  You aren't responding to DHCP requests.

I don't go to car dealers for service, because they've institutionalized price gouging.  I needed a part for lift gates on my wife's car.  Installed the pair of parts would cost me $350 at the dealer.  I bought the parts on Amazon for $20 (w/ shipping) and installed them in 20 minutes.

I've got a couple of local car repair guys who provide me with great service, and understand the difference between perfect, and good enough, and the value that good enough has when I have to weigh the difference between options.  I'll take a $50 weld that fits close enough for my ten-year-old car, rather than replacing the entire door frame for the perfect fit.  The difference can only be detected as wind noise past 50 MPH.

I understand these things well enough to make informed decisions about good-enough.  In being an engaged patient, I try to understand similar cases for my health, and so do other family members.

It's scary to see that some of the "car dealer" institutionalized gouging going on in some healthcare settings.  My wife figured out that that the ice-pack used during each PT visit was costing us $45 dollars each visit (that's an expensive ice-pack), and told them she'd do that at home.

I like my doctor, but it's hard for me to tell whether he's one of the local guys, or one of the "dealers".  To figure that out, I need to keep learning.  I wish there was a consumer reports for human care.

-- Keith

IHE PCC Planning Committee Advances Profile Proposals

The IHE PCC Planning Committee met this week to discuss upcoming profile proposals for the 2013-2014 profile development cycle.  Many attendees to this meeting were virtual given travel challenges raised by Hurricane Sandy.  Flights throughout the Northeast were cancelled, making it impossible for many to attend in person.

We agreed to move forward 4 proposals and one project to the Technical Committee in December.

Order and Referral Matching

This proposal suggests defining content that would appear in documents and in an XDS Registry to support matching of documents back to the original order or referral identifier.

Patient Focused/Facing Care Plan Workflow Definition

This proposal suggests defining a workflow profile that would enable development and refinement of care plans.

Early Hearing Detection and Intervention Workflow Definition

This proposal suggests defining a workflow profile to support early hearing screening, detection and intervention workflows.

Diagnostic Study Request Workflow Definition

This proposal suggests defining a workflow profile to support completion of requests for diagnostic studies.

Finally, the big project is the C-CDA Harmonization Effort, to include harmonization of the Immunization Content profile.

We also spent a bit of time responding to public comments on the Tumor Board Workflow Profile, which we expect to have published for Trial Implementation in time for the European Connectathon being held in mid-April in Instanbul, Turkey.

Thanks to all who proposed profiles for this season.  I look forward to discussing these proposals and projects in the technical committee meeting in December.

Where do they go? Insurance ID Cards and CCD & CCDA

I've gotten a few questions lately about the CCD and C-CDA Payers Section.  This is an vastly underutilized section in most implementations, but could have great value in Patient to Provider communication, as it could eliminate the most annoying, costly (to get wrong), and possibly error-prone part of the registration process.

You know that part where they ask for your insurance card.

Below are some samples of insurance cards.

There are at least four and sometimes more identifiers on these cards, and they all identify different things.  They are usually printed in fairly small type, with 8pt type being fairly common for the less important identifiers, and 6pt type on the back being fairly common for the list of phone numbers you need to call for different things.  There's often no bar code or magnetic stripe (I guess it's not in the payers best interest for these cards to be usable).

There are identifiers for the policy, which is often labeled "Group Number".  This represents the identifier for the policy covering the healthcare activity.  Then there's an identifier for the policy holder, usually called the subscriber identifier.  But that gets confusing because some plans also call that the policy-holder's member number.

Then there's the member id (or member number).  That identifies the family member being covered, and is usually the subscriber-id followed by a sequence number.  Some plans use -1 for the subscriber, -2 for the spouse, and then children as -3 to -n in birth order.  Others alphabetize by first name (as mine did).  That makes my eldest daughter -2, my wife -3, and my youngest daughter -4.

Following that, there could be one or more plan identifiers.  These are the identifiers for the specific kind of insurance plan that you have.  They represent a particular kind of insurance plan, and from what I can tell, are managed by state insurance regulators.  It's not uncommon to have a separate plan covering your regular care (e.g., ambulatory), and a separate plan for hospitalization.

OK, got that?  Now, what about the payer ID?  There isn't one yet, but I expect after the regulations pass and every payer has an identifier, you'll find that there as well.

Some cards also double as Pharmacy Benefit Management cards.  Those will have two additional numbers on them, called RxBIN and RxGRP, which are routing numbers used to identify how to communicate with the PBM (effectively identifiers for the PBM).

When we built CCD, we started from a coverage model developed by the HL7 Financial Management workgroup.  That model appears below:

Within CCD and C-CDA, there are three templates defined:
The Coverage Activity template represents the list of policies (or programs like CHIP, Medicaid, et cetera) that provides coverage to the patient.  It contains one or more policy or program activities which describe one component of the coverage.  These can be sequenced (really prioritized) by the sequenceNumber field in the act relationship.
The policy activity has an identifier.  This is the "policy number" or "group number" associated with the policy or program covering the patient.

The plan act defines the policy and is where you'd put the plan identifier.


The covered party is the patient.  The identifier associated with them is where you put the member id.

The responsible party is the "policy holder", and is where you would put the subscriber id.

Finally, the Payer is who actually makes the payment, and is where you'd put the PBM routing numbers, or payer ids when those become available.

The HITSP C83 specification goes into great detail on this section of the CCD, explaining where the content goes.  At the end of this post, you can find a full example that has been pieced together from various examples in that document.

The C-CDA follows a similar pattern.  You should be able to cross-walk the templates yourself using the template map in the appendix of C-CDA.

  -- Keith


<act classCode='ACT' moodCode='DEF'>
  <templateId root='2.16.840.1.113883.10.20.1.20'/>
  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.17'/>
    <id root=''/>
    <code code='48768-6' displayName='Payment Sources' 
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <statusCode code='completed'/>
    <!-- Example 1, A health plan -->
    <entryRelationship typeCode='COMP'>
      <sequenceNumber value='1'/>
      <act classCode='ACT' moodCode='EVN'>
        <templateId root='2.16.840.1.113883.10.20.1.26'/>
        <templateId root='2.16.840.1.113883.3.88.11.83.5'/>
        <id root='2844AF96-37D5-42a8-9FE3-3995C110B4F8'
          extension='GroupOrContract#'/>
        <code code='IP' displayName='Individual Policy' 
          codeSystem='2.16.840.1.113883.6.255.1336' 
          codeSystemName='X12N-1336'/>
        <statusCode code='completed'/>
        <performer typeCode='PRF'>
          <!-- This examples assume an RxBIN of 699999 and an RxPCN of PZZZZ -->
          <assignedEntity classCode='ASSIGNED'>
            <id root='2.16.840.1.113883.3.88.3.1' extension='699999'/>
            <id root='2.16.840.1.113883.3.88.3.1.699999' extension='PZZZZ'/>
            <addr>…</addr>
            <telecom value='…'/>
            <representedOrganization classCode='ORG'>
              <name>…</name>
            </representedOrganization>
          </assignedEntity>
        </performer>
        <!-- Example 2, The patient is a dependent of the subscriber -->
        <participant typeCode='COV'>
          <time>
            <low value='20070209'/>
          </time>
          <participantRole classCode='PAT'>
            <id root='…' extension='MEMBERID#'/>
            <code code='DEPEND' displayName='dependent' 
              codeSystem='2.16.840.1.113883.5.111'  codeSystemName='RoleCode'/>
            <playingEntity>
              <name><given>Baby</given><family>Ross</family></name>
              <sdtc:birthTime value='20070209'/>
            </playingEntity>
        </participant>
        <participant typeCode='HLD'>
          <participantRole classCode='IND'>
            <id root='…' extension='SUBSCRIBERID#'/>
            <playingEntity>
              <name><given>Meg</given><family>Ellen</family></name>
              <sdtc:birthTime value='19600127'/>
            </playingEntity>
        </participant>
        <entryRelationship typeCode='REFR'>
          <act classCode='ACT' moodCode='DEF'>
            <id root='2844AF96-37D5-42a8-9FE3-3995C110B4FA' extension='PlanID'/>
            <code code='HMO' displayName='health maintenance organization policy' 
              codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>
            <text>Health Plan Name</text>
          </act>
        </entryRelationship>
      </act>
    </entryRelationship>
</act>