Skip to main content

The Platform

Clinical Data Pipeline

FHIR R4-native ingest from the facility's clinical systems. Standards-based authentication, automated LOINC and CPT mapping, SHA-256 evidence hashing, continuous sync into compliance evaluation.

Clinical Data Pipeline

Compliance evaluation is only as good as the data it evaluates. Most compliance tools require manual entry, CSV uploads, or brittle integrations that break when the source system updates. Regain Accreditation takes a different approach: the substrate speaks FHIR R4 natively, authenticates against clinical systems using the standards-based mechanism major health IT systems already expose, and maps clinical observations directly into compliance-evaluable evidence.

No manual abstraction. No batch uploads. No "please export your data and send it to us."

FHIR R4 ingest

The pipeline implements the SMART on FHIR Backend Services specification, the same authentication pattern used for system-to-system communication across the published FHIR ecosystem.

Authentication. private_key_jwt with RS384 JWT signing, client_credentials grant flow. Token endpoint discovery via .well-known/smart-configuration. Tested end-to-end against a public vendor sandbox; not yet running against a live production source system.

Retrieval. Async FHIR client with search_diagnostic_reports, search_observations, search_document_references, and read_resource. Auto-pagination follows FHIR Bundle next links to exhaustion. 401 responses trigger automatic token invalidation and retry, handling the token-expiration edge cases that quietly break naive FHIR integrations.

Cadence. Scheduled sync, no manual trigger required. Changes in the source clinical system flow into compliance evaluation on the next cycle.

Clinical mapping

Raw FHIR resources are not directly evaluable against accreditation Standards. A LOINC-coded observation needs to be mapped to the specific compliance condition it satisfies, and a CPT-coded procedure needs to be tied to the volume requirement it counts toward. That mapping is what the FHIR-to-compliance mapper does.

The mapper handles:

  • LOINC codes across the categories the program area's Standards address, for example, in echocardiography: left ventricular ejection fraction, strain, valve assessment, diastolic function, dimensions, and general findings
  • CPT codes for the modalities and study types the program covers, complete and limited studies, stress and transesophageal variants, congenital studies
  • Report completeness extraction: determining whether a final report contains the fields the Standards require for the study type
  • SHA-256 evidence hashing per record, creating a tamper-evident link between the source observation and the compliance finding it supports

When a rule fires, the evidence chain runs from the finding back through the mapper to the specific FHIR resource, with a cryptographic hash that proves the resource has not been modified since ingestion.

Evidence integrity

The engine derives evidence observations from the records it ingests and hashes those observations before evaluation. The hash travels with the derived observation through mapping, evaluation, and finding generation. At any point on the audit trail, the hash can be verified to confirm the evaluated dataset has not been modified between ingestion and finding.

This matters because the accreditation cycle increasingly scrutinizes not just whether evidence exists, but whether it is trustworthy. "How do you know the dataset the finding rests on has not been modified?" gets a concrete answer: SHA-256 hash, computed before evaluation, recomputable on demand.

The same hashing pattern extends to rule packs themselves. The compliance engine verifies pack integrity before each evaluation cycle. Data integrity and rule integrity are enforced by the same mechanism.

What flows through

In a typical deployment, the pipeline processes:

  1. Final reports: diagnostic reports, procedure documentation, study interpretations
  2. Clinical observations: measurement results with LOINC coding, values, units, reference ranges
  3. Document references: policies, protocols, training records, attestations
  4. Personnel records: credential status, competency assessments, continuing-education logs

Each data type maps to specific condition kinds in the rule pack for the program area. A lapsed credential triggers a credential-currency finding. A report missing a required field triggers a report-field finding. A quality metric below the standard triggers a quality-indicator finding. The pipeline routes each record to the conditions it can satisfy or violate.

Read-only by design

The pipeline integrates with existing clinical infrastructure; it does not replace it. The facility keeps its current EMR, its current modality systems, its current workflow. The pipeline reads from those systems via standard FHIR endpoints. It does not write back. It does not modify clinical data. It does not require changes to clinical workflows.

This is a deliberate constraint. Clinical systems are safety-critical. A substrate that requires modifications to clinical workflows introduces risk that exceeds its value. Reading is sufficient; writing is out of scope.

Read the Reviewer Surface page →