Showing posts with label CCDA. Show all posts
Showing posts with label CCDA. Show all posts

Wednesday, September 18, 2019

One more time ...

It's a Wednesday morning in mid-September, and those of us at the HL7 Working Group meeting will shortly be hearing from Ed Hammond and some will be awarded vases in Duke Blue, and so that means it's also time for me to award the next Ad Hoc Harley.

This next awardee is someone I'd best describe as a passionate lifetime student.  I first met this person while I was chair of the IHE Patient Care Coordination workgroup in IHE and they were just learning CDA.  I love to teach, and they absorbed just about everything I could teach and then sought out more. 

It didn't take long before the two of us could spend an hour of committee time discussing the exact way in which some small piece of CDA could be modeled so that it was just right, and the semantics meant exactly what they should.  A very strong leader, we were sure to clash on some topics, but always with mutual respect and retaining friendship even when we disagreed.  Health IT is better for those sorts of interactions, something not everyone appreciates (but I do, and so do they).

Before too long they had become CDA Certified, led a workgroup developing multiple CDA specifications and an author/editor of as many CDA implementation guides as I had.  They've been deeply involved in specifications for long term care, quality measurement, first in CDA and later in FHIR.  Most recently they've been leading terminology efforts with a team developing specifications that will aid the under served by enabling the capture of Social Determinants of Health in the HL7 Gravity Project.

I look forward to continuing to work with her, and learning what she has to teach me in this space myself as I award the next Ad Hoc Harley to ...

Lisa Nelson, BA, MBA, MMI of MaxMD


for being a lifetime student and a teacher of leaders...


Tuesday, February 5, 2019

History of the Concern Act in CCDA

This particular post results from questions on the HL7 Structured Documents workgroup's e-mail list.  It basically boils down to a question of why the Condition and Allergy observations have an Act structure wrapping the Observation related to the Condition or Allergy that is described within.

The answers are below:
  1. What were the intended semantics associated with the effectiveTime on the concern act?
    This is the time that the reported problem became the concern of the provider.
  2. What were the semantics of the author on the concern act as opposed to the semantics of the author on the Problem Observation?
    One provider can be concerned about an observation made by another provider.  The author of the concern is basically the person saying, this is an issue I need to track.
  3. What were the semantics of the Priority Preference on the concern act as opposed to the semantics of the Priority Preference on the Problem Observation?
    Again, this is related to the distinction between the "concern" and the "condition".  A low priority problem for the patient (e.g., a minor twinge in their tooth), might be a high priority concern for the patient's dentist.
  4. How was the design of the Problem Concern intend to be used relative to representing “the patient’s problem list”? 
    The provider's problem list for the patient can be viewed as the provider's record of the concerns they have regarding the health of the patient.


General Background

In 2005, shortly after CDA was introduced, HL7 and IHE collaborated on a joint project to develop templates to exchange a care record summary.  HL7 was to to work on level 1 and 2 templates (documents and sections), and IHE was to work on Level 3 templates (entries) to enable the exchange of of this data (you might recall that ASTM was building the CCR around this time as well).  I was the editor for both the HL7 and IHE documents (and later the editor for the HITSP C32, and one of many editors for CCD and later C-CDA).

Involved in this project also from the HL7 and IHE sides was Dan Russler, cochair of the Patient Care workgroup at the time in HL7, and alongside me, of the IHE Patient Care Coordination Workgroup.  Dan brought extensive knowledge of V3 structures and vocabulary that HL7 had been developing in Patient Care to the project, and I was the go to person for mapping this to CDA.  The project had been cooked up by leadership of HL7 and IHE to basically try to get something done on care record exchange, because some of the IHE sponsors who had also been engaged with the CCR project were getting tired of it getting bogged down in ASTM.  Also involved from the HL7 and IHE sides was Larry McKnight, a physician from Siemens.

In HL7, we based a lot of our work on the Vancouver Island Health Authority's e-Medical Summary, developed for CDA Release 2.0 in 2004 (before CDA Release 2.0 had even finished publication).  That organization was the first organization to use Schematron for validation in CDA documents, something that continues to this day, 15 years later.  But the eMS didn't really get into details for level 3 templates for problems, meds and allergies (our key areas of concern in this project).  Fortunately, the HL7 Patient Care group had been working on vocabulary and modeling to describe Concerns about a patient.

If you look at the changes to CCD over time, you will see in C-CDA 1.1 that the Problem Concern Act uses CONCERN from ActClass in Act.code.  This is because it couldn't be used in Act.class because CONCERN hadn't been an accepted V3 vocabulary term at the time CDA R2 was completed.  This resulted in part from long running debates over the semantics of the CONCERN Act, which didn't finally get resolved until 2014 and later after the third and final push to complete this work.

The Problem Concern Act in C-CDA is the representation in CDA of the semantics of a Health Concern, which is distinct from the underlying problem that causes the concern.  Concern is about provider awareness of a problem, while the problem observation is directly related to the problem itself.  Consider this: I have Cervicular Radiculopathy again, but this time in my left arm.  I told my physician about it on January 19th, but had symptoms going back to a week before, and I was examined on the 22nd.  So, the concern about my nerve pain should be dated 1/19, or perhaps 1/22 after he evaluated me, but the problem itself should have a start date somewhere around 1/11.  When this problem is resolved (say in a few more weeks), it can be marked in the problem observation with regard to the date is was resolved, and in the concern act when that resolution is reported to my provider (which will likely be after that).

The health concern itself can change over time, and acts as a wrapper around the relevant data: When I originally had the problem, we could have included not just the physician observation, but also subsequent diagnostic test data, the treatment plan and evaluation.  All of this development of the Health Concern act evolves from the Problem Oriented Medical Record pioneered by Dr. Larry Weed.

   Keith






Monday, July 23, 2018

Will Faxes never Die?

A very old fax machine
A question comes to me from a former colleague that I found interesting:

Can you convert a fax document into a CCDA for Direct Messaging?

Yes.  Here's how, at three different levels of quality:

Unstructured Document

This is the simplest method, but it won't meet requirements for 2014 or 2015 Certification.  It's still somewhat useful.

  1. Convert the image into a bitmap file format such as PDF or PNG.
  2. Create a CCDA Unstructured Document.  Optionally, apply the IHE Scanned Document requirements to the content as well.
  3. Include the document into a Direct Message

Getting to Electronic Text

Getting the content to meet 2014 or 2015 requirements for certification means doing quite a bit of additional work.  First step is to get to electronic text.
  1. First, you have to apply text recognition technology to the output to turn it into electronic text.  This converts the image content into letters and symbols that the computer can recongize.
  2. From this, create a bare-bones narrative structure with headings and section content.  Apply some very basic Natural Language Processing (NLP) to recognize headings and section content.  Signals such as line spacing, paragraph formatting and font styles are helpful here (that would often be included in a more than basic text recognition pass).  From here, you could create a Level 2 CDA (note, NOT a C-CDA yet) that would be MORE useful to the receiver.

Getting to Certification

After getting to electronic text, now you need to get to CCDA Entries.  It can be done, I've been there and done that more than a decade ago.
  1. From the previous step now you need to code the section headings to LOINC, and match the document content to an appropriate C-CDA template (knowing that you can also mix and match sections from other C-CDA documents into the base C-CDA CCD requirements).  At this point, you are at level 2 with coded sections.
  2. So finally, you need to run some specialized NLP to recognize things like problems, medications, allergies, et cetera ... and THEN
  3. Convert the specialized content to match the C-CDA template chosen in step 3.
And now, you COULD meet 2014 or 2015 Certification requirements.

Would I do this?

The question not asked, but which I will answer is:

Would you convert a fax document into a CCDA for Direct Messaging?

Probably not, AND certainly not for the structured content option.  Current NLP algorithms being what they are, you could probably get to about 95%  accuracy with the structured markup, which means about 1 error in 20 items.  That's MULTIPLE structure recognition errors per page, NOT a level of accuracy appropriate for patient care. The level of effort involved in cleaning up someone else's data is huge, the value obtained from it is very rarely worth the cost.  You are better off figuring out how to give your high volume fax senders a way to send you something better.

I might consider implementing the Unstructured Document mechanism as a feature for providers that are getting faxed today, as many would find it of some use.  It's not really much more though than giving them an e-mail end-point attached to a fax number, so again, of very little additional value.

Monday, June 4, 2018

Coloring within the Lines

When you first learned to color as a child, someone handed you a picture (like the following) and a bunch of crayons:
At first, you probably just threw blotches of color on the page, ignoring the lines. Then someone explained to you about keeping color within the lines. You practiced and practiced, and then realize that you could do really cool horse pictures within the lines. Then you turned your horse into a Zebra.
Not content with that, you made it into a Unicorn ... and later a Pegasus.

This is a metaphor for interoperability journey we started upon with Meaningful Use in 2010 and where we are headed in 2018.

First we had data that we needed to exchange, and a name for it (we called in the common clinical data set, but a horse by any other name is still a horse).  And we watched as everyone struggled to stay within the lines (the CCD specification).  Some even created a color-by-number guide that made it easier to make a pretty CCD.

When creating this horse picture, we stayed inside the lines with HL7 CDA, but to meet certain ONC requirements to make our horse look like a Zebra, we had to change the way we colored a little bit, but still came up with something that fit the lines (it just had a few more lines), and then we had our Zebra.

At times though, there were things that just didn't fit, and so we had to come up with a horn, or wings.  We did our best to create new lines that fit with (but not within) the existing lines, and went beyond the original drawing but still had the same general appearance, producing the C-CDA.

After a while, there's not much more to do with our horse (CDA), so we start with a new drawing (FHIR).  This horse will still get you from point A to point B, but much faster (no wings needed).

And that's progress in interoperability.


Wednesday, November 29, 2017

How to say no ... 2017 Edition

RochesterBestiary detail Griffin

Thanks goes out to Brett Marquard for suggesting this update!

Negation has always been a beast of a problem.  In 2011 I described a bestiary of negated concepts used in CDA, and how to relate them using the standard.  As time goes by and the standard becomes more widely used, our understanding of the best practices also changes.

So here is the original bestiary with links to examples to the CURRENTLY ACCEPTED best weapons for slaying these beasts when known and provided by the CDA Examples task force.  And I'll be posting a link to this post in the original.

  1. Patient is not on THIS drug.
    Example pending, check back in a bit
  2. Patient is not on ANY drugs.
    No Medications.
  3. Patient does not have THIS ailment.
    No Known Problems
  4. Patient does not have ANY ailment.
    No Known Problems
  5. Patient does not have THIS allergy.
    Example pending, check back in a bit
  6. Patient does not have ANY allergy.
    No Known Allergies
  7. Patient does not have ANY MEDICATION allergy.*
    No Known Medication Allergies
* New in this edition

Examples for all of the above and more can be found at http://cdasearch.hl7.org/

   Keith



Monday, October 9, 2017

Where do I find the Medication Generic Name in a CCD Document

The answer is, it depends on your CCD version:

CCDA 2.1 has this to say:
 4. SHALL contain exactly one [1..1] manufacturedMaterial (CONF:1098-7411).
     Note: A medication should be recorded as a pre-coordinated ingredient + strength + dose form (e.g., “metoprolol 25mg tablet”, “amoxicillin 400mg/5mL suspension”) where possible. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack).
     1. This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.4 DYNAMIC (CONF:1098-7412).
         1. This code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Clinical Substance urn:oid:2.16.840.1.113762.1.4.1010.2 DYNAMIC (CONF:1098-31884).

CCDA 1.1 has this to say:
 4. SHALL contain exactly one [1..1] manufacturedMaterial (CONF:81-7411).
     Note: A medication should be recorded as a pre-coordinated ingredient + strength + dose form (e.g., “metoprolol 25mg tablet”, “amoxicillin 400mg/5mL suspension”) where possible. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack).
     1. This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.4 DYNAMIC (CONF:81-7412).
         1. This code SHOULD contain zero or one [0..1] originalText (CONF:81-7413).
             1. The originalText, if present, SHOULD contain zero or one [0..1] reference (CONF:81-15986).
                 1. The reference, if present, SHOULD contain zero or one [0..1] @value (CONF:81-15987).
                     1. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1) (CONF:81-15988).
         2. This code MAY contain zero or more [0..*] translation (CONF:81-7414).
             1. Translations can be used to represent generic product name, packaged product code, etc (CONF:81-16875).

HITSP C32 has this to say (you can actually find this in the HITSP C83 specification):
2.2.2.8.13 Free Text Product Name Constraints
C83-[DE-8.15-CDA-1] The product (generic) name SHALL appear in the <originalText> element beneath the <code>

It's pretty clear that the preferred way to handle this changed in between CCD 1.0 (HITSP C32) and CCDA 1.1, and also that some critical information loss occurred with regard to how to record generic name between CCDA 1.1 and 2.1.  I think as industry understanding of CDA expanded, the need to express the detail about generic name probably changed, but not necessarily for the better.

If you want to include generic name, you would do it in a translation -- when you don't already list the drug using an RxNORM code from the Semantic Clinical Drug value set (generic codes) (e.g., you use a Semantic Branded Drug code).

I have two statements to make about this:

  1. Not all implementers are informaticists or would understand the distinction between types of RxNorm codes.  We (HL7) need to remember to speak to who is doing the work, not to ourselves.
  2. Brand and Generic information is already represented as relationships embedded in the RxNorm terminology itself.  The simultaneous transmission of a brand code and a generic code for that same drug simply repeats what is already present in RxNorm.  The advice I give these days would be to trust RxNorm before you trust your trading partner, and if what your trading partner tells you CONFLICTS, someone needs to go raise a red flag about inconsistent data.

   Keith



Thursday, August 17, 2017

You really don't understand the CCDA standard when ...


I often hear the complaint (about CDA documents) that: I just want to see ...

At the ONC meeting on Tuesday a provider remarked that in order to understand what was happening for a patient a provider read through 18 hundred pages of CCDA documents.  This was accompanied by the statement that they understood the standard.

I do (and did) protest.  If providers are reading that many pages, then the only thing understood about the standard is the word "Document", and understanding of the application of standards to interoperability in general is also lacking.  Just as in medicine where there is no singular magic pill to make a patient healthy, there isn't just one standard to apply to the various problems associated with interoperability.

CDA documents are snapshots in time of the data associated with a patient care event.  All the data elements found in the the dozen and a half elements defined by the Common Clinical Data Set. The CCD is supposed to contain the relevant and pertinent data, but we know that what is relevant and pertinent to one provider isn't necessarily to another. Even so, it's how the data that is presented to the end user (the provider) that is the problem, not the standard that gets the data from that data set from one provider to another.

Consider multiple ways to address this issue that have all been worked in other standards efforts:
  1. Consolidate data from multiple documents into a reasonable longitudinal view that reconciles information from across multiple sources of data.  There are OTHER standards that explain how to do this (e.g., the IHE Reconciliation Profile).  CCDA is about moving the data, and just like the web, you have to apply other standards to solve other problems.
  2. Use an XSL Stylesheet to make the data easier to read and arrange according to provider preferences.  HL7 and ONC ran a CDA Rendering challenge that produced a number of freely available open source solutions.  CDA is about communication of data.  It is up to applications to make it usable.  CDA isn't a standard for display, or a standard for application function.  It's a standard for communication.  
  3. Allow providers to incorporate the data as it becomes available.  If you implement workflows that support a 360 Closed Loop referral / consultation processes, and enable incorporation of the data into the EHR when it becomes available, you avoid trying to manage and consume multiple documents in "one swell FUPE*".
FHIR isn't going to magically change the challenge of viewing "all the data", but it is going to change the approach used by folks (and that will be the subject of a future post).

   -- Keith

* That's not a mispelling, but rather an acronym standing for Fowled-Up Process Execution


Thursday, January 12, 2017

What version of CCDA Document is this?

This is a question I get internally and externally all the time.  The answer is pretty straightforward. Look at the templateId elements underneath the <ClinicalDocument> element.  There will be at least two and possibly more.

If you see: <templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2015-08-01"/>
you can be sure this document is a CCDA Release 2.1 or later.  It will also bear:
<templateId root="2.16.840.1.113883.10.20.22.1.1"/> indicating that it is backwards compatible with CCDA Release 1.1.  

If you only have one templateId where root="2.16.840.1.113883.10.20.22.1.1" and there is no extension (like extension="2015-08-01"), you have a CCDA 1.1 that hasn't been uplifted to CCDA 2.1 yet.

If you have a templateId where root="2.16.840.1.113883.10.20.22.1.1" but extension="2014-06-09then you have CCDA 2.0 and it won't be backwards compatible with CCDA 1.1.

Now, what if you have a templateId with 2.16.840.1.113883.10.20.1?  Well, now were talking old-school CCD, first edition.  It's a fine thing that has mellowed with age.

What you really want to see is <Composition> or <Bundle> as your first element, in which case you might be dealing with CDA or CCDA on FHIR.

It's all very confusing, but not really.

Each of them provides a core set of data about the patient, and for every single one of them, it's pretty much the same set of elements.  Those you might call a Continuity of Care Record.  There are a lot of ways to write the XML, but in the end, the data is essentially the same.

   Keith

P.S.  Thanks to Corey Spears for taking up the challenge of answering this question on the Structured Docments workgroup.  I'd already half written this post when he responded.

Friday, August 21, 2015

It's time again...

It's that time again to award the next Ad Hoc Harley. This one goes out to a young fellow who has been very instrumental in developing CDA standards for years.  I've watched him grow from the new kid in town to being a very effective leader in HL7 and elsewhere.

He does a ton of work, is very thorough and organized, and just a general pleasure to work with all around.  He makes sure every voice is heard, and is able to deal with cranky people like me with a great deal of grace.

This particular award goes out to him for his leadership in the development of the C-CDA Release 2.1 DSTU.  When Structured Documents started looking at the backwards compatibility problems (at my urging), he joined in and helped a good deal with our initial analysis.  When we decided that we could, and therefore must do something to improve the backwards compatibility of the C-CDA 2.0 specification, he stepped up to the plate in a very big way.

He convinced his stakeholders to let him lead this effort, and also got them to provide resources to help with the detailed analysis.  His familiarity with Trifolia and the folks who developed it also helped a great deal in the early stages of the C-CDA 2.1 DSTU Update project to get us all going. This DSTU, by the way, was started in a project that was initiated less than 3 months ago.  It was a mission critical problem for Health IT, and is probably the quickest DSTU Update in HL7 history. Quite honestly, the healthcare industry owes this fellow a great deal of thanks for development of the latest edition of the DSTU.  We quite literally couldn't have done this without him.


This certifies that  
Brett Marquard of River Rock Associates


Has hereby been recognized for his contributions towards Meaningful Interoperability using the HL7 CDA Standard

P.S. C-CDA DSTU 2.1 is now available to HL7 Members and will be publicly available to non-members in 90 days (or very likely sooner if formally named in the ONC Certification and Standards Final rule expected in the next couple of months).


Friday, August 7, 2015

Moving forward from CCDA 1.1 to C-CDA 2.1

I just finished cleaning up the C-CDA 2.0 samples and reworking them for C-CDA 2.1.  As a result, I have a few notes already on what it takes to move up from 1.1 to 2.1 for those of you looking to plan ahead.

For any changed templates (there will be a list in C-CDA 2.1), you'll need to add the C-CDA 2.1 template identifier to your existing 1.1 template.

For problems, you'll need to add the LOINC equivalents in code/translation, as shown below.

<code code="64572001" displayName="Condition" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">
    <translation code="75323-6" displayName="Condition" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1"/>
</code>

<code code="409586006" displayName="Complaint" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96">
    <translation code="75322-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Complaint"/>
</code>

For the vital signs organizer, you'll need to do something very similar.

<code code="46680005" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Vital signs">
    <translation code="74728-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Vital signs"/>
</code>

And also for Cognitive Function.

<code code="2264892003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Number of pressure ulcers">
    <translation code="75277-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Number of pressure ulcers"/>
</code>

And Pressure Ulcers.
<code code='373930000' displayName="Cognitive function" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">
    <translation code="75275-8" displayName="Cognitive function" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
</code>

And a few places where ASSERTION shows up.
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4">
    <translation code="75321-0" displayName="Finding" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
</code>

You may yet find a few others, these were simply the ones that went on my electronic scratch pad as I did various edits to correct the samples.  This kind of stuff will take longer for an engineer to work out than it will to implement, probably on the order of 10:1.  So call it two weeks to design the changes, and then a day to implement them.  There's more to 2.1 than making it easy to move up a version, the main point was to retain compatibility with what's already in the field.  However, there's also some new stuff (like the Care Plan document), which will be incredibly valuable.

   Keith

P.S.  NOTE: While this post is tagged Stage 3 we have NO GUARANTEES that CCDA 2.1 will be named for Stage 3.  However, given how hard everyone has worked to make this happen, I am quite hopeful.

Monday, July 13, 2015

Trifolia Template Comparison for CCDA 2.1

I finished my Trifolia template comparison tool last night and used it to compare C-CDA 1.1 to C-CDA 2.1.  You can find my detailed report here. A quick summary of results follows along with some general observations:

TypeIssuesComments
Major21Most were issues where 1.1 is more restrictive (has SHALL constraints) in content that MAY be present.  It's the "X, if present, SHALL" that causes a potential problem. These constraints most often appear in performer//addr and performer//telecom.  There are also a couple of possibly missed constraints, though CCDA 1.1 doesn't always follow the same patterns with Narrative text constraints.
Minor3These were mostly cases where a deprecated template which was removed in C-CDA 2.1 might need to be addressed in a SHOULD NOT constraint, just to make the point. If folks strongly disagree, I can back down.
Future9Minor inconsistencies in constraint splitting, or where something might be fixed or clarified without changing the meaning.  These can all wait for later as maintenance as far as I'm concerned.
Total33Overall, not bad for several dozen pages of constraints.

You can get the comparison stylesheet here.  Tonight I'm probably going to compare 2.0 to 2.1 just to see what shows up.  That has a different purpose.  I want to see what it takes to create a 2.1/2.0 aware C-CDA consumer.  I think that might be a useful document to add to the C-CDA 2.1 package.



Friday, July 10, 2015

Comparing Template Versions in CCDA

One of the things that I'm doing right now is working on examples for C-CDA 2.1.  To evaluate these examples, I'm running them through both the 1.1 and 2.1 schematons produced by Trifolia, as well as a couple of other validators.  Sometimes the validators don't agree, as I've discussed previously.

To better address the compatibility issues and to verify that what I have is correct, I wanted to be able to compare requirements side by side.  So, I build an XSLT stylesheet to compare the output from Trifolia for two different template versions.  Here's how it works:

It processes an XML file containing the old XML Template in the format produced by Trifolia.  It accepts one parameter, the name of the new IG XML file (in that same format) to compare it to.  For each template in the input file, it attempts to find a matching template in the new IG, perhaps with a new version.  If there is no new version, it doesn't do anything.  If there is, it produces a table comparing the two templates.

The table displays the template metadata (IG Name, Title, Identifier, Version, Publication Status, Template Type, Open/Closed Status, Context, Previous Version, and Description).  If differences are found, the metadata name cell is highlighted in gray.

Then it traverses all the constraints within either template, sorted by context, and simply compares the narrative of each constraint, ignoring minor differences due to CONF: statement numbering in its comparison.  If a difference is found, it highlights the context cell with a background color of red, yellow or green depending on whether the original constraint was SHALL, SHOULD or MAY.

What appears below is a sample of the output.  There's still a bug or two in this, in that when two constraints apply to the same context (entryRelationship), the code doesn't correctly deal with that.  I have some work to do there yet.  When I get around to fixing that, I'll post the stylesheet.  You can see a sample of the output below.

This has proved to be very useful in comparing the CCDA 1.1 and 2.1 templates.  I wish I'd had the time to do this when we started on the compatibility work a few months back, as it would have made my life a lot easier.  However, I hadn't at that time figured out how to get a good comparison.  That's probably because I wasn't thinking about how a minimally viable comparison might work.  Now that I have that, I can actually get an even better comparison with a bit more work.

   Keith

US Realm Header

FeatureOriginalNew
IGConsolidationConsolidation V3
titleUS Realm HeaderUS Realm Header (V3)
identifier2.16.840.1.113883.10.20.22.1.12.16.840.1.113883.10.20.22.1.1
version2015-08-01:
publishStatusPublishedDraft
templateTypedocumentdocument
isOpentruetrue
contextTypeClinicalDocumentClinicalDocument
PreviousVersionUS Realm Header (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2014-06-09)
DescriptionThis section describes constraints that apply to the header for all documents within the scope of this implementation guide. Header constraints specific to each document type are described in the appropriate document-specific section below.This template defines constraints that represent common administrative and demographic concepts for US Realm CDA documents. Further specification, such as ClinicalDocument/code, are provided in document templates that conform to this template.
ClinicalDocument/realmCodeSHALL contain exactly one [1..1] realmCode="US" (CONF:16791).SHALL contain exactly one [1..1] realmCode="US" (CONF:16791).
ClinicalDocument/typeIdSHALL contain exactly one [1..1] typeId (CONF:5361).SHALL contain exactly one [1..1] typeId (CONF:5361).
ClinicalDocument/typeId/​@rootThis typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).This typeId SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" (CONF:5250).
ClinicalDocument/typeId/​@extensionThis typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).This typeId SHALL contain exactly one [1..1] @extension="POCD_HD000040" (CONF:5251).
ClinicalDocument/templateIdSHALL contain exactly one [1..1] templateId (CONF:5252) such that itSHALL contain exactly one [1..1] templateId (CONF:5252) such that it
ClinicalDocument/templateId/​@rootSHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).
ClinicalDocument/templateId/​@extensionSHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:32503).
ClinicalDocument/idSHALL contain exactly one [1..1] id (CONF:5363).SHALL contain exactly one [1..1] id (CONF:5363).
ClinicalDocument/codeSHALL contain exactly one [1..1] code (CONF:5253).SHALL contain exactly one [1..1] code (CONF:5253).
ClinicalDocument/titleSHALL contain exactly one [1..1] title (CONF:5254).SHALL contain exactly one [1..1] title (CONF:5254).
ClinicalDocument/effectiveTimeSHALL contain exactly one [1..1] effectiveTime (CONF:5256).SHALL contain exactly one [1..1] US Realm Date and Time (DTM.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.4) (CONF:5256).
ClinicalDocument/confidentialityCodeSHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC 2010-04-21 (CONF:5259).SHALL contain exactly one [1..1] confidentialityCode, which SHOULD be selected from ValueSet HL7 BasicConfidentialityKind urn:oid:2.16.840.1.113883.1.11.16926 STATIC (CONF:5259).


Thursday, July 9, 2015

Criticality vs. Severity in Allergies in HL7 CCDA

The HL7 Structured Documents workgroup had on its agenda to discuss updates to C-CDA 1.1 and 2.1 to address Allergy Criticality and Severity.  I first mentioned this problem at the end of last month.

Today, we discussed this in committee and with John Quinn, the HL7 CTO (who must approve errata), and agreed to address this issue as errata in the CCDA 2.1 DSTU Update project.  Once again, HL7 has shown that they can be responsive in addressing a critical issue.  I'm pleased to see this, and can only hope that we don't wind up being so responsive that we need to institute  Bureau of Sabotage.

Effectively what we will be doing in CCDA 2.1 DSTU Update project is create a new template to support criticality, and deprecating use of Severity template on the allergy itself.

   -- Keith


For those who aren't familiar with the issue, I will reproduce the important content below:

The stated project need for SDWG project 1014 is “Proposed US federal regulation has identified C-CDA 2.0 as being the preferred way forward, but introduces a need for compatibility that was not anticipated for in the original project scope.  An update is needed to ensure that new templates are backwards compatible.

Existing Consolidated CDA (C-CDA) needs to be enhanced by adding templates to represent priority data elements, and modified/new section level and document level templates needed for transitions of care and care plans, areas essential to patient care and the meaningful use of EHRs; we need to incorporate errata; and we want to address areas that implementers have found to be ambiguous.”    Patient Care is a co-sponsor of this project originally approved in 2013.  The TSC approved the updated project scope statement on June 9, 2015. 

The Patient Care Work Group (PCWG) has been working on the Allergy and Intolerance topic to update and harmonize standards since 2010.  The products related to this work include an Allergy and Intolerance Domain Analysis Model, Allergy and Intolerance Clinical Models (DSTU) and an Allergy and Intolerance FHIR resource.  In order to ensure harmonization across HL7 standards, the Patient Care WG conducted an extensive review of C-CDA R1.1 and R2.0.  During this review, the PCWG presented on-going issues to the SDWG at two face-to-face sessions (most recently at the Paris WG meeting) in order to reinforce the findings and recommendations of this year-long analysis of known C-CDA issues.  The results of this analysis were posted as DSTU comments for C-CDA R1.0 (Comment 643) and C-CDA R2.0 (Comment 644).   At the request of the SDWG, multiple comments were submitted against each C-CDA version in tabular format.  This summary document can also be found on the Patient Care wiki: C-CDA Harmonization Table.

The Issue

Patient Care has kept the SDWG apprised of work in the area of Allergies and Intolerances since this work began in 2010.  Multiple presentations on this topic were given at each Work Group meeting (see minutes from each joint PCWG/SDWG Thursday Q2).  As the PC WG harmonization process continued, it was apparent that the C-CDA did not recognize some of the concepts within the PCWG DAM or clinical models, or the FHIR allergy and intolerance resource.  Working with a primary representative and additional representatives from the SDWG, the PCWG has diligently outlined and proposed solutions to ensure harmonization all of the HL7 products that address allergies and intolerances.  This has included extensive terminology work in coding systems including HL7, SNOMED CT and LOINC. 

Extensive comments and recommendations were posted to the DSTU website for both C-CDA R1.1 and R2.0, with the expectation that these comments would be duly considered during the current review of errata and backwards compatibility issues.  Comments from the PCWG are substantive and seek to ensure that the use of C-CDA provides clinically correct data exchange between providers. 

On Thursday, June 25, the Patient Care WG presented a synthesis of these comments to the SDWG.  The most significant issue at hand relates to the use of the Severity Template in two contexts related to the Allergy and Intolerance Observation and the Reaction Observation. 

The current relationship of the Severity Template is shown in this diagram taken from C-CDA R1.1.  This relationship is retained in R2.0:  The relationship between the allergy observation and severity is erroneous, is creating confusion through ambiguity and does not reflect the current relationships in other HL7 allergy and intolerance standards.


The PCWG Allergy and Intolerance DAM and Clinical Models as well as the FHIR resource have a different relationship. 


A reaction is correctly described by severity, e.g. a patient had a mild reaction to a drug, or a severe reaction to a food.  However, the allergic condition is not described in terms of severity, rather the term criticality.  The concept of criticality is in the RIM as the code “CRIT”[1] in ActCode/ObservationType, and is associated with the allergic or intolerant condition. 

The definition of criticality as per the PCWG is as follows:  A clinical judgment as to the worst case result of a future exposure (including substance administration). When the worst case result is assessed to have a life-threatening or organ system threatening potential, it is considered to be of high criticality.

It is important to note that there is not a 1:1 relationship between the severity of a reaction and the criticality of the condition.  For example a patient might have a severe reaction to a medication (nausea) however that condition has a low criticality – e.g. the medication can still be prescribed if medically indicated.  Conversely, a child may have a mild reaction on the first exposure to a peanut, however a repeat exposure to peanuts may be life threatening and therefore of high criticality.

After the presentation by the PCWG on June 25 to the SDWG, the group discussed the issues at hand for some 30 minutes.  Despite an acknowledgement of the issues, no resolution was proposed nor voted on by the SDWG. 

Patient Safety and Clinical Practice

The PCWG has many other DSTU comments – however, we are writing to ensure that the criticality concept is included without delay in the C-CDA templates. 

Currently the use of severity in the context of a reaction and also in the context of a condition has the following potential consequences in systems exchanging information on allergies and intolerances:

1.      Patient safety issue:  When a system reports an allergic or intolerant reaction with mild severity but which is associated with a condition of high criticality (e.g. the risk of a life threatening reaction), based on severity alone a receiving system could allow an order to be processed for a drug or medication that should not be prescribed.  The current construct in the C-CDA does not capture or convey the correct information to mitigate this risk.
2.      The current construct does not allow for the most effective treatment:  A patient may report a severe reaction to a medication, such as “severe nausea” – however, nausea in most cases is of low criticality. A similar example is the common reaction to epinephrine (adrenaline) where most patients would describe their nausea, vomiting and sweating as severe – but if adrenaline is clinically indicated, it will be prescribed.   The current C-CDA construct is unable to correctly convey this information.
3.      Alert fatigue:  Clinicians often complain of alert fatigue, including for alerts for the severity of an allergic condition, since it is a spurious concept.  Given the documented drug-allergy alert override rate of around 90%[2], the use of criticality will clearly convey issues that require a careful consideration of the clinical options. 

In addition to the DSTU comments prepared by the PCWG, the C-CDA R2 ballot comments included a comment on the use of severity in two contexts.  The reconciliation spreadsheet for the 2013 ballot (Comment 290) noted under the disposition that SDWG would consult with the Allergy and Intolerance DAM.  However the final disposition reads as follows:   "In CCD.xml, add commenting [sic] which relates to the description in the severity template: ""When the Severity Observation is associated directly with an allergy it characterizes the allergy. When the Severity Observation is associated with a Reaction Observation it characterizes a Reaction."  This statement is incorrect, and it is unfortunate that the use of criticality (a concept currently existing in the RIM) was not considered. 

The C-CDA R2.1 Project

SDWG is considering candidate errata for C-CDA 2.1, a project designed to ensure backwards compatibility from R2.0 to R1.1 based on considerations related to the Meaningful Use 3 NPRM.  The project wiki is here: http://wiki.hl7.org/index.php?title=Consolidated_CDA_R2.1_DSTU_Update and the need for the project opinion is here: http://motorcycleguy.blogspot.com/2015/05/tell-onc-to-use-ccda-21-for-stage3-2015.html

What are errata?

The SDWG has discussed what errata are: (the post is the opinion of the author) http://motorcycleguy.blogspot.com/2013/03/defining-errata.html

The Chicago Manual of Style defines errata as follows: "Errata, lists of errors and their corrections, may take the form of loose, inserted sheets or bound-in pages. An errata sheet is definitely not a usual part of a book. It should never be supplied to correct simple typographical errors (which may be rectified in a later printing) or to insert additions to, or revisions of, the printed text (which should wait for the next edition of the book). It is a device to be used only in extreme cases where errors severe enough to cause misunderstanding are detected too late to correct in the normal way but before the finished (book) is distributed. Then the errors may be listed with their locations and their corrections on a sheet that is tipped in, either before or after the book is bound, or laid in loose, usually inside the front cover of the book.
Reference:  Chicago Manual of Style:  (referenced June 28, 2015) http://www.chicagomanualofstyle.org/home.html

Is the issue of criticality an erratum?  The PCWG feels that the omission of the criticality concept is of sufficient gravity to qualify as an erratum that must be considered in the current C-CDA 2.1 process.  The risk of not dealing with the criticality issue at this time is that the Meaningful Use 3 standard will point to a version of the C-CDA that is clinically incorrect and has the potential to cause patient harm. 

The PCWG understands the alacrity with which the errata process must occur to meet federal timelines.  The current timeline for C-CDA DSTU errata review is due to begin on July 1 and end on July 10th, 2015.  While the HL7 Governance and Operations Manual describes the process for submission of DSTU errata to the HL7 CTO, the PCWG appeals to the HL7 SDWG to duly consider this request prior to finalizing C-CDA 2.1 comments through the DSTU errata process.  Normally such an activity would be balloted allowing for broad member comment. 

Outcome Requested

The C-CDA is cited as the means to support health information exchange within the NPRM[3] for MU 3.    HL7 needs to ensure that the information exchanged is correct, based on current standards such as the RIM, and responsibly mitigates the risk of ambiguous and clinically incorrect information. The Patient Care WG respectfully requests that the concept of criticality be added to the C-CDA standard as an erratum because of the risk of patient harm. 

While the addition of a criticality template to C-CDA would be the most complete solution to this issue, there are several other paths forward:
1. At a minimum: Change the incorrectly referenced severity template to SHOULD NOT at the Allergy Intolerance Observation level.
2. If possible: Add a MAY conformance to the Allergy Intolerance Observation that permits use of the Criticality Observation.

The PCWG stands ready to assist with this endeavor. 

Respectfully submitted by the Patient Care WG Allergy and Intolerance Project Team,




[1] The current RIM definition of criticality is: CRIT (criticality) An observation representing a clinical judgment as to the worst case result of a future occurrence or the evolution of a current occurrence. It would be based on the severity of past occurrences, the details of what produced the past occurrences and the life-threatening or organ system threatening potential of the observation type.  The PCWG has a harmonization request pending to update this definition. 
[2] Bryant, AD, Fletcher, GS, Payne, TH.  Drug Interaction override rates in the Meaningful Use era – no evidence of progress.  App Clin Infor 2014:5(3);802-813 http://www.ncbi.nlm.nih.gov/pubmed/25298818


Tuesday, July 7, 2015

How Good it your CCDA Validator

I'm presently evaluating the HL7 C-CDA DSTU 2.1 update.  I'm doing it by way of updating the DSTU 2.0 sample files to conform to DSTU 2.1.  Along the way I've been testing my samples against both the 2.1 specification, and the 1.1 specification which it is to be backwards compatible with.

I have various validation tools for 1.1.  There's the Schematron produced by Trifolia, the TTT testing tool used for Meaningful Use, and the SITE Tool, as well as Josh Mandel's SMART CCDA Scorecard, and if I dug around hard enough, I could probably also find an Art Decor based validator.

Each one of these provides overlapping results.  Some are more up to date that others with HL7 Errata.  I'm still finding bugs with each of these so far.

One of the challenges that we have as an industry is that there is no single authority on what is a valid CCDA.  It should be HL7, but since ONC oversees the Certification program, and NIST develops the tools for that program, we have three different validators with slightly different ideas about what is a valid CCDA 1.1 document.

The validators are of varying quality with respect to how they work.  The Schematron-based tools are my favorite, simply because those tools are the most transparent about what they are testing.  None of the validation tools does a great job of taking me back to the source of truth used, although I can readily go from Conformance identifier back to the related specification.

I guess I'm spoiled by some of the W3C validators I've used, which link me directly to the conformance requirements in the standard.  Until we get an HTML version of CCDA, we won't be seeing that.  But hopefully that can be something that is produced sooner rather than later.

   Keith