Submitting WG/Project/Implementer Group
Health Care Devices WG, "Devices on FHIR" Project
Justification and Objectives
The purpose of the Device Track at the 2019-09 FHIR Connectathon is to provide an opportunity for implementers and other interested participants to familiarize themselves and gain hands-on experience with device observation data, and the FHIR representations and responsibilities of communicating devices from small wearable personal health devices to complex multicomponent acute-care devices like ventilators, anesthesia workstations, infusion pump systems, and multiparameter physiological monitors, including discussion of the PHD and PoCD FHIR Implementation Guides. Few people will probably come with implementations, which is fine; a desire to ask questions and offer opinions is sufficient, and drop-ins primarily participating in other tracks are welcome at any time.
This track will use R4 version of FHIR.
Clinical input requested
Clinical input regarding particular requirements for data transfer from devices to EMRs, and other scenarios including device alerts is highly sought after and welcome.
Proposed Track Lead
John Rhoads, firstname.lastname@example.org
Continua / Personal Connected Health Alliance
Lamprey Networks - Brian Reinhold - personal health device data reporter - device data consumer - various devices
Stefan Karl, John Rhoads - patient monitor point-of-care device data reporter - device data consumer
Ana Kostadinovska - thermometer, glucose meter personal health device data reporter
Trusted Solutions Foundry - Todd Cooper
Draeger USA - John Dyer
Medtrontic - Myron Finseth
Anyone interested in FHIR aspects of device-originated data and device-related scenarios including device alerts, future plans and roadmaps, IEEE 11073 concepts and nomenclature for devices and for physiological and technical data. No related experience required.
Slides and written orientation guide to be available.
Role 1 Device Observation Reporter
Creates and communicates FHIR form of device observation report with attendant supporting device data and metadata. Report content may be clinically oriented (e.g. blood pressure) or technology management oriented (e.g. battery charge state). May be specialized for personal health device reporting or point-of-care (acute care) reporting, or may support both. May operate directly as a component of a device or device gateway, or as an HL7 V2 to FHIR converter. Systems in this role are expected to pass this information as a bundle with specified content to a FHIR server and check the result.
Role 2 Device Observation Consumer
Receives communications from a reporter or retrieves resources from FHIR server corresponding to a device observation report with attendant supporting device data and metadata, and makes them available in a form suitable for storage or presentation in clinical contexts or in technology management contexts. May be specialized for personal health device reporting or point-of-care (acute care) reporting or may support both. Could be implemented (for example) as a free-standing display app or as a converter component for an existing electronic medical record or computerized medical equipment management system.
Scenario 1 Report a device observation and associated data
Describe the different scenarios participating systems can engage in during the connectathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.
Scenario Step 1 Personal Health Device Observation Report created and communicated to a FHIR server
Action: Create a transaction bundle conforming to the current version of the FHIR Personal Health Device Implementation Guide containing an observation from a real or simulated device and transmit it to a FHIR server.
Precondition: An observation of one or more quantitative or qualitative values is available, along with the supporting data about the device and the gateway (PHG) responsible for it as specified for it in the IG. If the specific configuration is capable of it, patient identity information including, at a minimum, a name and date of birth is associated with
Success Criteria: FHIR server indicates the bundle is accepted on several independently developed servers (i.e. HAPI FHIR servers, Pyro server, GTS)
Scenario 2 Access and use a device observation and associated data
Scenario Step 1 Personal Health Device Observation Report is retrieved by a software component and information is appropriated interpreted and stored
Action: Search for and retrieve the resources associated with a Personal Health Device Observation Resource and be able to show that it has been received by your system, in logs, or a command-line or other displays. A remote patient monitoring application will be available to retrieve and display uploaded PHD data.
Bonus point 1: a single-view presentation of the most important parts of the device observation data.
Bonus point 2: reading application (RPM) subscribes to PHD data.
- A "workbook"-type test script for Postman-type retrieval or prepopulated device observation data as a learning resource not requiring any programming.
- Inspection reports for device observation bundles including full device, patient, and observation details.
Expected test components
- Android uploaders
- RPM application
- Personal Health Devices – pulse oximeter, thermometers, glucose meters, ECG, blood pressure meters
- Personal Health Devices - physiological monitor with ECG measurements and pulse oximeter data
Security and Privacy Considerations
No requirement for use of TLS or other particular security measures at this time. However, if the server supports TLS, the uploader and reader can setup a TLS session with the server.