Detailed Clinical Models for Medical Device – Domain Analysis Model –

1. Detailed Clinical Models for Medical Device – Domain Analysis Model – Guide to the HL7 May 2011 Ballot

2. Overview This presentation is intended to help subject matter experts review the Domain Analysis Model intended to derive Detailed Clinical Models for Medical Devices • Detailed Clinical Model (DCM) • Describes clinical information • Promote semantic clarity and reuse • Standard Terminology is built-in rather than an afterthought (e.g. primary and secondary standard-based coding system) • Structured information to • Process improvement • Interoperabilityand automation • Reusable in many contexts • Application development • Interoperability • New standards • Profiling existing standards • Domain Analysis Models • Describe the stakeholders requirements to a integrators, developers, vendors, etc. • Communication among stakeholder groups • Modeling language helps communication, identifies main concepts, and leads to consensus • Methodology that supports the development of DCMs

3. Ballot Details • This ballot is informative and will expanded as new requirements and use cases are identified • The ballot artifacts are intended to be used: • by providers • To express semantic interoperability needs requirements (e.g. RFPs) • by consortia • To develop IHE Integration and Content Profile • by standard development organizations • To develop new standards for interoperability • Ballot: V3 Ballot  Domain Analysis Models: • http://www.hl7.org/v3ballot/html/dams/uvdmd/uvdmd.html • Project Site: http://gforge.hl7.org/gf/project/dcmmd/ • Releases: http://gforge.hl7.org/gf/project/dcmmd/frs/

4. Specification history • May 2011 - Informative In addition to addressing the ballot comments, this ballot includes additional use cases that are a high priority for the project stakeholders.: • Post-Operative Patient Transport (from PACU to ICU) • Patient-to-device Association • Time Synchronization for Networked Devices and for Legacy Devices • September 2010 - Draft for Comment Initial version documenting the Domain Analysis for the following use cases: • .Intubate Patient - Unplanned • Manage Patient on Ventilator • Liberate Patient from Ventilator, Planned

5. Approach Ballot Document Structure and Process 1 2 • Requirements illustrated by scenarios, standard operating procedures, and stakeholder requirements • Use cases identify the capabilities and users involved • Details use cases as clinical scenarios • Define information required to support the clinical workflow and interoperability between the systems involved including terminology The subject matter experts may review chapters 1 through 4 and the Annexes. Chapter 5 is a technical data type specification used to support modeling. 3 4

6. Actors to specify roles for business users relative to the use cases in scope • Indentify the users roles and/or system roles for users and systems involved in the clinical scenario(s) Is a Clinician… Clinician roles Is a Care Team Member… Care Team Member roles

7. Business Use Case Analysis to specify… Actor participation • Use Cases • Active verb • Based on requirements andclinical scenarios • Narrative description • Preconditions • Steps  Workflow • Postconditions • Actors • Participants in use cases • A role relative to the use case • Users, systems Business Use Case …based on Workflow Use Case 3 Reference to workflow Technical Use Case Technical Use Case

8. Device to Patient Association – State Transitions • Patient associated to one more devices • Device undergoes state changes • connected/disconnected to patient • settings configured Device Assigned to a Patient Device State Condition Transition Patient Ready Patient Not Available

9. Role Information produced by a step Clinical Workflow Process Step Trigger Information as input into a step Decision Device Data produced by a step

10. Technical Use Case • Actors: System Roles • The process steps are described as system interactions • Synchronize Time is a high-priority requirements Technical Use Case Technical Use Case System role System role

11. Time Synchronization for Legacy Devices • Legacy Devices are unable to synchronize time automatically • Missing network connection • Missing support for protocol (SNTP) • Device Manager required to • report device observation and parameters • Synchronized • It supplies time correction information (synchronized time) Medical Device Device Manager Network Time Server

12. Time Synchronization +Time Correction Use case is realized differently for legacy devices vs. networked/interoperable devices Synchronization Time correction

13. Patient to Device Association – Interoperable Medical Device Choice 1: Using ADT Choice 2: Enter at POC

14. Patient to Device Association – Legacy Medical Device Device Manager Choice 1: Using ADT Choice 2: Enter at POC

15. Information Derived from Workflow Analysis EHRS Data Required • High-level, identifies the information used or produced, precursors to DCMs Device Configuration Device Observation Common/Shared Information

16. Focus of the analysis: Medical Device Interoperability • Emphasis on device-to-device and device-to-system interoperability and automation • We specify the structure of relevant types of data Device Configuration Device Observation Common/Shared Information

17. Information Analysis to specify context for DCMs class association repetitions attribute Data type for date/time

18. DCMs provide the final level of detail : Standard Terminology Is a “Ventilator Setting” DCM Candidate Reusable data that may be used in information exchanges Parameter properties Terminology Constraints Inherited Constraints