1 / 56

Ken Fuchs Mindray North America Secretary IEEE 11073 Co-Chair IHE PCD Domain

Medical Device Interoperability and Relevant Standards Efforts IEEE 802.15.4j Meeting July 18, 2012. Ken Fuchs Mindray North America Secretary IEEE 11073 Co-Chair IHE PCD Domain. Medical Device Requirements What is Interoperability? MD Interoperability Players ISO/IEEE 11073 IHE PCD

essien
Download Presentation

Ken Fuchs Mindray North America Secretary IEEE 11073 Co-Chair IHE PCD Domain

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. Medical Device InteroperabilityandRelevant Standards EffortsIEEE 802.15.4j Meeting July 18, 2012 Ken Fuchs Mindray North America Secretary IEEE 11073 Co-Chair IHE PCD Domain

  2. Medical Device Requirements What is Interoperability? MD Interoperability Players ISO/IEEE 11073 IHE PCD Continua Other Interoperability “Players” Discussion Overview

  3. Point-of-Care: The Need Clinicians are starting to assemble MDs at the patient bedside. These devices need to talk to each other as well as to local data aggregators. Aggregators need to get the data to the EMR/EHR…

  4. Fixed configuration, e.g. anesthesia Data Processing System / PDMS Point-of-care Syringe Pumps and Infusors Patient Monitor Respirator Additional Pump – but changing periodically, and evolving over time Additional Monitor

  5. Variable configuration, e.g. intensive care Point-of-care Data Processing System / PDMS Many Syringe Pumps and Infusors Respirator Patient Monitor - changing frequently and within minutes

  6. Easy to Use and Safe • These systems need to operate safely under all conditions yet be easy to assemble. • In the future many of these devices will be wireless. • Only covers Layer 1… • Usable solutions will require a complete “stack” • For Medical Devices Layer 7 is the “Wild West” …

  7. What is Interoperability? • IEEE defines Interoperability as: • the ability of two or more systems or components to exchange information and to use the information that has been exchanged • AAMI has recently offered a Medical Device focused definition… • the ability of medical devices, clinical systems, or their components to communicate in order to safely fulfill an intended purpose. • Includes concepts of safety and intended purpose • Not very specific as to the amount of “glue” required to get these systems to talk to each other.

  8. Do we have MD Interoperability? • While most acute care devices are built around proprietary interfaces… • Most, if not all, EMRs can connect to devices • We have a growing contingent of vendors (Capsule, Nuvon, iSirona, Cerner, etc.) providing device integration middleware and services. • Patient monitoring vendors have created interoperable systems incorporating many 3rd party devices. • Clinicians have developed many demonstrations and applications showing device interoperability. • Maybe we already have Interoperability…

  9. Do We Have MD Interoperability? Probably not … Each new device integration is a custom effort requiring months of nursing/engineering skills It can cost between $6,750 and $10,000 per bed to integrate the devices, including ventilators, in a typical ICU (Moorman, 2010) Clinicians desiring to use a new device must wait for their application vendor to develop a new driver (which may never happen) The complexity of device interfacing may be hindering research which could lead to improved patient care Purchasing decisions are driven by whether an interface to specific devices exists

  10. Do We Have MD Interoperability? More issues with our current reality… Safety issues can arise due to the sizable SW effort and on-site customization required to integrate devices Costs to the Providers for system integration services are very high Not all required data to accomplish a Use Case may be available There can be finger pointing when trying to resolve problems Too much complexity in maintaining each link in the communication chain As device or system software is updated solutions break

  11. Current State of MD Interoperability?

  12. Is this the best we can do? When we say systems are Interoperable, does that mean that as long as there is some way of getting “stuff” from one system to another, we are happy? BASIC Interoperability Or, do we expect that we only need to point these systems at each other and stand back, satisfied that the job is done? SEAMLESS Interoperability Clearly we should be focused on achieving SEAMLESS Interoperability… Sometimes referred to as Plug and Play Interoperability

  13. Are Standards the Solution? • We have many Lower Layer Standards • And we have many Upper Layer standards: • HL7 • IEEE 11073-10101, 10xxx, etc. • IEEE 11073-20601, 40xxx, etc. • ASTM F2761 (ICE) • DICOM • ISO TC215, CEN TC251, IEC, etc. • So, what is the problem? • Standards are just a starting point.

  14. MD Interoperability Landscape

  15. Understanding Interoperability

  16. HL7’s Model of Interoperability

  17. Turnitsa’s Model Definition Increasing Capability for Interoperation Dynamic Dynamic Contextunderstood Level 5 Interoperable Pragmatic Contextunderstood Level 4 Semantic Meaningunderstood Level 3 Integratable Level 2 Syntactic Common Format Level 1 Technical Common Physical and Transport Layers Interfaceable Level 0 None Stand-alone

  18. Turnitsa’s Model - Annotated Example Increasing Capability for Interoperation Dynamic Resource and LoadManagement Level 5 Interoperable Pragmatic IHE PCD / ContinuaUse Case based Profiles… Level 4 Semantic Snomed, IHE-PCD RTM,IEEE 11073-10101, LOINC… Level 3 Integratable Level 2 Syntactic HL7, IEEE 11073, Continua… Level 1 Technical RS232, Ethernet, 802.11,Zigbee, BT, USB, TCP/IP… Interfaceable Level 0 None Stand-alone

  19. Interoperability Eco-System Increasing Capability for Interoperation Dynamic Level 5 Certification Association Authentication Authorization Discovery Safety Security Interoperable Pragmatic Level 4 Semantic Level 3 Integratable Level 2 Syntactic Level 1 Technical Interfaceable Level 0 None

  20. MD Interoperability Eco-System • Device Interoperability based on Framework(s) of Open Standards • Profiles of Standards • Conformance Testing • Certification Testing • Regulatory Pathways • etc. • Incentives that drive all parties to comply with these Framework(s) • There are a number of organizations that are working towards this in the medical device space.

  21. ISO/IEEE 11073Point of Care Medical Device Communication

  22. IEEE 11073 - Charter Point-of-care Medical Device communication: • Provide real-time plug-and-play interoperability for patient-connected medical devices • Facilitate the efficient exchange of vital signs and medical device data, acquired at the point-of-care, in all health care environments … Leveraging off-the-shelf technologies, scaling across a wide range of system complexities, and supporting commercially viable implementations.

  23. Overview • 11073 is a comprehensive system of point-of-care medical device communication standards • 11073 device types range from real-time-operating medical equipment to point-of-care test • 11073 supports wired, wireless IR and wireless RF network technologies • 11073 provides plug-and-play, internetworking and application gateway capabilities

  24. 11073 - Architecture Requirements: • True interoperability across all 7-layers from the ‘connector’ to the end application • Mechanisms to support the strong quality of service (safety) requirements placed on regulated medical devices • Maintainability as communications technology and applications change

  25. Data & Information Definitions 11073.1xxxx 11073.2xxxx Application Profiles Transport & Physical Layers 11073.3xxxx Internetworking Support 11073.5xxxx Application Gateways 11073.6xxxx Related – some shared concepts 11073.9xxxx Series structure

  26. 11073-1xxxx content Semantics needed to communicate a device’sstructure, application data, status and control information. Three main components: • Nomenclature: 11073.10101 • Domain Information Model (DIM): 11073.10201 • Device Specialisations: 11073.103xx

  27. 11073-10101 Nomenclature Nomenclature: A set of numeric codes that identify every item that is communicated between systems.

  28. Domain Information Model: An object oriented data model that specifies objects, attributes, attribute groups, event reports, and services that may be used to communicate device data and to control / configure the reporting of information . . . 11073-10201 Information Model • Medical Devices and Functionalities • Measured Data and Settings • Alert Information • Remote Control • Patient Information • Communication

  29. Domain Information Model

  30. 11073-2xxxx content Application profile standards... • Provide specific sets of capabilities tailored for a class of communication needs / architectures • Limit the options that are available • Remaining options must be discovered and in some cases negotiated when a connection is made (enabling plug-and-play interoperability!)

  31. 11073-2xxxx content Application profile standards... • Define a generic (non-device specific) set of data and services needed to initiate, configure, and maintain communication: Connect / Disconnect, Create / Delete, Get / Set, Event Report, Invoke, etc. • Specify the use of Standard Service Elements: ACSE, ROSE, CMISE, ASN.1, MDER (based on BER+), etc. • Provide optional packages, e.g for remote control

  32. 11073-3xxxx content Lower Layer Profiles: Point-to-Point transport standards… • IrDA-Based Cable Connected (11073.30200) • IrDA-Based Infrared Wireless (11073.30300) At various time also considered… • RF Wireless – high emphasis on QoS! • IP-Based (Ethernet)

  33. TR: Guidelines … RF wireless Use case topological overview

  34. TR: Guidelines … RF wireless Possible difficulties to be overcome… • High importance of data communicated • ‘Unknown’ communication capacity available • Security implications for different types of medical information remain difficult to determine – and standardise

  35. 1. Acute Care ECG Device POCT Device Monitor 1073 Cabled MDC Devices Ventilator IEEE 1073 & IrDA AP 5. POC Dev w/ EDI IV Pump POCT1 IR POCT Device IrDA AP 4. POC Dev w/ DMI modem modem modem modem Terminal Server Analog Phone Line modem modem modem modem POC Devices co-existence DMI EDI D POC Data Mgr. HIS o 2. General Clinic POCt Device CIS ECG Cart o POCT1 IR Other Dev. Pocket PC Palm PDA 3. Remote Device using Modem POCt Device Other Dev. POCT Device Other Dev.

  36. A history of collaborative and complementary efforts: Arrows indicate effective transfer of development and/or maintenance responsibility. 11073’s Evolution

  37. IHE PCD Domain(Integrating the Healthcare Enterprise - Patient Care Device)

  38. From Base Standards to Profile Standards Base Standards from SDOs Profile Development eHealth Projects IETF IHTSDO CPs

  39. IHE Organizational Structure Global Development IHE North America IHE Asia-Oceania Radiology IT Infrastructure Laboratory China Japan Canada USA Korea Taiwan Cardiology Patient Care Coordination Pathology Radiation Oncology Patient Care Device Eye Care IHE Europe Austria France Germany Netherlands Public Health, Quality and Research Pharmacy Italy Norway Spain UK Sweden Professional Societies / Sponsors ACC ACCE ACEP ACP ACOGHIMSS Contributing & ParticipatingVendors COCIR EAR-ECR DRG SIRM BIR EuroRec RSNA SFRSFIL ESC JAHISJIRAJRS METI-MLHW MEDIS-DCJAMI IHE International Board Regional Deployment

  40. Role of IHE PCD IHE PCD was formed in 2005 to address issues related to integration of Point-of-Care medical devices: With each other With enterprise systems IHE PCD wants to “raise the bar” from the current state of integration projects to out of the box, open, interoperable solutions. PCD Profiles tend to use HL7 and IEEE 11073 Nomenclature and DIM

  41. IHE Profiles Drafted & Revised IHE Development Process Test at IHE Connectathons Implementation Posted Publish in IHE’s Product Registry Demonstrate at a Published For Public Comment 14-18 mos. 6-13 mos. IHE Technical Framework Developed Profile Selection by Committees IHE Improves, Safety, Quality and Efficiency in Clinical Settings. Install Interoperable products in Clinical Settings worldwide IHE Call for Proposals Opens 1-5 mos.

  42. IHE PCD Profiles Physiologic Monitoring System CPOE/ Pharmacy System Clinical Decision Support System Ventilation/AnesthesiaSystem ACM, DEC, WCM, ADQ,PCIM ACM, DEC, WCM ACM, DEC, WCM, ADQ Barcode Medication Administration System EMR/EHR Infusion Pump Implantable Device ACM, DEC PIV IDCO CIS ACM, MEM ACM, DEC, WCM, ADQ,PCIM DEC EquipmentManagement System Home Based System Other Devices ACM: Alarm Communication Management ADQ: Asychronous Device Query DEC: Device Enterprise Communication IDCO: Implantable Device – Cardiac – Observation MEM: Medical Equipment Management PCIM: Point-of-Care Identity Management PIV: Point-of-Care Infusion Verification WCM: Waveform Content Module CurrentPCD FuturePCD Future Non- PCD

  43. Connectathon

  44. PCD @ HIMSS 2010 PCD – HIMSS 2011

  45. Continua Health Alliance

  46. “…to establish an eco-system of interoperable personal health systems that empower people & organizations to better manage their health and wellness”

  47. Continua Process Includes: • Standards Development • Profiles Development • “Plugfests” • Public Demonstrations • Certification Program

  48. Based on Connectivity Standards Thermometer Pulse Oximeter • 11073-10404 = Pulse Oximeter • 11073-10406 = Pulse / Heart Rate • 11073-10407 = Blood Pressure • 11073-10408 = Thermometer • 11073-10415 = Weighing Scale • 11073-10417 = Glucose • 11073-10441 = Cardiovascular Fitness Monitor • 11073-10442 = Strength Fitness Equipment • 11073-10471 = Independent Living Activity • 11073-10472 = Medication Monitor • 11073-20601 = Base Framework Protocol PC Pulse /Blood Pressure Personal Health System Weight Scale Cell Phone Glucose Meter Cardiovascular and Strength Fitness Monitor Set Top Box Independent Living Activity Aggregator Medication Monitor Medical Device Profile Specification Personal Health Device Class Specification

  49. XHR Interface Heart Failure & COPD Device Interface EHR Wireless Pulse Oximeter Telehealth Service PHR Obesity & Diabetes Weighing Scale Telehealth Service EHR Blood Pressure Monitor Telehealth Service Public Interoperability Demos

  50. Other MD Interoperability “Players”

More Related