Six Ways Device Vendors Differ, One Clinical Model: A Remote Patient Monitoring Platform on FHIR R4
A HealthTech company running a cloud platform for remote patient monitoring and virtual care had to take readings from multiple device vendors, each with its own protocol and payload, and turn them into one clinical record a clinician could act on. Valletta's senior backend, FHIR and platform engineers, embedded in the product team, owned the device abstraction layer, the HL7 FHIR R4 data flow and the alerting path from device to clinician. For confidentiality we describe the engagement without naming the company or the people involved.
Key Takeaways
- BLE gateway devices and a direct-connect device class converge on one validation, normalization and FHIR mapping path
- Vendor differences in BLE protocols, SDKs, APIs, payload structures, measurement formats and communication models stay inside the integration layer
- Every reading becomes an HL7 FHIR R4 (4.0.1) Observation linked to a Device and a Patient, stored in HAPI FHIR
- Threshold evaluation on the Observation raises a FHIR Flag in the clinician portal when a value is out of range
- Video consultations are tied to Patient, Practitioner, Appointment and Encounter, so a call is part of the clinical record
The client runs a cloud platform for remote patient monitoring and virtual care: connected devices, a patient app, a clinician portal, alerting, consultations and analytics. Valletta supplied senior backend and FHIR engineers together with DevOps and platform engineers, embedded in the product team and owning backend architecture, the HAPI FHIR layer, measurement processing, gateway and direct-connect integration, clinical alerting and the Kubernetes platform. The interfaces, the video provider choice and the clinical product belonged to the client's own teams.
The Challenge: Many Vendors, Many Protocols, One Clinical Truth
Remote patient monitoring generates far more data than episodic care: oxygen saturation, heart rate, blood pressure and temperature readings arrive from every patient every day, and across a growing population that is millions of Observation records. Volume was half the problem. The platform also had to support multiple vendors, and a vendor could differ in six ways: BLE protocol, SDK, API, payload structure, measurement format and communication model. Most devices spoke BLE to a gateway; a direct-connect device class talked to the backend over its own API.
Let those differences leak into clinical rules and portal screens, and every new vendor becomes a regulated change to the clinical layer, with traceability, verification and release obligations attached. The brief:
- Support a BLE gateway path and a direct-connect path without coupling the clinical layer to either transport
- Represent readings, devices and patients in HL7 FHIR R4 for interoperability with external systems
- Detect potentially abnormal measurements automatically and route them to a clinician
The Approach: Push Vendor Complexity to the Edge, Standardize Early
Valletta's engineers drew the line between device-specific and clinical as close to the device as possible: transport (BLE via gateway, or a direct API), device adaptation, validation and clinical normalization were four separate responsibilities, and only the last produced anything the clinical layer would see.
The second decision was to treat FHIR as the canonical clinical model, not an export format. Measurements became Observation resources at ingestion, with Device and Patient references, on HAPI FHIR, so alerting, the portal, analytics and external integrations consume one representation. How that layer is modeled and scaled is its own story: HAPI FHIR server on Kubernetes as a clinical data platform.
The third: frontends would not talk to the FHIR server for business orchestration. A backend of independently deployable services, organized by capability (device integrations, measurement processing, clinical alerts, virtual care, notifications, patient management), handled authentication, orchestration, validation, aggregation and access control. More moving parts, accepted deliberately: application state stays out of the clinical record, and not every internal concept has to become a FHIR resource.
The Solution: From a Vendor Payload to a Clinician's Decision
Two connectivity models, one ingestion contract
Most devices pair with a gateway over BLE; the gateway forwards measurements to the backend over a secure connection and exists to keep BLE communication out of backend services. Some device types talk to the backend directly over an API or device-specific protocol, as a direct-connect device class did here. Both paths land on the same validation and normalization step.
| Connectivity model | Transport | Where vendor logic lives | Trade-off |
|---|---|---|---|
| BLE gateway (most devices) | BLE to gateway, secure link to backend | Gateway and device adapter | One more hop; BLE details never enter the backend |
| Direct-connect (one device class) | API or device protocol straight to backend | Backend-side adapter | No gateway; the adapter absorbs the vendor protocol in the backend |
Normalize first, map to FHIR second
The pattern is the same for every vendor: vendor format, to adapter or gateway, to normalized measurement, to FHIR mapping, to Observation plus Device plus Patient. Normalization precedes FHIR mapping deliberately: the adapter is the only code that understands a vendor's layout of units, timestamps and identifiers. The normalized measurement becomes an Observation referencing its Device and Patient. Adding a vendor means writing an adapter, not touching a clinical rule.
From Observation to Flag: the alerting path
Storing readings is not monitoring. Each new Observation is evaluated against configured clinical thresholds or rules. Within range, the reading joins the normal workflow. Out of range, it raises an alert state as a FHIR Flag and surfaces it in the clinician portal. FHIR Subscription patterns let downstream services react to new or updated resources, so evaluation is event-driven rather than polled. Four concerns stay apart: raw ingestion, clinical persistence, alert evaluation and presentation, so a threshold change touches only evaluation.
A clinician portal and a patient app that never bypass the backend
Clinicians worked in a browser-based portal: patient search and profiles, measurements and trends, patients requiring attention, alerts, device information, appointments and encounters, clinical review and remote consultations. The portal never queried the FHIR database directly; the backend provided authorization, orchestration, aggregation and access control. The patient app covered authentication, care workflows, device interaction and measurement upload, notifications, deep links, consultations and assigned actions. Valletta's engineers developed the backend services both apps consume; the interfaces were the client's frontend and mobile teams' work.
Virtual consultations inside the clinical record
An external video provider was integrated, but the call was never an isolated feature. The backend orchestrated each session and tied it to patient, clinician, appointment and clinical context through Patient, Practitioner, Appointment and Encounter resources. A follow-up consultation triggered by an alert is linked to the reading that caused it.
The Results: What the Architecture Made True
The outcomes of an architecture engagement are properties of the system, and these are the ones that matter to a monitoring product:
- A new device vendor is an adapter in the integration layer, not a change to clinical rules, the portal or the FHIR model
- Every measurement is an HL7 FHIR R4 Observation with Device and Patient references, so external systems consume standard resources
- Potentially abnormal measurements reach a clinician automatically as a Flag, with review, decision and follow-up behind it
- Analytics runs on a separate layer and does not compete with production clinical APIs
The clinician should never be able to tell which vendor made the cuff. If they can, the abstraction has leaked.
Trade-offs and the Next Direction
FHIR at ingestion means every new measurement type must be modeled as an Observation before it is useful; the payoff is one representation for every consumer. A backend in front of FHIR is more to operate than direct access, but it is where access control and orchestration belong, and application state stayed there, not in the clinical record. Care pathways were the next direction: describing a patient journey with PlanDefinition, CarePlan, ServiceRequest, Task, Questionnaire and QuestionnaireResponse instead of hard-coding workflows into screens. The backend ran on Kubernetes with Helm, GitOps and GitHub Actions across development, staging, UAT and production, under processes related to ISO/IEC 27001 and ISO 13485; platform engineering under those demands is covered in healthcare DevOps under ISO 13485 and ISO 27001.
Frequently Asked Questions
How does remote patient monitoring work?
A patient takes readings at home with a pulse oximeter, blood pressure cuff or thermometer. Each measurement travels over Bluetooth Low Energy to a gateway, or directly over an API, to a backend that validates and normalizes it and stores it as an HL7 FHIR R4 Observation. Clinical rules compare the value with thresholds; out-of-range readings become alerts a clinician reviews in a portal.
Which technology is used in remote patient monitoring?
On the device side: Bluetooth Low Energy medical devices, wearables, gateways and direct-connect devices. On the data side: HL7 FHIR R4 as the clinical model, with Observation, Device, Patient and Flag resources, served here by HAPI FHIR. Around that: backend services by capability, a clinician portal, a patient mobile app, an external video provider, and Kubernetes with CI/CD and GitOps.
What is medical device integration?
Medical device integration is the engineering that turns vendor-specific device output into a standardized clinical record. Vendors differ in BLE protocols, SDKs, APIs, payload structures, measurement formats and communication models, so a layer of device adapters and gateways normalizes each vendor's data before it is mapped to FHIR resources. Done well, the clinical workflow never knows which vendor produced a reading.
How much does it cost to build a custom RPM platform?
Four drivers move the estimate more than any feature list: how many device vendors and connectivity models you support, whether you adopt FHIR from the start or migrate later, how sophisticated alerting and care pathways must be, and which regulatory processes (ISO/IEC 27001, ISO 13485, local rules) your release process has to satisfy. Valletta scopes those answers before quoting.
Should we build or buy a remote patient monitoring platform?
Buy if a vendor's device list, workflows and data model already match your clinical program and you accept its roadmap. Build the backend and integration layer, buying commodity parts such as video, if you need multiple device vendors, your own clinical rules, FHIR interoperability with hospital systems, or a regulated release process you control. The platform here took that mixed route.
Building or Scaling a Remote Patient Monitoring Platform?
The hard part of RPM is rarely the dashboard. It is the device layer, the clinical data model and a delivery process that lets you change either under regulation. Valletta's DevOps and platform engineering team has done that work inside an RPM product team.
Valletta works the forward-deployed way: the engineer who hears your problem designs the integration, ships it into your cluster and pipeline, and leaves when your team can run it without us. Read what a forward deployed engineer is, or hire DevOps engineers.
Tell us which devices, standards and regulators you are dealing with: vallettasoftware.com/contact-us