Implementation of Web Services Based Electronic Medical Record

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

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

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

4. 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$$$$$$$

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

6. Web Services • Enterprise EMR implementation? • Scalability? • Security? • Institutional support requirements?

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

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

10. Conventional System Architecture“Monolithic Application” RIS Application

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

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

13. ClinicStation XML Clinical Data Repository “Clinical Source Documents”

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

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

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

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

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

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

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

22. Trend – Structured Documents

23. XML XML Store Document Store Data

24. Medication Allergy Web Service Web Service Review of Systems Web Service

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

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

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

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

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

30. Web Services: XML data

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

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

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

34. Web Services Architectures • Multiple Web Services • # Web Services = # Functions • Single Web Service • 1 Web Service • Many Functions

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

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

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

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

39. Monitoring Components

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

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

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

43. MDACC Performance • Data collected every 5 seconds over a 24 hour period

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

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

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

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

48. Discussion… kmcenery@mdanderson.org csuitor@mdanderson.org