1. Michael van der Zel HIT-Architect University Medical Center Groningen, Netherlands RIMBAA InfoStructure @UMCG WGM Cambridge MA, oct-2010

2. Michael van der Zel september-20102 Agenda Who am I? UMCG & RIMBAA Services From the theme: “If one has a RIM based object store, what services should one define?” Some thoughts about some RIMBAA Issues From the theme: “And how does one query it? - RIMBAA will be duscussing ideas and experiences.”

3. Michael van der Zel september-20103 Me Michael van der Zel Personality (MBTI) INFJ – Idealist, Perfectionist, Chaotic “INFJs prefer the future and the pathway along which they aspire for profundity.” University Medical Center Groningen, Netherlands HIT Architect, Information Systems (EHR-S) Results 4 Care, Netherlands Detailed Clinical Models (ISO), HL7 v3

4. Michael van der Zel september-20104 Tag Cloud ISO Detailed Clinical Model

5. Michael van der Zel september-20105 Service = 1. Interface – functions a service exposes 2. Payload – data that functions work on/with 3. Behaviour – inner working of a function I will present one Service Decomposition in RIMBAA Applications Pattern See also: http://wiki.hl7.org/index.php?title=Service_Decomposition_in_RIMBAA_Applications

6. Michael van der Zel september-20106 http://softwareindustrialization.com/content/binary/design.jpg The Swing

7. Michael van der Zel september-20107

8. 8 What's beneath the surface? Traceability User Request Functional Techology EHR-S FM DCM HL7 v3 CCR/CCD IHE CDA SNOMED CT LOINC etc... ADL Meaningful use XML SAIF Workflow RIMBAA

9. Michael van der Zel september-20109 What is EHR-S FM?

10. Michael van der Zel september-201010 Summary of Care Record (KernEPD) ICT Masterplan Project, Hospital wide Easy access to shared data, Patient Demographics, Allergies, Patient History, Trial, Advance Directives, etc. Choices made: CUI, HL7 v3, SNOMED CT, Web, Detailed Clinical Models, EHR-S FM

11. Michael van der Zel september-201011 DC.1.4.1 Manage Allergy, Intolerance and Adverse Reaction List DC.1.4.1#1 The system SHALL provide the ability to capture true allergy, intolerance, and adverse reaction to drug, dietary or environmental triggers as unique, discrete entries. DC.1.4.1#2 The system SHOULD provide the ability to capture the reason for entry of the allergy, intolerance or adverse reaction. DC.1.4.1#3 The system SHALL provide the ability to capture the reaction type. DC.1.4.1#4: The system SHOULD provide the ability to capture the severity of a reaction. DC.1.4.1#7 The system SHOULD provide the ability to capture the source of allergy, intolerance, and adverse reaction information. DC.1.4.1#8 The system SHALL provide the ability to deactivate an item on the list. DC.1.4.1#9 The system SHALL provide the ability to capture the reason for deactivation of an item on the list. DC.1.4.1#10 The system MAY present allergies, intolerances and adverse reactions that have been deactivated. DC.1.4.1#11 The system MAY NOT provide the ability to display user defined sort order of list. DC.1.4.1#12 The system SHOULD provide the ability to indicate that the list of medications and other agents has been reviewed. DC.1.4.1#13 They system SHALL provide the ability to capture and display the date on which allergy information was entered. Functionally and mostly about Content + CUI Guidance for Recording Adverse Drug Reactions

12. Michael van der Zel september-201012 Function = aprox. Service Rule Engine Care Record Store Service SNOMED CT Terminology Service Authorisation Service Widget & Service HL7 v3 Query Tool Document Service Report Generator

13. Michael van der Zel september-201013 Manage Structured Health Record Information (IN.2.5.2) 1. The system SHALL capture structured health record information as part of the patient EHR. 2. The system SHALL retrieve structured health record information as part of the patient EHR. 3. The system SHALL provide the ability to update structured health record information. 4. The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction) to provide the ability to inactivate, obsolete, or destroy structured health record information. 5. The system SHOULD provide the ability to report structured health record information. 6. The system MAY track structured health record information over time. 7. The system SHOULD provide the ability to retrieve each item of structured health record information discretely within patient context. 8. The system SHALL provide the ability to append corrected structured health record information to the original structured health record information. A specific type of implementation is not implied. 9. The system SHALL provide the ability to append structured health record information to the original structured health record information. A specific type of implementation is not implied. 10. The system SHALL provide the ability to append augmented structured health record information to the original structured health record information. A specific type of implementation is not implied. The Behaviour of the Care Record Store Service and IF Operations

14. Michael van der Zel september-201014 Design inspired by EHR-S FM IN* InfoStructure Functions and Separation of Responsibility

15. Michael van der Zel september-201015 Sequence

16. Michael van der Zel september-201016 IF Kerngegeven Service Functional oriented GetStatus, GetSummary, GetEntries, ActivateEntry, CreateEntry, CompleteEntry, NullifyEntry Trigger names in operations

17. Michael van der Zel september-201017 IF Care Record Store Service CRUD Create, Read, Update, Delete And Find, Query, Link

18. Michael van der Zel september-201018 Payload EHR-S FM function(s) Detailed Clinical Model Convert to Care Record Template DC.1.4.1#4 DC.1.4.1#1 DC.1.4.1#4DC.1.4.1#3 Common Elements added from IN* Patient, Author time, etc. Care Record Template (Logical) DCM Information Model

19. Michael van der Zel september-201019 Care Record XML (Physical)

20. Michael van der Zel september-201020 CDR XML SQL Diagram XMLdb (IBM) MGRID (native support ISO DT!) XML in column (e.g. SQL-Server 2005)

21. Michael van der Zel september-201021 Behaviour HL7 v3 Act Life Cycle

22. Michael van der Zel september-201022 Summary The business requested a way to Record and Share Allergy Records EHR-S FM gives base criteria further specified by interviewing the stakeholders EHR-S FM function traceability gives necessary InfoStructure services Record Detailed with DCM and converted to Care Record CMET

23. Michael van der Zel september-201023 Conclusions EHR-S FM IN* Functions are basis for Services in Healthcare DCM great method to get details of Content HL7 v3 Care Record and Templates a great model for Payload HL7 v3 Act State Model basis for Behaviour Traceability great tool to link Technology to Functionality and Impact

24. Michael van der Zel september-201024 © 2010 Michael van der Zel mvdzel AT results4care.nl m.van.der.zel AT ict.umcg.nl Thanks for your attention