Implementation of Web Services Based Electronic Medical Record Kevin W. McEnery, M.D. Charles T. Suitor, M.S. U.T. M. D. Anderson Cancer Center Houston, TX

Web Services EMR Why web services Advantages over traditional EMR Review implementation Current status Discuss technical details Security, scalability National Health Information Infrastructure and WS Questions

EMR Project overview Legacy systems were on a variety of platforms No single access method could retrieve all the data we needed. The technical solution had to be affordable, and we had to be able to implement it quickly.

Traditional EMR Model Limitations Institutional Data Model may not easily map into EMR vendor’s data model Legacy systems have an inherent data structure EMR have their own data structure These may be incompatible EMR application workflow does not easily mesh with institution’s workflow EMR application customization$$$$$$ Institutional training session$$$$$ Long project delay$$$$ Numerous failure example$$$$$$$

Institution’s strategic decision Departmental systems best meet the needs of the business unit System selection not biased toward EMR Radiology – Siemens RIS, Stentor PACS Pathology – Tamtron Laboratory – Cerner Operating room – PICIS Pharmacy – GE BDM

Web Services Enterprise EMR implementation? Scalability? Security? Institutional support requirements ?

“I ask Congress to move forward on a comprehensive health care agenda… improved information technology to prevent medical errors and needless costs…” George W. Bush, State of the Union, 2005

Each folder is web service Allergies Reports Radiology Laboratory Pathology Images Pharmacy Cardiology OR Schedule Clinic Schedule Hospital Census

Conventional System Architecture “Monolithic Application” RIS Application

Central Data Repository EMR Application “Traditional EMR” “Monolithic Application”

Web Services Implementation Multiple clinical data sources already existed Level of enterprise availability varies e.g. Pharmacy system allergy data Legacy systems address needs of owners “Best of breed sub-systems” RIS, LIS, anatomic pathology… Single vendor solution unlikely Single legacy system contains official result Radiology report in RIS Path reports in pathology system

XML ClinicStation Clinical Data Repository “Clinical Source Documents”

Legacy System Database Stores Clinical Data Clinical documentation entered directly into legacy system by clinician Automatically available throughout the enterprise

Application Tier Client Tier Web Services Architecture Network Clinical Data Repository “Clinical Source Documents”

Clinical Documentation Patient Interaction Dictate Note Edit note Sign note Patient Interaction Dictate Note Edit note Sign note Patient Interaction Dictate Note Edit note Sign note Review Last Interaction

Limitations of “traditional” clinical data Much clinical data non-structured Dictated clinical notes Handwritten clinical notes Medical images Limited information regarding image content No current accepted, or legislated, standard regarding structured clinical data Exception: Pathology, Mammography Limited capability to automatically share clinical data across enterprise

Standardization of clinical data Recorded at the appropriate level of detail Consistent over time and across boundaries Transmitted without loss of meaning Aggregated at more general levels and along multiple different perspectives Interpreted by automated systems Modified from SNOMED Overview – American College of Pathologists

Allergy Medications Listing Review of Systems Height Weight-Vital Signs MRI Checklist Surgical History MRI Experience Signature and Authentication Patient Demographics DI Exam Patient Checklist Data Pain Symptoms– Vital Signs Diabetic History Pregnancy-Breast Feeding Patient Demographics Height Weight Vital Signs Review of Systems Allergy

Redundant Clinical Information Allergies Family History Medical/Oncology History Surgical History Current Medications ROS Patient problem list

Trend – Structured Documents

XML Store DataStore Document

Allergy Web Service Review of Systems Web Service Medication Web Service

Clinical Web Services Allergies Family History Medical/Oncology History Surgical History Current Medications ROS Patient problem list Redundant Clinical Information

Web services: Beyond EMR Patient Schedule ClinicStation myMDAnderson.org Patient kiosks Electronic whiteboards Diagnostic Imaging (8) Emergency Center

Web Services: Unlocking data RIS Application Radiology Reports WS DI Patient Tracking WS Procedure Comments WS Patient Schedule WS

Emergency Center Web Services ER Activity Digital Whiteboard (viewable in ICU) ER Room Census Digital Whiteboard

Data Source XML-based web service Rules Tier Client Tier XML XSL HTTP

Web Services: XML data

Distributed clinical architecture Services-based architecture provide a standard method to access and update clinical data Numerous applications possible Structured data flows to client XML Client formats and interacts with data for display Structured data flows to server XML

Will it scale? Instant access to clinical information >100 transactions/second >1,200,000 patient queries per month >50M audit event per month

6,197 computers 52.2 million transactions/month 5,753 users 1,073 physician users

Web Services Architectures Multiple Web Services # Web Services = # Functions Single Web Service 1 Web Service Many Functions

Building Web Services Clients call functions via a web server Examples GetRadiologyReport(Accession) GetLabProcedures(MRN)

Building Web Services Each Web Service must have several features Security Auditing Maintainability Specific business logic

Building Web Services Solve the common problems once Provide a single Web Service that provides Security – most likely a session Auditing – in and out available Dispatching to work components

Building Web Services Individual functions can be components (i.e. GetRadReport) Business logic only, no security or auditing Each function/component can be independently updated and monitored

Monitoring Components

Characteristics of Components Stateless Especially important for server farms Short execution time Keeps simultaneous execution down

Characteristics of Components Single Function per Component Easier to maintain & update Designed for multiple instances executing simultaneously Proper threading model No shared resources

MDACC Server Configuration 10 server farm, load distributed, via hardware network load balancer Each server is dual processor, 2GB RAM, Win2K Server Commodity pricing Robust performance

MDACC Performance Data collected every 5 seconds over a 24 hour period ExecutingReq/secCPU %Connections Average Max Min

Web Services Web Services aren’t magic Web Services systems only scale if they are designed to scale We have encountered a commercial Web Services HIT system with limited throughput 10 simultaneous queries, 3 sec/query

Integration Capabilities of legacy systems need to be considered Underpowered systems can be protected with a cache Query based cache HL7 replication based cache

Web Services EMR Web-services can provide a method for universal access to clinical information already available in legacy systems Alternative to centralized archive Best of breed legacy sub-systems

Web Services Enterprise implementation? Yes and growing… Can it scale? 1.2M patient queries/month Are they secure? Yes and meet HIPAA audit requirements What are institutional support requirements ? Minimal day to day Leverage existing institutional investment

Discussion…