This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

2.3.1 Clinical Document Architecture (CDA) on FHIR

2.3.1.1 What is CDA on FHIR?

CDA on FHIR specifies how to implement CDA R2 with the FHIR Composition resource.
The original HL7 Clinical Document Architecture (CDA) defined the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a documentation of clinical observations and services, with the following characteristics:

• Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance).
• Stewardship - A clinical document is maintained by an organization entrusted with its care.
• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
• Context - A clinical document establishes the context for its contents.
• Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
• Human readability - A clinical document is human readable.

2.3.1.2 Scope of the CDA on FHIR

The scope of CDA on FHIR is the standardization of clinical documents for exchange.

The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification.

CDA on FHIR 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.

2.3.1.3 Goals and Design Principles

The goals of the CDA on FHIR are:

• Give priority to delivery of patient care.
• Allow cost effective implementation across as wide a spectrum of systems as possible.
• Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
• Promote longevity of all information encoded according to this architecture.
• Enable a wide range of post-exchange processing applications.
• Be compatible with a wide range of document creation applications.
• Promote exchange that is independent of the underlying transfer or storage mechanism.
• Prepare the design reasonably quickly.
• Enable policy-makers to control their own information requirements without extension to this specification.

• This architecture must be compatible with XML and JSON.
• This architecture must be compatible with representations of clinical information arising from other HL7 committees.
• Technical barriers to use of the architecture should be minimized.
• The architecture specifies the representation of instances required for exchange.
• The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
• The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
• Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
• Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
• CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.
• Use open standards.

2.3.1 General CDA on FHIR Concepts

2.3.1.1 Major Components of a CDA on FHIR Document

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. [EDITORS: in CDA r2 there is a bunch of detail about how CDA is wrapped - and an example. Consider whether the discussion is relevant here: "A CDA document is wrapped by the <ClinicalDocument> element, and contains a header..."]

2.3.1.2 Human Readability and Rendering CDA Documents

The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser.

• There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
• Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools.
• Human readability applies to the authenticated content. There may be additional information conveyed in the document that is there primarily for machine processing that is not authenticated and need not be rendered.
• When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
• When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.

2.3.1.3 EDITORS CONTINUE FROM HERE (SDC IG COPIED BELOW)

The SDC FHIR Implementation Guide is built on top of the HL7 FHIR standard. It makes use of the following resources:

• DataElement is used to define data elements that can be referenced in questionnaires and can be used to auto-populate form data
• Questionnaire is used to define form definitions that may be downloaded for manual and/or automatic population
• QuestionnaireAnswers is used to share instance data captured using questionnaire forms
• ValueSet is used to define allowed values for data elements and for questions in questionnaires

Additional resources such as Patient , Practitioner , Provenance , AuditEvent and others are likely to be used in SDC solutions, though no SDC-specific profiles have been created for them. As well, basic aspects of the FHIR protocol, including RESTful operations , data types , search , etc. also apply.

The SDC specification consists of the following components:

• SDC profiles - Profiles on the four FHIR resources used to support the IG requirements:
  • SDC Data Element (DE) Profile - Constraints and extensions for capturing data elements
  • SDC Questionnaire Profile - Constraints and extensions for capturing form designs
  • SDC Questionnaire Answers Profile - Constraints and extensions for capturing form data instances
  • SDC Value Set Profile - Constraints and extensions for defining lists of allowed codes
• Pre-population Operation - The definition of the custom service that allows pre-population of forms based on CDA and other data sources
• Conformance statements - Definitions for the expected capabilities of each of the actors involved supporting SDC functionality:
  • SDC Data Element Manager - Repository for data elements
  • SDC Form Designer - System responsible for creating and editing forms
  • SDC Form Filler - System responsible for capturing user form input
  • SDC Form Manager - Repository for form definitions. Also performs pre-population
  • SDC Form Receiver - Repository for completed forms

2.3.1.4 Pre-population service

The Questionnaire resource defines a custom operation called populate . This operation supports generating a "blank" QuestionnaireAnswers instance based on a specified Questionnaire . It also allows for the returned questionnaire to be partially or even fully completed based on data passed in to the operation or data already available to the server on which the operation is invoked.

For SDC purposes, server systems claiming to support roles that require support for the populate operation ( SDC Form Manager ) SHALL, at minimum:

• Handle the input parameters identifier , questionnaire , subject and content
• Support content parameters consisting of a Binary resource containing a C-CDA document
• Populate the returned QuestionnaireAnswers instance for all questions referencing DataElements that are mapped to C-CDA content

Similarly, client systems claiming to support the populate operation ( SDC Form Filler ) SHALL, at a minimum:

• Be capable of invoking the operation on a selected questionnaire both directly ( Questionnaire/[identifier]/$populate ) as well as indirectly either by identifier or questionnaire
• Support passing a single C-CDA document as a Binary resource using the content parameter

IMPORTANT:

Not all DataElements will be appropriate or safe to reference in a Questionnaire. It is important that the definition associated with the data element fully reflects the context of the question in the questionnaire. For example, "gender" would not be a safe data element because it would not be clear whether the gender was that of the patient or a fetus of the patient. It must be clear from the data element definition exactly what piece of information should be extracted from a source system, CCDA document or other data source. (Inclusion of mappings to specifications such as CCDA is recommended practice whenever possible.)