480 likes | 601 Views
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
E N D
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
“Monolithic Application” “Traditional EMR” EMR Application Central Data Repository
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
ClinicStation XML Clinical Data Repository “Clinical Source Documents”
Legacy System Database Stores Clinical Data Automatically available throughout the enterprise Clinical documentation entered directly into legacy system by clinician
Web Services Architecture Client Tier Network Application Tier Network Clinical Data Repository “Clinical Source Documents” Data Tier
Patient Interaction Patient Interaction Dictate Note Dictate Note Edit note Edit note Sign note Sign note Clinical Documentation Review Last Interaction Review Last Interaction Patient Interaction Dictate Note Edit note Sign note
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
Patient Demographics Allergy Review of Systems Height Weight Vital Signs Patient Demographics Pregnancy - Breast Feeding Pain Symptoms – Vital Signs Diabetic History MRI Checklist Review of Systems Allergy Medications Listing Surgical History Height Weight - Vital Signs MRI Experience DI Exam Patient Signature and Checklist Data Authentication
Redundant Clinical Information • Allergies • Family History • Medical/Oncology History • Surgical History • Current Medications • ROS • Patient problem list
XML XML Store Document Store Data
Medication Allergy Web Service Web Service Review of Systems Web Service
Redundant Clinical Information Clinical Web Services • Allergies • Family History • Medical/Oncology History • Surgical History • Current Medications • ROS • Patient problem list
Web services: Beyond EMR • Patient Schedule • ClinicStation • myMDAnderson.org • Patient kiosks • Electronic whiteboards • Diagnostic Imaging (8) • Emergency Center
Web Services: Unlocking data Procedure Comments WS Patient Schedule WS RIS Application DI Patient Tracking WS Radiology Reports WS
Emergency Center Web Services ER Room Census Digital Whiteboard ER Activity Digital Whiteboard (viewable in ICU)
XML-based web service Client Tier XSL HTTP XML Rules Tier Data Source
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
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
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… kmcenery@mdanderson.org csuitor@mdanderson.org