Multimedia Standards For Document Architecture

0 views

Skip to first unread message

Piedad Coughlin

unread,

Aug 3, 2024, 5:50:37 PM8/3/24

to exndisisin

The site is secure.
The ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Many people know of Health Level 7 (HL7) as an organization that creates health care messaging standards. Health Level 7 is also developing standards for the representation of clinical documents (such as discharge summaries and progress notes). These document standards make up the HL7 Clinical Document Architecture (CDA). The HL7 CDA Framework, release 1.0, became an ANSI-approved HL7 standard in November 2000. This article presents the approach and objectives of the CDA, along with a technical overview of the standard. The CDA is a document markup standard that specifies the structure and semantics of clinical documents. A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content. The document can be sent inside an HL7 message and can exist independently, outside a transferring message. The first release of the standard has attempted to fill an important gap by addressing common and largely narrative clinical notes. It deliberately leaves out certain advanced and complex semantics, both to foster broad implementation and to give time for these complex semantics to be fleshed out within HL7. Being a part of the emerging HL7 version 3 family of standards, the CDA derives its semantic content from the shared HL7 Reference Information Model and is implemented in Extensible Markup Language. The HL7 mission is to develop standards that enable semantic interoperability across all platforms. The HL7 version 3 family of standards, including the CDA, are moving us closer to the realization of this vision.

The document discusses multimedia documents and hypermedia. It describes how multimedia documents contain both continuous and discrete media and require models for content, structure, manipulation, and representation. Standards for describing multimedia documents include SGML, HTML, and MHEG. Hypertext links discrete chunks of text, while hypermedia generalizes this to include additional media types and synchronization. The World Wide Web uses HTTP, URLs, and HTML to access and display hypermedia documents over the internet. Forms and CGI scripts allow for user interaction, while Java applets enable interactive content to run in web browsers.Read less

Clinical Document Architecture (CDA) is a popular, flexible markup standard developed by Health Level 7 International (HL7 ) that defines the structure of certain medical records, such as discharge summaries and progress notes, as a way to better exchange this information between providers and patients. These documents can include text, images and other types of multimedia -- all integral parts of electronic health records (EHRs).

CDA is based on XML (Extensible Markup Language). To represent health concepts, CDA uses HL7's Reference Information Model (RIM), which puts data in a clinical or administrative context and expresses how pieces of data are connected. CDA also takes advantage of coding systems such as SNOM CT (Systematized Nomenclature of Medicine -- Clinical Terms) and LOINC (Logical Observation Identifiers Names and Codes).

With the HL7 format using XML and RIM, Clinical Document Architecture allows EHRs and other health IT systems to process documents while also letting people easily read them on Web browsers and mobile devices.

By setting standards for information exchange, CDA is a step toward the goal of ensuring that patient records can be created and read by any EHR software system. Many EHR vendors can produce CDA from their proprietary formats, according to HL7.

CDA does not identify a particular method for transferring the data in a document; options include DICOM (Digital Imaging and Communications in Medicine), MIME (Multi-Purpose Internet Mail Extensions, FTP (File Transfer Protocol) and HTTP (Hypertext Transfer Protocol), as well as HL7 version 2 messages and HL7 version 3 messages.

Together with the Continuity of Care Record (CCR) standard, CDA forms the basis for the Continuity of Care Document (CCD) standard for patient document information exchange. Both the CCR and CCD standards meet the United States government's guidelines for the meaningful use of EHR technology.

HL7 standards also include a newer offering called Fast Healthcare Interoperability Resources (FHIR - pronounced "fire"). FHIR is gaining traction in the healthcare industry, and is different than CDA. For example, CDA focuses on clinical document exchange; FHIR can also exchange information about finances and other areas not directly linked to patient care.

Standardization in the field of document structures, languages and related facilities for the description and processing of compound and hypermedia documents, including:

languages for describing document logical structures and their support facilities
languages for describing document-like objects in web environmentsfacilities
document processing architecture and formatting for logical documentsfacilities
languages for describing interactive documentsfacilities
multilingual font information interchange and related servicesfacilities
final-form document architecture and page information interchangefacilities
hypermedia document structuring language and application resourcesfacilities
API's for document processing

Almost done!
You are only one step away from joining the ISO subscriber list. Please confirm your subscription by clicking on the email we've just sent to you. You will not be registered until you confirm your subscription. If you can't find the email, kindly check your spam folder and/or the promotions tab (if you use Gmail).

CDA documents can be transmitted in HL7 messages designed to transfer clinical documents. While the detailed specification for such messages is outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in HL7 messages.

The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Schema in a document authoring environment, such use is not the primary purpose of the CDA specification.

Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. (For more on this, see Relationship of the CDA to HL7 Messaging Standards).

NOTE: Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions.

This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow.

Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See Examples for a detailed conformant example).

A CDA document is wrapped by the element, and contains a header and a body. The header lies between the and the elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers.

The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. The example shows a structured body, which is wrapped by the element, and which is divided up into recursively nestable document sections.

The CDA narrative block is wrapped by the element within the element, and must contain the human readable content to be rendered. See also Human Readability and Rendering CDA Documents and CDA Conformance for principles governing the representation of the narrative block, and conformance requirements on the part of originators when populating the block, and recipients when rendering it.

Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two CDA entries, and a entry containing a nested entry, although several other CDA entries are defined.

CDA entries can nest and they can reference external objects. CDA external references always occur within the context of a CDA entry. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the element). Externally referenced material is not covered by the authentication of the document referencing it.

While the notion of levels in CDA, Release Two remains constant, the approach to representing the hierarchies has changed. The current specification consists of a single CDA XML Schema, and the architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which serve to constrain the richness and flexibility of CDA.

NOTE: The CDA can be constrained by mechanisms defined in HL7 V3 Refinement and Localization. HL7 technical formalisms (e.g. HL7 Template specifications, HL7 Model Interchange Format) to constrain CDA are still in development at the time of writing this standard.

There is no requirement that CDA must be constrained. Implementations that use structured data elements to drive automated processes will typically require that they be either: (1) constrained by an appropriately refined model or other HL7 approved constraint language; or (2) comply with a detailed implementation guide that details the manner in which structured elements are to be represented and their intended interpretation to a level sufficient to ensure a degree of clinical safety that is appropriate to the use case that it is designed to address.