Documents, Coverage & Provenance

7.1

DocumentReference — clinical notes & C-CDA

DocumentReference is the index card; the actual content is an attachment (PDF, RTF, plain text, or a C-CDA XML document) carried inline or by URL.

Required: status (current/superseded/entered-in-error), type (LOINC document type code), category, subject, date, content.attachment, content.format.

content.attachment carries the bytes (data base64 or url) plus contentType (MIME) and title.

content.format identifies the document profile (e.g. C-CDA Continuity of Care Document) using a Coding from a small set.

Two main flows

Free-form notes (progress note, discharge summary): contentType = text/plain or application/pdf, type = LOINC like 11506-3 (Progress note).
C-CDA (legacy interop): contentType = application/hl7-cda+xml, format identifies which C-CDA template.

7.2

Coverage — insurance

Coverage models a payer relationship: who pays, what plan, what subscriber id, what relationship the patient has to the subscriber.

Required: status, type, subscriberId, beneficiary (the Patient), relationship, payor (Organization or RelatedPerson).

Must Support: identifier (member ID), class (group, plan), period.

payor being a RelatedPerson is rare but valid (self-pay through a family member). Most often it's an Organization with an NAIC code identifier.

7.3

Provenance — who/what/when said this

Provenance is metadata about how a resource came to be — the audit trail for clinical assertions. Required for some Must Support flows in US Core.

Provenance answers: who recorded this, on what device, transformed from what source, when?

Required: target (the resource(s) this provenance is about), recorded (timestamp), agent.who (Practitioner/Organization/Device).

The classic US Core use case: a payer received a CCDA from a provider; they parse it to FHIR; the resulting Observations carry Provenance pointing back to the originating organization and the transformation.

Why you should care early

If you're building a write-back app (e.g. a SMART app sending data into an EHR), Provenance is how the EHR knows your app authored the resource — and is increasingly required by certification.

7.4

QuestionnaireResponse

Structured form answers — SDOH screeners, intake forms, PROMs. Pairs with a Questionnaire (the form definition) and often an Observation (the derived clinical fact).

US Core 7+ added us-core-questionnaireresponse so clients can read structured answers without re-parsing free text.

Required: status, subject, item (the answers).

item is recursive — sections nest. Each item has a linkId matching the Questionnaire's item.linkId, plus answer.value[x] (Coding, string, decimal, date…).