For each NPI, whether the CMS National Provider Directory lists the provider in a network this plan names, for the plan's year.

Lists a state's counties, each with the FIPS code the coverage-area-county search takes.

Reconciles one patient's medication records into one clean medication list, returned as a collection of reconciled MedicationRequests with a Provenance for each.

Plans sold in a US county.

Plans sold in a US state.

Plans a person can buy on their own, or plans sold only to employer and union groups.

The decrypted payload is a FHIR Bundle. This profile aligns with the KTC specification for a Patient Shared Bundle at https://ktc-spec.github.io/#fhir-bundle-profile-patientsharedbundle

This profile aligns with https://ktc-spec.github.io/#documentreference-profile-patientshareddocumentreference that is part of the CMS Health Tech Ecosystem Kill the Clipboard use case.

Example of a payor organization with a required type

An allergy or intolerance recorded about a care recipient. Where the source system supplied no code for the allergen, the delivered code restates the substance the record's own reaction detail names — or states the value is unknown when nothing on the record names it. Nothing is invented.

A plan of care recorded about a care recipient. The required assessment-and-plan category is present on every delivered record - added by haau3 when the source system did not state one, always keeping any category the source did state - and activities are described inline, commonly with an unknown status, exactly as the source stated them.

A care team a health system recorded about a care recipient. The people on the team and the role each one holds are the source system's own. Every delivered record carries the identifier naming the source record it came from. A participant may state that its member is unknown, when the source named a role but not who fills it, or named someone whose record was not delivered.

A record that information was communicated about a care recipient. Delivered exactly as it arrived, and current sources send very little: the records seen so far carry only a status and a subject, with no message content, sender, recipient or time. Treat the presence of a record as the fact, not as a message to read.

A clinical summary document delivered for a care recipient — a continuity-of-care document or a progress note, as the practice that produced it wrote it up. Every delivered record says who it is about, what kind of document it is, when it was written and by whom. Its sections state what they contain; the records they list are delivered as ordinary records of their own type, and a section lists only those haau3 holds.

A health problem recorded about a care recipient — a diagnosis, a concern, an item on a problem list. Every delivered record states which list it belongs to in a recognized vocabulary; anything the source system stated is always preserved alongside. Where no code for the problem could be read from the source, the record states the code is unknown rather than carrying an invented one.

A consent or advance directive as the source system recorded it. Delivered as it arrived: current sources state the consent category as unknown rather than naming one, and send no provision detail. Nothing here is derived by haau3.

An insurance plan delivered for a care recipient. Every delivered record names the person it covers, says how they relate to the subscriber or states plainly that the relationship is unknown, and names a payer. Where a source system named more than one payer, the additional payers are delivered on the same record rather than dropped.

A diagnostic report delivered about a care recipient — laboratory results, imaging, cardiology, pathology — grouping the individual results it is based on, or carrying the written report itself. Every delivered record says what kind of report it is, or states plainly that the kind is unknown; every delivered record names the person it belongs to.

A clinical document or note about a care recipient. The document's content is delivered as an address naming a file held on the same server, and haau3 delivers that file with it; a document commonly carries several renderings of one note, one per attachment.

A visit recorded about a care recipient, delivered exactly as the source system stated it: the visit class carries the source's own vocabulary rather than a translated one, the visit type may state that the value is unknown when the source never gave one, and the practitioners the source recorded on the visit are preserved.

An insurance claim delivered for a care recipient — what was billed against a plan and what the plan said about it. Every delivered record names the person it belongs to, the plan it was billed against, and the provider who billed it.

A relative's health history as the source system recorded it — which relative, and what they were diagnosed with. Delivered exactly as it arrived: relationships are properly coded, conditions carry coded diagnoses, and no age or birth date for the relative is sent. Nothing here is derived by haau3.

A goal recorded about a care recipient, delivered as the source system stated it. The goal itself is commonly carried in the description's text rather than a code, and haau3 delivers both exactly as they arrived.

A vaccination recorded about a care recipient. Delivered exactly as the source system stated it, including dose-protocol details; the occurrence may arrive as a date or as the source's own free-text form.

What a Medicare Advantage or ACA Marketplace plan covers and what a member pays, from the files CMS publishes, as haau3's Plan Benefits API serves it on api.haau3.com. Every Plan Benefits InsurancePlan also conforms to the SBC InsurancePlan profile of the CARIN Digital Insurance Card guide, 2.0.0-ballot, and names both profiles in meta.profile.

A medication — the drug that prescriptions, statements and dispenses reference. Delivered exactly as the source system stated it: every vocabulary's coding is preserved, and a readable name is always present in the code's text even where individual codings carry no display.

A dose of medication actually administered to a care recipient. Delivered exactly as the source system stated it; an organization-performed administration names a PractitionerRole carrying that organization, which is how R4 expresses the shape.

A pharmacy dispense recorded about a care recipient — a fill or refill handed over. Delivered exactly as the source system stated it, naming both the medication and the prescription it filled; hand-over time and quantity are present, preparation time and days-supply are not sent by current sources.

A prescription or medication order recorded about a care recipient. Delivered exactly as the source system stated it: the medication may be a reference to a delivered Medication or an inline code, the order date is frequently absent because the source never stated one, and the requester is most often an organization.

A medication a care recipient is or was taking, as the source system recorded it. Delivered exactly as it arrived: assertion dates are never sent by current sources, effective dates rarely, and dosage is predominantly the source's own free text. Read together with haau3 MedicationRequests when assembling a medication list.

Something measured or recorded about a care recipient — a lab result, a vital sign, a survey answer, an exam finding. Delivered records always state who they are about and what kind of record they are; where the kind could not be determined it is stated as unknown rather than invented. Categories the source system supplied are always preserved.

The organization for a care recipient.

A care recipient.

A patient's self-reported answer to one of the three haau3 'My Story' prompts. Each Observation represents a single (patient, prompt) pair, identifiable by a stable haau3 namespace key for deterministic upsert via conditional update on Identifier. Mirrors PACIO ADI's ADI-CareExperiencePreference constraints; instances additionally claim PACIO conformance via meta.profile.

A practitioner involved in a care recipient's care. Conforms to US Core 6.1.0 Practitioner; NPI is the anchor for haau3 practitioner identity resolution.

A procedure recorded about a care recipient, delivered exactly as the source system stated it: the procedure code may state that the value is unknown when the source never gave one, and the performed date is absent when the source never stated it.

A questionnaire or form

An individual's response to a questionnaire/form.

What haau3 added to one reconciled medication entry: data no source record stated, such as the RxNorm clinical drug coding, or the RxNorm name used as the entry's text when no source named the medication in words. Each target is the entry, narrowed to one added element by the targetElement extension (the element's id) or the targetPath extension (a simple FHIRPath). haau3 is the author, the activity is append, and the rule-set version and RxNorm release are those the entry was reconciled against. Present only when haau3 added something to the entry.

The response of the reconcile-medications operation: a collection holding one reconciled MedicationRequest per clinical drug, one Provenance for each naming its source records, a second Provenance for each entry haau3 added data to, and an OperationOutcome only when a source record was skipped or the records named more than one patient. Entries are identified by urn:uuid, every reconciled MedicationRequest and Provenance names its haau3 profile in meta.profile, and the collection holds no Medication or List resources. A collection with no entries is a valid answer.

Where one reconciled medication entry came from: the source records it was built from, haau3 as the software that assembled it, when it was produced and the date it was evaluated as of, and the rule-set version and RxNorm release it was reconciled against. What haau3 added to the entry, if anything, is named by a second Provenance, a haau3 Reconciled Medication Additions Provenance.

One entry in a reconciled medication list: one clinical drug (its ingredients, strengths and dose form) for one patient, computed by software from that patient's medication records rather than curated by a person. Two strengths of the same medication are two entries. Every coding a source stated is kept, the RxNorm clinical-drug coding is added and marked when no source carried it, and any evidence codes it carries say why it has its status. The source records behind the entry are named in its Provenance, and anything haau3 added to it in a second, additions Provenance.

Individuals related to the patient like caregivers, family members, or guardians. Records created by haau3 carry no source identifier; records delivered from a source system carry the identifier naming the record they came from. The active flag may state that the value is unknown, since source systems do not send it.

An order or referral recorded about a care recipient, delivered exactly as the source system stated it: the timing may be a date, a period, a schedule, or absent, and the order code may state that the value is unknown when the source never gave one.

A sample collected from a care recipient that a test was performed on. Where the source system did not state what kind of sample it was, the record says the value is unknown rather than carrying an invented one.

Marks a coding that haau3 added to a reconciled medication entry. Every coding without this mark came from a source record, exactly as the source stated it. The value names the kind of coding that was added.

A signal found in a patient's medication records that bears on one reconciled medication entry: why the entry has its status, or how its medication was coded. An entry carries the signals that apply as repeating extensions, and never a numeric confidence score. The codes and what each one means are in the MedList Evidence code system.

The version of the rules haau3 used to reconcile this entry, in the form YYYY-MM-DD.vN. The same source records, reconciled as of the same date under the same rule-set version and the same RxNorm release, give the same entry. A different version means the rules changed.

The RxNorm release this entry was reconciled against, as the haau3 terminology service names it in the version it reports for RxNorm (for example 09082026). Any RxNorm coding haau3 added to the entry comes from this release.

A service CMS's files price that has no code in the SBC benefit categories, such as lab tests, home health care, hospital observation and a visit to a nurse or physician assistant, with its costs. Its parts mirror plan.specificCost.benefit and its cost, so the service reads like any other. The SBC benefit categories bind plan.specificCost as required, so these services cannot appear there; haau3 publishes this extension until the SBC guide codes them.

The lowest and the highest of a cost the plan files as a range, as Medicare Advantage plans file every copay and coinsurance. The cost's value carries the highest with the comparator <=. Present only when the lowest and the highest differ. The SBC profile allows one value per cost; haau3 publishes this extension until the SBC guide carries a range.

Which network a deductible or out-of-pocket maximum belongs to, whom it covers (one member, each person in a family, or the whole family) and what it applies to (medical care, drugs, or both). generalCost.type says whether it is a deductible or a maximum, in the SBC guide's words. The SBC profile writes these as text only; haau3 publishes this extension until the SBC guide codes them.

The days of a stay a per-day cost covers, as Medicare Advantage plans file hospital and skilled nursing costs by day range ($550 a day for days 1 to 5, then $0 a day for days 6 to 90). The cost carries the per-day qualifier. The SBC profile has no element for days; haau3 publishes this extension until the SBC guide does.

A Medicare Advantage plan files this amount as Original Medicare's own, with no number of its own: a deductible, or hospital or skilled nursing cost sharing. The part says which. Where haau3 holds Original Medicare's published amounts, they come with the year they belong to and their source. If that year is not the plan's year (CMS publishes each year's amounts in mid-November of the year before), the cost's value carries a data-absent reason and the amounts here are the latest published, which may change. The SBC profile has no way to say an amount is Medicare's; haau3 publishes this extension until the SBC guide does.

Facts about a Plan Benefits plan that CMS's files state and InsurancePlan has no element for: the facts each program files about its plans. Each part is present only where it applies to the plan's program, which InsurancePlan.type names. The SBC guide has no elements for these; haau3 publishes this extension until it does.

The CMS release a Plan Benefits plan was read from: the release's name, and for each of CMS's files in it, the address CMS publishes it at, the date CMS last changed it and its SHA-256, so anyone can fetch the same file and check it. The SBC guide has no element for the source of a plan's data; haau3 publishes this extension until it does.

The cell of CMS's Marketplace file that a cost, deductible or maximum was read from, exactly as the file writes it ("$850.00 Copay per Stay after deductible", "$4000 per group", "Not Applicable"). The amount beside it is haau3's reading of this text. The SBC profile has no element for source text; haau3 publishes this extension until the SBC guide does.

A language the person communicates in, and whether it is the one they prefer, as the person states it or as a caregiver states it on their behalf. It has the same shape as communication and is kept apart from it: communication carries what source systems said about the person, and this extension carries what the person says. A record carries one instance per language, and preferred appears on at most one of them.

What "Medications" carries when this person's records are shared through haau3: haau3's reconciled medication list or the medication records as received. Absent, the reconciled list. The person or their caregiver chooses it in haau3, and a shared bundle never carries it.

The id and extensions a source sent for one entry of a repeating primitive (such as HumanName.given or Address.line) without saying which entry they belong to, because the source's list of values and its list of extensions had different lengths. Kept on the element that holds the list, with the position the source sent it at, instead of being attached to a value by guess. The source's own extensions are nested inside unchanged, under their own URLs. A record carries one instance per such entry.

A payer named by the source system beyond the first. US Core allows a Coverage to name one payer; where a source named several, the first is delivered in Coverage.payor and every other is delivered here, exactly as the source expressed it, so that no payer the source named is lost.

Every CMS Marketplace benefit name this guide hosts.

Every CMS PBP service category this guide hosts.

ValueSet for DocumentReference.type for patient-shared documents in the KTC use

Every kind of coding haau3 adds to a reconciled medication entry.

Every MedList evidence code, for the evidence extension on a reconciled medication entry.

The intents a reconciled medication entry can carry, as US Core's medication list guidance uses them: order when an order backs the entry, and plan when the entry rests only on reported use.

The statuses a reconciled medication entry can carry: a subset of FHIR's MedicationRequest status. An entry is never draft or entered-in-error.

Value set for payor identifier types.

Every Plan Benefits cost qualifier.

What a deductible or out-of-pocket maximum applies to.

Whom a deductible or out-of-pocket maximum covers: HL7's individual and family (the whole family), and haau3's family-per-person.

Which network a deductible or out-of-pocket maximum belongs to: HL7's in and out (in is the first tier for a plan with two in-network tiers), and haau3's codes for the rest.

Every Plan Benefits cost type: HL7's benefit-type codes for a copay, a coinsurance (copay-percent) and a per-service deductible, and haau3's for the rest.

Every Plan Benefits general cost type.

The Original Medicare amounts haau3 supplies for a Medicare-defined amount.

The parts of Original Medicare a Medicare-defined amount refers to.

The Marketplace metal levels: HL7's platinum, gold, silver, bronze and catastrophic, and haau3's expanded-bronze.

The status codes of the $in-network operation on InsurancePlan.

The reason codes of the $in-network operation on InsurancePlan.

The RxNorm concepts in one NLM Current Prescribable Content release, which the version names. NLM describes that release as holding active RxNorm normalized names, codes (RxCUIs), attributes and relationships, and as excluding suppressed and obsolete data, drugs that are exclusively non-US or foreign, and drugs for exclusive veterinary use. Membership is therefore a statement about a dated release rather than about RxNorm as a whole: a code absent from this value set may still be a valid RxNorm code outside that release.

Both things "Medications" can carry in a share.

Every haau3 software that computes records from other records.

The three LOINC codes corresponding to the MVP haau3 'My Story' questions. Strict subset of the PACIO Care Experience Preferences Grouping value set (http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1115.11).

LOINC panel codes for the questionnaires haau3 can administer.

The benefit names (BenefitName) of CMS's 2026 Health Insurance Exchange Benefits and Cost Sharing public use file for the services Plan Benefits serves. Each code is the name exactly as the file writes it. An ACA Marketplace benefit in Plan Benefits carries one of these beside its SBC benefit category, as the fixed reference to CMS's file. CMS publishes no code system for them; haau3 hosts them, verbatim, until CMS or the SBC guide does.

The Medicare-covered service categories of CMS's Plan Benefit Package (PBP) Benefits 2027 files, with their codes and labels as CMS's data dictionary gives them. A Medicare Advantage benefit in Plan Benefits carries one of these beside its SBC benefit category, as the fixed reference to CMS's files. CMS publishes no code system for them; haau3 hosts them, verbatim, until CMS or the SBC guide does. The supplemental categories are not yet included.

The kinds of coding haau3 adds to a reconciled medication entry, named by the MedList Added Coding extension on each added coding.

Signals haau3 records on a reconciled medication entry to say why the entry has its status and how its medication was coded. Each code names what was found in the patient's records and what it means for the entry. An entry carries every code that applies.

Code system for payor identifier types.

Facts that describe a Plan Benefits cost entry: which in-network tier it is, how it is charged, and how it relates to the deductible and the out-of-pocket maximum. haau3 publishes these until the SBC guide codes them.

The parts of a deductible's or out-of-pocket maximum's scope HL7's benefit-network and benefit-unit have no code for: the networks other than in and out, each person in a family, and what the amount applies to. haau3 publishes these until the SBC guide codes them.

The kinds of Plan Benefits cost entry HL7's benefit-type has no code for: the per-visit cap on coinsurance, and, for an entry with no amount, why it has none. A copay, a coinsurance and a per-service deductible use HL7's benefit-type. haau3 publishes these until the SBC guide codes cost types.

Plan-level costs other than deductibles and out-of-pocket maximums. haau3 publishes these until the SBC guide codes them.

The parts of Original Medicare a Medicare Advantage plan's Medicare-defined amount refers to, and the Original Medicare amounts haau3 supplies for one. haau3 publishes these until the SBC guide codes them.

The Marketplace metal level HL7's insuranceplan-plan-type has no code for. haau3 publishes this until HL7 codes it.

What the CMS National Provider Directory says about one provider and the networks of one plan, for the plan's year: the status codes of the $in-network operation on InsurancePlan. A directory listing is not a statement of a contract, which is why HL7's applicability codes, defined by a contract with the insurer, are not used.

Why the CMS National Provider Directory holds no network data for a plan in the plan's year: the reason codes of the $in-network operation on InsurancePlan.

Who can buy a Plan Benefits plan: the codes of the sold-to search on InsurancePlan.

What "Medications" carries when a person's records are shared through haau3: haau3's reconciled medication list, or the medication records as received. A share carries one or the other.

The haau3 software that computed a record from other records, rather than receiving it from a source system. Carried in meta.tag on the computed record and on each of its Provenances.

A Medicare Advantage contract number as CMS assigns it.

CMS's own identifier system for a Medicare Advantage plan.

A Medicare Advantage plan's key in CMS's Plan Benefit Package files, as the files write it.

A Marketplace issuer's five-digit HIOS issuer ID.

A Marketplace plan's 17-character HIOS plan ID, including its cost-sharing reduction variant.

A Marketplace plan's 14-character HIOS standard component ID, shared by all its variants.

Stable haau3 patient id. Used on Patient.identifier only.

The answer for an ACA Marketplace plan: the directory holds no network data for it, so the reason says why and the plan's own provider directory is given. The NPI is illustrative.

The answer for a Medicare Advantage plan the directory holds for the plan's year: one network checked, and three providers, one listed in it, one the directory holds but the network does not list, and one the directory does not hold. The NPIs and the directory records are illustrative.

The 6-item Transportation Security Index is an abbreviated version of the 16-item Transportation Security Index. It captures the lived experiences of people experiencing transportation insecurity, and it has been validated using a nationally representative survey. The index can be used to assign respondents a continuous score representing their level of transportation insecurity or to categorize respondents as experiencing no insecurity or insecurity that is marginal, low, moderate, or high.

Example of a QuestionnaireResponse for the 6-item Transportation Security Index questionnaire (LOINC code 106423-7).

Example haau3 Coverage instance representing a commercial insurance plan.

Example organization that conforms to C4BB Commercial Organization.

Example organization that conforms to C4BB Organization, representing a Medicaid HMO payer.

Example LOINC 60591-5 for a FHIR-rendered PDF.

Example patient that conforms to Haau3 Patient.

Example practitioner that conforms to Haau3 Practitioner (US Core 6.1.0 Practitioner) with additional fields to align with CMS National Provider Directory.

Example caregiver that conforms to Haau3 RelatedPerson, with the relationship the haau3 app writes and the languages the caregiver states, beside the communication entries an older record carries.

Example LOINC 51855-5 patient story PDF.

Example patient-reported AllergyIntolerance demonstrating an additional clinical content entry in a Patient-Shared Bundle.

Example Condition demonstrating an additional clinical content entry alongside the patient-shared DocumentReferences.

Example patient-reported Immunization demonstrating an additional clinical content entry in a Patient-Shared Bundle.

Example US Core Lab Result Observation — Hemoglobin A1c result of 7.1% for the example patient.

Example patient-reported MedicationRequest demonstrating an additional clinical content entry in a Patient-Shared Bundle.

Example patient that conforms to US Core 6.1.0 Patient.

Example US Core Vital Signs Observation — blood pressure panel 120/78 mmHg for the example patient.

Worked example of a patient-shared Bundle whose medications are haau3's reconciled medication list: one reconciled MedicationRequest, tagged derived-by medlist, and its Provenance, which carries haau3 as a contained Organization and names the record the entry was built from in words. The records as received are not in the bundle. Note: this rendered example shows meta.profile on its entries because IG tooling stamps it on examples; bundles haau3 issues do not carry meta.profile, and receivers must not require it.

Worked example of a patient-shared Bundle containing the patient subject, the two patient-shared PDFs, clinical content and one self-reported Patient Story observation. Its medications are the records as received: a MedicationRequest, a MedicationStatement and the Medication the statement names, so the reference resolves inside the bundle. Note: this rendered example shows meta.profile on its entries because IG tooling stamps it on examples; bundles haau3 issues do not carry meta.profile, and receivers must not require it.

A request to the reconcile-medications operation: a collection of one patient's medication records. A Janumet order, the patient's own statement that they take Janumet, their statement that they take lisinopril, and an order that names no medication, which the response reports as skipped. Every record is synthetic.

A request to the reconcile-medications operation in the Parameters form: one resource part per medication record, and an asOf part that sets the date and time the list is evaluated as of. Every record is synthetic.

Example haau3 Coverage instance representing a Medicaid HMO plan.

Example haau3 Patient Story Observation answering 'Are there things that are important to you about how you receive care?'

Example haau3 Patient Story Observation answering 'If it were possible to choose, where would you like to spend your final days?'

Example haau3 Patient Story Observation answering 'What do you want caregivers to know about your religious beliefs?'

AvMed Entrust Gold 125 (2026), a 2026 ACA Marketplace plan with two in-network tiers, as Plan Benefits serves it: read from CMS's PY2026 Marketplace public use files, release aca-2026-2026-08-10.

UnitedHealthcare's AARP Medicare Advantage from UHC FL-0021 (PPO), a 2027 Medicare Advantage plan, as Plan Benefits serves it: read from CMS's PBP Benefits 2027 files, release ma-2027-2026-10-01.

The eHealth Literacy Scale (eHEALS) is an 8-item measure developed to measure consumers' combined knowledge, comfort, and perceived skills at finding, evaluating, and applying electronic health information to health problems. The objective of the study was to psychometrically evaluate the properties of the eHEALS within a population context.

Example of a QuestionnaireResponse for the eHealth Literacy Scale questionnaire (LOINC code 107619-9).

An allergy whose source system supplied no code for the allergen. The delivered code restates the substance the record's own reaction detail names, with a tag recording the completion; the reaction detail is preserved unchanged.

An active plan of care carrying the required assessment-and-plan category, which the source system did not state, with its activity described inline and that activity's status stated as unknown.

An active care team a health system recorded about a care recipient, delivered as sent: it carries the identifier naming its source record, and its participant carries the role the source stated and the practitioner who fills it.

A completed communication about the care recipient, delivered exactly as it arrived: no content, sender, recipient or time accompanies it. Treat the record as the fact that a communication occurred rather than as a message to read.

A clinical summary document as it is commonly delivered: the practice that produced it, the clinician who attested to it, the span of care it covers, and its headings — with entries delivered only for the records haau3 also holds.

A health problem whose source system stated its kind only in its own vocabularies. The delivered record carries the recognized problem-list value ahead of the source's own codings, which are preserved unchanged, and a tag recording the completion.

An active advance-directive consent delivered as it arrived. The category states that the kind of consent is unknown, which is what the source system sent rather than anything haau3 derived, and no provision detail accompanies it.

An insurance plan as it is commonly delivered: a primary payer identified by a reference, a second payer the source named in words alone and which is carried on the record rather than dropped, and a relationship stated in the source system's own terms.

A laboratory report as it is commonly delivered: the kind stated in the source system's own terms, a period rather than a single time, no issued time, the individual results named as separate records, and the report itself carried inside the record for a person to read.

A report whose source system did not say what kind of report it is. The delivered record states that the kind is unknown, in the standard shape for a value that is expected but not known, and carries a tag recording that the statement was supplied rather than sent.

A clinical note delivered as two renderings of one document, each naming a file held on the same server, with the custodian stated by name as the source sent it.

An office visit whose class carries the CPT code the source system sent rather than a translated standard code, and whose status the source left as unknown. Delivered exactly as stated.

An insurance claim as it is commonly delivered: the source system's own CARIN profile left in place, the billing provider carried inside the claim, the payer named by an identifier, and the plan it was billed against named as a delivered record.

A completed family history for the care recipient's mother, carrying two coded conditions. Delivered as it arrived, with no age or birth date for the relative, because current sources send neither.

An active goal whose meaning the source system carried in the description's text, with a coding that states only that no code was available.

A vaccination delivered exactly as the source stated it, including dose-protocol detail. The occurrence is the machine-usable date; the tag records that a duplicative source text form was set aside.

A medication whose RxNorm coding arrived without display text, as most production codings do. The code's text carries the readable name a consumer can always rely on.

A completed medication administration: the drug by reference, the care recipient, and the administration time, exactly as the source stated them.

A completed pharmacy refill: hand-over time and quantity present, preparation time and days-supply absent as current sources send them, referencing both the delivered Medication and the delivered MedicationRequest it filled.

A completed medication order delivered without an authoredOn date, because the source system never stated one. The medication is a reference to a delivered haau3 Medication, as most production records' are; VA and eClinicalWorks records carry the inline code instead.

An active medication-use statement delivered without an assertion date or effective dates, because the source system stated neither. The dosage is the source's own free text, delivered as it arrived.

A measurement whose kind the source system stated only in its own private vocabulary. The record states that its standard kind is unknown rather than carrying an invented one, and the source's own category is preserved unchanged.

A completed procedure where the source system never said what was done. The code states that the value is unknown rather than carrying an invented one; the performed date and the order it fulfilled are delivered as stated.

An in-progress set of questionnaire answers delivered as they arrived. The authoring date states that it is unknown rather than carrying a value, because the source system sent none and haau3 invents nothing. The questionnaire it answers is named by a URL on the source system.

What haau3 added to the Janumet entry: the generic clinical-drug coding, from the RxNorm release named here, pointed at by the id the entry gives that coding. haau3 is the author, carried as a contained Organization.

The reconciled list for the example request: a Janumet entry built from an order and a statement, a lisinopril entry built from a statement alone, a Provenance for each, a second Provenance naming the coding haau3 added to the Janumet entry, and an OperationOutcome reporting the order that named no medication as skipped. Every record is synthetic.

Where the shared entry came from, as a shared bundle carries it: tagged derived-by medlist, haau3 as a contained Organization, and the source record named in words with its type, since the records as received do not travel with the reconciled list.

Where the lisinopril entry came from: the patient's statement. haau3 is the assembler, carried as a contained Organization.

Where the Janumet entry came from: the order and the patient's statement. haau3 is the assembler, carried as a contained Organization.

A reconciled entry as a shared bundle carries it: tagged derived-by medlist, built from one undated statement of use that named no reporter, so its intent is plan and reportedBoolean is true. The statement already carried the RxNorm clinical drug, so haau3 added nothing.

A reconciled entry built from a Janumet order and the patient's own statement that they take it. The branded RxNorm coding both sources stated is kept, and the generic clinical-drug coding is added and marked because no source carried it; a second Provenance names that addition.

A reconciled entry built from the patient's own statement alone. Its intent is plan and it names the patient as the reporter and the requester, as US Core's medication list guidance asks for reported medications. The statement already carried the RxNorm clinical drug, so haau3 added no coding.

An active referral order with the date the source stated and the order described in the source's own words.

A sample a lab result was run on, where the source system did not say what kind of sample it was. The type states that the value is unknown rather than carrying an invented one.