Focus on Interoperability
The roles that Device-to-EMR & Device-to-Device
Interoperability Will Have in Meeting This Century
’s
Healthcare Quality and Finance Challenges
Elliot B. Sloane, PhD, CCE, FHIMSS
Founder, Center for Healthcare Information Research and Policy
Co-Chair, IHE International Board of Directors, IHE-USA
Board of Directors, Delaware Valley HIMSS
Board of Directors, ANSI Healthcare Technology Standards Panel Sponsor, IEEE 11073 Medical Informatics Standards
Some of the current FAQs – Dual Career in Clinical Engineering and Health IT:
Elliot B. Sloane, PhD, CCE, FHIMSS
Founder, Center for Healthcare Information Research and Policy
HIMSS roles:
Board of Directors, Delaware Valley HIMSS
HIMSS Annual Conference Education Committee HIMSS Professional Careers Committee
Past Chair, HIMSS Security and Privacy Steering Committee
IHE roles:
Co-Chair, IHE International Board of Directors
Board of Directors, IHE-USA
Other professional roles:
NSF Co-PI – Certification Specialist in Health Information and Management Systems (CSHIMS) project, Bellevue College, WA
Sponsor, IEEE 11073 Medical Informatics Standards
Past President, American College of Clinical Engineering
Presentation Overview
•
Overview of medical device
interoperability, ecosystems, and
standards
• Where medical and personal health
devices fit into the new healthcare
financing models
– Example: Accountable Care Organizations
(ACOs)
Types of interoperability
•
Device-to-system
(often homogeneous)
– e.g., central station monitoring or a centralized “smart
pump” system, where each device is an
extension/component of the whole system
•
Device-to-device
(often heterogeneous)
– Where devices can send/receive data to each other,
possibly control other devices or share alarm/alerts
•
Device to EMR
(usually heterogeneous)
– Where devices can either send/log data into the
patient EMR and/or receive data or control
Interoperability Ecosystem Terms
There can be overlap and combinations
• Fully autonomous
– Each device or subsystem may be whole and independent from the others (e.g., most legacy devices, some middleware vendors whose products are also registered as medical devices, ASTM/ICE?)
• Shared autonomy
– Devices may interact with other devices or the EMR, e.g., sharing settings, alarms or drug/dose-error alerts, but control remains at the device-patient or device-clinician point (typical of IHE Patient Care Devices)
• Integrated communication
– Devices send data to central aggregation device that stores and
forwards to authorized clinical provider (typical of IHE PCD, Continua, and ASTM/ICE)
• Integrated control
– Devices are controlled by a central smart system controller (ASTM/ICE)
• Plug and Play (or PnP)
– Device can identify itself and it’s capabilities to the other components in the system, allowing automatic integration and operation
Vast majority of interoperability to
date?
• Probably legacy devices in hospitals
– Brand-specific electrical and data encoding
– 3,500 hospitals x 4,000 devices/hospital =
14 million devices (plus another 3 million or
so in rental, home and long term care?)
– “Long tail” that will take a decade or more to
replace/adapt
– The turf of “middleware” products from
Two growing clusters of
interoperable medical device choices
• Continua Health Alliance
(
www.ContinuaAlliance.org
)
– Both consumer and FDA-regulated devices
– Integrated communication
• IHE Patient Care Device Domain (IHE-PCD, at
www.IHE.net/PCD
)
– Primarily FDA-regulated devices
Available Continua Products
• Looks like
about 50 or
so at the
main
Continua
Alliance
web site
(note many
major
consumer
brands.)
http://www.continuaalliance.org/products/productshowcase.htmlAvailable IHE-PCD Products
The IHE-PCD, Continua-WAN, and IHE EMR
interfaces were shown in 2010 HIMSS
Additional emerging device
interoperability options
• Sourced from the ASTM F2761 and MD
PnP projects, in collaboration with Mass
General, CIMIT, TATRC, and others
–
www.MDPnP.org
is a good launch point
–
ICE
= Integrated Control Environment
– I believe that Dr. Goldman mentioned
commercial products are expected in a couple of
years at a Spring ’11 ONC hearing, and that
EMR communication is also planned (for details,
you may review the 4/15/2011 transcript from the
3/28 meeting at healthit.hhs.gov)
Another rapidly growing
interoperability ecosystem?
• Apps on a wide variety of Apple, Droid,
and other platforms.
• Some such products are passing FDA
regulatory muster
• FDA has asked for public comment on
apps, because the rate of development
seems to be quite high
MANY choices!
Hundreds of products can communicate with PCs and PHRs,
Presentation Overview
• Overview of medical device interoperability,
ecosystems, and standards
•
Where medical and personal health devices
fit into the new healthcare financing models
–
Accountable Care Organizations (ACO)
–
Patient-Centered Medical Home (PCMH)
–
CMS Innovation Center’s “Independent
Living at Home”
Presentation Overview
• Overview of medical device
interoperability, ecosystems, and
standards
•
Where medical and personal health
devices fit into the new healthcare
financing models
–
Example: Accountable Care
Organizations (ACOs)
ACOs – Putting the PROVIDERS
in charge; spurring innovation
• Basic equation:
–
Process Innovation + Satisfied Customers
MUST EQUAL net savings for healthcare
–
Process Innovation
intends to reward
risk-taking and investment
•
Risk taking
– groups of providers make the
investments
•
Rewards
– CMS and Providers will share savings
–
Satisfied Customers
Federal Register, May 20, 2011
• “Payment arrangements that place a
group of
providers at joint risk
for quality performance
and financial performance for the majority of
their patients and revenues (including
non-Medicare patients and revenues).
Such
payment arrangements will require
participants to transition from
fee-for-service to population-based payment by
What is the ACO target?
• Federal Register:
– “In an effort to provide focus to ACO quality improvement activity, we have identified 5 key domains within the
dimensions of improved care and improved health that we
propose will serve as the basis for assessing, benchmarking,
rewarding, and improving ACO quality performance.”
These 5 domains are as follows:
Better Care for Individuals:
1. Patient/Caregiver Experience 2. Care Coordination
3. Patient Safety
CMS’s proposed ACO Scorecard?
31 of 65 measures were “At Risk Populations”
CMS’s proposed ACO Scorecard?
“At Risk Populations” continued, Page 2…
CMS’s ACO proposed Scorecard?
“At Risk Populations” continued, Page 3…
5 Domains reduced to 4, 65 measures reduced to 33
• Care Coordination/Patient Safety (6 measures)
< merged
• Preventive Health (8 measures)
• At-Risk Populations (12 measures)
• Patient/Caregiver Experience (7 measures).
and
ACOs may now share in 100% of the care cost
savings, and may not have ANY risk if there
are no savings!
CMS’s ACO final Scorecard?
Expected Federal savings AND
ACO Bonus Payments
CMS’s ACO accounting focus?
•
Manage and reduce clinical costs of:
– Diabetes
– Coronary Artery Disease (CAD) – Congestive Heart Failure (CHF)
– Chronic Obstructive Pulmonary Disease (COPD) – Falls (often hypotension, hypoxia, or meds)
•
The “metric?”
– National Quality Forum (NQF), reflecting best practices,
AS REFLECTED IN REDUCED ADMISSIONS TO
HOSPITALS!
Virtually of ALL of CMS’s ACO
metrics (and rewards) focus on
long-term chronic diseases/risks
Almost all of these diseases & risks are
“slow moving,” and can be managed in
the home with readily available
low-cost medical and patient care devices!
Devices and the ACO Value Proposition
Innovative collaboration between providers, CMS, and EMR
and device manufacturers can put this country’s money into
Finally, realize that ACO’s are only
the tip of the Policy iceberg!
• The Federal Government MUST reduce
Medicare and Medicaid expenditures, because
of the underlying finances
– Most of HITECH ’09 and virtually ALL of PPACA ’10
state again and again that fee-for-service
reimbursement models will be replaced with fixed
per-patient fees based on quality per-patient care
–
Just as “never happen” fees are being eaten by
hospitals, readmission fees will also be either
withheld directly, or “incented” via ACOs and
other means, indirectly!
Presentation Overview
• Overview of medical device
interoperability, ecosystems, and
standards
• Where medical and personal health
devices fit into the new healthcare
financing models
– Example: Accountable Care Organizations
(ACOs)
The punchline?
• By every means available, financial incentives
are lining up to restrict hospital and physician
compensation SOLELY to “optimal” lean care
paradigms
– Nurses and physicians will not be paid to enter clinical
data into EMRs, only to care for patients
– Clinical providers must be freed up to become
USERS of the EMR, not clerks
– And, as I’ve said before, we need to start acting like
the EMR is becoming a medical device, even if it is
not actively regulated as such
Interoperable Medical Devices, and assuring
automatic, reliable and efficient data is
transferred to Electronic Medical Record
systems, has to be our shared passion!
–
Thanks to ONC’s support from 2005-2009,
the
HITSP/IS77 Remote Monitoring
and
HITSP/TN905 Common Medical Device
Communications
documentation were
created
•
Both excellent documents are free, and can be
Procurement and Implementation
Handbooks
(Free, too!)
• User Handbooks (http://www.ihe.net/Resources/handbook.cfm) The handbooks linked below describe how implementers can use IHE to select, specify, purchase and deploy healthcare IT systems with advanced integration capabilities. The initial documents
address the domains of radiology and mammography. Future editions will address other IHE domains.
– Patient Care Devices published for public comment January 2010
• Submit comments on this document to the IHE Forums
– Radiology
– Mammography
• MD PnP Free Interoperability Requirements for the Enterprise (FIRE) materials are available at http://mdpnp.org/MD_FIRE.php
Regardless of your interoperability strategy,
these documents can help you
understand, plan, and communicate about
medical device interoperability issues
Take Aways?
• Think of devices and EMRs as parts of a
complex system of systems for healthcare
delivery, quality, and efficiency
– Whether coming from the clinical technology or IS
perspective, there is no beginning or end, and the
components are truly becoming interdependent.
• Think through “continuum of care”
strategies
• You WILL need to support home care devices,
personal health records, and other solutions if
they directly affect hospital revenue and
Thanks for your
passion, and for all YOU
do!
Comments and questions are
welcome at the end of the
presentations!
Elliot B. Sloane, PhD, CCE, FHIMSSebsloane@@gmail.com, @ieee.org, @aol.com, @yahoo.com, @hotmail.com, etc..
www.ebsloane.org
11/1/2011
Integrating Medical Devices and Clinical Systems -Update from the Trenches
from the Trenches
CE-IT Community Town Hall Meeting
11 - 1 -11
Paul Maurer, CPHIMS – Director Applications Main Line Health System
Conflict of Interest Disclosure
Paul Maurer Has no real or apparent conflicts of interest to report.
11/1/2011
Main Line Health
Main Line Health System • Four Acute Care Facilities • Standalone Rehab HospitalStandalone Rehab Hospital • Drug and Alcohol Treatment Center • Five Free Standing Outpatient Facilities Department Structure
•Centralized Information Services Department serving all Facilities reporting to CIO
•Centralized Biomedical Engineering Department reporting to Materials Management
Key Statistics
10,280 Employees 1,933 Medical Staff Members
1,168 Licensed Beds 12,536 Cardiovascular Discharges
65,824 Admissions 803,459 Outpatient Visits
7,456 Births 148,188 Emergency Visits
15,510 Inpatient Surgeries 19,339 Outpatient Surgeries
11/1/2011
Applications Environment
•Primary Vendors:
•Siemens - HIS, Radiology, Pharmacy, MAK, Patient Accounting, OPENLink Interface Engine. Soarian for Results, Clinical
Documentation, Workflow, Order Entry and CPOE, EHR, Critical Care C O f ilit f ll C li i l it f CPOE
•Cerner – One facility uses full Cerner clinical suite for CPOE, documentation, and ancillary systems
•NextGen – Practice Management and EHR
•McKesson - Enterprise Radiology & Cardiology PACS, Medication dispensing (robot-rx),Cardiology Information System (CIS)
•PeopleSoft HR, GL, Materials and AP
•HIE - MobileMD
•Variety of other vendors for departmental and specialized functions. y p p Over 130 applications in inventory
Primary Vendors:
GE – Patient Monitors, Telemetry - Integrated with critical care hospital information system.
CareFusion (aka Alaris/Cardinal) Smart IV Pumps, Medication Cabinets
Integrated Medical Devices
CareFusion (aka Alaris/Cardinal) Smart IV Pumps, Medication Cabinets
Integrated with hospital pharmacy system
GE/ Siemens/ Other - Imaging Modalities (CT, US, MRI, DR,…).
Integrated with Enterprise Imaging (PACS) for Cardiology and Radiology
Accudose – POC Testing Glucometers/ Blood Gas. Integrated with Laboratory Information System
Philips/Witt Cath Labs and various Echo. Integrated with Cardiology Information System (CIS)
11/1/2011
Goal for the next 15 minutes!
7
•Evolution of Medical Device Integration at Main Line Health
•Case Study on CE/IT roles
•Update from front lines (two active CE/IT projects)
•Meaningful Use Impacts
•Done !Done !
Evolution of IT and Medical Device Integration at Main Line Health
8
11/1/2011
Evolution of Device and IT Integration
9
Beginning Phase I ..Application Software
embedded in Medical Device
Medical Devices Medical Devices IS IS Hospital Information System Hospital Information System Medical Devices Medical Devices •Separate systems •Standalone Devices •No integration..(sneaker net data transfers)
•Little to no CE/IT communication
•Embedded application and computer systems within Medical Device
•Medical devices on separate networks
•No data sharing
•Beginning of CE/IT communication
10
Phase III ..More complex
integration.
Phase II ..Simple Integration
Evolution of Device and IT Integration
Hospital Information System Medical Devices Medical Devices IS IS Hospital Information System Medical Devices Medical Devices IS IS
First level of integration Outbound • More standards for data exchange Output of
•First level of integration - Outbound
– Patient identifiers and/or location information via HL7 ADT or Custom point to point interfaces
•Growing complexity of IS
component of Medical Device, mini applications evolving into robust applications.
• More standards for data exchange, Output of information BACK to “HIS” (two way integration)
• Beginning of network sharing
• Complexity and feature/function of Hospital and Medical Device application continue to grow.
• Battle for ‘foreground’. i.e. Where will the clinician live? the Hospital Information System (“HIS”) or within Medical device application
11/1/2011
11
Our Current State… Physician
Practice “EHR” HIE
Devices
Evolution of Device and IT Integration
• Continued growth in – number of devices
– complexity of data set exchange
– interoperability complexity.
• Consolidation of data into electronic health record in the HIS.
• Addition of CPOE and Clinical documentation
Hospital Information System Medical Devices Medical Devices IS IS
have made HIS the core ‘foreground’ system. • Greater interoperability blurs line from where HIS
ends and Device begins
• Clinical Data exchange outside of health system. • External pressure for incorporation of additional
standards (e.g. LOINC codes for lab tests, drug allergy standardization, CCD) are changing landscape of integration.
Medical Devices
IS
Clinical Engineering
•Strong Relationship with
Information Systems
•Project Management and Traditional Roles (in our environment)
•Strong Relationship with Clinicians
•Culture of Immediacy –Faster Response and Service Levels
•Embedded with Clinical Processes
•Knowledge of Medical Devices
•Project Management and Structured approach to implementation and testing
•Culture of Process and Structure
•Specialists for Hardware, Networking, Applications and Integration
Knowledge of Medical Devices
•Relationship with Device Vendors
•Relationship with Information System Vendors
11/1/2011
Support Process
Case Study - PACS Our First Large scale CE/IT Initiative Our Support Story
pp
–Radiologists called vendors directly without CE/IT knowledge
–CE/IT changed device settings independently
–Needed vendor escalationNeeded vendor escalation without knowing who to contact
–Each group assumed other groups taking care of problems…
–Very unhappy Radiologists
The Outcome…
Very unhappy Radiologists
–Extended/unnecessary downtimes
–Wasted time/resources
–Diminished care
–Frustrated technical teams
11/1/2011
•Agreed that CE, IT and the department must provide support as a team
What we Did…
•Given increasingly overlapping areas of support, it was essential to define roles
•What will Clinical Engineering do?
•What will IT do?
•What will IT do?
•What will Clinical Departments do?
•Establish clear escalation process
•Have clear communication
D e ff i n e d R o l e s TIPS
11/1/2011
“All issues must be owned by either
Roles Excerpt…
All issues must be owned by either Biomed, IS or Radiology. When ownership needs to be transferred to another group, this should be done via verbal or e-mail communication with the new owner accepting responsibility.”
TIPS
Utilize a standard form to document roles and
How and Where to Document Roles? Utilize a standard form to document roles and
review with all parties. A Service Level Objective Document (SLO) is one way to do this
Who will support the software, integration, and
provide education? Establish communication TIPS
p
11/1/2011
•Service Levels need to be higher for medical d i i t ti
What we learned…
device integration
•Clinicians now rely on ability to view data real-time in core systems.
•Impacts to the sytem…Impact clinician workflow and the patient care process! workflow and the patient care process!
•Results and data collected by Medical Devices
need to be available. Ingredients: - Medical Device - Information System - Network 20
In Summary… The Recipe for Application and Medical Device Integration
Network
- CE, IT, Clinical Team Directions:
•Combine medical device, network and information system. Note- may be necessary to beat thoroughly to get everything to blend.
•In separate bowl, add CE, IT and other personnel. Define roles, until there is consistency of “TEAM”
•Carefully bake, try to avoid being burned
11/1/2011
Critical Care System - Integrated Clinical documentation and critical care monitoring system.
Environment - Bedside monitors, vents, CE , IT, Vendors,
Update from Front Lines..Two IT/CE initiatives in progress! This stuff isn’t easy!
Environment Bedside monitors, vents, CE , IT, Vendors, Clinical staff that ‘loved’ their multi-part tri-fold form.
IT/CE implications. High availability requirement, complexity of data types, coordination between multiple vendors.
Progress to date – Clinicians love the electronic flow sheets! Application is well received.☺
Unexpected challenges – simulators not matching production feeds?
Critical Care System - Integrated Clinical documentation and critical care monitoring system.
Environment - Bedside monitors, vents, CE , IT, Vendors,
Update from Front Lines..Two IT/CE initiatives in progress! This stuff isn’t easy!
Environment Bedside monitors, vents, CE , IT, Vendors, Clinical staff that ‘loved’ their multi-part tri-fold form.
IT/CE implications. High availability requirement, complexity of data types, coordination between multiple vendors.
Progress to date – Clinicians love the electronic flow sheets! Application is well received.☺
---From:xxxxxxxxxxx
Sent:Monday, October 24, 2011 10:28 AM
To:xxxxxxxxxxxx
Cc:xxxxxxxxxxxxxxxx
Subject:ART Line Status Update
Importance:High
Status Update from last week’s work:
Originally identified multiple Arterial Line (ART) issue has been confirmed fixed through our testing. We no longer see the “averaging” issue when a patient has multiple ART li
Unexpected challenges – simulators not matching production feeds?
lines.
New issue identified that Mean ABP for 2ndand 3rdlines is not coming over (1stline Mean ABP does come over though). XXXX came on site last week to test and we are not seeing this issue when testing via the BioMed Simulators with test patient data.
Next Steps – We need a multiple ART line patient from PROD that we can use to feed data into test again. This is how this new issue was originally identified so we want to make sure we test with a real patient again.
11/1/2011
Cardiology Information System
Environment – Echo Carts, Cath Lab system, Imaging, Documentation, multiple vendors, biomed, IT, very busy independent cardiologists with minimal time between cases
Update from Front Lines..Two IT/CE initiatives in progress! This stuff isn’t easy!
independent cardiologists with minimal time between cases.
IT/CE implications. Imaging integration, large clinical data sets from cath lab. Lack of standards and discrete data.
Progress to date – Echo reporting going well, beautiful report, faster turnaround time. ☺
Ch ll C th D t t h t t fi ld t Challenges – Cath Datasets are huge, text fields are not discrete. Reporting is slowing down the physicians
Winds of Change…….
Impact of ARRA and Health Care Reform on Medical Device Integration
11/1/2011
•Pushing adoption of advanced clinical data
ARRA Hi-tech Act
applications like CPOE, Quality Measure reporting and much more!
•Promotes integration of clinical results and portability
and exchange of datasets.
•Encourages collection of more clinical data for use
•Encourages collection of more clinical data for use
with real-time rules/alerts as well as advanced clinical decision support workflows
•All on a Certified Platform.
Accountable Care Organizations Change in locations of care Healthcare Reform g Could…
•Require more data aggregation between physician and hospital based systems…including any medical device data
Could…
•Require more POC medical device integration from remote
locations..glucometers, blood pressure monitors used in either environment
11/1/2011
Implications for Device Integration Looking Ahead
•Complexity of required clinical functions and certification will force organizations to look at the
‘information system’ portions of complex medical device applications (e.g. cath lab systems, fetal monitoring) much more closely
•Will organizations want to support advanced clinical functions on multiple platforms? Or will they move functions on multiple platforms? Or will they move to a core Certified system strategy ?
Implications for Device Integration Looking Ahead
•Greater need to integrate any clinical data acquired by the device to the HIS as discrete data.
• Summary blocks of text will not meet the needs of a complex clinical system that will require discrete data for use with rules, workflows, quality measures etc.
•Need for Standardization of interfaces and integration protocols will be increased…
11/1/2011
Implications for Device Integration Looking Ahead
•Need for integration hubs specific to medical devices will increase.
•As a result of the Certified System requirement…
– Niche Information Systems associated with medical device systems will face greater scrutiny and or need to meet ‘certification’ criteria
– Focus will be on integrating data into the certified system to meet measures, reporting requirements and facilitate exchange of data
Whether you are
In Closing.
Whether you are working with IT, CE, your Vendor, your Customer, Clinicians etc. Remember…
Work Together, Define Your Roles and
Communicate,
Communicate… and prepare for more changes to come!
11/1/2011
Thank You !
Enjoy these times of change, and remember Change brings Opportunity!
The Time for Interoperability is
NOW!
An update from the field
The Time for Interoperability is
NOW!
An update from the field
Steve Merritt
Infrastructure Engineer
MS Biomedical Engineering
Co-chair IHE Patient Care Devices Planning Committee
Baystate Health Baystate Medical Center Baystate Franklin Medical Center Baystate Mary Lane Hospital D’Amour Center for Cancer Care Baystate Medical Practices Baystate
VNA & Hospice At a Glance
Type of Organization: IDN/ teaching hospital FTE’s: 10,000
Physicians: 1,663 (492 employed)
Residents: 311 residents, 250 medical students
Inpatient Statistics Inpatient Facilities: 3 Beds: 774
Admissions: 44,000 Patient Days: 210,000
Average Length of Stay: 4.7
Why Are We Here?
Why Are We Here?
Barriers to adoption
Momentum moving us forward
How IHE is breaking down these barriers
Planning for Interoperability NOW
Barriers: Market Forces
Barriers: Market Forces
Healthcare organization
financial
priorities
• Where is the ROI for medical device interoperability?
• Each solution must be justified financially
• Reimbursement drivers
• Are you willing to pay more for standards?
Would anyone buy an ultrasound without “DICOM”
Vendors marketing
one-size-fits-all
• Do they really make financial sense?
• Don’t listen to these marketing or sales guys
Talk to people who have actually implemented
Safely, Effectively
Safely, Effectively
Rigorous
validation, verification, and testing
of medical devices is required
This
slows development
to market timelines
We’re creating complex
systems of systems
requiring intricate analysis
Complex Problems
Complex Problems
Most healthcare organizations do not have the staff
to
understand requirements
of medical device
interoperability
• Sure it “interfaces” to your EMR but what does that mean?
We need to
simplify
the integration requirements
• Vendor salespeople wouldn’t be able to blow as much smoke
Imaging devices as an example
Key Benefits of Point of Care Medical
Device Interoperability
Key Benefits of Point of Care Medical
Device Interoperability
More accurate data
(10 to 20% errors introduced with data transcription)
• Improved patient safety and care outcomes • Improved discharge decisions
• Improved Case Management, Infection Prevention and QA
More “real time” data available to MD, clinicians and care
managers
• More clinically sound diagnosis and orders
• Earlier initiative of appropriate interventions and therapies
• Prevention of undetected patient deterioration (“failure to rescue”) • More “proactive” patient management (↓LOS, ↑ reimbursement)
• Better outcomes
Increased MD productivity and satisfaction
Increased Nursing productivity and satisfaction
• 1 to 1.5 hrs day savings per RN or PCT
FY12 FY13 FY14 FY15 FY16
Patient Monitoring
BMC NICU monitors to CIS HOF Telemetry
HOF Telemetry to Alarm Mgmt All BMC Monitors to Alarm Mgmt All BHS Monitors to Alarm Mgmt
•Improve Patient Safety
•Provide the right information to the right person at the right time
•Reduce documentation errors •Interoperability with EMR
•Continuous documentation of cardiac rhythms into the EMR
BMC PICU monitors to CIS
BMC CCN monitors to CIS PACU monitors to CIS
PediPACU monitors to CIS New ED monitors to CIS
HOF Care Rooms BMC Backfill Rooms HOF Critical Care Rooms
BOSC
HOF Critical Care Rms INET BMC Backfill Rooms INET
HOF Care Rooms INET
Clinical Technology
System Integration
Clinical System
Anesthesia
Ventilators
Analog Vent Alarms to Nurse Call •Reduce documentation errors
HOF Procedure Rooms
CVIS Interoperability ORIS Interoperability BFMC FetalLink FY12 Request Already Fully Funded (FY11 or HOF) FY12 Request (moved out to FY13) Replace CCN monitors Replace NICU monitors Replace PICU monitors
Not funded
New ED Monitors
Alarm Management Example
Alarm Management Example
Multi-input <-> multi-output
Combination of traditional
biomedical systems and IT
networks, databases, servers,
communication devices and
systems
Collaboration between CE and
IT
required
• Effective communication of
requirements
• Deep understanding of criticality
Must
work together
from
inception through technology
assessment to implementation
and support
IHE PCD: Simplify Specs!
IHE PCD: Simplify Specs!
IHE
IHE
International organization of manufacturers, standards organizations,
and users
• IHE is not a standard, IHE is a user of standards
Identify and constrain standards to make them more user friendly and
truly interoperable
• Saying it’s a compliant IHE Image Acquisition Actor means a lot more than
saying its “DICOM”
• Claiming a Central Station is a Device Observation Reporter (DOR) means
more than saying its HL7
Standards are broadly based while IHE drills down to specify the parts
of standards that are normally ambiguous
• Example: A medical device claiming to be a DOR must use HL7 v2.6 and
must structure their HL7 messages in a way clearly defined by IHE, using message contents and semantics that is also clearly defined by the IHE PCD Rossetta Terminology tables
IHE Technical Frameworks
IHE Technical Frameworks
Profiles
• Describe clinical information management use cases and
specify how to use existing standards (HL7, DICOM, IEEE 11073, etc,...) to address them.
Actors
• A system or application responsible for certain information or
tasks. Each Actor supports a specific set of IHE transactions to communicate with other Actors.
Transactions
• An exchange of information between Actors. For each
transaction a Technical Framework describes how to use an established standard (such as HL7, DICOM or W3C) to
Alarm Source
Alarm Aggregator
Alarm
Receiver CoordinatorAlarm
Alarm Disseminator Alarm Communication Alarm Endpoint Alarm Communicator (AC) Alarm Manager (AM) Alarm Reporter (AR) Alarm Reporter Alarm Cache Alarm Archiver (AA)
Communication detailed in this profile Communication not detailed in this profile
. . . . . .
Communication of alarm information from patient care devices to an alarm manager system communicating with secondary means of notification to caregivers.
Typical secondary notification means would be annunciators, pagers, and smart phones.
Case A1: Location Sourced
Case A1: Location Sourced
Patient wants a pillow Patient pulls nurse call
Nurse call system lights the room’s dome light and light at central station.
Nurse call system, operating as an Alarm Reporter (AR) actor sends Report Alarm [PCD-04] to Alarm Manager (AM) indicating nurse call alarm.
The Alarm Manager (AM) logs receipt of the alarm. The Alarm Manager (AM) identifies the appropriate nurse based upon configured nurse to patient assignments, identifies the appropriate Alarm Communicator (AC) actor and destination communication device based upon nurse to device configuration in Alarm Manager (AM), sends Disseminate Alarm [PCD-06] to nurse’s
communication device. The Alarm Manager (AM) logs the dissemination to the Alarm Communicator (AC).
The nurse receives the alarm on their assigned device. The information minimally includes the patient location (room number). The nurse goes to the room,
determines the needs of the patient, and provides the patient with a pillow. The nurse then resets the nurse call pull. The nurse call system turns off the room’s dome light and the light at the central station.
The nurse call system, operating as an Alarm Reporter (AR) actor sends Report Alarm [PCD-04] to Alarm Manager (AM) indicating reset of the nurse call alarm. The Alarm Manager (AM) receives the alarm turns off any configured alarm escalation AR -> AM
AM -> AC
AC -> Nurse
AR PCD-04 Report Alarm AM PCD-06Disseminate Alarm AC PCD-05 Report Alarm Status PCD-07 Report
Dissemination Alarm Status Opt Opt Alarm Reporter -Nurse Call -Medical Devices -Physio Monitors -Pumps -Apnea -Bedboard System Alarm Manager
-”Smart” alarm systems -Alarm aggregators
Alarm Communicator
-Vocera
-Cisco Wireless IP Phone -Cell Phone
Leveraging
IHE for purchasing
Leveraging
IHE for purchasing
How do you get IHE Integration Profiles?
• Specify IHE capabilities as requirements
• State in the RFP which IHE Actors and Integration Profiles
you want.
What do IHE Integration Profiles cost?
• Nothing in most cases
• Any cost should be a fraction of the overall
When do I specify integration requirements?
• Ask during the technology assessment phase
Device Lifecycle
Device Lifecycle
Diminishing but still 5 to 7 years
Are you ready to interface your 5 year old
patient monitors or ventilators?
Two-fold problem
•
Life-cycle impedance matching
Not likely that EMR will be replaced at the same time
your medical devices are
Need for open-standards based interoperability
•
Even if you’re not looking to interface your device
at implementation, you need to understand its
interoperability capabilities at the time of
purchase
Why
Specify IHE
Why
Specify IHE
Specifying integration requirements for the system you are
purchasing is a simple matter of selecting which IHE Integration Profiles and which IHE Actors you want supported
When you tell a vendor you want a certain IHE actor they
immediately know your interface specifications instead of requiring an extensive interface technical assessment
Users can concentrate on the clinical requirements of their
equipment – not how it is going to interface to other systems
Removes custom interfaces as obstacles for future upgrades
The
Business Case
for
Implementing IHE Profiles
The
Business Case
for
Implementing IHE Profiles
Enables you to efficiently manage the array of integrated
information systems necessary to support effective healthcare
The alternative
• Building site-specific interfaces
More expensive
Requires maintaining these custom interfaces for the life of the system involved.
Integration via IHE is less costly at the start and makes future
acquisitions easier to plan and execute
IHE Profiles give clear definitions of how the pieces fit together
What Can You
Do
?
What Can You
Do
?
Plan, Evaluate, Purchase IHE Conforming Devices
In continuing discussions with vendors – at all levels
• Push IHE Interoperability
Refer to lower deployment, maintenance costs
• Encourage vendors’ active IHE participation
Lower development, installation, support costs
• Refer to profiles
Leverage public and objective commitments
In RFPs
• Refer to profiles, Conformance Statements
• Use Conformance Statements to “nail down” vendor’s
representations
PCD User Handbook 2011 Edition
PCD User Handbook 2011 Edition
Overview of IHE-PCD
Value Propositions for medical device interoperability Advice on how to specify IHE in technology assessment Tools to find IHE-PCD compliant products
Guidance on installation testing to confirm that IHE capabilities are
functioning properly
Issues to consider when installing and configuring IHE-compliant
system
Identifying and addressing potential problems in order to maximize
your benefit despite existing “legacy” systems
http://www.ihe.net/Resources/handbook.cfm
2011 Changes include
• Appendix H Mapping Clinical Requirements to Purchasing Requirements • Consolidation of the 2 major sections into 1 section
Sample RFP language
Sample RFP language
“The device shall support the IHE Device Enterprise
Communication (DEC) Integration Profile as the Device Observation Reporter (DOR) Actor.”
“The pump shall support the IHE Point-of-Care Infusion
Verification (PIV) Integration Profile as the Infusion Order Consumer (IOC) Actor.”
“The device shall support the IHE Alarm Communication
Management (ACM) Integration Profile as the Alarm Reporter (AR) Actor.”
The alarm aggregator shall support the IHE Alarm
Communication Management (ACM) Integration Profile as
Pharmacy Pump Server HIS Pa ti en t Id DOR eMAR DOC Point‐of‐care Medication Or der IOC IOP IOP PDS PCD ‐ 03 PCD ‐ 03 ITI ‐ 030 PCD ‐ 01 In fusion Documen ta tion AR Report Alarm PCD‐04 Or der Order PCD‐03 PDC Secondary Alarm Manager AC Dissemina te Alarm PCD ‐ 06 Alarm St at us PCD ‐ 07 AM Pager Smartphone Annunciator Communication Device
Vital Signs Monitor (VSM) VSM Server HIS Pa ti en t Id DOR EHR DOC PDS ITI ‐ 030 PCD ‐ 01 Vit al Signs Measur emen ts AR Secondary Alarm Manager AC Report Alarm PCD‐04 Alarm Status PCD‐05 Dissemina te Alarm PCD ‐ 06 Alarm St at us PCD ‐ 07 AM Pager Smartphone Annunciator PDC Communication Device Note: These interfaces could be built directly into the device
Example contract clause
Example contract clause
[Vendor] shall ensure that the Hardware and Software provided by
[Vendor] is capable of serving as the Device Observation Reporter (DOR) Actor to send data from the applicable patient care devices (PCD) listed in Exhibit F attached hereto to which such Hardware is
connected in which the Software is installed as described in the current IHE Device Enterprise Communication (DEC) Integration Profile,
provided that the applicable PCD and the applicable Device
Observation Consumer (DOC), Device Observation Filter (DOF) and
other Customer system components being utilized themselves conform to the IHE Device Enterprise Communication (DEC) Integration Profile. If this functionality is not available as of the Effective Date, [Vendor] shall provide it to Customer in an Update, as that term is defined in Schedule A hereto, at no cost to Customer as soon as is practicable thereafter. In the event of changes to such IHE DEC Integration
Profile terms are made after the Effective Date and additional products or services are necessary to comply with the changes, provision of
such additional products or services shall be subject to mutual agreement of the parties as to pricing and other terms.
Are These Devices
Really
Available?
Are These Devices
Really
Available?
19 products from 15 vendors are available for
you to purchase today
Device Enterprise Communication (DEC)
Point of Care Infusion Verification (PIV)
Alarm Communication Management (ACM)
Implantable Devices Cardiac Observation (IDCO)
Search for IHE-PCD Compliant Devices and Systems
2011 Significant Profiles
2011 Significant Profiles
[DEC] Device Enterprise Communication – supports communication
of information acquired from point-of-care medical devices to applications such as clinical information systems and electronic health record systems, using a consistent messaging format and device semantic content.
Status: Final Text Q2/2011; Connectathon 27 vendors; Registry: 4 products (we estimate ~20 products by end of year).
[IDCO] Implantable Device – Cardiac – Observation specifies the
creation, transmission, and processing of discrete data elements and report attachments associated with cardiac device interrogations
(observations) or messages. Status: Final Text Q2/2011; Connectathon 10 vendors; Registry: 0 products.
[PIV] Point-of-care Infusion Verification supports communication of
a 5-Rights validated medication delivery / infusion order from a BCMA system to an infusion pump or pump management system. Status: Final Text Q2/2011; Connectathon 7 vendors; Registry: 0 products.
[ACM] Alarm Communication Management enables the remote
communication of point-of-care medical device alarm conditions ensuring the right alarm with the right priority to the right individuals with the right content (e.g., evidentiary data). Status: Trial Implementation, Final text Q2/2012; Connectathon 13 vendors; Registry: 3 products.
[WCM] Waveform Communication Management provides support for
the communication of physiological 2-dimensional waveforms. Status: Trial Implementation; expect first Connectathon participants in 2012.
Roadmap
Roadmap
http://wiki.ihe.net/index.php?title=PCD_Roadmap
1. Deployments - getting products with IHE-PCD actors
implemented in the marketplace.
2. Clinical Integration Profiles - multi-domain projects to
encompass entire workflows that involve actors from different domains
3. Alarm and Event Management
4. Semantic Interoperability
5. Device Specialization Profiles
Medical Equipment Management:
Device Maintenance
Medical Equipment Management:
Device Maintenance
Working towards effective Predictive Maintenance
•
In 2011 we plan to establish Content Profiles
for acquisition of device status and logs
•
Rosetta Terminology Mapping:
Establish the required IEEE 11073 terms, and
enumerations
•
Leverage DEC and ACM Profiles and PCD-01
Medical Equipment Management:
Cybersecurity
Medical Equipment Management:
Cybersecurity
Cybersecurity Whitepaper final version
IHE Standards Adoption Process
IHE Standards Adoption Process
Document Use Case Document Use Case Identify available
standards (e.g. HL7, DICOM, IEEE, IETF) Identify available standards (e.g. HL7, DICOM, IEEE, IETF)
Develop technical specifications Develop technical specifications Testing at Connectathons Testing at Connectathons IHE Demonstrations IHE Demonstrations Products with IHE Products with IHE
Improved safety, quality & efficiency!
Improved safety, quality
Take-Aways
Take-Aways
Plan for interoperability now
Prepare roadmaps
Leverage IHE
Research other standards work
Monthly CE-IT integration meetings with key
stakeholders
Involve all resources necessary at technology
