Transcript Detailed Clinical Models for

Detailed Clinical Models for Medical Device
Domain Analysis Model
Catherine Hoang
Ioana Singureanu
Greg Staudenmaier
1
Overview
• 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
•
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
2
– Interoperability
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 Sevenhealthcare interoperability
standards development
organization
• IHE: Integrating the Healthcare
Enterprise – standards-related
consortium
• Continua Health Alliance –
standards-related consortium
specialized in personal
healthcare devices
3
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
4
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
5
Approach
1.
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
2.
3.
4.
Includes standard terminology
bindings
–
Interoperability requirements
•
with the information systems
•
between devices
Consistent, repeatable approach/methodology
Ballot Document Structure and
Process
1
2
3
4
–
6
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
Clinician
Patient
Is a Clinician…
AuthorizedIntubator
AuthorizedExtubator
CareTeamMember
Clinician
roles
Is a Care Team Member…
Care Team Member
roles
RespiratoryTherapist
Transporter
Nurse
Physician
7
Business Use Case Analysis to
specify…
uc 1.1: Intubate Patient - Overview Diagram
Actor
participation
• Use Cases
– Active verb
– Based on
requirements and
clinical scenarios
– Narrative description
AuthorizedIntubator
(from Business Actors)
CareTeamMember
Business
(from Business Actors)
Use Case
perform procedure
participate
Intubate Patient
• Preconditions
• Steps  Workflow
• Postconditions
Intubate Patient
Use Case
…based
«trace» on
«include»
«include»
Patient
(from Business Actors)
– Participants in use cases
– A role relative to the use
case
• Users, systems
Workflow
3
(from 2.1 Intubate Patient Workflow
receive procedure/treatment
• Actors
Process steps detailed here:
Reference to
workflow
Synchronize Time
Associate Device with a
Patient at the
Point-of-care
(from 1.5.1 Patient to Device Association)
(from 1.5.2 Time Synchronization)
Technical
Use Case
8
Device to Patient Association
– State Transitions
stm 1.5.a: Device Assignment and Configuration State Machine
Free
Device
State
assign the device to the patient
[patient identity is verified]
Assigned
break association
Transition
• Patient associated to
one more devices
• Device undergoes state
changes
– connected/disconnected
to patient
– settings configured
Device Assigned
to a Patient
Condition
stm 1.5.b: Assigned Device States
[configure settings]
patient
ready
Active
[connect patient]
Patient
Ready
[disconnect patient]
[connect patient]
Inactive
[configure settings]
[configure setting]
patient
Patient
Not
not
available
Available
9
act 2.2: Manage Patient on Ventilator
Role
Process
Step
Respiratory Therapist :RespiratoryTherapist
Periodic or
alarm-based
1. Conduct respiratory
assessment
Information
produced by a
step
Nurse or Respiratory Therapist :Clinician
[information updated]
«device_data»
Alarm Status
(from 3.1 Information Analysis)
Periodic oral
care
3. Need for
suction
Trigger
Clinical Workflow
[yes]
4. Apply suction
EHR-S and Device
Information
as
Data produced during
the workflow
or used
input into
a step
Oral care
required
during this workflow.
6. Move tube to other side of mouth
Decision
[yes]
[no]
7. Confirm tube placement
8. Disposable
materials
due for change
[input information]
[no]
[yes]
9. Change disposable
materials
«EHR»
Respiratory Consult
Order
(from 3.1 Information Analysis)
Device Data
produced
by a step
10. Provide
oral
care
«device_data»
Pulse Oximetry
10
(from 3.1 Information Analysis)
Attending :Physician
PACU Nurse :Nurse
:Transporter
ICU Nurse :Nurse
Post-0perative Transport
Patient in PACU,
connected to devices
1. Order Patient
Transfer
«EHR»
Transfer Order
15. ICU setup
(from 3.1 Information Analysis)
2. Get patient history,
demographics,
language
3. Get risk factors
«EHR»
Patient Medical History
EHR Data
(from 3.1 Information Analysis)
«EHR»
Risk factors
4. Get allergy
(from 3.1 Information Analysis)
«EHR»
Allergies
5. Get medications
(from 3.1 Information Analysis)
«EHR»
Medication
(from 3.1 Information Analysis)
6. Get IV lines
7. Check disposable
devices
8. Submit a device
request
«device_config»
IV Line Information
16. Set up
Devices
Transfer
completed
(from 3.1 Information Analysis)
«EHR»
Flowsheet
(from 3.1 Information
«EHR» Analysis)
Device Characteristics
Record
(from 3.1 Information Analysis)
«device_data»
Operational Device
Settings
11
5. Get medications
Medication
Transfer
completed
(from 3.1 Information Analysis)
«device_config»
IV Line Information
Post-0perative Transport
6. Get IV lines
(from 3.1 Information Analysis)
«EHR»
Flowsheet
7. Check disposable
devices
(from 3.1 Information
«EHR» Analysis)
Device Characteristics
Record
8. Submit a device
request
Device Data
Device Data
(from 3.1 Information Analysis)
«device_data»
Operational Device
Settings
(from 3.1 Information Analysis)
9. Alert
ICU/Destination
«device_config»
Personalized Device
Settings
10. Check the need for
transport device
[transport device
needed]
11. Transfer
settings to the
transport device
(from 3.1 Information Analysis)
[device will be
replaced at the
destination]
12. Send current
device settings
13. Break device
associations
[device is sent
with the
patient]
14. Move
patient
12
Post-0perative Transport
1. Order Patient
Transfer
«EHR»
Transfer Order
15. ICU setup
(from 3.1 Information Analysis)
2. Get patient history,
demographics,
language
3. Get risk factors
«EHR»
Patient Medical History
(from 3.1 Information Analysis)
«EHR»
Risk factors
4. Get allergy
(from 3.1 Information Analysis)
«EHR»
Allergies
5. Get medications
(from 3.1 Information Analysis)
«EHR»
Medication
(from 3.1 Information Analysis)
6. Get IV lines
7. Check disposable
devices
8. Submit a device
request
«device_config»
IV Line Information
16. Set up
Devices
Transfer
completed
(from 3.1 Information Analysis)
«EHR»
Flowsheet
(from 3.1 Information
«EHR» Analysis)
Device Characteristics
Record
(from 3.1 Information Analysis)
«device_data»
Operational Device
Settings
(from 3.1 Information Analysis)
9. Alert
ICU/Destination
10. Check the need for
transport device
«device_config»
Personalized Device
Settings
(from 3.1 Information Analysis)
13
Technical
Use Case
uc 1.5.a: Time Synchronization for Networked Devices
• Actors: System Roles
• The process steps are
described as system
interactions
• Synchronize Time is a
high-priority requirements
NetworkedMedicalDevice
(from Technical Actors)
NetworkTime
Server Actors)
(from Technical
look up current time
provide current time
Technica
Technical
l Use
Use
Case
Case
Synchronize Time
System
System
role
role
sd 2.5.2.a :Time Synchronization for Networked Devices
NetworkedMedicalDevice
NetworkTime Server
1.0 send(Request)
1.1 SNTPData()
1.2 updateDeviceTime()
14
(from Technical Actors)
(from Technical Actors)
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
LegacyMedicalDevice
(from Technical Actors)
DeviceManager
(from Technical Actors)
correct timestamp, syncrhonize
Medical
Device
Synchronize Time
Device
Manager
provide current time
NetworkTime
Server Actors)
(from Technical
Network
Time Server
15
Time Synchronization +Time Correction
Use case is realized differently for legacy devices vs. networked/interoperable devices
sd 2.5.2.b Time Correction/Substitution for Legacy Devices
Nursing
Flowsheet
LegacyMedicalDevice
DeviceManager
ADT System
NetworkTime Server
opt - DeviceManager is time synchronized
1.0 send(Request)
Synchronization
1.1 SNTPData()
1.2 AddPatient(ADT_A01)
1.3 deviceObservation(NCCLS)
1.4 addTimeStamp()
Time
correction
1.5 addPatientContext()
1.6 deviceObservation(ORU^R01)
(from Technical Actors)
(from Technical Actors)
(from Technical Actors) (from Technical Actors)
(from Technical Actors)
16
Patient to Device Association –
Interoperable Medical Device
sd 2.5.1.a Patient to Device Association
ADT System
MedicalDevice
Nursing
Flowsheet
DeviceManager
opt - Look up patient based on inbound ADT
1.0 ADT(A01)
[ADT is supported]
1.1 lookUpPatient(lastname)
1.2 patientInfo(name, mrn[0..1], account[..1], gender)
Choice 1: Using
Hospital Info
System (ADT)
alt - Barcode or device input
[Barcode Reader Supported]
1.3 readPatientInfo(mrn, id)
Choice 2: Enter at
point-of-care
1.4 persistPatientInfo(mrn, name[0..1], account[0..1])
1.5 perform measurements()
1.6 deviceObservation(ORU^R01)
1.7 deviceObservation(ORU^R01)
The observation contains a reference to the
Patient Info (.e.g. HL7 Version 2.x PID segment).
17
Patient to Device Association –
Legacy Medical Device
Device
Manager
sd 2.5.1.b: Patient to Device Association (Legacy Devices)
LegacyMedicalDevice
Clinician
ADT System
Nursing
Flowsheet
DeviceManager
opt - Configuration Assigns Device to Location
1.0 configure(bedLocation, deviceId)
Choice 1:
Location based
1.2 assignDevice(deviceId, patienId, bedLocation)
1.1 managePatientEncounter(PV1, patientId, bedLocation)
alt - User Assigns Device to Patient
1.3 assignDevice(deviceId, patientId, patientAccount[0..1])
1.4 deviceObservations(NCCLS)
1.5 addPatientContext()
1.6 addTimeStamp()
Choice 2:
Patient assigned at
point-of-care
Choice 3:
Patient
association using
Device Manager
1.7 deviceObservations(ORU^R01)
18
Information Derived from Workflow
Analysis
• High-level, identifies the information
used or produced, precursors to DCMs
object 3.1: Information Analysis
Device
Observation
Device
Configuration
Device Configuration
Device Observations
«device_data»
Alarm Status
«device_data»
Vital Signs
«device_data»
Pulse Oximetry
«device_data»
Operational Device
Settings
«device_config»
Personalized Device
Settings
«device_config»
IV Line Information
«device_config»
Ventilator Parameters
Common/
Shared
Information
«EHR»
Device Characteristics
Record
«EHR»
Respiratory Consult Order
«EHR»
Patient Medical History
Shared Objects
«device,EHR»
Device Association
«device,lab_result»
ABG
«EHR»
Allergies
«EHR»
Chest X-ray Order, Image,
Interpretation
EHR Data
Required
EHR Data
«EHR»
Medication
«EHR»
Risk factors
«EHR»
Procedure
Documentation
«EHR»
Transfer Order
«EHR»
Flowsheet
19
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
object 3.1: Information Analysis
Device
Observation
Device
Configuration
Common/
«EHR»
Respiratory
SharedConsult Order
Information
Device Configuration
Device Observations
«device_data»
Alarm Status
«device_data»
Vital Signs
«device_data»
Pulse Oximetry
«device_data»
Operational Device
Settings
«device_config»
Personalized Device
Settings
«device_config»
IV Line Information
«device_config»
Ventilator Parameters
«EHR»
Device Characteristics
Record
«EHR»
Patient Medical History
Shared Objects
«device,EHR»
Device Association
«device,lab_result»
ABG
«EHR»
Allergies
«EHR»
Chest X-ray Order, Image,
Interpretation
20
Information Analysis to specify context for
DCMs
class
class 3.2.b: Medical Device Analysis
Device
«EHR»
Respiratory
Consult Order
{abstract}
+
+
+
+
+
deviceIdentifier: InstanceIdentifier [1..*]
type: CodedValue
modelNumber: InstanceIdentifier
vendorId: Id
softwareVersion: Text
association
observations
(from 3.1 Information Analysis)
DeviceObservations
repetitions
+performance
+configuration
attribute
DeviceConfiguration
+
mode
+
+
+
+
+
+
+
+
ParameterConfiguration
parameterCode: CodedValue
parameterValue: PhysicalQuantity
effectiveTime: PointInTime
allowableRange: PhysicalQuantityInterval
+
+
accuracy: CodeValueNullable [0..1]
precision: CodeValueNullable [0..1]
qualityOfService: CodeValueNullable [0..
normalRange: PhysicalQuantityInterval
instrumentalExtremeRange: PhysicalQuantit
physiologicalExtremeRange: PhysicalQuantit
patientExtremeRange: PhysicalQuantityInte
Verification
time: PointInTime
verfiedBy
+ severityCode: CodedValue
::Alarm
+ eventCode: CodedValue
+ userMessage: Text
+ statusCode: CodedValue
operatedBy
Alarm
{abstract}
eventCode: CodedValue
Clinician
+
id: InstanceIdentifier
+ name:
PersonName
data
type
for
date/time
Resolution
+
+
ReferenceRange
ReportedAlarmStatus
assignmentTime: PointInTime
unassignmentTime: PointInTime
id: InstanceIdentifier [1..*]
account: InstanceIdentifier [0..1]
+
1..* +
+
+
+
::Alarm
+ eventCode: CodedValue
+ userMessage: Text
+ statusCode: CodedValue
PatientReference
+referenceRange
+alarmReported
AlarmEventConfiguration
+
+
*
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]
+alarmConfiguration
DeviceAssignment
+
+
+
DeviceMeasurement
+parameterConfiguration
+
+
+
+
1
+observation
PerformanceSpecification
date: PointInTime
21
DCMs provide the final level of detail :
Standard Terminology
Reusable data that may be used
in information exchanges
Is a
“Ventilator
Setting”
DCM
Candidate
class 4.1.b: DCMs representing Ventilator Settings
Parameter
properties
Terminology
Constraints
Inherited
Constraints
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 }
22