Clinical Document Architecture ﴾CDA﴿

The Clinical Document Architecture ﴾CDA﴿ is one of the HL7 standards designed to standardize the structure and ensure the semantic compatibility of medical systems in the exchange of medical information and / or medical documents. The first version of the standard was approved by ANSI back in 2001. The second version, which is used to this day, was approved by ANSI in 2005. The third version, CDA R3, is under development and approval.

CDA R2 (Release 2) guarantees the presence of the following seven characteristics in the CDA document:
• The safety of the information provided;
• Management of the information provided;
• Support authentication requirements for all submitted information;
• Maintaining the context of the information provided;
• Support information integrity;
• The ability to read the information submitted by a person;
• Support for binary information, such as multimedia components, PDF, images and more.

These characteristics make CDA extremely flexible for use in various areas. And even despite the fact that among the developers of medical systems, CDA systems are considered to be an extremely difficult standard, it has become one of the most successful HL7 developed for integrating medical data and is consistent with the requirements of Meaningful Use 1 and 2 adopted in the United States. Most medical systems currently encode information in one of nine possible CDA document templates, for example, the Continuity of Care Document (CCD) is one of these templates.
')
This article provides an overview or simplified description of the main components of the CDA. And so, like any document, the CDA contains the document header (CDA Header) and the document body (CDA Body).

CDA Header

As shown in the following picture, some administrative information based on the RL HL7 classes and entities is included in the CDA header.



The main class in the CDA header is called the Clinical Document, and, according to its name, contains, among other things, information for identifying the document, the title, the language used, the version, the date of publication and the level of confidentiality. Next, consider the purpose of some of the above classes. To avoid confusion, class names will be given in their English transcription.

Authenticator

This class is included in the document to identify a person and / or organization that can be used to authenticate the entire contents of a CDA document.

Recipient

Everything is simple, the recipient document header is used to identify the recipient (person and / or organization) of the document and may include such data as name, address and other information. Recipients may be many.

Author

This class encodes information to identify and verify a person or device, as well as the organization of their representatives who are responsible for the data in the CDA document.

Custodian

The data class is used to identify and verify the organization responsible for the security of the document. Such an organization is responsible for the safety of all data in the document (for the entire document).

Source

This class encodes information about the person and / or organization who placed the data into the medical system, on the basis of which the document was created. A similar face might be, for example, a Data Entry clerk.

Parent CDA

Since a CDA document may be part of another CDA document, such information must be presented somewhere. In this class, information about the relationship between two or more documents is encoded.

Patient

Using this class in the header of the CDA document provides information about the main participant of all events - the patient. Name, address, guardians, and any other information to fully identify the patient. It is worth noting that some types of data are prohibited in some countries. For example, information about racial and religious affiliation is required in the United States, but is not acceptable in Europe.

CDA Body

The body of a document or a CDA Body can be either unstructured for data that is not encoded in XML, or structured for data represented in XML format. The concept of levels of semantic compatibility of CDA is closely related to the features of such coding (this article is not considered).

The description below will also use the English names of the components or classes.

Non-structured Body

An unstructured document body can contain only one attachment with a link to data outside of this CDA document, or a Base64 encoded binary attachment (PDF, image, audio, video, etc.).

Structured Body

The structured body of the document is designed as an extremely flexible mechanism for the inclusion of a variety of clinical and administrative data. This is what makes CDA so powerful in conceptual terms that it can theoretically be used to encode the entire patient's history, no matter how complex it is. The reverse side of such flexibility in the implementation of all the existing features of the standard. One of the reasons for this is the incorrectness or incompleteness of the understanding of the standard itself by various organizations.

To eliminate this disagreement, CDA document templates were invented. Creating templates and various developer manuals is aimed at simplifying the implementation and limiting discrepancies of the standard for the same clinical areas. Such templates include Clinical Notes, CCD, Discharge Summary, etc.). All of them are presented on the official website of HL7. In addition, there are about 70 section templates and even more record templates.



As shown in the figure above, the structured body of the document may contain one or more sections, each of which may contain honey or administrative information, as well as attachments. At the same time, the CDA standard itself does not say how to establish relationships between similar data, for this you need to refer to the numerous developer guides available on the official HL7 website or developed by each organization individually.