Should wearable data go into the EHR as raw readings or summaries?

Summaries and confirmed alerts, in most programs. The raw stream stays in a time-series store the clinician can open from the chart, so the flowsheet holds only what the care team agreed to review.

Does HIPAA cover data from a patient's own fitness tracker?

It depends on who holds the data. Once a covered provider receives and stores the readings, that copy is protected health information. A consumer app the patient uses on their own falls under the FTC rule, not HIPAA.

Which LOINC codes do common wearable readings use?

The FHIR vital signs profile uses 85354-9 for the blood pressure panel, 8867-4 for heart rate, 59408-5 for pulse oximetry and 29463-7 for body weight. Map every reading to its code before writing parsers.

How do you keep the same reading from being counted twice?

Hash the patient, measurement type, effective time and source device, and drop any reading whose hash already exists. This matters most when a cuff syncs both directly and through a phone health store.

What changed in RPM billing for 2026?

The CY 2026 Physician Fee Schedule added 99445 for 2 to 15 days of device data and 99470 for the first 10 minutes of treatment management. Programs no longer lose the month entirely when a patient transmits on fewer than 16 days.

Wearable Technology in Healthcare: Data to EHR

Wearable technology in healthcare covers body-worn sensors, from cleared glucose monitors and ECG patches to consumer watches and rings, whose readings are meant to inform care outside the clinic. The hardware is the easy part. The hard part is moving those readings into a clinical system in a form a clinician will trust and act on.

This guide is about that data path. It covers how readings travel from device to EHR, how to model them in HL7 FHIR, how to turn streams into summaries, what the billing and privacy rules expect, and where integrations fail.

What is wearable technology in healthcare?

Need wearable readings inside the EHR?

Agnotic builds the integration from device clouds and health stores to the EHR, with FHIR modeling, summary rules and the write path the hospital approves.

EHR Integration Services

Wearable technology in healthcare is the use of body-worn sensors, such as glucose monitors, ECG patches, blood pressure cuffs and smartwatches, to capture physiologic data outside the clinic. Its clinical value depends on integration: readings must be normalized, tagged with their source device, summarized and written into the EHR through an interface the health system approves.

Clinical devices and consumer wearables

Cleared clinical devices: Continuous glucose monitors, multi-day ECG patches, pulse oximeters and blood pressure monitors that carry a Unique Device Identifier and validated accuracy for the measured parameter.
Cellular monitoring kits: Cuffs, scales and glucometers that send readings through a built-in cellular modem, with no phone pairing for the patient to manage.
Consumer watches and rings: Optical heart rate, heart-rate variability, activity and sleep data, plus specific software features that may carry their own FDA authorization.

The difference matters downstream. A clinician reading a blood pressure in the chart needs to know whether it came from a program-issued cuff or a patient's own watch, and the integration must carry that fact with every value.

Which rules decide where wearable data can go?

Five rules govern wearable data once it leaves the device: billing, EHR access, privacy, device status and cybersecurity. Each one changes a design decision in the pipeline.

CMS billing: The CY 2026 Physician Fee Schedule final rule (CMS-1832-F) kept 99453 for setup and 99454 for 16 to 30 days of device data, added 99445 for 2 to 15 days, and added 99470 for the first 10 minutes of treatment management beside 99457 and 99458.
Device requirement for RPM: CMS expects remote physiologic monitoring data to come from a device that meets the FDA definition of a medical device and to be collected and transmitted electronically, not typed in by the patient.
EHR access: ONC (ASTP) criterion 45 CFR 170.315(g)(10) certifies a read API for patient and population services. Filing readings into the chart goes through a separate path, such as a vendor write API or an HL7 v2 results interface.
Privacy: When wearable data is collected for a covered provider or plan, the HIPAA Security Rule applies. A direct-to-consumer wearable app outside HIPAA falls under the FTC Health Breach Notification Rule, 16 CFR Part 318, instead.
Cybersecurity: For a connected wearable that is a cyber device, FD&C Act section 524B makes the maker submit a software bill of materials and a postmarket vulnerability plan, which affects how device clouds and gateways are patched.

How does wearable data reach the EHR?

Wearable data pipeline: device tiers, ingestion through OS health stores or device clouds, normalization and triage, then EHR filing and RPM billing

Wearable data reaches the EHR in four stages: ingestion, normalization, triage and filing. Each stage has its own owner and its own failure.

1. Ingestion: Readings arrive by one of four paths: direct Bluetooth Low Energy through a phone app, Apple HealthKit, Android Health Connect, or a server-to-server feed from the device maker's cloud. Each path has its own consent, token expiry and retry behavior.
2. Normalization: The pipeline maps every value to a LOINC code and a UCUM unit, converts device time to UTC, attaches the device model, firmware and serial, and drops duplicates when the same reading arrives by two paths.
3. Triage: Clinician-approved rules compare readings against the patient's baseline and ordered thresholds. Out-of-range values open a task. Everything else stays in the time-series store.
4. Filing: Summaries and confirmed alerts go to the EHR through the interface the site supports, such as a vendor FHIR write API or HL7 v2 ORU messages, while the full stream stays one click away in a SMART on FHIR viewer.

Choosing an ingestion path

Direct Bluetooth: Best control over timing and device metadata, but the phone app must reconnect after the operating system suspends it, and each device model needs its own parser.
Apple HealthKit: Broad coverage of iPhone and Apple Watch data with one integration. Read denials are invisible to the app, and samples from many apps are mixed together, so source filtering is required.
Android Health Connect: The equivalent store on Android, with per-type permissions and change tokens for incremental reads. Coverage depends on which device apps write to it.
Device maker cloud: A server-to-server feed with OAuth tokens per patient and webhooks for new data. No phone code, but the program depends on the vendor's API terms, rate limits and outages.

Many programs combine two paths, such as a cellular cuff through the maker's cloud plus HealthKit for activity. That choice makes deduplication and source labeling mandatory from day one.

How should wearable readings be modeled in FHIR?

Wearable readings should be FHIR R4 Observation resources that follow the vital signs profile where one applies, with the source device and the patient's role in the measurement recorded explicitly.

Codes: Use the LOINC codes the FHIR vital signs profile names, such as 85354-9 for the blood pressure panel with 8480-6 systolic and 8462-4 diastolic components, 8867-4 for heart rate and 59408-5 for pulse oximetry.
Category: Set the vital-signs category so EHR flowsheets and US Core clients find the reading where they expect it.
Device: Reference a Device resource with manufacturer, model, serial number and, for cleared devices, the UDI. This is how a chart separates a program cuff from a consumer watch.
Time: Use effectiveDateTime for a single reading and effectivePeriod for a summary such as a seven-day average, so a summary is never mistaken for a point reading.
Origin: Record the patient as performer for self-measured readings and keep a Provenance resource for the transformation from raw stream to summary.

Turning streams into summaries clinicians read

A clinician does not need every sample. The integration's job is to decide what reaches the chart, and that decision belongs to the clinical team, written down before go-live.

Summary windows: Daily or weekly values, such as morning and evening blood pressure averages or glucose time in range, filed on a schedule the care team chooses.
Alert rules: Sustained out-of-range readings or a baseline shift over several days, not a single spike from a loose cuff or a running wrist.
Context fields: Fasting or post-meal for glucose, rest or exercise for heart rate, and body position where the device reports it.
Gap reporting: A missing day is a clinical signal. The summary should say "no readings for three days" instead of leaving a quiet blank.
Billing counters: Distinct days with device data and clinical review minutes, tracked per 30-day period so the program knows whether 99445 or 99454 and 99470 or 99457 apply.

Where wearable integrations fail

These failure points come from the data path itself. Each one should have a test case before the first patient is enrolled.

Raw streams in the chart: Filing every minute of watch data into a flowsheet buries the readings that matter and gets the interface switched off.
Assuming the read API can write: Planning to file data through the certified (g)(10) API, then discovering the site only accepts HL7 v2 or a vendor-specific write path.
Silent token expiry: A device cloud token or HealthKit permission lapses and the dashboard shows a stable patient with no new data.
Duplicate readings: The same cuff reading arrives through Bluetooth and through HealthKit, and the average shifts.
Time zone drift: A device clock set to a different zone files evening readings as morning ones.
Wellness data billed as RPM: Readings from a consumer device that does not meet the medical device definition are counted toward RPM days.

What to settle with the health system before go-live

Much of the integration schedule is set by decisions the health system owns. Get each answer in writing.

Write path: Vendor FHIR write API, HL7 v2 ORU interface or a monitoring platform the EHR already accepts, and who builds and tests it.
Filing location: Flowsheet rows, results or a patient-generated data section, and how consumer readings are labeled.
Alert ownership: Which team receives tasks, in which in-basket or queue, and the escalation path after hours.
Patient matching: The identifier the integration uses and what happens when a match fails.
Agreements: A business associate agreement with every vendor that stores or moves the readings, including device clouds.
Review plan: Who signs off on summary windows and thresholds, and how changes are recorded.

How Agnotic can help

In a wearable program, the interface is where clinical value is won or lost. Agnotic Technologies builds the data path for care programs and digital health teams: ingestion from health stores and device clouds, LOINC and UCUM normalization, clinician-owned summary rules, FHIR and HL7 v2 filing, and a SMART on FHIR viewer for the full stream.

Agnotic starts from the health system's interface rules and the care team's review workflow, then designs the summary windows, alert rules and device labels to fit them. The result is a feed clinicians can read in the chart they already use, with the full stream available when they need to look closer.

Connect wearable data to your EHR with Agnotic

Explore EHR integration services, or browse more articles in the Wearables and Devices hub.

EHR Integration Services Wearables and Devices Articles

Sources

Frequently Asked Questions

Only if the device meets the FDA definition of a medical device for the measured parameter and transmits the data automatically. A general wellness tracker does not meet that requirement, so its readings should be stored and labeled separately.

Wearable Technology Healthcare