Harmonizing Health eDecisions with HQMF

I've spent a significant chunk of the past four days reviewing the Health eDecisions ballot.  I gave you my initial overview of the ballot content on Thursday (after I'd already spent about a day on it).

I'd like to apologize to those who've worked so hard on this material for not being available sooner. I violated one of my own precepts in standards by waiting this long to provide input, and as a result, it's going to be more difficult for me (and anyone else), to get any of that input accepted.  I did that knowingly, and that's I risk I have to take.  At the same time, we are only at the halfway point (or perhaps even less) if we consider that my own feedback is part of a larger process.  So, if this feedback is valuable, perhaps it will be accepted.  After all, it's not like there are any pending rules right around the corner waiting on this ballot? Right? Phew.

I spend my first day of review looking at the balloted specification itself.  I spend the next three doing five things back and forth, iterating until I thought I was done enough to submit these as comments:

1. Reviewing Examples
2. Seeing how to harmonize HED with HQMF
3. Reworking examples from HED to my harmonized format (good thing I started late because the example content was also published late).
4. Documenting my changes (in word and excel format for the Ballot)
5. Modifying my HQMF R-MIM to reflect the proposed changes to ensure I have them right.

I've reached the comment submission stage of done-itude.  Here's an edited version of my proposed changes.

Use V3 instead of trying to be V3-Like

The biggest challenge I have with the current HED specification is that while it's close enough to HL7 V3 for me to understand it, not close enough for me to write it or interpret it without a crib sheet, and also far enough away that I'd have to rewrite all the code I have to deal with it.  What I'm proposing allows me to reuse quite a bit of code that I've already written to work with this.

We've already invested quite a bit of time in HQMF, which is a full V3 specification to support declarative structures for evaluating quality measures.  I and others have talked about how about how real-time quality measurement and decision support overlap.  Well, here's the proof.

HQMF already has most of what we need in its document header for metadata, has a well defined data criteria section for data access (what HED uses VMR for), can readily evaluate logical conditions (as is done with the InitialPatientPopulation criteria), and has decent structures for creating hierarchical groups (e.g., sections and subsections).  It also happens to conform to the ISO 21090 data types directly, rather than requiring an indirect mapping.

I stole the HQMF R-MIM and altered it to create an alternative one for HED.  In fact, there's some stuff I'd like to bring back into HQMF, like the notion that title should be allowed on any act to help provide documentation for it.  You can see most of it below.

Header

Adopt the HQMF Header with several changes.

Code

Adopt different code values to represent ECA-RULE, Order Set, and Document Template.

Use Author instead of Contributor

Use the HQMF Author construct to represent contributors.

Add Distributor for Publisher

Add a distributor participation to represent publishers (or suggest to HL7 Harmonization the inclusion of publisher as a sub-type of distributor if we need more specificity here).

Related Resources

To record related resources, allow a reference/support association to a relatedDocument element.

Allow id, title, text/reference, code, setId and versionNumber, and bibliographicCitationText in relatedDocument

Allow these to be associated with a document or section using reference and/or support act relationships.

Replace MeasureAttribute with KnowledgeAttribute

Replace the MeasureAttribute with a KnowledgeAttribute structure to support metadata capture.

Add Keywords

Add a keywords observation that can appear in the subjectOf relationship.  The value attribute should be SET<ST> to allow each keyword to be included in the <keywords> observation as a separate <value> element.

Delete the MeasurePeriod as a ControlVariable

Delete measurePeriod since it isn’t applicable.

Body

Adopt the HQMF Body with several changes.

Data Types

Use HL7 Data Types Release 2.0.  These are already based on the ISO 21090 data types specification and will be compatible with HQMF.

Add the title attribute to all criteria elements to support documentation (do this for HQMF as well).

Data Access

To handle Data access, use the dataCriteria section from HQMF.  This enables you to identify qualifying events such as patient age > 18, patient on an anti-thrombotic, patient having a documented reason for not being on an anti-thrombotic, patient being diagnosed with IVT or AMI, patient being scheduled for CABG or PCI et cetera.

Model Linking

HQMF uses soft model linkage as well.  Each data criterion can reference a model by an appropriate identifier.  So, you can link to VMR or to QRDA or any other data model.

Add DescriptionSection based on MeasureDescriptionSection

Build new sections based on MeasureDescriptionSection that allows a description of the KnowledgeDocument to be recorded [Perhaps even adopting this section in QualityMeasureDocument with the same semantics].

Event Condition Action Rules

Conditions in event-condition-action rules should borrow the model for InitialPopulationSection from HQMF.  I’d rename this to ConditionActionSection.  Retain the PatientPopulationCriteria (and remove the others), and rename it to ConditionCriteria.

Section

A section is a visual grouping within the knowledge artifact.  Sections can be nested.  Nested sections are evaluated only if the parent section is evaluated.

A top level section can have 0 to N triggers specifying the activation criteria.  Each trigger has a triggerEvent act whose code specifies the event that occurs to trigger the content in that section.  The section is evaluated only after at least one of the trigger events has occurred.  A section need not have any trigger events.

A section can have 0 to N preconditions.  All preconditions in the section must be true before any actions or subsections in the section are evaluated.

A section may have a title and text.  Any section title or text will be displayed to the end user when the preconditions are true.

A section may provide references to other content using the reference element.  A section can have any number of references.  A section may also provide references to supporting evidence using the support element.  The difference between supporting evidence and reference content is that supporting evidence shows the evidence behind the rule, order set, or documentation
requirement, whereas reference content can contain other information (e.g., implementation suggestions, regulation, et cetera). 

A section may have actions associated with it.  Actions are related to the section via the option, or component relationships. 

If the section is evaluated, all components within that section are evaluated. 

A section has one or more <component> or <option> entries.  All <component> entries are evaluated.  All <option> entries are choices that may be evaluated.  Each component or
option may contain a grouper, or a single action.

Trigger

A trigger contains a triggerEvent, which indicates what event can trigger evaluation of the actions in the section in which it is contained.

Precondition

A precondition contains a reference to a data element in the data criteria section, or logical expression over data elements which are found in the dataCriteria section.   A reference to a data criterion entry is true if there is a record in the selected record set that matches the criterion.

Component

A component may contain a section, an action, or a group of actions to be performed.

All options within a section must be marked as inclusive or exclusive.  If any option marked as exclusive is chosen, all other options in the section (marked as either inclusive or exclusive) cannot be chosen.

Option

An option may be a section, and action, or a group of actions to be performed.

An option may have a priorityNumber to specify relative ordering of choices.  Lower values have a higher priority.  When the priorityNumber is less than 1.0, the option may be preselected.  If more than one exclusive option can be selected, the one with the highest priority (lowest
value) will be selected.  All inclusive options with a priorityNumber less than 1.0 will be selected.

In ChooseAtMostOneAction and ChooseOnlyOneAction groupers, the option with the lowest priorityNumber (if it is less than  1.0) will be preselected.  In ChooseAnyAction or ChooseOneOrMoreAction groupers, all options with priorityNumber less than 1.0 will be preselected.

Use of option to support specializations of an order

It is one thing to say “choose a med from this list”, and another thing to craft an appropriate order set of drugs which should be used with appropriate dose, route and frequency.  Value Sets do not support this, but order sets often do.  The option can also be used in a proposal, to provide
more details about choices (e.g., different medication dose regimens).  These more detailed proposals can also have options.  It is recommended that no more than two levels of option be provided.

Actions

An action is a proposal for a course of action, such as administration of a medication, execution of a procedure, ordering a lab test or diagnostic procedure or assessment, et cetera; or documentation of a preexisting event or intent to perform an action (e.g., prior medication
administration or orders).

The former are represented as ActProposal elements (ActProposal, ObservationProposal, ProcedureProposal, EncounterProposal, SubstanceAdministrationProposal, SupplyProposal, SectionProposal).  The latter are represented as simple Acts (Act, Observation, Procedure, Encounter, SubstanceAdministration, Supply), in Event or Intent mood to document the occurrence of the event (Event Mood), or a recorded order (Intent Mood) for the act.

All actions have a required text element which provides a human readable text interpretation of the act being proposed or to be documented.

Action Groups

Actions can be grouped in five ways:  As a set of actions from which at most one can be performed, one and only one can be performed, as a set of actions from which any can be chosen, as a set of actions from which at least one must be chosen, or as a set of actions which always occur together.
Call these ChooseAtMostOneAction, ChooseOnlyOneAction, ChooseAnyAction,  ChooseOneOrMoreAction, and ChooseAllAction.

The DoNothing Act

The DoNothing Act can only appear in exclusive options. Selection of this act precludes selection of any other option, and is used to enable “None of the Above” to be chosen from the list of actions.  Use of this act in a rule, order set or documentation knowledge artifact reflects the intent of the artifact designer to allow other actions to be taken other than the given choices.  It is up to the implementer to decide how to represent this alternative.

The Message Act

The message act simply causes information to be provided to the end user of the knowledge artifact (I'm not even sure this is necessary).

On the Distinctions between Decision Support, Order Set, and Documentation Knowledge Artifacts

A decision support rule is little different from an order set.  It proposes actions to be performed by a provider based on patient data and knowledge rules.  The key difference is that it does not provide as much variation in choices for the provider to select from, whereas an order set may.

A documentation knowledge artifact, is nothing more than an order set where the only choices are to document something (an event, or an order for a service).

This is perhaps an over dramatic simplification, but it helped me make sense of how the same structures could be used for all three artifacts.

For my ballot, I be submitting specific negatives on each section, the above proposals, the R-MIM I developed, and the two examples I prepared to show how this all works.  I hope its enough to change some minds about how to approach it.

Thinking, Doing and Redoing

I've been working on software development projects and standards projects for decades.  One of the things I've learned as a developer about these projects is that you aren't done until you've shipped.

For software; code complete isn't shipped, sent to QA isn't shipped, and finishing Beta isn't shipped.  Shipped means that the CD is in the customer's hands.

For standards, sent out for ballot isn't shipped, passing ballot isn't shipped, and negatives reconciled isn't shipped.  It's only when the final text is in the customer's hands that you've hit shipped.

A typical project (regardless of domain) spends its time something like this:

⅓ Thinking
⅓ Doing
⅓ Redoing

It's the redoing part that's really hard.  That's where the feedback that you get from QA or from customers, or from a ballot has to go back into the product.

There's very little you can do to make redoing take less time as an overall fraction of your project time.  You can move feedback earlier into the project (as iterative approaches do), but what that winds up reducing not just "redoing", but also "doing" and even "thinking".

So, if you are in the middle of a ballot process, try not to think of yourself as being nearly done.  You are just at the halfway point.  When the ballot is over, and you start implementing the feedback, you'll be about ⅔ done.  When you've made all the changes from ballot feedback, then you are "nearly done", but remember, it isn't until the specification is in customer's hands that you've reached complete.

One other thing:  A standard isn't really done until its been implemented, and is in your customer's customer's hands.  That's a whole 'nother project (or a bunch of separate projects running in parallel), so when you've put it into your customer's hands without a pilot, you're only about halfway done.

-- Keith

Initial Health eDecision Ballot Comments

I'm reading through the Health eDecisions (HeD) specification and ballot material right now.  I find myself rather frustrated.

There are some simple production issues that weren't addressed (e.g., Error! Source Reference Not Found.) when the materials were put together.  This is a minor quality issue that can be addressed later, but it makes the content much harder to read, and provides an image of amateurism with respect to the content that is distracting.

Data Types

HeD claims conformance to ISO 21090 data types, but doesn't use the actual names given in 21090 in the elements, nor does it use the 21090 XML schema. It can thus only claim indirect conformance.  What drives me crazy about this is that if you are going to use a standard, and refer people to that standard for details, changing it doesn't help anyone (even constraining it causes confusion, but that is often necessary).

The description of the data type content is purely an extraction from the schema, adding little value.  It contains an image from the schema editor, and two tables, one for elements, and one for attributes which provide the element or attribute name, its datatype, cardinality, and whether the element is required or optional (which can be deterministically computed from cardinality).

HeD Expression Language

No.  No.  No.  Please write on the board 1000 times (and you must write it with the pointy brackets):
<subject>I</subject> <verb>will</verb> <adverb>not</adverb> <verb>create</verb> <adjective>programming</adjective> <noun>languages</noun> <preposition>in</preposition> <noun>XML</noun>.

There's not enough in the guide for me to go much further, I now have to look at the examples and the schemas to see how this really works.  That, in and of itself is pretty damning, because if I cannot figure out how to write one of these artifacts from the guide, then the guide has failed.

Conformance of an Application vs. of an Instance

One of the challenges with conformance is distinguishing between conformance of an instance, and conformance of an application.  All too often I hear that "this CCD document isn't valid" because it doesn't pass the NIST CCD Validator for Meaningful Use, when in fact, the instance is valid, because the data doesn't exist for that patient at the time the document was generated.  A perfect example is labs.  You have to be able to generate lab results when they are present, but not every patient has labs done during every visit.  The key to conformance for the instance is to generate the lab section correctly to indicate that none were drawn.

There have been some very long, drawn out discussions over the use of the terms SHOULD and R2 (Required if Known) in HL7 and IHE specifications that in part, result from this difference.
One of the ways that we could be more clear in creating interoperability specifications is to specify what an application must be able to capture as well as what it must be able to transmit.  In this way, we could separate application conformance from instance conformance.  For HL7 CDA, we've been a bit sloppy with this.

What required if known means is that an application SHALL be able to report a value when it is known, but it was never really clear whether it being known was a requirement of the application. We have often shortened the phrase "Required if Known" to "SHOULD" because it is simpler to say, even though SHOULD is somewhat different in meaning.  I have to take some of the blame for this; I was translating "Required if Known" to non-technical folks, and did so badly back in 2005, and it stuck.

HL7 uses the words Mandatory and Required to deal with this topic to some degree.  Mandatory means that A) the application must be able to capture the information (it can never be unknown) and B) must transmit the data.  Required means that the application A) must be able to capture the data (but it could be unknown), and B) must transmit it.

For required data elements, HL7 conformance says that:

... conforming applications must demonstrate their ability to provide and communicate not null values. Receiving applications must demonstrate their ability to receive and process (eg. Store, display to users) not null values for required elements.

DICOM breaks these down into Type 1, Type 2, and Type 3 attributes.  Type 1 is equivalent to HL7's Mandatory (in fact, DICOM uses the word Mandatory in the definition of Type 1).  Type 2 is equivalent to HL7's required, and adds this note:

The intent of Type 2 Data Elements is to allow a zero length to be conveyed when the operator or application does not know its value or has a specific reason for not specifying its value. It is the intent that the device should support these Data Elements.

In DICOM, Type 1 and Type 2 also have "Conditional" variants, known as Type 1C and Type 2C.  These are like Type 1 and Type 2, but only when the applicable condition is true.

In both cases, HL7 and DICOM provide a mechanism to say what an application must be able to do, and what an instance must look like.  However, we've gotten confused over time about what this means.  Separating required application behavior from what must appear in an instance could help clarify this.

Cool Toy of the Week

For Christmas, I got an Getting Started with Arduino Kit. You write software in the C/C++ (a language I know well) to program the Arduino Micro Controller.

My first project extended from Blink.  It was basically a binary clock using six LEDs to show the time (in binary).  The clock had three display modes: Hours, Minutes and Seconds.  You control the display mode by clicking the first button to cycle through each mode.  You can also hold down both buttons to set the clock.  That zeros the seconds.  By depressing button two, you advance the hours.  Pressing button one again takes you to minutes, which you advance again using button two.  Finally, you return it to the running mode by pressing the first button again. It's an interesting experience, and I went through several different gyrations on how to use the buttons to set the clock, and to use the LEDs to indicate which mode you were in before I arrived on the ones I used.

I had an Erector Spykee - Micro Robot that is operated by remote control that I got a few years back for Christmas that I wasn't using.  I decided to take it apart to and learned how to connect up the IR receiver inside it. After a bit of playing I figured out that the red wire goes to +5V, the yellow to Ground, and the green wire has the signal. I tried to read the signal using the analog input, not realizing how the IR worked. I managed to read it anyway, and figured out to some degree how to decode the signals. After a while, I looked around and found this library, which I then augmented to read the IR signals generated by the silly little remote.  That gives me two continuous buttons and four toggle buttons which I can now use to control my Arduino remotely.  I may have to work that into my first useful project to give me some override controls.  The robot also had a few LEDs, a small motor with a forward and reverse drive, and an 8ohm speaker that I will be using with my new toy.  I can use the motor later when I need to make a mobile robot.

Now I'm planning my first "useful" project.  My plan is to create a device that, upon sensing the remote control signal that turns the TV on, will tell my children to finish their homework.  It can use the IR sensor to detect the "power on signal" for the TV.  Once that is detected, I'll send a WAV file to the speaker.  After an hour, it will send out another signal to turn the TV off again.

To do that requires a bit of finagling.  The Arduino has a Pulse Width Modulated signal that gives be eight bits of signal control, but I have to add a low-pass filter to the circuit to turn that into a voltage to control the speaker.  This web-site helped me to figure out what resistor/capacitor combination to work with during my last shopping trip at Radio Shack  While I was there, I picked up a $14.00 SD Card Shield so I could store the audio of me telling my kids to finish their homework first on an SD card.  That way, I didn't have to encode it all, but could read it off the card, and use different audio messages as I needed.

One other thing that I'll need for this project is an IR transmitter, so I can send the Power Off signal to the TV after an hour, and tell my kids to go outside and play.  This should be a hoot.  I stopped by Best Buy to purchase a cheap SD card, and found a $5 calculator that I'm going to take apart for the LCD display.  I'll probably need a controller for that display.  I think that will be used in my second project.  The cool thing about this first project is that I can build it in pieces.  I first did the IR stuff.  Next I'll build the speaker/filter circuit and play with that.  Then I'll play around with the SD card reader.  And finally, I'll put it all together.

What a cool toy.

With apologies to Clement Clark Moore

Twas just days before Christmas,
when all through the house
Not an HID was stirring, not even a mouse.
The phones were all laid in their chargers with care,
In hopes that all T-cons could wait 'til next year.

The geeks were all nestled all snug in their beds,
While visions of RTs danced in their heads.
And ma w/ her facebook, & I gave my last tweet,
were just settling our iPads for a long winter’s sleep.

And then, there on twitter, I heard of a spoof
of a Christmas poem marked with a W00T!
As I drew up my tablet, and was pulling it down,
it popped up in FlipBoard with hardly a sound.

OMG it was funny, that silly elf,
I ROTFL in spite of my self.
And laying my finger on the button to close,
I went back to bed, happier than I rose.



Happy Christmas to All, and to all a good-night!

Two new consumer-focused HIT FACA Workgroups looking for members

Submit your application for potential membership on two new consumer-focused HIT FACA Workgroups The HIT FACA Committees are forming two new consumer focused workgroups, the HIT Policy Committee’s Consumer Empowerment Workgroup and the HIT Standards Committee’s Consumer Technology Workgroup.  HIT Policy Committee’s Consumer Empowerment Workgroup will be charged with providing recommendations on policy issues and opportunities for strengthening the ability of consumers, patients, and lay caregivers to manage health and health care for themselves or others.  Examples of issues to be covered include patient generation of their health data, incorporating patient preferences into care plans, and new types/sources of patient data.     HIT Standards Committee’s Consumer Technology Workgroup will be charged with providing recommendations on standards and interoperability issues and opportunities related to strengthening the ability of consumers, patients, and lay caregivers to manage health and health care for themselves or others.  Examples of issues to be addressed include portability of patient data, patient access to and generation of their health data, and incorporating patient preferences for a variety of issues, such as care plans.   If you are interested in being considered for membership on either of the two workgroups, please register at ONC’s Workgroup Application Database.  ONC will be reviewing the applications received by January 14, 2013.  For more information on the Committees and Workgroups, please visit the ONC FACA Website.  Thank you for your interest in the HIT Federal advisory Committees.