As the discussion went on, it evolved into there existing a template identifier that indicates "This document conforms to all applicable sections and entries (and documents), found in the CDA Consolidation guide".
This feature was already present in the HITSP C83 specification, and is reproduced below. As such, it is certainly within the scope of the HL7 project to ensure that this feature is reconciled along with the IHE and HL7 guides.
Please note that the following constraints have been added to support the creation of structured documents using the templates defined in this section. The last two constraints are to ensure that a CDA document conforms to the HITSP defined sections and entities where these entries are available. If HITSP has not created an appropriate entry or section, the CDA document MAY include those.
C83-[CDA-10] CDA document instances that adhere to the specifications for the sections and entries defined within this specification MAY declare their conformance to these constraints by including <templateId> element with a value of 2.16.840.1.113883.3.88.11.83.1 in the root attribute and no extension.
C83-[CDA-11] Conforming CDA document instances SHALL conform to the HITSP defined sections* where available
C83-[CDA-12] Conforming CDA document instances SHALL conform to the HITSP defined entries** for clinical statements where available
* If the intent of the section is to capture information that could be captured in an existing HITSP section, the section shall conform to the HITSP defined section (although it may be further constrained).There are a couple of key questions around this proposal:
**If the intent of the entry (clinical statement) is to capture information that could be captured in an existing HITSP entry, the entry shall conform to the HITSP defined entry (although it may be further constrained).
What is the point of it?
The main point is that the CDA Consolidation guide, like the CCD, IHE PCC Technical Framework and HITSP C83 specifications that it harmonizes, is a library of documents, sections and entries. In IHE we've found that the IHE PCC Technical Framework is more widely used as a library of sections and entries than the individual document templates specified within it. The IHE section and entry templates are presently in use in national projects in the US, Europe, Japan and China. The same is true for CCD template (there are over 20 implementation guides using CCD templates). We can certainly expect, based on that experience that the same will also be true for the CDA Consolidation guide. The HITSP guide not only anticipated this behavior based on prior experience, but also promoted it through the above conformance rules.
What are the benefits of asserting this template identifier?
Suppose that you have developed an application that understands the CDA Consolidation guide, and gathers information from appropriate sections on problems, medications, and allergies. Now, you want to use this application, but someone has determined that they need a new document type not covered by the guide. As an example, let's look at an assessment of health and functional status for long term care use. This clearly isn't covered by the current set of documents in the CDA Consolidation guide.
But, if someone were to create a new implementation guide, and use the CDA Consolidation guide sections and entries, my application could take advantage of that fact. There is a major concern here, which is a potential impact on patient safety. Suppose my application uses the information in this document, specifically on problems, medications, and allergies, to provide some clinical decision support for the patient assessed in the document. Suppose also that the creators of that assessment instrument (a CDA implementation guide), decided that they didn't like the way that CDA Consolidation dealt with allergies, and so they used an incompatible model. What could happen? Well, if you didn't know that they used a different model for allergies, when you tried to extract the allergy information, your application would either not find it, or not find all the details recorded in the same way as they had been recorded according to the consolidation guide. As an end result, you wouldn't have the allergy information, and could produce incorrect, perhaps even dangerous results.
Now, how can you tell that they've used templates you understand. In this particular example, you'd make a list of the templates you need, and then go check to make sure that the document incorporated them. This particular example is deliberately simplified, so maybe you only need the handful of sections and entries related to problems, meds and allergies (there's at least a dozen of these). Even having checked that, you really don't have any assurance that they haven't added another section that does things differently in a way that you don't understand.
What the CDA Consolidation template identifier would do is tell you that the document has done things the CDA Consolidation guide way for everything that overlaps in anyway with what already exists. That means that it doesn't record the same information present and described somewhere in the guide in a way that it NOT compatible with the guide.
This gives the receiving system a statement of assurance that says, if CDA Consolidation guide did it this way, this document does it this way as well. That means that the receiving system has less to worry about with respect to information being recorded differently from what it already understands.
This is exactly the rationale that HITSP used when adding these conformance statements to the C83 specification in support of the Clinical Note Details use case. And in fact, someone did create a guide just like the one I just described that conformed to the HITSP template for C83. It was the CARE-SET implementation guide used in the C-HIEP demonstration project. And guess what, that project also used MDHT.
Granted, just because someone asserts the template identifier, it doesn't mean that you can simply assume that what they've done is correct. You also have to be able to test conformance to it.
How can you test this?
Some of the opposition seems to come from "we don't know how to automate the test." There are assertions in the CDA Consolidation guide that have implications, and there are some unstated assumptions that may need to be made more explicit. If the section template id is X, then the LOINC code for the section must be Y. In most cases for these documents, there should be only one section of that type, so:
- X -> Y (template id X implies LOINC code Y)
- |Y| = 1 (there shall only be one occurence of LOINC code Y)
- |Y| !-> X -> (|Y| > 1) (if Y does not imply X, then there could be more than one section with LOINC code of Y)
- Thus, Y -> X (so, in a conforming instance, if the LOINC code is Y, the template ID must be X)
So, you can detect non-conforming sections and entries where these kinds of assertions (and assumptions) are present. You can also detect non-conforming entries with similar constraints on code (or other attributes) or detect missing entries from sections. You can also identify specific entry classes that do not conform to template identifiers in the guide for inspection to see whether or not they overlap.
One of the challenges here is figuring out how to create the appropriate tests based on the data that is used to generate the guide. This may be a technical challenge, but just because there is a technical challenge shouldn't be an impediment to implementing the idea. It's certainly feasible. The MDHT project managed it (see slide 8) for C-HIEP.
How does this benefit implementation guide and standards developers?
A guide that requires the assertion of the Consolidation template identifier in instances is itself asserting that it doesn't doesn't conflict with the CDA Consolidation guide. That means that it, and any additional templates it creates would be more easily considered for inclusion into the next edition of the consolidation guide. A guide that doesn't do this requires a deeper look for gaps and overlaps. It also means that when such a guide is reviewed and approved, reviewers can point out inconsistencies not just as potential problems, but rather as implementation guide errors.
How this simplifies creation of other guides?
With one assertion, I can adopt all the rules in the CDA Consolidation guide. Essentially, I've declared:
import org.hl7.sdwg.CDAConsolidation.*; (for Java developers)
using org.hl7.sdwg.CDAConsolidation; (for C# developers)
All of the rules, all the logic, all the consistency implied in the guide is asserted in one little statement. If, as a CDA implementation guide creator, I am ready to trust in the CDA Consolidation guide, then I can turn my attention to other things that guide doesn't support. This is extremely powerful. You can adopt hundreds of pages of specification, and avoid countless hours of struggle, and there's even a way to say you did just that. If we want to make it easy to create implementation guides (e.g., using tools like MDHT) to meet other use cases, this is the kind of thing that we need to consider.
I've been through this process not once, not twice, but many times. In IHE adopting from HL7 CCD, in HL7 adopting from IHE PCC, in HITSP adopting both, and back again in HL7 with the consolidation guide. If we want "one ring to bind them", it needs to have a name, and I need to be be able to use it meaningfully. This would be extremely important for IHE adoption, because we want to ensure consistency. IHE already has document content that isn't included in the CDA Consolidation guide. How would we be able to assert consistency with it?
What does optional or recommended really mean?
A guide that asserts the Consolidation template identifier is stating that it is doing things consistently with what the guide indicates. If the guide says that severity is recorded in this way, and the instance record severity differently, and the severity assessment is optional, has the guide conformed? While the instance might conform to the allowed model, it really has failed to follow the intent of the guide. The guide says to record severity this way, and the instance didn't. This is an incompatibility that would later need to be resolved if the new guide were "brought in" to the CDA Consolidation guide.
It's a brand, not just a guide!
This is my last rationale for inclusion of this, and probably the weakest from a technical perspective, but strongest from an implementation perspective. As HL7 learned from developing the CCD, everybody wanted to be able to call everything a CCD, but not everything was. This gives HL7 something that allows everybody to use CDA Consolidation, even when it doesn't have the exact document they need, and still claim conformance to the guide.
No comments:
Post a Comment