Transcript Representation and Coding of Medical Data G4020

Integration of Health Information Resources
into Electronic Health Records
James J. Cimino, MD
Department of Biomedical Informatics, Columbia University, New York, NY
Jerome A. Osheroff, MD
Thomson Micromedex, Greenwood Village, CO
University of Pennsylvania, Philadelphia, PA
Guilherme del Fiol, MD, MS
Intermountain Healthcare, Salt Lake City, UT
Christopher Alban, MD, MBA
Epic Systems Corporation, Madison, WI
What Are We Talking About?
• Clinicians often have unresolved information needs
• Needs arise while using clinical information systems
• Systems know the user’s context but not the need
• Resource managers can match context to need
• Content providers can address specific needs
• But:
– How can context-specific needs be anticipated?
– What can content providers do?
– Can standards help?
– Will clinical systems use standards?
Topics of this Panel
• Informatics research on understanding needs:
– Jim Cimino, Columbia University
• Content provider perspective:
– Jerry Osheroff, Thomson Micromedex
• Standards in development:
– Guilherme del Fiol, HL7
• Clinical information system vendor perspective:
– Chris Alban, Epic Systems
A Informatics Researcher’s Perspective
James J. Cimino, MD
Department of Biomedical Informatics
Columbia University
Informatics Research on
Information Needs
• Observational studies of practicing clinicians
• Studies of clinicians’ queries of resources
• What about studies of information needs
while using clinical information systems?
• How can we automate answering the
questions?
Video Converter
and recorder
Video Converter
and recorder
Portable Usability Lab
Morae screen
capture
What are the Information Needs?
• Observations:
– Four days, three sites, 159 minutes of
videotape
– 154 information needs
• 1/3 information about the patient
– Abdominal CT was abnormal, what are
LFTs?
• 1/3 institutional information
– What specimen do I collect for this test?
• 1/3 health information
– What does this pill look like?
– What are the patient instructions?
• Computers used 50% of the time
• 81/154 needs not satisfied
Context parameters
•
•
•
•
•
Application
Concept of interest
Patient age and gender
User role
Institution
Conversion of Needs into Links
• Express the need as a question
• Identify an appropriate resource
• Develop integration approach:
– Simple link
– Concept-based link
– Simple search
– Concept-based search
– Intelligent agent
– Calculator
• Develop method to translate context
terms into resource terms
The Medical Entities Dictionary (MED)
Medical
Entity
Substance
Chemical
Laboratory
Specimen
Anatomic
Substance
Plasma
Carbohydrate
Bioactive
Substance
Plasma
Specimen
Event
Diagnostic
Procedure
Laboratory
Test
Plasma
Glucose
Glucose
Laboratory
Procedure
CHEM-7
Part of
Translations with the MED
Intravascular
Gentamicin
Tests
Summary
Reports
Injectable
Gentamicin
Serum
Gentamicin
Level
Gentamicin
Gentamicn
Sensitivity
Test
Decision
Rule
Gentamicin
Toxicity
Drug
Information
Expert
System
1
47
2
4
0
24
15
12
11
2000
54
0
31
23
31
4
0
2
0
3
4
5
6
7
8
10
11
12
Resource Use
By Context
AnionGapCalc (11)
PubMed (14)
CPMCLabManual-Collection (15)
1500
Harrisons (28)
AdverseEffects-MDX-IB (31)
AdultDose-MDX-IB (34)
Indications-MDX-IB (40)
Lab Tests Online (47)
LexiComp-PatientInfo (60)
UpToDate (110)
CPMCLabManual (210)
1000
HR-micromedex (2173)
HR-up-to-date (1864)
HR-ICD9-free (267)
HR-eresources (185)
HR-crlonline (151)
HR-icd9cmcoder (148)
HR-medlineplus (101)
500
HR-InfDisRefs (91)
HR-ovid (83)
HR-hripcsak-icd9 (62)
HR-harrisons (47)
HR-cpmclabinfo (40)
HR-pageonline (28)
0
card
rad
visit
LabDetail
InPatientDrugs
100%
Relative Resource
Use by Context
i
90%
AnionGapCalc (11)
PubMed (14)
80%
CPMCLabManual-Collection (15)
Harrisons (28)
70%
AdverseEffects-MDX-IB (31)
i
60%
AdultDose-MDX-IB (34)
Indications-MDX-IB (40)
Lab Tests Online (47)
LexiComp-PatientInfo (60)
UpToDate (110)
50%
CPMCLabManual (210)
HR-micromedex (2173)
HR-up-to-date (1864)
40%
HR-ICD9-free (267)
HR-eresources (185)
HR-crlonline (151)
30%
HR-icd9cmcoder (148)
HR-medlineplus (101)
20%
HR-InfDisRefs (91)
HR-ovid (83)
HR-hripcsak-icd9 (62)
10%
HR-harrisons (47)
HR-cpmclabinfo (40)
HR-pageonline (28)
0%
card
rad
visit
LabDetail
InPatientDrugs
Resource and Infobutton Use
9000
8000
7000
6000
5000
Health Resources (Anonymous)
Health Resources (UserID)
Infobuttons
4000
3000
2000
1000
Se
p05
Ju
l-0
5
ay
-0
5
M
ar
-0
5
M
Ja
n05
No
v04
Se
p04
Ju
l-0
4
ay
-0
4
M
ar
-0
4
M
Ja
n04
0
User Satisfaction
160
140
120
100
Strongly Disagree
Disagree
Neutral
Agree
Strongly Agree
80
60
40
20
0
Q1
Q2
Q3
Q1. The website was easy to navigate
Q2. I was successful in finding the information I needed
Q3. This WebCIS resource was helpful
Conclusions
• Stereotypical questions recur
• Context helps narrow down the choices
• Automated answering can be done, but…
…integration requires creative solutions and…
…terminology translation is a challenge
• Maybe standards are the answer…
Infobuttons:
A content provider perspective
AMIA Annual Symposium 2005
October 26, 2005
Jerome A. Osheroff, MD, FACP, FACMI
CCIO, Thomson Micromedex
Chair, HIMSS CDS Task Force
Faculty/Staff, U. Penn. Health System
Vendor Context/Challenge:
Meet clinical information needs
• Develop evidence-based information to
answer questions and provide guidance
• Deliver pertinent content into workflow
– too many steps; too much time to
select/interact/sort
• Patient/user/context-specific
– “Allow entry of patient-specific data, such as
age and gender, to help narrow the search”
JAMIA May ’05
– Easy integration process/CDS value for CIS
vendors
Solution/Approach
• Favorable response to Infobuttons@
Columbia/elsewhere -> Micromedex
market research -> Market receptivity ->
product dev.
• Emerging HL7 standard
– attractive option for serving patient- and
context-specific content in a user-friendly
manner
– active Micromedex collaboration
• Not just can do – should do
– for business/pt. care
End-user Content Requirements
General
• Trusted, consistent
• Evidence-based
• Current
• Responsive to needs
Infobutton-specific
• Granular
• Patient-specific
Content Infrastructure Requirements
(Micromedex Approach)
• Content Management System
– stores codified referential information: drugs,
diseases, lab tests, patient education, etc.
– highly granular form: tags for age, gender,
disease stage, etc. to indicate where the
information applies
• Web services for message exchange
– additional features to fully leverage
Micromedex capabilities/codified content.
• Testing/certification environment
MICROMEDEX InfoButton Access ™
• First commercial healthcare infobutton app:
– Drug, Disease, Lab info; others coming
– Patient Education drug and disease topics
• Product goal: increase usage of clinical
decision support in order to reduce
preventable patient adverse effects and
improve care quality
• Growing list of CIS infobuttons partners:
– Epic, Meditech, Bridge Medical, TheraDoc
• Research on product value (e.g. Partners,
Columbia)
InfoButton Access - Technology
Context information is “pulled” from the EMR and sent as
search request parameters to InfoButton application.
Web Services:
http://healthcare.thomsonhc.com/search.cgi?MainSe
archConcept=Metformin
InfoButton sends back a direct hit or
web page of relevant results:
Display options:
•Single document
•Document section such as
Adult Dose
Clinical Drug Info:
Metformin Hydrochloride
Patient Information:
Metformin (oral)
Healthcare Series
User clicks on
InfoButton in EMR
Content:
-DrugPoints
-DrugNotes
-Disease
Briefs
-CareNotes
Parameters Accepted
Parameter
Options
Main Search
Concept
Clinical Problem (Text/ICD-9)
Medication (Text/NDC)
Info subtype, e.g. Adult Dose
Question Modifier
Information
Clinician vs. patient-level info
Context
Application Context Problem list vs. medication list
Language
(for patient ed only)
Future: patient age, co-morbid illness, lab values…
Infobutton Access Example
Business Value: End User
• Reduces time/effort to answer clinical ?s
– e.g. dose, side effects, indication
• More care, less searching: used
frequently
• Needed knowledge more directly into
workflow; affects decisions
• Context/patient-specific information:
more responsive to needs
Business Value: HCO Purchaser
• Enhanced care sooner:
– Quick/easy integration; MDX hosts data
– less training
• Promotes best clinical practices:
– Reduce unanswered/un-pursued clinical ?s
and negative care impact
• Leverages existing Micromedex
subscriptions
– Summary/infobutton -> drill down to richer
content
Business Value: CIS Vendor
– Adds significant value to system (i.e. CDS)
– Compliant with HL7: easy, seamless
integration
– Level playing field for content
Business Value: Content Vendor
– Leverage investment in content
development/ management/ delivery
– Greater customer value derived from
content
– Customer pull on CIS vendors for MDX
content
– Micromedex plans re: HL7
– ongoing involvement in HL7 standard
– feedback from our experiences
Lessons Learned
• Flexibility in underlying technology (e.g.
HTML/URLs vs. XML for input/output) to meet
the realities of the CIS vendor marketplace.
• Power of highly granular content
development and management is key
• Academic/market analysis of needs, use and
impact is central to continuous improvement
 Collaboration with researchers, HL7, and HIS
vendors is serving as a model for bringing
informatics innovations in content delivery
into widespread use.
Outline
• Why do we need a standard?
• HL7 proposal
– Introduction
– Implementation scenarios
– Parameters and terminology
– Implementation recommendations
– Current status
What are the clinical
manifestations of high
serum potassium?
i
•
•
•
•
65 years old
female
physician
lab results
Infobutton
Manager
• Question formulation
• Resource selection
• Syntax / terminology
translation
Resource 1
Resource 2
Resource 3
Why do we need a standard?
• Difference in message structure and values
– Each resource has its own API syntax
– Various terminologies (free-text is still the norm)
• Multiple ways of expressing an infobutton
query
– Single unstructured parameter, free-text
– Single structured parameter, coded
– Multiple structured parameters, coded
Single unstructured parameter, freetext value
http://www.InformationResource.com/search.cgi
keyword = “hyperkalemia”
Information about
hyperkalemia
i
Single parameter, structured, coded
value
http://www.InformationResource.com/search.cgi
mainConcept = “2823-3^Serum
potassium^LOINC”
labResult = “High”
Information about
high potassium
i
http://www.InformationResource.com/search.cgi
task = labResults
mainConcept = “2823-3^Serum
potassium^LOINC”
labResult = “High”
patientAge = 65
modifier = “Clinical Manifestations”
userRole = Physician
language = English
•Lab results
•65 years old
•Physician
•English
i
What are the
clinical manifestations
of high potassium
No standard in place
API
Clinical
Information
System
i
API
Infobutton
Manager
API
API
Results
(HTML)
Resource 1
Resource 2
Resource 3
Outline
• Why do we need a standard?
• HL7 proposal
– Introduction
– Implementation scenarios
– Parameters and terminology
– Implementation recommendations
– Current status
HL7 proposal
• Support integration between clinical
information systems, infobutton manager
components, and e-resources
• Decision Support Technical Committee
• Based on HL7 V3
– From ad-hoc to well-defined methodology based
on a referecence information model (RIM)
– Reduce optionality
– Allow certification of vendors’ conformance
History
• Initial proposal presented in 2003
– URL-based
– Not HL7 V3 compliant
• Revised version in 2004
– Decision to become V3 compliant
– List of parameters more mature
Participants
• Health care & academic institutions
– IHC, Columbia University, Partners
Healthcare, Cedars-Sinai
• E-resource vendors
– ACP, Micromedex, Wolters Kluwer, First
Data Bank
• CIS vendors
– IDX, Eclypsis, Epic, Cerner
Outline
• Why do we need a standard?
• HL7 proposal
– Introduction
– Implementation scenarios
– Parameters and terminology
– Implementation recommendations
– Current status
Independent IM
HL7
Clinical
Information
System
i
Infobutton
Manager
HL7
(IM)
HL7
HL7
HTML
Second version
Resource 1
Resource 2
Resource 3
CIS has IM
Infobutton
Clinical Manager
Information
System
i
HL7
Resource 1
HL7
HL7
Resource 2
Resource 3
E-resource has IM
Resource 1
HL7
Clinical
Information
System
i
HL7
Resource 2
(infobutton manager)
HL7
Resource 3
Two IMs communicating
Resource 1
HL7
Clinical
Information
System
i
Infobutton
HL7 Manager
HL7
Resource 2
(infobutton manager)
HL7
Resource 3
Outline
• Why do we need a standard?
• HL7 proposal
– Introduction
– Implementation scenarios
– Parameters and terminology
– Implementation recommendations
– Current status
Proposed Parameters
• Authorization
• Main search concept (e.g., problem,
medication)
– Can be associated with a modifier
• Context
– Task (problem list, order entry)
– Care setting (outpatient, inpatient)
– Patient
• Age, gender
– Content recipient
• Language, role (patient, physician, nurse)
Terminology
• Enforced vs. Recommended
• Consolidated Health Informatics
– Medications: RxNorm, NDF-RT
– Labs: LOINC
– Problems: SNOMED-CT
• Other parameters (gender, recipient
role): HL7
Outline
• Why do we need a standard?
• HL7 proposal
– Introduction
– Implementation scenarios
– Parameters and terminology
– Implementation recommendations
– Current status
Implementation Recommendations
• Clinical Information Systems / Infobutton
Managers
– Formulate queries as complete as possible
• E-resources
– Process only the parameters and codes that they
can handle
– Ignore parameters that cannot be handled
• Goal: maximize interoperability and
accelerate adoption
Current Status
• Draft proposal at HL7 web site
• Tasks
– Map proposed parameters to
HL7 RIM
– Define terminologies
– Define message specification
• Implementations based on the current
proposal are available
Questions?
[email protected]
A CIS Vendor’s Perspective
• Christopher
Alban, MD, MBA
• Epic Systems
Corporation
• Overview
– The problem
– The solution
– Testing
– Customer
experiences
– Future directions
The Problem
The Solution
• Historically
– A variety of solutions
• Current solution
– An Epic-defined
“standard”
– Very similar to
proposed HL7
standard
– Testing
• Future
– Migrate our
“standard” to the HL7
standard
Clinical
Information
System
Infobutton
Manager
(IM)
Embedded in CIS
Resource 1
Resource 2
Resource 3
IM with Content Supplier
Testing – Search XML
<search version=”1.0”>
<sessionid></sessionid>
<auth></auth>
<usertype></usertype>
<param type="age"></param>
<param type="sex"></param>
…
<language></language>
<code type="ICD9">493.9</ code>
<code type="ICD9">410.9</ code>
...
<code type="CPT(R)">44950</code>
<code type="CPT(R)">33514</code>
...
<keywords>
<keyword>asthma</keyword>
<keyword>heart attack</keyword>
...
</keywords>
<results>
<max>3</max>
<format>html</format>
<results>
</search>










sessionid - unique number identifying this request.
auth - for vendor to authenticate the request.
usertype - patient/provider (could be used to indicate type of content to
return).
param – context parameters, currently Epic only supports age and sex,
but in the future this list can be extended.
o
age - numeric value in years.
o
sex - male/female/unknown (or blank for unknown)
language - if vendor has content in different languages
code - alphanumeric representation of diagnosis, medication,
procedure, etc.
type – indicates what type of code the value in the <code> node
pertains (e.g. ICD9, CPT®, NDC, GPI, SNOMED, etc.)
keyword – words to search on. Could correspond to codes listed
above or be in addition to the codes.
max - indicate maximum number of results to be returned.
format - xml/html/hl7 desired format of documents returned. Currently
HTML is the only supported format.
Testing – Result XML
<results version=”1.0”>
<sessionid></sessionid>
<error></error>
<result type="">
<location></location>
<title></title>
<preview></preview>
</result>
...
</results>



sessionid - same value that was passed in the search node
error – use this node to return any error information if there is any.
type - may only be useful in MyChart. The idea is that there could be
general news, personal health, etc.

location - could either be a fully formed URL, a query parameter
specifying the document or something in-between which when
clicked/browsed to will return the document in HTML format. See
examples below.

title - is to be displayed in list of results in EpicCare or MyChart

preview - may only be useful in MyChart. It would be used to display a
little blurb about the article after the patient logged in prior to the patient
selecting to view the article (i.e. a thumbnail view).
Examples of <location> node:
If the <location> node were to contain a fully formed URL:

http://www.vendor.com/cough.html

http://www.vendor.com/document=123

http://www.vendor.com/doc=cough
This may be the approach to use if there were no common root for all of the
vendor’s content
If there were a common root then it may be better for the root to be
configured in Epic and then the vendor would return only the ending,
identification piece. For example, "http://www.vendor.com/doc=" would
be configured in Epic and the <location> node returned from the vendor
search would be "123". So, the fully formed URL would be
"http://www.vendor.com/doc=123"
Testing
• Multiple vendors
• Provider and patient oriented content
Search Initiation
Results Return
Customer Experiences
• Patient (consumer)
content in patient
portal
– Custom Infobutton
Managers
– Fully Embedded
Model
• Provider content
– Embedded
Clinical
Information
System
Customer
Infobutton
Manager (IM)
Resource 1
Resource 2
Resource 3
HTML
Future Plans
• Support current variety of models
• Move to current Infobutton precursor
where possible
• Migrate to the HL7 infobutton standard
once it is finalized
Discussion