Transcript Use of Patient Care Data for Clinical Research

Single Source: Starbrite Trial
http://www.idealliance.org/proceedings/xml03/slides/alschuler&bain/alschuler&bain.ppt
Traditional Remedies for
Clinical Trials and Healthcare
Information:
Patient Care Data in Support of
Clinical Research
Liora Alschuler, Landen Bain,
Rebecca Kush, PhD, Meredith Nahm,
Roberto Ruggeri
December, 2003
Single Source: Starbrite Trial
• Liora Alschuler
– alschuler.spinosa, consultants
– Co-chair HL7 Structured Documents TC & Marketing
Committee
– Co-editor, Clinical Document Architecture (ANSI/HL7 CDA)
– [email protected]
• Landen Bain
– CDISC Board
– Co-chair HL7 Marketing Committee
• Rebecca Kush, PhD
– Founder and President, CDISC
• Meredith Nahm
– Manager, Clinical Data Management, Duke Clinical Research
Institute
• Roberto Ruggeri
– Microsoft Healthcare Evangelist
Single Source: Starbrite Trial
The Challenge: Integrate
Patient Care and Clinical Research
Data
Patient Care World
Clinical Research World
Electronic
Medical Record
The Void
Single Source: Starbrite Trial
Clinical Research World
Patient Care World
-Multiple data sources and data types.
-HL7 v2.x a pervasive standard.
-Electronic medical records assembled
from multiple sources.
-Carefully controlled data.
-Each trial’s data independent.
-CDISC the emerging standard.
-Data flow from sites to CROs to
sponsors to FDA.
Electronic
Medical Record
Connectors
-Standards: HL7’s CDA;
CDISC’s ODM.
-Technology: XML
-Single Source document
approach
Single Source: Starbrite Trial
Impact on Healthcare and Drug
Information
• Steve Ruberg, Applied Clinical Trials,
February, 2002:
“The essential kernal of the whole clinical
development processs is the data… Thus,
without a data-centric approach to
developing any e-clinical solution, we are
unlikely to be fully successful. The data is
the foundation on which we build our
entire effort.”
Single Source: Starbrite Trial
Business Drivers
• Need to shorten cycle time of drug
development:
– Drug company R & D is too high;
– Government pressure.
• Drive for personalized, prospective
medicine.
• Patient and investigator convenience.
• HHS desire to link research data to
physician behavior.
• Rationalize provider document workflow.
Single Source: Starbrite Trial
Project opportunities
• Starbright – a small clinical trial at
Duke’s Clinical Research Institute
(DCRI)
– DCRI’s Data Mgt and IT groups are
cooperating with the trial’s investigator.
– Goal is to capture both patient care and
clinical trial data at the front end, and
populate both data streams, using CDA
and CDISC standards
Single Source: Starbrite Trial
Obstacles
• Two different world views between
patient care and clinical research:
– Bio-statisticians want perfect data;
– Clinicians want everything they can grab.
• Lack of a structured vocabulary.
• Privacy concerns.
• CDISC, HL7 divergent data models
Single Source: Starbrite Trial
Starbrite Trial
• Participants:
–
–
–
–
CDISC
Duke Clinic
Duke Clinical Research Institute (DCRI)
investigatiors
• Liora Alschuler, Landen Bain, Rebecca Kush,
PhD, Meredith Nahm, Steve Woody, Sally
Cassells, Richard Low, John Madden, MD
– technology partners, Microsoft (primary),
Arbortext, Topsail, Sentillion
Single Source: Starbrite Trial
Clinical Data Interchange
Standards Consortium
CDISC is an open, multidisciplinary, non-profit
organization committed to the development of
worldwide industry standards to support the
electronic acquisition, exchange, submission and
archiving of clinical trials data and metadata for
medical and biopharmaceutical product
development.
The CDISC mission is to lead the development of
global, vendor-neutral, platform-independent
standards to improve data quality and accelerate
product development in our industry.
Single Source: Starbrite Trial
CDISC
• Formed in 1997 as a volunteer group
• As of 2000, funded as non-profit
organization
• Now supported by >140 corporate
members: pharmaceutical companies;
biotech companies; CROs; technology
providers
• CDISC Groups now growing in Japan,
Europe; initiated in India
• Standards developed through consensusbased approach by teams of volunteers;
public reviews
• No fee for use of the standards; freely
available on CDISC website (www.cdisc.org)
Single Source: Starbrite Trial
ICH and CDISC
• CDISC developed standards for submission of
clinical trial data, which was beyond the scope
of ICH since only FDA requires that data be
included in regulatory submissions at this time.
• The current plan is for FDA to reference the
HL7-approved CDISC Submission Data
Standards (SDS) as a specification in their
FDA Guidance on the implementation of the
ICH electronic Common Technical Document
(eCTD).
Single Source: Starbrite Trial
Health Level Seven
• ANSI-accredited Standards Development
Organization
• Established 1987
• Approx. 2000 members
• 23 affiliates in Europe, Asia-Pacific,
South America, Africa
HL7
Single Source: Starbrite Trial
• Working group meetings
– 3 times each year
– about 500 attendees
Board of Directors
Business affairs
Elected
Technical Steering Committee
Technical affairs
Appointed officers plus chairs
of the committees & SIGs
The Working Group
The working HL7
Any member can register
for any committee or SIG
Technical Committees
Create normative specifications
or chapters in the standard
Special Interest Groups
Collaborate in area of interest to
contribute to the work of the TCs
The Membership
"real"
The
HL7
Any member can register
for any committee or SIG
Single Source: Starbrite Trial
a few of the HL7 TCs
•
•
•
•
Modeling & Methodology
Patient Care
Orders & Observations
Structured Documents: Clinical
Document Architecture (CDA, SPL)
• RCRIM: Regulated Clinical Research
Information Management
• CCOW: Context Management
Single Source: Starbrite Trial
a few of the HL7 SIGs
•
•
•
•
•
•
•
XML
Genomics
Clinical Guidelines
Electronic Health Record
JAVA
Imaging Integration
Medication
Single Source: Starbrite Trial
HL7 Standards
• Version 2.x
– used worldwide, 90% of US hospitals
– “pipe & hat”: HL7-proprietary, EDI-like
PID||2247^^^Primary|098018500^^^MRN||FIX
-INTF^PAT||19650618|Female|
• Version 2.XML
– a normative XML encoding for V2
<PatientGroup>
- <PID PID07_DateOfBirth="19650618"
PID08_Sex="Female"
Single Source: Starbrite Trial
HL7 Standards
• Version 3
– based on Reference Information Model
(RIM)
– technology independent: so far,
developing XML schemas, JAVA API
• RCRIM/CDISC lab reporting is a V3
draft standard, as is SPL
• First normative V3 spec was CDA
Single Source: Starbrite Trial
Single Source: how is it
different?
• eSource & electronic data capture (EDC)
–
–
–
–
redundant with creation of clinic note
full burden lies on investigator
require that information reside in EMR
proprietary data formats
• CDA & CDISC in “single-source”
– capture trial data, merge it into clinic note (reuse)
– works with current technology, workflow (EMR
optional destination, not required)
– open, non-proprietary data formats
– XML bridging disparate data models
Single Source: Starbrite Trial
CDA & CDISC in Starbrite Trial
Manual creation and re-entry of CRF
HIS
lab, ADT,
meds,
source
documents
LIS
validation

display

db
manual
entry to
CRF
CLINIC
re-key CRF
CRO
Current
processes
(dual
source)
HIS
lab, ADT,
meds,
source
documents
LIS


display
dictate
chart note
Redundant creation of chart note
Single Source: Starbrite Trial
CDA & CDISC in Starbrite Trial
Merged workflow: clinical trial data
captured in initial CDA, re-used in
chart note
HIS
lab, ADT,
meds,
source
documents
LIS

PDF
CDA(1)
display

ODM
eCRF
db
Proposed
processes
(single
source)
validation
CDA(2)
complete
chart note
CLINIC
CRO
Single Source: Starbrite Trial
CDA & CDISC in Starbrite Trial
• features:
– contributes to patient chart, not the
reverse, optimizes clinical workflow
– no requirement to create/extract from
EMR
– fewer privacy and regulatory issues
– can be driven from electronic protocol
– uses HL7 CDA and CDISC ODM
Single Source: Starbrite Trial
CDA & CDISC in Starbrite Trial
• System features/requirements:
•
•
•
•
multi-stage, incremental document creation
optimal re-use (minimal redundant entry)
minimal change to current workflow
create both ODM-compliant XML for trials
and CDA-compliant XML for clinical records,
mapping between ODM.xml and CDA.xml
• low cost
• rapid development
• optimal use of technology partners, off-theshelf technology
Single Source: Starbrite Trial
XML-encoded information
• With a few simple tags, and controlled
vocabulary, XML can describe anything
• but…
• the tags need to be defined:
<orderNum> : HL7: order placed
<orderNum> : CDISC: visit sequence
Single Source: Starbrite Trial
CDA
• Clinical Document Architecture
• ANSI/HL7 CDA R1.0-2000
• first certified XML spec for
healthcare
• first balloted portion of HL7’s “V3”
• first RIM-based specification
• created & maintained by HL7
Structured Documents Technical
Committee (SDTC)
Single Source: Starbrite Trial
CDA: scope
• The scope of the CDA is the
standardization of clinical documents
for exchange.
• CDA enables, but does not constrain:
–
–
–
–
–
authoring
document management
storage
distribution
display
Single Source: Starbrite Trial
CDA: Release 1.0
• priority is patient care, other
applications facilitated
• minimize technical barriers to
implementation
• promote longevity of clinical records
• scoped by exchange, independent of
transfer or storage
• enable policy-makers to control
information requirements
Single Source: Starbrite Trial
What can you do
Applications of the CDA…or
with a few tags?
• access/portability/exchange
– query/locate by patient, provider, practioner,
setting, encounter, date
• integration
– multiple transcription systems
– with EHR records
• re-use/derivative data
– summaries
– billing
Single Source: Starbrite Trial
•
•
•
•
•
•
CDA: Major Implementations
PICNIC (European Union)
SCIPHOX (Germany)
HYGEIAnet/WebOnColl (Greece)
NHS South Staffordshire (United Kingdom)
Aluetietojärjestelmä (Finland)
MERIT-9 (Japan)
• e-Claims Supporting Doc Arch (Canada);
HIPAA Claims Attachments (US, proposed)
• Mayo Clinic (US)
• Buenos Aires project (Argentina)
• Dalhousie U, QEII Health Sci Ctr (Canada)
Single Source: Starbrite Trial
The CDA document defined
CDA Release 2 (draft), section 2.1:
A clinical document ... has the following characteristics:
 Persistence
 Stewardship
 Potential for authentication
 Context
 Wholeness
 Human readability
“Context - Contents of a clinical document share a
common context unless all or part of that context is
overridden or nullified.”
(material in blue is quoted from the
Clinical Document Architecture Release 1.0)
Single Source: Starbrite Trial
Requirements for a universal
clinical document
• Span full range of technical
sophistication
• Minimal constraint on content
• Makes all types of information human
readable and, to the greatest extent
possible, also machine processible
Single Source: Starbrite Trial
CDA::Readability
• CDA documents are “human readable” =
– This principle means that CDA documents are
human readable using:
a) widely-available and commonly deployed XMLaware browsers and print drivers and
b) a generic CDA style sheet written in a
standard style sheet language.
• CDA documents are also “machine
processable” to the degree that markup has
been added
– required markup provides initial functionality
– optional markup can augment processing
XML-encoded info in CDA
Single Source: Starbrite Trial
<Section>
<code code="10123-x" codeSystem="LOINC">Allergies and Adverse
Reactions</code>
<text>
<list>
<item><content>Penicillin - Hives</content></item>
</list>
</text>
<component>
<Observation>
<code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/>
<value xsi:type="CD" code="DF-10074" codeSystem="SNOMED"
human readable
machine processible
displayName="Allergy to penicillin"/>
<pertinentInformation typeCode="MFST">
<Observation>
<code code="G-1001" codeSystem="SNOMED" displayName="Prior dx"/
<value xsi:type="CD" code="D0-00165"
codeSystem="SNOMED" displayName="Hives"/>
</Observation>
CDA Release 2.0: Draft
Single Source: Starbrite Trial
CDISC ODM
• Operational Data Model
– ver. 1.1, April, 2002
– www.CDISC.org
• Defined by set of XML DTDs
• A database insertion schema
Single Source: Starbrite Trial
CDISC ODM
• The technical focus in the development of
ODM 1.0 was the definition of structures
to represent the three major information
components relating to a clinical trial:
– clinical study metadata (item definitions and
protocol)
– clinical study administrative data (users and
access privileges)
– clinical study data (complete record of patient
data and audit trail)
Single Source: Starbrite Trial
CDISC ODM
• Study allows representation of more than one
study in a single file
• AdminData includes information about the users
of the system, the clinical sites involved in the
study, and associated security information
• ReferenceData provides information relevant to
the interpretation of data that is not necessarily
study specific, such as lab normal ranges
• ClinicalData contains the actual data item values
associated with each study.
Single Source: Starbrite Trial
CDA::ODM
• XML drives
presentation
(stylesheet)
• Model-based
• Standard
vocabulary
• Distinct
– Metadata
– Identifiers
– Datatypes
• Presentation not
relevant (has
link to pdf)
• Stand-alone
• Private
vocabulary
• Distinct
– Metadata
– Identifiers
– Datatypes
Single Source: Starbrite Trial
Use of ODM & CDA in Singlesource
CDA
Initiate
document
Complete
studyrequired
data
entry
• Why not ODM2CDA?
– CDA
•
•
•
•
Comprehensive
General
Human readable
Defined by abstract
data model and
controlled vocabulary
Complete
data
entry for
patient
chart
Finalize,
sign and
archive
ODM
Clinical
trial
manage
ment
SDSinODM/
define.XML
Clinical
document
repository
(EHR)
FDA
BNPDATA (TYPE 4)
F
DOMAIN <V:2> = ‘BD’
Single Source: Starbrite Trial
BDDTM <DATE>
BDDY <V:25>
BDTEST <STBNP>
BDTESTCD (derived) <V:8>
BDSEQ <I:1>
BDORRES <F:9:3>
CDSEQ <I:1>
BDORRESU <V:8> = ‘pcg/mL’
CDDY = BNPDATA.BDDY
CDDTM = BNPDATA.BDDTM
CDTEST <V:40> = ‘ Most Recent Target Congestion Score’
ESSEQ <I:1>
BDBNDTM <DATE>
CDATDTM <DATE>
CDTESTCD <V:8> = ‘CONGSCOR’
CDORRES <I:3>
ESDTM = BNPDATA.BDDTM
ESDY = BNPDATA.BDDY
ESTEST <STSUMM>
ESTESTCD (derived) <V:8>
ENDPOINT (TYPE 4) F
DOMAIN <V:2> = ‘ES’
ESPATADJ <I:2>
ESPATNT <ZYES>
ESORRES <C_NY>
CSDATA (TYPE 1) F
DOMAIN <V:2> = ‘CD’
ESCLNADJ <I:2>
ESCLINCN <ZYES>
ESHSPADM <I:2>
ES1ADTM <DATE>
VSSEQ <I:1>
VSDTM = BNPDATA.BDDTM
VSDY = BNPDATA.BDDY
VSSEQ = 1
VSSEQ = 2
VSSEQ = 7
ES2ADTM <DATE>
VSTEST <STTST>
VSTESTCD (derived) = <V:8>
VSSEQ = 4
VSSEQ = 3
VSSEQ = 5
VSORRES <F:9:3>
VSSEQ = 6
VSORRESU <STUNIT>
VSDY = BNPDATA.BDDY
CPDTM = BNPDATA.BDDTM
CPFLUID <ZYES>
CPHYPOVL <ZYES>
CPHYPERK <ZYES>
CPHYPOKA <ZYES>
CLINDATA (TYPE 4)
DOMAIN <V:2> = ‘VS’
VSPOS (derived) <V:8>
CLINPROB (TYPE 4) F
CPBUNCRT <ZYES>
CPNOPROB <ZYES>
DOMAIN <V:2> = ‘CP
CPOTH <ZYES>
CPRSOTH <V:200>
CSTEST <STSCOR>
CSTESTCD (derived) <V:8>
Single Source: Starbrite Trial
CCSCORE (TYPE 4)
CSSEQ <I:1>
DOMAIN <V:2> = CS
CSORRES <I:3>
ADSEQ <I:1>
CSDTM = BNPDATA.BDDTM
CSDY = BNPDATA.BDDY
ADDTM = BNPDATA.BDDTM
ADDY = BNPDATA.ADDY
ADTEST <STCLND>
ADDDATA (TYPE 4) PS F
DOMAIN <V:2> = AD
ADORRES <C_NY>
ADTESTCD <V:8>
NSTEST <STSTRT>
NSRSOTH <V:200>
NSSEQ <I:1>
DCSEQ <I:1>
F
NSORRES <C_NY>
NSTESTCD <V:8>
NEWSTRAT (TYPE 4)
DOMAIN <V:2> = NS
F
DELVCARE (TYPE 4) F
DCTEST <STCLIN>
DCORRES <V:25>
DCORRESU (derived) <V:8>
DCFLUID <ZYES>
DCFLEXDR <ZYES>
DCSALT <ZYES>
DCSMOKE <ZYES>
IVSEQ <I:1>
DOMAIN <V:2> = DC
DCWEIGHT <ZYES>
DCHTMEDS <ZYES>
IVDT = TIMELINE.TLCLDT
IVTEST <STINTV>
IVORRES <C_NY>
INTRVENT (TYPE 4)
DOMAIN <V:2> = IV
IVMEDOTH <V:200>
IVNONOTH <V:200>
F
Single Source: Starbrite Trial
Five sample data elements
•
•
•
•
•
BNP Data
Endpoint Summary
Weight
Orthopnea
Weight gain
Single Source: Starbrite Trial
Single Source: Starbrite Trial
Section
Endpoint
summary
Data element
Since last contact,
were diuretics
adjusted?
Coding
ID only
<section>
<code code="Endpoint Summary" codeSystem="DukeClinic"
codeSystemName="Starbrite" />
- <text>
- <paragraph>
- <content ID="S4">
Since the last contact, were diuretics adjusted?
<content ID="S4.1">No</content>
</content>
</paragraph>
- <ItemGroupData ItemGroupOID="CDA2ODM.IG.ENDPOINT" ItemGroupRepeatKey="1"
TransactionType="Insert">
<ItemData ItemOID="CDA2ODM.ID.ESSEQ" Value="1" />
<ItemData ItemOID="CDA2ODM.ID.ESTEST" Value="1" />
<ItemData ItemOID="CDA2ODM.ID.ESORRES" Value="N" />
Single Source: Starbrite Trial
CDA
Duke
Clinical
Document
Repository

Transformation

Sentillion

Starbrite Clinical
Document Management
Initial Architecture
Starbrite
Document
management
Microsoft InfoPath
XML/Office 2003

Clinic data input
Inbox
TopSail
Integration


Microsoft Word
XML/Office 2003
Inbox transcription
workstation

to DCRI as
ODM.XML
Arbortext


Clinic workstation:
‘Browser’ and Starbrite
Publisher
1) Create new record for each visit: contains
visit-specific and templated information
2) Trial data input: nurse and physician,
incremental, real-time data integrity checks
3) Trial data completion: First CDA complete,
trial data (eCRF) extracted, transformed to
ODM.
4) Chart data creation: physician: pre-populate
chart CDA using trial data, “cut & paste” from
other records
5) complete note using voice interface to
transcription system
6) review, sign
and export
Single Source: Starbrite Trial
How to automate translation?
Submissions
XML
• eProtocol
dictates:
HL7XML
Operations
XML
–
–
–
–
Identifiers
Vocabulary
Extensibility
Constraints on
source XML
– Constraints on
target XML
Single Source: Starbrite Trial
CDA & CDISC in Starbrite Trial
• Status, October, 2003:
– preliminary technical design and
information analysis complete
– information design, in progress: Liora
Alschuler, Sally Cassells (Lincoln
Technologies, CDISC) completing data
CDA/ODM data mapping
– technical implementation: kick-off
meeting October 14, Durham, NC
(attending: Microsoft, Arbortext,
Topsail, DCRI)
– project pilot in place Q1, 2004
Single Source: Starbrite Trial
Single-source: beyond
Starbrite
• Next steps:
– Design and prototype a general solution
– Expand scope: integrate with standardsbased electronic protocol
– Implement at one or more additional
sites
• Establish base of industry
partnerships to sustain second stage
design, testing, implementation
Content and Interoperability
Standards Panel:
HL7 Clinical Document Architecture
(CDA::CCR::CCD)
June 9, 2006
Liora Alschuler
http://www.ahima.org/meetings/ltc/documents/Alschuler_HITinLTCPanel.June06.rev.ppt
About me
•Liora Alschuler
–Consultant, Alschuler Associates, LLC
•Tricare Management Activity, Department of Defense, Enterprise
Wide Referrals & Authorizations; Documents, Files, Images (DFI)
•Subcontractor, HITSP Standards Harmonization
•Industry-leading PHR, EMR and RHIO solution vendors
–Co-editor, CDA
–Co-chair HL7 Structured Documents TC
–Co-author, CDA & CRS Quick Start Guides
–Member, HL7 Board of Directors
–HL7 IHE Liaison
–past Chair, KEG & XML SIG & HL7 Marketing Committee
–Author ABCD... SGML: A Managers Guide to Structured
Information, 1995
–www.AlschulerAssociates.com , [email protected]
49
Healthcare IT 101
• Largely a failed endeavor
• IOM perspective
– Institute of Medicine, To Err Is Human
– 98,000 preventable deaths each year
• MOM perspective
– Post discharge
– What meds?
– Office visit: no value
• Problems known
• Why not fixed?
50
Outline
•
•
•
•
•
HL7
CDA
CDA for exchange networks
CDA+CCR=CCD
Summary, Resources & Questions
51
Health Level Seven (HL7.org)
• Standards Development Organization
• Developing standards for interoperability
–
–
–
–
•
•
•
•
Patient care
Public health
Clinical trials
Reimbursement
HIPAA DSMO
20 years, 2000 members
30+ international affiliates
“A model community”: building standards to
a single information model
52
Committees & Special Interest Groups
















Anatomic Pathology
Anesthesia
Architecture Review
Board**
Arden Syntax
Attachments
Cardiology
Common Message
Element Types***
CCOW*
Clinical Decision
Support*
Clinical Genomics
Clinical Guidelines
Community Based
Health Services
Conformance
Infrastructure &
Messaging*
Education**
Electronic Health
Records*



















Electronic Services**
Emergency Dept.
Financial Management*
Government Projects (US)
Imaging Integration
Implementation**
International Affiliates**
Java
Laboratory
Health Care Devices
Marketing**
Medical Records/
Information Management*
Modeling & Methodology*
Orders & Observations*
Organization Review**
Outreach for Clinical
Research*
Patient Administration*
Patient Care*
Patient Safety







Pediatric Data Standards
Personnel Management*
Pharmacy
Process Improvement**
Public Health &
Emergency Response
Publishing**
Regulated Clinical
Research Information
Management (RCRIM)*
(formerly Clinical Trials)









Scheduling & Logistics*
Security*
Service Oriented Arch.
Structured Documents*
Technical Steering
Committee**
Templates
Tooling**
Vocabulary*
XML
* Technical Committees, ** Board Committees, ***Task Force
53
As of 06/06
HL7 for messaging
• It’s all about the interface:
• Hospital-centric view of HIT
54
HL7 beyond the hospital interface
Enterprise
Facility
Region
Network
55
National
HL7 beyond the messaging interface
• CCOW: multi-application context
management, single sign-on
• Arden Syntax: decision support,
guidelines
• Electronic Health Record: functional,
system and interoperability models
• Reference Information Model (RIM)
• Clinical Document Architecture
56
Outline
•
•
•
•
•
HL7
CDA
CDA for exchange networks
CDA+CCR=CCD
Summary, Resources & Questions
57
CDA
•
•
•
•
Clinical Document Architecture
ANSI/HL7 CDA R1.0-2000
ANSI/HL7 CDA R2.0-2005
A specification for document exchange
using
–
–
–
–
XML,
the HL7 Reference Information Model (RIM)
Version 3 methodology
and vocabulary (SNOMED, ICD, local,…)
58
CDA: A Document Exchange
Specification
• This is a CDA
• and this
• and this
• and this
• and this
• and this
• and this
59
CDA: electronic documents
• eDocuments for Interoperability
– Many CDA documents comprise an
individual electronic medical record
– Key component for local, regional,
national electronic health records
– Gentle on-ramp to information exchange
• Everyone uses documents
• EMR compatible, no EMR required
• All types of clinical documents
Consult
Discharge
Radiology
Path
CCD
CDA
Health
chart
60
Sample CDA
• Header
• Body
– Readable: required
– Computable: optional
61
CDA Header: Metadata
• Identify
– Patient
– Provider
– Document type...
• Sufficient for
–
–
–
–
–
required
Medical records management
Document management
Registry/repositoryg
Record locator service
Store, query, retrieve
62
CDA Body: Human-readable report
• Any type of clinical document
–
–
–
–
H&P
Consult
Op note
Discharge Summary...
• Format: tif, PDF, HTML, XML:
–
–
–
–
–
–
–
Paragraph
List
Table
Caption
Link
Content
Presentation
required
63
CDA Body: Machine Processible
– Model-based computable semantics:
• Observation
• Procedure
• Organizer
• Supply
• Encounter
• Substance Administration
• Observation Media
• Region Of Interest
• Act
Optional
64
CDA: Incremental Computability
• Standard HL7
metadata
• Simple XML for point
of care human
readability
• RIM semantics for
reusable computability
(“semantic
interoperability”)
65
Investing in Information
• CDA can be simple
• CDA can be complex
• Simple encoding relatively inexpensive
• Complex encoding costs more
• You get what you pay for:
– like charging a battery,
– the more detailed the encoding
– the greater the potential for reuse
67
Outline
•
•
•
•
•
HL7
CDA
CDA for exchange networks
CDA+CCR=CCD
Summary, Resources & Questions
68
CDA document-based network
• All transform to CDA
• View the complete record
• No loss in computable
semantics
EMR
HL7|^v2
data
PMpaper
HL7|^v2
text
text
HL7|^v2
chart
LIS
text
DICOM
RIS/dictation
paper
NCPDP
eRx/paper
•
•
•
•
•
•
EHR
V-EHR
PHR
Patient Portal
Physician Portal
Health Record Bank
69
CDA for Information
Exchange
• International: basis of interoperability in most
advanced national networks
– Finland, Greece, Canada, Germany, Japan, Korea, France,
Italy, New Zealand, Australia, and more
• US: Federal Health Architecture/CHI
– CMS Notice of Proposed Rule Making
• Claims attachments using CDA + X12
• First pilot concluded, others underway
– VA/DoD bi-directional exchange
• US: Document format for NHIN pilots, RHIO design
– NHIN Pilots: preliminary architecture
– HITSP: preliminary choice
– IHE Medical Summary – CDA for NHIN/RHIO exchange
70
Major Implementations
(outside US)
•
•
•
•
•
•
•
•
•
•
PICNIC (European Union)
SCIPHOX (Germany)
HYGEIAnet/WebOnColl (Greece)
Aluetietojärjestelmä (Finland)
Health Information Summaries (New
Zealand)
Referrals (Australia)
MERIT-9 (Japan)
NHS (Wales)
Buenos Aires HMO project (Argentina)
Plus projects in France, Italy, Russia,
Estonia, Taiwan, Korea…
71
CDA: an international standard
72
CDA: Investing in Information
• CDA at the Mayo Clinic
– Initiated in 1999
– About 50,000 documents each week
– Clinical documents: Most important capital asset
• CDA at New York Presbyterian (was ColPres)
– “CDA Philosophy”
– Clinical notes contain critical information in
narrative
– Best format for information mining and
aggregation across applications
– 1/3 of all discharges summaries
73
XML Value Chain
Voice
Recognized
Dictation
Clinical
Trials
Anonymize
Data
Mining
Clinically
Useful
Markup
DSS
EMR
QA
Transcription
NLP Engine
CDA
Transformation
PDA
Access
Coding
Clinical
Guidelines
XML
Markup
Billing
01010010010100100101001010101000101010101000101010010101010101010100101001001010100101010010010010001001001010010010000101010101001010101001001001001001010010101
01010010010010010100101010010010010010010010010010101000101000101001010010010010010101010010100100100100100100100100100100100100100101001010010010010010001010010
Allscripts Touchworks
IHE
Medical
Summaries
HIMSS 2006:
a CDA Gallery
GE Centricity
Siemens Soarian (XML)
MediNotes e
Siemens Soarian (PDF)
Eclipsys Sunrise
CDA for Information
Exchange
• IHE choice for Medical Summaries
MediNotes
NextGen Healthcare Information
Systems
AllScripts
GE Healthcare
Philips Medical Systems
McKesson
CapMed/IBM
Eclipsys
Medical Informatics Engineering
Dictaphone
Epic Systems
GE Healthcare
Misys Healthcare Systems
Siemens
MediNotes e
NextGen EMR
Touchworks EHR
Centricity® Enterprise Solution
(formerly Carecast)
Xtenity
Horizon Ambulatory Care
Personal HealthKey
Sunrise
Webchart
Enterprise Workstation
EpicCare
Centricity® Physician Office
Misys Connect
Soarian
76
Outline
•
•
•
•
•
HL7
CDA
CDA for exchange networks
CDA+CCR=CCD
Summary, Resources & Questions
77
Agreements/MOUs
* Accredited Standards Committee X12 — ASC-X12
* American Dental Association — ADA
o ADA Joint Project Statement
* American Society for Testing Materials — ASTM
* CEN/TC 251
* Clinical Data Interchange Standards Consortium — CDISC
* Digital Imaging and Communication In Medicine — DICOM
* eHealth Initiative – eHI
* Institute for Electrical and Electronic Engineers — IEEE
* Integrating the Healthcare Enterprise — IHE
* Medbiquitous
* National Council for Prescription Drug Program — NCPDP
* OASIS
* Object Management Group — OMG
* University of Nevada Las Vegas — UNLV
* College of American Pathologists - SNOMED International
Division — SNOMED
78
HL7’s CDA
• Clinical Document Architecture
– ANSI/HL7 R1-2000, R2-2005
• eDocuments for Interoperability
– Key component for local,
regional, national electronic
health records
– Gentle on-ramp to information
exchange
• Everyone uses documents
• EMR compatible, no EMR
required
• All types of clinical documents
79
Consult
Discharge
Radiology
Path
Summary
CDA
Health
chart
ASTM’s CCR
80
ASTM CCR vs. HL7 CDA
• Conflicting?
• Overlapping?
• What if you could have both!#*?I!!
– What if you could have your data
elements
– And send them in a common exchange
framework?
82
ASTM CCR + HL7 CDA =
CCD
• CDA is designed to support professional society
recommendations, national clinical practice
guidelines, standardized data sets, etc.
• From the perspective of CDA, the ASTM CCR is a
standardized data set that can be used to constrain
CDA specifically for summary documents.
• The resulting specification, known as the
Continuity of Care Document (CCD), is being
developed as a collaborative effort between ASTM
and HL7.
83
ASTM’s CCR
84
Continuity of Care
Document CCR data element
• CCD maps the
CCR elements
into a CDA
representation.
CDA R2 correspondence
Results
Section
Result
Observation
DateTime
Observation.effectiveTime
IDs
Observation.id
Type: Values include:
Hematology,
Chemistry, Serology,
Virology, Toxicology,
Microbiology,
Imaging - X-ray,
Ultrasound, CT, MRI,
Angiography, Cardiac
Echo, Nuclear
Medicine, Pathology,
Procedure
Draw values from
observation.code (e.g. by
looking at the LOINC class
for a LOINC code).
Description
Observation.code
Status
Observation.statusCode
Procedure
Observation.methodCode;
Procedure
Test
85
Observation
Continuity of Care Document
•
•
Did this come out of the blue?
There is a history of collaboration
–
–
–
–
Many people have participated in both efforts
Presentation on CDA for continuity of care at ASTM CCR
meeting, August, 2003
Memorandum of Understanding, 2004
Acapulco demo: CDA for CCR, October, 2004
•
–
Initial HL7 Care Record Summary ballot, April, 2005:
•
•
–
HL7 partnered with Massachusetts Medical Society,
Microsoft, Ramsey Systems (UK)
Limited to CDA header, no detailed section coding
Anticipated: “Development of detailed (CDA Level 3)
Implementation Guides for “continuity of care” (CCR) in
collaboration with the ASTM E31 under the 2004
Memorandum of Understanding”
HL7 ballot on CCR, Spring 2005: incorporated changes
required for bi-directional exchange and semantic
interoperability
86
Continuity of Care Document
• “ASTM is dedicated and privileged to
work in collaboration with HL7 on the
expression of ASTM's Continuity of
Care Record content within HL7's CDA
XML syntax and the seamless
transformation of clinical and
administrative data between the two
standards.”
• Rick Peters, MD, E31.28
87
Continuity of Care Document
• Benefits
– Industry concensus on summary document
contents and requirements through ASTM ballots
(2004, 2005)
– Industry concensus on document exchange
framework through HL7 ballots (1999-2005)
– Summaries for continuity of care
• Interoperable with full range of document types
• Interoperable with HL7 V3 messages, all RIM-based
specifications (public health reporting, clinical trials,
structured product labels and more)
88
Outline
•
•
•
•
•
HL7
CDA
CDA for exchange networks
CDA+CCR=CCD
Summary, Resources & Questions
89
CDA for Interoperability
• HL7/ANSI specification based on
– Reference Information Model (RIM)
– Extensible Markup Language (XML)
– Standard Terminology
• The spec:
– Header+Human-readable report+(optional) computable
semantics
• Industry acceptance:
– Internationally implemented for 6 years
– US: FHA, CHI, CMS, VA, DoD, NHIN, HITSP...
– Vendor support: strong & growing
• Interoperability
– Full patient record, not just the data that can be coded
today
– Full patient record – summaries and more, implementation
guides in the works from multiple professional societies
and agencies
90
Current Work
• HL7
–
–
–
–
–
–
–
–
–
Continuity of Care Document (with ASTM)
Pathology reports (with CAP)
Imaging reports (with DICOM)
Claims attachments, migrate from R1 (with CMS)
Medical Summary (with IHE, EHR Vendors
Association)
Dental reports (with ADA)
Anesthesiology Reports (with Anes SIG)
Public health reports (with CDC)
... What should we be doing to develop standard
documents for LTC?
91
References & More Info
www.HL7.org Structured Documents Technical Committee web page
All meetings, listservs, open to all
JAMIA
Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV,
Shabo A. HL7 Clinical Document Architecture, Release 2. J Am Med
Inform Assoc. 2006;13:30–39.
http://www.jamia.org/cgi/reprint/13/1/30
Care Record Summary
http://www.hl7.org/Library/Committees/structure/CareRecordSum
mary%5FI2%5F2005SEP%2Ezip
CDA Release 2.0 Normative Edition: see HL7.org
AlschulerAssociates.com
Quick Start Guides
CDA/CRS Validator
CDA Gallery
[email protected]
92
Thank you!
Questions?
93
http://www.alschulerassociates.com/library/presentations/CDA4CDT.PEHRC.June07.ppt
Clinical Document Architecture for
Common Document Types
PEHRC
June 18, 2007
Liora Alschuler
Liora Alschuler
– Consultant in healthcare IT 1997-present
• Background in electronic text, industry analyst with
Seybold Publications, xml.com
• Author, ABCD... SGML: A Manager’s Guide to
Structured Information, 1995
• Founded consulting firm in 2005
– Volunteer standards work
• Health Level Seven Board of Directors (2005-2008)
• Co-chair Structured Documents Technical Committee
• Co-editor Clinical Document Architecture (CDA)
– [email protected]
Alschuler Associates, LLC
• Consultants in standards-based solutions for healthcare information
working with vendors, providers, standards developers
• Clients
– Military Health System
• Enterprise-wide documents, files, images (DFIEA)
– Centers for Disease Control and Prevention
• Implementation Guide for infectious disease reporting (NHSN)
– North American Association of Central Cancer Registries
• Implementation Guide for cancer abstracts
– Department of Health and Human Services
• Subcontracts on Health IT Standards Panel (HITSP) and Health
Information Standards for Privacy and Confidentiality (HISPC)
– American Hospital Association
• Use case development for healthcare IT standards initiative
– CDA4CDT
• Co-founder & Project Management
– Private, commercial clients: Fortune 100 and startups
• www.alschulerassociates.com
• HL7
• CDA
– what is it
– where is it used
• CCD
• CDA4CDT
– & the PEHRC
Health Level Seven
• Non-profit ANSI Standards Development
Organization
• 20 years old
• 2000+ members
– individual, corporate
• 30 affiliates
– US affiliate in near future
• “A model community”: building standards
to a single information model
HL7 Steering Divisions
Foundation & Technologies
• Implementable Technology
Specifications
Structure & Semantic Design
• Implementation/Conformance
• Clinical Context
Object
• Infrastructure
& Messaging
• JavaWorkgroup
• Clinical
Decision Support
• Modeling
& Methodology
• Electronic Health Record
• Security
• Financial
Management
• Service
Oriented
Architecture
• Genomics
• Templates
• Orders & Observations
• Vocabulary
• Patient Administration
• Scheduling & Logistics
• Structured Documents
Domain Experts
• Anesthesiology
• Attachments
• Cardiology
• Clinical Guidelines
• Community Based Collaborative Care
• Emergency Care
• Government Projects
• Health Care Devices
• Imaging Integration
• Laboratory
• Patient Care
• Patient Safety
• Pediatrics Data Standards
• Public Health Emergency Response
• Pharmacy
• Regulated Clinical Research Information
Management
CDA: A Document Exchange
Specification
•
•
•
•
•
•
•
This is a CDA
and this
and this
and this
and this
and this
and this
The CDA document defined
CDA Release 2, section 2.1:
A clinical document ... has the following characteristics:
 Persistence
 Stewardship
 Potential for authentication
 Context
 Wholeness
 Human readability
• therefore, CDA documents are not:
– data fragments, unless signed
– birth-to-death aggregate records
– electronic health records
CDA Design Principles
• priority is patient care, other
applications facilitated
• minimize technical barriers to
implementation
• promote longevity of clinical records
• scoped by exchange, independent of
transfer or storage
• enable policy-makers to control
information requirements
Sample CDA
• Header
• Body
– Readable: required
– Computable: optional
CDA Header: Metadata
• Identify
– Patient
– Provider
– Document type...
• Sufficient for
–
–
–
–
–
Medical records management
Document management
Registry/repository
Record locator service
Store, query, retrieve
required
CDA Body: Human-readable report
• Any type of clinical document
–
–
–
–
H&P
Consult
Op note
Discharge Summary...
• Format: tif, PDF, HTML, XML:
–
–
–
–
–
–
–
Paragraph
List
Table
Caption
Link
Content
Presentation
required
CDA Body: Machine Processible
– Model-based computable semantics:
•
•
•
•
•
•
•
•
•
Observation
Procedure
Organizer
Supply
Encounter
Substance Administration
Observation Media
Region Of Interest
Act
Optional
CDA: Incremental Semantic
Interoperability
• Standard HL7 metadata
• Simple XML for point of
care human readability
• RIM semantics for
reusable computability
(“semantic
interoperability”)
Primary Use Cases
• access/portability/exchange
– query/locate by patient, provider, practitioner, setting,
encounter, date
– access distributed information through common
metadata
– document management
• integration
– transcription systems
– EHR records
• re-use/derivative data
– summaries, reports
– decision support
CDA for Information
Exchange in the US
• Recommended by Health Information
Technology Standards Panel (HITSP) work
groups
• CMS Notice of Proposed Rule Making
– Claims attachments using CDA + X12
– First pilot concluded, others underway
• Widespread vendor adoption:
– Integrating the Healthcare Enterprise
– CDA4CDT
– Other
Current Implementation: US
•
Mayo Clinic
– Initiated in 1999
– About 50,000 documents each week
– Clinical documents: Most important capital asset
•
New York Presbyterian
–
–
–
–
•
“CDA Philosophy”: mix of fielded data and narrative
Best format for information mining and aggregation across applications
Clinical notes contain critical information in narrative
1/3 of all discharges summaries
Military Health System
– Documents, Files, Images Enhanced AHLTA (DFIEA)
• Enterprise-wide document management
• Web-services gateway to VA, civilian providers
– MHS/VHA Bi-direction Health Information Exchange
– Enterprise Wide Referrals and Authorizations
•
University of Pittsburgh Medical Center
– Narrative notes using speech recognition, NLP
– Linking radiology reports with PACS-rendered image
•
Other
– Kaiser, Trinity, Partners, Ochsner...
CDA for Information Exchange
• IHE choice for Medical Summaries: 2006
MediNotes
NextGen Healthcare Information
Systems
AllScripts
GE Healthcare
Philips Medical Systems
McKesson
CapMed/IBM
Eclipsys
Medical Informatics Engineering
Dictaphone
Epic Systems
GE Healthcare
Misys Healthcare Systems
Siemens
MediNotes e
NextGen EMR
Touchworks EHR
Centricity® Enterprise Solution
(formerly Carecast)
Xtenity
Horizon Ambulatory Care
Personal HealthKey
Sunrise
Webchart
Enterprise Workstation
EpicCare
Centricity® Physician Office
Misys Connect
Soarian
Allscripts Touchworks
GE Centricity
Siemens Soarian (XML)
MediNotes e
Siemens Soarian (PDF)
Eclipsys Sunrise
IHE
Medical
Summaries
HIMSS 2006:
a CDA Gallery
CDA for Information
Exchange
• IHE choice for profiles: 2007
==========
==========
=========
XPHR
XDMS - Referral
EDR
===========
==========
==========
=========
Capmed XDS-SD Allscripts
Allscripts
GHNIHE ===========
Bell/XWave
Epic
Nextgen Blueware Epic
===========
Medinotes
Capmed GE
XDMS - Discharge Misys
============
CGI
Medinotes ===========
XD-LAB
CPSI
MIE
========
============
GE
Misys
BPPC
Bell/XWave
GE Healthcare
IBM
Nextgen
========
Eclipsys
Infinitt
Allscripts
Epic
MIE
Capmed
GE
Misys
Misys
Medinotes
NoMoreClipboard
Quovadx
Medquist
Quovadx
MIE
SMS
Misys
Softmedical
Nextgen
http://ihewiki.wustl.edu/wiki/index.php/ChicagoTiani Spirit
2007-Connectathon-Registered-Documents
CDA & CCD
• IHE Profiles 2005-2007 based on the Care
Record Summary (CRS)
– first standard implementation guide for CDA
– restricted to “level 2” to avoid competition w/CCR
– covered a wider number of use cases
• IHE 2007-2008 will move to conform with
CCD
• New CDA implementation guides also
conform with CCD
ASTM CCR+HL7 CDA = CCD
• The primary use case for the ASTM CCR is to provide a snapshot in time
containing a summary of the pertinent clinical, demographic, and
administrative data for a specific patient.
• From its inception, CDA has supported the ability to represent professional
society recommendations, national clinical practice guidelines, standardized
data sets, etc.
•From the perspective of CDA, the ASTM CCR is a standardized data set
that can be used to constrain CDA specifically for summary documents.
•The resulting specification is known as the Continuity of Care Document
(CCD).
Continuity of Care Document
• CCD maps the CCR elements into a CDA representation.
CCR data element
CDA R2 correspondence
Results
Section
Result
Observation
DateTime
Observation / effectiveTime
IDs
Observation / id
Description
Observation / code
Status
Observation / statusCode
Continuity of Care Document
• CCD maps the CCR elements into a CDA representation.
<Results>
<section>
<Result>
<code code="30954-2“
<CCRDataObjectID>
codeSystem="2.16.840.1.113883.6.1"
2.16.840.1.113883.19.1
codeSystemName="LOINC"/>
</CCRDataObjectID>
<title>Laboratory results</title>
<DateTime>
<text>
<Type>
CBC (04/07/2000): HGB 13.2; WBC 6.7; PLT 123*
<Text>Assessment Time</Text>
</text>
</Type>
<entry>
<ExactDateTime>
<observation classCode="OBS" moodCode="EVN">
200004071430
<id root="2.16.840.1.113883.19" extension="
</ExactDateTime>
<code code="43789009"
</DateTime>
codeSystem="2.16.840.1.113883.6.96"
<Type>
codeSystemName="SNOMED CT"
<Text>Hematology</Text>
displayName="CBC WO DIFFERENTIAL"/>
</Type>
<statusCode code="completed"/>
<Description>
<effectiveTime value="200004071430"/>
<Text>CBC WO DIFFERENTIAL</Text>
<Code>
<Value>43789009</Value>
<CodingSystem>SNOMED CT</CodingSystem>
</Code>
</Description>
<Status><Text>Final Results</Text></Status>
CDA Business Case
• Gentle on-ramp to information exchange - CDA is straight-forward to
implement, and provides a mechanism for incremental semantic
interoperability.
• Improved patient care - CDA provides a mechanism for inserting
best practices and evidence-based medicine directly into the process of
care (via the same “template” mechanism used to build CCD), thereby
making it easier to do the right thing.
• Lower costs – CDA provides necessary information to coordinate care,
reducing redundant testing and optimizing care delivery for quality and cost.
• CDA hits the “sweet spot” – CDA
encompasses all of clinical documents. A
single standard for the entire EHR is too broad.
Multiple standards and/or messages for each
EHR function may be difficult to implement.
CDA is “just right”.
CDA beyond CCD
• Not everything we want to exchange is
a summary
• Let’s look at what’s happening with
development of other document types...
Other CDA content profile
development
– Within HL7:
• Clinical domains: anatomic pathology, imaging, lab,
anesthesiology, pediatrics, long term care, others?
• ASIG: HIPAA Attachments – adding dental
– Outside HL7: Public health & MDS
• NAACCR Cancer abstracts (no HL7 ballot)
• CDC Infectious Disease Reports (will be HL7 ballot)
• MDS: soon, from HHS
– IHE
• 2006: 1 content type built on HL7 CRS
• 2007: 7 content types, some constrain CRS, others
new
• Current cycle:
– updating all to be consistent with CCD
– adding Discharge Summary
– CDA4CDT
CDA for Common
Document Types
• Project initiated in January, 2007
– M*Modal
– AHDI(was AAMT)/MTIA
– AHIMA
• Strong support from dictation / transcription
and document management industries
• Cooperation/coordination with HL7, IHE,
EHR vendors and providers
CDA4CDT Mission
• Develop CDA Implementation
Guides (IGs) for common types of
electronic healthcare documents
• Bring them through the HL7 ballot
process
• Promote their use and adoption by
healthcare organizations and health
information exchange networks
Rationale
• Enlarge and enrich the flow of data
into the electronic health record
• Speed the development of
interoperable clinical document
repositories
• Bridge the gap between narrative
documents produced through
dictation and the structured,
computable records within an EHR
Why would physicians promoting
the EHR have an interest in
documents?
• Assumptions:
– EMR/EHR is the solution
– Documents are the problem
• Questions:
– Are they mutually exclusive or
complementary?
– Can eDocuments bridge the gap?
Problems with Documents
• Can’t compute
• Can’t automate decision support
• Can’t validate conformance to content
requirements
• And why are they still prevalent?
–
–
–
–
Nuanced & precise
Support human decision making
Retain current workflow
eDocuments support narrative & codes
• multiple indices optimized for reimbursement, decision
support, quality metrics, research
• Document management completes the EMR
Why encourage continued
use of documents?
• Worst case:
– no computable clinical data
– no reuse
– + information at the point of care
• Best case:
– fully computable data to populate EHR
• Likely case:
– section-level reuse (i.e. HPI pre-populates
Discharge Summary) – we can do this now
– gradual rise in semantic interoperability
Why not keep pushing for
fully interoperable records?
• Semantic interoperability is hard
– over 250,000 concepts in SNOMED CT
– we can’t give up, we need safe computability
• Need information at the point of care
• Networks need data: self-sustaining networks
have Big Data
– Initial ROI will spur further investment
– MTIA members process 300M documents/year
• Complex systems are built from simple systems
• CDA: no loss of computability
minimum
metadata
today
future
CDA4CDT: bridging the gap
between EHRs and eDocuments
• CDA4CDT will:
– Establish consensus on content using CDA eDocument
format
– Propagate support for CDA within the dictation/transcription
industry
– Create consistent electronic documents for importation into
EMR, document repositories and health information
exchanges
– Increase EMR adoption
• Highest potential:
– Massively increase amount of data in fledgling exchange
networks because minimally disruptive to current workflow
• Defining success:
– At least 25% of RFPs for transcription, EMRs, integration and
information exchange cite compliance as a requirement
CDA4CDT
• Scope
– Develop implementation guide for use across the industry
– Rapid development, leverage framework, precedents
– Establish section-level content, reuse section templates
• H&P Timeline
– Initial draft in 7 weeks
– Balloted as HL7 Draft Standard for Trial Use
• March 26 ballot open, April 24 close
• Ballot reconciliation approximately 5 weeks
• Revised draft to ballot in August
• Consult Note Timeline
– Target August 2007 initial ballot
• Discharge Summary: Coordinating with IHE on
publication
– Target publication fall 2007
Technical working group
• A focused group of working volunteers
– prior knowledge of CDA
– experience implementing CDA
– familiarity with the current set of CDA
implementation guides
• Participation is open at all stages of the
ballot and ballot review process
• CDA4CDT retains no copyright of
balloted material
H&P Method
• Review precedents:
– ASTM’s Standard Specifications for Healthcare Document Formats
(E2184.02) (Headings and subheadings used in the healthcare
industry and associated with specific report types)
– HL7/ASTM Continuity of Care Document (CCD)
– Clinical LOINC document and section codes
– HL7 ASIG CDA R2 Attachment for Clinical Notes
– HL7 Care Record Summary (CRS)
– IHE profiles, including the content profiles within Patient Care
Coordination
– MHS/DoD-VA-IM-IT Demo Project Discharge Summary and SOAP
HL7 CDA R2 Implementation Guides
• Review samples/templates:
– Sample CDA documents developed for local provider institutions
(Mayo Clinic, University of Pittsburgh Medical Center, New York
Presbyterian, and others)
– Non-CDA sample documents supplied by participating providers
and vendors
– H&P templates from AHIMA, vendors, providers
• Statistical analysis: over 15,000 dictated H&Ps by M*Modal
• Test design against samples
Draft H&P
Ballot results
• 78 comments received
– ACP, Trinity Health, Kaiser Permanente,
VHA, Regenstreif
– Epic, GE, Medquist, Northrop
• All comments addressed
– All negatives will be withdrawn
– Draft in revision
– Will re-ballot in August/September
• If passed, will be “Draft Standard for Trial
Use” (DSTU)
– stable platform for implementation
– within 2 years either normative or revised
Ballot issues
• Most difficult
– balance diversity of current practice against
desire for consistency
– where can you lead the industry, where must
you follow?
• Clarify intended content
– Past Medical History vs. Surgical History
• Physical exam: diversity of practice
– Define full set of sub-headings
– Allow narrative &/or sub-sections
Consult Note
• Same method as H&P
–
–
–
–
consistent with precedents
large scale analysis of dictated notes
reuse section-level content
review E&M guidelines
• Examine required metadata
• Examine report contents
– Require “reason for referral”
– Relationship with “reason for visit”, “chief
complaint”
• Seeking pre-ballot review
Future work
• Horizontal: additional document types
– Op note
– Specialize the History & Physical
• Vertical: supporting implementation
– Quick Start Guides for implementers
– Training for implementers
• Promotion: Among providers
– Education on utility, strategic value
– End-user training for compliance
• Whatever it takes to support and promote
widespread adoption
How can PEHRC, PEHRC
members get involved?
• Participate in design review
– through CDA4CDT
– through HL7 Structured Documents TC
– through HL7 Board of Directors
• Participate in the ballot
– as HL7 member or non-member
• Encourage implementation
– within professional society
– within practice group
CDA for Common Document Types
• Founders:
• Benefactors:
• Participants:
Acusis, Kaiser Permanente, Mayo Clinic, Military Health System,
University of Pittsburgh Medical Center, GE Healthcare
• Management:
HL7: patient-centered health information
HL7 TC/SIG
RCRIM
SDTC
Pharmacy
Lab
Image Int.
Patient Care
Decision
Support
Public
Health
Pharmacy
Discharge
medications
PCP followup
Consult
New drug
information
PHR/EHR
Vocabulary Services
Knowledge Base
R&D
Study
Develop
Report
HL7 Standards
RIM-DataTypes-ITS
SPL
CDA: Discharge Sum
V3 msg: Med Order
CDA: lab, imaging
V2: lab
Arden
ICSR
aECG
CT Lab
Stability
MOUs
X12, ADA
ASTM, CEN
CDISC, DICOM, eHI
IEEE, IHE,
OASIS,OMG,
NCPDP, CAP, WEDI
CDA from Dictation
• narrative documents can be
enhanced through natural language
processing and use of templates
with no disruption to the
existing
M*Modal view of “validation
display”
workflow