HL 7 Clinical Document Architecture Release 2 Haitham

  • Slides: 18
Download presentation
HL 7 Clinical Document Architecture, Release 2 Haitham KUSSAIBI 1

HL 7 Clinical Document Architecture, Release 2 Haitham KUSSAIBI 1

CDA R 2 Journal: Journal of the American Medical Informatics Association Ref: 2006; 13(1):

CDA R 2 Journal: Journal of the American Medical Informatics Association Ref: 2006; 13(1): 30 -39. Authors: ROBERT H. DOLIN, MD, LIORA ALSCHULER, SANDY BOYER, BSP, CALVIN BEEBE, FRED M. BEHLEN, PHD, PAUL V. BIRON, AMNON SHABO (SHVO), PHD 2

Article objetive Introduction and overview to CDA R 2 For medical informaticians who do

Article objetive Introduction and overview to CDA R 2 For medical informaticians who do not have significant familiarity with HL 7 Version 3. • Introduce the approach and objectives used in the creation of this standard. • An overview of the standard, not sufficient for implementation but sufficiently detailed to enable the reader to understand the scope and contents of the standard. 3

Introduction CDA is an ANSI–approved HL 7 Standard. A CDA document has a header

Introduction CDA is an ANSI–approved HL 7 Standard. A CDA document has a header and a body. The header identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. The body contains the clinical report. It can be either an unstructured blob or a structured markup. 4

Introduction-2 CDA R 1 November 2000 CDA R 2 May 2005 Only header is

Introduction-2 CDA R 1 November 2000 CDA R 2 May 2005 Only header is RIM derived Both header and body are RIM derived CDA R 1 > CDA R 2? Encode the narrative clinical statements found in clinical reports which created on different information systems, to enable comparison of their content. 5

CDA R 2 Overview • • • The HL 7 CDA is a document

CDA R 2 Overview • • • The HL 7 CDA is a document markup standard that specifies the structure and semantics of a clinical document (such as a discharge summary, progress note, procedure report) for the purpose of exchange. A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content. It can be transferred within a message, and can exist independently. 6

CDA R 2 Overview-2 • • • CDA documents are encoded in Extensible Markup

CDA R 2 Overview-2 • • • CDA documents are encoded in Extensible Markup Language (XML). They derive their machine processable meaning from the HL 7 RIM and use the HL 7 Version 3 data types. The RIM and the V 3 data types provide a powerful mechanism for enabling CDA’s incorporation of concepts from standard coding systems such as (SNOMED CT) and (LOINC). 7

Major Components of a CDA Document -Clinical. Document element. -Header and Body Figure 1

Major Components of a CDA Document -Clinical. Document element. -Header and Body Figure 1 shows a structured body, which is wrapped by the <structured. Body> element and is divided up into recursively nestable document sections. 8

Major Components of a CDA Document-2 • Each section can contain a ‘‘narrative block’’,

Major Components of a CDA Document-2 • Each section can contain a ‘‘narrative block’’, entries and external references. • The narrative block is a critical component of CDA and must contain the human readable content. It contains XML markup that is similar to XHTML. • CDA entries (optional) represent structured content provided for further computer processing. It is derived from classes in the RIM that enable formal representation of clinical statements. 9

CDA Documents and HL 7 Messages Difference: • Messages: transient, trigger based, and nonpersistent.

CDA Documents and HL 7 Messages Difference: • Messages: transient, trigger based, and nonpersistent. • Clinical documents: have persistence, wholeness, and clinician authentication and are human readable. Transferrings Rules: • CDA documents can be exchanged in HL 7 messages or other transport solutions. • All components can be exchanged as a unit (package). • Metadata about the CDA instance needed for document management must be included. • Content needing to be rendered or additional files associated with a CDA document can be included. 10

CDA Extensibility • When local semantics have no corresponding representation in the CDA, locally

CDA Extensibility • When local semantics have no corresponding representation in the CDA, locally defined markup can be used to extend it. • CDA provide a clean and standard mechanism for tagging them. 11

CDA R 2 Technical Artifacts (Object Model) HL 7 DF governs the process used

CDA R 2 Technical Artifacts (Object Model) HL 7 DF governs the process used to derive the CDAR 2 object model from the RIM. HL 7 XML Implementation Technology Specification defines the XML conventions and algorithmically converts the object model into an XML schema. 12

HL 7 V 3 Data Types and vocabulary Data types: • Define the structural

HL 7 V 3 Data Types and vocabulary Data types: • Define the structural format of the data carried within an RIM class’s attribute and influence the set of allowable values an attribute may assume. • Ex. GTS (>complex time expression), CD(>postcoordination of codes = codes combinig to create a more specific concept) Vocabulary: • Several CDA components are designed to carry concepts drawn from HL 7 -recognized coding systems such as LOINC or SNOMED CT. • Their value sets specify allowable codes, and a coding strength of (CNE), or (CWE). 13

CDA R 2 Object Model Technical diagram of the CDA specification. RIM classes represented

CDA R 2 Object Model Technical diagram of the CDA specification. RIM classes represented by HL 7 conventions. (Act: action, Participation: context, Entity: actors, Role, Act. Relationship, Role. Link) Every Act has a mandatory mood. Code attribute, which distinguishes it as a factual statement (‘‘EVN’’, ‘‘DEF’’). An Act can have zero to many Participations, each played by an Entity in some Role. A Role is a relationship between two Entities, the one playing it, and the other who recognizes it. 14

CDA R 2 Object Model - Header • Set the context for the document

CDA R 2 Object Model - Header • Set the context for the document as a whole. • Enable clinical document exchange across and within institutions. • Facilitate clinical document management. • Facilitate compilation of an individual patient’s clinical documents into a lifetime electronic patient record. The entry point into the CDA model is the Clinical. Document class that contains various attributes (id, code, …). Many participants (such as authenticator, author, encounter Participant, legal. Authenticator, and performer). 15

CDA R 2 Object Model - Body Contains the clinical report and can be

CDA R 2 Object Model - Body Contains the clinical report and can be either an unstructured blob, represented by the Non. XMLBody class (for those applications that can do no more than simply wrap an existing non-XML document with the CDA Header), or a structured markup, represented by the Structured. Body class (which contains one or more Section components). • • Section class contains various attributes. Has participants some of them modeled as a ‘‘shadow’’ (i. e. , exact copy) of a participant made in otherwise in the document. Has relationship like the entry which leads to the clinical statement portion of the model. Dotted clinical Statement box represents a choice structure, which contains specializations of the Act class. 16

Future Directions The lack of a global terminology solution make possible to express a

Future Directions The lack of a global terminology solution make possible to express a clinical statement in many ways. Thus, the primary direction for the future will be to manage this potential for variability, by constraining transformations between the allowable representations. Three activities within HL 7 focusing on this next step include: HL 7 Templates. HL 7 Clinical Statement Model. HL 7 Term. Info project. All of which will complement CDA R 2. 17

Conclusion CDA R 2 represents a stable platform for the exchange of clinical documents.

Conclusion CDA R 2 represents a stable platform for the exchange of clinical documents. The underlying design: Minimizes the technical barriers to adoption (easy to implement). Providing a migration pathway toward progressively richer computer processable content. 18