This page defines the source-neutral FHIR contract for recording that a patient
was physically present for an ambulatory practice encounter. The contract is
the
EncounterPraxisPresenceConfirmed
profile in this package.
The profile identifies a deliberately narrow subset of EncounterPraxis so a
consumer does not mistake every ordinary clinical Encounter with a period for
confirmed-presence evidence. It introduces no extension and does not identify
the technology that supplied the evidence.
| Element | Requirement | Meaning |
|---|---|---|
meta.profile |
includes encounter-praxis-presence-confirmed |
Machine-selectable assertion that the producer has confirmed presence under this contract |
subject |
required Patient | Patient whose presence was confirmed |
serviceProvider |
required Organization | Practice organization responsible for the encounter |
period.start |
required | Start of the Encounter associated with confirmed presence |
statusHistory.status = arrived |
exactly one required presenceArrival slice |
The standard FHIR arrival stage that established the presence assertion |
statusHistory.period.start |
required on the arrival slice | Time at which confirmed presence began |
location.location and location.period |
optional | Real resolved place and the interval during which the patient was there |
appointment |
optional | Appointment associated with the Encounter, when one exists |
The KBV parent binds the current Encounter.status to the German Encounter
status ValueSet. That ValueSet does not include the FHIR R4 arrived code,
although Encounter.statusHistory.status retains the FHIR Core binding and can
record arrived. Producers therefore use in-progress for an active contact
or finished for a completed contact and put the arrival stage in
statusHistory. A consumer checks the profile canonical, the arrival slice,
freshness, and an acceptable current status; it must not select on
Encounter.period alone and must reject entered-in-error resources.
When the source resolves a real FHIR Location, Encounter.location.location
may reference it and Encounter.location.period records the interval during
which the patient was physically present there. When the source supplies only
a Patient, Organization, and timestamp, the producer must not create a
synthetic Location such as a guessed reception desk. Omitting location is
conformant and preferable to a false location assertion.
When an actual reception area is represented as a resolved Location, its
Location.type may continue to use
PraxisWorkplaceFunctionCS#reception-check-in. The active code describes the
physical place; it is not generic check-in metadata on the Encounter.
A remote identity or token flow does not by itself establish physical presence at a named practice Location. A producer may declare this profile only when its own authoritative process has established the presence assertion represented by the Encounter. The profile is not a cryptographic-proof profile.
The Encounter records the interoperable outcome, while the evidence source
remains separate. Use base FHIR R4 Provenance when interoperable lineage is
required. Provenance does not replace the profile assertion and must not copy
raw token material, cryptographic validation results, or protocol exchanges
into the Encounter.
Gematik defines the PoPP token and its verification at the TI service and API boundary, not as an Encounter profile. VSDM 2 uses its published protocol and FHIR exchange for insurance master data; those Patient, Coverage, and payer data are not a substitute for the presence Encounter. Conversely, this profile does not represent a PoPP token, a VSDM 2 response, or proof that either protocol was executed.
Authoritative upstream references: