on (event) if (condition)
then { action }
Let's transform the structure a bit:
action(p) and condition(p)
-------------------------------
condition(p)
It should be obvious that this is a transformation that can be automated.
In this transformation, the numerator is patients for which the predicate action is true and for which the predicate condition is true. The denominator is patients for which the predicate condition is true. This is the definition of a measure. It just so happens that I have a perfect example to play with: an ECA rule developed from NQF Measure 68 that appeared in the HeD Ballot.
I restructured that rule to use an HQMF-like declaration. Now I want to build a transformation that reverses the process of creating a rule from a measure, to creating a measure from a rule.
Data Criteria
In the data criteria section, there is:- an observation criterion of AMI_Diagnosis
<observationCriteria>
<id root="0" extension="AMI_Diagnosis"/>
<statusCode code="completed"/>
<value xsi:type="CD" valueSet="2.16.840.1.113883.3.464.1003.104.12.1001"/>
<definition>...</definition>
</observationCriteria> - an observation criterion of IVD_Diagnosis that looks very much like the above, save that the id is AMI_Diagnosis and the value set is different.
- a procedure criterion for CABG_Procedures
<procedureCriteria>
<id root="0" extension="CABG_Procedures"/>
<title>Coronary artery bypass graft procedures</title>
<code valueSet="2.16.840.1.113883.3.464.1003.104.12.1002"/>
<definition>...</definition>
</procedureCriteria> - a procedure criterion for PCI_Procedures that looks very much like the above, save that it is related percutaneous coronary interventions, rather than CABG.
- an observation criterion for age18andOlder
<observationCriteria>
<id root="0" extension="age18AndOlder"/>
<code code="424144002" codeSystem="2.16.840.1.113883.6.96" displayName="Age"/>
<value xsi:type="IVL_PQ"><low value="18" unit="a"/></value>
<definition>...</definition>
</observationCriteria> - a substance administration criterion representing a prescription for antithrombotic in the past year.
<substanceAdministrationCriteria> <id root="0" extension="onAntiThrombotic"/> <title>Prescribed antithrombotic w/in the past year</title> <effectiveTime><low><expression>date(now,-1,"a")</expression></low> </effectiveTime> <participant typeCode="CSM"> <roleParticipant classCode="THER"> <code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/> </roleParticipant> </participant> <definition>...</definition></substanceAdministrationCriteria> - an observation criterion representing a reason not to prescribe an antithrombotic.
<observationCriteria> <id root="0" extension="antithromboticNotPrescribedForDocumentedReason"/> <title>Patient or other Reason for not prescribing an antithrombotic</title> <code code="G8697" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4"/> <definition>...</definition></observationCriteria>
Condition Action Section
In the condition action section, there are a condition criteria that are anded together:
The patient must be older than 18.
<precondition>
<observationReference>
<id root="0" extension="age18AndOlder"/>
</observationReference>
</precondition>
The patient must not be on an antithrombotic, nor have a documented reason for not being on one.
<precondition>
<allFalse>
<precondition>
<observationReference>
<id root="0" extension="onAntiThrombotic"/>
</observationReference>
</precondition>
<precondition>
<observationReference>
<id root="0" extension="antithromboticNotPrescribedForDocumentedReason"/>
</observationReference>
</precondition>
</allFalse>
</precondition>
The patient must have a diagnosis of AMI or IVD, or be scheduled for CABG or PCI.
<precondition>
<atLeastOneTrue>
<precondition>
<observationReference>
<id root="0" extension="AMI_Diagnosis"/>
</observationReference>
</precondition>
<precondition>
<observationReference>
<id root="0" extension="IVD_Diagnosis"/>
</observationReference>
</precondition>
<precondition>
<procedureReference>
<id root="0" extension="CABG_Procedures"/>
</procedureReference>
</precondition>
<precondition>
<procedureReference>
<id root="0" extension="PCI_Procedures"/>
</procedureReference>
</precondition>
</atLeastOneTrue>
</precondition>
This represents the condition in the ECA rule. In the measure, I'd like to ensure that the denominator matches all of these preconditions. I can simply move all the preconditions to be inside the demoninatorCriteria in HQMF. Here's a snipped of XSLT which would do that:
<xsl:template match="hed:conditionCriteria">
<entry>
<denominatorCriteria>
<id root="c75181d0-73eb-11de-8a39-0800200c9a66" extension="DENOM"/>
<xsl:copy-of select="hed:precondition"/>
</denominatorCriteria>
</entry>
</xsl:template>
There are three choices presented to the provider for things to do in the ECA rule in a Choose One Action:
<ChooseOneAction>
<title>Treatment and documentation options</title>
<text>Treatment or documentation a clinician may order or
perform for an IVD patient with no prescribed antithrombotic
in the patient record
</text>
<option>...</option>...
</ChoseOneAction>
The action itself needs to be turned into a numerator criterion. Note: There's also a Choose At Least One Action too that I proposed. The ChooseOne action would map to the OnlyOneTrue construction in HQMF, and the Choose At Least One Action would map to the AtLeastOneTrue construction. Here's an XSLT snippet that would perform that transformation:
<xsl:template match="ChooseOneAction">
<OnlyOneTrue>
<xsl:copy-of select="hed:title|hed:text"/>
<xsl:apply-templates select="hed:option/*" mode="numerator"/>
</xsl:template>
Each of the options appears as follows and needs transformation as well:
1. Prescribe an antithrombotic
<option>
<substanceAdministrationProposal>
<participant typeCode="CSM">
<roleParticipant classCode="THER">
<code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/>
</roleParticipant>
</participant>
</substanceAdministrationProposal>
</option>
2. Document an antithrombotic that already existed.
<option>
<SubstanceAdministrationIntent>
<title>Document antithrombotic prescription in the patient's active med list</title>
<participant typeCode="CSM">
<roleParticipant classCode="THER">
<code valueSet="2.16.840.1.113883.3.464.1003.196.12.1211"/>
</roleParticipant>
</participant>
</SubstanceAdministrationIntent>
</option>
3. Document the reason for not prescribing an antithrombotic
<option>
<observationProposal>
<title>Document reason for not prescribing aspirin or other antithrombotic</title>
<text/>
<code code="G8697" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4"/>
<value/>
</observationProposal>
</option>
Proposals don't exist in HQMF since it looks back at what was done, so we need to look for orders or events that happened. These need to be turned into criteria that show up in the data criteria section. The substance administration proposal describes what needs to be done. We just change the name from substanceAdministrationProposal to substanceAdministrationCriteria and we obtain a criteria that matches the proposal. Changing the name of an element is trivial in XSLT. The pattern in the template for this:
<newName>
<xsl:copy-of select='node()'/>
</newName>
At this point, we now have a measure, but we need to specify a measure period. We'll leave that choice up to the measure developer.
There are a couple of things this measure doesn't have:
- It doesn't distinguish between initial patient population and denominator criteria. We could add a marker in the rule to help distinguish those.
- It doesn't distinguish criteria that are present because they represent exceptions or exclusions. Again, we could add markers in the rule to help distinguish those.
- It doesn't address dynamically created proposals. You might propose for some rule, a specific medication, but also a dose that is related to the patient's weight or age. Having dynamic criteria is a subject of another post, but this is also related to the next issue.
- A proposal can be overridden and/or changed or customized by the provider. The rule will often provided suggested values. There are essential (with respect to measurement) components (e.g., the medication), and not-essential components (e.g., a text description of the reason why a medication wasn't given). If we just turn the proposal into a criteria, we haven't addressed the essential vs. non-essential distinctions in the proposal.
This last case can be addressed in the rule, using a structure similar to how I dealt with offering choices for different medication dosing regimens. In this case, the first part of the proposal offered the essential detail (the medication), and the options within the proposal offered suggestions for non-essential details that can be altered by the provider acting on the proposals.
Over the next week, I'll be writing this transformation, and addressing some of these issues. What I've also demonstrated here is a very strong reason for keeping HeD and HQMF aligned as we develop both of these ballots. HeD was asked to align itself with HQMF in my ballot comment, but at the same time, HQMF must also align itself with HeD. I'm hoping that there is a ballot comment we can hang that on in HQMF, but if necessary, I'll take it through channels to get what we need in HL7 to keep these two ballots aligned.
-- Keith
0 comments:
Post a Comment