1 / 15

April 24, 2013

e lectronic Submission of Medical Documentation (esMD) Clinical Document Architecture R2 and C-CDA Comparison. April 24, 2013. CDA R2: Levels of Constraint. Level 1 – The unconstrained CDA specification Level 2 – The CDA specification with section-level templates applied .

enan
Download Presentation

April 24, 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. CDA R2: Levels of Constraint • 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.

  3. CDA R2 - Conformance • 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

  4. C-CDA Conformance • Originator Responsibilities • An originator can apply a templateIdi 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 templateIdfor every template that an object in an instance document conforms to. The implementation guide (IG) shall assert whenever templateIdsare 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).

  5. C-CDA: Levels of Constraint • 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 leveltemplates.

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

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

  8. Open and Closed Templates • 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.

  9. Conformance Verbs • 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 fferentcourse • MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications

  10. Cardinality • The cardinality indicator (0..1, 1..1, 1..*, etc.) specifies the allowable occurrences within a document instance. The cardinality indicators are interpreted with the followngformat “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

  11. Vocabulary Conformance • 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 specified version of a value set, or DYNAMIC, meaning that they are bound to the most current version of the value set.

  12. Containment relationships • 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:2.16.840.1.113883.10.20.22.4.48) (CONF:8801). • Example of direct containment contstraint • SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.10.20.22.2.21" (CONF:7928)

  13. Null Flavor 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

  14. DataTypes • 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

  15. References • 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 2005. Ann Arbor, MI: Health Level Seven, Inc., 2005. • HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.1 - US Realm

More Related