Clinical Document Architecture Care Record Summaries Liora Alschuler

  • Slides: 22
Download presentation
Clinical Document Architecture: Care Record Summaries Liora Alschuler alschuler. spinosa Co-chair, Structured Documents TC

Clinical Document Architecture: Care Record Summaries Liora Alschuler alschuler. spinosa Co-chair, Structured Documents TC Co-editor, CDA HL 7 Board of Directors Liora Alschuler liora@the-word-electric. com

Health Level Seven (HL 7. org) l l Standards Development Organization Developing standards for

Health Level Seven (HL 7. org) l l Standards Development Organization Developing standards for interoperability l l l l Patient care Public health Clinical trials Reimbursement HIPAA DSMO 20 years, 2000 members 26 international affiliates “A model community”: building standards to a single information model

CDA l l l Clinical Document Architecture ANSI/HL 7 CDA R 1. 0 -2000

CDA l l l Clinical Document Architecture ANSI/HL 7 CDA R 1. 0 -2000 CDA R 2. 0 to be published shortly created & maintained by HL 7 Structured Documents Technical Committee (SDTC) A specification for document exchange using l l XML, the HL 7 Reference Information Model (RIM) Version 3 methodology and vocabulary (SNOMED, ICD, local, …)

CDA: A Document Exchange Specification l l l l This is a CDA and

CDA: A Document Exchange Specification l l l l This is a CDA and this and this

CDA Release 2: Text + Observation <Section> <code="10153 -2" code. System="LOINC“> Past Medical History

CDA Release 2: Text + Observation <Section> <code="10153 -2" code. System="LOINC“> Past Medical History </code> <text>Patiënt met een voorgeschiedenis astma en hoge bloeddruk. Nu opgenomen in het ziekenhuis met een osteoartritis, rechter knie </text> <component 1> <context. Conduction. Ind value="TRUE"/> <Observation class. Code=“COND”> <code=”G-1001” code. System=”SNOMED” display. Name=”Prior dx”/> <value code=”D 1 -201 A 8” code. System=”SNOMED” display. Name=”Osteoarthritis”> <original. Text><reference value=”#a 3”/></original. Text> </value> <target. Site. Code code=”T-15720” code. System=”SNOMED” display. Name=”knee”> <qualifier> <name code=”G-C 220” code. System=”SNOMED” display. Name=”with laterality”/> <value code=”G-A 100” code. System=”SNOMED” display. Name=”right”/> </qualifier> </target. Site. Code> </Observation> </component 1> </Section>

CDA l l Widely implemented outside the US l most common application is transfer

CDA l l Widely implemented outside the US l most common application is transfer of care (Germany, Greece, Finland, Japan, Korea, Canada, Argentina) l CDA transfer of care pilot in British Columbia (see CDA Implementation Guide for Vancouver Island Health Authority on SDTC web page) In the US l CDA considered for HIPAA Claims Attachments (as payload in X 12 message) l Mayo: ramping up to 50, 000 notes/week: investment in information as capital asset l Columbia-Presbyterian: text and fielded data entry with natural language processing and controlled vocabulary l Tricare Management Activity (Do. D TMA) will implement CDA attachments supporting referrals management

CDA l Specification is generic l l l Human-readable “narrative block” l l Any

CDA l Specification is generic l l l Human-readable “narrative block” l l Any document type Any clinical content Defines legal content Displays with simple style sheet Required Machine-readable “clinical statements” l l l Drives automated extraction, decision support…. Uses HL 7 RIM, controlled vocabulary Optional

CDA Body: Human-readable l l l paragraph list table caption required link content revise

CDA Body: Human-readable l l l paragraph list table caption required link content revise (delete/insert) subscript/superscript special characters (e. g. , symbols, Greek letters) in Unicode emphasis line break render. Multi. Media (non-XML graphics, video…)

CDA Body: Machine Processible l Clinical statement l l l l l Observation Procedure

CDA Body: Machine Processible l Clinical statement l l l l l Observation Procedure Organizer Supply Encounter Substance Administration Observation Media Region Of Interest Act Optional

Creating CDA Document Types l l Add constraints to generic specification Designed for a

Creating CDA Document Types l l Add constraints to generic specification Designed for a community of users l l l Can be further specialized for closer communities l l Scope: US Clinical applications: transfer of care Scope: Massachusetts Clinical application: pediatric Document coded to requirements of the document type Still valid against generic schema and specification

Validating CDA document types. x. Path, . xsl, prose CRS Schematron. xsd. xml <Section

Validating CDA document types. x. Path, . xsl, prose CRS Schematron. xsd. xml <Section code=Plan> XPath validation of Implementation Guide requirements Validates against generic schema

CDA & Incremental Semantic Interoperability l l Patients transfer between providers with vastly different

CDA & Incremental Semantic Interoperability l l Patients transfer between providers with vastly different IT capabilities Need to support information requirements at point of care l l Full EMR adoption… not predictable based on past adoption curves Assume gradually rising, but still heterogeneous levels of sophistication l l Data formats (imaging, text, XML) Coded data (metadata, basic structure, simple results reporting, complex clinical statements)

CDA & Incremental Semantic Interoperability l Level 1: standardizes just the metadata (header) required

CDA & Incremental Semantic Interoperability l Level 1: standardizes just the metadata (header) required for management l l Query, retrieve, file, track Full clinical content, but no coding requirements Target authoring: any (including imaging, fax) Level 2: Level 1 + standard structures (section, list, table titles) l l l Clinical domain-specific Supports basic extraction, summary Target authoring: dictation, electronic text with template or minimal consistent structure

CDA & Incremental Semantic Interoperability l l l Level 1: just the metadata (header)

CDA & Incremental Semantic Interoperability l l l Level 1: just the metadata (header) Level 2: Level 1 + structures Level 3: Level 2 + clinical statements (coded for machine processing) l l Expressive to full extent of Reference Information Model and vocabulary Target authoring: EMR, forms entry, natural language processing Many actual levels between these benchmarks A document can always exceed the required level of encoding

Clinical content invariant, regardless of level Level 1: XML, no codes Level 1: non-XML

Clinical content invariant, regardless of level Level 1: XML, no codes Level 1: non-XML body Level 2: XML, section codes

Let’s take a look…

Let’s take a look…

Implementation Guides constrain coding Identical required section coding l l Not presentation Not narrative

Implementation Guides constrain coding Identical required section coding l l Not presentation Not narrative style Different optional narrative coding Two styles of presentation, one Implementation Guide

Implementation Guides constrain coding l l l Not presentation Not narrative style Can impose

Implementation Guides constrain coding l l l Not presentation Not narrative style Can impose uniform presentation, style l l l but just for presentation the coding drives machine processing Distinction becomes more significant with Level 3

Current ballots & more… 1 3 4 2

Current ballots & more… 1 3 4 2

Care Record Summary Implementation Guides for CDA Release 2 April 13, 2005 Keith W.

Care Record Summary Implementation Guides for CDA Release 2 April 13, 2005 Keith W. Boone keith. boone@dictaphone. com Dictaphone Corporation Clinical Language Understanding

Thank you! Questions?

Thank you! Questions?