Nurse Lisa notices that a blood pressure device on the ward is defective and is producing incorrect measurement values. The same device has been used to take spot measurements on several patients over the previous days. After discussing the issue with her colleagues, the biomedical engineering team is asked to determine which patients had measurements taken with this device since its last technical inspection.

Using the device's unique identifier, the team queries the patient records to find every encounter in which the device was used, along with the measurements it produced. The affected measurements are then labeled as suspicious or erroneous in each patient's record, and clinicians are notified so that new measurements can be taken. The captured device-to-patient linkage and the time-bounded usage records make it possible to support future safety reviews, equipment recalls, and quality investigations.

• Support retrospective device recall and safety investigations bounded by a service interval (e.g., last technical inspection to present).
• Allow erroneous observations to be flagged or amended without losing the original record.
• Maintain a maintenance/inspection history of the device sufficient to bound the period of suspect data.
• Support notification workflows so affected patients can be re-measured.

• UDI-based device identification to enable cross-system lookup of the same device instance.
• Linkage between Observation, Device, and Patient that is preserved when data is exchanged between EHR, biomedical asset management, and quality reporting systems.
• Possible reporting to manufacturer or regulatory recall workflows when a defect is confirmed.

• Use Device to represent the specific INSTANCE of the blood pressure monitor (uniquely identified, e.g., by UDI or serial number). Use DeviceDefinition only when catalog-level information (make/model capabilities) is needed in addition to the instance.
• Each measurement is recorded as an Observation with Observation.device referencing the Device instance and Observation.subject referencing the Patient. This is the primary linkage used to locate suspect measurements.
• For spot measurements with non-communicating devices, DeviceAssociation records the time-bounded association of the device with each patient; DeviceUsage can additionally capture details of how the device was used.
• Distinguish DeviceMetric (device-reported settings/metric definitions for communicating devices) from Observation (the clinical measurement value). For a simple non-communicating BPM, Observation alone is typically sufficient.
• For longitudinal traceability, bound queries by the device's last inspection/maintenance event and query Observation, DeviceAssociation, and DeviceUsage records referencing the Device within that interval.
• Mark affected Observation records as suspect using Observation.status (e.g., entered-in-error) or by amending with corrected results, preserving audit trail.

• Device examples
• DeviceAssociation examples
• Observation examples
• DeviceUsage (OO Incubator)

• Device instance identifier (e.g., UDI, serial number) and device type
• Device maintenance / last technical inspection date
• Patient identity for each subject the device was used on
• Measurement values and time of each Observation produced by the device
• Time-bounded association/usage record linking device to patient
• Practitioner who performed the measurement (optional)

Patient Josh is sedated and ventilated in the ICU. During a case review, doctor Sarah notices that Josh's respiration rate was unexpectedly low for a few minutes during the previous shift. To investigate whether the ventilator settings were the cause, Sarah retrieves the device settings that were active in the period starting one hour before and ending one hour after the abnormal readings.

By correlating the time-stamped settings records with the measurement timeline, Sarah discovers that the ventilation mode was changed during that window and then reverted a few minutes later. This insight allows her to attribute the anomalous readings to the transient mode change rather than a clinical deterioration, and to document the finding for the clinical team and for equipment governance review.

• Support time-bounded queries that retrieve both measurement observations and the device settings (metric configurations) effective during a given interval.
• Preserve a complete, timestamped history of device setting changes so that the active configuration at any past point in time can be reconstructed.
• Link setting records unambiguously to the specific device instance and, where applicable, to the patient being treated.
• Support audit and governance workflows that review who changed a setting and when.

• Device settings must be exchanged alongside measurement observations so that receiving systems can reconstruct the full operational context of a measurement.
• Timestamps on settings records must be sufficiently precise (sub-minute resolution) and aligned with the timestamps on Observation resources to allow accurate temporal correlation.
• Settings and measurements originating from different subsystems (e.g., ventilator vs. bedside monitor) must share a common device reference so that queries across systems return a coherent picture.
• Possible integration with clinical incident reporting or equipment governance systems when an unexpected setting change is identified.

• Use Device to represent the specific INSTANCE of the ventilator (uniquely identified by UDI or serial number).
• Use DeviceMetric to describe each measurable or configurable channel of the device (e.g., ventilation mode, tidal volume setting, respiration rate). Each DeviceMetric references its parent Device and captures the metric's operational state and calibration status.
• Record each clinical measurement produced by the device as an Observation with Observation.device referencing the relevant DeviceMetric (or the Device directly). This is the primary resource for measurement values.
• Record device configuration values (settings) also as Observation resources, using an appropriate category (e.g., http://terminology.hl7.org/CodeSystem/observation-category|procedure or a device-settings category) and codes that identify the setting being captured. Each settings Observation must carry a precise Observation.effectiveDateTime or Observation.effectivePeriod so that the active configuration at any past moment can be determined.
• To retrieve the settings window, query Observation records with the device reference, the relevant setting codes, and a date (effective time) parameter spanning the desired interval.
• Optionally, use DeviceAssociation to record the time-bounded association of the ventilator with the patient, providing the context needed to scope queries to a specific patient-device pairing.

• Device examples
• DeviceMetric examples
• Observation examples
• DeviceAssociation examples

• Device instance identifier (e.g., UDI, serial number) and device type
• DeviceMetric definitions for each measured and configurable channel of the ventilator
• Timestamped Observation records for each clinical measurement (e.g., respiration rate) produced by the device
• Timestamped Observation records for each device setting value, with sufficient precision to reconstruct the active configuration at any past point in time
• Patient identity to scope the clinical context
• Practitioner or user identity associated with setting changes (for audit purposes)

Patient Helen is recovering from heart failure in the cardiology ward. She wears a portable telemetry monitor around the clock that continuously measures her EKG. During the night shift, nurse Frank receives a tachycardia alarm from Helen's monitor. Helen's current heart rate is 97 bpm, which Frank does not consider clinically concerning based on his experience. He checks on Helen, confirms she is comfortable, and returns to the nurses' station.

Wanting to understand why the alarm triggered at such a low heart rate, Frank queries the alarm record to determine which tachycardia threshold was active at the time the alarm fired. He discovers the limit was configured at 90 bpm - significantly below the typical clinical range of 120-140 bpm. This finding prompts a review of the device's alarm configuration, ensuring thresholds are corrected and appropriate for Helen's care plan going forward.

• Capture each alarm event with a precise timestamp and a reference to the device and patient involved.
• Record the alarm threshold values (and their source - default, manually set, or care-plan-driven) that were in effect when the alarm fired.
• Preserve a timestamped history of threshold changes so that the active configuration at the moment of any past alarm can be reconstructed.
• Support clinician workflows that allow alarm configuration review without disrupting active monitoring.
• Support quality and safety investigations by linking alarm events to the responsible practitioner, care plan, and device instance.

• Alarm events and alarm threshold settings must be exchangeable alongside the measurement observations that triggered them, so that receiving systems can reconstruct the full alarm context.
• Timestamps on alarm records and threshold records must be precisely aligned with measurement Observation timestamps to allow accurate temporal correlation.
• Device identity must be consistently represented across alarm management, clinical documentation, and biomedical engineering systems.
• Potential integration with clinical escalation, incident reporting, and alarm fatigue monitoring systems.

• Use Device to represent the specific INSTANCE of the telemetry monitor (uniquely identified by UDI or serial number).
• Use DeviceAlert to record each alarm event. DeviceAlert captures the alarm type, priority, status, the device that raised it, the patient it concerns, and the precise time at which the alarm fired.
• Record the alarm threshold values active at the time of the alarm as Observation resources (or as components within the DeviceAlert if the implementation guide supports it), referencing the corresponding DeviceMetric that describes the configurable alarm channel (e.g., tachycardia upper limit).
• Use DeviceMetric to describe each alarm-capable channel of the monitor, including its current operational state and threshold definitions. Each DeviceMetric references its parent Device.
• To reconstruct the active threshold at the time of an alarm, query the threshold Observation records for the relevant DeviceMetric with an effective time at or before the alarm timestamp.
• Link DeviceAlert to the patient via DeviceAlert.subject and to the device via DeviceAlert.device to enable scoped queries across both dimensions.

• Device examples
• DeviceAlert examples
• DeviceMetric examples
• Observation examples

• Device instance identifier (e.g., UDI, serial number) and device type
• DeviceMetric definitions for each alarm-capable channel (e.g., tachycardia upper limit, bradycardia lower limit)
• DeviceAlert record for each alarm event, including alarm type, priority, status, and precise timestamp
• Timestamped threshold configuration records (as Observation resources or DeviceAlert components) for each alarm channel, enabling reconstruction of the active threshold at any past point in time
• Patient identity to scope the clinical context
• Practitioner or user identity associated with threshold changes (for audit purposes)
• Measurement Observation that triggered the alarm (e.g., the heart rate value that exceeded the threshold)

Maria works for the outpatient service contractor of her town's hospital and is responsible for managing the stock of home ventilators. While reviewing the device inventory, she notices a ventilator with an unknown status. To investigate, she queries the device's historical records in the system.

The records show that the ventilator was assigned and dispensed to a patient the previous year and was returned to the storage room two weeks ago. However, the device has not yet been administratively unassigned from that patient, leaving its status ambiguous. After physically confirming that the device is present in the storage room and is in operative condition, Maria updates the device's association record to reflect that it has been returned and is now available for the next outpatient.

• Record each stage of the device lifecycle (allocated, dispensed, in use, returned, available) with precise timestamps.
• Maintain an association record that links the device to the patient for the duration of the loan and is explicitly closed when the device is returned.
• Support retrospective queries over the full history of a device's assignments and returns, enabling stock reconciliation and dispute resolution.
• Support status corrections when the physical state of the device (e.g., returned to storage) and the electronic record are out of sync.
• Prevent a device from being re-assigned while it is still electronically associated with a previous patient.

• Device identity (UDI or serial number) must be consistently represented across the EHR, the contractor's stock management system, and any biomedical engineering systems to enable cross-system lifecycle queries.
• Patient identity must be linked to device association and dispense records in a way that is preserved when data is exchanged between the hospital and the outpatient contractor.
• Status updates (e.g., return events) originating in one system must be propagated to all systems that hold a copy of the association record to avoid stale data.
• Possible integration with procurement and maintenance systems for end-of-life or repair workflows.

• Use Device to represent the specific INSTANCE of the home ventilator (uniquely identified by UDI or serial number). The Device.availabilityStatus element reflects the device's availability for use (e.g., available).
• Use DeviceAssociation to record the time-bounded relationship between the device and the patient. When the device is returned, DeviceAssociation.period.end and DeviceAssociation.status must be updated to reflect the end of the loan.
• Use DeviceDispense to record the dispensing event (when the device was physically handed to the patient) and, where supported, the return event. DeviceDispense.status tracks the current state of the dispense transaction.
• To reconstruct the full lifecycle of a device, query DeviceAssociation and DeviceDispense resources filtered by the device identifier, ordered by date, to obtain a chronological history of all allocation, dispense, and return events.
• When a discrepancy between the physical state and the electronic record is identified, update DeviceAssociation.status and Device.availabilityStatus to reflect the corrected state, preserving the original records for audit purposes.

• Device examples
• DeviceAssociation examples
• DeviceDispense examples

• Device instance identifier (e.g., UDI, serial number), type, and current availability
• Patient identity for each patient the device was assigned to
• DeviceAssociation records covering each allocation period, with start and end timestamps
• DeviceDispense records for each dispense and return event, with timestamps and status
• Practitioner or staff identity responsible for each lifecycle transition (for audit purposes)
• Location (e.g., storage room) when the device is not associated with a patient

Lizzy is the attending physician in a general ward. She has an elderly patient with pulmonary edema who recently experienced an acute cardiorespiratory event. Given the patient's risk of rapid deterioration, Lizzy decides that continuous monitoring is necessary.

Through the hospital's EHR, Lizzy submits a monitoring order specifying continuous EKG and SpO2 surveillance and periodic blood pressure measurements for the next 72 hours. The order is communicated to the nursing staff and, where the infrastructure supports it, to the biomedical equipment management system so that an appropriate bedside monitor can be allocated and associated with the patient. The resulting device assignment, any dispense event, and the observations produced during the monitoring period are all traceable back to the original order.

• Support specification of monitoring type (continuous vs. periodic), measured parameters, and monitoring duration in the order.
• Allow the order to drive device allocation workflows, including selection of a device type or specific device instance.
• Maintain a traceable link between the order, the device association or dispense event, and the observations produced.
• Support modification or cancellation of the monitoring order and propagation of those changes to active device assignments.
• Allow the order to be fulfilled by either a specific device instance or any device conforming to a defined device type.

• The monitoring order must be communicated from the EHR to nursing workflow systems and, where applicable, to biomedical equipment management systems.
• Device type specifications in the order must be expressed in a way that can be matched against the device inventory (using DeviceDefinition or coded device type).
• Observation resources produced during the monitoring period must reference both the fulfilling device and the originating order to support clinical and operational reporting.
• Possible integration with scheduling systems for periodic measurements and with alarm management systems for threshold configuration.

• Use ServiceRequest as the primary resource to represent the monitoring order. ServiceRequest.code specifies the type of monitoring (e.g., continuous cardiac monitoring); ServiceRequest.occurrence captures the 72-hour duration.
• Where the order must specify a device type rather than a specific instance, use a coded service or a related DeviceRequest that references the relevant DeviceDefinition or specific Device.
• Once a device is allocated, use DeviceAssociation to record the time-bounded association of the specific Device instance with the patient, referencing the fulfilling order where supported.
• Where a device is formally dispensed (e.g., attached or handed over by biomedical staff), use DeviceDispense to record the dispense event.
• Each Observation produced during the monitoring period should reference the device via Observation.device and may reference the order via Observation.basedOn to maintain full traceability.

• ServiceRequest examples
• DeviceRequest examples
• Device examples
• DeviceAssociation examples
• DeviceDispense examples
• Observation examples

• Patient identity and clinical context (diagnosis, risk level) driving the order
• ServiceRequest specifying monitoring parameters, mode (continuous/periodic), and duration
• Device type or specific device instance selected to fulfill the order
• DeviceAssociation record linking the device instance to the patient for the monitoring period
• DeviceDispense record for the allocation/dispense event (where applicable)
• Observation resources produced during the monitoring period, referencing the device and the order
• Ordering clinician and responsible practitioner identities

F1 (PHD scenario): Deborah manages a cohort of outpatient cardiac monitoring patients who wear Holter monitors and take daily weight and blood pressure measurements at home. Following recent incidents of rapid clinical deterioration, her employer decides that all weight scale and blood pressure devices in the field should upload their stored readings daily rather than three times per week. Deborah remotely reconfigures the reporting schedule on all affected device types so that any stored readings are transmitted every day.

F2 (PoCD scenario): Rob is a nurse working at a central monitoring unit overseeing dozens of patients in two hospital wards. He notices that post-surgery patient Jingze has all vitals within normal range but appears restless in the video feed. Given that Jingze's sedation dosage has been low for the past 12 hours, Rob raises a remote command to configure the benzodiazepine infusion pump at Jingze's bedside to administer a bolus dose. The command is issued through the clinical system, delivered to the pump, and the resulting administration is recorded as an observation.

• Support issuance of device configuration commands (e.g., change reporting frequency, trigger bolus) by authorized users only, with appropriate access control.
• Record each command with its originating clinician, target device, target patient (where applicable), requested setting or action, and timestamp.
• Capture the outcome of the command (accepted, rejected, executed, failed) and link it back to the original command record.
• For F1: support bulk reconfiguration of all devices of a given type across a patient cohort.
• For F2: ensure that drug administration commands are subject to clinical safety checks (dosage limits, allergy checks) before execution.
• Preserve an immutable audit trail of all remote configuration changes for safety and regulatory purposes.

• Remote commands must be expressed in a standardized format that can be interpreted by the receiving device gateway or device management system.
• Device identity must be consistently represented across the clinical system, the device gateway, and the device itself.
• For F2, the command and its resulting drug administration must integrate with medication administration and clinical decision support systems.
• Observation resources reflecting the outcome of a configuration change (e.g., confirmed new reporting schedule, bolus delivered) must reference the originating command for traceability.
• Possible integration with alarm and escalation systems if a command fails or the device does not respond.

• Use Device to represent the specific instance (F2) or the device type cohort (F1) targeted by the command. For F1, where the command targets a device type rather than a single instance, reference a DeviceDefinition.
• Use ServiceRequest to represent the remote configuration command or action request. ServiceRequest.code identifies the action (e.g., change reporting schedule, administer bolus); ServiceRequest.subject references the patient; the target device is identified by the request details or by a related DeviceRequest or DeviceAssociation, as appropriate.
• Where the command targets a specific metric or operational channel of the device, reference the relevant DeviceMetric to provide the configuration context.
• Record the outcome of the command (e.g., confirmed new setting, bolus administered) as an Observation with Observation.basedOn referencing the ServiceRequest, providing end-to-end traceability from command to clinical effect.
• For F2, ensure the ServiceRequest is routed through the appropriate clinical safety and authorization workflow before the command is delivered to the device gateway.
• For F1 bulk reconfiguration, one ServiceRequest per device instance (or a group-level request if the implementation supports it) should be created to maintain per-device audit records.

• ServiceRequest examples
• Device examples
• DeviceMetric examples
• Observation examples

• Device instance or device type identifier for the target device(s)
• Patient identity (where the command is patient-specific, as in F2)
• ServiceRequest encoding the command type, target setting or action, and requested value
• Authorizing clinician or administrator identity
• Timestamp of command issuance and outcome timestamp
• Command outcome status (accepted, executed, failed, rejected)
• Observation recording the resulting device state or clinical effect (e.g., updated reporting schedule, bolus administered), referencing the originating ServiceRequest
• For F2: medication details (drug, dose, route) for the bolus command