Reporting Projection Marker CodeSystem Code system¶
| Canonical | ../CodeSystem/reporting-projection |
|---|---|
| Status | draft · 1.26.0 |
| Content | complete |
| Source | FSH · JSON |
Markers the reporting projection mints for itself, held under a system no source value set uses so that a minted marker is never mistaken for an answer the chart captured.
Why they exist. Reporting flattens a patient's chart into one row per patient, and some chart elements repeat. Collapsing a repeating element by taking whichever answer was listed first is not a simplification but a wrong value: it attributes the patient to a single answer they did not give alone, in the dimension being measured. The row carries a marker instead, and the report counts the marker as its own visible segment.
Read the system, not the code. A projection column carries a (system, code) pair, and most codes
in it came from the value set the chart recorded -- including the absence answers (v3 NullFlavor
OTH, data-absent-reason asked-declined, asked-unknown), which are captured answers rather than
missing data and keep counting as answers. The dedicated system is what lets a consumer tell a
minted marker from a recorded one by inspection, without consulting a list of source systems.
These are not values on a FHIR element. Unlike the other code systems this guide declares, values under this one are written into the projection's own row rather than onto a resource. It is declared because it shares a column with codes that did come from FHIR, and a consumer has to tell the two apart.
One marker today, and the vocabulary is expected to grow as more repeating elements reach the projection. Declaring the system rather than waiting for a second marker is what lets the "is this minted" test be written once, against the system, rather than against a growing list of literals.
multiple is not an answer. It records that the patient's answers are not one value. Folding it
into an "other" bucket, or dropping it, undercounts exactly the patients it exists to make visible.
MIGRATION. Nexus EMR writes this system today as
http://services.well.com/fhir/CodeSystem/reporting-projection, an address this specification does
not publish, on a host it does not govern. It is live in code and in stored projection rows, and is
under migration to the canonical declared here. Write the canonical; expect both until the migration
completes, and match both addresses exactly rather than deriving one from the other.
| Code | Display | Definition |
|---|---|---|
multiple |
More than one answer | The patient gave MORE THAN ONE answer for an element the projection can hold only one of, so the row records that fact rather than choosing between them. Written today where a pat… |