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. Central Data Repository EMR Application “Traditional EMR” “Monolithic Application”

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. XML ClinicStation Clinical Data Repository “Clinical Source Documents”

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

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

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

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

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

22. Trend – Structured Documents

23. XML Store DataStore Document

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

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

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

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

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

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

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 ExecutingReq/secCPU %Connections Average1435.32.45903 Max149162.218.82778 Min14.00.0829

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