My most recent work has put me in a position to learn a great deal more about the health care IT industry. It has been quite an interesting learning curve over the past few months. Looking back, I’ve worked on hospital scheduling systems for an extensive period of time, then coincidentally lead the development of a claims administration system and now I’m learning about another corner of the industry (clinical documentation).
CDA is short for Clinical Document Architecture, which is a standard based on a standard called the HL7 RIM – reference information model. CDA, essentially, defines the XML-based structure in which a doctor can report information on procedures, allergies, diagnosis (etc.) for a patient.
The full CDA specification can be found here.
Basics
For me, the hardest thing to grasp about the concept as a whole was that CDA doesn’t define a messaging structure, it does define a document structure. A key factor to this is that a CDA document has persistence; it isn’t intended to be created on the fly and thrown away after reading once, it is meant to stay around and provide a historic reference for the patient.s health care.
I think of it this way: A CDA structured document can be compared to a standard form you create for your customers to fill out in order to gather feedback on your support quality (i.e. a box in the top left for their name, bellow it a box for their birth-date that tells them they must specify MM/DD/YYYY, etc.).
A CDA document is very similar, but instead of specifying boxes on a document, the XML structure is being constrained to indicate that the <name> element must be used to specify a name, which minimally requires first and last name child elements. An XML schema is used to specify what the structure of a CDA document can be.
Basic Structure
A CDA document can be broken up (in my mind) into two logic sections; The header and the body. The header represents all of the high-level information about the document, such as the document type, patient information (name, id, address, telephone, etc.), document author details (who created the CDA document), custodian information (who manages the document), etc.
Note: One thing to remember here is that a CDA document always represents a patient. And, almost always, a document will represent only one patient. The only times that I am aware of that a CDA document will represent more than one patient is in the case of group therapy and with conjoined twins.
The body of a CDA document contains the real information on what the document represents. For example, the header of the body may indicate .Discharge Summary.. The body of the discharge summary will indicate the discharge disposition (who, how, where), the admitting diagnosis, the hospital course, any medications that the patient is discharged with, etc.
The goal of CDA document is to enhance the interoperability of systems that manage health-care information where a machine would be able to read a document and fully understand the contents of the document (IE: have coded values for all of the diagnosis and procedures represented within the document). Unfortunately, having a doctor perform a procedure and have a system that can represent the procedure in a fully coded CDA document isn’t always feasible. In many cases still, a doctor will simply create their own narrative text that describes the procedure in plain human terms and wrap it up with a CDA header. Because of this fact, there are several levels (three to be specific) of interoperability within CDA:
1) Level One: The unconstrained CDA. This is the lowest level of coding where only the header information is coded/structured in a way that the computer can understand it. The body of the CDA document does not have any coding and is simply a number of sections that have narrative text in it that is generated by hand by the doctor or physician.
2) Level Two: Section-level templates are applied. This is where the system has generated some of the coding for the CDA document (at the section level of the CDA document). This at least provides a bit more understanding on the machine.s behalf on what the document.s contents are.
3) Level Three: Entry-level templates are applied. This is the highest level of coding/interoperability. This is the ideal level, where everything represented in the document is broken down into coded elements and anything that shows up in the narrative text can be represented at the coded level within an entry. This allows the machine to fully read and understand what diagnosis/procedures the document represents.
CDA is represented by an RMIM (Reference Message Information Model) diagram which can be found here.
Implementations
The definition of the CDA standard is a big step towards interoperability between systems. However, there are still many interpretations for how CDA should be used. The most classic example that stands out for me is when representing a procedure. Some like to represent a procedure by just specifying a <code>, while others like to represent a procedure with a <code> and a <value> element (where the code is .ASSERTION. and the value is the actual procedure performed).
Implementation guides are a way to instruct developers specifically how to use CDA for a given use-case. Two implementation guides I am pretty familiar with are Unstructured Documents and Discharge Summary. The Unstructured Document implementation guide provides specific instructions on how to use CDA when representing (for example) a scanned image or a pdf file. The discharge summary provides instructions on how to use CDA to represent the information that is necessary when a patient is discharged (such as medications, past medical history, etc.).
In a brief summary, an implementation guide is a means to further constrain the CDA specification. For example, a birthdate within the header may not be required by the base CDA standard, but use-case represented by the implementation guide may always require a birthdate, therefore the implementation guide indicates that when representing XXX, the birthdate is always required.
Compliance vs. Conformance
While attending the HL7 conferences this January, one of the trainers gave specific note of the difference between compliance and conformance which I found very useful. I think it is important to realize that just because your system is compliant to a standard, doesn’t necessarily mean it is conformant.
The way I think about it is within the context of an employee within a company that defines the required and optional tasks for a role (such as project manager). An employee may perform their bare-minimum duties so that they are compliant with the duties of their role. Or, an employee that is conformant may perform at 100% where not only the bare-minimum duties are performed, but all optional duties are performed as well.
Validation
An XML schema may define what goes where (what is required, what is optional, the order in which elements can be specified, etc.), but it doesn’t provide a great deal of flexibility in validating the data that is entered. Sure, some basic validation can be handled, like ensuring that a birth date is entered in the correct format. However, a schema can.t handle more complex scenarios, like .if XXX is defined, then YYY must be defined. CDA uses a system called Schematron to handle these more advanced scenarios.
Schematron provides a way to specify a set of XSLT tests. Each test has a context and a set of assertions that can be applied to the context (where the context may be the <birthTime> element and the assertions test data around the context to determine if the test is successful or not).
For example, the following chunk represents some schematron xml that has a single error test (there can also be warning tests), which tests that @someAttribute is equal to .someValidValue. within the context of the <someElement> element, when someElement’s @id attribute is equal to “someTestId”. If the assertion test does not return true, then the error message specified by the inner text of the <sch:assert> element is returned as an error.
<sch:phase id="errors">
<sch:active pattern="error-test-1"/>
</sch:active>
</sch:phase>
<sch:pattern id="error-test-1">
<sch:rule context="someElement[@id='someTestId']">
<sch:assert test="@someAttribute='someValidValue'">@someAttribute MUST be equal to 'someValidValue'</sch:assert>
</sch:rule>
</sch:pattern>