electronic Submission of Medical Documentation (esMD) Clinical Document Architecture R2 and C-CDA Comparison April 24, 2013

Level 1 – The unconstrained CDA specification Level 2 – The CDA specification with section-level templates applied. Level 3 – The CDA specification with entry-level (and optionally section-level) templates applied. CDA R2: Levels of Constraint 2

A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. Recipient Responsibilities –Assume default values where they are defined in this specification, and where the instance does not contain a –Parse and interpret the complete CDA header –Parse and interpret the CDA body sufficiently to be able to render it Originator Responsibilities –Properly construct CDA Narrative Blocks CDA R2 - Conformance 3

Originator Responsibilities –An originator can apply a templateId i f there is a desire to assert conformance with a particular template. In the most general forms of CDA exchange, an originator need not apply a templateId for every template that an object in an instance document conforms to. The implementation guide (IG) shall assert whenever templateIds are required for conformance. Recipient Responsibilities –A recipient may reject an instance that does not contain a particular templateId (e.g., a recipient looking to receive only Procedure Note documents can reject an instance without the appropriate templateId). –A recipient may process objects in an instance document that do not contain a templateId (e.g., a recipient can process entries that contain Observation acts within a Problems section, even i f the entries do not have templateIds). C-CDA Conformance 4

The CDA standard describes conformance requirements in terms of three general levels corresponding to three different, incremental types of conformance statements: Level 1 requirements impose constraints upon the CDA Header. The body of a Level 1 document may be XML or an alternate allowed format. If XML, it must be CDA-conformant markup. Level 2 requirements specify constraints at the section level of a CDA XML document: most critically, the section code and the cardinality of the sections themselves, whether optional or required. Level 3 requirements specify constraints at the entry level within a section. A specification is considered “Le vel 3” i f i t requires any entry level templates. C-CDA: Levels of Constraint 5

CDA R2 – Acknowledges that templates can be created C-CDA – Defines templates for documents, sections and entries Use of Templates 6

Open vs. closed statements Conformance verbs Cardinality Vocabulary conformance Containment relationships Null flavors C-CDA Conformance Statements 7

Open templates –All of the features of the CDA R2 base specification are allowed except as constrained by the templates. Closed template –Specifies everything that is allowed and nothing further may be included. Open and Closed Templates 8

SHALL: an absolute requirement SHALL NOT: an absolute prohibition against inclusion SHOULD/SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a di fferent course MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications Conformance Verbs 9

The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within a document instance. The cardinality indicators are interpreted with the followng format “m…n” where m represents the least and n the most: –0..1 zero or one –1..1 exactly one –1..* at least one –0..* zero or more –1..n at least one and not more than n Cardinality 10

Value-set bindings adhere to HL7 Vocabulary Working Group best practices, and include both a conformance verb (SHALL, SHOULD, MAY, etc.) and an indication of DYNAMIC vs. STATIC binding. Value-set constraints can be STATIC, meaning that they are bound to a speci fied version of a value set, or DYNAMIC, meaning that they are bound to the most current version of the value set. Vocabulary Conformance 11

Containment constraints between a section and its entry are indirect in this guide, meaning that where a section asserts containment of an entry, that entry can either be a direct child or a further descendent of that section. Example of indirect containment constraint –SHALL contain at least one [1..*] entry (CONF:8647) such that it a. SHALL contain exactly one [1..1] Advance Directive Observation (templateId: ) (CONF:8801).CONF:8801 Example of direct containment contstraint –SHALL contain exactly one [1..1] (CONF:7928) Containment relationships 12

Use null flavors for unknown, required, or optional attributes: NI No information. This is the most general and default null flavor. NA Not applicable. Known to have no proper value (e.g., last menstrual period for a male). UNK Unknown. A proper value is applicable, but is not known. ASKU Asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know). NAV Temporarily unavailable. The information is not available, but is expected to be available later. NASK Not asked. The patient was not asked. MSK There is information on this item available but it has not been provided by the sender due to security, privacy, or other reasons. There may be an alternate mechanism for gaining access to this information Null Flavor 13

All data types used in a CDA document are described in the CDA R2 normative edition. All attributes of a data type are allowed unless explicitly prohibited by this specification. Examples –AD – Address –CNE – Coded with No Exceptions –DT – Date –ED – Encapsulated Data DataTypes 14

Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A, editors. HL7 Clinical Document Architecture, Release 2.0. ANSI-approved HL7 Standard, May Ann Arbor, MI: Health Level Seven, Inc., HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release US Realm References 15