Acknowledgements

1. Generation of Context-SpecificePCRs using Domain-SpecificModelingMOTHIS WorkshopNashville, TN, Sept 30, 2007Rohit Shenvi(rshenvi@uab.edu)Dept. of Computer and Information SciencesAdvNet Project, HI, Dept. of HSA University of Alabama at Birmingham

2. Acknowledgements • Advisors: • Helmuth Orthner, PhD, Professor of Health Informatics, Department of Health Services Administration, UAB • Jeff Gray, PhD, Associate Professor, Department of Computer and Information Sciences, UAB • Collaborators: • Giovanni Mazza, MSHI, MSCS, System Manager, AdvNet Project, Health Informatics, Dept. of Health Services Admin., UAB • Devashish Saini, MD, MSHI, Resident Physician, University of Missouri-Columbia • Marcie Battles, MSEE, AdvNet Project Manager, HI, Dept. HSA • Support: • This project has been funded by Federal funds from the National Library of Medicine, NIH, under Contract No. N01-LM-3-3513 and the National Science Foundation, under CAREER grant CCF-0643725.

3. Overview of Presentation • EMS Environment and Workflow • Electronic Patient Care Report (ePCR) Project • ePCR Development: Modular Approach • CAB, CSLA, WCF, WPF • ePCR Model Design: GME • Domain-Specific Modeling in EMS • Summary • Lessons Learned

4. EMS Patient Flow EMT Assesses, Treats & Transports Patient 9-1-1 Dispatcher Ambulance dispatched Treatment Patient Triage & Transport Hospital ED

5. Patient Care Report (PCR) EMT Assesses, Treats & Transports Patient

6. Issues and Problems • Most EMTs have moderate typing skills • Little or moderate experience with computers • Concerned about extra work • “Paper + Computer = Slower Work” • EMS (paper) documentation is a problem • Over 60% of required data elements are missing (Mandar Gori's Thesis Project) • Adherence to clinical protocols is low • Could be a documentation problem • Contact is with Online Medical Control is avoided even when required (Dr. Devashish Saini’s MSHI Thesis)

7. ePCR Project • Data acquisition using ePCR • User Friendly Interfaces to Enter Data with Minimum Actions • Implementation of Security Mechanisms such as Encryption and Authorized Access to Patient Data • Sharing data collected in the field • Collect National EMS Information System (NEMSIS)-compliant data • Web Services to push/pull patient data to/from ePCR terminal • Transmitting Data to the Central Station

8. Paper vs. Electronic ePCR PCR

9. Initial Prototype: Burns

10. Initial Lessons Learned Developing new User Interfaces is very labor intensive Maintenance and Scalability difficult because business logic is intertwined throughout the application EMS agencies require customization of the ePCR GUI and Business layer Usability Study of ePCR UI requires quick development of various design alternatives

11. 2nd Prototype: Modular Approach InitialApproach Modular Approach 11

12. 2nd Prototype: Modular Approach Layered Architecture Presentation User Interface Business Logic Data Validation: Range Checking Data Manipulation Conversion from common units to international units Data Layer ADO.NET Data Storage 12

13. Domain-Specific Modeling • Identify entities in the domain that need to be modeled • Design the metamodel • Build model interpreter • Design the domain-specific model

14. Domain-Specific Modeling 14

15. Domain-Specific Modeling • Promises • Generation of platform specific systems • Reduced turnaround time • Improves user-developer interaction during system development

16. Domain-Specific Modeling in EMS • Business layer needs to adapt for new requirements • Patient category (pediatric, adult, geriatric, etc.) • Medical devices (pulse ox, EKG, etc.) • Drug-drug interaction engine integration with the ePCR • UI automation

17. Domain-Specific Modeling in EMS • Drug interactions • Needs to be integrated within the ePCR • Domain-specific modeling to generate wrapper code on the drug interaction API for the ePCR • Our focus • Generation of business and data layer using domain- specific modeling

18. ePCR Model Design: GME • ePCR • MandatoryBO • OptionalBO • PropertyOf_Mandatory • PropertyOf_Optional • MandatoryConn • OptCon ePCR metamodel

19. ePCR Model Design: GME • ePCR Context • Demographics • Vitals • Assessment • Treatment • Narrative • Attachments • Billing • Triage ePCR domain-specific model

20. Model to Code Transformation • Transformation logic • Each object transforms to a CSLA business class • Each objects’ properties are converted to C# code

21. Lessons Learned • It is difficult to implement new business rules and modify existing ones without affecting the modules where they are found • Need a mechanism to inject rules into objects at run time • The specification of the rules should be done in a simple unambiguous language and translated later to executable code

22. Limitations and Future Work • Limitations of Metamodel • Initial attempt at building the metamodel. It does not contain the constructs for complex business objects • Limitations of Interpreter Functionality • Not implemented to generate full fledged CSLA business objects • Experimental Validations • Formal verification and validation not done

23. Conclusions • We discussed issues related to ePCR development • Deficiencies and improvements • We introduced the modeling paradigm • Areas potentially benefiting by domain-specific modeling languages • A partial implementation of the ePCR business layer was illustrated

24. Generation of Context-SpecificePCRs using Domain-SpecificModelingQuestions & Thank YouRohit Shenvi(rshenvi@uab.edu)Dept. of Computer and Information SciencesAdvNet Project, HI, Dept. of HSA University of Alabama at Birmingham

25. Model to Code Transformation 25

26. Initial Prototype: Vitals

27. Methodology • UI design using WPF and CAB • WPF: Windows Presentation Foundation • CAB: Composite UI Application Block • Business and data layer using CSLA • CSLA: Component-Based Scalable Logical Architecture • Communication layer using WCF • WCF: Windows Communication Foundation

28. Domain-Specific Modeling in EMS • Motivation • Modeling paradigm • Promises • Potential areas of implementation in the ePCR development cycle