220 likes | 374 Views
Detailed Clinical Models for Medical Device Domain Analysis Model. Catherine Hoang Ioana Singureanu Greg Staudenmaier. Overview. Detailed Clinical Model (DCM) Atomic clinical information Promote semantic clarity and reuse
E N D
Detailed Clinical Models for Medical Device Domain Analysis Model Catherine Hoang Ioana Singureanu Greg Staudenmaier
Overview • Detailed Clinical Model (DCM) • Atomic 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 support • Process improvement • Interoperability and automation • Reusable in many contexts • New standards • Profiling existing standards • Application development • Interoperability • Domain Analysis Model (DAM) • Describe the stakeholders requirements to a integrators, developers, vendors, etc. • Assist communication among stakeholder groups • Uses a Std. modeling language (UML) improves communication, identifies main concepts, and leads to consensus • Models can be used to generate code or other models (e.g. ontology) • Methodology that supports the development of DCMs • Context for DCMs
Glossary • DAM: Domain Analysis Model • UML: Unified Modeling Language – a standard developed by the Object Management Group • DCM: Detailed Clinical Model – reusable information models, standardized • LOINC: Logical Observation Identifiers Names and Codes – standard codes for laboratory • SNOMED-CT: Systematized Nomenclature of Medicine--Clinical Terms – Terminology System • ISO: International Organization for Standardization – standards development organization • HL7: Health Level Seven- healthcare interoperability standards development organization • IHE: Integrating the Healthcare Enterprise – standards-related consortium • Continua Health Alliance – standards-related consortium specialized in personal healthcare devices
May 2011: 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 requirements (e.g. RFP) • by consortia (e.g. IHE, Continua Health Alliance) • To develop Integration and Content Profile • by standard development organizations (e.g. HL7, ISO) • 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/ • Latest project artifacts
Specification history 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 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 • Patient-to-device Association • Time Synchronization for Networked Devices and for Legacy Devices
Approach Ballot Document Structure and Process 1 2 • Gathered requirements illustrated by scenarios, standard operating procedures, and stakeholder requirements • Use cases that were derived from clinical scenario illustrate the requirements in a precise way. Use cases identify the capabilities and user or system roles involved . • Next we elaborated the use cases as workflows, step by step, identify the type of information produced or required by each step • Refine the information structures (correspond to device data) required to support workflow • Includes standard terminology bindings • Interoperability requirements • with the information systems • between devices Consistent, repeatable approach/methodology 3 4
Actors to specify roles for business users relative to the use cases in scope • Identify 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
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
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
Clinical Workflow Role Information produced by a step Process Step Trigger Information as input into a step Decision Device Data produced by a step
Post-0perative Transport EHR Data
Post-0perative Transport Device Data Device Data
InformationReceived Post-0perative Transport
Technical Use Case • Actors: System Roles • The process steps are described as system interactions • Synchronize Time is a high-priority requirements Technical Use Case System role Technical Use Case System role
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
Time Synchronization +Time Correction Use case is realized differently for legacy devices vs. networked/interoperable devices Synchronization Time correction
Patient to Device Association – Interoperable Medical Device Choice 1: Using Hospital Info System (ADT) Choice 2: Enter at point-of-care
Patient to Device Association – Legacy Medical Device Device Manager Choice 1: Location based Choice 2: Patient assigned at point-of-care Choice 3: Patient association using Device Manager
Information Derived from Workflow Analysis EHR Data Required • High-level, identifies the information used or produced, precursors to DCMs Device Configuration Device Observation Common/Shared Information
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
Information Analysis to specify context for DCMs class association repetitions attribute data type for date/time
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