Rural health programs rarely fail on ambition. They fail when thirty organizations send the same lab result thirty different ways, and nobody can compute a measure anyone believes. We build the layer that resolves them to one patient record and one set of codes — so a care team sees a timeline instead of a pile of documents, and the program reports outcomes from coded data rather than free text.
The integration problem is not that the data is missing. It is that the same fact arrives under a different name from every direction.
Clinics emit HL7 v2 and FHIR. Pharmacies run NCPDP. EMS runs NEMSIS. Home and wearable monitoring adds a stream belonging to none of them. These are not competing versions of one standard — they are four unrelated record traditions that happen to describe the same patient.
One analyzer sends a local mnemonic, another a vendor default, a third a LOINC code bound to the wrong specimen. Counted naively they look like different tests. A measure computed over that is not wrong by a little.
Until the sources resolve to one patient timeline, coordination stays manual and the outcome measures the program owes get assembled by people reading documents. That is slow, expensive, and impossible to audit at the end of a period.
We build the semantic layer underneath a program — canonical concepts, alias governance, terminology services, FHIR exchange, and a human review queue for every code that does not map cleanly. The community, workforce and governance work belongs to the people who already do it well.
We work as the technical layer behind a program, not as its front door. Where a program already has an integrator, the honest shape of our involvement is usually to assist through development and rollout rather than to replace anyone.
Everything in this section exists and can be demonstrated end to end in a live session. What is designed but not yet proven is in the next section, kept separate on purpose.
The full LOINC release — 98,101 codes — is loaded and checksummed at load. A code is accepted only if it exists and is ACTIVE in the loaded release. It is never validated by check-digit arithmetic, because 14,304 codes in the 2.83 release fail that check: a system that trusts the check digit rejects real, valid LOINCs and has no idea it is doing it.
An automated scanner bins every candidate binding into four confidence tiers. Only an exact match to a code that is present and ACTIVE in the loaded release may commit automatically. Vendor defaults, fuzzy display-name matches and unknowns are raised as proposals and wait for a person. Today 87 proposals are pending and 20 bindings have been approved by a human, each a named, timestamped action.
A result whose code cannot be resolved is quarantined and routed to a steward queue — never discarded, never guessed at. When a steward later binds that key, the decision applies retroactively to every result already quarantined under it. Of 69,930 synthetic lab results processed, 66,108 (94.5%) are currently resolved; the remainder are visible and waiting, not lost.
When a binding has not been verified against the release, the published FHIR export omits the code entirely and carries a has-unverified-loinc-binding flag in its place. A downstream server cannot mistake a provisional guess for a confirmed code, because the guess is not there to mistake.
The dictionary publishes as FHIR R4 (4.0.1) CodeSystem, ValueSet and ConceptMap resources — 154 concepts, 19 ValueSets, one global ConceptMap, delivered as a single Bundle that loads in one transaction. It was validated by loading into stock open-source HAPI FHIR 8.12.0, built from source, with zero profile-validation errors and all four terminology operations passing: $lookup, $expand, $validate-code, $translate.
Inbound messages are acknowledged and written to an immutable raw envelope before any processing, with an idempotency key so retries never duplicate — which means any downstream store can be rebuilt by replaying the originals. 371,000+ synthetic HL7 messages processed to date across roughly fifteen lab-panel and reporting categories, at a measured single-process ceiling of 50 messages per second.
Standing up a FHIR server is a weekend. Deciding what a code means, and being able to show who decided it and when, is the work that actually takes a year — and it is the part that determines whether a program's impact report survives review.
Every dictionary release is immutable, versioned and checksummed, with a stored snapshot of its members, so a coverage figure quoted six months ago can be recomputed from the release it was quoted against rather than defended from memory. A weekly scan flags codes the standard has since discouraged, and reopens the flag automatically if the code is still in use.
Kept deliberately separate from the section above. These are designed and in some cases coded, but they have not been proven end to end — and we will not describe them as though they have.
Mapping the pharmacy and EMS sides onto the same FHIR resources as the clinical data, plus a device intake path so home-monitoring readings land as coded observations against the same patient — rather than in a separate vendor dashboard nobody reconciles.
Nightly coverage snapshots per organization and per domain exist today. Turning them into program-level impact reporting requires each participating organization to be identified in the inbound stream — a real onboarding step, not a switch we flip.
Connecting many organizations means an onboarding path each one can follow: connectivity, a test corpus, a mapping pass, and a feedback report telling that organization which of its codes we could not understand. Designed, and honestly, not yet run end to end with a real site.
We are not certified under SOC 2, HITRUST or FedRAMP, and there is no such thing as being “HIPAA certified.” We have not run US Core conformance testing. We do not have a live production cloud deployment, and we do not publish service-level commitments we have never measured against. If any of those are prerequisites for your program, we are not the right fit today, and we would rather you learn that from this page than from a procurement process.
The same five steps whether one clinic is connected or fifty.
The message is acknowledged and stored immutably before anything reads it, keyed so a retry can never double-count.
Codes and local names are matched against the canonical dictionary and the loaded LOINC release. Anything ambiguous is quarantined, not guessed.
Unresolved keys reach a human queue ordered by consequence. A person decides; the decision is named, timestamped, and applies retroactively.
The dictionary is cut as an immutable, checksummed release and exported as FHIR R4 terminology any conformant server can load.
Measures are computed from normalized coded results, against a specific dictionary release — so a number can be reproduced later, not just asserted.
// The order matters. Steps 02 and 03 are where programs usually take a shortcut, and where the impact report later falls apart.
All measured on synthetic data. Every one of them can be re-derived in front of you in a working session.
Codes in the LOINC 2.83 release that fail the mod-10 check-digit rule. They are real, valid, active LOINCs. Any system validating by arithmetic instead of by the release silently rejects all of them — which is why we validate by existence and ACTIVE status, and by nothing else.
The published terminology bundle loads into stock open-source HAPI FHIR 8.12.0 with zero CodeSystem, ConceptMap or ValueSet validation errors, and all four terminology operations passing. It was validated on somebody else's server precisely so the result does not depend on ours.
Machine-generated binding proposals currently pending human disposition. We report this number rather than hide it: a semantic layer with nothing in its review queue is not finished, it is unsupervised.
A development environment running entirely on synthetic patients and synthetic message traffic generated by our own clinical simulator. No real patient data has ever touched development or validation. That is what makes a thirty-minute working demonstration possible with no data agreement and no PHI exposure — you can watch the whole pipeline run before anyone signs anything.
Documentation is a deliverable here, not an afterthought. These are written as the work is built, not reconstructed at the end.
What the system is, what it runs on, what is built versus planned, and the decisions still open — each one written down rather than absorbed into somebody's head.
How a code becomes a concept: the tiers, the commit rule, the review queue, the deprecation scan, and the query to recompute any coverage figure we have quoted.
Every dictionary release, immutable and checksummed, with a stored snapshot of its members so past figures stay reproducible.
The evidence that the published bundle loads and validates cleanly on an independent, open-source FHIR server — including what failed on the first attempt and what changed.
The validation record includes the failures. The first load attempt was rejected and profile validation reported hundreds of errors before it reported none. A validation document with no failures in it is not a validation document — and a program office that is going to trust this layer should be able to see how it got to clean.
Thirty minutes, end to end, on synthetic data only — no PHI, no data agreement needed to see it. If the fit is wrong you will know inside that half hour, and so will we.
Clinical Decision Support Notice — CareCompile is a non-diagnostic clinical decision support tool intended to augment, not replace, physician judgment. All AI-generated analyses are advisory only; clinical decisions remain the sole responsibility of the licensed treating clinician. CareCompile is not FDA-cleared or FDA-approved as a medical device and is not intended to diagnose, treat, cure, or prevent any disease. For investigational and decision-support use only. Figures on this page are measured on synthetic data in a development environment and are stated as of the most recent build.
