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.