Platform · Interoperability · the position

Where this fits the federal stack, class by class

How the record fits USCDI, FHIR, SMART on FHIR, TEFCA and Blue Button, with the gap beside each.

The rubric names USCDI+, HL7 FHIR, TEFCA, Blue Button 2.0 and the CMS Interoperability Framework. This page answers each by name with the state the capability register gives it — built, blocked, designed, or unassessed — and the specific gap written next to every one.

How this page stays true

Each framework card cites a register row by its exact title, or says unassessed. The resource types named for the export are the list the build asserts against a real download, both ways. The element counts are read from the published set. Nothing here has been submitted to, reviewed by, or endorsed by any standards body, and the page is written so it cannot sound as if it had.

01 · Named in the rubric

Six frameworks, six states

HL7 FHIR R4 · the patient exportBuiltWorking
A patient downloads their whole record as one FHIR R4 Bundle (type collection). It writes Patient, Condition, Observation, DiagnosticReport, MedicationStatement, Consent, and its coverage statement names every element of the published set it does not carry rather than inventing one. Each sharing switch and each care-team grant is a Consent with its dates, the clinician named as a Practitioner; a research cell is written as a Group only when it holds five or more records. The file is checked against the R4 JSON Schema, which is schema validation, not the full HL7 validator.
The gapNo US Core profile is claimed. Codes are plain text or the platform’s own symptom code system; there is no LOINC, SNOMED or RxNorm mapping in the export today. The tick-borne elements travel as extensions under lymehq.com with no published StructureDefinition.
hl7.org/fhir/R4 (opens in a new tab)
The element set · a USCDI+ draftBuiltWorking
The record’s element set is published in full — six classes, eighteen elements, each with its definition and a disclosure line saying whether the export carries it, does not hold it, or treats it as policy. A draft for discussion, submitted to nobody.
The gapNo tick-borne USCDI+ domain exists to conform to. The novel elements below are the contribution, and they are expected to be contested.
healthit.gov · USCDI (opens in a new tab)
SMART on FHIR · portal importDesigned, not builtDesigned, not built
A patient pulls their own records from a portal into the record they own. The designed route is Epic Individual Access Services under TEFCA — patient-directed, USCDI v3, free to developers.
The gapNothing runs. No app is registered against any sandbox, and no Observation has ever been imported this way.
hl7.org/fhir/smart-app-launch (opens in a new tab)
CMS Blue Button 2.0 · Medicare claimsBuilt · blocked upstreamBlocked upstream
The connect flow — the consent gate, the PKCE exchange and the redirect chain to CMS — is built and proven to the boundary against CMS’s sandbox. A beneficiary’s own claims would arrive as ExplanationOfBenefit at FHIR 4.0.1. For production, CMS publishes a separate patient-access path, CMS Aligned Networks: a client_credentials grant with SMART asymmetric authentication and a cms_smart JWT extension modelled on TEFCA’s tefca_smart, carrying an IAL2 ID token from CLEAR or ID.me, with no medicare.gov login.
The gapThe sandbox fails on CMS’s side: its synthetic beneficiary logins fail at medicare.gov SSO, re-tested 24 September 2026 and reproduced on CMS’s own v3 test client in a clean browser with CMS’s published credentials. The Aligned Networks path needs a Medicare App Library listing and a registered JWK Set; we have neither, so it is designed, not built. No claims data has ever moved.
bluebutton.cms.gov · CMS Aligned Networks (opens in a new tab)
TEFCAUnassessed
The only TEFCA-shaped thing in the design is the portal-import route above: the patient pulls, through Individual Access Services. The record is not a network node and nothing queries it.
The gapUnassessed, in the roadmap’s word. No QHIN relationship, no identity proofing, and no representation for tick-borne conditions exists to exchange.
healthit.gov · TEFCA (opens in a new tab)
CMS Interoperability FrameworkUnassessed
What is true of the code: the patient holds the keys, exports in a standard format, and every access to their record is written to an append-only audit log. LymeHQ is not a payer and runs no Patient Access API.
The gapUnassessed against the framework itself. The clinician directory is a page, not a FHIR Practitioner endpoint.
cms.gov · interoperability (opens in a new tab)

A public API

There is no public API, and none is in the register. The only machine-readable surface is the patient’s own export, which the patient downloads themselves.

02 · USCDI v4

Which classes a written resource serves

5 of 18 classes have a resource type in the export. The rest are not modelled, and say so.

USCDI class	In the export	What LymeHQ writes · the gap
Patient Demographics / Information	Patient	Name and identifiers as held. Address leaves only as the first three ZIP digits; the export is the patient’s own copy.
Problems	Condition	Diagnoses and coinfections as recorded on the platform, text-coded.
Laboratory	DiagnosticReport	Panels with each analyte as an Observation and a data-origin extension saying where the result came from.
Health Status Assessments	Observation	The daily symptom scores, coded in the platform’s own symptom code system. No standard vocabulary carries them.
Medications	MedicationStatement	Names and dates. The patient’s own export carries the dosage they typed; the brief a clinician reads does not, by rule.
Provenance	Not modelled	A Provenance resource for each lab report you added and confirmed: you as the person who entered and confirmed it, and when. Older results carry their origin as an extension; nothing else carries who or when.
Allergies and Intolerances	Not modelled	Not modelled.
Care Team Members	Not modelled	Not modelled in the export. A care relationship exists as a database row and never leaves.
Clinical Notes	Not modelled	Not modelled. The journal never leaves the patient’s own screens.
Clinical Tests	Not modelled	Not modelled.
Diagnostic Imaging	Not modelled	Not modelled.
Encounter Information	Not modelled	Not modelled.
Goals and Preferences	Not modelled	Not modelled.
Health Insurance Information	Not modelled	Not modelled. Imported Medicare claims would be the first entry; none has moved.
Immunizations	Not modelled	Not modelled.
Medical Devices	Not modelled	Not modelled.
Procedures	Not modelled	Not modelled.
Vital Signs	Not modelled	Not modelled.

USCDI+ has no tick-borne set. The published element set is the draft of one: 10 of 18 elements have no place in any existing standard, 10 are in the export today, and two classes are new outright (Tick exposure and Household sentinel). Symptom scores travel under https://lymehq.com/fhir/CodeSystem/symptom-scores, a code system nothing has accepted. The full set, element by element, is on our standards work.

Beside the set, one proposed element: the patient’s own five-word answer to how the day was, written down as an ordered category rather than a number.

Proposed element · outside the set above

Overall, how was today

Ordered categorical · five levels

rank 1Rough
rank 2Hard
rank 3OK
rank 4Good
rank 5Clear

The value: The label is the value. The rank is carried beside it for ordering, and for nothing else.
No interval is assumed: No interval is assumed between levels: the step from Rough to Hard is not the step from OK to Good. The rank is never averaged, summed or differenced, and no figure is computed across a person’s days.
Missingness is part of the element: A day with no answer is part of the element. It is recorded as not answered — never imputed from other days or from the symptom scores, and never dropped from a count of days.
Precedent for the shape: CDC’s HRQOL-4 asks one general-health question on five ordered words — excellent, very good, good, fair, poor. It is the precedent for the shape, not the source: this question is about a day rather than health in general, and its five words are the tracker’s own. cdc.gov · HRQOL Healthy Days core module (opens in a new tab)
In the exports: Recorded, and not exported: neither the patient’s FHIR export nor the research dataset carries it. That is a consent decision about who may read a person’s own word for their day, not a gap in any standard.

03 · By name

De-identification, and what leaves

What an aggregate has to clear

Research output leaves only as counts, from a cache the researcher cannot read directly: a floor of five enforced inside the database by the only two functions that can query it, with no configuration that lowers it; geography reduced to the first three ZIP digits, with seventeen restricted prefixes collapsed to a single code; ages in ten-year bands with everyone over ninety in one. A cell under the floor renders as withheld, never as blank.

WorkingCohort counts, k of at least five enforced before display

Ruled outAny export that could identify a person

Blocked upstreamPathogen presence at block-group level

There is no cross-organisation patient matching, because nothing arrives from another organisation. The blocked row above is the one place finer geography is designed: block groups for a health department, under an agreement that does not exist yet.

04 · Scalability · reuse

What changes for another condition, and what does not

Each line is a register row, in the state the register gives it. No date and no estimate.

Stays as it is · condition-agnostic

WorkingTimeline, check-in, daily log

WorkingAdd a lab report — your document kept, the values typed by you or read from a portal file

WorkingMedications — a record, not an engine

WorkingPre-visit brief, patient and provider sides

WorkingShared with me, scoped to what was granted

WorkingCohort counts, k of at least five enforced before display

WorkingExport everything

WorkingDelete your account

Also the consent switches that start off, the both-locks sharing rule and the append-only audit log, which are rules rather than register rows.

Changes · condition-specific

WorkingThe tick-bite workflow

WorkingHousehold record and the pet sentinel

WorkingCDC tickborne surveillance, 1992 to 2023

WorkingThe element set and codebook