HL7: Your HL7 CDA document is not compliant
In this short article, I will try to show why your HL7 CDA document most likely does not comply with the standard, and also suggest what to do about it.
What is Clinical Document Architecture (CDA) I also briefly described in another post - habrahabr.ru/post/255879
I’ll immediately notice that a “complete” CDA description will occupy a whole book with 300 pages, one of which is called " The CDA Book ". Therefore, there is no way in one article to talk about all the features of this standard.
Let me remind you that Clinical Document Architecture is one of 20 domains of the HL7v3 standard. If you are familiar with v3, and I hope most readers have at least a little idea what it is, then you know that in this version all artifacts are based onHL7 Reference Information Model (RIM).
To make the further explanation clearer, let's see how models are built in HL7v3. You should start with RIM, which is as follows:
As you can see, RIM is based on 4 base classes: Entity , Role , Participation, and Act , and two additional classes for describing relationships: Role Link and Act Relationship. The concept of “class” for those who have at least once encountered software development, probably suggests an object-oriented structure of RIM and, I must say, this is almost true. Why almost, because RIM follows the basic principles of inheritance in OOP. The standard explicitly states:
But then the discrepancies begin. To obtain the required messages, the HL7v3 uses the refinement process, which leads to the creation of several Domain Message Information Model (D-MIM) for domains and a set of Refined Message Information Model (R-MIM) in each of them. Following the same rules from R-MIM, the final Hierarchical Message Descriptions (HMD) are obtained from which, in turn, the messages are built.
The process of refinement ( refinement ) is based on the constraint process (restrictions) and localization process(localization). As the name implies, the restriction process does not imply further expansion or redefinition of classes, on the contrary, the descendant class can include all or some of the properties of its parent class, but no more. The localization process assumes that some models do not fully meet business requirements and need to be supplemented. Such additions, most often implemented in the form of extensions (extensions) in the future, may become part of the model. Although it is much more common to hear that if you need extensions, then you are probably misinterpreting your business processes.
And so, having a little understanding in the process of implementing the HL7v3 models, let's go back to CDA, namely to CDA R-MIM, to the part that describes the body of the document.
All classes to choose fromclinicalStatement inherits from the Act class . For example, for the given Observation class , the main description is not to be found in the section Universal Domains -> Clinical Document Architecture (although it also makes sense there, but to learn about some additional features of using this class), but in Foundation -> Reference Information Model -> Classes -> Observation .
Similarly for entryRelationship . If you use only the description in the Clinical Document Architecture domain itself , you can understand that "CDA has identified and modeled various link and reference scenarios ”, as well as the usage features of entryRelationship.inversionInd and entryRelationship.contextConductionInd .
However, as you can see, entryRelationship inherits other attributes from its parent class, ActRelationship . Including ActRelationship.seperatableInd , which by default is “true” and is used for “ an indication that the source Act is intended to be interpreted independently of the target Act. Indicates the author's desire and willingness to attest to the content of the source Act if separated from the target Act. "(Source HL7 NE)
Thus, if your CDA section template most likely uses entryRelationship to describe clinical conditions, for example: type of allergic reaction - allergic agents - allergen - degree of manifestation, then since ActRelationship.seperatableInd = true by default, then by law of inheritance, all your descriptions are independent of each other. That is, the allergen exists in the document by itself, it is not connected with anyone and does not define anyone. As well as the "degree of manifestation" it is unclear what exists on its own in unclear what conditions.
If the goal is “ the target (for the inner class of Observation) cannot stand by itself without knowledge of the source act (for the outer class of Act), then this class attribute should be set to“ false ”". (source "The CDA Book", with my additions in parentheses)
That is so that all attachments carry the meaning that was originally laid in them, in each case there must be entryRelationship.seperatableInd = false in an explicit form.
However, you will hardly find at least one example of using this attribute in a real CDA document or CDA document template.
What to do?
The eternal question. Most likely nothing. Wait until HL7 corrects the model, or a description in one of the next versions of the HL7v3 Normative Edition, where this attribute will be false by default.
Or you can make such corrections in the XML schema POCD_MT000040.EntryRelationship.
Or add one line to your specification indicating that by default this attribute is always false.
Update: I'm glad someone is minus. But from the fact that you are minus, this, as well as many other problems associated with CDA conformance tests, does not disappear.
Update2: Someone noticed that C-CDA R2.1 in some cases requires (SHALL) to use the CD.qualifier element, which is represented in the XML schema as:
What is Clinical Document Architecture (CDA) I also briefly described in another post - habrahabr.ru/post/255879
I’ll immediately notice that a “complete” CDA description will occupy a whole book with 300 pages, one of which is called " The CDA Book ". Therefore, there is no way in one article to talk about all the features of this standard.
Let me remind you that Clinical Document Architecture is one of 20 domains of the HL7v3 standard. If you are familiar with v3, and I hope most readers have at least a little idea what it is, then you know that in this version all artifacts are based onHL7 Reference Information Model (RIM).
To make the further explanation clearer, let's see how models are built in HL7v3. You should start with RIM, which is as follows:
As you can see, RIM is based on 4 base classes: Entity , Role , Participation, and Act , and two additional classes for describing relationships: Role Link and Act Relationship. The concept of “class” for those who have at least once encountered software development, probably suggests an object-oriented structure of RIM and, I must say, this is almost true. Why almost, because RIM follows the basic principles of inheritance in OOP. The standard explicitly states:
- Generalization - when the descendant class includes all the properties of the parent class.
- Specialization — The successor class overrides some of the parent's functions, and also defines additional properties for even more specialization.
But then the discrepancies begin. To obtain the required messages, the HL7v3 uses the refinement process, which leads to the creation of several Domain Message Information Model (D-MIM) for domains and a set of Refined Message Information Model (R-MIM) in each of them. Following the same rules from R-MIM, the final Hierarchical Message Descriptions (HMD) are obtained from which, in turn, the messages are built.
The process of refinement ( refinement ) is based on the constraint process (restrictions) and localization process(localization). As the name implies, the restriction process does not imply further expansion or redefinition of classes, on the contrary, the descendant class can include all or some of the properties of its parent class, but no more. The localization process assumes that some models do not fully meet business requirements and need to be supplemented. Such additions, most often implemented in the form of extensions (extensions) in the future, may become part of the model. Although it is much more common to hear that if you need extensions, then you are probably misinterpreting your business processes.
And so, having a little understanding in the process of implementing the HL7v3 models, let's go back to CDA, namely to CDA R-MIM, to the part that describes the body of the document.
All classes to choose fromclinicalStatement inherits from the Act class . For example, for the given Observation class , the main description is not to be found in the section Universal Domains -> Clinical Document Architecture (although it also makes sense there, but to learn about some additional features of using this class), but in Foundation -> Reference Information Model -> Classes -> Observation .
Similarly for entryRelationship . If you use only the description in the Clinical Document Architecture domain itself , you can understand that "CDA has identified and modeled various link and reference scenarios ”, as well as the usage features of entryRelationship.inversionInd and entryRelationship.contextConductionInd .
However, as you can see, entryRelationship inherits other attributes from its parent class, ActRelationship . Including ActRelationship.seperatableInd , which by default is “true” and is used for “ an indication that the source Act is intended to be interpreted independently of the target Act. Indicates the author's desire and willingness to attest to the content of the source Act if separated from the target Act. "(Source HL7 NE)
Thus, if your CDA section template most likely uses entryRelationship to describe clinical conditions, for example: type of allergic reaction - allergic agents - allergen - degree of manifestation, then since ActRelationship.seperatableInd = true by default, then by law of inheritance, all your descriptions are independent of each other. That is, the allergen exists in the document by itself, it is not connected with anyone and does not define anyone. As well as the "degree of manifestation" it is unclear what exists on its own in unclear what conditions.
If the goal is “ the target (for the inner class of Observation) cannot stand by itself without knowledge of the source act (for the outer class of Act), then this class attribute should be set to“ false ”". (source "The CDA Book", with my additions in parentheses)
That is so that all attachments carry the meaning that was originally laid in them, in each case there must be entryRelationship.seperatableInd = false in an explicit form.
However, you will hardly find at least one example of using this attribute in a real CDA document or CDA document template.
What to do?
The eternal question. Most likely nothing. Wait until HL7 corrects the model, or a description in one of the next versions of the HL7v3 Normative Edition, where this attribute will be false by default.
Or you can make such corrections in the XML schema POCD_MT000040.EntryRelationship.
Or add one line to your specification indicating that by default this attribute is always false.
Update: I'm glad someone is minus. But from the fact that you are minus, this, as well as many other problems associated with CDA conformance tests, does not disappear.
Update2: Someone noticed that C-CDA R2.1 in some cases requires (SHALL) to use the CD.qualifier element, which is represented in the XML schema as: