Strawman statement of requirements: CDA Levels Two & Three rev. 0.5, November 7, 2001

General Requirements for both Level Two & Level Three: Differentiation between Levels: Requirements for Level Two: Requirements for Level Three: Open issues: Requirements contained in ANSI/HL7 CDA R1.0-2000:

General Requirements for both Level Two & Level Three:

1. Meet or exceed all goals, principles and requirements for lower levels (Level Two meets all requirements for Level One; Level Three for Levels One & Two). (See last section below which quotes applicable passages and sections from the Framework and Level One specification.)

2. Retain requirement for human readability while adding requirements for machine processibility. Levels Two and Three are differentiated from each other by their degree of support for machine processing.

3. Permit automated (e.g., one XSLT script) transformation from higher level to lower level, with no loss of human readability or attested clinical content. Loss of machine-processibility when down-translating is acknowledged.

Differentiation between Levels: The large bulk of clinical documents potentially encoded in XML today and in the near future will lie somewhere between the extremes of markup granularity with some, but not all, discrete data encoded within a defined context.

Level One allows use of coded entries to identify sections and insertion of coded entries within the context of a section. It does not constraint or require the use of these semantic codes, neither does it differentiate between documents based on clinical document type. In Level One, a document generator can add semantic markup identifying sections and terms within the document, and comply with the allowed Level One syntax, but the conventions for when to do so are locally-defined.

Level Two adds requirements and constraints for use of coded entries based on clinical document type. Thus, while there is only one Level One schema, there can be at least one Level Two schema for each clinical document type.

Level Three adds additional markup to Level Two documents. This markup conveys discrete observations. The insertion of observations will be designed to leverage the defined context of a CDA document.

Requirements for Level Two: The baseline requirement for Level Two is section-level constraint on the generic Level One specification according to clinical document type. 1. Create a set of document specifications (HMDs, DTDs, schemas) specialized according to document type (document type here is a clinical designation, e.g., H&P, Discharge Summary, etc.). It constrains the Level One CDA specification according to clinical document type.

2. Each document type is a constraint on Level One, and, optionally, a constraint on a related Level Two document. Thus, a Level Two Progress Note is a constraint on Level One and a Level Two Endocrinology Progress Note is a constraint on Level Two Progress Note.

3. Level Two supports a range of processing requirements by constraining some, not necessarily all, section-level semantics and some, not all, section content to the level of coded entries. Level Two content will contain free text with and without associated markup. The granularity of encoding required within a Level Two document will vary from large-grained to fine-grained, according to industry capability and requirements. For example, a Level Two SOAP note that constrains only four section headers with no further required markup would be a large-grained specification. At the same time within Level Two, a SOAP note specification can be written that requires encoding of some fielded data such as current medications and vital signs. They would both be CDA Level Two SOAP notes. The least granular specification will be the Level Two base document.

NOTE: We need some method for identifying, tracking and relating all Level Two document types.

4. Required markup for a Level Two base document will be such that conformance can be achieved by transcription technology or an automated transformation from the output of a typical transcription system.

5. Level Two documents are automatically translatable to Level One CDA, but not necessarily to other CDA Level Two doc types.

6. Relationship to HL7 templates: each document specification may, itself, be considered a template. In addition, each document specification may contain one or more templates. Thus, an H&P specification can be a template and can contain a template for blood pressure. (This is not a requirement, per se.)

7. Level Two supports some forms of automated processing, e.g., indexing, retrieval, and enables automation in support of human review (case management, for example), but does not guarantee safe context of fielded data to support fully-automated clinical applications, e.g., decision support.

Requirements for Level Three: The goal for Level Three is encoding of discrete, field-level data within a context such that fielded data can be extracted for heterogeneous processing applications. 1. Create a set of document specifications (HMDs, DTDs, schemas) specialized according to document type (document type here is a clinical designation, e.g., H&P, Discharge Summary, etc.) that extend the requirement for machine-processibility to the level of observations.

2. Level Three specifications may extend and constrain specific Level Two document types, but it is not necessary to first build a Level Two. (For certain types of documents that are not typically transcribed, it may not make sense to create Level Two specifications.)

3. Level Three documents are down-translatable to any CDA level Two document specification of the same clinical classification.

4. Level Three documents ensure the safe context of observations to support unconstrained automated processing to the fullest extent possible.

5. Level Three requires a formal model of inheritance to ensure safe context of discrete observations.

6. It is explicitly not a requirement for Level Three that all clinical information be encoded as observations. A Level Three document can contain a mix of narrative with associated encoding and narrative without associated encoding.

Open issues:

1. need formal model of inheritance; not sure how this requirement should be applied to Level Two, but certainly a requirement for Level Three. 2. need formal method of correlating specifciations for clinical document types within each level. This requires completion of a formal document ontology.

Requirements contained in ANSI/HL7 CDA R1.0-2000:

"Levels" within the architecture represent a quantum set of specializations, to which further constraints can be applied:  CDA Level One is the root of the hierarchy and is the most general document specification. RIM classes are used in the specification of the document header, while the document body is largely structural, although terms from controlled vocabulary can be applied.  "CDA Level Two" will be a specialization of CDA Level One. It will constrain the set of allowable structures and semantics based on document type code, and may add additional markup.  "CDA Level Three" will be a specialization of CDA Level Two that will add additional markup, enabling clinical content to be formally expressed to the extent that is it modeled in the RIM.

The scope of the CDA is the standardization of clinical documents for exchange. Specifically, Levels Two & Three retain these characteristics of a clinical document, as stated in ANSI/HL7 CDA R1.0-2000:

 Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.1  Stewardship – A clinical document is maintained by a person or organization entrusted with its care.  Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.  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.

Levels Two & Three retain these “key aspects”, per the framework document:

 CDA documents are encoded in Extensible Markup Language (XML).  CDA documents derive their meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. [version of RIM, data types to be specified.]

Goals & Design Principles from ANSI/HL7 CDA R1.0-2000:

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

1.2.2 Design Principles

1 There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance. A number of design principles follow from consideration of the above goals. 1. This architecture must be compatible with XML and the HL7 RIM. 2. Technical barriers to use of the architecture should be minimized. 3. The architecture specifies the schemas required for exchange. 4. The architecture should impose minimal constraints or requirements on document structure and content required for exchange. 5. The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data. 6. Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies. 7. Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture. 8. 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 9. Use open standards.