1. 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

2. 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?

3. 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

4. A Informatics Researcher’s Perspective James J. Cimino, MD Department of Biomedical Informatics Columbia University

5. 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?

6. Video Converter and recorder

7. Portable Usability Lab Video Converter and recorder

8. Morae screen capture

9. 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

10. Context parameters Application Concept of interest Patient age and gender User role Institution

11. 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

12. The Medical Entities Dictionary (MED) Medical Entity Laboratory Procedure CHEM-7 Plasma Glucose Laboratory Specimen Plasma Specimen Substance Sampled Part of Has Specimen Event Laboratory Test Diagnostic Procedure Substance Measured Glucose Plasma Anatomic Substance Bioactive Substance Chemical Carbo- hydrate

13. Translations with the MED Gentamicin Injectable Gentamicin Gentamicn Sensitivity Test Serum Gentamicin Level Gentamicin Toxicity Etiology Measures Sensitivity Substance Measured Has ingredient is-a Intravascular Gentamicin Tests Summary Reports Decision Rule Expert System Drug Information

25. Resource Use By Context

26. Relative Resource Use by Context i i

27. Resource and Infobutton Use

28. User Satisfaction Q1. The website was easy to navigate Q2. I was successful in finding the information I needed Q3. This WebCIS resource was helpful

29. 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…

30. 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

31. 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

32. 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

33. End-user Content Requirements General Trusted, consistent Evidence-based Current Responsive to needs Infobutton-specific Granular Patient-specific

34. 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

35. 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)

36. InfoButton Access - Technology User clicks on InfoButton in EMR Healthcare Series Web Services: http://healthcare.thomsonhc.com/search.cgi?MainSe archConcept=Metformin Content: -DrugPoints -DrugNotes -Disease Briefs -CareNotes Clinical Drug Info: Metformin Hydrochloride Patient Information: Metformin (oral) Context information is “pulled” from the EMR and sent as search request parameters to InfoButton application. InfoButton sends back a direct hit or web page of relevant results: Display options: Single document Document section such as Adult Dose

37. Parameters Accepted ParameterOptions Main Search Concept Clinical Problem (Text/ICD-9) Medication (Text/NDC) Question ModifierInfo subtype, e.g. Adult Dose Information Context Clinician vs. patient-level info Application ContextProblem list vs. medication list Language(for patient ed only) Future: patient age, co-morbid illness, lab values…

38. Infobutton Access Example

41. 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

42. 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

43. Business Value: CIS Vendor –Adds significant value to system (i.e. CDS) –Compliant with HL7: easy, seamless integration –Level playing field for content

44. 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

45. 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.

46. Outline Why do we need a standard? HL7 proposal –Introduction –Implementation scenarios –Parameters and terminology –Implementation recommendations –Current status

47. i What are the clinical manifestations of high serum potassium? 65 years old female physician lab results Resource 3 Resource 1 Resource 2 Infobutton Manager Question formulation Resource selection Syntax / terminology translation

48. 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

49. http://www.InformationResource.com/search.cgi keyword = “hyperkalemia” Information about hyperkalemia i Single unstructured parameter, free- text value

50. http://www.InformationResource.com/search.cgi mainConcept = “2823-3 ^ Serum potassium^LOINC” labResult = “High” Information about high potassium i Single parameter, structured, coded value

51. What are the clinical manifestations of high potassium Lab results 65 years old Physician English 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 i

52. Resource 3 Resource 1 Resource 2 Infobutton Manager API No standard in place Clinical Information System i Results (HTML)

53. Outline Why do we need a standard? HL7 proposal –Introduction –Implementation scenarios –Parameters and terminology –Implementation recommendations –Current status

54. 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

55. 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

56. 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

57. Outline Why do we need a standard? HL7 proposal –Introduction –Implementation scenarios –Parameters and terminology –Implementation recommendations –Current status

58. Clinical Information System i Resource 3 Resource 1 Resource 2 HL7 Infobutton Manager (IM) HL7 Independent IM HTML Second version

59. CIS has IM Resource 3 Resource 1 Resource 2 HL7 Clinical Information System Infobutton Manager i

60. E-resource has IM Clinical Information System i Resource 2 (infobutton manager) HL7 Resource 3 Resource 1 HL7

61. Two IMs communicating Clinical Information System i Resource 2 (infobutton manager) HL7 Resource 3 HL7 Infobutton Manager HL7 Resource 1 HL7

62. Outline Why do we need a standard? HL7 proposal –Introduction –Implementation scenarios –Parameters and terminology –Implementation recommendations –Current status

63. 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)

64. Terminology Enforced vs. Recommended Consolidated Health Informatics –Medications: RxNorm, NDF-RT –Labs: LOINC –Problems: SNOMED-CT Other parameters (gender, recipient role): HL7

65. Outline Why do we need a standard? HL7 proposal –Introduction –Implementation scenarios –Parameters and terminology –Implementation recommendations –Current status

66. 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

67. 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

68. Questions? guilherme.delfiol@ihc.com

69. A CIS Vendor’s Perspective Christopher Alban, MD, MBA Epic Systems Corporation Overview –The problem –The solution –Testing –Customer experiences –Future directions

70. The Problem

71. 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 Resource 3 Resource 1 Resource 2 Infobutton Manager (IM) Embedded in CIS IM with Content Supplier

72. Testing – Search XML … 493.9 410.9... 44950 33514... asthma heart attack... 3 html  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 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.

73. Testing – Result XML...  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 node: If the 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 node returned from the vendor search would be "123". So, the fully formed URL would be "http://www.vendor.com/doc=123"

74. Testing Multiple vendors Provider and patient oriented content Search Initiation Results Return

75. Customer Experiences Patient (consumer) content in patient portal –Custom Infobutton Managers –Fully Embedded Model Provider content –Embedded Clinical Information System Resource 3 Resource 1 Resource 2 Customer Infobutton Manager (IM) HTML

76. Future Plans Support current variety of models Move to current Infobutton precursor where possible Migrate to the HL7 infobutton standard once it is finalized

77. Discussion