Electronic Exchange of Structured Interim Discharge Summaries
Download
Report
Transcript Electronic Exchange of Structured Interim Discharge Summaries
Electronic Exchange of
Structured Interim Discharge
Summaries Using the XMLbased Clinical Document
Architecture
Grace Paterson, Medical Informatics
Xiaoli Wang, Dalhousie Computer Science
http://www.medicine.dal.ca/dmedinfo
XML Standard for Healthcare
Comprehensive healthcare information
exchange standard must include the full
electronic health record, not just fielded data
Clinical Document Architecture (CDA) is a
specification for exchanging clinical
documents using eXtensible Markup
Language (XML)
Bob Dolin’s Ehealth 2001 Workshop
presentation available on CIHI HL7 website
Power of XML
XML, like HTML, is a derivative of Standard
Generalized Markup Language (SGML)
Information Technology’s “lingua franca”
Current “must-have” feature in software
Browsers, Notepad, SAS, Oracle, Internet Security
E-Commerce and Automating Transactions
E-Health gets a tremendous boost at low cost
Power of a Think Tank Kona Proposal
Week of July 7, 1997, a group of physicians, healthcare
system vendors and consultants met at Kona Mansion, NH
OUTCOME: a multi-level architecture for the exchange of
Electronic Health Care Records
April 2000. Kona Proposal was revised into the PRA
(Patient Record Architecture) but went to HL7 ballot August
2000 as CDA (Clinical Document Architecture)
Xiaoli phoned Liora Alschuler for specifications
CDA and Shared Care
CDA gives priority to documents generated by
clinicians involved in direct patient care
Care occurs where the patient’s pillow is hospital, family physician, long term care
CDA standard can be readily implemented, and
is platform and application independent
Promotes shared care in appropriate setting
Structured Discharge Summary
QEII DEPARTMENT OF MEDICINE
Header Information (Participants and Roles)
Most Responsible Diagnosis/Admitting Dx
Comorbidities/Cardiac Risk Factors
Allergies
Course in Hospital
Pertinent Investigations/LabResults
Structured Discharge (con’d)
Follow Up
Recommendations for Family Doctor
Medications on Discharge (unchanged from
admission, altered, new)
Discharge Outcome Measures
Physician’s Signature/Status/Print Name
Discharge Summary and Dictated Job #
CDA and Knowledge Integration
Publishers submit abstracts to MedLine in XML
XML tag <FullText> provides external link to
fulltext for MedLine abstract
CDA has <content>, <link>, <coded_entry>,
<observation_media>, and <local_markup>
Nova Scotians can link from CDA document to
Electronic Bookshelf entries in doctorsns.com
for prompts and “Information Given to Patient”
CDA and Outcomes Research
• From time of Florence Nightingale to mid60s, Hospital Annual Reports documented
discharges as recovered, improved, no
change, worsened, died
• Generic scales (SF-36)
• Disease specific scales (IBDQ)
• Health Status (comfort, function, lifespan)
• Health Outcomes and HL7 V3 Data Types
Feedback
Model
Key features of CDA
A clinical document should be human readable.
The clinical document will be legally authenticated,
and the authentication of a clinical document will be
applied to the whole, not portions of the document.
Entrusted person or organization will maintain the
clinical document.
A CDA document can include text, images, sounds
and other multimedia content.
CDA documents are encoded in XML.
CDA documents will be consistent with HL7 data
types.
Necessary and Sufficient Components
Persistence
Stewardship
Potential for Authentication
Wholeness
Human Readability
Specification
Overview of CDA Architecture
In Level One, the level one DTD is for all kinds of
clinical document.
In Level Two, a specific clinical document will be
defined in consultation with Professional Societies
QEII Hospital has gone through up to 12 revisions of Cardiology,
Internal Medicine, Geriatrics, COPD templates
We were able to implement each template in Level One
Defined process for going from CDA Level One to CDA
Level Three - tightly coupled with HL7 V3 Data Types
Deliberate decision to wait for V3 ballot results Aug 2001
XML Design (Header)
CDA Header is used to uniquely identify a clinical document in
order to exchange it among organizations
There are four components for header: document information,
Encounter data, providers and patients
Document information includes <id>, <set id>, <version_nbr>,
<document_type_cd>, <confidentiality_cd>,
<document_relationship>
Encounter data describe the setting in which the documented
encounter occurred. It includes <patient_encounter>, <practice
_setting_cd>, <encounter_tmr>, <service_location>, <addr>.
Provider include the person who participated in the services being
documented.
Patient include the patient and other significant participants (such as
family members)
XML (Level One Body)
Nested containers in Level One body: sections,
paragraphs, list and tables.
Minimal amount of markup and minimal
constraint for this markup.
Coded entries uses HL7 Version 3 Data Types
Appendix A lists object identifiers, e.g.,
2.16.840.1.113883.6.3 is the external coding
scheme ICD10
<coded_entry>
<section>
<caption>Most Responsible Diagnosis</caption>
<section>
ICD10
Object Identifier for
<caption>Unstable Angina
ICD10 coding scheme
<caption_cd V=“I20.0”
S=“2.16.840.1.113883.6.3”/>
</caption>
<paragraph>
<content>Y</content>
</paragraph>
</section>
Implementation
To generate a Discharge Summary, the user
enters the information into Web form
Information is POSTed to Web server where
a Java servlet parses the input data and
marks up the data into the CDA format
Written to disk as an XML file
Retrieved as XML file by Java servlet and
parsed into constituent elements by SAX
parser, converted to HTML and displayed
Implementation
XML describes the meaning of content,
independent of its display
There are two style sheets for XML
CSS (Cascading Style Sheet)
XSL (XML Style Sheets Language)
User enters chart number for search and
choice of display style (web form or
discharge summary)
Implementation
Parser of XML
We must access information in XML
documents through an XML parser.
There are two kinds of parser: SAX and
DOM, SAX is event-based parser and DOM
is object-based parser, the core object is
Node.
Implementation
• Several events for SAX:
• startDocument()/endDocument()
• startElement()endElement()
• Characters()
• Several methods for DOM:
• NodeType, parentNode, childNode, firstchild,
getElementByTagName(), getText(),
getNameItem().
Summary and Next Steps
The procedure of this project includes understanding
specification, designing a system, implementing the
system, and the final testing.
The purpose of the system is to meet the need of an
extensible, hierarchical, structured clinical document
exchange.
Work-in-progress with other CS Students:
CDA document storage in Statistical Analysis
System (SAS)
CDA integrated with Electronic Bookshelf
Automatic Indexing Using UMLS for Coded Entries
Acknowledgements
• Dr. Michael Shepherd, Computer Science
• Dr. Carolyn Watters, Computer Science
• Dr. David Zitner, Director, Medical Informatics; Chair,
Health Records Committee, QEII Health Sciences Centre
• Kathy MacNeil, Director, Patient Information Services,
QEII Health Sciences Centre
• Patient Care Record Committee, Capital Health District
Authority
• Mary Eileen Wall, Clinical Informatics Coordinator, QEII
Health Sciences Centre
• Sandra Cascadden, Director of IT Services, QEII Health
Sciences Centre
• Ron Soper, Computer Science CO-OP Student