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 | Confirmed start of the practice visit |
period.end |
optional | Administrative completion of the practice visit, when the source provides it |
statusHistory |
optional | Source-recorded lifecycle history, when it exists |
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 confirmed start of the practice visit is Encounter.period.start. Producers
use in-progress while the practice visit is active and finished after its
administrative completion. The contract does not require an artificial arrival
stage or any statusHistory entry. A producer that has real lifecycle history
may still populate base FHIR statusHistory, but a consumer must not rely on
it for confirmed presence. A consumer checks the profile canonical,
period.start, freshness, and an acceptable current status; it must not select
on Encounter.period alone and must reject entered-in-error resources.
Prior resources with real statusHistory remain conformant. New producers must
not manufacture an arrived stage merely to satisfy this profile. Consumers
retain the profile-canonical and current-status gates, but use the required
period.start as the presence time.
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: