# How Should Clinics Validate FHIR Observations Before Sending Patient-Pulse Data?

getpulse.care · September 26, 2026

> What FHIR Observation Validation Actually Means FHIR Observation validation is the process of checking that a clinical measurement is encoded as a...

## What FHIR Observation Validation Actually Means

FHIR Observation validation is the process of checking that a clinical measurement is encoded as a valid, internally consistent, and appropriately interpreted FHIR Observation. “Valid” does not mean only that the JSON is syntactically correct. A payload can be well-formed JSON and still fail because it uses an unknown code, omits a required unit, places the reference in the wrong element, or combines several unrelated tests under one identifier. For patient-pulse SaaS, the practical objective is to make every submitted observation traceable to its source, clinically interpretable, and safe for downstream systems to process.

**Also worth reading:** [What is AI model validation in healthcare and how should clinics validate AI tools before deployment?](https://getpulse.care/knowledge/what_is_ai_model_validation_in_healthcare_and_how_should_clinics_validate_ai_tools_before_deployment.php) · [How Do RPM Software Implementation Guides Help Clinics Deploy Remote Patient Monitoring Safely?](https://getpulse.care/knowledge/how_do_rpm_software_implementation_guides_help_clinics_deploy_remote_patient_monitoring_safely.php) · [How Do B2B Care Coordination SaaS Platforms Help Clinics Manage Patient Pulses in 2026?](https://getpulse.care/knowledge/how_do_b2b_care_coordination_saas_platforms_help_clinics_manage_patient_pulses_in_2026.php)

An Observation typically carries a status, category, code, patient, encounter, effective time, value, and sometimes reference ranges, interpretation, method, device, and performer. A pulse reading might use a vital-sign code, report a value such as 72 beats per minute with UCUM unit /min, and record the measurement time separately from when the data was transmitted. Validation therefore covers structure, terminology, units, references, business rules, and the semantic relationship among fields. The FHIR R4 Observation resource is the relevant baseline unless a deployment explicitly adopts another published FHIR release.

A useful distinction is between base FHIR conformance and profile-level conformance. Base validation tests the resource against the selected HL7 definition, while profile validation additionally checks constraints introduced by a profile, implementation guide, or national program. A clinic may also need project-specific rules, such as rejecting readings outside a device’s declared range or requiring patient-pulse consent before accepting remote measurements. These organizational rules are not automatically part of FHIR itself, so vendors should document which standard, profiles, and local policies their validation service applies.

## The Validation Layers Clinics Should Apply

Validation should be divided into layers so that a failure tells the operator what is wrong rather than merely returning “invalid.” The first layer is syntax: parsers check JSON or XML according to the chosen FHIR encoding. The second is resource validation: the server checks cardinality, data types, allowed values, required bindings, references, and invariants defined by FHIR. The third is terminology validation, confirming that codes come from the declared value set or code system and that displays are not being used as if they were machine-readable codes.

The fourth layer concerns clinical semantics. It asks whether a heart-rate value has the expected unit, whether a temperature has the right scale, whether an observation code matches the supplied value type, and whether the effective date-time is plausible. The fifth is workflow validation: the patient, encounter, ordering clinician, device, and consent record may need to be checked against the receiving system’s rules. A final layer is acceptance testing against representative test cases, because a validator can pass every field-level check while still producing a message that a real EHR, device gateway, or analytics platform cannot use.

These layers should be applied at different times. Synchronous validation at API ingress rejects unsafe or unusable submissions immediately, while asynchronous validation can support quarantine, reconciliation, and later reprocessing. For care networks, retaining both the original payload and validation results is important because upstream corrections do not automatically repair historical records. A high-assurance workflow may reject obvious errors at the edge, quarantine uncertain submissions, and make a controlled revalidation attempt rather than silently changing clinical data.

## Recommended Validation Workflow for Patient-Pulse Feeds

Begin by declaring a precise conformance contract. Specify the FHIR release, resource types, profiles, value sets, cardinalities, identifiers, required references, privacy controls, and API error format. If a clinic sends heart rate, respiratory rate, oxygen saturation, temperature, and blood pressure, define whether each measurement is a separate Observation or whether selected clinical workflows use a blood-pressure component profile. This prevents a “successful” feed from being ambiguous once it reaches a clinician or dashboard.

Next, validate a small, representative test set before bulk ingestion. Include normal readings, boundary readings, missing optional fields, wrong units, duplicated submissions, unknown codes, late-arriving events, and references to unavailable patients. During testing, compare source counts with accepted, rejected, and quarantined counts. As a practical target, aim for 100% acceptance of valid conformance test cases and explicit handling of every invalid case; “at least 99% successful” is not an adequate safety target when failed records may disappear from a care view.

At runtime, preserve a unique submission identifier and make the API idempotent. The receiving system should detect a repeated Observation, distinguish a correction from a duplicate, and return a machine-readable outcome for every message. In a B2B environment, operational reporting should track at least four measures: the number received, the number accepted, the number rejected by reason, and the number awaiting reconciliation. Alerts can be based on sustained rejection rates, but a single malformed message should not automatically create a noisy incident.

Finally, test the full route, not just the validator. A resource may pass local checks but fail at a partner because the partner requires a different profile, identifier system, terminology server, or authorization policy. Run contract tests with each major receiving endpoint and retain dated test evidence. This is particularly important when connected devices, EHRs, and care-coordination platforms have different assumptions about observation timing, provenance, and device identity.

## Observation Requirements, Cardinality, Codes, and Units

The most effective rule is to preserve the distinction between what was measured, how it was measured, and what it means. Observation.code identifies the measurement, Observation.value[x] or a data-absent-reason communicates the result, and Observation.effective[x] records when it applied. Units should use the formal UCUM representation where the measure is expressed as a quantity. A numeric value without a compatible unit may be syntactically valid but clinically unsafe, especially for temperature or blood pressure.

Cardinality must be checked according to the selected FHIR version and profile rather than copied from a generic form. Some core elements are required, some are conditionally required, and others are optional. A production service should not treat every missing optional element as an error, but it should enforce conditional relationships such as the need for a reason when no result is present. The FHIR specification also distinguishes absent data from a zero result, so replacing unavailable data with 0 can create a false clinical finding.

Terminology is another frequent source of failure. A code may be locally valid yet not belong to the binding required by the chosen profile. Display text is for human readability and should not substitute for a stable code. If a local vocabulary is necessary, document its system, version, and mapping to the canonical terminology. Governance should also address retired or deprecated concepts, because a dashboard may continue showing a label even after the underlying code is no longer accepted by a newer profile.

Provenance and reference checks deserve special attention in multi-entity deployments. The patient reference should resolve under the receiving system’s identifier rules, while device, performer, specimen, and encounter references should either resolve or be handled according to the agreed policy. Connected-device feeds also need a clear distinction between the device’s identifier, the clinician responsible for review, and the time the measurement was generated versus the time it was received.

| Feature | Baseline FHIR check | Profile and workflow validation | Operational acceptance test |
| --- | --- | --- | --- |
| Syntax and data types | Confirms parseable JSON or XML and valid primitive types | Checks profile-specific types and extensions | Confirms the partner can decode the exact payload |
| Codes and units | Verifies declared bindings and formal quantities | Enforces project-specific value sets and UCUM units | Confirms codes render correctly in the receiving workflow |
| Patient and device links | Checks basic reference structure | Applies identifier, consent, and source rules | Tests real, missing, retired, and mismatched references |
| Error handling | Returns field or invariant failures | Classifies rejection, correction, and quarantine | Verifies retries do not create duplicate Observations |
| Auditability | Establishes resource identity and status | Adds local provenance, policy, and validation metadata | Reviews dated evidence across the full route |

## Common Mistakes That Make Validation Misleading
One common mistake is using a display label in place of a coded value. Another is validating only the Observation and ignoring the referenced Patient, Device, Practitioner, or Encounter. Some teams also assume that a successful HTTP response means clinical acceptance; a 200 status can still accompany a payload that has been quarantined or only partially processed. The validation contract should define the difference between transport success, resource validity, clinical acceptance, and display availability.

A second common error is silently normalizing data. Automatic conversion of 98.6 degrees Fahrenheit to Celsius may be reasonable when the source, unit, and transformation are fully documented, but it must not happen invisibly. Preserve the original value, record the standardized value, and document whether the original or transformed result is displayed. Automatic unit inference from a number alone is especially dangerous because several clinical quantities use numerically similar values with different meanings.

Teams also over-validate optional data or under-validate provenance. Rejecting every missing nonessential field can reduce adoption and encourage senders to fill fields with invented placeholders. Conversely, accepting a measurement without source, time, or status may make later reconciliation impossible. Validation should be proportional to risk: required safety fields and provenance need strict controls, while optional narrative enhancements can often be accepted as absent.

Finally, treat validator upgrades as interface changes. A terminology update, profile revision, or FHIR release transition can alter accepted codes, cardinalities, or extension requirements. Pin versions, test the migration set, and communicate breaking changes to clinic and device partners before deployment. Do not claim universal compatibility when validation depends on a particular profile, terminology server, or partner implementation.

## Direct FHIR Validation Compared with Alternative Approaches

Organizations can choose among several validation approaches, but they solve different parts of the problem. Direct HL7 FHIR validation is the most appropriate when the interface contract is genuinely FHIR-based. Lightweight custom checks may be useful for an internal prototype, yet they are unlikely to cover the specification’s breadth and should not be represented as full conformance testing. Commercial validators can provide maintained rules and tooling, while open-source validators can support transparent infrastructure and version control.

A useful decision is based on required coverage, operational control, and total cost rather than on the word “FHIR” alone. A small clinic with a narrow, stable feed may begin with a standards-aware library and a small local rule set. A care network supporting several EHRs, device vendors, and regional profiles usually benefits from a validation gateway, terminology management, contract tests, and audit reporting. The governance burden can be as important as the software cost because every profile and local rule needs an owner and a review date.

| Approach | Strengths | Limitations | Suitable use |
| --- | --- | --- | --- |
| Custom code checks | Fast to build for a narrow feed; full local control | High maintenance; weak coverage of FHIR constraints | Prototypes and very small, stable interfaces |
| Open-source FHIR validator | Standards-oriented, transparent, and automatable | Requires deployment, version management, and interpretation | Teams with technical infrastructure and interoperability expertise |
| Commercial validation service | Maintained tooling, support, and profile packs | Licensing and integration costs; vendor dependency | Multi-partner networks and regulated operational workflows |
| EHR or integration-engine rules | Convenient when the receiving platform already governs the feed | May be limited to one vendor’s supported profiles | Interfaces already centered on a particular EHR ecosystem |
| Manual review plus automated tests | Useful for edge cases and profile governance | Slower and difficult to scale across high-volume feeds | Release qualification and exception review |

The best approach is often layered. Automated structural and terminology checks can run at ingestion, commercial or open-source tooling can verify profile conformance in staging, and human review can settle semantic questions that cannot be safely automated. No approach should replace a documented source-to-destination data contract.

## When to Act and What Validation May Cost

Act before connecting live clinical measurements to a care-coordination workflow, especially when the data influences alerts, follow-up tasks, or patient monitoring. The same diligence is warranted when adding a new EHR, device vendor, observation code, or partner endpoint. A one-time test is not enough because terminology and profile behavior can change, and because the operational meaning of a reading may change even when the resource remains structurally valid.

FHIR specifications and many implementation resources are publicly available, so the standards themselves generally do not create a per-message license fee. Implementation costs come from engineering time, validator hosting, terminology services, security controls, test data, profile development, monitoring, and partner support. A precise price cannot be stated responsibly without knowing the number of profiles, transactions, environments, endpoints, and compliance requirements. Vendors should separate standards-based tooling fees from implementation, support, and custom terminology work.

For budgeting, organizations can estimate the recurring work in four categories. First is build cost: integration, schema tests, reference handling, and documentation. Second is validation operations: version updates, terminology maintenance, exception analysis, and audit retention. Third is partner cost: compatibility testing, onboarding, and change management. Fourth is risk cost: incorrect alerts, missed measurements, duplicate records, and manual recovery. For patient-pulse SaaS, the fourth category may dominate the business case because a technically small defect can affect many clinics and patients.

A practical release gate is to require zero unexplained failures in the approved conformance suite, complete traceability for rejected records, and documented behavior for retries and corrections. Go-live criteria should also include a rollback plan, named owners, and a review date. This is more defensible than promising a universal uptime or accuracy percentage that has not been measured in the target environment.

## The Definitive Validation Standard for Care-Coordination Platforms

For getpulse.care, FHIR Observation validation should be treated as a controlled data-quality boundary, not as a single syntax check. The platform should state exactly which FHIR release and profiles it supports, validate code systems and UCUM units, enforce patient and device reference policy, preserve provenance, and return actionable error information. It should also distinguish rejected messages from messages that are merely delayed, duplicated, or awaiting reconciliation.

The strongest implementation combines automated checks at the API edge with profile validation, terminology governance, contract tests, and human review of unresolved cases. It should never silently repair a clinical value, replace absent data with zero, or accept a display string as a substitute for a code. Every transformation should be recorded, every submission should have an idempotent identity, and every partner should have a tested compatibility profile.

That approach does not make interoperability automatic. FHIR supplies a common structure, but local profiles, code systems, identifiers, consent rules, and clinical workflows still require agreement. Clinics and care networks get the most value from FHIR when the validation contract is explicit, versioned, measurable, and shared across EHRs, device vendors, and downstream analytics. The result is not merely “valid FHIR”; it is a trustworthy patient-pulse data path that can support coordination without hiding uncertainty.

## Quick answers

### What is the minimum required data for a FHIR heart-rate Observation?

The exact requirements depend on the FHIR version and profile, but a clinically useful heart-rate Observation generally includes a status, an observation code, a patient reference, an effective time, a numeric value, and the unit /min when the value is a quantity. Device or performer references may be required by a local profile even when they are not required in every baseline workflow.

### Is a FHIR resource valid if the JSON parses successfully?

No. Parseable JSON only confirms syntax. A resource can still fail because of a missing required field, an invalid code, an incompatible unit, a broken reference, or a profile constraint, so resource, terminology, workflow, and operational checks are also needed.

### How should clinics handle duplicate FHIR Observations?

Senders should use a stable business or idempotency identifier so retries do not create duplicate clinical records. Receivers should compare identifiers, source context, and measurement time, then distinguish an exact retry from a legitimate correction or a new measurement.

### Do all FHIR Observations need the same fields?

No. Required and conditionally required elements vary by FHIR release, resource shape, profile, and clinical workflow. A validation service should implement the declared conformance contract rather than applying one generic field set to every Observation.

### Can a FHIR validator convert Fahrenheit to Celsius automatically?

It can convert a value only when the source unit and transformation are known and the conversion is governed by an explicit rule. The system should preserve the original observation and record the transformation so that neither the source nor the receiving team loses provenance.

Canonical: https://getpulse.care/knowledge/how_should_clinics_validate_fhir_observations_before_sending_patient-pulse_data.php
Markdown: https://getpulse.care/knowledge/how_should_clinics_validate_fhir_observations_before_sending_patient-pulse_data.php/index.md