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).

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.

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:

Type	Issues	Comments
Major	21	Most 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.
Minor	3	These 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.
Future	9	Minor 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.
Total	33	Overall, 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.

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

Feature	Original	New
IG	Consolidation	Consolidation V3
title	US Realm Header	US Realm Header (V3)
identifier	2.16.840.1.113883.10.20.22.1.1	2.16.840.1.113883.10.20.22.1.1
version		2015-08-01:
publishStatus	Published	Draft
templateType	document	document
isOpen	true	true
contextType	ClinicalDocument	ClinicalDocument
PreviousVersion		US Realm Header (V2) (urn:hl7ii:2.16.840.1.113883.10.20.22.1.1:2014-06-09)
Description	This 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/realmCode	SHALL contain exactly one [1..1] realmCode="US" (CONF:16791).	SHALL contain exactly one [1..1] realmCode="US" (CONF:16791).
ClinicalDocument/typeId	SHALL contain exactly one [1..1] typeId (CONF:5361).	SHALL contain exactly one [1..1] typeId (CONF:5361).
ClinicalDocument/typeId/​@root	This 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/​@extension	This 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/templateId	SHALL contain exactly one [1..1] templateId (CONF:5252) such that it	SHALL contain exactly one [1..1] templateId (CONF:5252) such that it
ClinicalDocument/templateId/​@root	SHALL 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/​@extension		SHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:32503).
ClinicalDocument/id	SHALL contain exactly one [1..1] id (CONF:5363).	SHALL contain exactly one [1..1] id (CONF:5363).
ClinicalDocument/code	SHALL contain exactly one [1..1] code (CONF:5253).	SHALL contain exactly one [1..1] code (CONF:5253).
ClinicalDocument/title	SHALL contain exactly one [1..1] title (CONF:5254).	SHALL contain exactly one [1..1] title (CONF:5254).
ClinicalDocument/effectiveTime	SHALL 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/confidentialityCode	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 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).

CCDA 2.1 DSTU Update Available for Comment

I was quite please to see this cross my desk this afternoon.  It is the announcement of the request for comments on the C-CDA 2.1 DSTU Update.  As you may recall, this project was initiated at the May working group meeting.  We are now at the first of July, some six weeks after we initiated this project, and have knocked down our third duck (there are about three more to go).  We've done our best to make sure that there is plenty of time to get this into the Meaningful Use Stage 3 regulation, and now it is time for HL7 members to do their part.  Please have a look at the new material and provide your comments before July 13th.

   Keith

---

Hello,

The Consolidated CDA R2.1 DSTU update is available for member review.

 C-CDA R2.1 20150701_Review_Posting

SDWG will follow the review process outlined here: http://wiki.hl7.org/index.php?title=C-CDA_R2.1_Comment_Submission

Comment submission deadline: 7/13/2105 11:59 PM ET

Updates open for comment are identified by yellow highlighting.

·         Volume 1 - If the heading is highlighted, the entire section is open for comment.

·         Volume 2 - The specific conformance statements updated are highlighted. Templates that are only updated to reference a contained template that have been versioned (extension="2015-08-01") are not open for comment. Figures with updated conformance statements are open for review.

There are 3 methods to find edits:

1.     Wordadvanced find - highlight search

2.     High-level change-log in Volume 1 (page 43)

3.     Excel comparison files (CDA R1.1 vs 2.0 Reviews) included in the review zip

All 3 methods should bring a reviewer to the same changes. Comment submission deadline: 7/13/2105 11:59 PM ET

Note, several R1.1/R2.0 errata are fixed in this release  -- all marked with 8/1/2015 (C-CDA R2.0/2.1) on our DSTU comments page (R1.1 / R2.0). SDWG is developing an R1.1/R2.0 errata summary which will be available prior to final publication of R2.1.

Best,

Brett

Brett Marquard

Principal

River Rock Associates

Allergies, Severity and Criticality in HL7 CCDA

A rather long document wound up in my e-mail this morning, sent to Structured Documents cochairs, HL7 Leadership and several other individuals (myself included).  The e-mail addresses concerns from the HL7 Patient Care Workgroup about a patient safety issue with the current C-CDA templates for Allergies, specifically in how these templates address Criticallity of an allergy, vs. Severity of a reaction.  C-CDA does NOT in fact relate criticallity with an allergy, only severity.  BTW, that concept of allergy severity goes back to 2005 and before, and was adopted in CCD, and forward into subsequent releases.

The Patient Care Workgroup has been working on these topics for a number of years, and believes that they should be addressed in the HL7 C-CDA DSTU 2.1 Update Project.  I could readily be convinced that is the case.

The concern of the Patient Care Workgroup is that the existing templates do not appropriately address how allergies should presented to a clinician, and as a result, produce a patient safety concern that should be addressed as soon as possible.

I'm pleased to see HL7 having to take on this kind of challenge, and look forward to see how this changes our processes going forward.  In this case, we have a "conflict" between two governance groups over something that could affect patient care.  Arguably, there should be a process to address this sort of issue.  Today, medical device manufacturers also have processes to address patient safety issues in the technology they produce, I think HL7 will need to adopt similar processes.

We saw a somewhat similar issue (addressing security rather than safety) crop up last year with CDA stylesheets.

Should HL7 support Backwards Compatible only, or Backwards compatibility as an option in the CCDA 2.1 DSTU Update?

One of the outstanding questions that the C-CDA project has to address is whether the 2.1 DSTU will require backwards compatibility only, or whether there will be a mode supporting backwards compatibility, and a mode where C-CDA 2.0 constraints are simply adopted.  We haven't made a decision yet.

Some would argue that supporting backwards compatibility only will simplify the guide for people. I have argued that will require HL7 to create a new project further down the line, and will not enable C-CDA 2.1 to be used in projects which are presently dependent upon C-CDA 2.0, some of which, like QRDA, also have a regulatory component naming a version of the standard.

To move forward, I will be proposing the following wording be adopted in constraints that are added to support backwards compatibility:

To support backwards compatibility, XXX SHALL/SHOULD/MAY YYY

This highlights the constraints added to support backwards compatibility.  Then we add language to the top of the specification depending upon which choice we make:

1. If we choose backwards compatibility only, we state:
   This specification adds constraints supporting backwards compatibility.  These constraints are identified by beginning with the phrase "To support backwards compatibility", and are otherwise equivalent to any other constraint.
2. If we choose to support both, we state:
   This specification adds constraints supporting backwards compatibility.  These constraints are identified by beginning with the phrase "To support backwards compatibility."  These are conditional constraints. When a document instance declares that it is supporting backwards compatibility by [mechanism to be established], these constraints must also be followed.  

This will allow the project team to create the constraints now, and make the choice later about whether these constraints are conditional or not.

HL7 is looking for feedback on this.  If you are a member of the Structured Documents mailing list, you can provide your feedback there, or on next weeks Thursday call, or on tomorrows C-CDA 2.1 DSTU Update project call.  As always, any feedback you provide in comments here, I will also forward to the workgroup, supporting them as best as I am able even though I have my own preferences.

Personally, I could still be convinced for option 1 by an argument that resonates with my own concerns, but am still strongly leaning towards option 2.

Tell ONC to use CCDA 2.1 for Stage3 / 2015 Certification for MeaningfulUse !

Comments close shortly on the ONC Certification Proposed Rule.  If you've already submitted yours, I'd still like you to tell ONC three more things:

1. HL7 is currently in the process of approving a project to update C-CDA 2.0 to 2.1 ensuring backwards compatibility with Version 1.1 named in previous Certification and Standards Rules.  This will avoid the unnecessary and potential dangerous situation of having to record two documents with dissimilar information about the same patient and encounter to support asynchronous bilateral cutover.  The project team hopes to complete this effort by July or August at the latest.
2. The changes would enable a C-CDA compliant 1.1 system to read and understand as much of a C-CDA 2.1 instance as is technically feasible.
3. We think this is a good idea, and would prefer it over other ONC suggested solutions (i.e., using 2.0 and sending two versions to support compatibility).

Click here to comment on the rule.  If you want to copy and paste my words above into your comment, feel free to do so!

     Keith

P.S. SDWG approved the PSS today!  On to the next stages.

Dual CCDA Reprise and an Action Item for You!

One of the issues that has been taking up my time over the last five weeks is an evaluation of the backwards compatibility issues between C-CDA 2.0 and C-CDA 1.1 with the Structured Document workgroup at HL7.

There are basically three different kinds of problems and one non-problem that we thought we might find:

1. Things that just don't work without a fix to one specification or the other.
2. Things that do work, but which are ugly if we are to use them, and so we'd like to make some changes to resolve them.
3. Things that could work but might need some clarification or explanation as to how to resolve in the Asynchronous Bilateral Cutover case where a dual-capable C-CDA was being used.
4. Things that simply work (which isn't really a problem).

There are also three different levels of compatibility that we likely needed to address:

1. Cases where the incorporate provisions of the rule would be impacted.  These are cases where the C-CDA entries are required to be transferred in some way to the EHR, such as with problems, medications, and medication allergies.
2. Cases where the viewing requirements might be impacted (different section requirements), or where clinical content varied between versions of a document.  For example, the Care Plan Section in C-CDA 1.1 includes Goals content, but in 2.0, there is a separate goals section.
3. Cases where other ("secondary") uses of the content, such as with quality measures, would potentially be impacted. These are not specifically requirements of the Certification rule, but are capabilities that some have used to facilitate other requirements.

The essential feedback from the evaluation is that it is technically feasible to create a C-CDA document that supports both specifications and which might be understood by both systems. However, such a solution seems to be more technically challenging that any would like.  HL7 members think we can do better.

The solution appears to be to quickly issue a DSTU Update of C-CDA to address these issues. Because of the timing of the regulation, we think this might be workable, but there are still a bunch of ducks we need to get in a row and then shot down.

SDWG will be seeking advice from its steering division and the TSC this evening, and will likely be taking action on it based on the outcomes.  I will report more on this later in the week (perhaps as early as tomorrow). Those I have discussed this with seem to think that it is feasible.

We have maybe six weeks to accomplish this task.  Due to the work of the Dual C-CDA task force we have an idea of what changes would need to be quickly implemented.  Here is how I think the timing works:

The ONC comment period closes in a month.  They will take at least two months to review the comments and produce a new rule, perhaps three.  One month before they submit the final rule, they have to have the published content available.  That gives us six weeks (not counting this one) to get 'er done.

Your action item is to reference an updated C-CDA in your comments on the Standards and Certification rule.  The only way to ensure that ONC references a new edition is for a) HL7 to make one available quickly, and B) for you to make comments referencing the C-CDA DSTU Update.

To submit a comment, click the link above, and hit the SUBMIT A FORMAL COMMENT button on the right hand size underneath the the title.

Supercompliance with HL7 CCDA Versions

I've written several times about C-CDA Release 2.0 and issues with template versioning which are pretty close to resolution, and I've also written previously about the 2015 Certification criteria and backwards compatibility with 2014 criteria.

What I'd like to expand upon now is an issue that could occur if C-CDA Release 2.0 was adopted as optional criteria for 2015 and how we could arrange things so that a 2014 system could receive it.  It draws in part on what I described previously as a Dual Compatible CCD, but is slightly different because CCDA 2.0 is largely backwards compatible with CCDA 1.1.

The issue is that when System N (for new) sends a CCDA 2.0 document to System O (for old) that understands CCDA 1.1 there are three things that could happen:

1. System O would correctly identify the fact that the CCDA 2.0 document did NOT comply with CCDA 1.1 and would reject it.
2. System O would NOT correctly identify this fact because the template identifiers are similar enough, and some don't understand the details of how to match identifier values in HL7 Version 3 and CDA, and so it would incorrectly try to process it.  System O would handle these as follows: 
1. Where these templates are backwards compatible:, System O would handle the 2.0 templates correctly where they are backwards compatible with 1.1, BUT, 
2. Where they are not, System O would have issues with interpretation of the content.

There are FEW cases where 2.b. would occur based on a preliminary analysis of CCDA 2.0, BUT, we need to spend more time looking into those details.  One case that has been identified is the templates for Smoking Status, where there are differences in interpretation of the effectiveTime element on the observation.

What I would propose that systems using CCDA 2.0 do is be "Super Compliant" (this is really independent of what my thoughts are on the 2015 certification rule).  Super Compliant means that they send documents which conform to both CCDA 2.0 rules, and CCDA 1.1 rules, and only send the same information twice when ABSOLUTELY NECESSARY (as in the case for Smoking Status), and only in very controlled ways.

It would mean that a sector or entry could declare conformance to both CCDA 1.1 and 2.0 except where that wasn't feasible (e.g., Smoking Status).  That last little note also means that we need to examine more carefully where backwards compatibility isn't the case. 

The benefit of this is that systems which understand CCDA 1.1 will, if properly interpreting the guide and underlying CDA Release 2.0 standards, work correctly.  Even if they don't fully interpret the CDA Release 2.0 standard properly (e.g., get confused about the Instance Identifier data type and similar but not identical identifiers), could and likely would still get the correct result.

This allows systems supporting CCDA 2.0 to work with systems only understanding 1.1.  It does mean that newer systems supporting CCDA 2.0 would still have to support CCDA 1.1 as input, because not every system available would be able to send CCDA 2.0, but that is already pretty likely to be the case for MOST Certified EHR products in use today.

I'll talk a little bit more tomorrow about flavors of compatibility and breaking changes (also called substantive changes) and how we could develop some policies for advancing standards that allows new features to be created, and problems to be fixed but still ensure that systems

CCDA Versions and MeaningfulUse 2015 Certification

One of the HUGE challenges introduced in the Meaningful Use 2015 certification criteria is the replacement of CCDA 1.1 with CCDA 2.0.

Here's the issue in a nutshell:
CCDAs produced by MU2014 certified product won't be able to Interoperate with CCDA'a produced by MU2015 certified product.  CCDA 2.0 tightens up the rules that have to be followed in CCDA 1.1, so it should just be a slam dunk.  However, it also changes the template identifiers, so it's the C32 to CCDA transition all over again for implementers.  In fact, they changed just about every template identifier.

It requires an extensive and deep gap analysis to do this kind up transition to a new version.  Essentially, the new templates are backwards compatible with the old (with a few minor exceptions), BUT, the template identifiers have also changed, and without a good map, getting from one to the other is difficult.  And 2015 CEHRT's should be able to work with 2014 CEHRT's as well, which means they have to support both.

So not only do we handle them a difficult transition, but we also make them accept what used to be valid as well, because it only makes sense, and we don't give them an easy way to transition upwards.  Easy transitions upwards in versions is another important principle in advancing standards.

This is NOT yet an insurmountable problem, but it will be if HL7 acts hastily in closing out the CCDA 2.0 ballot, or if HL7 members don't act to address the issue.  I was happy to let this go back in October when the vote was cast and the position I supported lost by two votes.  But that was when CCDA 2.0 was for MU Stage 3, and not when it was for 2015, just a year after we went from C32 to CCDA, and not when the new rule is optional.

It's not OK that a 2015 CEHRT won't be able to transmit a CCDA to a 2014 CEHRT because they use different versions of CCDA.  It's not OK because my doctor and my hospital use two different EHR's (which is fairly common when you consider that the Ambulatory and Hospital EHR markets are in different segments), and those EHRs are more likely to NOT be able to communicate if one or the other moves up to the new criteria.

We need to solve this problem.  Fortunately, CCDA is still in the operating room (finishing up the ballot), and there is still some chance that templates will finish first and a new versioning mechanisms will be in place for templates, at which time I have a good chance of being able to reopen this question, because the situation will have changed.  And there's time between now and the end of August when the 2015 FR is expected to be published for HL7 to solve the problem.

That isn't a complete solution for the 2015 certification rule though.  Realistically, more is needed to ensure a backwards compatibility path.  Transformation from a CCDA 2.0 to a CCDA 1.1 should be both feasible and automatic (not so in the other direction).  That provides a pathway to support both formats and provides a transition mechanism.  I have to do more thinking about this problem too.

    Keith

P.S.  I know this is my second post in as many hours, but I'm getting behind on posts, so just catch up!