Implementation of FHIR at University of Michigan

Transcription

1 Implementation of FHIR at University of Michigan Early forays into one future of interoperability Connecting Michigan for Health Andrew Rosenberg MD CMIO University of Michigan Health System

2 The Problem/Opportunity Applying real time phenotypic and monitor streaming data with novel analytics to an agnostic mobile integration platform to improve care for variety of Acute Hemodynamic Instability situations (neonate to adult)= Project AHI 2. Need for real time EHR data 3. Vendors not playing nice in the sandbox (don t allow native API s to be used) 4. FHIR, is the ideal solution 5. We don t have FHIR API s in place, but we have a tremendous variety of custom APIs and great developer talent 2

3 Case in Point: Critical Care Processing Big Data: Volume + Variety + Velocity + Voracity We want these data, in real time, for analtyics and mobile device distribution 3

4 Monitoring in the ICU: Filtering noise from real and meaningful data Using APIs 4

5 Logical Use Case Diagram: Acute Hemodynamic Instability Mark Salamango CIO, MCIRCC 5

6 UMHS Epic APIs Background 6

7 UMHS Web Services Long History of Development 7

8 Use and Develop Epic Web Services 8

9 Develop Custom UMHS/Epic Web Services: 9

10 Tools and Education for Web Services within Epic at UMHS 10

11 Epic Foundational Web Services 11

12 UMHS Custom Epic Web Services 12

13 UMHS Custom APIs Details Available for all. 13

14 Recent experience building clinical App using Epic FHIR API Epic FHIR Hackathon March, 18,

15 Proof of Concept; Epic FHIR Hackathon Charlson Comorbidity Scoring System App, using Epic FHIR resources; 1. Patient 2. Condition Developed by Steve Fayz UMHS Developer 15

16 Proof of Concept; Epic FHIR Hackathon Charlson Comorbidity Scoring System 16

17 Proof of Concept; Epic FHIR Hackathon Charlson Comorbidity Scoring System Developed by Steve Fayz UMHS Developer 17

18 Examples 18

19 UMHS Epic EMR APIs (Foundation, Custom vs FHIR) for use by 3 rd party Vendor Data Requirements for Airstrip & UMHS API Allergies FHIR Flowsheets Custom Vitals Custom Labs Custom Meds Epic (copied as custom) or FHIR Patient Lists Custom Pt. Infp Custom Care Team Custom Notes Custom Patient Search Custom Problems/Diag s FHIR We started studying the AirStrip's server API. 3 rd party vendors are not typically able to use foundation epic APIs This is the API their mobile clients call. Behind this API, AirStrip writes an adaptor to different EMRs like Epic, Cerner, Allscripts etc. Our goal is to provide an array of web services for the AirStrip's server to call. 19

20 Example deciding between FHIR or FHIR Like custom Web Service (until FHIR available): Problem and Diagnoses Information 1. For Problems/Diagnoses, AirStrip needs both; problems (often chronic) at patient level visit diagnoses (often acute) at encounter level. 2. For this subject, we only have an Epic Foundation version of web service available. This service includes only active Problems. 3. The FHIR's Condition resource/service was deemed sufficient Create custom Web Service or use a FHIR web service if available when needed. Will use FHIR (or it s specs for custom API) if the latter includes both problems and visit diagnoses. 5. FHIR will be available in Epic 2015 and in Epic 2014 as a SU (special update), aprox Sept, Ideally, we would evaluate Epic's 2015 code and try retrofitting it onto 2014 to enable some FHIR services. FHIR services are just like any other web service we developed. Technical Details: This is accomplished by creating E4C records based on the FHIR definition using Epic Command Builder. This command is mapped to an internal Caché routine which we will implement. The routine gets the data out of Chronicles database and return it to the caller in a FHIR Condition format. 20

21 Epic Problems Web Service Definition example We would end up creating something like this for Problems and Diagnoses if no standard like FHIR exists. It might be acceptable at first, but it can create a issue in terms of maintenance, compatibility, or manageability. 21

22 Data from Epic; Web Services, Intersystems, KB SQL I. Epic Interconnect server. released by Epic some very general web services out of box. separate licenses needed. FHIR Web Services built on this. II. Intersystem Cache web portal develop web service that pulls data from Epic s Cache Db. The Cache web portal is released by Intersystems as part of Cache, no separate license is needed, but Epic does not support this option. III. KB SQL 3 rd party software, SQL interface to Cache Not an API, uses SQL queries, (many already available for Clarity reports) 22

23 Questions & Discussion 23