How Should FHIR R5 Store and Exchange Heart Rate Data?

What FHIR R5 Actually Defines for a Patient's Pulse

The direct answer is that FHIR R5 represents a patient's pulse as an Observation resource whose code is LOINC 8867-4 (Heart rate), whose category is the vital-signs code, and whose value is a Quantity in beats per minute using the UCUM unit /min. The resource is linked to a subject, normally a Patient, through subject.reference, and it carries two separate timestamps: effectiveDateTime or effectivePeriod for when the measurement was taken, and issued for when the server recorded it. That distinction is not academic; a wearable that syncs 78 bpm readings at 02:00 should store 02:00 as the effective time and the sync moment as the issued time, otherwise longitudinal trends and alerting drift by hours. In a care-coordination context, the payoff is that a network can pool pulse data from EHRs, home devices, and patient-reported apps behind one query pattern instead of building a bespoke parser per vendor. FHIR R5, published as a normative release in 2023, keeps the Observation model that R4 established in 2016, so the core fields are familiar to most integration teams; the newer release refines bindings, value sets, and guidance around absent data and provenance. For teams building on platforms such as getpulse.care, the ingestion layer can normalize device payloads to a single Observation shape once, and everything downstream, including dashboards, thresholds, and outreach queues, reads the same record.

Also worth reading: What is clinic data exchange architecture and how does it impact multi-site care coordination? · What is the Da Vinci PDex payer data exchange and how does it work for providers and payers? · What Does a FHIR Data Integration Strategy Look Like for 2027?

The phrase patient pulse can also be used metaphorically to mean a dashboard signal of patient engagement or acuity, the kind of metric a B2B care-coordination platform surfaces for clinic staff. In the clinical-data sense, however, pulse means heart rate in beats per minute, and that is what FHIR R5 models. Keeping the two meanings separate prevents a common category error: engagement flags belong in workflow or analytics systems, while the numeric vital sign belongs in clinical resources such as Observation, optionally summarized in a DiagnosticReport or a Composition for a trending view.

The Anatomy of a Pulse Observation

A minimal, conformant heart-rate Observation carries resourceType Observation, an id, a status such as final, one or more category codings using the system http://terminology.hl7.org/CodeSystem/observation-category with the code vital-signs, and a code using http://loinc.org with the value 8867-4. The measurement itself lives in valueQuantity, for example value 78, system http://unitsofmeasure.org, and code /min, with unit set to beats/min for display. The subject points to the Patient, effectiveDateTime records the moment of measurement with a timezone offset such as 2026-09-24T08:15:00-04:00, and issued records when the server accepted the record. Optional elements include referenceRange with a low and high in /min, method such as auscultation or electronic, a device reference, a performer, and a note. When a blood-pressure cuff reports a rate alongside a pressure panel, derivedFrom links the rate to the parent panel, typically LOINC 85354-9, so the numbers stay associated rather than floating loose.

FHIR R5 also makes absence explicit. If a device could not take a reading, or the patient refused, the resource should carry dataAbsentReason with a code such as not-performed, not-asked, or asked-declined instead of a fabricated zero or a silently missing value. The status element distinguishes registered, preliminary, final, amended, corrected, entered-in-error, and unknown, which lets a coordination platform treat a streaming device value as preliminary and a clinician-verified value as final. Provenance and AuditEvent resources record where the data came from and who accessed or changed it, an expectation for any workflow that writes patient-reported data back into the longitudinal record. In short, a pulse Observation is more than a number plus a timestamp; it is a coded, categorized, status-bearing, auditable statement about one patient's heart rate at one moment.

Profiles, Versions, and the Interoperability Stack

FHIR R5 defines the resource and its constraints, but national profiles tighten the rules that matter for exchange. In the United States, the US Core Implementation Guide, whose current major release is 7.0.0 published in 2024, defines a vital signs profile on top of base R4 and R5 structures. That profile constrains category to vital-signs, binds the observation code to the LOINC vital-signs code system, requires the subject to be a Patient, and narrows cardinality for code, category, and value so that a sender cannot submit a free-text label or a non-patient subject. Many vendors still expose R4 endpoints, and the Observation fields used for pulse are compatible across R4 and R5, so a pragmatic architecture reads R5 when offered and writes R4 when necessary, governed by the server's CapabilityStatement. International efforts such as IHE profiles and national EHR specifications add further constraints, and the same 8867-4 code travels well because LOINC and UCUM are global code systems rather than vendor extensions.

Above the resource layer sit two more standards that care platforms need to know. SMART on FHIR, at version 2.2.0 and later, defines OAuth 2.0 scopes and launch flows so a patient app can read or write Observations with the patient's consent and without handling raw credentials. The second is terminology governance: LOINC supplies the clinical code, UCUM supplies the unit, and the value set behind the observation-category code system supplies vital-signs. A B2B platform such as getpulse.care sits between device gateways and clinical systems, so its job is to keep the terminology layer honest, map device-specific units such as bpm or BPM onto /min, and stamp meta.profile with the profiles it actually conforms to. The result is a pipeline that a hospital integration team, a payer analytics team, and a clinic dashboard can all read without renegotiating the data model.

Building a Patient Pulse Pipeline in Practice

Start by defining the use case, because a remote-monitoring alert, an in-clinic triage view, and a research dataset need different levels of detail and different retention. Then map every source to the target shape: a wrist wearable's proprietary bpm field becomes valueQuantity with /min, a phone app's manual entry becomes an Observation with method and note, and a phone-based intake form becomes a patient-reported Observation with a clear performer. Next, choose the write path. A device gateway typically posts a transaction Bundle containing Observations, or an app posts a single Observation to the patient's record through a SMART on FHIR launch with a write scope; both routes end up as resources a FHIR server can query with a request such as a search by code 8867-4, subject, status final, and a date range, sorted descending and capped with a count parameter. From there, build the read path for dashboards, trending weekly averages, and threshold flags, and write back only the records clinicians need, such as a nurse-entered final value that supersedes a preliminary device value.

Validation is where most implementations succeed or fail, so make it explicit. Reject or quarantine records that lack a unit, a code, or a subject; normalize timestamps to UTC with an offset; and attach a device reference so a coordinator can tell a validated cuff reading from an unverified consumer wearable. Deduplicate on device identifier plus effective time plus code, because gateways retry and retries create phantom spikes. Keep preliminary and final values separate in storage so a revised reading does not erase the audit trail, and record provenance targets for every automated write. Finally, measure the pipeline: the share of records with a usable unit, the share with a subject reference, median ingestion latency, and the number of alerts that a nurse acted on versus dismissed. A platform that reports those four numbers every week behaves like a clinical tool; one that reports only message volume behaves like a message queue.

Thresholds, Reference Ranges, and Alert Design

Heart-rate numbers only matter in context. In adults, a resting rate between 60 and 100 bpm is conventionally normal, with persistent rates above 100 classified as tachycardia and persistent rates below 60 as bradycardia, although clinical definitions vary and athletes routinely sit below 60 at rest. Pediatric norms differ sharply: a newborn's resting rate often runs 100 to 160 bpm, a young child 70 to 110, and an adolescent approaches the adult 60 to 100 range, so a single adult threshold will generate needless noise in a pediatric panel. Remote-monitoring programs typically define their own operational limits, and values such as a sustained rate below 45 or above 130 bpm, or a change of more than 20 bpm from baseline, are common starting points that a clinician should individualize rather than accept as universal rules.

Consumer wearables add their own error profile. Photoplethysmography is sensitive to motion and skin tone and is an estimate rather than an electrocardiogram, and in the Apple Heart Study only about 0.84 percent of positive irregular-pulse notifications were confirmed atrial fibrillation, a reminder that a notification is a prompt to seek confirmation, not a diagnosis. Good alert design therefore filters on duration, baseline deviation, and repeatability, since an alert that fires on every transient spike trains staff to ignore it. For a care network, the honest goal is fewer, better-targeted outreach calls, which is why threshold logic belongs in configuration rather than in hard-coded device firmware.

FHIR R5 Compared with Other Exchange Options

FHIR is not the only way to move a pulse, and a B2B buyer should compare options rather than adopt one by default. HL7 v2 messages such as ORU^R01 remain common inside hospital systems and integrate well with legacy lab and monitoring interfaces, but they are pipe-delimited, position-sensitive, and awkward for modern web APIs. Proprietary JSON endpoints are fast to build and easy for a single vendor's ecosystem, but they lock the buyer into that vendor's schema and force a rewrite for every new source. DICOM and waveform formats dominate imaging and continuous ECG rather than spot heart rates, which makes them a complement rather than a replacement for a pulse Observation. The table below contrasts the main options for a care network evaluating how to ingest patient pulse data in 2026.

The practical conclusion is that FHIR R5 wins on interoperability and access control, not on implementation simplicity. Teams that already run a mature interface engine may keep v2 for the hospital edge and translate to FHIR at the platform boundary, which is exactly the pattern many multi-site networks use.

Common Mistakes in FHIR R5 Pulse Implementations

The first mistake is writing a free-text label such as pulse or bpm instead of the coded pair of LOINC 8867-4 and UCUM /min, which makes the data invisible to terminology-driven analytics. The second is confusing the two timestamps by storing the sync time as the effective time, which smears trends and breaks alerting windows. The third is ignoring dataAbsentReason, so a refused or failed reading is stored as a zero, an omission, or a stale last-known value that a dashboard presents as current. The fourth is collapsing status, so a preliminary device value and a clinician-verified value look identical, and a corrected reading is overwritten instead of marked corrected or entered-in-error. The fifth is over-trusting consumer hardware, as when an irregular-pulse notification is promoted to a diagnosis without confirmation, a pattern the Apple Heart Study's low positive predictive value makes hard to defend.

The remaining mistakes are operational. Teams forget meta.profile and meta.source, so downstream consumers cannot tell which profile the record claims, and they skip Provenance and AuditEvent, leaving no trail when a patient disputes what was reported. They also apply adult thresholds to children, fire alerts on every transient spike, and push unfiltered streams into dashboards, producing alert fatigue that erodes trust in the whole program. A final trap is scaling before measuring: without tracking unit completeness, subject linkage, ingestion latency, and alert action rates, a rollout can look busy while delivering no clinical value. None of these failures require exotic technology to fix; each is a discipline of coding, timestamping, and governance that the specification already supports.

When to Act, What It Costs, and How Platforms Fit

Act now if a network is already running remote monitoring or triage over more than one data source, because every additional vendor without a shared Observation model multiplies integration work. A useful trigger is measurable: when more than 20 percent of incoming pulse records lack a usable unit or subject, when alert volume per coordinator exceeds what the team reviews in a shift, or when clinicians are calling patients to re-ask for numbers already captured by a device. Waiting is reasonable for a small single-site clinic with one EHR and a handful of cuff readings a day, because the return on a full pipeline is modest there. For a multi-site network or a B2B platform such as getpulse.care, the value appears once a single normalized stream feeds dashboards, outreach queues, and reporting across clinics rather than each site maintaining its own parser.

Cost follows the same logic. The FHIR R5 specification, LOINC, UCUM, and SMART on FHIR are free to use; the expense is engineering and operations. As a 2026 planning estimate, a mid-size clinic network should budget on the order of 50,000 to 250,000 dollars for initial integration, mapping, validation, and security review, plus ongoing interface-engine and terminology maintenance. Commercial remote-monitoring platforms commonly price between roughly 20 and 150 dollars per enrolled patient per month, and enterprise contracts can range from about 30,000 to more than 200,000 dollars a year depending on connectors, alerting, and support; these are planning ranges rather than quotes, and vendors such as getpulse.care set final pricing after a discovery call. Buyers should compare proposals on the same terms: number of device connectors, FHIR R4 and R5 support, audit logging, uptime commitments, and who owns the mapping layer. In the United States, add HIPAA operational safeguards, a business associate agreement, and a clear boundary between general wellness tracking and regulated medical-device functionality. With those pieces in place, a FHIR R5 pulse pipeline becomes the quiet infrastructure that makes the visible patient-pulse dashboard trustworthy.