Negating Supply and Encounter in QRDA

A while back I discussed some of the challenges that were discovered in QRDA when it was necessary to express a negation of the Supply and Encounter acts.  These acts in CDA simply don't have the negationInd attribute on them, and so cannot be readily negated.  The workaround I proposed was to use a negated Act instead, since you can incorporate what you need in Act and don't need some of the detail already present in Supply or Encounter when the act is being negated.

Here's the relevant extract from the CDA R-MIM:

For example, in Supply, what point is there to negate specific details about quantity (since you supplied nothing), or expectedUseTime.  And for Encounter, you have all the necessary attributes.

Now, to negate an encounter, all you need do is write it as if you were writing a negated Encounter that supported negationInd, including a code that specified what kind of encounter didn't occur.  The receiving system should be able to recognize the encounter codes in Act and understand that is negating an encounter.

Supply is a bit trickier, since there isn't always a code associated with Supply.  The precedent we established previously in CCDA with Condition (a specialization of Act) was to use the classCode "COND" in code, and we can do the same here, setting code/@code to SPLY and code/@codeSystem to 2.16.840.1.113883.5.6.  Supply also has a product that wasn't supplied, and this also needs to be specified.  In Supply we would do that with the product participant, but in Act, we would need to handle that with the generic Participant.  Set participant/@typeCode to PRD in this case.

The participantRole will be mapped to the ManufacturedProduct by setting participantRole/@classCode to MANU.  In the HL7 RIM, these two now have the same semantics. Similarly, the playingEntity/@classCode should be set to MMAT to match material.  The code and name elements in playingEntity would be set as you would have set for manufacturedMaterial, and lotNumberText is not material (since there is no lot associated with something you didn't supply).

The only thing not quite right here from a RIM modelling perspective is that determinerCode won't match since ManufacturedMaterial/determinerCode = KIND, and palyingEntity/determinerCode = INSTANCE.  While this modelling isn't quite right, there's nothing that we can do to change CDA R2 at this stage, we'll need to wait for CDA R2.1 should that ever happen.

So, now you hopefully should understand how these acts can be negated.  The next step will be to do an update of the QRDA specification to support these challenges.

The case against a negationInd extension for supply and encounter in CDA and QRDA

It's been proposed recently that the prohibition in CDA Release 2.0 against extensions altering the semantics of the information doesn't apply to RIM based extensions.  What the standard has to say in section 1.4 on Extensibility is [emphasis mine]:

Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging meaning that is not shared. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.

The rationale for including this extension in QRDA is to enable one measure (of 93) to be able to report that something was not supplied to the patient.

We did a risk analysis of this today on a special Structured Documents call.  Here's the scenario:

Data is captured for quality reporting and quality improvement activities.
Within that context, rules are created to ensure that patients are followed up on if they aren't getting appropriate treatment as evidenced by supply records.

1. A patient with DVT risk is ordered prophylaxis.
2. However, that prophylaxis is not supplied for some reason (e.g., patient couldn't afford to pay).
3. This is recorded using the extension.
4. A system that uses the proposed extension will correctly detect that the supply did not occur, and can initiate followup.  However, a system that does not use the proposed extension and is developed with the understanding that unrecognized extensions can safely be ignored will not recognize that the supply did not occur.  In fact, it will instead recognize the opposite, that supply did occur.
5. As a result of this, no followup on the necessary intervention is performed.  
6. Due to the resulting delay to detect that the prophylaxis was not given, a life threatening health event occurs.

We need to assess three things:

1. The severity of harm, which we evaluated as critical/life threatening [different organizations may use different terms].
2. Probability of occurrence of the hazard: Care management systems today are looking for the absence of the supply signal.  Presenting a supply signal using QRDA with the extension will always cause this trigger to fail.  Due to the way it interferes with followup activities, is unlikely to be noticed by a provider, so the probability of occurrence is high that it will occur.
3. Likelyhood of harm: This would have to be ratedMechanical prophylaxis can reduce the risk of DVT from 27% to 13% alone, or when used with medications, from 15% to 2% [see http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1925160/].

If you work out the rest, you realize this is not really a workable solution by itself.  Something else has to be done.  Documenting the extension and putting some clear warnings around it is something we know doesn't work well.  Trying to create patient safety in a design through labeling is the least effective method according to the FDA.

If I were the product manager for the 93 quality measures, I'd pull the one in question and release it later when CDA Release 2.1 (or as seems more likely, CDA on FHIR) has the capacity to address the need.

Combined 2015 CMS QRDA Implementation Guide Now Available

Combined 2015 CMS QRDA Implementation Guide Now Available

News Updates | July 29, 2014 Visit the eCQM Library Page to Review the Combined 2015 CMS QRDA Implementation Guide The Combined 2015 QRDA Implementation Guide for eligible professionals, eligible hospitals, and critical access hospitals (CAHs) to use for reporting electronic clinical quality measures (eCQMs) starting in the 2015 reporting year is now available on the CMS website. The 2015 Combined Implementation Guide provides technical instructions for QRDA Category I & Category III reporting for the following programs:  Hospital Quality Reporting including the EHR Incentive Programs and Inpatient Quality Reporting (IQR) Ambulatory programs including the Physician Quality Reporting System (PQRS), the Comprehensive Primary Care (CPC) Initiative, and Pioneer ACO CMS accepted public feedback on the draft guide from June 10, 2014 to July 8, 2014, and has made revisions accordingly for inclusion in this release. The CMS 2015 QRDA Implementation Guide is updated for the 2015 reporting year, and combines business requirements and information from three previously published CMS QRDA guides: The 2014 CMS QRDA Implementation Guide for Eligible Hospital Clinical Quality Measures   The 2014 CMS QRDA I Implementation Guides for Eligible Professionals Clinical Quality Measures [zip file] The 2014 CMS QRDA III Implementation Guides for Eligible Professionals Clinical Quality Measures [zip file] About the Combined Guide Combining the above guides into a single document provides a unified resource for implementers, eliminating the need to locate the individual program guides. More importantly, combining guides harmonizes differences among earlier versions of the CMS QRDA guides, especially between the QRDA-I guides for eligible professionals, eligible hospitals, and CAHs. The CMS 2015 QRDA Implementation Guide incorporates applicable technical corrections made in the new 2014 HL7 errata updates to the HL7 Implementation Guides for QRDA I and III. The new guide contains two main parts: Part A is the harmonized QRDA-I implementation guide for both eligible professionals and eligible hospitals/CAHs. Part B is the QRDA-III implementation guide for eligible professionals. It also includes appendices that annotate the changes between the HL7 QRDA-I and QRDA-III standards and the CMS QRDA specific constraints. Changes between the CMS 2014 QRDA guides and the new combined guide are provided as well. Additional Resources The 2015 CMS QRDA Implementation Guide is available for download on theeCQM Library Page in the Additional Resources section. To learn more about CQMs, visit the Clinical Quality Measures webpage.  For questions about reporting requirements using the 2015 QRDA Implementation Guide, please refer to the specific program’s help desk or information center.

Ours is to Reason Why, What Others Do or Nae

What follows came up on the Structured Documents call today.  Several of us agreed to propose a fix to this.  Here's my first crack at it:

There's some inconsistency between Consolidated CDA and QRDA when reporting on reasons why something was or wasn't done.  Consolidated CDA has the Immunization Refusal Reason Template, which models refusal in the way we agreed to handle the missing reasonCode attribute on various acts in CDA Release 2.  That method specified that a reason for doing or not doing something would be represented by an entryRelationship with typeCode = RSON, in an observation where observation/code indicated the reason why.  But we have no such templates in CCDA for reasons associated with other clinical activities, such as refusal of a medication, or other procedure.

In QRDA Release 2, we have Patient and Provider preference templates. These are used as reasons why things aren't done and are defined as follows:

Preferences are choices made by patients relative to options for care or treatment (including scheduling, care experience, and meeting of personal health goals) and the sharing and disclosure of their health information.

Provider preferences are choices made by care providers relative to options for care or treatment (including scheduling, care experience, and meeting of personal health goals).

I would merge these two:

Preferences are choices made by a person relative to options for care or treatment, including scheduling, care experience and meeting of health goals, including the sharing and disclosure of information.

When preferences are expressed as the reason for doing or not doing something, they more often than not are related to the act done or not done by the RSON act relationship as above, however, in several places in QRDA Release 2, it uses the REFR act relationship. This looks like a simple mistake to me.  To make it easier, I'd just include the act relationship and vocabulary constraints within the "Reason" template, so that we stop having to say all that stuff repeatedly everywhere that the reason is used.

Rather than having a code to identify who had the preference, I'd rather have codes that indicates that indicate the judgement or assessment made (e.g., religious preference, duplicate treatment, et cetera), and let the source of the information being recorded indicate whose preference we are talking about (provider or patient).  I'm not quite sure what the correct participation is here, but responsible party (the person in this case, who has primary responsibility for the reason being specified) seems to be closest.  Within that, the role class could then indicated whether this person was the patient, the patient's guardian, the provider, et cetera.

Hopefully, that could clean up the confusion that we have today.

Hashtag Soup: Relating QDM, HQMF, eMeasures, QueryHealth, QRDA, SIFramework and MeaningfulUse Stage2

This showed up in my inbox yesterday:

Hello Keith, 

I am trying to figure out how the following abbreviations are connected - NQF's QDM, HQMF, eMeasures, Query Health, QRDA, QDM based QRDAs, others.
Rather than individual definitions, I am a bit in the dark around how each of these are interconnected.

Appreciate your help.

Warm Regards, Shyam 

It's a question worthy of a full post, rather than a brief answer, so here goes.

---

QDM is the National Quality Forum's (NQF) Quality Data Model.  It is an information model representing the essential data needed to generate quality measures.  Because it is an information model, it doesn't necessarily go into the level of detail needed in an implementation, but it certainly describes the high level structures that an implementation needs to compute quality measures.

eMeasures is a term describing the electronic representation of quality measures.  In common use, it often refers to the electronic measures that NQF developed to represent the quality measures required under the ONC & CMS Meaningful Use regulations.  It is also used to refer to the HL7 HQMF.

HQMF stands for Health Quality Measure Format.  This is an HL7 Draft Standard for Trial Use (DSTU).  The DSTU is presently being reballoted by HL7 for a second release.  This is an electronic format for the representation of quality measures.  Release 1 is currently used by NQF to deliver eMeasures for Meaningful Use.  Release 2 was developed in large part based on pilot work being developed by Query Health.

Query Health is an ONC Standards and Interoperability Framework project whose purpose is to develop standards to enable sending the questions to the data.  Its key goal is to enable clinical research.  We used HQMF in query health because the kinds of questions that Quality Measures need answers too are often the same kinds of questions that show up in Clinical Research.  HQMF is a declarative format for expressing those questions.  We revised and prototyped a new schema for HQMF that is simpler, easier to read, and able to be computed in a variety of programming environments.  I've written quite a bit about Query Health on this blog.

QRDA stands for Quality Reporting Data Architecture.  If HQMF/Query Health/eMeasures represent the question, then QRDA represents the answers.  QRDA is an HL7 implementation guide on CDA Release 2 that describes the format for reporting quality data on a single patient (Category I), or aggregate results on multiple patients (Category III).  The former is a DSTU, the latter nearly so.  There is also an implementation guide showing how data modeled using the QDM can be represented in a QRDA.  Both Category I and Category III specifications have been identified as being required standard formats for reporting quality measures under the Meaningful Use 2014 Certification Criteria.

MAT is the Measure Authoring Tool.  This is a tool for creating eMeasures currently being maintained by NQF, but which will be transitioned to a new maintainer in early 2013.

VSAC is the NLM Value Set Authority Center, where value sets used for eMeasures and other standards used in Meaningful Use regulation are published.

If you want a poster-sized PDF of the content, you can get it via Google Drive:

Rethinking the Care Management profile in IHE

Several years ago, IHE PCC developed the Care Management (pdf) profile.  The idea behind this profile was to enable care managers (people) using a care management system to be able to access information from multiple data sources.  We had hoped that by specifying the data of interest (based on a care guideline) in a computable format, we could automate the generation of interfaces between various Health IT systems to the care management system.   The profile never took off because the standards we were using were neither well understood, nor very mature.  However, what I learned from that profile greatly influenced later HL7 work on HQMF.

I suggested that HQMF needs to have a data criteria section that describes the data of interest.  Over time, we made that section even better to support Query Health and HQMF Release 2.0 soon to be out for ballot.   Interest in the Care Management profile surfaced today in the IHE Face to Face meetings happening this week.

Given where the standards are now, it seems like it is possible to specify data of interest in an HQMF, without going any further to specify a measure.  From that, we can generate a CCDA, CCD, or QRDA document from an encounter that includes the necessary data of interest, and submit that to an HIE, Care Management system or other Health IT system managing the care for a patient (e.g., in a medical home or an ACO).

This is a paradigm that is already being used in part in some of the Beacon programs here in the US, and is fairly well understood.  I think it's time to shake the dust off the Care Management profile and rewrite it so that people will implement it.

On Parameterizing Templates in HL7

One of the outstanding discussions on QRDA was my negative comment on how they proposed to create dynamic templates.  I think the editors understand my comment a little bit better, but thought it would be worth writing down.

The current proposal was to create a template in QRDA that could support multiple measures with a similar structure, with the exception of the value set it used.  That template ID would just have specified root value (say 2.16.840.1.113883.19.4.21.13.2).  Then, you could "bind" the value set to the template by putting the value set OID (say 2.16.840.1.113883.19.9.4.5.1) in the extension.  So, now we have two templates:

<templateId root='2.16.840.1.113883.19.4.21.13.2'/>
<templateId root='2.16.840.1.113883.19.4.21.13.2' extension='2.16.840.1.113883.19.9.4.5.1 '/>

You'd never implement the first one.  The second one is what you would implement.  The challenge here (besides the fact that it is an egregious abuse of the HL7 II Data type), is that it doesn't support cases where there are multiple value set bindings to different components in the template.

I propose something a little bit different.  How about constructing the structural template so that it uses concept domains (a concept domain is an abstract definition of a value set or code system).

I'm going to create a new template (call it 2.16.840.1.113883.19.19.13.1.18.20) for a lab result observation structure that has bindings to a concept domains.

Asserting conformance to this template means that:
1.  The observation/code element shall contain a value  bound to the test result type concept domain.
2.  The observation/value element shall contain a value  bound to the test result value concept domain.
2.  The observation/interpretationCode element shall  shall contain a value bound to the test interpretation concept domain.

Now, we can create a couple of new value sets and a new template (2.16.840.1.113883.19.19.13.1.18.20.5.18).  Let's create a value set called detection tests.  Tests in this value set detect the presence of absence of a particular analyte or disease agent.  We'll also create a value set called "positive/negative results" which gives the two SNOMED CT codes used to report a positive or negative result, and a third value set (called "+/-") which gives the two HL7 codes used to interpret these results.

Asserting this new template means that:
1.  Data elements using the test result type concept domain shall use values in the detection tests value set.
2.  Data elements using the test result value concept domain shall use values in the positive/negative results value set.
3.  Data elements using the test interpretation concept domain shall use values bound to the "+/-" value set.

Now, where you find:
<templateId root='2.16.840.1.113883.19.19.13.1.18.20'/>
You can check the structure, and where you find:

<templateId root='2.16.840.1.113883.19.19.13.1.18.20.5.18'/>
You can check the values give come from the appropriate value sets.

Putting both of these together on the same template "binds" the value sets in the second template to the items in the first through concept domains.

Why is this important?  Well, you don't actually need to use the template ID to make these "binding assertions".  You could say:  If <realmCode code='US'/> then
1.  Data elements using the problem concept domain shall use (this value set) from SNOMED CT.
2.  Data elements using the lab result concept domain shall use (this value set) from LOINC.

Etcetera, all the way down through smoking status...

Aligning through Concept domains allows the vocabulary binding mechanisms to be reused, and supports all of the use cases.  It also doesn't abuse something in a way that will only further confuse people about the right way to use the II data type.

   Keith