POINTOFCARE DEVICES IN FHIR 2019 09 FHIR CONNECTATHON

POINT-OF-CARE DEVICES IN FHIR 2019 -09 FHIR CONNECTATHON

WHAT’S A POINT-OF-CARE DEVICE? • Differences from Personal Health Devices • Acute-care environments – ICUs, ORs, General wards, Procedure rooms, … • Different scale and complexity – measure more things, more structure in the devices and in the data derived from them • Always regulated medical devices – used for physiological measurements (e. g. multiparameter monitors) or therapy (e. g. ventilators, anesthesia workstations, infusion pumps, balloon pumps, dialysis machines, etc. ) • PHDs used by consumers; Po. CDs generally operated by trained professionals

DATA DIFFERENCES BETWEEN PHD AND POCD DEVICES • PHD conforms to a set device specialization • Po. CDs are often multicomponent and this is represented by a dynamic hierarchical containment tree: the whole device (Medical Device System, MDS) typically contains multiple subsystems (Virtual Medical Device) which can have Channels which can measure or report Metrics (physiological measurements, waveforms, device state indicators)

ISO/IEEE 11073 -10201 DOMAIN INFORMATION Real example device – MODEL AT A GLANCE Abstract model Medical Device System (MDS) The whole device Virtual Medical Device (VMD) A functional component Channel – only significant for some devices Metric – a single measurement / observation capability MDS VMD FHIR Representation A multiparameter physiological monitor The whole monitor A plug-in measuremen t module Monitor can contain many VMDs VMD can produce many metrics Channel Metric A single measurement, say, arterial pressure Metric has multiple attributes Top Level Device resource Parent Child Device resource Parent Device. Metric Resource

HOW DO MOST POCDS TRADITIONALLY REPORT THEIR DATA • Most often in a one-off vendor proprietary protocol • How can a system from another vendor, like an EMR, use this? • Write a custom driver (ick, may need hundreds of them, what about bugs and updates? ) – who wants to assign that many engineers for this? • Delegate the job of understanding and attendant business problems to third-party middleware or other devices that can proxy the data in a standard manner • What about standards? • IEEE 11073 Medical Device Communications standards, based on ISO/IEEE 11073 -10201 Domain Information Model (DIM) MDS-VMS-Channel-Metric • HL 7 V 2 e. g. IHE Patient Care Device: Device Enterprise Communications • Based on an HL 7 V 2 translation of the DIM model • Few products output this directly

DATA MAY COME FROM DEVICE ITSELF, OR FROM A DATA GATEWAY SYSTEM • May be third-party middleware software on a general purpose computer • May have to deal with legacy serial-port hardware (the dreaded RS-232)

WHY BOTHER WITH STANDARDS AND FHIR FOR DEVICES? WHAT’S THE PROBLEM • There are 400+ devices with proprietary protocols, often with non-standard identification for the data items. Does everybody wanting to use device need to implement support, and maintain that? Ridiculous. • There are 20+ flavors of EMR input for device data • (Thanks to Paul Schluter, Center for Medical Interoperability, for these appalling stats)

WHY BOTHER, CONTINUED. THE “ROACH MOTEL” PROBLEM • With all these variations in data form and data item identification, once you get the device data into a system, there is no trustworthy general way of getting them out (think clinical decision support and analytics). The data go in somewhere, but it is nigh unto impossible to get them out (the well-known device data theorist Jan Wittenber likened it to the “Roach Motel” roach catcher – they go in but they never come out). • You need a well-known way to access the data (widely known and used protocols), and to fully understand what it is once you’ve got it (standard terminology). FHIR looks pretty good for this.

WHAT ABOUT FHIR AND POINT-OF-CARE DEVICES? • Metrics go into Observation resource, linked to a Patient resource • Also linked to a Device FHIR resource (more about this later) • Observation is a carrier for the result. This is fine as far as it goes – it may be all that the receiving system wants • But what about device metadata? There may be other things you need to know about how the device is set up, what its dynamic state is and what are the circumstances of the measurement?

THE DEVICE FHIR RESOURCE • http: //build. fhir. org/device. html • Identification of the device (or component) instance • Unique Device Identification (UDI) • Or if not available, other available identity information: manufacturer • Linked to parent device resource if applicable • Linked to other relevant resources: patient, owner organization, contact, location • Other information: safety characteristics, notes

DEVICE FHIR RESOURCE DETAILS

THE DEVICEMETRIC FHIR RESOURCE • http: //build. fhir. org/devicemetric. html – supplementary information on specific measurement

MULTICOMPONENT DEVICES REPRESENTED BY MULTIPLE DEVICE FHIR RESOURCES • Linked in a hierarchy – a dynamic constellation of active components • MDS the parent • VMD links to containing parent resource • Channels link to parent VMDs • Metrics link to parent Channel • Device resources have attributes of corresponding component • Device. Metric has the special attributes of individual metrics

THERE ARE DIFFERENT KINDS OF METRICS • The first one you likely think of is the numeric kind: heart rate, respiration rate, oxygen saturation, etc. • Enumeration: mild/moderate/severe, heart rhythm type, etc. • Waveform: ECG, various ventilator waveforms, etc.

ANOTHER ANGLE: METADATA ABOUT CLINICAL OBSERVATIONS • Devices can and do communicate a whole lot besides the clinical observations • Rich metadata about the clinical observations. Highly detailed provenance (exactly where the data came from, down to the

YET ANOTHER ANGLE: DATA ABOUT THE DEVICE TO SUPPORT ITS CARE AND FEEDING • Besides the clinical data and metadata supporting it, devices send lots of information relevant to keeping them safely operational, to biomeds and their Computerized Maintanance Management Information systems • Software versions sent and can be checked for the need of updates for security or functionality • Operational states may be used for ‘hours used’ recording and similar items • Locational information (where the device is) may be available and can be invaluable for people wanting to use that kind of device • Devices may send maintenance warnings (users will know if power-up self test failed, but they’re busy and may not inform biomedical engineering department promptly) • And much more