Patient 360

Read this first. Nothing on this page is built. It is a design. Every value shown is synthetic. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue and $0 raised, and has never processed real patient data. The patient is deliberately unnamed. No real record can be held here until Sentinel’s de-identification reliably redacts plain personal names — it does not today — and a BAA or a Limited Data Set under a DUA is in place. This view organises and explains; it never diagnoses.

• Identity • Conditions • Medications • Encounters • Labs • Vitals • Insurance • Claims • Care team

◆

The whole picture

A designed view. Not a shipped feature. Every figure in it is synthetic; Ardia has never held a real patient record.

1. The problem

An 80-year-old with COPD in GOLD group E, heart failure with reduced ejection fraction, type 2 diabetes and hypertension does not have one health record. She has at least five, and none of them can see the others.

Concretely, in the synthetic case this whole view is designed against:

The hospital portal holds the admissions, the discharge summaries, the inpatient labs, and the problem list as that health system maintains it. It does not hold the independent pulmonologist's spirometry.
The independent pulmonologist, on a different EHR instance, holds the CAT and mMRC scores, the exacerbation history that actually drives GOLD group assignment, and the triple-therapy inhaler decision. That practice does not see the hospital's natriuretic peptide trend.
The reference lab holds the pharmacogenomic panel and the chemistry that gates dosing. It reports to the ordering clinician, not to the patient's other clinicians, and its creatinine reference range differs from the hospital lab's — so a value that is flat clinically looks like a step change when you put the two next to each other.
Two pharmacies each hold half the fill history. Neither knows about the other's dispenses. Both are invisible to every clinician who did not e-prescribe through them.
The DME supplier holds the home oxygen and the rented pulse oximeter, and is invisible to all four of the above.
The Medicare Advantage plan holds the only complete list of what was billed, what was paid, what was denied, and what clock is running. It shares almost none of that back in a form anyone can act on.

Six medications from three prescribers across two pharmacies. Five to nine encounters a year. Every one of those encounters generates a claim, and some fraction of those claims are denied — a fraction that is not something this page will assert a number for, because Ardia has no data of its own and inventing one would be exactly the behaviour this project exists to avoid. Any denial rate, appeal-success rate, caregiver-hours or caregiver-cost figure cited alongside this view must carry a named source and a year. The honest statement is: denials happen, appeal windows are short, and most people miss them. The magnitude needs a citation, not an assertion.

The work of reconciling all of it lands on one unpaid adult child. Not a clinician. The tasks are real and unglamorous: notice the paper denial notice in the mail before the clock runs out; work out whether the inhaler is unfilled because it was never sent or because the pharmacy hit a prior-authorization reject; figure out which of the three prescribers should be told that a fourth added something; know whether the oxygen is still covered.

That person is doing a records-integration job with a shoebox and a phone. Nothing in the current tooling is built for them. Epic's proxy access shows one health system. Apple Health shows what the devices and the connected portals hand it. Neither shows a single dollar of adjudication.

2. What a patient 360 is

One longitudinal record for one person, assembled from every source that holds a piece of them, answering seven questions:

Who they are — identity, demographics, and, critically, who else is allowed to see what. FHIR Patient, RelatedPerson, Consent, Provenance, AuditEvent, with US Core demographics and DS4P sensitivity labels. This is the domain that makes the other eight safe to exist.

What they have — conditions, allergies, immunizations. Condition, AllergyIntolerance, Immunization. SNOMED CT for the clinical concept, ICD-10-CM for what was actually billed, and both shown, because they routinely disagree.

What they take — medications, what was actually dispensed, adherence, and the pharmacogenomics that govern dosing. MedicationRequest, MedicationDispense, RxNorm for the product, NDC for the package that left the shelf, the CPIC phenotype from the reference lab, the AGS Beers 2023 flag for an 80-year-old.

What was done — encounters, procedures, surgeries, devices. Encounter, Procedure, Device with UDI, CPT/HCPCS and ICD-10-PCS, place of service, discharge disposition.

What was found — labs, imaging, molecular diagnostics. Observation, DiagnosticReport, ImagingStudy, LOINC, UCUM-normalized so cross-lab trending is honest, DICOM study identifiers, HGVS and ClinVar for variants, MolDX Z-codes as supplied by the performing lab and never generated.

What is happening at home — vitals, home monitoring, activity. Observation against US Core vital-sign profiles, Device and DeviceUseStatement for the rented oximeter and the oxygen concentrator, LOINC and UCUM, and the CPT 99453/99454/99457 remote-monitoring line that pays for it.

What it costs and what is covered — eligibility, benefits, claims, EOBs, denials, appeals. Coverage, CoverageEligibilityResponse, Claim, ClaimResponse, ExplanationOfBenefit, CARIN Blue Button profiles, the X12 270/271, 837, 835 underneath, CARC and RARC codes, the governing NCD or LCD.

And the thread through all of it — care team, care plan, goals, hand-off. CareTeam, CarePlan, Goal, Task, so the view is not nine stacked lists but one plan with nine kinds of evidence under it.

Nine domains. One person. One timeline.

3. The one thing nobody else does

Every patient-360 on the market shows clinical data. Epic MyChart, Apple Health, Health Gorilla, Particle, Zus, b.well, Validic — good at different parts of the same job, and Ardia would not be better than any of them at record retrieval. Ardia has no aggregation advantage. It should not claim one.

The difference is a single design decision: the coverage event sits on the same timeline row as the clinical event that generated it. Not a separate billing tab. Not the provider's accounts receivable. The plan's adjudication, joined to the order and the result.

Here is one synthetic sequence, end to end. No names, because there are none to use.

Day 0. Pulmonology — the independent practice, not the hospital — orders a chest CT without contrast. ServiceRequest, CPT 71260, ordering diagnosis J44.9 (COPD, unspecified). The order carries the reason the pulmonologist had in mind, which was a nodule noted on a prior study. That reason is in the note. It is not in the diagnosis field.

Day 6. Scheduled at the hospital imaging department. Appointment, place of service 22.

Day 11. Performed. ImagingStudy with a StudyInstanceUID and an AccessionNumber; DICOM modality CT, BodyPartExamined CHEST.

Day 13. Report returned. DiagnosticReport, LOINC-coded, structured against an RSNA template. Findings describe the nodule.

Day 15. The hospital submits an 837I. CLM01 carries the claim control number. Loop 2300 HI segment carries the diagnosis with an ABK qualifier: J44.9, the unspecific code from the order, not the finding.

Day 34. The 835 remittance returns. CLP07 links back to the 837. The CAS segment carries CO-50 — these are non-covered services because this is not deemed a medical necessity by the payer — with RARC N115, pointing at a Local Coverage Determination.

Day 34, same row. The view resolves the LCD by identifier against the Medicare Coverage Database and shows, in plain language, what that policy requires as a covered indication for CT of the chest. It shows that the diagnosis submitted was not one of them. It shows that the diagnosis that would have been one of them is sitting three rows above on the same problem list, and appears in the radiology report the patient can read on the row directly beneath.

Day 34. The clock starts. Medicare Advantage plan reconsideration under 42 CFR Part 422 subpart M: 60 days from the notice date. The row reads "44 days left to file" and counts down. Not a badge. An arithmetic fact with a regulatory citation under it.

Day 34. The view names the evidence that would overturn it: the radiology report documenting the finding, and a corrected or supporting diagnosis statement from the ordering pulmonologist. It does not decide that the appeal is correct. It does not assert medical necessity. It assembles.

Day 36. A draft reconsideration request is generated — the claim number, the service date, the CARC and RARC, the LCD identifier, the attached report, the argument that the covered indication was documented. It is a draft. A human reads it, a human signs it, a human files it. Task tracks that it is awaiting human review, and it stays there until a person acts. Nothing auto-files.

That is the whole differentiator, and it is a real one: deterministic joins — 837 CLM01 to 835 CLP07, service date plus NPI to ServiceRequest and DiagnosticReport, notice date to a regulatory clock — plus a CARC/RARC-to-evidence mapping. It is engineering, not magic.

The same join runs the other eight domains. The pharmacogenomic panel denied CO-50 with N115, sitting next to the CYP2C19 intermediate-metabolizer result that governs a prescription. The triple-therapy inhaler unfilled behind an NCPDP reject 75, with a 72-hour Part D coverage-determination clock. The remote-monitoring 99454 for the scale denied CO-151, next to the weight trend the scale produced. The home oxygen denied against NCD 240.2, with 41 days left, next to the SpO₂ readings. A molecular claim denied CO-16 for a missing MolDX Z-code and paid on resubmission — which is the single most instructive row on the page, because it shows a denial that was a clerical defect, not a clinical judgement.

Be equally plain about what this does not do. It adds nothing to eligibility accuracy — the payer is always the source of truth. It cannot pay a bill. It cannot fix data quality upstream. And it does nothing at all if the paper denial notice never gets opened, because for Original Medicare and for many plan communications that letter is still what starts the clock.

4. How it is governed

De-identification before inference. No identified record reaches a model. Sentinel strips identifiers before any text is sent for explanation.

The engine is Google Gemini — gemini-flash-lite — not Claude. Stated because a reader deserves to know whose model would see their data.

Six deterministic gates, evaluated on every generated explanation: de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop. A failed gate withholds the answer entirely. There is no degraded output, no hedged partial, no "here's my best guess." The patient sees that a question was asked, that a gate failed, and which one. That is a better outcome than a confident wrong answer, and it is the reason gates are deterministic code rather than instructions in a prompt.

Non-diagnostic, always. This view organises and explains. It does not diagnose, does not prescribe, does not assign acuity or triage priority, does not rank one patient against another. A suspected emergency escalates to 911 and the safety_escalation gate exists to force that path rather than let a model reason about it.

Consent-scoped caregiver access. This is where the differentiator creates a genuine obligation. Putting money on the timeline creates a financial surface, and an older adult should be able to exclude it. FHIR Consent with DS4P labels, tiered: the adult child can be granted the chest CT and the inhaler list while being denied the denials, the deductible, and the balance owed. Epic proxy access and Apple Health sharing both govern clinical data only; neither can express "see my imaging, not my money." Tier 4 exists because the coverage lane made it necessary.

A plain-language access log. Every read, rendered to the patient in sentences, not buried in an ATNA store — including reads by Ardia's own AI pipeline, and including the gate failures where nothing was returned.

And the gating dependency, stated plainly: Sentinel does not reliably redact plain personal names today. Structured identifiers, yes. A name written in free text inside a radiology impression or a nursing note, not dependably. That is a real, current, unfixed limitation, and it is the precise reason a patient-360 holding real PHI cannot ship. Not "should be careful." Cannot ship. Everything below in section 6 is downstream of fixing it.

One more honest limit: Ardia would not identity-proof anyone. It inherits whatever NIST SP 800-63-3 assurance level the upstream portal established, which for an 80-year-old enrolled at a hospital front desk is weak. And it cannot resolve the underlying fact that five systems disagree about who this person is. It can show the disagreement. It cannot settle it.

5. Where the data comes from

EHR clinical data — FHIR R4 via SMART on FHIR and OAuth 2.0, US Core profiles, against the hospital portal and the pulmonology practice. Conditions, encounters, procedures, labs, imaging metadata, care team, notes as DocumentReference. Cures Act information-blocking rules make the API available; they do not make it complete. Much of it still arrives as HL7 v2 ORU^R01 or as C-CDA documents and gets mapped on ingest.

Claims and coverage — three paths, in order of preference. The plan's CMS Patient Access API (CMS-9115-F) returning CARIN Blue Button ExplanationOfBenefit. Da Vinci PDex for payer-to-payer and member data. And clearinghouse X12 — 270/271 eligibility, 276/277 status, 278 prior auth, 837, 835 — where the API does not exist or does not carry the denial detail. CMS-0057-F adds a FHIR Prior Authorization API with denial reasons on 2026–2027 compliance dates; that is a dependency on a date, not a capability today.

Pharmacy — NCPDP SCRIPT 2017071 RxHistoryResponse and Surescripts medication history for fills; NCPDP Telecom D.0 reject codes for the point-of-sale failures that explain an unfilled prescription; Da Vinci PDex US Drug Formulary for what the plan covers; CMS Blue Button 2.0 Part D PDE for what was actually paid.

Devices and home monitoring — Apple HealthKit, Google Health Connect, vendor APIs, Bluetooth SIG GATT profiles for scale, cuff and oximeter, IEEE 11073 nomenclature where a device emits it. These are ingestion surfaces, not standards, and everyone uses the same ones. No advantage here.

Patient- and caregiver-entered — QuestionnaireResponse and photographs of paper notices, which for the appeal clock is often the only trigger available.

Hardest, ranked. Claims is hardest, for a reason worth naming: the patient can get the EOB, but the 835 CAS/LQ detail that says exactly why usually lives with the provider, and Ardia has no relationship with the provider. Second is name-level de-identification in free text, which is section 4's blocker. Third is the DME supplier, which has no API worth the word. Fourth is cross-lab UCUM normalization with honest method breaks — solvable, tedious, and routinely done badly by showing a smooth line where there was a methodology change. Easiest is the FHIR clinical read from a modern EHR, which is exactly the part five other companies already do well.

6. What is built today

Nothing.

0 customers.
0 pilots.
0 signed BAAs.
0 signed DUAs.
$0 revenue.
$0 raised.
0 real patient records ever processed.

Every number, code, date and countdown in this view is synthetic and was written to be realistic, not to be real. The 80-year-old described throughout does not exist.

The sequenced path to a first real record:

Legally, first. Either a Business Associate Agreement with a covered entity, or — the more realistic first step — a Limited Data Set under 45 CFR 164.514(e) with a Data Use Agreement, which permits dates and geography while excluding direct identifiers. An LDS is the right first target because it constrains the exact failure mode Sentinel currently has. Full Safe Harbor de-identification or Expert Determination for anything broader. 42 CFR Part 2 segmentation before any substance-use record is touched. GINA Title I compliance before any genomic result appears next to a coverage decision, because that combination is precisely what GINA anticipates.

Technically, second. Sentinel must redact plain personal names in free text at a measured, published rate against a held-out corpus, with the failure mode being over-redaction. The Gemini model version must be pinned, with a documented revalidation procedure on version change, because an unpinned model silently changes what the gates are guarding. The six gates need adversarial test suites, not spot checks. Audit logging must be complete before the first real read, not after.

Clinically, third. Clinician review of every explanation template. A named escalation path for the safety_escalation gate. And explicit sign-off that the non-diagnostic boundary holds under the specific pressure this view creates — because a patient looking at a denial and a lab result on the same row will ask "is this bad," and the correct answer from this system is never a clinical one.

None of these can be skipped by shipping to a friendly first user. A friendly first user is still a person with PHI.

7. The five pillars

Precision medicine. Precision medicine fails at the coverage boundary more often than at the science boundary. A therapy selected on molecular evidence is worthless if it is denied and nobody appeals in time. This view is the only one that shows the molecular result, the therapy it implies, the prior-authorization state, and the days remaining on the same row — and shows the specific evidence that would satisfy the policy. That is the practical form precision medicine takes for an 80-year-old on a Medicare Advantage plan.

Molecular and genomic diagnostics. The MolDX layer is genuinely distinct: CPT PLA codes, the DEX Z-code as supplied by the performing lab, prior-authorization state, and the CO-16 missing-Z-code denial that is a clerical failure rather than a clinical one. Paired with the HL7 Genomics Reporting IG for the result itself and CPIC phenotype terminology for what it means for dosing. Ardia does not generate genotypes and does not generate Z-codes. It shows the ones it is given, and shows what happened to the claim they were on.

The 2027 PAMA cliff. PAMA rate reductions push laboratory reimbursement down, and cost that a lab cannot absorb moves toward the patient — as denials, as balance, as tests quietly not ordered. This view is where an individual patient can actually see that happen to them: the molecular test, the reduced allowed amount, the increased patient responsibility, the appeal path. It does not fix PAMA. It makes PAMA legible at the level of one person, which is the only level at which most people encounter policy.

Pulmonary and respiratory care. The synthetic patient is a GOLD group E COPD patient because pulmonary is where the fragmentation is worst: the independent pulmonologist holds the exacerbation history, the hospital holds the admissions, the DME supplier holds the oxygen, the pharmacy holds the inhaler that was never filled, and the plan holds the denial on all of it. Spirometry LOINC panels, CAT and mMRC instruments, NCD 240.2 for home oxygen, the 99454 remote-monitoring line — one view, five sources, one timeline.

Elder care. Everything above lands on the consent design. Elder care is the pillar that forces Tier 4: an adult child who can be given the imaging and the medications while being denied the deductible and the denials. It forces the plain-language audit log, because the person most exposed to quiet over-sharing is the one least able to audit an ATNA store. It forces the discharge-gap arithmetic and the Beers 2023 flags. And it forces the non-diagnostic posture hardest, because a frightened family member at 11pm is exactly the reader who most wants this system to tell them what is wrong, and exactly the reader it must refuse.

Toxicology sits on the same roster and uses the same machinery — result, coverage policy, denial, clock — with 42 CFR Part 2 segmentation applied throughout.

Designed, not built. Synthetic throughout. Non-diagnostic. Not shippable until Sentinel reliably redacts names.

•

Identity, Demographics, Consent and Access

Why it matters

This is the domain that decides whether the other eleven domains are legal to show at all, and it is where an 80-year-old with COPD (GOLD group E), HFrEF, type 2 diabetes and hypertension currently loses. Their record is scattered across a hospital MRN, an independent pulmonology practice MRN, a reference lab requisition id, a DME supplier account and a Medicare Advantage member id. Nothing joins those five identities, so the chest CT in the hospital portal and the CO-50 denial on the plan's EOB never appear as the same event. The adult child acting as care collaborator has no lawful, scoped credential, so the family does what families do: they share the patient's portal password. That single workaround destroys the audit trail, gives the adult child every category of data including financial and behavioral records the patient never intended to share, and leaves the practice unable to tell whether it was the patient or the collaborator who read a result. Consent here is not a checkbox. It is the identity graph, the sharing scope, the break-glass path and the readable access log that make a shared record survivable for an older adult.

What this domain holds

Data element	FHIR R4	Code system	Note
Ardia pseudonymous subject id	`Patient.identifier (system = Ardia-internal pseudonym namespace, type ANON)`	`HL7 v2 Table 0203 Identifier Type (ANON / PI); HL7 v3 ActCode security label PSEUDED`	The only identifier Ardia's own storage would hold in the de-identified tier. Not derivable back to an MRN without the separately-held crosswalk. Nothing is built; today this is a design, not a running key service.
Source-system MRN (per organization)	`Patient.identifier[type=MR].value with .assigner reference to Organization`	`HL7 v2 Table 0203 identifier type MR; assigner identified by NPI (NPPES) or CLIA number for the reference lab`	Five distinct MRNs for this patient: hospital, pulmonology practice, reference lab, DME supplier, plan. Held only in the identified tier behind a BAA. Ardia holds none today.
Health plan member id / subscriber id	`Coverage.subscriberId; Patient.identifier[type=MB]`	`HL7 v2 Table 0203 type MB; carried in X12 270 loop 2100C NM109 and echoed in the 271 response`	This is the join key that lets a denial sit on the same timeline as the CT that generated it. No other patient-360 attempts this join.
Medicare Beneficiary Identifier (MBI)	`Patient.identifier (CMS-assigned, system = MBI namespace)`	`CMS MBI format (11 characters, no SSN); distinct from the MA plan's own member id`	An MA enrollee has both an MBI and a plan member id. Confusing them is a common cause of failed eligibility checks. MBI is a direct identifier and must never appear in the de-identified tier.
Birth date / age band	`Patient.birthDate`	`ISO 8601 date; HIPAA Safe Harbor §164.514(b)(2)(i)(C) age handling`	De-identified tier stores an age band, not a birth date, and aggregates any age over 89 to a single 90+ category. This patient is 80, so the band is 80-84.
Administrative gender, sex assigned at birth, gender identity	`Patient.gender; US Core us-core-birthsex extension; us-core-genderIdentity extension`	`HL7 AdministrativeGender; HL7 v3 birth sex codes; gender identity from SNOMED CT`	Kept separate because lab reference ranges and eligibility files use different ones. Ardia would display, not reconcile, and never infer.
Race and ethnicity	`US Core us-core-race and us-core-ethnicity extensions on Patient`	`OMB race and ethnicity categories; CDC Race & Ethnicity code system (PH_RaceAndEthnicity_CDC) for detailed values`	Collected because it drives equity reporting and, in pulmonary care, because race-based spirometry reference equations are being retired. Ardia would never use race as a clinical modifier.
Preferred language and interpreter need	`Patient.communication.language, .preferred`	`BCP-47 (urn:ietf:bcp:47)`	Determines whether an explanation can be rendered at all. Gemini output in a non-English language must pass the same six gates; if the honesty or non-diagnostic gate cannot be evaluated in that language, the answer is withheld.
Address / geographic subdivision	`Patient.address`	`USPS state codes; HIPAA Safe Harbor 3-digit ZIP rule (ZIP suppressed to 000 where the 3-digit area has 20,000 or fewer people)`	De-identified tier holds state and 3-digit ZIP only. Full address stays in the identified tier for DME delivery and plan service-area checks.
Telecom and emergency contact	`Patient.telecom; Patient.contact with .relationship`	`HL7 v2 Table 0131 contact role codes; ContactPoint system codes`	Direct identifiers. Suppressed entirely in the de-identified tier. This is exactly the free-text field where a personal name leaks, and where Sentinel currently fails.
Care collaborator (adult child) as a person	`RelatedPerson.relationship; linked from Patient via RelatedPerson.patient`	`HL7 v3 RoleCode CHILD (or PRN / GUARD where a legal proxy exists)`	Role label only. No name is stored in any tier Ardia can render. The collaborator authenticates as themselves, never as the patient.
Legal proxy / healthcare power of attorney	`Consent (category = advance directive) plus DocumentReference to the executed instrument`	`LOINC 42348-3 Advance directive; LOINC 81334-5 for the POA document class`	A POA is legally different from a consent-scoped collaborator. Ardia would surface which one is in force and refuse to treat one as the other.
Consent instrument (the record itself)	`Consent.status, .scope, .category, .patient, .dateTime, .performer, .sourceAttachment`	`Consent scope patient-privacy; category from LOINC 59284-0 Consent Document; IHE BPPC / APPC profiles`	Versioned and immutable. A change creates a new Consent, never an in-place edit, so the log can answer what was permitted on any past date.
Consent tier / scoped sharing matrix	`Consent.provision (nested), .provision.type (permit\|deny), .provision.actor.role, .provision.class, .provision.period`	`Provision class by FHIR resource type and by Ardia domain; actor role from HL7 v3 ParticipationType / RoleCode`	Four designed tiers: Tier 1 schedule and logistics only; Tier 2 adds conditions, medications and care team; Tier 3 adds results and imaging; Tier 4 adds coverage, claims, denials and out-of-pocket cost. Tier 4 is the differentiating one and also the elder-exploitation risk.
Sensitivity segmentation labels	`Resource.meta.security on every shared resource; Consent.provision.securityLabel`	`HL7 v3 Confidentiality (N, R, V); v3 ActCode sensitivity SUD, ETH, PSY, HIV, GDIS, SDV; HL7 Data Segmentation for Privacy (DS4P)`	Substance-use and toxicology results originating from a 42 CFR Part 2 program, and genetic results including MolDX Z-code-billed molecular tests, carry labels that force a separate consent decision and a redisclosure notice.
Consent verification and signature	`Consent.verification (.verified, .verifiedWith, .verificationDate); Signature.type on the attachment; Provenance`	`Signature type codes from urn:iso-astm:E1762-95:2013`	Records how consent was captured (in person, portal, telephone with witness) because an 80-year-old signing on a phone screen in a waiting room is a weak provenance story and should be visible as such.
Consent revocation event	`Consent.status = inactive; new Consent superseding; Provenance.activity`	`HL7 v3 ActCode; FHIR consent-state-codes`	Revocation must propagate to already-granted sessions and to any cached export. Designing this is easy; enforcing it across a Gemini prompt already in flight is the hard part and is not solved.
Break-glass emergency access	`AuditEvent.purposeOfEvent; Consent.provision.purpose override recorded as a distinct AuditEvent`	`HL7 v3 PurposeOfUse ETREAT (emergency treatment) and BTG (break the glass)`	Designed as: full clinical read, no cost or claims data, time-boxed, self-attested reason, and a notification to the patient and consented collaborator within a fixed window. Non-diagnostic still applies; a suspected emergency escalates to 911 rather than to a screen.
Access and audit log	`AuditEvent.type, .subtype, .action, .recorded, .agent (who, role, network), .source, .entity`	`DICOM Audit Message code system (via IHE ATNA); AuditEvent action codes C/R/U/D/E`	Every read is logged, including reads by the patient and by Ardia's own explanation pipeline. The log is rendered to the patient in plain language: who looked, when, at which domain, under which tier.
Data lineage / provenance of every rendered element	`Provenance.target, .recorded, .agent, .entity, .activity`	`HL7 v3 ProvenanceEventCurrentState; FHIR provenance-activity-type`	Required for honesty: every field on the patient-360 must be able to say which of the five sources it came from and when it was last refreshed, or it is shown as stale rather than shown as fact.
De-identification gate result	`Resource.meta.security de-identification tags; Provenance.activity for the de-id transform`	`HL7 v3 ActCode ANONYED, DEID, PSEUDED, SUBSETTED, REDACTED, MASKED`	Sentinel writes this tag. If the name-detection pass cannot assert clean, the resource is tagged as unverified and the AI explanation is withheld entirely rather than degraded. This gate is currently unreliable for plain personal names in narrative text.
Identity resolution / record linkage confidence	`Patient.link (.type = replaces \| refer \| seealso); Person; $match operation on Patient`	`No standard confidence code system; NIST SP 800-63-3 IAL for proofing strength`	Deterministic match on MBI or member id where present, probabilistic otherwise. Any match below threshold is shown to the user as an unresolved possible duplicate rather than silently merged. Silent merges are how one patient's result reaches another patient.
Authentication and authorization context	`Not a FHIR resource; SMART on FHIR scopes recorded in AuditEvent.agent`	`SMART App Launch scopes (patient/.rs, user/.rs); OAuth 2.0 / OIDC; NIST SP 800-63-3 AAL2`	Ardia would ride each source portal's own login rather than proof identity itself. Honest limitation: this inherits whatever proofing the hospital portal did, which is often weak for an 80-year-old enrolled at a front desk.
SDOH screening responses	`Observation (category = social-history / survey), QuestionnaireResponse`	`LOINC panels: PRAPARE 93025-5; Hunger Vital Sign 88122-7; AHC-HRSN screening 96777-8; answer values as LOINC answer codes or SNOMED CT findings`	For this patient the load-bearing items are transportation to pulmonary rehab, living alone, and cost-related medication underuse.
SDOH conditions and Z codes	`Condition (category = social-history or problem-list-item)`	`ICD-10-CM Z55-Z65 range (housing, economic, social environment); Z91.120 underdosing due to financial hardship; Z59.82 transportation insecurity; SNOMED CT equivalents`	Z codes are chronically under-coded because they do not pay. Ardia would show them where present and show the gap where absent, not impute them.
SDOH goals and referrals	`Goal, ServiceRequest, Task (Gravity Project SDOH Clinical Care IG)`	`SNOMED CT for intervention type; HCPCS for any billable community service`	Included so a closed loop is visible: screened, referred, and whether anything actually happened. Usually nothing did.
Result-release timing policy per source	`Not a patient resource; a per-Organization policy attribute rendered alongside DiagnosticReport / Observation`	`Governed by ONC information-blocking rules under the 21st Century Cures Act (45 CFR Part 171)`	Cures requires immediate release. Ardia's design shows the result exactly as the source released it, with an explicit banner that a clinician may not have reviewed it yet, and never adds interpretation ahead of the clinician.

HL7 FHIR R4 (Patient, RelatedPerson, Person, Consent, Provenance, AuditEvent, Coverage, Observation, Condition, Goal, ServiceRequest, Task, DocumentReference)US Core Implementation Guide (race, ethnicity, birth sex, gender identity, Patient profile)HL7 Data Segmentation for Privacy (DS4P) and HL7 v3 Confidentiality / ActCode sensitivity labelsIHE BPPC and Advanced Patient Privacy Consents (APPC); IHE ATNA with the DICOM Audit Message code systemSMART App Launch / SMART on FHIR scopes over OAuth 2.0 and OpenID ConnectHIPAA Privacy Rule and Security Rule; Safe Harbor de-identification at 45 CFR 164.514(b)(2) and Expert Determination at (b)(1)42 CFR Part 2 (substance use disorder records), as amended by the 2024 final rule aligning consent and redisclosure with HIPAAGenetic Information Nondiscrimination Act (GINA), Title I and Title II21st Century Cures Act information blocking rules, 45 CFR Part 171, and ONC HTI-1 certification criteriaCMS Interoperability and Prior Authorization final rule (CMS-0057-F); CMS Patient Access APICARIN Blue Button IG and Da Vinci PDex / PDex US Drug Formulary for Medicare Advantage claims and coverageX12 5010 270/271 eligibility, 837 claim, 835 remittance; CARC/RARC adjustment reason codesGravity Project SDOH Clinical Care IG; PRAPARE; Accountable Health Communities HRSN screening toolLOINC, SNOMED CT, ICD-10-CM, RxNorm, CPT/HCPCS, CVX, DICOM, and MolDX Z-code identifiers for molecular testsNIST SP 800-63-3 identity assurance (IAL) and authenticator assurance (AAL) levelsOMB Statistical Policy Directive No. 15 race and ethnicity categories; CDC Race & Ethnicity code systemTEFCA Common Agreement and QHIN Individual Access Services (as a future exchange path, not a current one)

Synthetic sample — no real patient data, no names

row_type	subject_pseudonym	age_band	administrative_gender	birth_sex_extension	race_omb
identity_record_deidentified_tier	ARD-SUBJ-0000-8F2C	80-84	female	F	White
identity_crosswalk_identified_tier_design_only	ARD-SUBJ-0000-8F2C
coverage_identity_join
consent_record
consent_scope_matrix
sdoh_observation
access_log_entries
break_glass_event
consent_revocation
sensitive_segmentation_example

What Ardia adds here

Concretely: this is the only patient-360 where consent scope includes money. Epic MyChart proxy access and Apple Health's sharing both govern clinical data; neither lets an older adult say "my adult child can see my chest CT and my inhalers, but not my denials, my deductible or what I owe." Ardia's Tier 4 exists precisely because the coverage-on-the-timeline differentiator creates a financial surface that a caregiver relationship should be able to exclude. Second, the audit log is rendered to the patient in plain language rather than buried in an ATNA store, including reads by Ardia's own AI pipeline and including gate failures where nothing was returned. Third, the six gates mean a de-identification failure withholds the answer rather than degrading it. Honestly, where it adds nothing: Ardia would not identity-proof anyone. It inherits whatever assurance the hospital portal did, which for an 80-year-old enrolled at a front desk is weak. It also cannot fix the underlying problem that five systems disagree about who this person is.

Where the data comes from.

Identity and demographics would come from each source's own system rather than from Ardia: the hospital and the pulmonology practice via FHIR R4 US Core Patient over SMART on FHIR (moderate difficulty where the EHR vendor's patient-access API is already certified under ONC criteria; hard where the practice runs a small ambulatory EHR with no app registration path). The Medicare Advantage plan's member identity and coverage come from the CMS-mandated Patient Access API and Da Vinci PDex, plus real-time X12 270/271 eligibility through a clearinghouse (moderate, but requires a trading-partner agreement). The reference lab's identity is a requisition record reachable only through the ordering practice, not directly (hard). The DME supplier is typically reachable only through the 835 remittance on the plan side (hard). SDOH is patient-entered or captured during an annual wellness visit and is the least reliable source of all. Consent, the sharing scope, the audit log and break-glass records are the only things in this domain Ardia would originate itself - and originating them means becoming a HIPAA business associate, which requires a signed BAA that does not exist.

Risks in this domain

Re-identification: an 80-year-old woman with COPD GOLD group E, HFrEF, type 2 diabetes and hypertension on a Medicare Advantage plan in a single 3-digit ZIP is close to unique. Safe Harbor field removal does not make this record anonymous, and the quasi-identifier combination defeats naive k-anonymity. Expert determination, not Safe Harbor, is the honest standard here.
Sentinel does not reliably redact plain personal names in free text today. Referral letters, nursing notes, pharmacy comments and DME delivery notes all carry names in narrative. Until this is fixed, no real PHI can enter the system at all - this is the gating dependency for the entire patient-360, not just this domain.
42 CFR Part 2: toxicology and substance-use records from a Part 2 program require consent that is separate from a general HIPAA authorization, plus a redisclosure prohibition notice. Toxicology is on Ardia's roster, so this is a live constraint, not a hypothetical. Aggregating Part 2 data into an unsegmented 360 view would be a violation.
GINA: molecular and genomic results, including MolDX Z-code-billed panels, are genetic information. GINA Title I and II restrict use by health insurers and employers, but do not cover life, long-term care or disability insurance - so an older adult sharing a genomic result with family creates an exposure GINA does not close. Ardia must say this rather than imply genetic data is protected everywhere.
Elder financial exploitation: Tier 4 exposes deductible status, out-of-pocket totals, denial amounts and appeal deadlines. Granting it to an adult child is exactly the access pattern exploitation uses. The design keeps Tier 4 off by default, requires an affirmative separate grant, expires it annually, and surfaces every Tier 4 read to the patient - and still cannot detect coercion.
Caregiver access without consent: today the common workaround is a shared portal password. That produces an audit log that attributes the collaborator's reads to the patient, which makes every downstream protection unfalsifiable. Consent capture must also handle diminished capacity, where the person granting access may not be able to give informed consent - and Ardia is not qualified to assess capacity.
Coercion and undue influence at consent capture: an in-person signature witnessed by practice staff is weak evidence when the person holding the phone is the one who will receive access. The provenance is recorded and displayed, but recording weak provenance does not make it strong.
Safety of pre-review result release: federal information-blocking rules require immediate release, so a patient can read a chest CT impression at 11pm before any clinician has called. Ardia can display the source's release exactly as-is with a clear not-yet-reviewed banner, but must never interpret, never assign acuity, and must escalate any suspected emergency to 911.
Break-glass abuse: emergency access is the single largest privacy hole in every health system that has one. Mitigations designed here - time-boxing, attested reason, cost data excluded, mandatory patient and collaborator notification - reduce but do not eliminate it.
The audit log is itself PHI: it reveals which specialists a patient saw and when. It must be protected at the same level as the clinical data and must not be exported casually.
Revocation propagation: a revoked consent cannot be guaranteed to reach an already-issued export, a cached view on a collaborator's phone, or a model prompt already in flight. This is unsolved and is stated as unsolved.
Silent identity merges: probabilistic linkage across five source systems will occasionally merge two people. In a 360 view that includes medications and results, a wrong merge is a patient-safety event. Sub-threshold matches must surface as unconfirmed rather than resolve silently.
Cross-border and vendor exposure: routing any de-identified text through Google Gemini creates a third-party processing relationship that requires its own contractual terms before any real data exists.

Build status.

Nothing in this domain is built. There is no identity service, no crosswalk, no Consent store, no AuditEvent store, no break-glass path, no SDOH ingestion and no consent UI. What exists is this design. Ardia Precision Health has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data - every row above is synthetic and no person, clinician or family member is named anywhere in it. Before a single real record can be held, four things must be true in order: (1) Sentinel's de-identification must reliably detect and redact plain personal names in free-text narrative, which it does not do today - this is the hard gate and it blocks everything else; (2) a signed BAA must be in place with each covered entity, plus a separate 42 CFR Part 2 qualified service organization arrangement before any substance-use or toxicology data is touched; (3) processing terms must be in place with Google for the Gemini (gemini-flash-lite) path, since the six gates - de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop - run around a third-party model; (4) counsel must review the consent tier model, the break-glass notification window and the Part 2 / GINA segmentation before it is offered to any patient. Until all four hold, this page can only ever be demonstrated with synthetic data, and it should say so on its face. The view is also non-diagnostic by construction: it organises and explains, never diagnoses, never prescribes, never assigns acuity, and escalates a suspected emergency to 911.

•

Conditions, Allergies and Immunizations

Why it matters

An 80-year-old with COPD, HFrEF, type 2 diabetes and hypertension does not have one problem list — they have four. The hospital system holds one, the independent pulmonology practice holds another, the reference lab knows only the diagnosis code that arrived on the requisition, and the Medicare Advantage plan holds a fifth that exists purely for adjudication. These disagree in ways that hurt. A COPD exacerbation coded J44.1 during a February admission is still sitting on the problem list as "active" in September, so every downstream summary reads as if the patient is exacerbating today. An ACE-inhibitor cough recorded as a penicillin-class "allergy" in one system blocks a drug the patient tolerates. A pneumococcal dose given at a grocery-store pharmacy never reaches the primary care chart, so the patient is offered it a second time while the RSV and high-dose influenza doses they actually need go unflagged.

The concrete failure this domain fixes: the adult child acting as care collaborator cannot answer, at a specialist visit, "what is actually wrong, what is resolved, what did they react to, and what shots are current" — and cannot see that the diagnosis code attached to a claim is the reason a test was denied.

What this domain holds

Data element	FHIR R4	Code system	Note
Problem list entry (condition concept)	`Condition.code (CodeableConcept, multiple codings)`	`ICD-10-CM and SNOMED CT dual-coded in the same CodeableConcept`	US Core requires SNOMED CT for problem-list items; ICD-10-CM is what actually travels on the claim. Ardia stores BOTH codings on one resource so the clinical concept and the billed concept can be reconciled instead of drifting. Where the source system sends only ICD-10-CM, that is recorded as-is and flagged as un-normalized rather than machine-translated into a SNOMED code Ardia cannot vouch for.
Active vs resolved state	`Condition.clinicalStatus`	`HL7 condition-clinical value set: active \| recurrence \| relapse \| inactive \| remission \| resolved`	The single most-abused element in real feeds. Many EHRs never set it, or leave every historical encounter diagnosis 'active' forever. Ardia displays absent clinicalStatus as 'source did not state', never as 'active'.
Confidence in the diagnosis	`Condition.verificationStatus`	`HL7 condition-ver-status: unconfirmed \| provisional \| differential \| confirmed \| refuted \| entered-in-error`	A 'provisional' or 'differential' condition must be visually distinct from a confirmed one. Showing a differential diagnosis to a patient as fact is a real harm pathway, and is exactly the kind of inference the non_diagnostic gate must refuse to smooth over.
Problem-list item vs encounter diagnosis	`Condition.category`	`HL7 condition-category: problem-list-item \| encounter-diagnosis; also SNOMED CT for health-concern`	An encounter diagnosis is a claim-time statement about one visit; a problem-list item is a longitudinal assertion. Collapsing them is how a resolved 2019 pneumonia ends up on an 'active problems' card. Ardia keeps them in separate lanes and only promotes to the problem list when the source did.
Onset	`Condition.onsetDateTime \| onsetAge \| onsetPeriod \| onsetString`	`Date/age; UCUM for age units`	Most legacy feeds carry only a year, or nothing. Ardia renders onset at the precision the source gave (a bare year stays a year) and never back-fills onset from the first claim date without labelling it as an inference.
Resolution / abatement	`Condition.abatementDateTime \| abatementAge \| abatementBoolean`	`Date; boolean where only 'resolved, date unknown' is known`	Required to render a condition as genuinely closed. Absence of abatement is not evidence of activity.
Recorded date and asserted date	`Condition.recordedDate; US Core condition-assertedDate extension`	`dateTime`	recordedDate is when the row was created in that system, which is frequently a data-migration date and not clinically meaningful. Ardia shows it as provenance metadata, not as clinical history.
Last assessed	`No native R4 element — derived from Condition.meta.lastUpdated, the most recent Encounter whose Encounter.diagnosis references this Condition, and Provenance.occurredDateTime`	`dateTime (derived, labelled as derived)`	Honest gap: FHIR R4 has no 'last assessed' field. Anything Ardia shows here is a derivation and must be labelled as such, with the underlying encounter shown so the reader can check it. A COPD problem last touched by a clinician 19 months ago should say so.
Severity	`Condition.severity`	`SNOMED CT: 255604002 mild \| 6736007 moderate \| 24484000 severe`	Ardia surfaces severity ONLY when the source clinician recorded it. Ardia never computes, infers or upgrades severity — that is acuity assignment and is out of scope by design.
Disease stage / group	`Condition.stage.summary, Condition.stage.assessment (reference to the assessing Observation or DiagnosticReport)`	`SNOMED CT where a concept exists (e.g. NYHA class concepts for heart failure). GOLD 2023 'group E' has no reliable standard code — carried as source text plus a local code, explicitly marked non-standard`	This is where honesty matters more than completeness. Do not fabricate a SNOMED code for GOLD group E. Carry the source string, name the classification system and the assessment it came from (post-bronchodilator FEV1/FVC on spirometry, CAT score, exacerbation count).
Body site / laterality	`Condition.bodySite`	`SNOMED CT body structure`	Low value for COPD/HF; high value for the pulmonary nodule and imaging-linked findings that sit alongside them.
Who asserted it, and from where	`Condition.recorder, Condition.asserter, Condition.meta.source, Provenance`	`Role-labelled reference (pulmonology, primary care, patient-reported)`	Every condition row carries which source system and which role asserted it. Patient- or caregiver-asserted conditions are visually separated from clinician-asserted ones and never merged into the clinical problem list.
Allergy / intolerance substance	`AllergyIntolerance.code`	`RxNorm ingredient or precise-ingredient for drug allergies; NDF-RT / drug-class concept for class-level allergies; SNOMED CT substance for food and environmental; UNII where a specific substance is needed`	Class-level ('penicillins') and ingredient-level allergies behave differently in any downstream check. Ardia preserves whichever granularity the source recorded and does not widen an ingredient allergy into a class allergy.
Allergy vs intolerance	`AllergyIntolerance.type`	`allergy \| intolerance`	Clinically decisive and almost always wrong in real data. ACE-inhibitor cough is an intolerance, not an allergy; statin myalgia is an intolerance. Mislabelling them removes whole drug classes from an older adult's options for the rest of their life.
Allergy category	`AllergyIntolerance.category`	`food \| medication \| environment \| biologic`	Drives which parts of the 360 the allergy annotates — medication category cross-links to the medications domain, biologic to immunizations.
Criticality	`AllergyIntolerance.criticality`	`low \| high \| unable-to-assess`	Criticality is a clinician's judgement of potential future harm; reaction severity is what happened last time. They are different fields and Ardia must not conflate them or derive one from the other.
Reaction manifestation and severity	`AllergyIntolerance.reaction.manifestation, .reaction.severity, .reaction.substance, .reaction.exposureRoute, .reaction.description`	`SNOMED CT clinical finding for manifestation; mild \| moderate \| severe for severity; SNOMED route`	'Rash' and 'anaphylaxis' cannot render identically. Where the source gives free text only, it is shown as free text with a 'not coded' marker rather than being coded by an LLM.
Onset and last occurrence of the reaction	`AllergyIntolerance.onsetDateTime, AllergyIntolerance.lastOccurrence`	`dateTime`	A reaction from the 1970s and one from last year are different decisions. Older adults carry decades-old allergy entries no one has revisited; showing the date is what makes de-labelling possible.
Allergy clinical and verification status	`AllergyIntolerance.clinicalStatus, .verificationStatus`	`HL7 allergyintolerance-clinical (active \| inactive \| resolved); allergyintolerance-verification (unconfirmed \| presumed \| confirmed \| refuted \| entered-in-error)`	Supports formal de-labelling — a refuted penicillin allergy after challenge testing must be visible as refuted, not silently deleted.
Explicit 'no known allergy' assertion	`AllergyIntolerance.code with a no-known-allergy concept`	`SNOMED CT 716186003 (no known allergy) and its substance-specific descendants`	An empty list and an affirmative 'none known' are different facts. Ardia distinguishes 'the source sent no allergy data' from 'the source asserted no known allergies as of a date'.
Vaccine product administered	`Immunization.vaccineCode; Immunization.manufacturer; Immunization.lotNumber`	`CVX for the vaccine concept (e.g. 197 high-dose quadrivalent influenza, 187 recombinant zoster, 216 PCV20, 115 Tdap); NDC for the specific product; MVX for manufacturer`	CVX is the interoperable code and the one IIS registries speak. COVID-19 and RSV CVX codes are reissued as formulations change — those are carried as whatever CVX the source sent, with the season named, rather than pinned to a code that may be superseded.
Administration date, site, route, dose	`Immunization.occurrenceDateTime, .site, .route, .doseQuantity`	`dateTime; SNOMED CT / HL7 v2 site and route value sets; UCUM for dose`	Route and dose matter for the high-dose vs standard-dose influenza distinction that is specifically an elder-care decision.
Dose number in series	`Immunization.protocolApplied.doseNumberPositiveInt, .seriesDoses, .series, .targetDisease`	`SNOMED CT for targetDisease`	Two-dose recombinant zoster and the pneumococcal sequencing rules are where older adults most often end up half-vaccinated. This is the element that makes 'dose 1 of 2, second dose overdue' renderable.
Source of the immunization record	`Immunization.primarySource (boolean), Immunization.reportOrigin, Immunization.performer, Immunization.location`	`HL7 immunization-origin value set (provider record \| written record \| recall \| school record \| public agency)`	Pharmacy-administered doses reach the state IIS but often not the primary care chart; patient-recalled doses are not the same evidence as an administration record. Ardia labels every dose with how it is known.
Vaccine not given, and why	`Immunization.status = not-done with Immunization.statusReason; ImmunizationRecommendation for gaps`	`HL7 immunization-status-reason (patient objection, immunity, medical precaution); SNOMED CT for contraindication`	A refusal and a contraindication are both 'not given' and must not look like an oversight. Ardia surfaces recommendation gaps as informational only, attributed to the published schedule, never as a directive.
Condition → encounter linkage	`Encounter.diagnosis.condition, Encounter.diagnosis.use, Encounter.diagnosis.rank; Encounter.reasonReference`	`HL7 encounter-diagnosis-use (admitting \| billing \| discharge)`	The join that turns a problem list into a story: which visits this condition actually drove, and in what role.
Condition → medication linkage	`MedicationRequest.reasonReference / .reasonCode; MedicationStatement.reasonReference`	`Reference to Condition; ICD-10-CM or SNOMED CT where only a code is sent`	Frequently absent in real feeds — most EHRs do not populate reasonReference. Where it is missing, Ardia shows the medication unlinked rather than guessing which of four conditions it treats.
Condition → order and result linkage	`ServiceRequest.reasonReference / .reasonCode; DiagnosticReport.basedOn`	`CPT/HCPCS on the order; LOINC on the result; ICD-10-CM as the ordering diagnosis`	The ordering diagnosis on a molecular or pulmonary test is the field that determines payability. This is the hinge between this domain and the coverage domain.
Condition → claim linkage	`Claim.diagnosis.diagnosisCodeableConcept, Claim.diagnosis.sequence, Claim.item.diagnosisSequence; ExplanationOfBenefit.diagnosis`	`ICD-10-CM; X12 837 loop 2300 HI segment, qualifier ABK (principal) / ABF (other diagnosis); service line pointers in SV107`	This is the element no consumer patient-360 carries. The diagnosis code that was billed is often NOT the condition on the problem list, and the difference is frequently why a claim failed.
Condition → denial linkage	`ExplanationOfBenefit.item.adjudication, ClaimResponse.item.adjudication with denial reason codes`	`CARC (e.g. CO-50 not deemed medically necessary; 167 diagnosis not covered) and RARC (e.g. N115 decision based on a Local Coverage Determination); X12 835 CAS segment for CARC, LQ segment with LQ01=HE for RARC`	The differentiator, made concrete at the condition level: 'the spirometry was denied because the diagnosis submitted was not on the LCD's covered list' is a sentence only Ardia's design can produce.
Condition → coverage policy linkage	`Represented as a reference/annotation on the ServiceRequest and EOB (no dedicated R4 element)`	`CMS LCD (L-number) and NCD identifiers; MolDX Z-code assigned through the Palmetto GBA DEX registry for molecular tests`	For molecular and genomic diagnostics the covered-diagnosis list in an LCD, plus the correct Z-code, decides payment. With the 2027 PAMA rate reductions squeezing lab margins, a mis-specific diagnosis code is increasingly the difference between a test being run and being refused outright.

FHIR R4 Condition, AllergyIntolerance, Immunization, ImmunizationRecommendation, Encounter.diagnosis, ProvenanceUS Core 6.x/7.x profiles: Condition Problem and Health Concern, Condition Encounter Diagnosis, AllergyIntolerance, ImmunizationICD-10-CM (billed diagnosis; CMS-maintained, annual October update)SNOMED CT US Edition (clinical problem concepts, substances, manifestations, severity, target disease)RxNorm ingredient / precise-ingredient and NDF-RT drug classes for medication allergiesUNII for substance identity where a precise substance is requiredCVX vaccine codes, MVX manufacturer codes, NDC for the administered product (CDC IIS standards)HL7 terminology value sets: condition-clinical, condition-ver-status, condition-category, allergyintolerance-clinical, allergyintolerance-verification, allergyintolerance-criticality, immunization-origin, immunization-status-reason, encounter-diagnosis-useLOINC for the assessments that stage a condition (spirometry panels, HbA1c, natriuretic peptide, absolute eosinophil count)CPT / HCPCS on the orders a condition drives; ICD-10-PCS for inpatient proceduresX12 837P/837I loop 2300 HI segment (ABK/ABF diagnosis qualifiers); X12 835 CAS and LQ segments; X12 270/271 for eligibilityCARC and RARC code sets (X12 / WPC maintained)CMS LCD and NCD coverage policies; MolDX Z-codes via the Palmetto GBA DEX registryIHE / HL7 C-CDA Problems, Allergies and Immunizations sections for document-based sourcesState Immunization Information System (IIS) interfaces, HL7 v2.5.1 VXU/QBP-RSP

Synthetic sample — no real patient data, no names

rowType	display	icd10cm	snomed	category	clinicalStatus
condition	Chronic obstructive pulmonary disease, GOLD group E	J44.9 (COPD, unspecified); J44.1 used on the February exacerbation encounter	13645005 (chronic obstructive lung disease)	problem-list-item	active
condition	Chronic systolic heart failure with reduced ejection fraction	I50.22 (chronic systolic (congestive) heart failure)	SNOMED CT concept for heart failure with reduced ejection fraction (descendant of 84114007 heart failure) — specific concept ID not asserted here rather than guessed	problem-list-item	active
condition	Type 2 diabetes mellitus without complications	E11.9	44054006 (diabetes mellitus type 2)	problem-list-item	active
condition	Essential (primary) hypertension	I10	59621000 (essential hypertension)	problem-list-item	active
condition	COPD with (acute) exacerbation — inpatient episode	J44.1	195951007 (acute exacerbation of chronic obstructive airways disease)	encounter-diagnosis	resolved
condition	Personal history of nicotine dependence	Z87.891	SNOMED CT concept for history of tobacco use (concept ID not asserted here)	problem-list-item	inactive
allergy				medication	active
allergy				medication	active
allergy				medication	active
allergy					active
immunization
immunization
immunization
immunization

What Ardia adds here

Epic MyChart shows one health system's problem list. Apple Health shows what the patient's devices and connected portals hand it. Health Gorilla, Particle and Zus aggregate clinical records well but stop at the clinical boundary. None of them attach the billed diagnosis code to the condition, or show that the chest CT was denied CO-50 against an LCD because the ordering diagnosis was the unspecific COPD code rather than the nodule finding sitting three rows above it on the same problem list. That single join — problem list to 837 HI segment to 835 CARC/RARC to LCD to a 60-day Medicare Advantage reconsideration clock — is Ardia's whole claim to difference here, and it is real, not cosmetic.

Where Ardia adds nothing, honestly: it does not improve the underlying data. Conditions arrive mis-staged, allergies arrive mislabelled as allergies when they are intolerances, immunizations arrive incomplete. Ardia surfaces the disagreement between sources and dates every assertion. It cannot resolve them, and it must never pretend to.

Where the data comes from.

Conditions come primarily from the EHR via FHIR R4 US Core (Condition Problem and Health Concern, Condition Encounter Diagnosis) — for this patient that means at least two independent feeds, the hospital system and the independent pulmonology practice, which will disagree on codes, specificity and clinical status. Where a source predates FHIR, conditions arrive inside a C-CDA Problems section and must be parsed. Integration difficulty: moderate for the FHIR path (the resources are well-profiled and widely supported), hard for reconciliation — deciding that I50.22 in one chart and I50.9 in another are the same condition is a terminology and provenance problem, not an API problem, and Ardia's design chooses to display both rather than auto-merge.

Encounter diagnoses also arrive as claim data: X12 837 from the provider side or, more realistically for a patient-facing product, the Medicare Advantage plan's member-facing API under the CMS Interoperability rule, which exposes ExplanationOfBenefit with diagnosis codes and adjudication. Difficulty: hard — payer API quality varies widely, and joining a claim's ICD-10-CM code back to the clinical Condition resource that generated it is the hardest join in this entire design and the one nobody else attempts.

Allergies come from the EHR via FHIR AllergyIntolerance, and are the lowest-quality data in the domain: type and criticality are frequently wrong or absent, manifestations are often free text, and entries are decades old. Pharmacy systems hold a partial parallel list. Difficulty: easy to ingest, very hard to trust.

Immunizations have a genuinely better source than the EHR: state Immunization Information System registries, queried over HL7 v2.5.1 QBP/RSP or increasingly a FHIR Immunization endpoint, which capture retail-pharmacy doses the primary care chart never sees. Difficulty: hard for a non-provider entity — IIS access is granted per state under state law, with separate agreements, and patient-access pathways differ by jurisdiction. Patient- or caregiver-supplied vaccination cards are the fallback and are labelled as non-primary-source.

Nothing above is connected today. All of it is a target-state description.

Risks in this domain

Re-identification: a problem list is a near-unique fingerprint. COPD GOLD E plus HFrEF plus type 2 diabetes plus age 80 plus a three-digit ZIP is identifying on its own — removing the name does not de-identify a condition set. Any export, analytics view, or model prompt built on this domain must be treated as identifiable data regardless of name removal.
THE GATING DEPENDENCY: Sentinel's de-identification does not reliably redact plain personal names today. Free-text Condition.note, AllergyIntolerance.reaction.description and clinician narrative routinely contain names of patients, family members and prescribers. Until name detection is fixed and validated, this domain cannot hold real PHI at all.
42 CFR Part 2: substance-use disorder diagnoses from a Part 2 program carry consent requirements far stricter than HIPAA, do not travel under a standard BAA, and cannot be redisclosed on the strength of a general authorization. A problem list that silently ingests an SUD condition from a covered program creates a redisclosure violation. Part 2 conditions must be consent-gated and segmentable, and Ardia's design must be able to withhold them entirely — including from the care collaborator and from any AI context window.
GINA: genetic conditions and molecular results (SERPINA1 genotype, any germline finding) are genetic information. Employers and most health insurers may not use it. It must sit behind its own consent scope, be excluded from the default care-collaborator view, and never be passed into a model prompt that could echo it into an unrelated answer.
Elder financial exploitation: a full condition list on an 80-year-old — cognitive status, frailty, terminal or degenerative diagnoses — is a targeting document. Combined with the coverage and cost data this 360 deliberately places alongside it, a compromised caregiver account becomes a fraud toolkit. Consent scopes must be revocable by the patient alone, time-boxed, auditable, and visible to the patient in plain language.
Caregiver access without genuine consent: the adult child is frequently the one who sets up the account. Consent captured at that moment may be the caregiver's convenience rather than the patient's decision. The design needs patient-initiated or clinician-witnessed consent, periodic re-attestation, and an access log the patient can read — plus the ability to grant conditions-and-immunizations access while withholding sensitive diagnoses.
Surfacing a condition before a clinician has discussed it: a new malignancy, a dementia diagnosis, or a refuted-versus-confirmed status change can reach a patient or caregiver in this view before any clinician has spoken to them. Information Blocking rules push toward immediate release; patient safety pushes the other way. The design must respect the source's release policy rather than accelerating it.
Provisional and differential diagnoses read as fact: verificationStatus is widely unpopulated in real feeds. A differential rendered as a confirmed condition is a manufactured diagnosis. Absent verificationStatus must render as 'source did not state', never as confirmed.
Stale 'active' conditions causing real harm: an unresolved encounter diagnosis from an acute admission, still marked active, can drive a wrong impression at a specialist visit and can propagate into risk-adjustment and claims data. Ardia's separation of encounter diagnoses from problem-list items is a safety control, not a UI nicety.
Allergy over-labelling: a decades-old, unconfirmed penicillin entry narrows an older adult's antibiotic options for life. Displaying it without its date and verification status perpetuates the harm. Conversely, Ardia must never suggest de-labelling — that is a clinician decision and the scope_of_practice gate blocks it.
Immunization gap displays becoming de facto medical advice: 'dose 2 overdue' is a schedule fact; 'you should get dose 2' is advice. The line is thin and the non_diagnostic and scope_of_practice gates must hold it, with the published schedule cited as the source and primary care named as the decision-maker.
Model-layer leakage: any Gemini-generated explanation of this domain sees condition and allergy text. Prompt content, logging, and retention must be scoped accordingly, and a failed gate must withhold the entire answer rather than degrade to a partial one.
Terminology drift as a correctness risk: ICD-10-CM updates annually in October, SNOMED CT semi-annually, CVX continuously as new formulations ship. A cached code set silently becomes wrong. Version-stamping every coding is required, not optional.
Coverage inference overreach: stating that a denial was 'wrong' or that an appeal will succeed is not something Ardia can support. The design shows the CARC/RARC, the LCD cited, and the deadline — facts from the 835 and the policy — and stops there.

Build status.

Nothing in this domain is built. There is no Condition, AllergyIntolerance or Immunization ingestion pipeline, no terminology service, no problem-list reconciliation logic, no encounter-diagnosis-to-claim join, and no UI. This is a design on paper for a page that does not exist. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed a real patient record. Every code, row and denial in this document is synthetic and was written to illustrate the design.

What is needed before any of it can hold real data, in order: (1) Sentinel's name-detection gap closed and independently validated — free-text condition notes and reaction descriptions carry names today and are not reliably redacted, so a patient-360 holding real PHI cannot ship until this is fixed; (2) an executed BAA with each data source, plus a DUA where claims data is involved; (3) a versioned terminology service for ICD-10-CM, SNOMED CT, RxNorm, CVX, CARC/RARC and LCD/NCD content, with version stamps written onto every stored coding; (4) consent scoping that can segment 42 CFR Part 2 conditions and GINA-protected genetic findings out of the care-collaborator view and out of every model prompt; (5) the six deterministic gates (de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop) wired in front of the Gemini flash-lite explanation layer, with a failed gate withholding the answer entirely rather than degrading it.

Only after all five would a build start, and it would start read-only with synthetic data. This view never diagnoses, never prescribes, never assigns acuity, and escalates any suspected emergency to 911.

•

Medications, Adherence and Pharmacogenomics

Why it matters

An 80-year-old with COPD (GOLD group E), HFrEF, type 2 diabetes and hypertension carries 6+ active medications written by three prescribers and filled at two pharmacies. No single system holds the whole list. Primary care's chart shows what primary care wrote. The independent pulmonologist's EHR holds the inhalers. The hospital portal holds what was started at discharge and never stopped. The failure this domain fixes is concrete: an antiplatelet started by cardiology sits alongside a proton-pump inhibitor added months earlier by another prescriber, and neither system knows the patient's CYP2C19 genotype — so a CYP2C19 intermediate metabolizer takes clopidogrel whose activation is blunted twice over, by genotype and by interaction. Nobody sees both facts on one page because the genotype lives in a lab report and the PPI lives in a pharmacy claim. Meanwhile the adult child acting as care collaborator is reconciling two inhalers that turn out to be the same inhaled corticosteroid under two names, and guessing whether last week's counter rejection was a prior-authorization requirement or a formulary exclusion. One list, one reconciliation, and one place where refill history, PGx phenotype, Beers flag and pharmacy reject code sit together — that is the entire point of this domain. Non-diagnostic throughout: it organises and explains, never prescribes.

What this domain holds

Data element	FHIR R4	Code system	Note
Active medication order (prescription)	`MedicationRequest.medicationCodeableConcept; .status; .intent; .authoredOn`	`RxNorm — ingredient RXCUI plus SCD/SBD (semantic clinical/branded drug) term for the exact product; e.g. clopidogrel ingredient RXCUI 32968, omeprazole 7646, furosemide 4603, metformin 6809, metoprolol 6918`	Ingredient-level RXCUIs above are the ones stated with confidence; every RXCUI, SCD and SBD must be resolved and revalidated against the current RxNav/RxNorm release at load time. Nothing here is asserted as a final production code set.
Dose, route, frequency, PRN condition	`MedicationRequest.dosageInstruction.timing / .route / .doseAndRate / .asNeededCodeableConcept`	`SNOMED CT route of administration; UCUM units; timing per FHIR Timing (e.g. BID, QHS)`	Free-text sig is what actually arrives from most sources; structured dosage is frequently absent or partial. Show the sig verbatim alongside any parsed structure, and never silently 'correct' a sig.
Prescriber and prescribing specialty	`MedicationRequest.requester → PractitionerRole.practitioner / .specialty; Organization`	`NUCC Health Care Provider Taxonomy for specialty; NPI as Practitioner.identifier`	Displayed as a ROLE LABEL only in this view — 'cardiology', 'primary care', 'pulmonology'. Per Ardia's naming constraint no clinician name is rendered, and Sentinel cannot yet be relied on to strip a name that leaks through a free-text field.
Dispensing pharmacy and fill event	`MedicationDispense.performer.actor → Organization; .whenHandedOver; .quantity; .daysSupply`	`NDC 11-digit (labeler–product–package) for the dispensed package; NCPDP Provider ID / NPI for the pharmacy`	NDC is what identifies the physical pill the patient is holding — pill imprint, color, manufacturer. RxNorm identifies the concept. Both are needed: the caregiver's real question is 'is this white oval the same as the old pink round one?'
Refill history and refills remaining	`MedicationRequest.dispenseRequest.numberOfRepeatsAllowed; .initialFill; MedicationDispense history`	`NCPDP SCRIPT 2017071 RxFill / RxHistoryResponse; NCPDP Telecom D.0 paid claim`	Fill history from a medication-history network is the single highest-yield reconciliation source, because it is payer-and-pharmacy-observed rather than prescriber-asserted.
Adherence signal (proportion of days covered)	`Observation (derived) with locally-defined code + MeasureReport referencing the PQA measure`	`No LOINC exists for PDC. PQA adherence measures (diabetes medications, RAS antagonists, statins) as used in CMS Part D Star Ratings; ICD-10-CM Z91.14 for documented non-adherence`	PDC ≥ 0.80 is the conventional threshold. Be explicit in the UI that PDC is a claims-derived proxy for possession, not ingestion, and that 90-day mail-order fills, cash-pay purchases and samples distort it.
Patient-reported / OTC / supplement entries	`MedicationStatement.medicationCodeableConcept; .informationSource = Patient or RelatedPerson`	`RxNorm where a concept exists; otherwise free text flagged as unmapped`	OTC NSAIDs, antihistamines and supplements are invisible to every claim feed and are exactly the items that cause harm in this patient. Provenance must distinguish patient-entered from payer-observed on the face of the row.
Allergy and intolerance	`AllergyIntolerance.code; .reaction.manifestation; .criticality; .verificationStatus`	`RxNorm ingredient or SNOMED CT substance for the agent; SNOMED CT for manifestation`	Intolerance mislabeled as allergy is a chronic data-quality problem and drives unnecessary second-line therapy in older adults.
Drug–drug interaction flag	`DetectedIssue.code; .severity; .implicated (→ MedicationRequest); .detail; .mitigation`	`HL7 v3 ActCode detected-issue values (e.g. drug-interaction and duplicate-therapy concepts); severity per FHIR DetectedIssue.severity`	Ardia would license interaction content (First Databank, Medi-Span or equivalent) rather than author it. The interaction knowledge base is not a differentiator and should not be presented as one.
Duplicate therapy / reconciliation conflict	`DetectedIssue with duplicate-therapy code; List (medication list) with two contributing sources; Provenance per entry`	`RxNorm ingredient-level collapse across brands; ATC class for therapeutic-duplication grouping`	The common real case here: an ICS/LABA from a hospital discharge and an ICS/LAMA/LABA single-inhaler triple from pulmonology, both active, double-dosing the corticosteroid.
Potentially inappropriate medication (deprescribing risk)	`DetectedIssue.code + .evidence; RiskAssessment where a rationale is carried`	`AGS Beers Criteria 2023 category (avoid; avoid with specific conditions; use with caution; drug–disease interaction; renal dosing) — a published guideline, not a code system; anchor conditions in ICD-10-CM (I50.22, N18.x, J44.9)`	Beers is a conversation-starter, not a rule. The view must render it as 'worth asking about at the next visit', never as 'stop this'. Scope-of-practice gate blocks any phrasing that reads as an instruction to discontinue.
Renal / hepatic dosing context	`Observation (lab) linked to the medication row`	`LOINC — creatinine 2160-0; eGFR (MDRD term 33914-3, with the current CKD-EPI 2021 LOINC term preferred and resolved at build); potassium 2823-3; HbA1c 4548-4`	Metformin, several DOACs and gabapentinoids are renally dosed; showing the current eGFR next to the dose is high-value and costs nothing.
PGx genotype (star allele diplotype)	`Observation per HL7 Genomics Reporting IG — genotype / haplotype / diplotype profiles; Observation.derivedFrom → DiagnosticReport`	`PharmVar star-allele nomenclature (CYP2C19 1, 2, 17; CYP2D6 1, 4, with copy-number state); underlying variants by dbSNP rsID (CYP2C19 2 = rs4244285; 17 = rs12248560; CYP2D6 4 = rs3892097); LOINC genetic-analysis terms from the Genomics Reporting IG panel — specific LOINC numbers to be pulled from the IG rather than fabricated here`	Diplotype, not raw variant, is the clinically actionable unit. CYP2D6 requires copy-number and hybrid-allele calling, which many panels do not do well — the assay's limitations must travel with the result.
PGx phenotype (metabolizer status)	`Observation (phenotype profile), Genomics Reporting IG`	`CPIC standardized phenotype terms — ultrarapid / rapid / normal / intermediate / poor metabolizer; CYP2C19 activity score where applicable`	Phenotype is assay- and allele-panel-dependent. A '1/1 normal metabolizer' call from a panel that does not test *17 or rarer alleles is a weaker statement than it looks; surface the tested-allele list.
PGx therapeutic implication and guideline recommendation	`Observation (therapeutic-implication profile) referencing MedicationRequest; .component with the medication (RxNorm) and the recommendation`	`CPIC guideline + evidence level (A/B); PharmGKB annotation; DPWG (Dutch Pharmacogenetics Working Group) recommendation where CPIC has none; FDA Table of Pharmacogenetic Associations`	CPIC level A examples relevant to this patient: CYP2C19–clopidogrel, CYP2C9/VKORC1–warfarin, CYP2D6–codeine/tramadol. For CYP2D6 and metoprolol, DPWG is the appropriate citation — attribute each recommendation to the body that actually issued it.
PGx test order, result and MolecuIQ linkage	`ServiceRequest → DiagnosticReport → Observation; DiagnosticReport.performer → Organization (reference lab)`	`CPT 81225 (CYP2C19 common variants), 81226 (CYP2D6 common variants), 81418 (drug-metabolism genomic sequence analysis panel); MolDX Z-code from the DEX registry appended to the CPT line`	This is the MolecuIQ join: the molecular result and the medication it governs become one object. The Z-code is what a MAC actually adjudicates against, and is the field most often missing on the claim.
Coverage and benefit for the drug	`Coverage.payor / .class (Part D plan, group, PBN); InsurancePlan + FormularyDrug per Da Vinci PDex US Drug Formulary IG`	`X12 270/271 eligibility; formulary tier, prior-authorization flag, step-therapy flag, quantity limit; Surescripts Real-Time Prescription Benefit for patient-specific cost`	Formulary status is the difference between a prescription and a medication. It is knowable before the patient reaches the counter and almost never shown to them.
Pharmacy claim outcome and point-of-sale reject	`ExplanationOfBenefit (CARIN Blue Button pharmacy profile); Claim / ClaimResponse`	`NCPDP Telecom D.0 reject codes — 70 product/service not covered, 75 prior authorization required, 79 refill too soon, 88 DUR reject; Part D PDE record via CMS Blue Button 2.0`	Pharmacy benefit does NOT flow through X12 837/835 — it flows through NCPDP D.0 and Part D PDE. Conflating the two is the most common modeling error in this domain.
Medical-benefit claim outcome for the PGx test	`Claim (professional) / ExplanationOfBenefit; ClaimResponse.item.adjudication`	`X12 837P submitted, X12 835 remittance; CARC (e.g. CO-50 not medically necessary, CO-96 non-covered, CO-197 authorization absent) with RARC (e.g. N115 decision based on an LCD)`	This is where the domain earns the Ardia differentiator: the genotype, the medication it governs, the claim, and the denial reason on one timeline.
Appeal / coverage-determination clock	`Task (appeal workflow) with due date; Communication for the plan notice`	`Medicare Advantage 60-day plan reconsideration window for a medical-benefit denial; Part D coverage determination — 72 hours standard, 24 hours expedited; redetermination window per plan notice`	A countdown is the single most useful thing on the page for a caregiver, and no clinical portal shows it. Dates come from the plan notice, not from Ardia's inference.
Part D coverage phase and out-of-pocket position	`ExplanationOfBenefit.total / .adjudication (patient responsibility); Coverage.costToBeneficiary`	`Part D PDE fields; Inflation Reduction Act annual out-of-pocket cap; Medicare Prescription Payment Plan (M3P) enrollment status`	Cost is an adherence variable in this population, not a footnote. A patient stops the inhaler in the month the deductible resets.
Pharmacy-administered immunizations	`Immunization.vaccineCode; .occurrenceDateTime; .performer → Organization (pharmacy)`	`CVX for the vaccine, MVX for manufacturer, NDC for the administered product; billed under the pharmacy benefit for most Part D vaccines`	Included because for a COPD patient the pneumococcal, influenza, RSV and COVID history is a medication-adjacent care-gap item that lives in the pharmacy record, not the clinic record.
Source and trust provenance for every row	`Provenance.agent / .entity / .recorded on each MedicationRequest, MedicationDispense and Observation`	`Source system type — EHR FHIR API, medication-history network, PBM/PDE claim, patient-entered, caregiver-entered`	Every row must be able to answer 'who said so, when, and how sure are we'. Reconciliation without provenance produces a confident, wrong list.
Caregiver consent scope	`Consent.provision.actor (RelatedPerson) / .provision.data / .provision.period / .provision.type`	`FHIR Consent; role labels only (adult child / care collaborator)`	Scope must be per-domain and revocable by the patient without a support ticket. A caregiver granted medication access is not thereby granted PGx or cost access — genetic and financial data need separate, explicit grants.

FHIR R4 with US Core 6.1+ — MedicationRequest, MedicationDispense, MedicationStatement, AllergyIntolerance, DetectedIssue, Observation, Immunization, Coverage, ExplanationOfBenefit, Consent, Provenance, TaskHL7 Genomics Reporting Implementation Guide — genotype, haplotype, diplotype, therapeutic-implication and medication-recommendation profilesRxNorm (ingredient RXCUI, SCD, SBD) and NDC 11-digit for the dispensed packageSNOMED CT (route, substance, reaction manifestation) and ICD-10-CM (J44.1, J44.9, I50.22, E11.9, I10, Z79.02, Z79.84, Z79.899, Z91.14)LOINC for the labs that gate dosing — creatinine 2160-0, eGFR (33914-3 MDRD, CKD-EPI 2021 term preferred), potassium 2823-3, HbA1c 4548-4 — plus Genomics Reporting IG LOINC terms for PGxCPT 81225 (CYP2C19), 81226 (CYP2D6), 81418 (drug-metabolism panel), with a MolDX DEX Z-code on the claim lineNCPDP SCRIPT 2017071 (e-prescribing, RxHistoryResponse) and NCPDP Telecom D.0 (point-of-sale adjudication, reject codes 70/75/79/88)X12 270/271 eligibility, 837P claim, 835 remittance, with CARC (CO-50, CO-96, CO-197) and RARC (N115) reason codesDa Vinci PDex US Drug Formulary IG; CARIN Blue Button pharmacy ExplanationOfBenefit; CMS Blue Button 2.0 Part D PDE; Da Vinci PDex for payer-to-payer and member dataSurescripts Medication History and Real-Time Prescription BenefitCPIC guidelines and phenotype terminology; PharmVar star-allele nomenclature; PharmGKB annotations; DPWG recommendations; FDA Table of Pharmacogenetic AssociationsAGS Beers Criteria 2023 for potentially inappropriate medication use in older adultsPQA adherence measures (PDC) as operationalised in CMS Part D Star Ratings; Medication Therapy Management / Comprehensive Medication Review eligibilitySMART on FHIR / OAuth 2.0 for EHR app authorization; FHIR Consent for caregiver scopingCVX / MVX for pharmacy-administered immunizations

Synthetic sample — no real patient data, no names

row_type	medication	rxnorm_ingredient	product_code	sig	indication_icd10
medication	clopidogrel 75 mg oral tablet	32968	RxNorm SCD for the 75 mg oral tablet; NDC 11-digit resolved at dispense	Take 1 tablet by mouth daily	Z79.02 long term (current) use of antithrombotics/antiplatelets
medication	omeprazole 20 mg delayed-release capsule	7646		Take 1 capsule by mouth daily before breakfast
pgx_result
pgx_result
pgx_claim
medication	inhaled corticosteroid / LAMA / LABA single-inhaler triple therapy, 1 inhalation daily				J44.9 COPD, unspecified
medication	inhaled corticosteroid / LABA metered-dose inhaler, 2 inhalations twice daily				J44.1 COPD with (acute) exacerbation
medication	furosemide 40 mg oral tablet	4603		Take 1 tablet by mouth every morning; take an extra tablet for a 3 lb weight gain per the heart-failure plan	I50.22 chronic systolic (congestive) heart failure
medication	metformin 1000 mg oral tablet	6809		Take 1 tablet by mouth twice daily with meals	E11.9 type 2 diabetes mellitus without complications; Z79.84 long term use of oral hypoglycemic drugs
medication	glimepiride 4 mg oral tablet	RxNorm ingredient RXCUI for glimepiride — verify in RxNav
medication	naproxen 220 mg, over the counter, taken most days for knee pain	RxNorm ingredient RXCUI for naproxen — verify in RxNav
adherence
benefit_position
immunization

What Ardia adds here

Epic MyChart shows the medication list one health system holds; Apple Health shows what the patient typed plus what connected organisations release. Both are clinical-only. Neither tells this patient that the triple-therapy inhaler her pulmonologist prescribed is sitting unfilled behind an NCPDP reject 75 prior-authorization requirement, that a Part D coverage determination has a 72-hour clock, or that the pharmacogenomic panel that produced her CYP2C19 intermediate-metabolizer result was denied CO-50 with RARC N115 and has a 60-day Medicare Advantage reconsideration window still open. Ardia's contribution is the join: the RxNorm product, the NDC actually dispensed, the PGx diplotype that governs it, the Beers flag, and the pharmacy or medical-benefit outcome as one row with one timeline. Be honest about the rest. Ardia would license interaction and Beers content, not author it. It does not generate the genotype — a reference lab does. It cannot see cash-pay, OTC or sample medications. And it changes nothing clinically without a prescriber acting.

Risks in this domain

Re-identification: a medication list is a strong quasi-identifier. HIPAA Safe Harbor removes names and dates but not drug names — an 80-year-old on a specific triple-therapy inhaler plus a specific antiplatelet plus a sulfonylurea is close to unique in a small geography. De-identification of this domain by field removal alone does not work.
Sentinel's name-detection gap: Sentinel de-identification does not reliably redact plain personal names today. Medication data is dense with free text — sig strings, pharmacy notes, prescriber comments, patient-entered entries — where a name will leak. This is a hard gating dependency, not a backlog item.
42 CFR Part 2: buprenorphine, methadone or naltrexone dispensed by a Part 2 program carries redisclosure restrictions distinct from HIPAA. A merged medication list assembled from a Part 2 source cannot be freely redisclosed to a caregiver, another provider or a payer without consent that meets Part 2's requirements. Filtering these out silently is also wrong — it produces an incomplete list a clinician may rely on.
GINA: PGx results are genetic information. GINA covers health insurance and employment discrimination — it does NOT cover life, long-term care or disability insurance. For an 80-year-old, long-term-care underwriting is precisely the live exposure, and a caregiver-visible genotype increases the surface.
Caregiver access without consent: adult-child access must be granted by the patient, scoped per domain, time-bounded and revocable without a support ticket. Medication access must not silently confer PGx or cost access. The abusive or coercive family member is a real threat model in elder care, not an edge case.
Elder financial exploitation: this domain exposes drug costs, Part D coverage phase, out-of-pocket position and plan identifiers — a high-value target for pharmacy and Medicare scam calls. No payment instrument should ever be collected in this view, and cost data should be the most tightly scoped element in the record.
Safety of surfacing before clinician review: showing a patient 'your genotype means clopidogrel may not work' can cause self-discontinuation of an antiplatelet, with catastrophic consequences. PGx and interaction findings must be released only after the ordering or prescribing clinician has seen them, framed as questions for that clinician, and never as instructions. The human_in_the_loop and scope_of_practice gates exist for exactly this.
Non-diagnostic boundary: any AI explanation runs on Google Gemini (gemini-flash-lite), not Claude, behind six deterministic gates — de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop. A failed gate withholds the answer entirely rather than degrading it. The model must never name a dose, a taper or a substitution.
Incomplete list creating false reassurance: OTC NSAIDs, supplements, samples, cash-pay generics and $4-list fills produce no claim and no FHIR record. A confident-looking reconciled list that omits the naproxen is more dangerous than an obviously partial one. Completeness must be stated, not implied.
Alert fatigue and false positives: interaction and Beers engines over-fire. A caregiver shown eleven flags will stop reading before the one that matters. Ranking, suppression logic and clinician-tunable thresholds are a safety requirement, not a UX preference.
Data latency and staleness: Part D PDE data lags weeks; a discontinued medication persists in claims-derived views. Every row needs a visible as-of date and source, or the view will show a drug the patient stopped a month ago.
PAMA 2027 exposure of the upstream result: the PGx codes that feed this domain (CPT 81225, 81226, 81418) sit on the Clinical Laboratory Fee Schedule and face the scheduled PAMA rate reductions resuming in 2027. If the panel becomes uneconomic to run, the CYP2C19 result that would have flagged this patient's antiplatelet never gets ordered. This domain's most valuable field is the one most exposed to the rate cliff.
Genetic data retention: PGx results are lifelong and immutable. A retention and deletion policy that works for a claim does not work for a genotype, and deletion obligations under state genetic-privacy laws differ from HIPAA.

Build status.

Nothing in this domain is built. It is a designed view, not a shipped feature. Ardia Precision Health today has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data. Every code, row and phenotype above is synthetic and illustrative; no patient, clinician or family member is named anywhere, by design. Codes stated with confidence are still to be revalidated against current RxNorm, LOINC, CPT and the HL7 Genomics Reporting IG at build time — where a specific value was uncertain it is described rather than fabricated. What has to happen before a single real medication row can be held, roughly in order: (1) fix Sentinel's name-detection gap — it does not reliably redact plain personal names today, and this domain is dense with free-text sig and pharmacy fields where a name will leak; this is the gating dependency and no PHI can be ingested until it closes; (2) execute a BAA with each covered entity or business-associate source before any connection is opened; (3) obtain patient authorization and, separately, Part 2-compliant consent for any substance-use-treatment source; (4) reach the medication-history and real-time-benefit networks, which require an eligible entity, contracts and patient consent — these are commercial and legal gates, not engineering ones; (5) register for CMS Blue Button 2.0 to reach Part D PDE data, and complete SMART on FHIR app registration per EHR; (6) license interaction and Beers content; (7) build and independently review the six gates on the Gemini path, with evidence that a failed gate withholds the answer entirely. Until every one of those is done, this remains a design artifact and should be described as one to anyone who sees it.

•

Encounters, Procedures and Surgeries

Why it matters

For an 80-year-old with GOLD group E COPD and HFrEF, the encounter timeline is where the record actually breaks. Over a year they may have five to nine encounters across an ED, an inpatient stay, an independent pulmonology office, a hospital outpatient department, a telehealth visit and a DME supplier. Each site holds its own fragment. Nobody holds the sequence. The concrete failure is the discharge-to-followup gap: the patient leaves the hospital after a COPD exacerbation with a discharge summary the adult child never receives, a transitional care management visit that must happen within 7 or 14 days, a home oxygen order that has not yet shipped, and a medication list that changed during the stay. Two weeks later nobody in the family can answer three questions - did the follow-up visit happen, did the oxygen arrive, and was anything from that stay denied. The second failure is surgical history: before a bronchoscopy or a cataract procedure, the anticoagulation history, the prior ICD implant and its UDI, and the prior anaesthesia record live in three different charts. A care collaborator is asked to recite them from memory in a pre-op phone call and gets them wrong.

What this domain holds

Data element	FHIR R4	Code system	Note
Encounter identifier and type	`Encounter.identifier, Encounter.type`	`SNOMED CT encounter type; CPT/HCPCS E&M level on the professional claim (e.g. 99213/99214 office, 99281-99285 ED)`	One row per encounter, keyed by source system plus local id. The same physical visit often arrives twice - once as a clinical Encounter from FHIR, once as an 837 claim - and must be deduplicated, not double-counted.
Encounter class (setting)	`Encounter.class`	`HL7 v3 ActCode: AMB ambulatory, EMER emergency, IMP inpatient, OBSENC observation, VR virtual, HH home health`	Drives the timeline lane. OBSENC vs IMP is financially decisive for a Medicare patient - observation is Part B, does not count toward the 3-day inpatient stay for SNF coverage, and is a common source of surprise cost.
Place of service	`Encounter.location.location; on the claim, ExplanationOfBenefit.item.locationCodeableConcept`	`CMS Place of Service codes: 11 office, 19/22 outpatient hospital, 21 inpatient hospital, 23 ED, 02 telehealth other than home, 10 telehealth in patient's home, 31 SNF, 12 home`	POS 10 vs 02 changes the telehealth payment rate and is a recurring denial cause after the post-PHE rule changes.
Encounter period and length of stay	`Encounter.period.start, Encounter.period.end, Encounter.length`	`ISO 8601 instants; UCUM for length units`	Length of stay is derived, never patient-asserted. Timezone normalisation matters - a midnight admission crossing days changes the LOS and the payment window.
Admission source	`Encounter.hospitalization.admitSource`	`NUBC point-of-origin codes; HL7 admit-source ValueSet`	Distinguishes ED-to-inpatient conversion from a direct admit from an office - a different clinical and billing story.
Discharge disposition	`Encounter.hospitalization.dischargeDisposition`	`NUBC Patient Discharge Status: 01 home/self-care, 03 SNF, 06 home health, 30 still a patient, 62 inpatient rehab`	The most load-bearing field for the discharge-to-followup gap. Disposition 06 means a home health agency owes a start-of-care visit within roughly 48 hours; the view can show whether one was ever recorded.
Encounter diagnoses, ranked, with present-on-admission	`Encounter.diagnosis.condition, Encounter.diagnosis.use, Encounter.diagnosis.rank; Condition.code`	`ICD-10-CM (J44.1 COPD with acute exacerbation, I50.23 acute-on-chronic systolic heart failure, E11.9 type 2 diabetes, I10 essential hypertension); SNOMED CT for the clinical Condition`	Principal, secondary and admitting are different uses of the same code set. POA indicators drive hospital-acquired-condition logic and ride on the institutional claim, not usually the FHIR feed.
DRG assignment for the inpatient stay	`Carried on Claim/ExplanationOfBenefit as supportingInfo or the C4BB DRG extension in R4`	`MS-DRG (190/191/192 COPD with MCC/CC/without; 291/292/293 heart failure and shock)`	Explains why the plan paid a fixed amount regardless of length of stay - the answer when a family asks why a 2-day and a 5-day stay cost the same.
Institutional line detail	`ExplanationOfBenefit.item (institutional profile)`	`UB-04 revenue codes (0450 emergency room, 0762 observation room, 0410 respiratory services); HCPCS on the line`	The layer that shows a family the ED facility fee sitting alongside the ED physician fee - two claims, two cost shares, one visit.
Performing and attending role	`Encounter.participant.type, Encounter.participant.individual to PractitionerRole.specialty, Procedure.performer.function`	`NUCC Health Care Provider Taxonomy for specialty; HL7 ParticipationType for role`	Ardia stores the PractitionerRole reference but renders ONLY the specialty label - pulmonology, cardiology, hospitalist. No clinician names appear anywhere, consistent with the site-wide removal of human names.
Facility and organisation	`Encounter.serviceProvider to Organization; Encounter.location to Location`	`NPI Type 2 organisational identifier, NUCC taxonomy, CLIA number where a lab is involved`	Rendered as the regional hospital, the independent pulmonology practice, the reference lab. Facility identity is retained internally for network-status and claim matching.
Procedure performed (professional)	`Procedure.code, Procedure.category, Procedure.performedDateTime or performedPeriod`	`CPT (31622 diagnostic bronchoscopy, 94060 spirometry with bronchodilator, 71260 CT thorax with contrast, the 33249-family ICD system insertion), HCPCS Level II for supplies and DME, SNOMED CT procedure concept as the clinical anchor`	CPT descriptors are AMA-licensed content. Displaying them requires an AMA licence - a real cost line for this domain, not a footnote.
Inpatient procedure (facility coding)	`Procedure.code, second coding slice`	`ICD-10-PCS, 7-character structure (section, body system, root operation, body part, approach, device, qualifier) - e.g. the 0BJ08ZZ-family inspection of the tracheobronchial tree, via natural or artificial opening endoscopic`	ICD-10-PCS appears only on inpatient institutional claims. The same bronchoscopy carries a CPT code on the professional claim and a PCS code on the facility claim; both must resolve to one timeline event.
Body site and laterality	`Procedure.bodySite`	`SNOMED CT body structure; CPT modifiers LT, RT, 50 on the claim line`	Laterality mismatch between the clinical record and the claim is both a common denial trigger and a genuine safety signal. Surfaced as a discrepancy between two sources, never as a clinical finding.
Anaesthesia and sedation record summary	`Procedure (anaesthesia category), Procedure.usedCode, linked Encounter.type`	`CPT anaesthesia code range with physical status modifiers P1-P6; ASA physical status classification`	For an 80-year-old, prior sedation tolerance is the question every pre-op call asks. Surfaced as recorded history only - never as clearance or a recommendation.
Procedure outcome and complications	`Procedure.outcome, Procedure.complication, Procedure.complicationDetail`	`SNOMED CT; ICD-10-CM where a complication was coded as a diagnosis`	Sparsely populated in real feeds. Where absent the view must say not recorded in the received data, rather than implying an uncomplicated course.
Implanted device and UDI	`Device.udiCarrier.deviceIdentifier, Device.udiCarrier.carrierHRF, Device.type, Device.status; Procedure.usedReference to Device`	`GS1 or HIBCC UDI-DI resolved against the FDA GUDID; SNOMED CT device type; HCPCS for the billed device`	The UDI-DI is safe to display; the UDI-PI (serial and lot) is a direct identifier held as restricted PHI. This is the field that answers what exactly is in my parent's chest before an MRI.
Device advisory and recall status	`Device.status plus a Flag on the patient record`	`FDA GUDID lookup and the FDA recall database; no clinical code system`	Ardia would surface that a manufacturer advisory exists and link the FDA notice. It would not interpret the advisory or advise on replacement - that is a cardiology decision.
Prior authorisation status for the procedure	`ServiceRequest, Task, Claim with use=preauthorization, ClaimResponse.preAuthRef`	`X12 278 request and response; the CPT/HCPCS of the requested service; plan-specific review reason codes`	A Medicare Advantage plan can require prior auth on a bronchoscopy or advanced imaging. Pended for medical necessity review, day 9 of 14 is information no clinical portal shows the family.
Eligibility snapshot at the moment of service	`CoverageEligibilityRequest, CoverageEligibilityResponse, Coverage`	`X12 270 inquiry and 271 response; service type codes; in-network vs out-of-network indicator`	Captured as of the encounter date, not today. Answers whether the plan was active and the facility in network on that date - the root cause of a large share of surprise bills.
Claim and remittance for the encounter	`Claim, ClaimResponse, ExplanationOfBenefit.item.adjudication`	`X12 837P professional and 837I institutional outbound; X12 835 remittance inbound; CARC and RARC on the adjudication reason`	This is the join that makes Ardia different: the 837 claim line carries the same CPT as Procedure.code, so the clinical event and its money sit on one row.
Denial reason and appeal clock	`ExplanationOfBenefit.item.adjudication.reason, ClaimResponse.item.adjudication`	`CARC (CO-50 not deemed a medical necessity, CO-197 precertification or authorisation absent, CO-96 non-covered charge, CO-45 charge exceeds fee schedule) with RARC qualifiers such as N130; the LCD or NCD policy identifier where coverage policy is cited`	Ardia computes days remaining against the deadline that actually applies - 60 days for a Medicare Advantage plan reconsideration - and shows the countdown beside the clinical event. Calendar arithmetic only, never legal advice.
Patient financial responsibility for the encounter	`ExplanationOfBenefit.item.adjudication (deductible, coinsurance, copay, patientpay categories), ExplanationOfBenefit.total`	`CARC patient-responsibility group PR (PR-1 deductible, PR-2 coinsurance, PR-3 copay); C4BB adjudication categories`	Separates what the plan denied from what the patient actually owes - two different letters that arrive looking identical.
Discharge summary and encounter documents	`DocumentReference, Composition (C-CDA discharge summary), Encounter.reasonReference`	`LOINC document type codes for discharge summary, operative note, procedure note, ED note; C-CDA R2.1 templates`	The operative note and the discharge summary are the two documents families most often cannot find. Stored as documents; any AI summary of them runs behind the six gates.
Discharge instructions and follow-up orders	`ServiceRequest, Task, CarePlan.activity`	`SNOMED CT for the ordered activity; CPT 99495/99496 for the transitional care management visit that should follow`	Turning free-text discharge instructions into trackable items is the highest-value transformation in this domain and the most exposed to LLM error, so every item stays linked to its source sentence for human verification.
Follow-up appointment and the measured gap	`Appointment.start, Appointment.status, Encounter.appointment`	`No code system - a derived interval in days between Encounter.period.end and the next Appointment or Encounter`	Displayed as a fact: 19 days since discharge, no follow-up encounter recorded. It is not a risk score and carries no acuity judgement.
Post-acute services and DME	`Encounter with class HH, ServiceRequest, DeviceRequest`	`HCPCS Level II E-series for stationary and portable oxygen equipment; home health revenue codes; OASIS assessment exists but is agency-held and not exposed`	Home oxygen for a GOLD group E patient requires documented qualifying saturation on room air - a coverage rule that routinely delays delivery, and the delay is invisible in every clinical portal.
Prior 30-day encounter context	`Derived across the longitudinal Encounter set using Encounter.period and Encounter.class`	`No code system - a count and a set of links`	Deliberately NOT a readmission risk score. Ardia does not compute LACE, HOSPITAL or any acuity index; that would be a clinical judgement it is not permitted to make. It shows raw facts and leaves the judgement to a clinician.
Encounter-linked molecular or genomic order	`ServiceRequest, Specimen, DiagnosticReport, Procedure for the collection`	`CPT PLA codes and the 81xxx molecular series; LOINC for the result; MolDX Z-code identifier registered through the DEX registry`	Links the pillars: a bronchoscopy encounter yields a specimen that yields a molecular test whose payment depends on a Z-code and, from 2027, on a PAMA-reset rate. The encounter row is where that chain begins.
Provenance of every row	`Provenance.agent, Provenance.entity, Provenance.recorded, Meta.source`	`No clinical code system - source system identifier plus retrieval timestamp`	Every field shows which of the five sources it came from and when it was last refreshed. Conflicting values from two sources are shown side by side, never silently merged.
Care collaborator consent scope	`Consent.provision.type, Consent.provision.class, Consent.provision.period, Consent.provision.actor`	`HL7 Consent policy and scope ValueSets; HL7 privacy labels`	The adult child's access is scoped per domain and per time window. Encounter-level consent can permit coverage and appointment visibility while excluding a sensitive encounter entirely.
Sensitive-encounter segmentation flag	`Meta.security label on Encounter and Procedure`	`HL7 Confidentiality codes and ActCode privacy labels (ETH substance-use related, PSY, HIV, SEX)`	42 CFR Part 2 encounters must be segmentable and must not be redisclosed without specific consent. Most source feeds do not label reliably, so the safe default is to withhold any encounter whose provider taxonomy indicates a Part 2 programme.

FHIR R4 - Encounter, Procedure, Device, DeviceRequest, ServiceRequest, Appointment, Task, DocumentReference, Composition, Coverage, CoverageEligibilityRequest/Response, Claim, ClaimResponse, ExplanationOfBenefit, CareTeam, PractitionerRole, Organization, Location, Consent, Provenance, FlagUS Core 6.1/7.0 - US Core Encounter, US Core Procedure, US Core DocumentReference profilesCARIN Blue Button (C4BB) ExplanationOfBenefit profiles - Inpatient Institutional, Outpatient Institutional, Professional/NonClinicianDa Vinci PDex, and Da Vinci Prior Authorization Support (PAS) for the 278 workflowICD-10-CM for diagnoses; ICD-10-PCS for inpatient proceduresCPT and HCPCS Level II for professional procedures, DME and supplies - AMA licence required to display descriptorsSNOMED CT for clinical procedure, body structure, device type and outcome conceptsLOINC for document types and for the results an encounter generatesMS-DRG grouping; NUBC revenue codes, point-of-origin codes and patient discharge status codes (UB-04)CMS Place of Service code setX12 5010 - 270/271 eligibility, 276/277 claim status, 278 prior authorisation, 837P and 837I claims, 835 remittance adviceCARC and RARC claim adjustment and remittance advice remark code setsMedicare LCD and NCD coverage policy identifiers; MolDX Z-codes via the DEX registry for molecular tests generated by an encounterFDA UDI and GUDID, with GS1 and HIBCC device identifiersNUCC Health Care Provider Taxonomy; NPI Type 1 and Type 2C-CDA R2.1 discharge summary, operative note and procedure note templatesHL7 Confidentiality and privacy security labels for 42 CFR Part 2 segmentationSMART on FHIR and OAuth 2.0; CMS Interoperability and Prior Authorization final rule (CMS-0057-F) APIs

Synthetic sample — no real patient data, no names

row_type	encounter_id	class	place_of_service	facility	when
encounter	SYNTH-ENC-0001	EMER (HL7 ActCode)	23 - emergency room, hospital	regional hospital, in-network	T-58 days 21:40 to T-57 days 03:15
encounter	SYNTH-ENC-0002	IMP inpatient	21 - inpatient hospital		T-57 days to T-53 days, length of stay 4 days
procedure					T-55 days
coverage_event
encounter	SYNTH-ENC-0003	HH home health	12 - home		T-51 days, start of care
gap_alert
encounter	SYNTH-ENC-0004	AMB ambulatory	22 - on-campus outpatient hospital		T-31 days
claim_and_remittance
encounter	SYNTH-ENC-0005	VR virtual	10 - telehealth provided in the patient's home		T-12 days
surgical_history					approximately 4 years ago
surgical_history					approximately 7 years ago

What Ardia adds here

Every other patient-360 shows the clinical event. Epic MyChart shows the bronchoscopy and the CT report but not the 837, the 835, the CARC, or the appeal clock, and shows only the health systems on that instance, so the independent pulmonologist and the DME supplier are missing. Apple Health shows almost no encounter or procedure data beyond what a linked portal exposes. Health Gorilla, Particle and Zus aggregate clinical records across networks well, and Ardia would be no better at that; they simply are not designed to put the denial on the same row. Ardia's addition is the join: CPT 71260 as Procedure.code, the 837 line that carried it, and the 835 that denied it CO-50 become one timeline entry with 44 days left to appeal. Honestly, Ardia adds nothing to record retrieval itself, and would be worse than Epic at real-time inpatient status. The differentiator is the coverage lane, the discharge-gap arithmetic, and consent-scoped collaborator access. None of it is built.

Where the data comes from.

Five real sources, in descending order of reliability and ascending order of difficulty. (1) Payer claims data - the 837 the provider sent and the 835 the plan returned, reachable through the CMS Interoperability and Patient Access / CMS-0057-F Patient Access and Prior Authorization APIs for a Medicare Advantage plan, or through a clearinghouse relationship. This is the most complete encounter census, because every billed encounter appears regardless of which health system delivered it, and it is the only source carrying denial and appeal data. It lags 14 to 45 days. (2) Hospital and clinic EHRs via SMART on FHIR US Core - accurate, real-time, and structurally rich, but scoped to one health system, so the independent pulmonologist is invisible from the hospital's API. Medium difficulty per connection, high difficulty at scale. (3) National networks - Carequality, eHealth Exchange, TEFCA QHINs, or a commercial aggregator - for cross-system C-CDA documents; document-centric, so procedures arrive as narrative that needs parsing. (4) DME suppliers and home health agencies - largely portal-only, often no API at all, frequently fax-era; realistically patient-entered or scraped with consent. (5) Patient and care-collaborator entry for remote surgical history, flagged as unverified. The hard engineering problem is not any single connection - it is deduplicating the FHIR Encounter and the claim that describe the same visit.

Risks in this domain

Re-identification: an encounter timeline is a quasi-identifier. Admission dates plus a named facility plus a rare procedure plus an 80-year-old age band can single out one person even with every direct identifier stripped. Date-shifting would break the appeal-deadline arithmetic that is the whole point of this domain, so shifting is not an available mitigation here.
Sentinel does not reliably redact plain personal names today. Discharge summaries, operative notes and free-text discharge instructions are dense with clinician, family and facility names. Until name detection is fixed, no real note text can enter this domain. This is a hard gating dependency, not a backlog item.
42 CFR Part 2: an encounter at a substance-use treatment programme carries redisclosure restrictions far stricter than HIPAA, and toxicology results attach to exactly these encounters. Source feeds rarely label them reliably, so the safe default is to withhold any encounter whose provider taxonomy or facility type indicates a Part 2 programme, and to state the resulting incompleteness openly rather than paper over it.
Safety of surfacing before a clinician has seen it: an operative note, a coded complication, or a pathology-linked procedure result can reach the patient and the adult child before anyone has explained it. Information Blocking rules push toward immediate release; elder-care reality argues for framing. Ardia's position is release with plain-language framing plus an explicit 'your clinician has not yet reviewed this with you' state, and never an interpretation.
Caregiver access without consent: the adult child is the most likely unauthorised viewer, usually well-intentioned and in possession of the parent's device passcode. Consent must be per-domain, time-bounded, revocable by the patient alone, and the patient must be able to see who viewed what and when.
Elder financial exploitation: an encounter timeline annotated with denials, balances and appeal deadlines is a map of an older adult's financial pressure points. It can be used to pressure a parent into ceding decision-making, or by a scammer posing as a hospital billing office. Every dollar figure needs visible provenance and a standing statement that Ardia never requests payment.
Weak legal protection for procedure history: GINA covers genetic information, but nothing equivalent covers surgical and implant history, which carries its own underwriting and employment implications. The encounter domain is therefore less legally protected than the genomics domain sitting beside it, and should not be treated as lower risk simply because it feels more mundane.
Wrong inference from incomplete data: a missing follow-up encounter may mean the visit happened at a practice that does not share data, not that it was skipped. Presenting an absence as a gap without naming which sources were queried and when is a genuine harm vector for an anxious family.
Acuity creep: the strongest product pull in this domain is to add a readmission risk score. Doing so would make Ardia clinical decision support, would likely bring it inside regulated device-function territory, and would break the non-diagnostic commitment outright. The design refuses it deliberately.
Licensing exposure independent of privacy: CPT descriptors are AMA-licensed and MS-DRG grouper logic is separately licensed. Displaying either without a licence is a legal risk that has nothing to do with PHI and is easy to overlook.

Build status.

Nothing in this domain exists today. There is no encounter ingestion pipeline, no 837/835 parser, no 278 tracker, no timeline UI, and no deduplication logic between the FHIR Encounter and the claim describing the same visit. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data. Every row above is synthetic and was written for this design; the patient is unnamed by construction and no clinician, facility or family name appears anywhere. Any AI explanation of an encounter or a denial would run on Google Gemini (gemini-flash-lite), not Claude, behind six deterministic gates - de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop - where a failed gate withholds the answer entirely rather than degrading it. What is needed first, in order: (1) fix Sentinel's plain-name detection gap, since discharge summaries and operative notes are name-dense and this domain is unusable without it; (2) execute a BAA with a covered entity or business associate before a single real encounter is held; (3) obtain an AMA CPT licence for descriptor display; (4) build the FHIR-to-claim deduplication layer, which is the hard engineering problem here; (5) build consent scoping before any second person can see a first person's timeline. Until all five are done this is a designed view demonstrated on synthetic data only.

•

Labs, Imaging and Diagnostics

Why it matters

An 80-year-old with COPD (GOLD group E), HFrEF, type 2 diabetes and hypertension generates results in four disconnected places: the hospital portal holds the chest CT and the echo, the independent pulmonologist holds spirometry and DLCO, a reference lab holds the chemistry, CBC, HbA1c and NT-proBNP, and a molecular lab holds an alpha-1 antitrypsin genotype nobody has looked at since it resulted. The adult child acting as care collaborator sees four logins, four PDF conventions, four reference-range formats, and no way to tell that creatinine has drifted from 1.1 to 1.6 mg/dL across three different labs — because each portal shows only its own draws, and each lab's "normal" flag is computed against its own range. Meanwhile the diuretic was increased, the potassium was drawn at a lab that is out of network, and the CT that documented the exacerbation was denied CO-50 with a 60-day appeal clock nobody started. The failure this domain fixes is not "the patient cannot see a number." It is that nobody can see the same number twice in a row, in order, next to the thing that caused it and the coverage decision that followed it.

What this domain holds

Data element	FHIR R4	Code system	Note
Result value + unit (quantitative)	`Observation.valueQuantity (value, unit, system=http://unitsofmeasure.org, code)`	`LOINC for the analyte; UCUM for the unit`	UCUM normalization is mandatory before any cross-lab trend: one lab reports creatinine in mg/dL, another in umol/L. Store both the as-reported value and the normalized value; never overwrite the source.
Analyte / test identity	`Observation.code`	`LOINC — e.g. 2160-0 creatinine serum/plasma, 4548-4 HbA1c, 718-7 hemoglobin, 2823-3 potassium, 2951-2 sodium, 3094-0 BUN, 33762-6 NT-proBNP, 2345-7 glucose, 6690-2 leukocytes, 777-3 platelets, 33914-3 eGFR (MDRD)`	Local lab codes are the norm in real feeds; LOINC must be mapped, and the mapping's provenance recorded. Unmapped local codes are displayed but excluded from trending.
Panel membership (panel vs single)	`Observation.hasMember / DiagnosticReport.result; Observation.category=laboratory`	`LOINC panel codes — e.g. 24323-8 comprehensive metabolic panel, 58410-2 CBC with differential panel`	A CMP is one order, one specimen, one charge and fourteen Observations. Rendering fourteen separate rows is the single most common reason a patient portal feels unreadable. Collapse to the panel, expand on demand.
Reference range and interpretation flag	`Observation.referenceRange (low, high, type, appliesTo, age); Observation.interpretation`	`HL7 v3 ObservationInterpretation (N, H, L, HH, LL, A, AA); v2 abnormal-flags where the source is HL7 v2 ORU^R01`	Ranges are lab-specific, method-specific, and sometimes age- or sex-specific. Ardia must render the range that shipped with the result, never a range of its own invention — inventing a range is practicing medicine.
Delta / trend across draws	`Derived Observation with Observation.derivedFrom pointing at each source Observation; Provenance on the derived value`	`No standard code system for delta itself; the derived Observation carries the analyte's LOINC and a UCUM unit`	Ardia-computed, therefore Ardia-owned. Deltas only computed when analyte LOINC, UCUM unit and specimen type match; a method change (e.g. IDMS-traceable vs older creatinine assay) breaks the series and must be shown as a break, not smoothed over.
Specimen and collection time	`Specimen.type, Specimen.collection.collectedDateTime; Observation.effectiveDateTime vs Observation.issued`	`SNOMED CT specimen concepts (serum, plasma, whole blood, urine, arterial blood)`	Collected-time and issued-time differ by hours to days and drive the whole ordering of the timeline. Portals routinely show issued-time and mislead. Show collected-time as the timeline anchor.
Performing lab, order and requester	`Observation.performer, ServiceRequest.requester, ServiceRequest.performer, DiagnosticReport.performer`	`CLIA number as an Identifier; NPI as Practitioner/Organization identifier; role labels only in the UI`	Three prescribers across two pharmacies and four result sources means every result needs a visible 'who ordered this, who ran it.' Displayed as role labels (primary care, pulmonology, cardiology, reference lab).
Arterial blood gas set (pulmonary pillar)	`Observation set under one DiagnosticReport; Observation.category=laboratory`	`LOINC — 11558-4 pH arterial, 2019-8 pCO2 arterial, 2703-7 pO2 arterial, 2708-6 oxygen saturation arterial; pulse-ox saturation is a different LOINC and must not be trended against ABG saturation`	Conflating pulse-oximetry SpO2 with arterial SaO2 on one line is a real and dangerous charting error. Separate series, separate axes, explicit labels.
Pulmonary function testing	`Observation (FEV1, FVC, FEV1/FVC, DLCO, % predicted) grouped in a DiagnosticReport; ServiceRequest for the order`	`LOINC spirometry and diffusion-capacity codes (FEV1, FVC, FEV1/FVC ratio, DLCO corrected for hemoglobin) — LOINC has distinct codes for pre- vs post-bronchodilator and for measured vs % predicted; CPT 94010 spirometry, 94729 DLCO`	Do not fabricate the individual LOINC numbers into a UI; bind them from the LOINC pulmonary panel at build time. Pre/post bronchodilator must never be trended as one series. GOLD group is a clinician's assignment, not Ardia's — display it only if it arrived as a coded Condition.
Molecular / genomic report	`DiagnosticReport.category=GE (genetics) with Observation instances on the Genomics Reporting IG profiles (genotype, variant, implication); MolecularSequence in R4; DocumentReference for the signed PDF`	`LOINC genetic-testing codes; HGVS for variant nomenclature (c./p. notation against a stated transcript); ClinVar for assertions; HGNC gene symbols; SNOMED CT for clinical significance; CPT genomic codes (e.g. 81162 BRCA1/2 full sequence + dup/del, 81445 / 81455 targeted genomic sequencing panels); PLA (0xxxU) codes for proprietary assays; MolDX DEX Z-code as an Identifier on the ServiceRequest/Claim line`	The Z-code is an alphanumeric DEX registry identifier assigned per assay — Ardia stores whatever the lab supplied and never mints one. Genomic results are permanently sensitive and drive the GINA and cascade-to-relatives problems below.
Toxicology / drug testing	`Observation.category=laboratory with a toxicology sub-category; DiagnosticReport grouping presumptive vs definitive`	`LOINC drug-of-abuse screen and confirmation codes (separate codes for immunoassay presumptive vs LC-MS/MS definitive, and per-analyte codes for the confirmation); CPT 80307 presumptive by instrumented chemistry analyzer, and the definitive drug-testing code family for confirmation; SNOMED CT for substance concepts`	Presumptive positive is not a result — it is a screen. Ardia must display presumptive and definitive as different things and must never let a presumptive immunoassay stand alone in a summary. Also the 42 CFR Part 2 trigger: if the result came from a federally assisted SUD program, it is segregated and not redisclosed.
Imaging study metadata	`ImagingStudy.modality, .series.bodySite, .started, .numberOfSeries, .numberOfInstances, .identifier (StudyInstanceUID), .endpoint (WADO-RS)`	`DICOM modality (0008,0060) CT/CR/DX/US/MR/NM; DICOM BodyPartExamined (0018,0015); SNOMED CT or RadLex for body region; DICOM StudyInstanceUID / SeriesInstanceUID / SOPInstanceUID; AccessionNumber (0008,0050)`	Ardia stores pointers and metadata, not pixels. No DICOM image is rendered, downloaded, cached or interpreted. The WADO-RS endpoint, if present, is passed through to the source portal's own viewer with the source's own authentication.
Imaging order and procedure code	`ServiceRequest.code with reasonCode; Procedure for the performed study`	`CPT — 71250 CT thorax without contrast, 71260 CT thorax with contrast, 71271 low-dose CT for lung cancer screening, 71046 chest radiograph 2 views, 93306 transthoracic echo complete with spectral and color Doppler; HCPCS G0296 (visit to determine eligibility for LDCT screening); ICD-10-CM reason codes e.g. J44.1, I50.22, Z12.2`	The CPT on the order is the same code that lands on the 837 claim line and comes back on the 835 with a CARC. That shared code is the join key that makes the coverage overlay possible at all.
Radiology report text	`DiagnosticReport.presentedForm (PDF/text) and .conclusion; DocumentReference for the narrative`	`LOINC/RSNA Radiology Playbook codes identify the study type; report sections follow the standard Indication / Technique / Comparison / Findings / Impression structure`	This is the only imaging content Ardia ever explains. Ardia reads the REPORT TEXT, never the image. The distinction is stated on-screen, not buried in terms.
Result status and amendments	`Observation.status / DiagnosticReport.status (registered \| preliminary \| final \| amended \| corrected \| entered-in-error)`	`FHIR ObservationStatus value set`	A corrected result that silently replaces the original is a patient-safety event. Ardia shows the correction, the original, and the timestamp of the change.
Critical / actionable flag and release timing	`Observation.interpretation with HH/LL; DiagnosticReport.status; local release-hold metadata carried in an extension or Task`	`HL7 ObservationInterpretation abnormal-high/low; no national standard for release embargo`	21st Century Cures information-blocking rules push results to patients immediately; the safety literature says some results land badly without a clinician. Ardia's position: display what the source released, add no interpretation, and route anything flagged critical to the safety_escalation gate — which, on a suspected emergency, says call 911 and withholds the explanation.
Coverage / eligibility at time of order	`Coverage; CoverageEligibilityRequest / CoverageEligibilityResponse`	`X12 270 eligibility inquiry / 271 response; Medicare Advantage plan and contract identifiers`	Captured at order time, not claim time. The 271 is what tells you the study was in or out of network before it was performed — the single most useful thing a patient never sees.
Claim line for the diagnostic event	`Claim.item (with CPT/HCPCS, service date, revenue code for facility), ExplanationOfBenefit.item`	`X12 837P/837I; CPT/HCPCS on the line; ICD-10-CM as the linked diagnosis; NPI and place-of-service`	The claim line is the bridge. One accession number, one CPT, one claim line, one remittance line.
Remittance, denial reason and appeal clock	`ClaimResponse.item.adjudication with .reason; ExplanationOfBenefit.item.adjudication; Task for the appeal workflow`	`X12 835 remittance; CARC (e.g. CO-50 not deemed medically necessary, CO-197 authorization absent, CO-16 lacks information, PR-1 deductible); RARC (e.g. N115 decision based on a Local Coverage Determination); LCD/NCD identifiers; Medicare Advantage 60-day plan reconsideration deadline`	CO-50 plus RARC N115 means an LCD says this indication is not covered — which is answerable with documentation. Ardia surfaces the code, the plain-English meaning, the named policy, and the days remaining. It does not file the appeal and does not tell the patient they will win.
Consent scope for the care collaborator	`Consent.provision with .type=permit/deny, .class (Observation, DiagnosticReport, ImagingStudy), .code, .period; Consent.provision.securityLabel`	`HL7 Confidentiality and ActCode sensitivity labels (e.g. genetic, substance-use, behavioral); 42 CFR Part 2 segmentation labels`	Category-level, revocable, time-boxed, and logged. The adult child can be granted labs and imaging while genetic and toxicology stay excluded — and the patient can revoke it in one action without a phone call.
Provenance for every displayed element	`Provenance.target, .recorded, .agent, .entity; Observation.derivedFrom for anything computed`	`FHIR ProvenanceEventCurrentState; source system identifiers`	Every value on screen says which of the four sources it came from and when it was fetched. Anything Ardia computed (a delta, a unit conversion, a merged series) is visually distinct from anything a lab reported.

FHIR R4: Observation, DiagnosticReport, ImagingStudy, ServiceRequest, Specimen, DocumentReference, Media, MolecularSequence, Provenance, Consent, Coverage, CoverageEligibilityResponse, Claim, ClaimResponse, ExplanationOfBenefit, TaskUS Core 6.x profiles: Laboratory Result Observation, DiagnosticReport for Laboratory Results, DiagnosticReport Note, Smoking Status, Vital SignsHL7 FHIR Genomics Reporting Implementation Guide (variant, genotype, diagnostic implication profiles)LOINC (analytes, panels, document/report types, LOINC-RSNA Radiology Playbook)UCUM (units, and the normalization required for cross-lab trending)SNOMED CT (specimen types, body sites, substances, clinical findings)ICD-10-CM (order reason and claim-linked diagnosis)CPT / HCPCS Level II, including PLA 0xxxU codes for proprietary molecular assaysDICOM (modality 0008,0060; BodyPartExamined 0018,0015; StudyInstanceUID; AccessionNumber 0008,0050; WADO-RS retrieval endpoints)RadLex / RSNA report templates for radiology narrative structureHGVS variant nomenclature, HGNC gene symbols, ClinVar assertionsMolDX DEX Z-code identifiers (stored as supplied by the performing lab; never generated)X12 5010: 270/271 eligibility, 278 prior authorization, 837P/837I claim, 275 attachment, 835 remittanceCARC and RARC code lists (WPC-maintained), plus Medicare LCD/NCD policy identifiersHL7 v2 ORU^R01 (the format most real lab feeds still arrive in, mapped on ingest)IHE profiles: XDS-I.b for imaging document sharing, ATNA for audit logging21st Century Cures Act information-blocking rules; HIPAA Privacy and Security Rules; 42 CFR Part 2; GINA Title I/II; state genetic-privacy statutes

Synthetic sample — no real patient data, no names

row_type	analyte	loinc	series	ardia_delta	ardia_note
lab_trend_cross_source	Creatinine, serum	2160-0	[{'collected': '2026-01-14', 'value': '1.05 mg/dL', 'source': 'reference lab', 'ref_range': '0.70-1.30 mg/dL', 'fla	+0.56 mg/dL over 7 months (+53%); computed by Ardia, derivedFrom the four Observations above, UCUM-normalized, method break: none detected	Ardia states the movement and that two different labs with two different reference ranges are involved. It does not say why, does not name a cause, and does not suggest any change to therapy. Non-diag
lab_panel
lab_single		4548-4		+0.5 percentage points over ~6 months; same performing lab and method, so the series is continuous
lab_single_cardiac		33762-6
pulmonary_function
imaging_with_denial
imaging_routine
imaging_echo
molecular_report
toxicology
corrected_result		2823-3
eligibility_precheck

What Ardia adds here

Epic MyChart shows results from Epic. Apple Health shows what a device or a connected portal hands it. Health Gorilla, Particle and Zus aggregate clinical data well and stop at the clinical boundary. None of them put the 835 next to the result. Ardia's concrete addition here is three things. One: cross-source trending — creatinine from the reference lab and the hospital lab, UCUM-normalized, plotted as one series with the reference-range differences shown rather than hidden, and method breaks marked instead of smoothed. Two: the coverage overlay — the CT order, the DICOM study, the radiology report, the 837 line and the CO-50/N115 denial with 52 days left on the Medicare Advantage reconsideration clock, on one row. Three: the MolDX layer — showing that a molecular claim was denied CO-16 for a missing Z-code and later paid. Where Ardia adds nothing: it does not read images, does not produce results faster, does not replace the ordering clinician, does not diagnose, and cannot outperform Epic on data that lives only inside Epic.

Risks in this domain

Nothing in this domain is built. There is no ingestion pipeline, no LOINC mapping table, no DICOM metadata store, no 835 parser, no consent engine. This is a design, not a feature.
Sentinel de-identification does not reliably redact plain personal names today. Radiology reports, pathology narratives and molecular report PDFs are dense with names — ordering clinician, radiologist, referring practice, sometimes the patient in the header. Until name detection is fixed, this domain cannot hold a single real report. This is the gating dependency, not a nice-to-have.
No BAA is in place, no DUA, zero customers, zero pilots, zero real patient records ever processed. Every row above is synthetic and unnamed by construction.
Re-identification: an 80-year-old, a rare alpha-1 genotype, a specific reference lab and a date range is close to unique. Aggregated lab and imaging metadata re-identifies even after direct identifiers are stripped; k-anonymity on quasi-identifiers is required before any analytics use, and rare-variant records may not be safely aggregatable at all.
42 CFR Part 2: toxicology or any diagnostic result originating from a federally assisted substance-use program carries redisclosure restrictions far stricter than HIPAA. Consent must be specific and written; a general HIPAA authorization is not sufficient; and the data must be segmented at ingest, not filtered at display.
GINA and state genetic-privacy law: genetic results are permanently sensitive, implicate blood relatives who never consented, and carry employment and long-term-care/life/disability insurance exposure that GINA does not fully cover. Genetic content must be off by default for every collaborator and every downstream use.
Caregiver access without consent: the adult child is the likeliest unauthorized reader. Consent must be category-scoped, time-boxed, revocable in one action by the patient alone, and fully audited — and the patient must be able to revoke without a confrontation. Cognitive decline makes the consent itself fragile: capacity can change between the grant and the read.
Elder financial exploitation: a patient-360 that shows out-of-pocket amounts, denial dollar figures and appeal deadlines is a targeting map. Cost and coverage fields need their own access tier, and Ardia must never generate outbound payment requests or link to third-party payment or 'appeal help' services.
Surfacing a result before a clinician has seen it: the 21st Century Cures information-blocking rules push results out immediately, but a critical value, an incidental imaging finding, or a molecular result landing on a phone at 11pm with no clinician attached causes real harm. Ardia's mitigation is to display exactly what the source released, add no interpretation, and route anything flagged critical or any emergency-suggestive question to safety_escalation — which withholds the explanation entirely and says call 911. That is a mitigation, not a solution.
Wrong-patient and wrong-study merges: matching results across four unaffiliated sources without a national patient identifier produces false merges. A mismatched lab or imaging study attached to the wrong record is a patient-safety event. Probabilistic matches must be shown as unconfirmed and must never feed a trend.
Unit and reference-range errors: a mis-normalized UCUM conversion or a borrowed reference range silently changes what looks normal. Any Ardia-computed value must be visually distinguishable from a lab-reported one, with Provenance attached.
AI explanation failure: the explanation engine would be Google Gemini (gemini-flash-lite), not Claude, behind six deterministic gates — de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop. A failed gate withholds the answer entirely rather than degrading it. A hallucinated reading of a radiology impression or a fabricated reference range is the highest-severity failure this domain can produce.
Image boundary drift: the moment anything in the product reads pixels rather than report text, Ardia is a diagnostic device under FDA software-as-a-medical-device rules. The boundary must be enforced architecturally — no pixel retrieval path exists — not by policy alone.
Appeal-deadline reliance: surfacing '52 days remaining' creates a duty of accuracy. A wrong clock could cost a patient an appeal. Deadlines must be derived from the plan's own dated notice, labelled as Ardia's arithmetic, and never presented as legal advice.

Build status.

Nothing in this domain exists today. There is no code, no ingestion, no storage, no UI. What exists is this specification. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data — every value in this design is synthetic and every person is a role label. The patient-360 itself is a new page; the eleven existing solution-360 pages are unchanged and unrelated. What is needed first, in order: (1) fix Sentinel's name-detection gap — it does not reliably redact plain personal names, and radiology and molecular reports are full of them, so no real report can be ingested until this is closed and independently measured against a held-out corpus with a published recall figure; (2) a signed BAA with any data source, plus DUAs for any de-identified use; (3) a LOINC and local-code mapping layer with UCUM normalization and recorded provenance, since real feeds arrive as HL7 v2 ORU with local codes; (4) an 835/837 parser and a CARC/RARC-to-plain-English dictionary, which is the actual differentiator and does not exist; (5) the consent engine with category-level, revocable, audited scoping, including hard segmentation for 42 CFR Part 2 and genetic data; (6) the six-gate wrapper around gemini-flash-lite with fail-closed behavior verified by adversarial testing on radiology narrative. Until (1) and (2) are both done, this view can only ever be demonstrated on synthetic data, and it should be labelled that way on screen.

•

Vitals, Home Monitoring and Daily Activity

Why it matters

An 80-year-old with HFrEF and GOLD group E COPD is managed by trend, not by any single number. The weight that matters is plus three pounds overnight or plus five in a week. The SpO2 that matters is the drift from a personal resting baseline of 92% to 88% on exertion. The FEV1 that matters is this month against the same patient's own best, not against a population predicted value. Today those three trends live in three places: the scale's own app on a phone the patient rarely opens, a paper card of oximeter readings in a kitchen drawer, and a DME supplier's portal the adult child was never given a login for. Nobody sees the shape. The failure repeats: the family notices ankle swelling at day nine instead of day three, and the diuretic conversation happens in an emergency department instead of on the phone with cardiology. A second, quieter failure runs alongside it. The concentrator, the cuff, the transmitting oximeter that produce these numbers are themselves claims, and when a claim is denied the device is withdrawn. The monitoring plan collapses and the first the family hears of it is a supplier's collection letter. This domain puts the trend, and the coverage status of the thing producing the trend, on one surface for the patient and one consented care collaborator.

What this domain holds

Data element	FHIR R4	Code system	Note
Office blood pressure (systolic/diastolic)	`Observation (US Core Blood Pressure profile); Observation.component[0..1].valueQuantity, Observation.effectiveDateTime, Observation.bodySite, Observation.method`	`LOINC 85354-9 (BP panel) with components LOINC 8480-6 systolic and 8462-4 diastolic; UCUM mm[Hg]; SNOMED CT for body site (arm) and cuff method`	Category vital-signs. Position and cuff size belong in Observation.component or bodySite/method - an 80-year-old's seated-vs-standing difference is the whole point in orthostasis, and dropping it makes the number unreadable.
Home blood pressure reading	`Observation (same profile) + Observation.device -> Device, Observation.performer -> Patient or RelatedPerson, Provenance.agent`	`Same LOINC/UCUM as office BP; device identified by Device.type (SNOMED CT device concept) and Device.udiCarrier (GS1 UDI-DI)`	Must be visually distinguishable from an office reading in the UI. A home cuff reading and a clinic reading are not interchangeable evidence and should never be plotted as one undifferentiated line without a source marker.
Body weight, daily home scale	`Observation; Observation.valueQuantity, Observation.effectiveDateTime, Observation.device`	`LOINC 29463-7 Body weight; UCUM kg or [lb_av]; SNOMED CT for scale device type`	The single highest-value element in this domain for HFrEF. Time-of-day consistency matters more than precision; store the raw value and the capture time, never a rounded daily average that hides a 24-hour jump.
Derived weight change (24-hour and 7-day delta)	`Observation with Observation.derivedFrom -> the source weight Observations; Observation.valueQuantity`	`No widely-established LOINC term for a 24-hour weight delta - do not fabricate one. Carry it as a derived Observation with a locally-defined code plus Observation.code.text and full derivedFrom provenance`	This is a computed convenience, not a measurement, and the UI must say so. Ardia computes the delta; Ardia does not interpret it. The interpretation belongs to cardiology.
Heart rate	`Observation (US Core Heart Rate); Observation.valueQuantity`	`LOINC 8867-4; UCUM /min`	Wearable-derived optical HR and cuff-derived pulse are different measurements with different failure modes; keep Observation.method and Observation.device populated.
Respiratory rate	`Observation (US Core Respiratory Rate); Observation.valueQuantity`	`LOINC 9279-1; UCUM /min`	Rarely measured accurately at home. If it arrives from a consumer wearable, label the estimation method or suppress it.
Body temperature	`Observation (US Core Body Temperature); Observation.valueQuantity, Observation.method`	`LOINC 8310-5; UCUM Cel or [degF]; SNOMED CT route (oral, tympanic, temporal)`	Route materially changes the number in an older adult; an unrouted temperature is close to useless.
Height and BMI	`Observation (US Core Body Height, BMI); Observation.valueQuantity`	`LOINC 8302-2 body height, LOINC 39156-5 BMI; UCUM cm, kg/m2`	BMI is a derived value and should carry derivedFrom. In an 80-year-old with fluid overload, BMI is a poor signal and should be de-emphasised in the UI relative to weight trend.
Pulse oximetry SpO2 (rest and on exertion)	`Observation (US Core Pulse Oximetry); Observation.valueQuantity, Observation.component for inspired oxygen, Observation.method`	`LOINC 59408-5 (SpO2 by pulse oximetry) or 2708-6 (oxygen saturation in arterial blood); UCUM %; SNOMED CT for method and finger/probe site`	Must record whether the patient was on room air or supplemental oxygen and at rest or ambulating - the same 88% means opposite things. Pulse oximeters are known to over-read in patients with darker skin pigmentation (FDA has issued a safety communication on this); the UI must carry that caveat rather than presenting SpO2 as ground truth.
Supplemental oxygen flow rate / delivery	`Observation.component alongside SpO2, or a separate Observation; DeviceUseStatement for the concentrator`	`LOINC has terms for inhaled oxygen flow rate and inhaled oxygen concentration - use the published term rather than an invented code; UCUM L/min and %; HCPCS Level II for the equipment (see device row)`	Without flow rate, an oxygen-qualifying oximetry value cannot be assessed against coverage policy, which is where the whole downstream claim turns.
Home spirometry FEV1	`Observation; Observation.valueQuantity plus a percent-predicted component; Observation.device; Observation.status`	`LOINC 20150-9 FEV1; UCUM L; percent-predicted carried as a separate component using the published LOINC percent-predicted term`	Home spirometry is not equivalent to a lab pulmonary function test performed to ATS/ERS acceptability and repeatability criteria. Effort quality, session best-of-three, and whether it was pre- or post-bronchodilator all have to travel with the value or the trend is noise. Never let a home FEV1 restage GOLD group.
FVC and FEV1/FVC ratio	`Observation; separate Observations or components with derivedFrom for the ratio`	`LOINC publishes distinct terms for FVC and for the FEV1/FVC ratio - bind to the published terms; do not guess the numeric codes. UCUM L and %`	Only meaningful from a device and manoeuvre capable of a full forced vital capacity. Many home devices report FEV1 only; absence must be represented with Observation.dataAbsentReason, not a zero.
Peak expiratory flow	`Observation; Observation.valueQuantity`	`LOINC peak expiratory flow rate term; UCUM L/min; equipment HCPCS Level II peak flow meter code (A4614 family)`	Low-cost and widely used, but effort-dependent and poorly standardised across meters. Personal-best zones are more useful than predicted values in an 80-year-old.
Capillary blood glucose and CGM stream	`Observation; Observation.valueQuantity, Observation.effectiveDateTime; CGM summary metrics as derived Observations with derivedFrom`	`LOINC glucose terms (mass/volume in blood; the glucometer-specific capillary term for fingerstick); UCUM mg/dL or mmol/L; equipment/supply HCPCS Level II - E0607 home glucose monitor, A4253 test strips, A4259 lancets, and the CGM supply-allowance and receiver codes (A4239, E2103)`	Time-in-range and glucose management indicator are derived values that need explicit derivedFrom and a stated calculation window. Hypoglycaemia in an 80-year-old on multiple agents is the real safety issue here and belongs in the deterministic escalation path, not in an AI summary.
Patient-reported symptom scores (dyspnoea, COPD symptom burden)	`QuestionnaireResponse plus a summary Observation with Observation.derivedFrom -> QuestionnaireResponse`	`LOINC publishes survey panels and individual question terms for standardised respiratory instruments - bind to the published panel rather than inventing item codes; SNOMED CT for the dyspnoea concept`	Licensed instruments (CAT, for example) have copyright and licensing terms; Ardia cannot reproduce instrument text without a licence. Store the score and cite the instrument by name only until licensing is settled.
Daily step count and ambulation volume	`Observation with Observation.category = activity; Observation.valueQuantity, Observation.effectivePeriod`	`LOINC number-of-steps terms (24-hour measured, and pedometer-derived); UCUM {steps}`	Sourced from Apple HealthKit, a Fitbit/Google account, or a phone motion coprocessor. Consumer step counts systematically undercount slow, shuffling, assistive-device gait - exactly this patient's gait - so absolute counts should be suppressed in favour of within-patient change.
Cadence activity classification (walking / stairs / sitting / standing / lying)	`Observation, category = activity, Observation.valueCodeableConcept using SNOMED CT activity concepts; Observation.derivedFrom -> raw accelerometer/gyroscope Observation; Observation.status held at preliminary; Device for the model as software`	`SNOMED CT concepts for the posture/activity states; UCUM not applicable; the model itself represented as a Device with Device.type software and an explicit version string`	HONEST LIMITS, stated in the UI next to every value: Cadence is a classifier trained on the public UCI HAR dataset (waist-mounted smartphone, 30 adults aged roughly 19-48). Company-reported subject-independent accuracy is 95.45% on that public benchmark. It has NEVER been scored on a single real older adult, and it is NOT a fall detector - it does not detect, predict, or infer falls and must never be presented as doing so. An 80-year-old with COPD and heart failure walks nothing like a 25-year-old in a lab; the domain shift is severe and unquantified. This element ships as a labelled research signal or it does not ship.
Device inventory and connectivity state	`Device (Device.type, Device.manufacturer, Device.serialNumber, Device.udiCarrier), DeviceRequest, DeviceUseStatement (R4), Device.status`	`SNOMED CT device concepts; GS1/HIBCC UDI-DI in Device.udiCarrier; HCPCS Level II for the billable item - E1390 stationary oxygen concentrator, E0431 portable gaseous oxygen, A4670 automatic blood pressure monitor`	Includes last-sync timestamp and battery/cellular state. A silent scale is indistinguishable from a stable weight, and that ambiguity has killed people. Absence of data must render as absence, never as a flat line.
Measurement provenance and performer	`Provenance.agent, Provenance.entity, Observation.performer, Observation.device, Observation.issued`	`FHIR Provenance participation-type value set; no external terminology required`	Four distinct provenance classes must be visually separable: clinician-measured in office, device-transmitted from home, patient-keyed by hand, and care-collaborator-keyed on the patient's behalf. The last of these is also an elder-abuse surface and should be logged, not just stored.
Personal baseline, target and reference range	`Observation.referenceRange (with low/high and appliesTo), Goal (target weight, target SpO2 floor), CarePlan`	`UCUM for bounds; SNOMED CT for the goal concept; no invented codes`	Ranges must be per-patient and clinician-set, imported from the care plan. Ardia must not generate a personalised threshold on its own - that is a clinical decision and crosses the non-diagnostic line.
Device and monitoring coverage status	`Coverage, CoverageEligibilityRequest, CoverageEligibilityResponse (Coverage.class, benefit category, in-network status)`	`X12 270/271 eligibility and benefit inquiry for the DMEPOS benefit category; Medicare Advantage plan and contract identifiers`	Answers the question a portal never answers: is the concentrator still a covered benefit under this plan year, and is the supplier still in network after a January network change.
Remote monitoring claim and denial state	`Claim, ClaimResponse, ExplanationOfBenefit; EOB.item.adjudication.reason, EOB.item.productOrService`	`CPT 99453 setup and patient education, 99454 device supply per 30 days, 99457 first 20 minutes of management, 99458 each additional 20 minutes; CPT 98975-98978 and 98980/98981 for remote therapeutic monitoring including the respiratory device supply code; X12 837P submitted, X12 835 remitted; CARC and RARC on the 835`	THE DIFFERENTIATOR. The RPM device the patient is weighing themselves on generates a monthly claim. When that claim denies - CO-151 for units billed, PR-204 as not covered under the plan, CO-97 as bundled - the patient is the last to know and the device goes back. Putting the 835 adjudication on the same timeline as the weight trend is the thing no other patient-360 does.
Coverage policy and appeal clock for home oxygen and monitors	`Coverage, ClaimResponse, plus a DocumentReference to the cited policy; Task or Communication for the appeal action`	`NCD 240.2 Home Use of Oxygen; the DME MAC oxygen and glucose-monitor LCDs (cite the LCD identifier, not an invented one); X12 278 prior authorisation for DMEPOS; CARC CO-50 not medically necessary, CARC CO-16 with RARC N115 indicating a local coverage determination basis`	Home oxygen turns on a documented qualifying oximetry or arterial blood gas value under NCD 240.2 - which is a value that lives in THIS domain. The Medicare Advantage 60-day plan reconsideration window has to be shown as a countdown with days remaining, because the deadline, not the merits, is what usually loses the appeal.
Deterministic safety flag and escalation	`Flag, DetectedIssue, CommunicationRequest; never RiskAssessment`	`SNOMED CT for the concept being flagged; no scoring or acuity terminology`	Thresholds are rule-based, clinician-configured, and rendered as fixed copy - never model-generated text. A suspected emergency routes to 911, full stop. Ardia deliberately does not use FHIR RiskAssessment because assigning risk is diagnostic and out of scope.
Care-collaborator visibility scope for this domain	`Consent, Consent.provision.data, Consent.provision.period, Consent.provision.actor -> RelatedPerson; AuditEvent for every access`	`FHIR consent policy and scope value sets; no external terminology`	Vitals are the element families most often shared with an adult child, and glucose plus weight are also the elements most usable for coercion. Scope must be per-element-family and revocable by the patient alone, with every collaborator view written to AuditEvent.

FHIR R4 (Observation, US Core Vital Signs / Blood Pressure / Pulse Oximetry / Body Weight profiles, Device, DeviceRequest, DeviceUseStatement, QuestionnaireResponse, Provenance, Goal, CarePlan, Flag, DetectedIssue, Consent, AuditEvent, Coverage, Claim, ClaimResponse, ExplanationOfBenefit)LOINC (vital signs, pulse oximetry, spirometry, glucose, step counts, survey panels)SNOMED CT (conditions, body sites, methods, device concepts, activity and posture concepts)UCUM (mm[Hg], kg, [lb_av], L, L/min, %, mg/dL, mmol/L, /min)CPT (99453, 99454, 99457, 99458 remote physiologic monitoring; 98975-98981 remote therapeutic monitoring; 94010, 94060 spirometry; 94760, 94761, 94762 pulse oximetry)HCPCS Level II (E1390, E0431 oxygen equipment; A4670 automatic BP monitor; E0607, A4253, A4259 glucose monitoring; A4239, E2103 continuous glucose monitoring; A4614 peak flow meter)ICD-10-CM (COPD, heart failure, type 2 diabetes, hypertension - as the linked conditions justifying monitoring)X12 270/271 eligibility and benefit inquiry, X12 278 DMEPOS prior authorisation, X12 837P professional claim, X12 835 remittance adviceCARC / RARC claim adjustment and remark codes on the 835Medicare NCD 240.2 Home Use of Oxygen; DME MAC local coverage determinations for oxygen and glucose monitorsGS1 / HIBCC UDI on Device.udiCarrierApple HealthKit, Google Health Connect and vendor device APIs as ingestion surfaces (not standards, but the real integration path)Bluetooth SIG GATT profiles for weight scale, blood pressure and pulse oximeter devicesIEEE 11073 personal health device nomenclature where a device emits it

Synthetic sample — no real patient data, no names

kind	source	fhir	effective	value	provenance
home_weight	cellular scale, DME supplier	Observation / LOINC 29463-7	2026-08-28T06:12	84.4 kg (186.1 lb)	device-transmitted
home_weight	cellular scale, DME supplier	Observation / LOINC 29463-7	2026-09-04T06:07	85.7 kg (188.9 lb)	device-transmitted
home_weight	cellular scale, DME supplier	Observation / LOINC 29463-7	2026-09-07T06:21	87.5 kg (192.9 lb)	device-transmitted
derived_weight_delta		Observation.derivedFrom -> the three weights above		+1.8 kg (+4.0 lb)	computed by Ardia
home_pulse_oximetry	transmitting fingertip oximeter	Observation / LOINC 59408-5	2026-09-07T09:40	88 %	device-transmitted
home_pulse_oximetry	transmitting fingertip oximeter	Observation / LOINC 59408-5	2026-09-07T09:47	84 %	device-transmitted
office_blood_pressure	primary care office visit	Observation / LOINC 85354-9 with components 8480-6 and 8462-4	2026-08-19T10:15	148 / 78 mm[Hg]	clinician-measured
home_blood_pressure	patient's own upper-arm cuff (HCPCS A4670)	Observation / LOINC 85354-9	2026-09-06T07:30	126 / 64 mm[Hg]	device-transmitted
home_spirometry_fev1	home spirometer, independent pulmonology practice	Observation / LOINC 20150-9 + percent-predicted component	2026-09-02T08:05	0.94 L (approx. 38 % predicted)	device-transmitted
capillary_glucose	home glucose meter (HCPCS E0607, strips A4253)	Observation / LOINC capillary glucose by glucometer	2026-09-05T22:40	58 mg/dL	patient-keyed
step_count	phone motion sensor via HealthKit	Observation, category=activity / LOINC steps in 24 hours	2026-09-06	612 {steps}	consumer device
cadence_activity_classification	Cadence classifier v0 (research)	Observation, category=activity, valueCodeableConcept SNOMED CT, status=preliminary, derivedFrom raw accelerometer	2026-09-06	lying 71 % / sitting 22 % / standing 5 % / walking 2 % of classified time	Ardia software model, Device.type=software
device_connectivity		Device.status + last-sync timestamp
coverage_check		CoverageEligibilityResponse	2026-07-01

What Ardia adds here

Apple Health already holds the weight and the steps, but it does not know the patient has HFrEF, and it has no idea the oximeter is rented DME governed by a coverage policy. Epic MyChart holds the office vitals, and home readings only if that health system runs the monitoring programme - it shows nothing from the independent pulmonologist or the DME supplier. Validic and Health Gorilla move device and clinical data well, but they are pipes sold to health systems, not a view an 80-year-old and one adult child open. None of them show that the 99454 supplying the scale was denied CO-151, or that a 60-day reconsideration clock on the oxygen denial has 41 days left. Being honest about where Ardia adds nothing: it does not make any measurement more accurate, it uses the same HealthKit and vendor APIs everyone uses, and the Cadence classifier contributes no clinical value today. What it adds is one baseline per patient across four sources, honest provenance on every point, visible data gaps, and the claim beside the reading.

Risks in this domain

Re-identification: a longitudinal daily weight, step and sleep-posture series is close to a behavioural fingerprint. Even stripped of the eighteen HIPAA identifiers, a year of 6 a.m. weights plus a ZIP tabulation area and an age of 80 is plausibly re-identifiable. De-identification here is far harder than for a lab panel.
Sentinel's name-detection gap: Sentinel de-identification does not reliably redact plain personal names today. Vitals rows carry free text - device nicknames, patient-keyed notes, questionnaire comments - and names leak through exactly those fields. This is a hard blocker on holding any real data in this domain.
Surfacing a result before a clinician has seen it: an 88 % SpO2 or a 58 mg/dL glucose reaching a frightened 80-year-old and an adult child with no clinician in the loop can drive both panic and dangerous self-management - stopping a diuretic, turning oxygen up unsupervised. Every threshold rendering must be fixed, non-diagnostic copy with an explicit escalation path, and a suspected emergency routes to 911.
Elder financial exploitation: continuous vitals and activity data reveal when the patient is home, asleep, immobile or cognitively struggling. In the hands of a coercive relative that is a targeting tool. Care-collaborator access must be per-element, time-bounded, revocable by the patient alone, and fully audited.
Caregiver access without genuine consent: consent captured on the patient's phone while the adult child holds the phone is not consent. This domain needs an independent verification path and periodic re-attestation, not a one-time checkbox.
Cadence over-claim: the single largest reputational and safety risk in this domain. If a labelled research signal trained on 19-to-48-year-olds in a lab is ever presented as fall detection, immobility monitoring or clinical decline, a family will rely on it and it will fail. The mitigation is refusal to ship it unlabelled, and never wiring it into any alert.
Home spirometry treated as diagnostic: an unsupervised FEV1 without ATS/ERS-grade quality control can under- or over-read badly. If a home value is allowed to look like a lab PFT, it can influence therapy inappropriately. Home values must be visually and semantically segregated from lab-grade results.
Pulse oximeter accuracy disparity: pulse oximeters are known to over-read oxygen saturation in patients with darker skin pigmentation, which means a false reassurance risk that falls unevenly. The caveat has to be surfaced at the point of display, not buried in terms of service.
Data gaps read as good news: a scale that stopped transmitting looks identical to a stable weight on a naive chart. Silence must render as silence.
42 CFR Part 2: this domain does not itself hold substance-use treatment records, but activity, sleep and vitals imported from a Part 2 programme's monitoring, or linked to one, inherit Part 2 restrictions that are stricter than HIPAA and are not satisfied by a general HIPAA authorisation.
GINA: no genetic data lives here, but this domain will sit on the same page as molecular diagnostics. A unified export or a single caregiver permission that spans both would expose genetic information under a consent granted for blood pressure. Permissioning must not be page-wide.
Device-vendor terms and secondary use: HealthKit, Fitbit and DME vendor APIs each carry their own use restrictions and, in some cases, prohibitions on downstream sharing. Ingesting is not the same as being permitted to redistribute to a care collaborator.
Regulatory: rules-based display of clinician-set thresholds is intended to remain outside FDA device regulation, but a threshold Ardia chooses, personalises or optimises starts to look like clinical decision support software subject to FDA oversight. The boundary is real and Ardia must stay on the display side of it.
No BAA: Ardia has no signed BAA or DUA with any covered entity. Ingesting device or EHR vitals without one is a compliance failure before it is anything else.

Build status.

Nothing in this domain is built. There is no vitals ingestion pipeline, no device pairing, no HealthKit or Health Connect integration, no DME supplier feed, no X12 835 parser, no charting layer, no threshold engine, and no consent scoping for care collaborators. Every value in the sample rows above is synthetic and hand-written for this design. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data. The only asset that exists is the Cadence classifier, and it is a research artefact: trained on the public UCI HAR dataset, 95.45% subject-independent accuracy company-reported on that public benchmark, never scored on a single real older adult, and explicitly not a fall detector. What is needed first, in order: (1) fix Sentinel's name-detection gap - the de-identification layer does not reliably redact plain personal names today, and no real PHI can be held in a patient-360 until it does; (2) a signed BAA with any data source and a DUA for any secondary use; (3) a chosen single ingestion path - most likely HealthKit plus one DME supplier - rather than four at once; (4) an X12 835 ingestion path with CARC/RARC mapping, since the coverage lane is the actual differentiator and it does not exist; (5) a clinician-set threshold configuration surface, because Ardia must not choose thresholds itself; (6) legal review of the FDA clinical-decision-support boundary. Any AI explanation would run on Google Gemini (gemini-flash-lite), not Claude, behind six deterministic gates - de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop - where a failed gate withholds the answer entirely rather than degrading it. The view is non-diagnostic by construction: it organises and explains, it never diagnoses, prescribes or assigns acuity, and a suspected emergency escalates to 911.

•

Insurance, coverage and benefits

Why it matters

An 80-year-old with GOLD group E COPD, HFrEF, type 2 diabetes and hypertension does not fail because the medicine is wrong. They fail because a chest CT ordered by pulmonology comes back denied CO-50 and nobody tells them there is a 60-day clock; because the triple-therapy inhaler needs step therapy and the pharmacy just says "not covered," so the patient goes without; because the oxygen concentrator is in month 11 of a 36-month capped rental and the continued-need reassessment is due before winter; because a molecular panel already run gets denied CO-197 for a missing prior authorization and the lab bills the patient anyway even though the 835 marked it provider-liable. Every one of those is an administrative failure with a clinical consequence, and every one is invisible in a clinical-only patient record. The adult child acting as care collaborator is currently reconstructing this from a shoebox of EOBs, three portals and a phone tree. This domain exists so the coverage fact sits beside the clinical event that generated it, with the deadline showing, before the window closes. Nothing here diagnoses; it explains, and it counts down.

What this domain holds

Data element	FHIR R4	Code system	Note
Plan enrollment (Medicare Advantage contract, PBP, plan type)	`Coverage.type, Coverage.class (type=plan), Coverage.period, Coverage.payor`	`HL7 coverage-type / X12 271 EB04 insurance type code; CMS contract-PBP identifier (H-number + plan benefit package) carried as Coverage.class.value`	Distinguishes MA HMO from MA PPO from Original Medicare + Medigap, which changes every downstream rule: network penalty, appeal path, whether an ABN applies. Original Medicare uses the ABN (CMS-R-131); MA does not — it uses an integrated denial notice. Getting this field wrong makes every deadline shown to the patient wrong.
Member id, group id, subscriber relationship	`Coverage.subscriberId, Coverage.identifier, Coverage.class (type=group), Coverage.relationship, Coverage.beneficiary`	`X12 271 Loop 2100C NM109 (member id), REF*6P (group); MBI format for Medicare`	Never rendered in full to a care collaborator by default — masked to last four unless the consent scope explicitly grants billing-identifier visibility. The MBI is a re-identification key and an elder-fraud target.
Real-time eligibility check and response	`CoverageEligibilityRequest (.purpose=benefits\|validation, .item.category, .servicedDate), CoverageEligibilityResponse (.insurance.item.*, .error)`	`X12 270/271; 271 EB01 eligibility/benefit code (1=Active Coverage, 6=Inactive, C=Deductible, G=Out-of-Pocket Stop Loss, A=Coinsurance, B=Copayment, F=Limitations), EB03 service type code (30=Health Benefit Plan Coverage, 98=Professional Office Visit, 5=Diagnostic Lab, 4=Diagnostic X-Ray, 12=DME Purchase, 18=DME Rental, 88=Pharmacy), AAA03 reject reason on failure`	CAQH CORE operating rules require real-time response. The response is a point-in-time snapshot, not a guarantee of payment — the view must say so on the same line, because patients read 'Active Coverage' as 'this will be paid'.
Network status of a specific provider or facility for a specific service	`CoverageEligibilityResponse.insurance.item.network (in\|out), Da Vinci Plan-Net PractitionerRole.network / Organization, InsurancePlan.network`	`HL7 benefit-network value set; NPI (Type 1 individual, Type 2 organization) as the join key`	FHIR R4 has no first-class 'is this provider in network' resource; Plan-Net is the closest and payer directories are notoriously stale. Ardia should show network status with its retrieval timestamp and source, and refuse to assert it when the directory is older than a set threshold rather than guess.
Cost-share design (copay, coinsurance, deductible by service category)	`Coverage.costToBeneficiary.type + .valueMoney/.valueQuantity, CoverageEligibilityResponse.insurance.item.benefit (type=copay\|coinsurance), .item.unit, .item.term`	`HL7 coverage-copay-type; X12 271 EB01=A/B with EB07 percent or EB06 monetary amount; benefit-unit (individual\|family), benefit-term (annual\|lifetime\|day)`	Must be stated per service category, not as one number. An MA plan can have $0 primary care, $45 specialist, 20% for Part B drugs and a per-day inpatient copay simultaneously.
Deductible and out-of-pocket maximum accumulators (medical)	`CoverageEligibilityResponse.insurance.item.benefit.allowedMoney / .usedMoney; ExplanationOfBenefit.benefitBalance.financial.allowedMoney / .usedMoney`	`X12 271 EB01=C (deductible) and G (out-of-pocket stop loss) with EB06 amount and DTP dates; CARC PR-1 (deductible), PR-2 (coinsurance), PR-3 (copayment) on the 835`	Accumulators drift: the 271 lags claims in flight. Show both the payer-reported figure and its as-of timestamp, and never present a computed estimate as the payer's number.
Part D drug benefit phase and out-of-pocket accumulator	`Coverage (Part D), CoverageEligibilityResponse.insurance.item.benefit; ExplanationOfBenefit (pharmacy) .total`	`NCPDP Telecommunication D.0 response fields; CMS Part D benefit phases; annual Part D out-of-pocket cap (indexed; $2,000 in 2025) and the Medicare Prescription Payment Plan`	The single most useful number for an 80-year-old on six-plus drugs. The cap and the smoothing program changed the shape of this entirely; the view should show months remaining and whether smoothing is elected.
Formulary tier, quantity limit, step therapy, PA flag per drug	`Da Vinci US Drug Formulary: List + MedicationKnowledge (STU1) or InsurancePlan.plan.specificCost.benefit.cost (later versions); MedicationRequest.insurance`	`RxNorm RxCUI as the drug key (NDC for the dispensed package); CMS formulary file tier and utilization-management flags`	Bind formulary to RxNorm, not NDC — NDC is package-specific and changes on refill. Tier alone does not predict cost; pair it with the phase-aware cost estimate and label the estimate as an estimate.
Prior authorization requirement and status	`CoverageEligibilityResponse.insurance.item.authorizationRequired + .authorizationSupporting, Claim.insurance.preAuthRef, ExplanationOfBenefit.preAuthRef, Task (Da Vinci PAS), Da Vinci CRD/DTR hooks`	`X12 278 request/response; NCPDP SCRIPT ePA (PAInitiationRequest / PARequest / PAResponse) for drugs; CARC CO-197 (precertification/authorization absent) when it was missed`	CMS-0057-F requires MA plans to stand up a FHIR Prior Authorization API — same year as the 2027 PAMA cliff. Until then, PA status is scraped from portals or inferred from the 835, and Ardia must say which.
Submitted claim (professional / institutional)	`Claim (.type, .item.productOrService, .diagnosis, .provider, .billablePeriod), ClaimResponse`	`X12 837P/837I: Loop 2300 CLM, HI segment with ABK (principal dx) / ABF (secondary dx) using ICD-10-CM, Loop 2400 SV1/SV2 with CPT/HCPCS, REF*G1 prior auth; ICD-10-PCS for inpatient procedures`	Ardia would rarely see the raw 837 — it sees the payer's rendering of it via the CARIN Blue Button EOB. State that provenance rather than implying claim-level access.
Remittance / adjudication outcome	`ExplanationOfBenefit.outcome, .item.adjudication (submitted, eligible, deductible, copay, benefit), .total, .payment`	`X12 835: CLP02 claim status code, CLP04 paid amount, CAS01 group code (CO contractual, PR patient responsibility, OA other, PI payer initiated), CAS02 CARC, CAS03 amount; LQ01=HE with LQ02 RARC`	The CAS group code is the field that tells a patient whether they owe the money. CO means the provider eats it; PR means the patient does. Almost no consumer app surfaces this distinction, and it is the whole ballgame.
Denial reason, in patient-readable form	`ExplanationOfBenefit.item.adjudication.reason, .processNote.text, ClaimResponse.error.code`	`CARC (e.g. CO-50 not deemed medically necessary, CO-197 authorization absent, CO-96 non-covered charge, CARC 204 not covered under the current benefit plan, CO-16 claim lacks information, CO-45 charge exceeds fee schedule, CO-151 frequency not supported) paired with RARC (e.g. MA130 for incomplete/invalid claim information)`	Show the literal code AND a plain-language restatement, always labelled as an explanation and never as a judgement about whether the care was needed. This is where the non-diagnostic gate matters most: 'not medically necessary' is a payment code, not a clinical opinion, and the copy must say so.
Governing coverage policy for the service	`DocumentReference (policy citation, .content.attachment.url, .context.related → the Claim/EOB), or a Basic profile linked from ExplanationOfBenefit.item`	`CMS Medicare Coverage Database: NCD identifiers (e.g. NCD 240.2 Home Use of Oxygen; NCD 210.14 lung cancer screening with LDCT) and DME MAC / A-B MAC LCD + Local Coverage Article identifiers; for MA, the plan's own published medical policy document id`	Resolve LCD/LCA numbers live from the CMS Medicare Coverage Database at render time and show the version date — do not hard-code them, they are retired and superseded constantly. For an MA plan, the plan's medical policy governs and may be stricter than the NCD only where CMS permits.
Appeal path, deadline and current stage	`Task (.businessStatus, .restriction.period for the deadline), Communication / CommunicationRequest, DocumentReference for the denial notice`	`Medicare Advantage Part C: 60 calendar days from the denial notice to request a plan reconsideration; expedited pre-service 72 hours, standard pre-service 30 days, payment 60 days; Part D redetermination 60 days, coverage determination 72h standard / 24h expedited; CMS-10003 integrated denial notice`	The countdown is the single highest-value object in this domain and the easiest to get wrong. Anchor it to the date on the notice, not the date Ardia ingested it, and show 'as calculated from the notice dated X' so a wrong anchor is visible.
DME coverage, rental month and continued-use documentation	`DeviceRequest.codeCodeableConcept, Device, SupplyRequest / SupplyDelivery, Coverage + ExplanationOfBenefit for the rental line`	`HCPCS Level II (e.g. E1390 stationary oxygen concentrator, E0431 portable gaseous oxygen system, E0470/E0471 respiratory assist devices, E0601 CPAP, A-codes for supplies); modifiers RR (rental), KX (requirements met), GA/GY/GZ on Original Medicare; capped-rental month count`	Oxygen is where elder-care coverage most often breaks: qualifying blood gas or oximetry values, a 36-month capped rental clock, supplier network status and a continued-need reassessment all interact. Surfacing the rental month and the next documentation date prevents a mid-winter service interruption.
Molecular / genomic test coverage and MolDX registration	`ServiceRequest.insurance, Claim.item.productOrService, ExplanationOfBenefit.item.adjudication`	`CPT Category I molecular codes and CPT PLA codes (the 0001U–xxxxU proprietary-lab-analysis range) for the assay; MolDX DEX Z-code identifier reported with the claim line per the MAC's instruction; LOINC for the resulting observation`	Do not fabricate a Z-code or a PLA number — resolve the Z-code from the DEX registry and the PLA code from the assay's own listing. An unregistered or mismatched Z-code is a common, entirely administrative denial for a test the patient already had. This is the direct coverage-side expression of the 2027 PAMA cliff: as CLFS rates fall, labs narrow networks and push more of these to patient responsibility.
Estimated patient responsibility before service	`CoverageEligibilityResponse.insurance.item.benefit (as inputs), plus a locally computed estimate carried as an extension — not as an EOB`	`Derived from 271 accumulators + plan cost-share + contracted rate where known`	Must be visually distinct from a payer-adjudicated amount and labelled an estimate with its inputs shown. A Good Faith Estimate under the No Surprises Act is a different, provider-issued instrument and should not be conflated with this.
Consent scope governing what the care collaborator sees	`Consent (.provision.purpose, .provision.class, .provision.period, .provision.actor), Patient.link, RelatedPerson`	`HL7 consent policy / consent scope value sets; role labels only — no names stored in the display layer`	Coverage data must be independently scopable from clinical data. An adult child may legitimately need the deductible and the appeal deadline while having no business seeing a behavioral-health claim line. Default to clinical-redacted, billing-visible, and require an explicit grant to widen it.
Coordination of benefits / secondary coverage	`Coverage.order, Coverage.subrogation, multiple Coverage resources`	`X12 271 EB01=R (other or additional payor); Medicare Secondary Payer rules`	Also carries Part D Low Income Subsidy, state pharmaceutical assistance and manufacturer copay programs — commonly the difference between an affordable and an abandoned prescription for this patient profile.
Source, retrieval timestamp and confidence of every coverage fact	`Provenance (.agent, .recorded, .entity), Meta.source, Meta.lastUpdated on every resource above`	`n/a — internal provenance model`	Non-negotiable in this domain. A stale accumulator or a stale network flag causes real financial harm. Every number in the UI shows where it came from and when, and goes visibly grey past a freshness threshold rather than silently persisting.

FHIR R4 — Coverage, CoverageEligibilityRequest, CoverageEligibilityResponse, Claim, ClaimResponse, ExplanationOfBenefit, InsurancePlan, DeviceRequest, SupplyDelivery, Task, Consent, RelatedPerson, DocumentReference, ProvenanceCARIN Blue Button IG (patient-facing ExplanationOfBenefit profiles)Da Vinci PDex, PDex US Drug Formulary, Plan-Net (provider directory and network), CRD / DTR / PAS (prior authorization)CMS-9115-F Interoperability and Patient Access final rule (payer Patient Access API)CMS-0057-F Interoperability and Prior Authorization final rule (FHIR Prior Authorization API, 2027)X12 270/271 health care eligibility benefit inquiry and responseX12 278 health care services review — request for review and responseX12 837P / 837I health care claimX12 835 health care claim payment/adviceCARC (Claim Adjustment Reason Codes) and RARC (Remittance Advice Remark Codes), X12 external code listsCAQH CORE operating rules for eligibility and claim statusICD-10-CM (diagnosis on the claim), ICD-10-PCS (inpatient procedures)CPT and CPT PLA codes; HCPCS Level II with DME modifiersLOINC (resulting observations), RxNorm (formulary drug identity), NDC (dispensed package), SNOMED CT (clinical concepts), CVX (immunizations)MolDX DEX Z-code identifiers (Palmetto GBA registry)CMS Medicare Coverage Database — NCD, LCD and Local Coverage Article identifiersNCPDP Telecommunication D.0 and NCPDP SCRIPT ePAMedicare Advantage Part C and Part D appeal timeframes; CMS-10003 integrated denial notice; CMS-R-131 ABN (Original Medicare only)HIPAA Privacy and Security Rules; 42 CFR Part 2; GINA Title I; ONC Information Blocking rule; No Surprises Act Good Faith Estimate

Synthetic sample — no real patient data, no names

row_type	coverage_type	fhir_resource	member_id_display	group_id_display	plan_identifier
coverage_enrollment	Medicare Advantage HMO (Part C, includes Part D)	Coverage	•••••4417 (masked; full value gated behind step-up auth)	•••••082	CMS contract H-number + PBP (synthetic placeholder, not a real plan)
eligibility_check_271		CoverageEligibilityResponse
accumulator_medical		CoverageEligibilityResponse.insurance.item.benefit
claim_denied
molecular_test_pended
dme_oxygen		DeviceRequest + SupplyDelivery + ExplanationOfBenefit (rental line)
formulary_drug		Da Vinci US Drug Formulary List/MedicationKnowledge; MedicationRequest.insurance
accumulator_part_d
out_of_network_claim
prior_auth_pending
claim_information_denial
consent_scope		Consent + RelatedPerson (role label only, no name stored in the display layer)

What Ardia adds here

Epic MyChart shows the visit and a bill. Apple Health shows steps and a lab value. Neither shows the adjudication. Ardia's design puts the 271 eligibility response, the 837 claim, the 835 remittance and the CARC/RARC denial on the SAME timeline row as the clinical event that generated them — so the chest CT ordered by pulmonology, the radiology report, the CO-50 denial and "42 of 60 days left to file a plan reconsideration" are one object, not four systems. It also does three things no clinical-only 360 attempts: it names the governing coverage policy (NCD/LCD or MA plan medical policy) beside the ordered service, so the patient sees WHY; it tracks MolDX Z-code and PA state for molecular tests, where the 2027 PAMA cliff will push more lab cost onto patients; and it renders accumulators as progress, not a number. Honestly: Ardia adds nothing on raw eligibility accuracy — the payer is always the source of truth — and nothing on paying the bill. It is a comprehension and deadline layer, not a transaction layer.

Where the data comes from.

The payer is the only authoritative source, and there are four realistic paths to it, in ascending order of difficulty. (1) CMS-9115-F Patient Access APIs — every Medicare Advantage plan is required to expose FHIR R4 endpoints for coverage, adjudicated claims (CARIN Blue Button ExplanationOfBenefit), clinical data (PDex) and the drug formulary, released to a patient-authorized third-party app. This is the correct first integration: mandated, patient-consented, no payer contract negotiation, and it carries exactly the claim-and-denial content this domain needs. Difficulty: moderate — app registration, attestation, an OAuth flow an 80-year-old can actually complete, and highly variable payer implementation quality. (2) Real-time X12 270/271 eligibility via a clearinghouse (Availity, Waystar, Change/Optum). Difficulty: high for a consumer-facing company — trading-partner agreements are written for providers and typically do not permit this use; expect to need a provider sponsor or a covered-entity relationship. (3) The clinical side of the pairing — the order, the report, the medication — comes from the EHR via FHIR R4, SMART on FHIR patient-mediated access. Moderate. (4) X12 837/835 in raw form: realistically unavailable to Ardia. Ardia sees the payer's EOB rendering, not the provider's remittance, and the design must say so rather than implying claim-file access. DME and pharmacy add two more: supplier portals (poor APIs, often scrape-only) and NCPDP-based pharmacy benefit data, usually reachable only through the plan's own Part D data rather than the pharmacy. Note plainly: none of these connections exist. Ardia has no BAA, no DUA, no payer credential and no clearinghouse relationship today.

Risks in this domain

Re-identification: coverage records are among the most identifying data in healthcare. A contract/PBP number plus a five-digit ZIP plus an age of 80 plus a rare molecular test narrows to a very small population even with the name stripped. HIPAA Safe Harbor de-identification is not achievable on a longitudinal coverage timeline; this data must be treated as fully identified PHI and protected accordingly.
Sentinel's name-detection gap is the gating dependency and it bites hardest here. Coverage artifacts are saturated with plain personal names in free-text positions the redactor does not reliably catch: the subscriber name in the 271, rendering and billing provider names across the 835 and EOB, the denial letter body, the appeal correspondence, the consent record naming the adult child. Until name detection is fixed and independently tested, no real coverage PHI can be ingested at all.
42 CFR Part 2: a claim line from a Part 2 program, or a CARC on a substance-use-disorder service, re-discloses that treatment. Part 2 requires consent specific to the disclosure and prohibits redisclosure; a general HIPAA authorization is not enough. Part 2-sourced claim lines must be segmented at ingest and suppressed by default from any collaborator view, and Ardia must be able to prove the segmentation, not just assert it.
GINA: coverage and claim data for a genetic or molecular test reveals that the test happened, and a denial rationale can reveal the indication. GINA restricts genetic information in health-plan underwriting and employment; Ardia holding a searchable record of genetic-test coverage events creates a discovery and subpoena target regardless of intent.
Elder financial exploitation: this domain concentrates exactly what an exploiter wants — MBI, member and group ids, plan name, payment amounts, deductible status, and evidence of which bills are unpaid. Full identifiers must be masked by default, high-value fields must require step-up authentication to reveal, and every reveal must be logged and visible to the patient.
Caregiver access without contemporaneous consent: an adult child helping with a denial can drift into a surrogate with unbounded access, and an 80-year-old with fluctuating capacity may not remember granting it. Consent must be time-bounded, scoped separately for billing versus clinical content, re-affirmed on a schedule, revocable by the patient in one action, and always visible to the patient as 'this person can currently see X'.
Surfacing a result or an adverse coverage event before a clinician has seen it: a denial notice referencing an indication, or an EOB line naming a procedure, can disclose a diagnosis to a patient in a billing context with no clinician present. This is the Information Blocking rule colliding with patient safety. The design must hold coverage artifacts whose content implies an undelivered clinical finding behind the human_in_the_loop gate.
Financial-harm-by-error: a wrong appeal deadline, a stale accumulator or a stale network flag can cost the patient real money or a missed appeal window. Every deadline shows its anchor date and source; expired or unverifiable data goes visibly stale rather than being displayed as current.
Advice-boundary risk: explaining a denial sits close to legal and insurance advice, and telling someone what to do about a CO-50 is not the same as telling them what CO-50 means. The scope_of_practice gate must hold the line at explanation plus the plan's own published procedure, with escalation to SHIP counselors, the plan, or the ordering practice rather than a recommendation from Ardia.
Non-diagnostic integrity: 'not medically necessary' is a payment determination. If Ardia renders it in a way that reads as a clinical opinion, the view has diagnosed by implication. Copy must be gated and tested for this specific failure.
Payer terms and data-use limits: CMS-9115-F Patient Access API data is patient-authorized and carries app-attestation and privacy-policy obligations; clearinghouse 270/271 access carries trading-partner agreements that typically forbid the consumer-facing use described here. A BAA plus, where applicable, a DUA must be in place before a single byte moves, and none exist today.
Safety escalation: a patient blocked from a rescue inhaler by a formulary or PA denial is a clinical situation, not an administrative one. Any coverage event affecting an acute respiratory medication must route to the safety_escalation gate, with 911 for a suspected emergency and a same-day human contact path otherwise.

Build status.

Nothing in this domain is built. There is no coverage schema, no 270/271 client, no clearinghouse relationship, no CARIN Blue Button or PDex client, no payer credential, no parser for 835 CAS/LQ segments, no appeal-deadline clock, no LCD/NCD resolver, and no UI. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data. Every row above is synthetic and hand-written. What is needed first, in order: (1) close the Sentinel de-identification gap — Sentinel does not reliably redact plain personal names today, and coverage artifacts are dense with them (subscriber name on the 271, provider names on the 835, the adult child's name on a consent record), so no real PHI can be held until that is fixed and independently tested; (2) a signed BAA with any data source, plus a DUA for payer APIs; (3) a payer or clearinghouse connection — realistically CMS-9115-F Patient Access APIs first, because they are mandated and patient-authorized, before any 270/271 or clearinghouse deal; (4) the six deterministic gates (de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop) wired in front of the Gemini gemini-flash-lite explanation engine — Claude is not the runtime engine — with a failed gate withholding the answer entirely rather than degrading it; (5) legal review of surfacing denial and appeal information, which is adjacent to advice. Until (1) and (2) are done this is a design document, not a feature.

•

Claims, EOB, denials and appeal status

Why it matters

An 80-year-old with COPD (GOLD group E), HFrEF, type 2 diabetes and hypertension does not experience "a claim." They experience a chest CT their pulmonologist ordered, then a letter months later, then a bill, then silence. The order, the result, the denial notice and the bill each live in a different system: hospital portal, independent pulmonology practice, reference lab, DME supplier, and the Medicare Advantage plan's own member site. Nobody holds all five.

The concrete failure this domain fixes: a service is denied CO-50 or CO-197, the plan mails a Notice of Denial of Medical Coverage, and the 60-calendar-day clock to request a plan reconsideration starts running from that notice date. The patient reads it as a bill, not a decision. The adult child acting as care collaborator finds the letter six weeks later, in a stack, with nine days left, not knowing that what would overturn it is a single pulmonology note documenting the failed prior therapy the policy requires. The appeal window closes on a service that was covered all along, and the household pays a bill it did not owe. That is the failure. It is administrative, it is common, and it is fixable with data.

What this domain holds

Data element	FHIR R4	Code system	Note
Claim identifier and payer control number	`Claim.identifier / ExplanationOfBenefit.identifier`	`X12 837 CLM01 (patient control number); X12 835 CLP07 (payer claim control number)`	The join key between what the provider submitted and what the payer returned. Without CLP07 you cannot reconcile an 835 line back to the 837 line, and you cannot follow a claim through resubmission.
Claim type and submission format	`ExplanationOfBenefit.type, .subType`	`X12 837P professional / 837I institutional / 837D dental; NCPDP D.0 for pharmacy; CARIN Blue Button (C4BB) EOB profile selection`	Determines which C4BB EOB profile applies (Outpatient Institutional, Professional NonClinician, Inpatient Institutional, Pharmacy) and therefore which adjudication fields are even meaningful.
Billing, rendering and ordering provider	`ExplanationOfBenefit.provider, .careTeam.provider, .careTeam.role`	`NPI (NPPES); provider taxonomy (NUCC code set)`	Stored as NPI plus taxonomy. Rendered in the UI as a role label only - 'pulmonology', 'the hospital', 'the DME supplier' - never as a clinician's name, per the no-names constraint.
Service line procedure or item	`ExplanationOfBenefit.item.productOrService`	`CPT / HCPCS Level II; ICD-10-PCS on inpatient institutional claims; NDC on pharmacy claims`	Examples relevant to this patient: 71250 CT thorax without contrast, 94010 spirometry, 94729 DLCO add-on, 93306 complete echo, 83036 hemoglobin A1c, E1390 oxygen concentrator, G0480 definitive drug testing 1-7 classes.
Line modifiers	`ExplanationOfBenefit.item.modifier`	`CPT/HCPCS modifiers - e.g. 26/TC professional-technical split, 59 and the X{EPSU} subset, KX (documentation on file), GA/GX/GY/GZ (ABN and statutory-exclusion signalling)`	Modifiers are frequently the actual cause of a denial. A missing KX on a DME or therapy line, or a GZ where a GA was intended, changes liability from plan to patient.
Diagnosis codes and line-level pointers	`ExplanationOfBenefit.diagnosis.diagnosisCodeableConcept, .item.diagnosisSequence`	`ICD-10-CM; X12 837 HI segment`	Claim diagnoses are billing assertions, not confirmed diagnoses. For this patient: J44.1, J44.9, I50.22, E11.9, I10, J96.11, Z99.81. Must be labelled in the UI as 'the code used for billing', never as 'your diagnosis'.
Dates of service and statement period	`ExplanationOfBenefit.item.servicedDate / servicedPeriod, .billablePeriod`	`X12 837 DTP segments`	The anchor that lets a claim line sit on the same timeline row as the ServiceRequest, the DiagnosticReport and the ImagingStudy that produced it. This alignment is the entire point of the domain.
Revenue code and DRG assignment	`ExplanationOfBenefit.item.revenue, .supportingInfo (drg)`	`NUBC revenue codes; MS-DRG (e.g. 190/191/192 for COPD with MCC / with CC / without CC or MCC)`	Applies to the inpatient exacerbation admission. The DRG explains why an entire multi-day stay produced one payment amount and one patient day-copay rather than line-by-line charges.
Charged, allowed, plan-paid and adjustment amounts	`ExplanationOfBenefit.item.adjudication.category + .amount`	`X12 835 CLP03/CLP04/CLP05, SVC02/SVC03, CAS segments, AMT; C4BB adjudication value set`	Four numbers that patients routinely confuse: billed, allowed, plan paid, patient owes. Displaying billed charge as if it were what is owed is the single most common EOB misreading.
Patient responsibility breakdown	`ExplanationOfBenefit.item.adjudication (deductible, coinsurance, copay, noncovered)`	`CARC group PR with PR-1 deductible, PR-2 coinsurance, PR-3 copayment; X12 835 CAS with group code PR`	Separating true cost-share from a full-denial balance matters: a PR-2 coinsurance is owed, a CO-50 balance may be entirely reversible on appeal, and a CO-45 contractual reduction is never patient liability.
Denial / adjustment reason	`ExplanationOfBenefit.item.adjudication.reason; ExplanationOfBenefit.processNote`	`CARC - X12 external code list 139 - with group codes CO, PR, OA, PI`	The differentiator field. CO-50 not deemed medically necessary, CO-197 precertification/authorization absent, CO-16 claim lacks information, CO-151 information does not support this frequency, CO-96 non-covered, CO-29 timely filing expired.
Remittance remark codes	`ExplanationOfBenefit.item.adjudication.reason (RARC slice) / processNote`	`RARC - X12 external code list 411 - e.g. N115 decision based on a Local Coverage Determination, M127 missing patient medical record, N130 consult plan benefit documents`	RARC is where the actionable detail sits. CO-50 alone is unactionable; CO-50 plus N115 tells you exactly which coverage policy to read and argue against.
Coverage policy cited by the denial	`ExplanationOfBenefit.supportingInfo; DocumentReference (policy PDF)`	`Medicare Coverage Database LCD identifier (L-number) or NCD manual section; MA plan internal medical policy identifier`	Do not fabricate L-numbers. The design stores the identifier the payer actually returns and resolves it against the published Medicare Coverage Database; if no policy is cited, the field stays empty and says so.
Molecular test identity behind an unlisted code	`ExplanationOfBenefit.item.productOrService (81479 unlisted molecular pathology, or a PLA code) with the registry identifier in .item.detail or .supportingInfo`	`CPT PLA codes; CPT 81479; MolDX DEX Z-Code (a five-character alphanumeric identifier beginning with Z, assigned in the DEX registry - specific values not invented here)`	Directly serves molecular diagnostics and the 2027 PAMA rate cliff. As CLFS rates fall, denials and documentation demands rise, and a missing or mismatched Z-Code is a routine cause of a molecular claim denying with no clinical dispute at all.
Prior authorization / referral reference	`Claim.insurance.preAuthRef, ExplanationOfBenefit.insurance.preAuthRef; Da Vinci PAS Claim/ClaimResponse`	`X12 278 request/response; Da Vinci Prior Authorization Support; CMS-0057-F Prior Authorization API (compliance 2027)`	CO-197 denials are decided here, before the service happens. A patient-visible record of whether an authorization existed, and its number, is the fastest route to overturning a CO-197.
Eligibility and benefit snapshot as of the date of service	`Coverage; CoverageEligibilityRequest / CoverageEligibilityResponse.insurance.item`	`X12 270 inquiry / 271 response, EB segments; Medicare Beneficiary Identifier (MBI); MA contract and plan benefit package identifiers`	Retrospective eligibility matters because a surprising number of denials are simply 'wrong plan on file' - a CO-109 or an eligibility-date mismatch, not a clinical judgement at all.
Benefit accumulators	`ExplanationOfBenefit.benefitBalance.financial`	`C4BB / CARIN accumulator categories; MA maximum out-of-pocket (MOOP)`	Deductible met, MOOP progress, Part D phase. Lets the view answer 'why did this cost more than last time' without a phone call.
In-flight claim status	`Task (business status) and ClaimResponse.outcome; ExplanationOfBenefit.status`	`X12 276 inquiry / 277 response and 277CA acknowledgment, using the Claim Status Category Codes and Claim Status Codes external code lists`	The gap between 'submitted' and 'adjudicated' is where patients assume something went wrong. Showing pended vs rejected-at-the-clearinghouse vs finalized removes a whole class of anxiety.
Denial notice document	`DocumentReference (linked to the EOB via .context.related)`	`CMS-10003 Notice of Denial of Medical Coverage or Payment / Integrated Denial Notice; Medicare Summary Notice for FFS; plan-issued member EOB`	The notice date - not the 835 date, not the service date - is what starts the appeal clock. Capturing the notice itself, including a photographed paper letter, is a hard requirement for computing the deadline honestly.
Appeal case record	`Task with focus = Claim/ExplanationOfBenefit; Communication and CommunicationRequest for correspondence`	`No national code system exists for consumer appeal state; the design uses an internal status vocabulary aligned to the CMS appeal level names`	Be explicit in the UI that appeal status is Ardia's own tracking construct, reconciled against payer correspondence, not a code the payer transmits.
Appeal deadline clock	`Task.restriction.period.end; Task.input (notice date, clock basis, jurisdiction)`	`Derived from regulation, not from a code system: Medicare Advantage - 60 calendar days from the denial notice to request a plan reconsideration; Medicare FFS - 120 days from the initial determination to request redetermination; Part D - 60 days to request a redetermination; ERISA commercial - typically 180 days for internal appeal`	Every displayed clock must show its basis date, its source document, and a plain statement that the plan's own notice governs. A wrong countdown is worse than no countdown.
Appeal level and reviewing entity	`Task.partOf chain (one Task per level)`	`MA: plan reconsideration, then automatic forward to the Independent Review Entity, then ALJ hearing at OMHA subject to the annual amount-in-controversy threshold, then Medicare Appeals Council, then federal district court. FFS: redetermination by the MAC, reconsideration by the QIC, then ALJ, Council, court`	Each level has its own filing window and its own decision deadline (e.g. MA expedited 72 hours, MA standard pre-service 30 days). The chain, not a single deadline, is what a family actually needs to see.
Evidence bundle attached to the appeal	`DocumentReference + Provenance, referenced from Task.input; Binary for the actual file`	`LOINC document type codes for clinical notes (e.g. 11488-4 consult note, 34117-2 history and physical, 18842-5 discharge summary); PDF/CDA/FHIR Document mime types`	What actually gets attached: the pulmonology note, the prior therapy trial, the oximetry or blood gas result for oxygen, the ordering provider's signed order, the pathology or molecular report.
Evidence gap - what would overturn this	`Task.input with a coded requirement plus a human-readable statement; no FHIR element is purpose-built for this`	`Derived by deterministic mapping from CARC + RARC + the cited LCD/NCD or plan policy criteria to a required artifact; not a coded standard`	This is Ardia-authored logic, and must be labelled as such. It is administrative and evidentiary, never clinical: it says 'the policy requires documentation of X', never 'you have X' or 'you should have X'.
Appeal outcome and reversal remittance	`A replacement ExplanationOfBenefit; PaymentReconciliation; PaymentNotice`	`X12 837 CLM05-3 claim frequency code 7 (replacement) or 8 (void); X12 835 claim status code indicating reversal of a previous payment`	Closing the loop is what makes the timeline trustworthy. A denial that was later overturned must visibly resolve, with the corrected patient responsibility, not just disappear.
Timely filing and window-derived flags	`Extensions on Claim / Task`	`Medicare 12-month timely filing limit; plan-specific commercial limits; CO-29 when it has already expired`	Distinguishes 'you can still appeal this' from 'this window closed and the remaining question is whether the provider can bill you at all'.
Pharmacy claim adjudication and Part D determinations	`ExplanationOfBenefit (C4BB Pharmacy profile); MedicationRequest linkage`	`NCPDP D.0 with NCPDP reject codes (e.g. 70 product not covered, 75 prior authorization required, 76 plan limitations exceeded); NDC; RxNorm`	With 6+ medications across 3 prescribers and 2 pharmacies, a Part D rejection at the counter is the most frequent coverage event this patient will experience - and it runs on a different appeal track from Part C medical denials.
Consent scope covering financial and sensitive data for the care collaborator	`Consent.provision (purpose, class, code, period) with per-domain restrictions`	`HL7 ActCode information sensitivity policy values (e.g. ETH substance abuse, PSY, HIV, GDIS genetic disease); 42 CFR Part 2 handling labels`	The adult child's access must be scoped per domain and per sensitivity class. A collaborator may legitimately see the oxygen DME denial and legitimately not see a toxicology or genetic claim line.
Provenance of every row	`Provenance.agent, .entity, .recorded`	`Not a clinical code system; records source system, retrieval method and timestamp`	Distinguishes a row pulled from a payer Patient Access API from one transcribed by the patient off a paper letter. Confidence in a deadline depends entirely on which of those it is.

HL7 FHIR R4 - Claim, ClaimResponse, ExplanationOfBenefit, Coverage, CoverageEligibilityRequest/Response, PaymentReconciliation, PaymentNotice, Task, Communication, DocumentReference, Consent, Provenance, Account, InvoiceCARIN Blue Button (C4BB) Implementation Guide - EOB profiles for Inpatient Institutional, Outpatient Institutional, Professional NonClinician, Oral, PharmacyDa Vinci Payer Data Exchange (PDex), Prior Authorization Support (PAS), Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR)CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) - Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs, including denial reasons, with 2026-2027 compliance datesX12 270/271 eligibility inquiry and responseX12 276/277 claim status, and 277CA claim acknowledgmentX12 278 prior authorization request and responseX12 837P / 837I / 837D claim submissionX12 835 electronic remittance advice (CLP, SVC, CAS, PLB, AMT segments)X12 external code list 139 - Claim Adjustment Reason Codes (CARC) with group codes CO, PR, OA, PIX12 external code list 411 - Remittance Advice Remark Codes (RARC)X12 Claim Status Category Codes and Claim Status CodesNCPDP Telecommunication D.0 and NCPDP reject codes for pharmacy adjudicationICD-10-CM, ICD-10-PCS, CPT, CPT PLA, HCPCS Level II, NUBC revenue codes, MS-DRGLOINC (linked lab orders and clinical document types), SNOMED CT, RxNorm, NDCMedicare Coverage Database - National Coverage Determinations and Local Coverage Determinations with LCAsMolDX program and the DEX Z-Code registry for molecular test identificationMedicare Advantage appeals under 42 CFR Part 422 subpart M; Medicare FFS appeals under 42 CFR Part 405 subpart I; Part D appeals under 42 CFR Part 423 subpart MCMS-10003 Notice of Denial of Medical Coverage or Payment (Integrated Denial Notice); CMS-1696 Appointment of RepresentativeHIPAA Privacy, Security and Breach Notification Rules; 42 CFR Part 2; GINA; ONC information blocking rules (45 CFR Part 171)

Synthetic sample — no real patient data, no names

row	timelineDate	event	instrument	coverageType	memberIdentifier
eligibility	ISO-2026-01-02	Coverage verified for the benefit year	X12 271 response to a 270 inquiry	Medicare Advantage (Part C), HMO product	MBI on file - masked in this synthetic record
claim	ISO-2026-03-14 (about 6 months ago)	CT of the chest, ordered by pulmonology for worsening dyspnea and suspected interstitial change over COPD	837P submitted by the imaging facility; 835 returned 22 days later
appeal-outcome	ISO-2026-05-06	Plan reconsideration decided - favorable, denial overturned	Plan reconsideration decision letter; corrected 835 with a claim status code indicating reversal of the previous payment; replacement claim carried frequency code 7
claim	ISO-2026-04-02 (about 5 months ago)	Molecular pulmonary panel run at the reference lab	837P from the reference lab; 835 returned 11 days later
claim	ISO-2026-04-21 (about 4.5 months ago)	Stationary oxygen concentrator, monthly rental from the DME supplier	837P from the DME supplier; 835 returned 16 days later
claim	ISO-2026-06-11 (about 3 months ago)	Inpatient admission for a COPD exacerbation, 4 days	837I from the hospital; 835 returned 27 days later
claim	ISO-2026-07-09 (about 2 months ago)	Pulmonary function testing at the independent pulmonology practice	837P; 835 returned 9 days later
claim	ISO-2026-07-30 (about 6 weeks ago)	Definitive drug testing ordered as part of medication monitoring	837P from the reference lab; 835 returned 14 days later
pharmacy	ISO-2026-08-19 (about 3 weeks ago)	Refill rejected at the pharmacy counter	NCPDP D.0 real-time rejection at pharmacy 2 of 2
claim-status	ISO-2026-09-02 (about 1 week ago)	Cardiology echocardiogram - claim in flight	X12 277 response to a 276 status inquiry

What Ardia adds here

Epic MyChart shows the CT order, the radiology report and a hospital bill - but only for that health system, and its billing view is the provider's accounts receivable, not the plan's adjudication. Apple Health shows clinical records and holds no claims at all. Health Gorilla, Particle and Zus aggregate clinical data for providers; b.well and Validic assemble consumer records; none of them puts a CARC code, a coverage policy citation and a running appeal deadline on the same row as the imaging study that triggered them.

Ardia's addition is that single row: the order, the result, the denial reason, the policy cited, the days left, and the one document that would overturn it. Concretely, it is deterministic joins - 837 CLM01 to 835 CLP07, service date and NPI to ServiceRequest and DiagnosticReport, notice date to a regulatory clock - plus a CARC/RARC-to-evidence mapping.

Honestly, Ardia adds nothing to clinical data quality, nothing a payer's own Patient Access API cannot already return, and nothing at all if the patient never receives or photographs the paper denial notice that starts the clock.

Risks in this domain

Re-identification. Claims are among the most re-identifiable data that exist. Even with every name stripped, a series of dates of service, provider NPIs, a ZIP code, a rare procedure code and an age band identifies a specific person with high probability. De-identification of a claims timeline is materially harder than de-identification of a note, and safe-harbor removal of the eighteen identifiers does not by itself defeat linkage against public provider directories.
Sentinel's name-detection gap. Sentinel does not reliably redact plain personal names today. Claims data is full of them - subscriber and dependent names in 837 loops, guarantor names, signature blocks and adjuster names in denial letters, and free text in remark and appeal correspondence. A patient-360 holding real claims cannot ship until this is fixed. This is a hard gating dependency, not a backlog item.
42 CFR Part 2. A single claim line for opioid treatment program services, or a toxicology or counselling code, discloses substance use disorder treatment. Part 2 requires specific written consent for disclosure and constrains redisclosure beyond what HIPAA requires. Suppression must be designed so that the absence of data is not itself a signal - a visible hole in a timeline on a specific date is a disclosure.
GINA and genetic data. Molecular and genomic claim lines, MolDX Z-Codes and the diagnoses that accompany them reveal that genetic testing occurred and often what it was looking for. GINA restricts use in health insurance underwriting and employment, but does not cover life, long-term care or disability insurance. Exposing a molecular claim line to a family member who is also a household policy applicant creates a real, uncompensated harm.
Elder financial exploitation. A dollar-denominated, deadline-stamped view of an 80-year-old's obligations is exactly the map an exploiter wants: what is owed, to whom, and which bills feel urgent. It also gives phishing and 'pay this denied claim now' scams a script with true details in it. Any outbound notification must never contain a payment link, and the view must never present a payer balance as a payable action.
Caregiver access without consent. The adult child is a care collaborator under consent-scoped access, which is not the same as an authorized representative for appeals. Filing an appeal on the patient's behalf with a Medicare plan generally requires a valid appointment of representative (CMS-1696) or equivalent. Consent must be revocable by the patient at any time, scoped per domain and per sensitivity class, time-limited, and auditable - and revocation must take effect immediately in the collaborator's view.
Surfacing a result or a code before a clinician has seen it. Claim diagnosis codes are billing assertions, frequently 'rule-out' or working codes, and are often wrong. Rendering an ICD-10-CM code from a claim as 'your diagnosis' can tell an 80-year-old they have a condition nobody has confirmed or discussed with them. Every claim-derived clinical code must be labelled as a billing code, never as a finding, and never interpreted.
Wrong appeal clocks. If Ardia displays '41 days left' and the basis date is wrong - the 835 date instead of the notice date, the wrong appeal track, or a plan-specific window that differs from the regulatory default - and the patient relies on it and misses the deadline, the harm is direct and financial. Every clock must display its basis document and date, and must say plainly that the plan's own notice governs.
Practising law or acting as an advocate without authority. Telling a patient what evidence would overturn a denial edges toward regulated territory in some jurisdictions, and drafting or filing an appeal on their behalf clearly does. The design keeps output to administrative fact - what the code means, what the policy text requires, what the deadline is - and routes anything further to a human, with human-in-the-loop as a gate, not a courtesy.
Provenance and payer data quality. Payer Patient Access APIs return incomplete and lagging data; a claim absent from the feed is not proof it does not exist. Presenting an incomplete claims history as complete invites a patient to conclude nothing is pending when something is. Every row and every gap must carry its source and its retrieval time.
No BAA, no DUA, no lawful basis today. Ardia has never processed real patient data. Ingesting claims for any identified person without an executed BAA with the covered entity or business associate supplying it, and without patient authorisation where required, would be unlawful regardless of technical safeguards.

Build status.

Nothing in this domain is built. There is no ingestion pipeline, no 835 parser, no CARC/RARC-to-evidence mapping, no appeal clock engine, and no UI. This is a designed view on paper, described here for the first time.

The company context is unchanged and stated plainly: Ardia Precision Health has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data of any kind. Every code, dollar amount, date and denial in this design is synthetic and was authored for illustration. No patient, clinician or family member is named anywhere, because no real record exists to name and because the constraint is absolute regardless.

What is needed before a single real claim can be held, in order: (1) Sentinel's plain-name detection gap must be closed and independently evaluated - claims payloads and denial letters are dense with names, and this is the gating blocker; (2) an executed BAA with each data source, plus patient authorisation where required, and 42 CFR Part 2 consent handling for any record that touches it; (3) real access to payer data - per-payer CARIN Blue Button endpoints today, and the CMS-0057-F Patient Access and Prior Authorization APIs as they come into force through 2026-2027; (4) a maintained ingestion of the X12 CARC and RARC external code lists and the Medicare Coverage Database, since both change on a published schedule and a stale mapping produces confidently wrong guidance; (5) a deterministic rules engine for appeal clocks and evidence mapping, built and tested as rules rather than as model output; (6) the six gates - de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop - wired around any Gemini (gemini-flash-lite) explanation, with a failed gate withholding the answer entirely rather than degrading it; and (7) legal review of how far appeal assistance can go before it requires an appointed representative or constitutes regulated practice.

Until all seven are true, this view can be demonstrated only on synthetic data, and should be described to anyone - investor, clinician or patient - as a design, not a product.

•

Care team, care plan, goals and hand-off

Why it matters

An 80-year-old with COPD GOLD group E, HFrEF, type 2 diabetes and hypertension is not managed by one team. There is a primary care practice, an independent pulmonology practice, a cardiology practice, two dispensing pharmacies, a DME supplier for home oxygen, a Medicare Advantage plan care manager, and one adult child acting as care collaborator. Nobody holds the whole list. The concrete failure is ordinary and repeated: pulmonology starts a steroid taper and adjusts inhalers after an exacerbation, cardiology uprates the diuretic the same month, and neither sees the other's plan; the discharge follow-up that Medicare pays for under transitional care management is never scheduled inside 7 or 14 days; the adult child drives to an appointment that was moved; the POLST signed two years ago sits in a hospital scan nobody can retrieve at 2am; and the pulmonary rehab referral is authorised but the authorisation lapses before the first session. A care-team-and-plan domain fixes a coordination failure, not a clinical one: one role-labelled roster, one merged plan with goals someone actually owns, the next appointments in date order, the directive retrievable, and a hand-off the care collaborator can read without a clinical vocabulary.

What this domain holds

Data element	FHIR R4	Code system	Note
Care team roster entry (role only)	`CareTeam.participant.member (reference to PractitionerRole \| Organization \| RelatedPerson) with CareTeam.participant.role`	`NUCC Health Care Provider Taxonomy for the specialty role (e.g. 207RP1001X Pulmonary Disease, 207RC0000X Cardiovascular Disease); SNOMED CT practitioner-role concepts as an alternative binding; FHIR CareTeam participant role value set`	Rendered as a role label ONLY - 'pulmonology', 'primary care', 'cardiology'. The design deliberately does not display Practitioner.name or Organization.name to the patient-facing view, because Sentinel cannot yet be trusted to redact personal names downstream. Names may exist in the source resource and must be suppressed at render, not merely 'not shown by default'.
Care team status and period	`CareTeam.status (active \| inactive), CareTeam.period, CareTeam.participant.period`	`FHIR care-team-status required binding`	Answers 'is this person still on my team?' - the single most common stale field in every patient-facing roster. A pulmonologist seen once 3 years ago should fall off, not persist forever.
Consent tier per role	`Consent.provision.actor.role + Consent.provision.actor.reference, Consent.provision.type (permit \| deny), Consent.provision.class, Consent.provision.securityLabel`	`HL7 v3 ActCode sensitivity codes (ETH substance use, HIV, PSY, GDIS genetic disease information, SEX); HL7 v3 Confidentiality (N, R, V); obligation policy code NORDSCLCD for no-redisclosure; FHIR consent-policy / ActConsentDirective`	This is the load-bearing element of the whole domain. Each role gets an explicit tier: full, clinical-only, logistics-only, emergency-break-glass. The care collaborator tier is set by the patient, is revocable, and is time-boxed via Consent.provision.period.
Care collaborator relationship (no name)	`RelatedPerson.relationship, RelatedPerson.active, RelatedPerson.period; linked from CareTeam.participant`	`HL7 v3 RoleCode relationship codes (e.g. CHILD, SONC/DAUC, CAREGIVER); SNOMED CT person-role concepts`	Displayed as 'adult child / care collaborator'. RelatedPerson.name is never rendered. Legal authority (healthcare agent vs informal helper) is a separate field - conflating them is a real-world harm.
Emergency contact	`Patient.contact.relationship (+ Patient.contact.period)`	`HL7 v2/v3 contact-role codes (C = emergency contact); SNOMED CT relationship concepts`	Stored separately from care collaborator: an emergency contact is not automatically authorised to see records. Most portals blur this line.
Advance directive document	`DocumentReference (type = advance directive) with DocumentReference.content.attachment; Consent with Consent.category for directive-type consent`	`LOINC 42348-3 'Advance directives' section; SNOMED CT concepts for living will / healthcare power of attorney; document-type LOINC for the specific instrument`	Holds the document plus effective date, signing date, and whether a newer version exists. Displayed with an explicit 'last confirmed' date because a directive that has never been re-affirmed is a known failure mode.
POLST / portable medical order	`Consent (directive) plus ServiceRequest for each actionable order line (CPR, intubation, artificial nutrition), ServiceRequest.orderDetail, ServiceRequest.doNotPerform`	`SNOMED CT procedure concepts for resuscitation / mechanical ventilation / artificial feeding; POLST form fields are not themselves a code system - the orders inside them are coded to SNOMED CT. Do not fabricate a POLST-specific code; bind to the state registry identifier where one exists`	POLST is a clinician order set, not a patient preference note. Ardia would display it read-only, never let a patient or care collaborator edit it, and always show the signing clinician's ROLE and the form's jurisdiction.
Healthcare agent designation and activation state	`Consent.provision.actor with role = healthcare agent; Patient.contact; RelatedPerson`	`HL7 v3 RoleCode (HPOWATT / healthcare power of attorney concepts); SNOMED CT healthcare-agent concepts`	Must record whether the agent's authority is currently ACTIVE (patient lacks capacity) or DORMANT. Showing an agent as active when they are not is an elder-autonomy harm.
Care plan header	`CarePlan.status, CarePlan.intent (plan \| order), CarePlan.category, CarePlan.period, CarePlan.addresses (-> Condition)`	`SNOMED CT care-plan category concepts; CarePlan.addresses points at ICD-10-CM / SNOMED CT coded Conditions (J44.1 COPD with acute exacerbation, J44.9, I50.22 chronic systolic HF, E11.9 T2DM, I10 essential hypertension)`	Ardia merges plans from multiple CarePlan sources into one view and shows the SOURCE of each - it does not silently reconcile conflicting plans. Reconciliation is a clinical act.
Care plan activity	`CarePlan.activity.detail (or activity.reference -> ServiceRequest \| MedicationRequest \| NutritionOrder \| Appointment)`	`SNOMED CT procedure/regime-therapy concepts; CPT/HCPCS where the activity is a billable service (pulmonary rehabilitation, chronic care management, remote physiologic monitoring)`	Each activity carries an owner ROLE and a due date. An activity with no owner is displayed as unowned rather than assumed to belong to the patient.
Goal, target and measure	`Goal.description, Goal.lifecycleStatus, Goal.achievementStatus, Goal.target.measure, Goal.target.detailQuantity, Goal.target.dueDate, Goal.expressedBy`	`LOINC for the target measure (4548-4 HbA1c, 8480-6 systolic BP, 8462-4 diastolic BP, 29463-7 body weight); SNOMED CT for non-measurable goals (smoking cessation, exacerbation avoidance); CAT and mMRC dyspnea instruments have LOINC panel codes - bind to the published LOINC panel rather than inventing one`	Goal.expressedBy distinguishes a clinician-set target from a patient-stated goal ('be able to walk to the mailbox'). Ardia shows both and never rewrites a patient goal into clinical language.
Goal progress note (non-diagnostic)	`Goal.note, Goal.outcomeReference (-> Observation)`	`LOINC for the linked Observation; free text is uncoded`	Progress is shown as observed values against target. Ardia does not compute 'on track / off track' judgements - that is an acuity call and violates the non-diagnostic rule.
Upcoming appointment	`Appointment.status, Appointment.start/end, Appointment.serviceType, Appointment.appointmentType, Appointment.participant (role-labelled), Appointment.reasonCode`	`HL7 v2-0276 appointment-reason (ROUTINE, FOLLOWUP, WALKIN); SNOMED CT for service type; CPT for the expected service where known (99495/99496 transitional care management, 99497 advance care planning, G0438/G0439 annual wellness visit)`	Includes location logistics the care collaborator actually needs: is it in person, telehealth, does it require a driver, is a fasting lab drawn first.
Follow-up obligation / open loop	`Task.status, Task.intent, Task.code, Task.owner (role), Task.restriction.period, Task.focus (-> ServiceRequest \| DiagnosticReport \| ClaimResponse)`	`FHIR task-code; SNOMED CT for the clinical follow-up act; CPT for a billable follow-up encounter`	The 'what has not happened yet' list: a post-discharge call inside 7 days, a referral placed but not scheduled, a result acknowledged but not discussed, an appeal not filed.
Referral and its authorisation state	`ServiceRequest.status/intent, plus CoverageEligibilityRequest/Response and Claim (preauthorization) linkage`	`CPT/HCPCS for the referred service (e.g. pulmonary rehabilitation HCPCS G0424 or the current CPT respiratory-rehab codes); X12 278 health care services review for prior authorisation; X12 270/271 for eligibility`	This is where the Ardia differentiator lands inside this domain: a referral is shown WITH its authorisation status and expiry, not as a bare 'referred' line.
Coverage / denial event attached to a plan activity	`ClaimResponse.item.adjudication, ExplanationOfBenefit.item.adjudication.reason, Coverage`	`X12 837 claim, X12 835 remittance; CARC (e.g. CO-50 not deemed medically necessary, CO-197 precertification absent) and RARC supplementing codes; LCD/NCD policy identifiers; MolDX Z-code identifiers where a molecular test is in the plan`	Denials are joined to the care-plan activity that generated them, so a lapsed rehab authorisation or a denied molecular test appears as a plan blocker with an appeal clock, not as a separate billing screen.
Appeal clock	`Task (appeal) with Task.restriction.period.end; ClaimResponse linkage`	`Medicare Advantage plan reconsideration - 60 calendar days from the notice of denial for a standard party-filed request; 72-hour expedited pathway where delay jeopardises health. Source dates from the 835/denial notice, never computed from a guess`	Displayed as days remaining. Ardia must show the date the clock started and the document it came from, because a wrong clock is worse than no clock.
Caregiver hand-off packet	`Composition (hand-off summary) or CarePlan.supportingInfo; Communication / CommunicationRequest for the transmission`	`LOINC document-type codes for summary-of-care documents; C-CDA Care Plan document type where exchanged as CDA`	A generated, role-labelled, consent-filtered snapshot: active plan, goals, next 3 appointments, current oxygen setting and supplier, directive status, and open loops. Redacted by the care collaborator's consent tier before generation, not after.
Home oxygen and DME context	`DeviceRequest / DeviceUseStatement, ServiceRequest for the supplier order`	`HCPCS Level II DME codes (E1390 stationary oxygen concentrator, E0431 portable gaseous oxygen system); LOINC for the qualifying oximetry Observation`	Belongs in care team because the DME supplier is a de facto team member with recertification obligations that break the plan when missed. Pulmonary pillar.
Provenance and source attribution	`Provenance.target, Provenance.agent (role), Provenance.recorded, Provenance.entity`	`FHIR provenance-participant-type; source system identifiers`	Every roster row, goal and appointment shows which of the five sources it came from (hospital portal, independent pulmonology practice, reference lab, DME supplier, plan) and when it was last refreshed. Staleness is displayed, not hidden.
Consent audit trail	`AuditEvent.agent, AuditEvent.entity, AuditEvent.recorded; Consent.verification`	`DICOM/HL7 AuditEvent type and subtype codes; FHIR audit-event-action`	The patient can see every time the care collaborator viewed a section and can revoke a tier in one action. This is the control that makes caregiver access defensible.

FHIR R4: CareTeam, CarePlan, Goal, Appointment, Task, Consent, RelatedPerson, PractitionerRole, Organization, ServiceRequest, DeviceRequest, DocumentReference, Composition, Communication, Provenance, AuditEvent, ClaimResponse, ExplanationOfBenefit, Coverage, CoverageEligibilityRequest/ResponseUS Core (care team, care plan, goal, encounter, provenance profiles) as the realistic EHR-side contractC-CDA Care Plan document and Advance Directives section (LOINC 42348-3) for legacy exchangeSNOMED CT - procedures, regime/therapy, relationship and resuscitation-order conceptsICD-10-CM - conditions the plan addresses (J44.1, J44.9, I50.22, E11.9, I10)LOINC - goal target measures (4548-4, 8480-6, 8462-4, 29463-7), document types, published CAT / mMRC instrument panelsCPT / HCPCS - 99495 and 99496 transitional care management, 99490 and 99491 chronic care management, 99497 and 99498 advance care planning, G0438/G0439 annual wellness visit, 99453/99454/99457 remote physiologic monitoring, E1390 and E0431 home oxygenNUCC Health Care Provider Taxonomy - specialty role codes (207RP1001X pulmonary disease, 207RC0000X cardiovascular disease)HL7 v3 ActCode sensitivity (ETH, HIV, PSY, GDIS), Confidentiality (N, R, V) and obligation NORDSCLCD, via HL7 Data Segmentation for PrivacyX12 270/271 eligibility, 278 services review / prior authorisation, 837 claim, 835 remittance; CARC and RARC adjustment reason codesMedicare LCD/NCD coverage policy identifiers; MolDX Z-code identifiers for molecular tests appearing in the planMedicare Advantage organisation determination and 60-day plan reconsideration timeline; expedited 72-hour pathwayCMS Interoperability and Prior Authorization rule (CMS-0057-F) APIs, relevant to the 2027 timeframeNational POLST form framework plus state POLST/MOLST registry identifiers where a registry exists

Synthetic sample — no real patient data, no names

row_type	role_label	taxonomy	status	on_team_since	consent_tier
care_team	primary care	NUCC 261QP2300X (primary care clinic) / 207Q00000X family medicine	active	2019-03	full
care_team	pulmonology	NUCC 207RP1001X pulmonary disease	active	2022-11	full
care_team	cardiology	NUCC 207RC0000X cardiovascular disease	active	2023-06	full
care_team	dispensing pharmacy A (retail)	NUCC 3336C0003X community/retail pharmacy	active		clinical-only (medications and allergies)
care_team	dispensing pharmacy B (mail order)	NUCC mail-order pharmacy taxonomy	active		clinical-only (medications and allergies)
care_team	home oxygen / DME supplier		active		logistics-only
care_team	adult child / care collaborator		active		clinical + logistics + coverage; genetic (GDIS) and behavioural (PSY, ETH) sections DENIED by patient
care_team	Medicare Advantage plan care manager		active		coverage and appeals only - no clinical notes
care_team	emergency contact		active		none - contact only, no record access
care_plan_activity			blocked
care_plan_activity			active
care_plan_activity			overdue
care_plan_conflict
goal

What Ardia adds here

Epic MyChart shows the care team of the health system that owns MyChart. Apple Health shows what a connected institution publishes. Neither shows a plan assembled from a hospital portal, an independent pulmonology practice, a reference lab, two pharmacies and a DME supplier at once, and neither attaches money to it. Ardia's specific addition here is the coverage join: a pulmonary rehab referral displayed with its X12 278 authorisation window and 19 days of validity left; a denied chest CT displayed with CARC CO-50 and 38 of 60 days remaining for Medicare Advantage plan reconsideration, sitting in the same open-loop list as the missed transitional care management call. Second addition: per-role consent tiers with a visible audit trail, so caregiver access is granted, scoped, expiring and revocable rather than a shared password. Honestly, Ardia adds nothing to appointment booking, nothing to POLST authoring, and nothing MyChart cannot do inside a single system. Its value only appears when care is fragmented - which, for this patient, it is.

Where the data comes from.

Realistically multi-sourced, and that fragmentation is the point. Care team and care plan: EHR via FHIR R4 US Core (CareTeam, CarePlan, Goal), through SMART on FHIR patient-authorised access or Bulk Data where a provider partnership exists - moderate difficulty per source, high in aggregate because each source publishes a different partial roster and none of them reconcile. Appointments: FHIR Appointment where exposed, but many practices - especially the independent pulmonology practice and the DME supplier - expose nothing, so realistic fallback is patient- or caregiver-entered, clearly labelled as such. Advance directives and POLST: the hardest. Usually a scanned PDF in a hospital DocumentReference, sometimes a state POLST/MOLST registry, often only a paper copy in a drawer - expect low retrievability and design for 'we do not have this on file'. Consent tiers: Ardia-native, patient-set, no external source. Coverage, denial and appeal data: the payer via the CMS Patient Access API and, for the plan-side view, X12 270/271, 837 and 835 through a clearinghouse - contractually hard (clearinghouse agreement plus payer relationship) but technically well-specified. Home oxygen: DME supplier portals, typically no API, likely manual or caregiver-entered at first. Overall integration difficulty: high, and dominated by contracts and consent rather than by code.

Risks in this domain

Re-identification: a care-team roster is a quasi-identifier set. Specialty mix, visit cadence, a specific DME supplier and a geographic area can re-identify an 80-year-old even with every name stripped. Role-only labelling reduces the display risk but not the underlying dataset risk.
Sentinel does not reliably redact plain personal names today. Clinician names, family names and patient names arrive inside free-text CarePlan.description, Goal.note and hand-off narratives. Until this is fixed, no real record in this domain can be processed by the AI explanation path, and no real PHI can be held at all.
Caregiver access without genuine consent: an adult child who set up the account and 'helps' the patient click through the grant is a well-documented pattern. Time-boxed tiers, patient-visible audit, and independent re-affirmation reduce but do not eliminate this. A patient with fluctuating capacity is the hardest case and needs a human process, not a UI control.
Elder financial exploitation: coverage, claim and appeal data plus caregiver access is a map of the patient's money. Denial amounts, plan details and appointment schedules are exploitation-relevant. The coverage tier must be separately grantable and separately revocable.
42 CFR Part 2: any substance-use treatment provider on the roster, or an SUD-related plan activity, carries redisclosure restrictions that ordinary HIPAA-based sharing violates. Requires DS4P sensitivity labelling (ActCode ETH) plus the NORDSCLCD obligation, and safest initial behaviour is to exclude Part 2 sources entirely rather than mislabel them.
GINA and genetic sensitivity: a genetics or molecular-diagnostics role on the care team, or a plan activity referencing a MolDX Z-coded test, discloses genetic-testing status by implication. GINA restricts employer and health-insurer use; a leaked care-team roster can carry that inference without any result being shown. Genetic segments must be a separate consent tier (ActCode GDIS), off by default for caregivers.
Surfacing a result or plan change before a clinician has reviewed it: an open loop reading 'imaging result available, no follow-up recorded' can deliver bad news with no clinician present. Information-blocking rules push toward immediate release while safety pushes the other way. Requires an explicit, documented release policy and a clinician-in-the-loop gate for defined categories.
False reassurance from stale or partial data: an absent transitional care management call may simply mean the source is not connected. Displaying absence as 'did not happen' is a real harm. Every row must carry source and last-refreshed, and gaps must read as unknown.
Wrong appeal clock: a countdown computed from the wrong date could cause a patient to miss a 60-day plan reconsideration window. The clock must be sourced from the denial notice, show its start date and source document, and never be inferred.
Scope creep into clinical judgement: merging two conflicting plans, ranking goals, or labelling a goal 'off track' is acuity assignment and crosses the non-diagnostic line. The design must display conflicts, not resolve them.
POLST integrity: a stale, altered or misattributed portable medical order is a life-safety risk. Read-only display, signing role and date, jurisdiction, and registry linkage are mandatory; Ardia must never be the system of record for a POLST.
Emergency misuse: a care-team view is not an emergency system. Any suspected emergency must escalate to 911, and the design must not imply that a caregiver hand-off substitutes for calling a clinician.

Build status.

Nothing in this domain is built. There is no CareTeam ingestion, no Consent engine, no per-role tiering, no appointment feed, no directive store, no hand-off generator, and no coverage-to-plan join. This is a design on paper for a new Patient 360 page; the eleven existing solution-360 pages are unchanged and unrelated. Ardia has 0 customers, 0 pilots, 0 signed BAAs or DUAs, $0 revenue, $0 raised, and has never processed real patient data. Every row above is synthetic and constructed for this design. Gating dependencies, in order. (1) Sentinel's de-identification cannot reliably detect and redact plain personal names, and this domain is dense with them in free text - this must be fixed and independently tested before any real record is touched. (2) A signed BAA with each data source, plus DUAs where research or secondary use is contemplated. (3) A written consent model with legal review covering caregiver scoping, capacity, 42 CFR Part 2 and GINA, before any caregiver tier ships. (4) A documented result-release and safety-escalation policy, since this domain surfaces open loops. (5) Only then the engineering: FHIR ingestion from at least two independent sources, identity matching, provenance and staleness display, and the X12 835/CARC join that makes it differentiated. Any AI explanation runs on Google Gemini (gemini-flash-lite) behind six deterministic gates - de_identification, non_diagnostic, scope_of_practice, safety_escalation, honesty, human_in_the_loop - where a failed gate withholds the answer entirely rather than degrading it.

→

The product views behind this

All eleven solution 360° views Ardia One app Ardia Studio Research programme