1 / 22

Detailed Clinical Models for Medical Device Domain Analysis Model

Detailed Clinical Models for Medical Device Domain Analysis Model. Guide to the HL7 May 2011 Ballot. Overview. Detailed Clinical Model (DCM) Atomic clinical information Promote semantic clarity and reuse

karah
Télécharger la présentation

Detailed Clinical Models for Medical Device Domain Analysis Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. 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 • with the information systems • between devices Consistent, repeatable approach/methodology 3 4

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

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

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

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

  11. Post-0perative Transport

  12. Post-0perative Transport

  13. Post-0perative Transport

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

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

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

  17. Patient to Device Association – Interoperable Medical Device Choice 1: Using Hospital Info System (ADT) Choice 2: Enter at point-of-care

  18. Patient to Device Association – Legacy Medical Device Device Manager Choice 1: Location based Choice 3: Patient assigned at point-of-care Choice 3: Patient association using Device Manager

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

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

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

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

More Related