1 Clinical Document Architecture (previously "Patient Record Architecture") HL7 Meeting St. Louis, Missouri September 13, 2000 Bob D olin, MD Kaiser Permanente.

Slides:



Advertisements
Similar presentations
Numbers Treasure Hunt Following each question, click on the answer. If correct, the next page will load with a graphic first – these can be used to check.
Advertisements

Scenario: EOT/EOT-R/COT Resident admitted March 10th Admitted for PT and OT following knee replacement for patient with CHF, COPD, shortness of breath.
Variations of the Turing Machine
3rd Annual Plex/2E Worldwide Users Conference 13A Batch Processing in 2E Jeffrey A. Welsh, STAR BASE Consulting, Inc. September 20, 2007.
AP STUDY SESSION 2.
1
Chapter 9 Structuring System Data Requirements
Chapter 7 System Models.
Copyright © 2003 Pearson Education, Inc. Slide 3-1 Created by Cheryl M. Hughes The Web Wizards Guide to XML by Cheryl M. Hughes.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
Copyright © 2003 Pearson Education, Inc. Slide 7-1 Created by Cheryl M. Hughes The Web Wizards Guide to XML by Cheryl M. Hughes.
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 4 Computing Platforms.
Processes and Operating Systems
September, 2005What IHE Delivers 1 CDA-based content integration profiles Philippe Lagouarde, Cegedim Co-chair Vendor, IHE-France.
1 Hyades Command Routing Message flow and data translation.
David Burdett May 11, 2004 Package Binding for WS CDL.
1 Introducing the Specifications of the Metro Ethernet Forum MEF 19 Abstract Test Suite for UNI Type 1 February 2008.
Prepared by: Workforce Enterprise Services For: The Illinois Department of Commerce and Economic Opportunity Bureau of Workforce Development ENTRY OF EMPLOYER.
Local Customization Chapter 2. Local Customization 2-2 Objectives Customization Considerations Types of Data Elements Location for Locally Defined Data.
Custom Services and Training Provider Details Chapter 4.
1 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt BlendsDigraphsShort.
1 Chapter 12 File Management Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and Design Principles,
Programming Language Concepts
1 Click here to End Presentation Software: Installation and Updates Internet Download CD release NACIS Updates.
Knowledge Extraction from Technical Documents Knowledge Extraction from Technical Documents *With first class-support for Feature Modeling Rehan Rauf,
Break Time Remaining 10:00.
1 Laying Out Pages with Tiles Source :
Turing Machines.
Table 12.1: Cash Flows to a Cash and Carry Trading Strategy.
PP Test Review Sections 6-1 to 6-6
User Friendly Price Book Maintenance A Family of Enhancements For iSeries 400 DMAS from Copyright I/O International, 2006, 2007, 2008, 2010 Skip Intro.
Microsoft Confidential. We look at the world... with our own eyes...
EIS Bridge Tool and Staging Tables September 1, 2009 Instructor: Way Poteat Slide: 1.
Outline Minimum Spanning Tree Maximal Flow Algorithm LP formulation 1.
© Copyright by Deitel & Associates, Inc. and Pearson Education Inc. All Rights Reserved. 1 Outline 24.1 Test-Driving the Ticket Information Application.
Exarte Bezoek aan de Mediacampus Bachelor in de grafische en digitale media April 2014.
Copyright © 2012, Elsevier Inc. All rights Reserved. 1 Chapter 7 Modeling Structure with Blocks.
 Copyright I/O International, 2013 Visit us at: A Feature Within from Item Class User Friendly Maintenance  Copyright.
Copyright © [2002]. Roger L. Costello. All Rights Reserved. 1 XML Schemas Reference Manual Roger L. Costello XML Technologies Course.
1 RA III - Regional Training Seminar on CLIMAT&CLIMAT TEMP Reporting Buenos Aires, Argentina, 25 – 27 October 2006 Status of observing programmes in RA.
1 © 2004, Cisco Systems, Inc. All rights reserved. CCNA 1 v3.1 Module 10 Routing Fundamentals and Subnets.
Adding Up In Chunks.
1 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt Synthetic.
: 3 00.
5 minutes.
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
1 hi at no doifpi me be go we of at be do go hi if me no of pi we Inorder Traversal Inorder traversal. n Visit the left subtree. n Visit the node. n Visit.
1 Let’s Recapitulate. 2 Regular Languages DFAs NFAs Regular Expressions Regular Grammars.
Types of selection structures
Speak Up for Safety Dr. Susan Strauss Harassment & Bullying Consultant November 9, 2012.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 12 View Design and Integration.
Chapter 12 Working with Forms Principles of Web Design, 4 th Edition.
Essential Cell Biology
Converting a Fraction to %
Clock will move after 1 minute
PSSA Preparation.
Chapter 11 Component-Level Design
Chapter 11 Creating Framed Layouts Principles of Web Design, 4 th Edition.
Chapter 13 Web Page Design Studio
Physics for Scientists & Engineers, 3rd Edition
Energy Generation in Mitochondria and Chlorplasts
Select a time to count down from the clock above
1.step PMIT start + initial project data input Concept Concept.
Know About E-CTLT Teachers Panel and working area.
Page 1 Orchard Harvest ™ LIS Find a Patient Training.
Introduction Peter Dolog dolog [at] cs [dot] aau [dot] dk Intelligent Web and Information Systems September 9, 2010.
1 Decidability continued…. 2 Theorem: For a recursively enumerable language it is undecidable to determine whether is finite Proof: We will reduce the.
Clinical Document Architecture. Outline History Introduction Levels Level One Structures.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Presentation transcript:

1 Clinical Document Architecture (previously "Patient Record Architecture") HL7 Meeting St. Louis, Missouri September 13, 2000 Bob D olin, MD Kaiser Permanente

2 Objectives Overview of August 2000 Clinical Document Architecture ballot proposal Introduction What is the CDA? The "A" in "CDA" Relationship of CDA to HL7 Messaging Standards Technical Specifications CDA Header CDA Body HL7 V3 Data Types Outline

3 The models and examples presented here are based on the August 2000 membership-level ballot draft. While the ballot did pass, there will be some minor edits before finalizing the standard. The examples displayed in the slides leave out required components and introduce modifications to illustrate a point. The examples in the other handout are complete and accurate. The exact representation of CDA instances is contingent on the outcome of the HL7 V3 data type DTD ballot. Disclaimer

4 Introduction Objectives Overview of August 2000 Clinical Document Architecture ballot proposal Introduction What is the CDA? The "A" in "CDA" Relationship of CDA to HL7 Messaging Standards Technical Specifications CDA Header CDA Body HL7 V3 Data Types

5 Introduction What is the CDA? The CDA is a document markup standard for the structure and semantics of exchanged "clinical documents". A clinical document is a documentation of observations and other services with the following characteristics: Persistence Stewardship Potential for authentication Wholeness Human readability A CDA document is a defined and complete information object that can exist outside of a message, and can include text, images, sounds, and other multimedia content.

6 Introduction What is the CDA? (cont.) Key aspects of the CDA: CDA documents are encoded in Extensible Markup Language (XML). CDA documents derive their meaning from the HL7 Reference Information Model (RIM ) and use HL7 V3 data types. The complete CDA will include a hierarchical set of document specifications. This hierarchy is referred to as an "architecture".

7 Introduction The "A" in "CDA" CDA Level One DTD CDA Level Two DTD Level Two :: Progress Note DTD Level Two :: Cardiology Progress Note DTD Level Two :: Endocrine Progress Note DTD Level Two :: Diabetes Progress Note DTD CDA Level Three DTD Level Three :: Progress Note DTD Level Three :: Cardiology Progress Note DTD Level Three :: Endocrine Progress Note DTD Level Three :: Diabetes Progress Note DTD CDA "Levels" - Quantum sets of specializations, to which further constraints can be applied.

8 Introduction The "A" in "CDA" (cont.) Level One :: RIM-derived document header. Body is largely structural, although codes can be inserted. Level Two :: HL7 Templates can constrain the general Level One DTD, resulting in Level Two DTDs. Level Three :: Clinical content can be marked up to the extent that it is modeled in the RIM. CDA Level One DTD* CDA Level Two DTD CDA Level Three DTD *The current spec only includes CDA Level One. Higher levels are under development.

9 Introduction The "A" in "CDA" (cont.) Level One minimizes the technical barriers to entry, while providing a "gentle introduction" to the HL7 RIM. Levels provide a migration pathway for iteratively adding greater markup to clinical documents. Levels establish baselines for conformance claims. CDA Level One DTD CDA Level Two DTD CDA Level Three DTD

10 HL7 V3 HL7 V2.x MSH|... EVN|... PID|... PV1|... TXA|... OBX|1|ED|... |... Introduction Relationship of CDA to HL7 Messaging Standards CDA documents are encapsulated as MIME packages within HL7 messages

11 Objectives Overview of August 2000 Clinical Document Architecture ballot proposal Introduction What is the CDA? The "A" in "CDA" Relationship of CDA to HL7 Messaging Standards Technical Specifications CDA Header CDA Body HL7 V3 Data Types Outline

12 Introduction CDA Header :: Specified in the CDA Header DTD; derived using the V3 Message Development process. CDA Level One Body :: Specified in the CDA Level One DTD; derived from document analysis, building on the modeling employed by document markup standards. HL7 V3 Data Types :: An XML implementation of the abstract data type specification used by both the CDA and the HL7 Version 3 message specifications. A CDA Level One document references the CDA Level One DTD (which references the CDA Header DTD, which references the HL7 V3 data type DTD). Technical Specifications

13 Introduction :: Vocabulary Domains Vocabulary domains represent value sets for coded CDA components. HL7-defined or drawn from HL7-recognized coding systems. CNE (Coded, No Extensions) vs. CWE (Coded, With Extensions) Vocabulary terms are transmitted via special data types (CS, CE, CD) Technical Specifications

14 Technical Specifications Vocabulary domain for (CWE) <!ATTLIST confidentiality_cd T NMTOKEN #FIXED "CE" %CE-attrib.list;...> <confidentiality_cd V="N" S=" " DN="normal"/>

15 Technical Specifications Vocabulary domain for (CNE) <!ELEMENT document_relationship.type_cd %CS-cont.model;> <!ATTLIST document_relationship.type_cd T NMTOKEN #FIXED "CS" V (APND|RPLC) #REQUIRED... >

16 CDA Header Overview The CDA Header is specified by the CDA Header DTD which is derived from a Hierarchical Description (HD), using a method that closely parallels the V3 Message Development Framework. There are four logical components of the CDA Header: 1. Document information; 2. Encounter data; 3. Service actors (such as providers); 4. Service targets (such as patients).

17... HL7 CDA <service_cd V="6298-8" S="LOINC" DN="POTASSIUM:SCNC:PT:BLD"/> HL7 V3 Message HL7 Reference Information Model CDA Header

18 Reference Information Model Header Information Model Hierarchical Description <!ELEMENT birth_dttm %TS-cont.model;> <!ATTLIST birth_dttm %TS-attrib.list; %common-atts; HL7-NAME CDATA #FIXED 'birth_dttm'> XML DTD subset of RIM tighten constraints linearization additional constraints algorithm CDA Header

19 HL7 RIM (MS Access or Rational Rose) CDA Header

20 CDA Header <document_type_cd V=" " S=" " DN="Consultation note"/>

21 CDA Header RIM 0.98 :: CDA Header Information Model

22 CDA Header Document information

23 CDA Header Encounter data

24 CDA Header Service actors

25 CDA Header Service targets

26 CDA Header encounter data service actors service targets document information

27 CDA Header XML element identification Every XML element within a CDA document has an optional identifier, which must be unique within the document. The identifier is an XML "ID" data type. <!ATTLIST Every_CDA_ELEMENT... ID ID #IMPLIED...>

28 CDA Header Document identification (,,, ) Every document has a required, globally-unique instance identifier,, an identifier that remains constant across all document revisions that derive from a common root,, and a version number,. Every document has a required document type code,. The externally-defined vocabulary domain for is drawn from LOINC.

29 CDA Header Document time stamps (,,,, ) Some temporal events can be represented as a specific point in time (indicated by "_dttm" and using the HL7 V3 TS data type), while other temporal events include time intervals (indicated by "_tmr" and using the HL7 V3 IVL_TS or GTS data type).

30 CDA Header Document relationships (, ) The CDA Header enables the explicit representation of the relationship between documents. A clinical document can append or replace another clinical document. Documents may be generated in response to one or more orders. The element points to fulfilled orders.

31 CDA Header Encounter data (,,,, ) Encounter data include a globally-unique identifier, the time of the encounter, a location, and an optional practice setting code, which is a categorization of the clinical setting (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) in which care is delivered.

32 CDA Header Service actors (,,,,,,, ) Service actors include those who authenticate the document, those intended to receive a copy of the document, document originators and transcriptionists, and health care providers who participated in the service(s) being documented. Service actors are capable of and accountable for their independent decisions.

33 CDA Header Service actors (cont.)

34 CDA Header Service targets (,, ) Service targets are physical entities, including living subjects and inanimate material, that are typically the object of services being documented. Service targets include the patient, other significant participants (such as family members), and those devices that may have originated portions of the document.

35 CDA Header Service targets (cont.)

36 Localization (, ) The CDA adds markup declarations that enable localization. The element is an optionally repeating, recursive element tacked on to the end of every content model. The "descriptor" attribute describes the element, and the value can be drawn from a local vocabulary domain. The "ignore" attribute tells the receiver to ignore just the local_header tag (ignore="markup"), or to ignore the local_header tag and all contained content (ignore="all"). The "render" attribute indicates how the sender would render the contents. The value can be drawn from a local vocabulary domain. CDA Header

37 Localization (cont.) CDA Header <!ELEMENT authenticator ( authenticator.type_cd, participation_tmr, signature_cd, person, local_header* )> <!ELEMENT local_header (#PCDATA | local_header | local_attr)* > <!ATTLIST local_header ignore (all | markup) "markup" descriptor CDATA #IMPLIED render CDATA #IMPLIED ID ID #IMPLIED xml:lang NMTOKEN #IMPLIED > <!ATTLIST local_attr name NMTOKEN #REQUIRED value CDATA #REQUIRED ID ID #IMPLIED xml:lang NMTOKEN #IMPLIED>

38 <document_type_cd V=" " S=" " DN="Consultation note"/>... extra stuff that is only used locally CDA Header Sample CDA document* * Note that the exact representation is contingent on the outcome of the HL7 V3 data type DTD ballot.

39 CDA Level One Body Overview The CDA Level One Body is comprised of sections or a single non-XML block. A section can contain "structures", nested section's, and codes. CDA structures contain "entries". Document analysis was used to articulate requirements for the CDA Level One Body. These are expressed in XML using industry-standard constructs. The structural components themselves are not part of RIM Where CDA entries are derivable from the RIM, they have an XML representation that follows the style used for the CDA Header.

40 CDA Level One Body Overview (cont.) CDA "structures" CDA "entries"

41 CDA Level One Body Shared XML Attributes These attributes are assigned to all XML elements in the CDA Level One Body. Their values are inherited by nested content, unless overridden. <!ATTLIST Every_CDA_Body_Element... ID ID #IMPLIED confidentiality IDREFS #IMPLIED originator IDREFS #IMPLIED xml:lang NMTOKEN #IMPLIED >

42 CDA Level One Body Non_xml body The CDA container represents a document body that is in some format other than XML. CDA's uses the HL7 V3 Encoded Data data type to reference data that is stored externally to the CDA Level One document (as opposed to encapsulating the data within the CDA document itself).

43 CDA Level One Body Captions The CDA is a label for a container. The element can occur in a,,,, or element. A contains plain text and may contain links, and can be coded using the element. The vocabulary domain for is externally-defined by LOINC.

44 CDA Level One Body CDA "structures" CDA "entries" CDA "structures" (,, )

45 CDA Level One Body CDA "structures" (cont.) Structures have optional captions. A contains CDA "entries". A contains one or more 's. An contains entries and nested structures. The CDA is a modification of the strict XHTML table model. In CDA Level One, any information can be presented as a table. The table markup is for presentation purposes only and, unlike a database table, does not possess meaningful field names.

46 CDA Level One Body CDA "structures" (cont.)

47 CDA Level One Body CDA "structures" CDA "entries" CDA "entries" (character data,,,,, )

48 CDA Level One Body Link The CDA is a generic referencing mechanism based on the HTML anchor tag. Multimedia that is part of the attestable content of the document requires the use of. Multimedia that is simply referenced should use. <!ATTLIST link_html name CDATA #IMPLIED href CDATA #IMPLIED rel CDATA #IMPLIED rev CDATA #IMPLIED title CDATA #IMPLIED >

49 CDA Level One Body Coded_entry The CDA uses the HL7 V3 Concept Descriptor data type to insert codes from HL7-recognized coding schemes into CDA documents. Where there are no suitable HL7-recognized codes available, locally-defined codes can be used. Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper.

50 CDA Level One Body Content The element nests recursively, enabling wrapping a string of text down to as small a chunk as desired. These elements can serve as anchors to be referenced by elements to indicate the original text that supports the use of a code. Asthma, with prior smoking history. Difficulty weaning off steroids. Will try gradual taper.

51 CDA Level One Body Observation_media The element, derived from the RIM Observation class, represents media that is logically part of a CDA document, but is stored outside the document and incorporated by reference (using the HL7 V3 Encoded Data data type). Erythematous rash, palmar surface, left index finger. <observation_media.value MT="image/jpeg"> Physical Exam Erythematous rash, palmar surface, left index finger.

52 CDA Level One Body Localization The implementation of localization in the CDA Level One Body using the element parallels the approach used in the CDA Header.

53 Objectives Overview of August 2000 Clinical Document Architecture ballot proposal Introduction What is the CDA? The "A" in "CDA" Relationship of CDA to HL7 Messaging Standards Technical Specifications CDA Header CDA Body HL7 V3 Data Types Outline