Transcript MD PnP Program Status - OpenHealthTools

Sept 14, 2012
OHT BoD Meeting
Baltimore, MD
OHT Medical Device Platform
Current thinking and activities
Julian M. Goldman, MD, Dave Arney
Mass Gen Hospital/CIMIT
Program on Medical Device Interoperability
E-card www.mdpnp.org
We have come a long way … in some areas …
“Smart Phones” are
“App Platforms”,
designed to enable
developers to use
processors, sensors,
data, and screen UI to
deliver Apps.
• Gyro/motion sensors
• Mic and speakers
• Radios (many!)
• GPS
• Operating System
designed to
effectively deliver
App requirements
What could healthcare “apps” do?
That depends on the “app platform”
This type of app is very useful.
But it is not the subject of today’s discussion
Imagine if apps could connect to the
sensors/devices in the physical environment,
they could finally solve some of these clinical
problems
Clinical care: Is
not neat and
tidy.
Poor access to
data, only
manual
coordination of
devices.
When standardized clinical databases are populated with standardized
data, validated clinical rules or “Apps” will be shared globally
Validated Clinical “Apps”
Validated Clinical “Apps”
Validated Clinical “Apps”
Validated Clinical “Apps”
Crowdsourcing of clinical apps could transform healthcare
J. Goldman, MD 2005-2012
Medical Device “Plug-and-Play”
Interoperability Program (MD PnP)
Founded in 2004, the MD PnP research program is a
multi-institutional community based at CIMIT and MGH.
Mission: lead the adoption of medical device
interoperability to improve patient safety
Funding: DoD/TATRC, NSF, NIST, NIH/NIBIB, CIMIT,
to develop open platform and test-bed to enable apps to
coordinate medical devices to improve the safety and
efficiency of diagnosis and therapy
MD PnP Program Status
• The program is at an inflection point
• Work to now has focused on developing demo
systems, gathering clinical and technical requirements,
and building developer and end-user communities
• We are now at a point where we are starting to build
‘real’ components, and beginning to publish code
online
• Major goals for the coming year:
– Build and release lots of code
– Get our developer and end-user communities involved
MD PnP Lab
One of our developers took some snapshots earlier today.
The lab is usually this messy- we clean it up for demos.
Lots of devices coming through, lots of projects going on.
MD PnP Lab
New system from CPC installed Wednesday:
Collects data from Ivy Patient monitor and anesthesia machine,
adding pump connectivity soon
Supports some limited control of monitor
MD PnP Lab
Patient Simulation is a challenge. Shown here are three patient simulators, a Philips
patient monitor, and several other devices. Not shown is a capnography simulator and
test lung.
Synchronizing patient simulators to create a coherent, realistic clinical use case is
difficult.
We’re looking forward to tying this work into OHT patient data repositories and
artificially generated patient data.
Conference: June 2007
2011 MD PnP Open House
MD PnP Programming Projects
• We have started posting code to github.com/mdpnp
• This year we plan to release code of interest to a broad community,
starting with device interface code, adding more as it matures
• We're developing a strategy & timeline for code release, would like
to talk with other OHT members about this
• MDCF has a large repository, there is agreement to link this in
• Other related projects include:
–
–
–
–
–
Penn/FDA GIP work
MD PnP DoD-supported Data Logger work
NwHIN CONNECT and DIRECT
HITIDE
Pan-SHARP demos
Hardware and Development
Environment
• Working with QNX and Intel on hardware
• Exploring requirements and options for embedded OS /
RTOS
• Working with RTI for their DDS middleware implementation
via a community use license
• Evaluating DDS for ICE applications with an eye to
commenting on the public DDS standard
• Current development is using BeagleBoard and BeagleBone
boards for device adapters and network controller
• The MD PnP lab contains a large and growing collection of
devices and networking equipment. This is a key resource
available to collaborators.
MD PnP Communities
• We've just started publicly posting code, but have been
developing a user and developer community for many
years.
• Figuring out how to get that community involved in the
public code is an important goal for this year.
• As is growing the community and getting more users
and developers involved.
• Community building is a funded aim of our new
DoD/TATRC grant and important to the success of the
NIH Quantum Interoperability project
MD PnP Program Collaborators
MD PnP Lab
• Located in Cambridge, MA
• Vender-neutral sandbox for experimenting with
device interoperability
• Contains devices from many of our partners and
others, some donated or loaned, more purchased
• Supports remote collaborators over network
– For specific protocols (NwHIN CONNECT, DIRECT)
– Or VPN into research network for direct connection to
devices
RESOLVED, That our American Medical Association (AMA)
believes that intercommunication and interoperability of
electronic medical devices could lead to important advances in
patient safety and patient care, and that the standards and
protocols to allow such seamless intercommunication should be
developed fully with these advances in mind. Our AMA also
recognizes that, as in all technological advances, interoperability
poses safety and medico-legal challenges as well … ”
as of July 2009:
Anesthesia Patient Safety Foundation
Society for Technology in Anesthesia
Society of American Gastrointestinal Endoscopic Surgeons
American Medical Association
World Federation of Societies of Anesthesiologists
American Society of Anesthesiologists
Massachusetts Medical Society
MD FIRE
Medical Device “Free Interoperability
Requirements for the Enterprise”
• Position Statement & Sample of Interoperability RFP and
Contract language
• Developed by Mass General Hospital / Partners, Johns
Hopkins, Kaiser Permanente via MD PnP research program
• Conveys healthcare needs to industry, and simplify
purchasing specifications
• V2 published in August 2012 added VA
5 Stakeholder groups from each organization:
Purchasing/materials management, BME, IS, Clinical, Legal
Download MD FIRE from www.mdpnp.org
MD FIRE
• “Healthcare Delivery
Organizations (HDOs) must
lead a call to action for
interoperability of medical
devices and systems.
• One way that HDOs can
effect this change is by
including medical device
interoperability as an
essential element in the
procurement process and in
vendor selection criteria.”
Download: mdpnp.org/MD_FIRE.php
Commissioner's Grid plan for
Manhattan (adopted 1811)
The Commissioners' Plan of 1811 was the
original design plan for the streets of
Manhattan, which put in place the grid plan
that has defined Manhattan to this day.
It originated as a proposal by the New York
State Legislature, adopted in 1811 for the
orderly development and sale of the land of
Manhattan between 14th Street and
Washington Heights. The plan is arguably the
most famous use of the grid plan and is
considered by most historians to have been
far-reaching and visionary.
http://en.wikipedia.org/wiki/Commissioners'_Plan_of_1811
http://www.library.cornell.edu/Reps/DOCS/nyc1811.htm
The NIST Medical device interoperability
Health IT project
• Requirements Analysis – Scenario-based functional decomposition of ICE
requirements
• Gap Analysis – Using FIPS 182 IDEF0 requirements modeling. Don’t start
with a design! Find the requirements, then design the system.
• Candidate scalable data transport middleware
– Medical Device Cooperation Framework (MDCF)
– The NIST Data Flow System V2
– OMG Data Distribution Services (DDS)
• 11073 Domain Information Model (DIM)
• NDFS mapping
ASTM F2761-09 CConOps 1
Patient Controlled Analgesia Fatality
•
•
•
Section B.2 Clinical Examples
B.2.1.1 Clinical scenario, safety Interlock
Current State: “A 49-year-old woman underwent an uneventful total abdominal
hysterectomy and bilateral salpingo-oophorectomy. Postoperatively, the patient
complained of severe pain and received intravenous morphine sulfate in small
increments. She began receiving a continuous infusion of morphine via a
patient-controlled analgesia (PCA) pump. A few hours after leaving the PACU
[post anesthesia care unit] and arriving on the floor, she was found pale with
shallow breathing, a faint pulse, and pinpoint pupils. The nursing staff called a
“code,” and the patient was resuscitated and transferred to the intensive care
unit on a respirator [ventilator]. Based on family wishes, life support was
withdrawn and the patient died. Review of the case by providers implicated a
PCA overdose.” [7] Delayed detection of respiratory compromise in patients
undergoing PCA therapy is not uncommon because monitoring of respiratory
status has been confounded by excessive nuisance alarms (poor alarm
specificity).”
Models of the ASTM 2761-09 Standard - Requirements Activity Diagrams
Pt. Record/
EHR Entries
Electronic
Medical Record
(m2)
Clinicians
ICE commands &
Pt. data/ICE Supervisor
GUI Display
Patient Notifications
and actuation control
(C1)
(C2)
Patient Status ,
Smart Alarms,
Device Status
Supervisor
Display Data
(O1)
Manage Patient via
Integrated Clinical Environment
(O2)
Forenesic Log Entries
A0
(M1)
Management/actuation cmds/
measurements,
Device Models
(M6)
(M4)
Global
Clock
(m6)
ICE Medical
Devices (m1)
(M7)
ICE
Supervisor
GUI State
(m7)
Certified Algorithms
(m4)
physiology/treatments
(M3)
(Smart Alarm,
Classification, Signal
Processing)
(M5)
Session Events/
Retrieved events
Forensic log
Database
(m5)
Certified Procedure
Suites, Devices(m3)
(Dev.- Characteristics, -Lists,
-Schedules, -Parameters, Safety
Interlocks, Device Exclusions,
Gui Setups,
Patient
Pt.Observations and treatments/
measurements
Patient Notifications
and actuation control
(Viewpoint Note: Nominal vs. Desired System Settings Negotiation of Clinician and Patient System Interaction)
Node:
Title:
A-0
Page:
Integrated Clinical Environment Context Model
1
• IDEF0 Activity Diagram: A hierarchy of diagrams
illuminating activities contextualized by inputs and
outputs
• Critical to get the highest levels right!
NIST
Pt. Record/
EHR Entries
Electronic
Medical Record
(m2)
System Data Flow Requirements
Model
Clinicians
ICE commands &
Pt. data/ICE Supervisor
GUI Display
Patient Notifications
and actuation control
(C1)
(C2)
Patient Status ,
Smart Alarms,
Device Status
Supervisor
Display Data
(O1)
Manage Patient via
Integrated Clinical Environment
(O2)
Forenesic Log Entries
A0
(M1)
Management/actuation cmds/
measurements,
Device Models
(M6)
(M4)
Global
Clock
(m6)
ICE Medical
Devices (m1)
(M7)
Certified Algorithms
(m4)
physiology/treatments
(M3)
ICE
Supervisor
GUI State
(m7)
(Smart Alarm,
Classification, Signal
Processing)
(M5)
Session Events/
Retrieved events
Forensic log
Database
(m5)
Certified Procedure
Suites, Devices(m3)
(Dev.- Characteristics, -Lists,
-Schedules, -Parameters, Safety
Interlocks, Device Exclusions,
Gui Setups,
ICE Clinicians
(C1)
Patient
Pt.Observations and treatments/
measurements
Patient Notifications
and actuation control
Patient
(C2)
(Viewpoint Note: Nominal vs. Desired System Settings Negotiation of Clinician and Patient System Interaction)
Node:
Title:
A-0
Information
request
Supervisor
Display /
Controls &
Patient Data
Page:
Integrated Clinical Environment Context Model
1
Device
actuations
Pt. device
actuations
Desired suite
configuration
(C1)
(C1)
Specify and
Manage ICE
Devices
(O1)
(I1)
(O2)
(I2)
(O3)
Desired activation
commands
(C2)
Acquire Pt.
Observations,
Actuate ICE Devices
A1
(O3)
Clock Validated Dev. Nominal
(m6) Activations/ Schedule
Measurements
(m3)
(m1)
Patient data &
single dev.
alarms
(C1)
Supervisor
Display Data
(O1)
(C2)
(I1)
(I3)
(I2)
Medical
Devices
(m1)
Patient data &
single dev.
alarms
(O2)
A2
Device Connects/
Actual device
model
Validation
override
(O1)
Validate
Actuations, Smart
Alarm, Monitor
Devices, Mitigate
(O1)
Validated
Smart Alarms
(O2)
Pt. Status
(O4)
Dev. Status
Fuse Data for
Supervisor
Display
A4
(O3)
(O5)
A3
Queries / Certified
medical procedure
suite (m3)
Associated
Suite
configuration
Validated
Activation
Commands &
Overrides
Device
Exclusion Rules,
Mitigation
Strategy
(m3)
Supervisor
GUI
(m7)
Log
Data
Medical Smart Alarm-,
Devices ClassificationAlgorithms
(m1)
Library (m4)
Generate or
Replay
Forensic
Log Entries
A5
Forensic
Data
Log (O2)
Data for
Forensic Log
Log System (m5)
Node:
NIST
Title:
A0
Clock (m6)
Page:
Manage Patient via Integrated Clinical Environment
nominal
Display
Setup
(m3)
2
ICE Clinicians
(C1)
System Data Flow Requirements
Model
Patient
(C2)
Information
request
Supervisor
Display /
Controls &
Patient Data
Device
actuations
Pt. device
actuations
Desired suite
configuration
(C1)
(C1)
Specify and
Manage ICE
Devices
(O1)
(I1)
(O2)
(I2)
(O3)
Desired activation
commands
(C2)
(O2)
(O3)
A2
Clock Validated Dev. Nominal
(m6) Activations/ Schedule
Measurements
(m3)
(m1)
Patient data &
single dev.
alarms
(C1)
Supervisor
Display Data
(O1)
(C2)
(I1)
(I3)
(I2)
Medical
Devices
(m1)
Patient data &
single dev.
alarms
(O1)
Acquire Pt.
Observations,
Actuate ICE Devices
A1
Device Connects/
Actual device
model
Validation
override
Validate
Actuations, Smart
Alarm, Monitor
Devices, Mitigate
(O1)
Validated
Smart Alarms
(O2)
Pt. Status
(O4)
Dev. Status
Fuse Data for
Supervisor
Display
A4
(O3)
(O5)
A3
Queries / Certified
medical procedure
suite (m3)
Associated
Suite
configuration
Validated
Activation
Commands &
Overrides
Device
Exclusion Rules,
Mitigation
Strategy
(m3)
Supervisor
GUI
(m7)
Log
Data
Medical Smart Alarm-,
Devices ClassificationAlgorithms
(m1)
Library (m4)
Generate or
Replay
Forensic
Log Entries
A5
nominal
Display
Setup
(m3)
ICE
Session
Log
(O3)
Forensic
Data
Log (O2)
Clinician (C1)
Data for
Forensic Log
Log System (m5)
Node:
Title:
A0
Clock (m6)
Page:
Manage Patient via Integrated Clinical Environment
2
Clinician
Selections
Nominal
Device
parameters
Pt. specific
Parameters
(override)
Desired
Procedure
Construct
Device
Parameters
Device
additions and deletions
(override nominal)
Nominal
Device Suite
Desired
Suite
A13
Desired
Device
Parameters
Desired DeviceList,
Characteristics
Desired
Device Suite
Configuration
(List +
Characteristics
only)
(O1)
Modify Nominal
Device List &
Characteristic
A12
Select Devices and/or
Procedure
Based Suite
A11
Queries/Certified
Procedure
Device Suite
Associated Suite
parameters
and
Device Models
Desired
Suite
parameters
Physical
Suite
Nominal
Device-List,
-Characteristics
List of desired
Device
Characteristics
Discover and
Connect Devices
A15
Device
Models
Queries / Certified medical procedure suite,
(Device-list,-characteristic)
(m3)
Medical
Devices
(m1)
MdPnP
Human
Node:
NIST
Title:
A1
Associate Desired
with Physical
Devices A14
Associated
Device Suite
(O2)
Page:
Specify and Manage ICE Devices
3