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., etc.) PHDs used by consumers; PoCDs generally operated by trained professionals

Data differences between phd and Pocd devices PHD conforms to a set device specialization PoCDs often present a single interface to multiple components: 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 model at a glance Real example device – A multiparameter physiological monitor FHIR Representation Abstract model Monitor can contain many VMDs Medical Device System (MDS) The whole device MDS The whole monitor Top Level Device resource A plug-in measurement module Parent Virtual Medical Device (VMD) A functional component VMD VMD can produce many metrics Child Device resource Channel – only significant for some devices Parent Child Device resource Channel Metric – a single measurement / observation capability Parent A single measurement, say, arterial pressure Metric Metric has multiple attributes DeviceMetric 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 HL7 V2 e.g. IHE Patient Care Device: Device Enterprise Communications Based on an HL7 V2 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 DeviceMetric 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)

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