catherine hoang ioana singureanu greg staudenmaier detailed clinical models for medical device...

1

Catherine HoangIoana Singureanu

Greg Staudenmaier

Detailed Clinical Models for Medical Device

Domain Analysis Model

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

http://www.hl7.org/v3ballot/html/dams/uvdmd/uvdmd.html

http://gforge.hl7.org/gf/project/dcmmd/

http://gforge.hl7.org/gf/project/dcmmd/frs/

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

Approach1. Gathered requirements

illustrated by scenarios, standard operating procedures, and stakeholder requirements

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

3. Next we elaborated the use cases as workflows, step by step, identify the type of information produced or required by each step

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

class A: Approach and Ballot Content

DCM for Medical Device Ballot Publication

Annexes

1. Business/Clinical Use Case

«structured»2. Clinical Workflow

Specifies the scope of the specification;it is revised as new requirements are identified.

3. Analysis Information Model

DCM1

(from 4. Detailed Clinical Models)

DCM2

(from 4. Detailed Clinical Models)

Clinical Scenario(s)

4. Detailed Clinical Models

+ DCM1+ DCM2

Glossary

5. Data Types

(from Detailed Clinical Model (DCM) for Medical Devices)

«import»

«import»

«flow»

«import»

«flow»

basedOn

«flow»

1

2

3

4

Ballot Document Structure and Process

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)

•

uc 1: Business/Clinical Use Case Actors

CareTeamMemberAuthorizedIntubator

RespiratoryTherapistNurse

Physician

Clinician

AuthorizedExtubator

Patient

Transporter

Is a Care Team Member…

Clinicianroles

Is a Clinician…

Care Team Memberroles

8

uc 1.1: Intubate Patient - Overview Diagram

Intubate Patient

AuthorizedIntubator(from Business Actors)

CareTeamMember(from Business Actors)

Patient(from Business Actors)

Intubate Patient

(from 2.1 Intubate Patient Workflow)

Process steps detailed here:

(from 1.5.1 Patient to Device Association)

Associate Device with a Patient at the Point-of-care (from 1.5.2 Time Synchronization)

Synchronize Time

«include»

«include»

perform procedure

participate

receive procedure/treatment

«trace»

Business Use Case Analysis to specify…

• 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

3

Actor participati

on

…based on WorkflowUse Case

Business Use Case

Reference to

workflow

Technical Use Case

Technical Use Case

9

stm 1.5.a: Device Assignment and Configuration State Machine

Free Assigned

break association

assign the device to the patient[patient identity is verified]

Device State Transitio

n

Condition

Device to Patient Association – State Transitions

• Patient associated to one more devices

• Device undergoes state changes– connected/

disconnected to patient

– settings configured

stm 1.5.b: Assigned Device States

Inactive

Active

patientready

patientnotavailable

[configure settings]

[connect patient]

[configure settings]

[disconnect patient]

[connect patient]

[configure setting]

Patient Ready

Patient Not Available

Device Assigned to a

Patient

10

Clin

ical W

ork

flow

act 2.2: Manage Patient on Ventilator

Nurse or Respiratory Therapist :ClinicianRespiratory Therapist :RespiratoryTherapist

1. Conduct respiratory assessment

Periodic oralarm-based

4. Apply suction

3. Need forsuction

6. Move tube to other side of mouth

7. Confirm tube placement

9. Change disposable materials

10. Provide oral care

11. Check monitors

12. Verify continuation of order and changes

Patient judged stable, ventilatorweaning check triggered

8. Disposablematerialsdue for change

«device_data»Alarm Status

(from 3.1 Information Analysis)

EHR-S and Device Data produced duringthe workflow or used during this workflow.

«EHR»Procedure

Documentation


«EHR»Respiratory Consult

Order


«device_data»Vital Signs


«device_data»Pulse Oximetry


Periodic oralcare

Oral carerequired

13. Optimize Ventialtor Setting

[yes]

[yes]

[no]

[update]

[use]

[yes]

[no]

[information updated]

[input information]

Role

Process Step

Information as input into a

step

Information produced by a step

Trigger

Device Data produced by a

step

Decision

11

act 2.4 Transport Patient

ICU Nurse :Nurse:Transporter PACU Nurse :NurseAttending :Physician

1. Order Patient Transfer

Patient in PACU,connected to devices

«EHR»Transfer Order

(from 3.1 Information Analysis)2. Get patient history,

demographics, language

«EHR»Patient Medical History


4. Get allergy

5. Get medications

6. Get IV lines «device_config»

IV Line Information


3. Get risk factors

«EHR»Risk factors


7. Check disposable devices

«EHR»Flowsheet


8. Submit a device request

«EHR»Device Characteristics

Record

(from 3.1 Information Analysis)«device_data»

Operational Device Settings


10. Check the need fortransport device

11. Transfer settings to the

transport device

14. Move patient

12. Send current device settings

9. Alert ICU/Destination

«EHR»Allergies

(from 3.1 Information Analysis)«EHR»

Medication


15. ICU setup

«device_config»Personalized Device

Settings


13. Break device associations

16. Set up Devices

Transfercompleted

[device will bereplaced at thedestination]

[device is sentwith thepatient]

[transport deviceneeded]

Post

-0p

era

tive T

ran

sport

EHR Data

12










4. Get allergy

5. Get medications


IV Line Information


3. Get risk factors

«EHR»Risk factors



«EHR»Flowsheet




Record






transport device

14. Move patient



«EHR»Allergies


Medication


15. ICU setup


Settings



16. Set up Devices

Transfercompleted




Post

-0p

era

tive T

ran

sport

Device DataDevice Data

13










4. Get allergy

5. Get medications


IV Line Information


3. Get risk factors

«EHR»Risk factors



«EHR»Flowsheet




Record






transport device

14. Move patient



«EHR»Allergies


Medication


15. ICU setup


Settings



16. Set up Devices

Transfercompleted




Post

-0p

era

tive T

ran

sport

Information

Received

14

Technical Use Case

• Actors: System Roles• The process steps are

described as system interactions

• Synchronize Time is a high-priority requirementssd 2.5.2.a :Time Synchronization for Networked Devices

NetworkedMedicalDevice

(from Technical Actors)

NetworkTime Server


1.0 send(Request)

1.1 SNTPData()

1.2 updateDeviceTime()

uc 1.5.a: Time Synchronization for Networked Devices

Synchronize Time

NetworkedMedicalDevice(from Technical Actors)

NetworkTime Server(from Technical Actors)

provide current timelook up current time

System role

Technical Use Case

System role

Technical Use Case

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)

uc 1.5.b: Time Syncrhonization for Legacy Devices

Synchronize Time

NetworkTime Server(from Technical Actors)

LegacyMedicalDevice(from Technical Actors)

DeviceManager(from Technical Actors)

correct timestamp, syncrhonize

provide current time

Device Manag

er

Medical

Device

Network Time

Server

16

Time Synchronization +Time Correction

sd 2.5.2.b Time Correction/Substitution for Legacy Devices

LegacyMedicalDevice


DeviceManager


NursingFlowsheet


NetworkTime Server


ADT System


opt - DeviceManager is time synchronized

1.0 send(Request)

1.1 SNTPData()

1.2 AddPatient(ADT_A01)

1.3 deviceObservation(NCCLS)

1.4 addTimeStamp()

1.5 addPatientContext()

1.6 deviceObservation(ORU^R01)

Time correctio

n

Synchronization

Use case is realized differently for legacy devices vs. networked/interoperable devices

17

Patient to Device Association – Interoperable Medical Device

sd 2.5.1.a Patient to Device Association

DeviceManager


MedicalDevice


ADT System


NursingFlowsheet


opt - Look up patient based on inbound ADT

[ADT is supported]

alt - Barcode or device input

[Barcode Reader Supported]

The observation contains a reference to the Patient Info (.e.g. HL7 Version 2.x PID segment).

1.0 ADT(A01)

1.1 lookUpPatient(lastname)

1.2 patientInfo(name, mrn[0..1], account[..1], gender)

1.3 readPatientInfo(mrn, id)

1.4 persistPatientInfo(mrn, name[0..1], account[0..1])

1.5 perform measurements()



Choice 1: Using Hospital

Info System (ADT)

Choice 2: Enter at point-of-care

18

sd 2.5.1.b: Patient to Device Association (Legacy Devices)

LegacyMedicalDevice


DeviceManager


ADT System


NursingFlowsheet


Clinician

(from Business Actors)

alt - User Assigns Device to Patient

opt - Configuration Assigns Device to Location

1.0 configure(bedLocation, deviceId)

1.1 managePatientEncounter(PV1, patientId, bedLocation)

1.2 assignDevice(deviceId, patienId, bedLocation)

1.3 assignDevice(deviceId, patientId, patientAccount[0..1])

1.4 deviceObservations(NCCLS)

1.5 addPatientContext()

1.6 addTimeStamp()

1.7 deviceObservations(ORU^R01)

Patient to Device Association – Legacy Medical Device

Choice 1: Location

based

Choice 3: Patient

association using Device

Manager

Device Manage

r

Choice 2: Patient

assigned at point-of-care

19

object 3.1: Information Analysis


«device,lab_result»ABG

«EHR»Procedure

Documentation



«EHR»Respiratory Consult Order

«EHR»Allergies



Record

«EHR»Flowsheet

«device_config»IV Line Information

«EHR»Chest X-ray Order, Image,

Interpretation

«EHR»Medication

«device_data»Operational Device

Settings «EHR»Patient Medical History


Settings

«device,EHR»Device Association

«EHR»Risk factors

«device_config»Ventilator Parameters

Device Configuration

EHR Data

Device Observations

Shared Objects

Information Derived from Workflow Analysis

• High-level, identifies the information used or produced, precursors to DCMs

Device Observati

on

Device Configuratio

n

Common/Shared

Information

EHR Data Required

20

object 3.1: Information Analysis


«device,lab_result»ABG

«EHR»Procedure

Documentation



«EHR»Respiratory Consult Order

«EHR»Allergies



Record

«EHR»Flowsheet

«device_config»IV Line Information

«EHR»Chest X-ray Order, Image,

Interpretation

«EHR»Medication

«device_data»Operational Device

Settings «EHR»Patient Medical History


Settings

«device,EHR»Device Association

«EHR»Risk factors

«device_config»Ventilator Parameters

Device Configuration

EHR Data

Device Observations

Shared Objects

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 Observati

on

Device Configurati

on

Common/Shared

Information

21

Information Analysis to specify context for DCMs

class 3.2.b: Medical Device Analysis

Device{abstract}

+ deviceIdentifier: InstanceIdentifier [1..*]+ type: CodedValue+ modelNumber: InstanceIdentifier+ vendorId: Id+ softwareVersion: Text

Clinician

+ id: InstanceIdentifier+ name: PersonName

ParameterConfiguration

+ parameterCode: CodedValue+ parameterValue: PhysicalQuantity+ effectiveTime: PointInTime+ allowableRange: PhysicalQuantityInterval

PatientReference

+ id: InstanceIdentifier [1..*]+ account: InstanceIdentifier [0..1]+ name: PersonName [0..1]+ gender: CodedValue [0..1]+ birthDate: PointInTime [0..1]

ReportedAlarmStatus

+ severityCode: CodedValue::Alarm+ eventCode: CodedValue+ userMessage: Text+ statusCode: CodedValue

Alarm{abstract}

+ eventCode: CodedValue+ userMessage: Text+ statusCode: CodedValue

Resolution

+ date: PointInTime

DeviceAssignment

+ assignmentTime: PointInTime+ unassignmentTime: PointInTime

DeviceConfiguration

+ mode

DeviceObservations

«EHR»Respiratory

Consult Order


PerformanceSpecification

+ accuracy: CodeValueNullable [0..1]+ precision: CodeValueNullable [0..1]+ qualityOfService: CodeValueNullable [0..1]

AlarmEventConfiguration

::Alarm+ eventCode: CodedValue+ userMessage: Text+ statusCode: CodedValue

DeviceMeasurement

+ code: CodedValue+ value: PhysicalQuantity+ effectiveTime: PointInTime+ measurementMethod: CodedValue [0..*]+ abnormalFlag: CodedValue [0..1]+ bodyPosition: CodedValue [0..1]+ bodySite: CodedValue [0..1]+ correctedEffectiveTime: PointInTime [0..1]

Verification

+ time: PointInTime

ReferenceRange

+ normalRange: PhysicalQuantityInterval+ instrumentalExtremeRange: PhysicalQuantityInterval [0..1]+ physiologicalExtremeRange: PhysicalQuantityInterval [0..1]+ patientExtremeRange: PhysicalQuantityInterval [0..1]

+configuration

observations

operatedBy

1+observation

*

verfiedBy

+performance

+referenceRange

1..*

+parameterConfiguration

+alarmConfiguration+alarmReported

attribute

class

association

repetitions

data type for

date/time

22

DCMs provide the final level of detail : Standard Terminology

class 4.1.b: DCMs representing Ventilator Settings

VentilatorSetting

«DCM»PressureSupport

::ParameterConfiguration+ parameterCode: CodedValue+ parameterValue: PhysicalQuantity+ effectiveTime: PointInTime+ allowableRange: PhysicalQuantityInterval

constraints{'parameterCode' is encoded and fixed to '20079-0'}{'parameterValue' is expressed in ...}{Not applicable if ventilator is set to volume control mode}

::VentilatorSetting{ 'parameterCode' is encoded using LOINC }{ Use Cases }

DCM Candidat

e

Parameter

properties

Terminology

Constraints

Inherited Constraint

s

Is a “Ventilator Setting”

Reusable data that may be used in information exchanges

catherine hoang ioana singureanu greg staudenmaier detailed clinical models for medical device...

Documents