1. Point-of-care devices in fhir
FHIR Connectathon

2. 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

3. 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)

4. 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

5. 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 Medical Device Communications standards, based on ISO/IEEE 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

6. 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)

7. 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)

8. 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.

9. 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?

10. The device fhir resource
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

11. Device FHIR Resource details

12. The devicemetric fhir resource
– supplementary information on specific measurement

13. 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

14. 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.

15. 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)

16. 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