The challenge that I have presently is that IHE wants to adapt or adopt a number of CCD-A templates to replace the CCD 1.0 templates we are currently using. Our implementers are much more concerned about how an assertion of conformance to a template must be represented in an instance than they are about how the template metadata represents a template identifier and its versions.
Right now, if you want to declare conformance at the document level to the Discharge Summary in the IHE XDS-MS profile, you would write this:
<templateId id="1.3.6.1.4.1.19376.1.5.3.1.1.4"/>
We'll need to update that profile to adopt as much as possible (removing US Realm constraints) to the CCD-A discharge summary. But we cannot use the CCD-A discharge summary directly because there will be some adaptations made. My current plan is to declare conformance to the new version thus:
<templateId id="1.3.6.1.4.1.19376.1.5.3.1.1.4" extension="20130615"/>
That means that the instance is declaring conformance to the version of the template published on June 15th of 2013.
This template would be compatible with the C-CDA discharge summary, in that its constraints do not violate the rules of the C-CDA Discharge summary (with entries required), so in the US, you would declare your instance conformant to both the IHE PCC and the C-CDA templates:
<templateId id="1.3.6.1.4.1.19376.1.5.3.1.1.4" extension="20130615"/>
<templateId id="2.16.840.1.113883.11.20.4.1" />
This is a mix of new and old style template assertions. I think that the updated templates specification should indicate a mechanism by which a versioned template ID is represented in an instance. That representation should provide a backwards compatible mechanism to represent unversioned templates for specifications that were in place before we got to the versioning mechanism.
IHE PCC will be permitted to add constraints to its template document that may not have been stated as strongly in the C-CDA. We could state that the LOINC code is fixed to 18842-5 for the document (and probably will), rather than having a list of possible values (as is present in C-CDA).
In the new world, most vocabulary constraints will be written in terms of vocabulary domains, and those domains will be bound to a value set through the realm assertion. Each document will contain a <realmCode> element that declares the realm bindings that apply (and there will usually be only one).
When <realmCode code="US"/> is present, the IHE USA national extensions to the profile will identify the set of vocabulary bindings and data type flavors that must for used with the document in the US. It will be the responsibility of IHE USA to declare what those are (and they will use the C-CDA and MU regulations to select appropriate values). When <realmCode code="FR"/> is present, it will be up to IHE France, and so on.
We would also (through IHE USA), likely declare that if you declare conformance to this template, and also specify the US realm, that you must also declare conformance to the appropriate C-CDA template (to ensure conformance to US requirements for the document).
This will allow various countries to start with the IHE specifications, and modify them (including changing them according to localization rules which are quite similar in IHE and HL7) as needed to meet their requirements.
It may be appropriate to ballot these specifications in both IHE and HL7, and in fact, this is a suggestion I've been considering. The challenge here is that IHE and HL7 are piloting the idea of balloting IHE specifications in HL7, and this is a very big profile to run through this process for the first time. We may want to focus the ballot on ONE document type (e.g., discharge summary) for that pilot, and follow up with the whole set over time as we understand the impacts of balloting IHE material in HL7.
Our first ballot could be either for comment only and/or DSTU, and should occur at the same time IHE goes through its public comment process (that would be out of cycle for HL7).
0 comments:
Post a Comment