The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis

Abstract

Health care provides many opportunities in which the sharing of data between independent sites is highly desirable. Several standards are required to produce the functional and semantic interoperability necessary to support the exchange of such data: a common reference information model, a common set of data elements, a common terminology, common data structures, and a common transport standard. This paper addresses one component of that set of standards: the ability to create a document that supports the exchange of structured data components. Unfortunately, two different standards development organizations have produced similar standards for that purpose based on different information models: Health Level 7 (HL7)'s Clinical Document Architecture (CDA) and The American Society for Testing and Materials (ASTM International) Continuity of Care Record (CCR). The coexistence of both standards might require mapping from one standard to the other, which could be accompanied by a loss of information and functionality. This paper examines and compares the two standards, emphasizes the strengths and weaknesses of each, and proposes a strategy of harmonization to enhance future progress. While some of the authors are members of HL7 and/or ASTM International, the authors stress that the viewpoints represented in this paper are those of the authors and do not represent the official viewpoints of either HL7 or of ASTM International.

Famous author Aldous Huxley wrote, “Technological progress has merely provided us with more efficient means for going backwards.”¹ As we move closer to the reality of creating a truly interoperable electronic health record (EHR), these words may ring true. While both clinicians and informaticians envision an EHR that embraces semantic interoperability and seamless information exchange, overlapping technologies emerge that may complicate the realization of this vision. Differing standards and data architectures may prove to be the greatest obstacle of all. Unless developers and standards organizations strive to work together, the array of competing technologies could become the health care information technology Tower of Babel.

In an ideal world, standards development organizations (SDOs) would communicate with and learn from one another. The result would be one standard for each purpose. It should not be surprising, however, that two SDOs frequently find themselves working on similar standards. When that happens, partial overlaps, contradictions, and competition can occur. In the case of the standards discussed in this paper, the competition has been strong and counterproductive for all parties involved. One organization, The American Society for Testing and Materials (ASTM International), was concerned that Health Level 7 (HL7) might have infringed upon ASTM's intellectual property rights and incorporated their work into HL7's proposed standard. This paper attempts to define and contrast the two similar standards in an effort to promote a better understanding and harmonization of the two efforts. The comparison is made from the viewpoint of persons active in HL7; however, it is important to note that the viewpoints represented are those of the authors alone.

Background

Traditionally, medical notes have been loosely structured, handwritten documents that vary in content by specialty but result in a record containing pertinent medical information and facts. Although rough guidelines impose some structure on these documents (e.g., problem-oriented SOAP [subjective, objective, assessment, and plan] notes²), there are no rules per se governing the organization of paper-based clinical notes. As we venture into the realm of electronic data exchange, however, the importance of structure becomes more evident. At present, several SDOs are working to create a framework for representing and exchanging the contents of EHRs. We examine in some detail two of the prominent medical record content–related standards under development. Independent of the standard to be used, generating structured content for EHRs is not widely accepted by practicing clinicians as being easy to do or problem free.³

Both the HL7 Clinical Document Architecture (CDA) and the ASTM International Continuity of Care Record (CCR) strive to facilitate the interchange of health care data among care providers. The CDA is based on the HL7 version 3 Reference Information Model (RIM),⁴ and the CCR is a clinical framework that was originally developed by health care practitioners to meet the information exchange needs of primary care providers.⁵ Both technologies use the World Wide Web Consortium standard of Extensible Markup Language (XML) to facilitate the exchange of structured medical data.⁶

The CDA has evolved through several iterations. While CDA release 1 (CDA R1) focused on the structured header, CDA release 2 (CDA R2) introduced the concept of structured elements within the document body. Similarly, the CCR is in its second revision, referred to originally as CCR version 1a and currently as ASTM International standard E2369-05.⁷ (To maximize clarity for the reader, this article refers to the newer version of CCR [ASTM E2369-05] as “version 1a” and the original draft standard as “version 1.” The authors note that ASTM currently refers to E2369-05 as “version 1.0.”) While version 1 of the CCR was based on a relatively simple XML schema, version 1a introduced a new object-oriented approach to data modeling.

The HL7 CDA is based on a formal information model and can be used for a number of document types, including radiology reports, progress notes, clinical summaries, and discharge summaries. Release 1 of the CDA became an ANSI standard in November 2000 and defined only a structured header. It permitted a unique identifier, a name for the document, a date of creation, an author, and a place of origin. The body of the document was left unstructured and served only as a container for narrative text. Users could provide additional structure to the body using their own rules, but these were not defined as part of the initial standard. Release 2 of the CDA added structure to the document body as well as to the header. The CDA is a complex standard that can be challenging to implement. To address this concern, the HL7 technical committee responsible for the CDA specification is in the midst of generating implementation manuals to facilitate CDA use.

The initial version of the CCR had as its strengths a lightweight, easily implemented approach, and it was intended primarily for the exchange of health summaries. This approach was quite straightforward, and many organizations quickly developed prototype implementations of the standard. The CCR impressed many members of the health informatics community during a demonstration at the 2004 annual conference of the Healthcare Information and Management Systems Society (HIMSS) and the 2004 Toward an Electronic Patient Record conference.^8,9

The second iteration of the CCR (version 1a), which underwent balloting as an ATSM standard in April 2005, provides a more complex architecture for exchanging electronic health summaries. As described in the standard, version 1a uses a new object-oriented data model⁷ that adds a level of detail and structure to the original CCR. The architecture of the current CCR specification appears to overlap with the CDA in both complexity and scope. Given this conflict, there is value in examining these two approaches. The clinical informatics community would benefit from the two parent SDOs working collaboratively to define a common standard for medical document exchange, and that cooperation appears now to be taking place. As Mr. Huxley implied in the opening quotation, adding additional technology is sometimes not the answer. Given the framework already provided by the HL7 Clinical Document Architecture and the proven clinical utility afforded by the CCR, the authors believe that synergy could be achieved by working together to blend the two standards into a single document exchange standard that retains the best features of each.

Overview of the Continuity of Care Record

ASTM International is an SDO whose mission is “To be the foremost developer and provider of voluntary consensus standards, related technical information, and services having globally recognized quality and applicability that promote public health and safety, and the overall quality of life.”¹⁰ The ASTM CCR was created to address a very real clinical problem: physicians need a way to collect a relevant nucleus of patient care information in a format that is structured, human-readable, and easily transferable. To that end, several high-profile medical organizations, including the American Academy of Pediatrics, the Massachusetts Medical Society, the American Academy of Family Physicians (AAFP), the Health Information Management and Systems Society (HIMSS), and the American Health Care Association, have joined forces with ASTM International to create what is now known as the CCR. According to the AAFP, the CCR is “a way to create flexible documents that contain the most relevant and timely core of health information about a patient, and to send these electronically from one care giver to another.”¹¹

The CCR was created by health care practitioners based on their perceptions of the data they wish to share in a given circumstance. Unlike many other standards, clinicians were actively involved in the creation of the CCR and were integral to defining its form and content. It is patient focused and emphasizes the data directly related to a patient's current medical problems. Ideally, the content for any instantiation is defined by a provider who knows the patient well. The CCR document is then used to transmit timely and focused information to other physicians involved in the patient's care. ASTM International defines the CCR as a “summary of the patient's health status (e.g., problems, medications, allergies) and basic information about insurance, advance directives, care documentation, and care plan recommendations.”¹² ▶ illustrates the conceptual model of the ASTM CCR version 1.¹³ ▶ provides an example of a patient summary encoded in the original CCR format (version 1). For comparison, ▶ displays corresponding information formatted for CDA, and ▶ is an example of the same patient information using the current CCR standard (version 1a). The increased complexity in going from CCR version 1 to CCR version 1a is evident by comparison.

Figure 1.

Conceptual model of Continuity of Care Record version 1, 02/08/2004.²²

Figure 2.

Sample Continuity of Care Record version 1 family history component. Constructed using XMLSpy^® based on schema “CCR31.xsd” by ASTM International, used for the 2004 HIMSS demonstration.

Figure 3.

Sample Clinical Document Architecture family history component. From Implementation Guide for CDA Release 2-Level 2-Care Record Summary (US realm), p. 16. Disease of interest altered to match examples from Continuity of Care Record.

Figure 4.

Sample Continuity of Care Record version 1a family history component. Created using the CCR Generator Tool (https://www.solventus.com/aquifer/ReportContainer.aspx?control=CCRgeneratorform) by Solventus, accessed February 6, 2006 via the Continuity of Care Record site (http://continuityofcarerecord.org/x6170.xml) of the American Academy of Family Physicians.

The CCR is intended to provide consulting physicians with the information necessary to participate in a patient's care. In relation to an EHR, the CCR can be described as a data extract. As the implementation guide explains, “the CCR represents the patient summary, which for many EHRs is called the ‘overview’ of the patient.”¹³ In essence, the CCR pools relevant information from multiple medical documents and creates a “snapshot” of the patient.⁷ From that view, it appears that the CCR was originally intended neither to replace the complete birth-to-death longitudinal record nor to define individually all the clinical documents that would make up such a record. However, the standard goes on to state that the CCR can be used to “facilitate the implementation” of use cases other than a “summary document,” although they are not directly supported by the standard.⁷ The standard does not fully indicate what the CCR use cases will entail. Thus, it is possible that these use cases will overlap with CDA templates.

The CCR is summarized by ASTM as “a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's health care, covering one or more health care encounters.”⁷ It is projected that the CCR will help prevent medication errors, provide a basis for avoiding drug–drug interactions and duplicate prescriptions, and reduce redundant laboratory testing. In addition, future applications may “empower patients to participate in managing their own health. For example, patients could use the CCR on their home computer to review medications for drug–drug interactions or synchronize their dosing schedule with their PDA.”⁵ Several recent demonstrations of the CCR have successfully used USB memory keys as the transport medium for CCR documents.¹⁴

A CCR document is represented using XML, making it easy to transport and display. At present, it is specified by an XML schema and an implementation guide. The CCR supports the use of coding systems such as Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), Logical Observation Identifiers Names and Codes (LOINC), RxNorm, and CPT, but it is up to the end-user to use the coded-data functionality; as the implementation guide explains, the CCR “strongly recommends the use of controlled vocabularies but has provided a small number of ‘escape hatches’ for free text where deemed absolutely necessary for those systems that cannot support discretely structured, tagged and coded data.”⁷ CCR-compliant XML documents will be compatible with standard HL7 messages, interpretable by many third-party EHRs, and human-readable using a standard Web browser. CCR documents can also be printed using a wide variety of tools ranging from Microsoft Word to Adobe Acrobat Reader. A CCR document consists of a set of data objects that are organized in a structured manner using XML.

The CCR version 1a recently became a full ASTM standard. While the April 4, 2004, ballot of CCR version 1 received approval by 95% of the ASTM Working Group members, the scope of version 1a appears to have attracted more interest and hence a larger voting pool than the original specification. A critical analysis of this technology is useful because there are significant differences between these two versions of the CCR (▶).

Table 1.

Comparison of CCR Versions 1 and 1a

Category	Version 1	Version 1a
Vendor interest	Significant vendor awareness and interest, including use in high-profile demonstrations at HIMSS 2004 and TEPR 2004	New version employs a more complex data model with expanded functionally; level of vendor interest not known at this time
Underlying data model	Proprietary, document-based data model	Proprietary, object-relational data model
Machine interpretability	Designed primarily for human consumption	Provides options for defining data in structured, machine-interpretable formats
Complexity	Relatively simple to implement	More complex to implement
Overlap with CDA	May overlap with HL7 CDA referral document	Overlaps with CDA in general purpose and scope

CCR = Continuity of Care Record; CDA = Clinical Document Architecture; HL7 = Health Level 7; HIMSS = Healthcare Information and Management Systems Society; TEPR = Toward an Electronic Patient Record.

Although the CCR has the potential to bring substantial benefit to the practice of clinical medicine, it is important to better understand the areas of overlap between the CCR and the CDA. The clarification of this relationship is critical to vendors, developers, and the informatics community in general. It is essential to harmonize the efforts of the two SDOs and produce a single standard that is truly interoperable and, to the greatest extent possible, “future proof.”

The Clinical Document Architecture

Like ASTM, HL7 is an American National Standards Institute-accredited SDO, whose mission is “to provide standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of health care services.”¹⁵ As such, HL7 has been integral in the creation of the messaging and health data standards that currently permeate health care in the United States.

Realizing that the effective communication of medical information requires both messaging standards and common data structures, HL7 developed the CDA (R1 in 2000¹⁶ and R2 in 2005¹⁷) to provide a common representation for clinical documents through “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 CDA derives its content directly from the HL7 Reference Information Model (RIM) and therefore is specifically designed to integrate with current HL7 technologies. A CDA document “can exist outside of a messaging context and/or can be a MIME-encoded payload within an HL7 message. Thus the CDA complements HL7 messaging.”¹⁷ In essence, each CDA instantiation represents a distinct clinical document, whether a progress note, discharge summary, or radiology report. The CDA is basically a constrained version of the HL7 RIM, in which RIM object classes have been assigned specific data types and vocabularies.¹⁸ In HL7 terms, this constraint of the RIM is called a Refined Message Information Model (R-MIM). The CDA document type and Universal Observation Identifier Names are defined with LOINC¹⁹ document codes. Like the CCR, the CDA allows for controlled terminologies such as SNOMED CT to enhance semantic interoperability between medical information systems. Although some contend that a single CDA document could in itself represent a complete EHR, others have envisioned the EHR consisting of a structured collection of multiple CDA documents. The defining characteristics of all CDA documents are persistence, stewardship, wholeness, human readability, and potential for authentication.¹⁶

Like the CCR, the CDA is implemented using XML. See ▶, ▶, and ▶ for a sample section of a CDA document and its analogous data formatted for CCR versions 1 and 1a by the authors. The common architecture can be adapted for progress notes, radiology reports, discharge summaries, transfer notes, medications, laboratory reports, and patient summaries. Although the initial HL7 Care Record Summary did not pass its first ballot, HL7 does directly support a discharge summary and a referral document. This concept raises the question of whether the CCR requires a separate standard or could be accurately represented as a CDA document. Some initial work is being performed by the Canadian company e-MS using the CDA to create a clinical summary of critical patient information.²⁰

The CDA allows for multiple distinct “levels” of machine readability to facilitate maximum compatibility. Level 1 is an “unconstrained” CDA and allows for free text in order to facilitate the transfer of unstructured clinical notes; this approach provides maximum compatibility with older systems and simplifies the implementation process from a technical standpoint. Level 2 adds a specification for section constraints within the CDA document in order to provide some structure while still allowing for unconstrained elements within the headings; e.g., one could define the section headings of subjective, objective, assessment, and plan for the classic SOAP note. Level 3 provides for fully structured “entry level templates” and is by far the most granular, allowing for maximum machine readability.¹⁸ In essence, each increasing level allows for additional machine readability, but the clinical content of the notes should be identical in all three levels. Currently, CDA R2 supports constraints up to level 2.¹⁷ CDA level 3 specifications are expected to be available in the near future. In contrast to the CDA's incremental levels of interoperability, the CCR relies on a single explicit data structure and does not allow for, or require, local extensions.

Comparison of the CDA Version 2 and the CCR Version 1a

While both methodologies aim to improve patient care through efficient information exchange, their approaches differ (▶). The CCR stresses the important pieces of data required to care for a patient, whereas the CDA serves as a document architecture to format all clinical documents. Both standards aim to facilitate the exchange of medical documents in a format that is both human readable and machine parsable. However, the scope of the CCR is focused on the primary care “summary record” and does not explicitly support other use cases. According to ASTM, “The primary use case for the CCR is to provide a snapshot in time… [it] does not speak to other use cases or workflows but is intended to facilitate the implementation of use cases and workflows.”⁷ While CCR version 1 focused clearly on this summary record, version 1a may be expanding its scope to encompass all possible clinical documents.

Table 2.

Comparison of CCR and CDA

Category	Similarities	Differences	Assessment
Purpose and scope	Both provide a mechanism for creating medical documents in a human-readable and, where possible, machine-interpretable format.	CCR focuses on patient summary information.	Authors of this article prefer the CDA approach because of:
		CDA has a much larger scope, accommodating any kind of medical document.	1. Explicit support for use in multiple document exchange scenarios other than the transport of a patient health summary
		CCR thus does not provide a formal mechanism for defining specialized CCR document types (e.g., discharge summaries, progress notes).	2. Ability to define templates for specific use cases
		By contrast, a patient summary is just one of many potential uses of the CDA standard and may be specified using a CDA “template.”	3. Use of standard components (e.g., data types, information models) based on input from many different stakeholders from various HL7 committees
		Because CDA was created by HL7, CDA is one of the HL7 version 3 family of standards; as such, its components (e.g., data types, information models) can be reused across other HL7 version 3 standards (e.g., messages).
Development methodology	Conducted at SDOs (ASTM for CCR, HL7 for CDA)	CCR does not explicitly consider use cases but was developed with direct clinician involvement.	The CCR methodology is most likely faster to implement. In the authors' opinion, the CDA model appears more robust in its ability to handle more complex details and extensions.
		HL7 version 3 methodology explicitly considers use cases; HL7 uses a robust, balloted, consensus-driven development methodology.
Difficulty of use and implementation	Both CCR version 1a and CDA R2 are fairly complex (as opposed to CCR version 1, which was much more straightforward to understand and implement).	Effort used to implement CCR version 1a cannot be easily leveraged for meeting other standards-based communication needs: the components used (e.g., data types, information models, vocabulary specifications) need not be standard components, but they can be standards based (e.g., LOINC, SNOMED CT).	HL7 approach is generally preferred by the authors (compared to CCR version 1a), but the lack of a level 3 implementation guide for the CDA is a relative weakness and adds to the complexity of any CDA implementation.
	Both CCR version 1a and CDA R2 provide detailed implementation guides, with validation mechanisms (implementation guide for CCR; implementation guide plus Schematron schemas or XSLT style sheets for CDA).	Effort used to implement CDA R2 can be leveraged for other data exchange needs, as they are based on common HL7 version 3 components.
		CCR does not provide a method for specifying specific document templates based on use cases (e.g., discharge summary, referral to cardiologist, patient health summary), whereas CDA provides an explicit method for doing this (see section below entitled “Ability to specify and support specific use cases”). Since CCR was pragmatically derived by clinicians, it is not clear which is better.
		CCR provides an implementation guide that covers its entire scope of work; CDA provides implementation guide only up to level 2 (section constraints), although the CDA committee is currently working on defining an implementation guide for level 3 (detailed structured content level).
Extensibility	Both CCR and CDA use XML syntax.	CCR makes a point of not allowing any user-configurable fields and thus does not allow for local differences in implementation.	In the authors' opinion, the CDA provides greater adaptability and extensibility to meet the needs of local implementations. If one adheres to the more narrowly defined purpose of CCR, it is uncertain how significant this difference is.
		CDA is adaptable and explicitly allows for local extensions and configurability. Because of its broad object-oriented approach to modeling, the HL7 CDA is able to meet local requirements, while still allowing mapping back to the standard. It is not clear how detrimental the lack of extensibility is for CCR when one adheres to its stated purpose. HL7 has potential to meet additional goals due to extensibility.
Ability to specify and support specific use cases		CCR does not provide a formal method for defining specialized document templates based on use cases; it was derived by clinicians to meet a specific purpose.	In the authors' opinion, the HL7 approach is preferable because it is widely applicable to multiple use cases and explicitly provides a mechanism for specifying document templates. Again, if one adheres to the more narrow goals of CCR, the advantage of HL7 may not be as great.
		CDA provides a concrete method for specifying document templates to be used for specific use cases. In the current implementation guides, the constraints for particular use cases can be defined using Schematron schemas (http://xml.ascc.net/schematron/).
Information modeling approach	Multitiered specification, going from just human readable to detailed, unambiguous machine-interpretable encoding.	CCR implements this concept using a CodedDescriptionType, where level 1 is a simple text string, level 2 is a coded simple text string, and level 3 is a coded simple text string plus structured representation.	It is difficult to say that one approach is superior over the other; however, in the authors' opinion, the use of a robust reference information model (RIM) makes the HL7 information modeling approach attractive. Furthermore, the HL7 RIM has been International Standards Organization-approved and is the basis for many other approved standards.
		CDA implements this concept using specifications at level 1 (unconstrained CDA specification), level 2 (section-level templates defined), and level 3 (entry-level templates defined).
		Multiple miscellaneous differences (e.g., how addresses are modeled, how vocabularies are specified).

CCR = Continuity of Care Record; CDA = Clinical Document Architecture; HL7 = Health Level 7; SDO = standards development organization; R1 = release 1; R2 = release 2; SNOMED CT = Systematized Nomenclature of Medicine Clinical Terms; LOINC = Logical Observation Identifiers Names and Codes; ASTM = American Society for Testing and Materials.

In contrast, the CDA was conceived and specifically built to represent virtually any type of medical document, and it adds complexity to cover this generality. It has been suggested that a complete CCR “summary document” could be expressed as a CDA document template. Since the CCR has clear clinical utility and the CDA provides a strong structural backbone, it seems that harmonization of these technologies is the best solution. Since the CDA is intimately linked to the HL7 RIM, its components are applicable across other HL7 standards, and it could add additional functionality and interoperability to the clinically useful CCR.

It seems to the authors that the initial difference between the two standards lay in purpose and scope. The CDA is document centric and useful in modeling the complex structure of a multitude of clinical documents. In contrast, the CCR was designed to focus on the data elements rather than the documents. It was originally modeled on the Patient Care Referral Form set forth by the Massachusetts Department of Public Health, and it strives to collect all the data objects relevant to a patient's current medical condition.²¹

The authors raise several questions regarding CCR version 1a. The implementation guide suggests that the CCR can be used for many use cases other than the original referral record. This statement reinforces the authors' belief that the new CCR may overlap in scope with the CDA. Since its inception, the CDA has explicitly considered a myriad of use cases and explored the application of the CDA to a multitude of clinical scenarios. These scenarios will help define the specialty-specific domain constraints required for a wide variety of clinical documents. Schematron schemas can be used to constrain specific use cases.

Both the CCR version 1a and the CDA R2 are complex. In its first iteration, the CCR was perceived as more user-friendly and more easily implemented since the number of classes was smaller and the overall data structure was more intuitive. Although the CDA's object-oriented data model appears more complicated than that of CCR version 1, the authors believe that the difference in perceived complexity stems from the late appearance of its implementation guides. In contrast, the CCR comes with an excellent implementation guide that defines the components of the standard. At present, the CDA implementation guide only addresses section constraints (Level 2) (e.g., family history, social history). A Level 3 implementation guide that defines completely structured content is due to be released by HL7. The authors anticipate that the Level 3 implementation guide will reduce development times and allow for substantial progress to be made in a short period of time.

With the release of CCR version 1a, the CCR has taken on a level of complexity more similar to that of the CDA. The authors believe that this version of the CCR is as complex as the CDA. This added complexity could facilitate richer semantic representation and allow for other types of clinical documents, but it may not advance the comparative advantage that the original CCR held over the CDA in terms of simplicity.

The authors believe that the complexity of these novel technologies must be weighed against the future potential for semantic interoperability. Interoperability requires common or standard data elements with precise definitions, a predefined vocabulary system, and strict processing rules. Realizing this, ASTM initially proposed two technical implementations for the CCR: a simplified base standard that can be implemented quickly and a second version that could be mapped to the CDA if required to facilitate information exchange.

Both the CDA and the CCR have an unclear relationship with a complete EHR. The CDA was designed to create a wide variety of individual clinical documents; thus, it should be possible to organize and collect these documents in the context of an EHR system. The CCR focuses on the summary record and, as such, it could span multiple encounters and multiple health care providers. Although the initial purpose of the CCR was to represent a patient summary, the CCR can be used to represent a lifelong EHR if the referring physician chooses to include that level of detail. The content of a CCR relies heavily on the opinion of the referring physician. This option may be viewed as either an advantage or a disadvantage.

As previously noted, by design, the CCR does not provide for user-configurable fields. The implementation guide stresses the point: “To reiterate, there are no end-user or vendor configurable fields in the CCR.”⁷ The structure of the CCR requires this level of consistency in order to ensure interoperability. Unfortunately, in the authors' opinion, this lack of local extensibility could make it difficult for institutions to tailor the CCR to meet needs beyond the stated purpose of the CCR. In many cases, if additional purposes are desired, this may force vendors and local centers to create proprietary solutions that deviate from the CCR standard. The CDA, on the other hand, is quite flexible and permits local extensibility while maintaining direct mapping to the RIM. This flexibility may be viewed as an advantage or disadvantage, given the work required to create useful local representations for documents.

Conclusion

Overall, the CCR is a clinically useful document that has been forged from the ground up to meet a specific need. Its major contribution is capturing the intent of providers and vendors to move data between disparate groups in a human-readable, summary form. Its utility as a clinical tool remains unquestioned, and it promises great advances beyond our current paper-based systems. In the authors' opinion, as a general-purpose information exchange standard for all EHR components, the technical implementation of the CCR falls short of the mark because the CCR was designed for a single purpose. Although the CCR meets an important clinical need, users may require the enhanced interoperability offered by the CDA when other needs exist.

Looking ahead at the future of these standards, a major goal should be to maximize their strengths and minimize their weaknesses. The information contained in both formats can be expected to improve patient care, reduce medication errors, and ameliorate the financial burden of unnecessary duplicate testing. The CCR's usefulness was manifest in the simple yet robust clinical functionality provided by the initial version of the standard. The strength of the CDA, on the other hand, lies in its strong framework and dynamic adaptability. In the authors' opinion, with CCR version 1a, ASTM deviated from the strengths of version 1 by moving CCR toward some of the functionality, and thus the complexity, of the CDA. Rather than creating an overlapping set of technologies, it is more prudent that the organizations collaborate and capitalize on each initiative's strengths.

As clinicians and informaticians, the authors are frustrated by the conflicting technologies in health care information technology. While the authors see substantial value in the CCR, they are concerned that it does not possess the same potential for interoperability as the CDA. Several possible solutions exist, however. One solution is to completely map the CCR into CDA using XSLT transformations. This solution is only acceptable if it can be done without data loss. If the two standards cannot be directly linked in this way, a second option might be to define a Common Data Element Set to be used in all clinical documents. (In this sense, data elements can be thought of as individual entries, such as fill-in-the-blanks, on a medical intake form.) The elements can be combined and organized to accommodate a wide variety of clinical scenarios. Of course, special care must be taken to assign terminologies to each data element. In this way, CDA documents, CCR records, X12N claim forms, DICOM image reports, and many others might finally be able to communicate together. In the end, the ideal solution is a single standard using content and knowledge from both groups.

Recently, after much discussion among the members of both groups, the issues appear to be resolving. HL7 announced in November 2005 that it is creating an implementation guide for expressing the CCR data set in the CDA. This action provides a critical step toward interoperability and builds on the strengths of both organizations. The implementation guide will combine the CCR-defined set of data elements with the CDA's method for expressing clinical documents. To achieve semantic interoperability, CCR data elements will be expressed in CDA syntax and will be compatible with the HL7 RIM. We must continue pursuing cooperation and collaboration, rather than competition, to achieve our common goal of improving health and saving lives.