References and identifiers

A record's identity, its business identifier and its links to other records have different purposes.

Linking shared resources

Patient, Practitioner, PractitionerRole, Organization and Location are reusable resources in central storage. DigiDOT records link to the national no-basis profiles permitted by each field. For a clinician, use no-basis-Practitioner; the reference field describes whether that person requested, recorded, performed or authored the information.

Use a literal reference to the stored resource. Within the same FHIR service, a relative reference such as Practitioner/planning-practitioner avoids an environment-specific service URL.

"recorder": {
  "reference": "Practitioner/planning-practitioner",
  "type": "Practitioner",
  "display": "Robin Taylor"
}

The same pattern applies to the care provider and clinic, for example Organization/planning-county and Location/planning-location in the example scenario.

Identifier-only references are not permitted. For these shared-resource links, reference is 1..1 and identifier is 0..0. A real reference value is required; display alone or a contained reference starting with # is insufficient. Where an Annotation permits both authorString and authorReference, the literal-reference rule applies to its Reference option.

HPR, national identity numbers and organisation numbers belong in the referenced resource's identifier, with the correct assigning system. They are not substituted for its resource ID. Adding a later verified identifier to the same Practitioner preserves the existing clinical references. Reference.type, when supplied, is a resource type such as Practitioner, not a profession.

Reuse or register before linking

1. Find a verified match in central storage using the relevant identifier and namespace. Reuse the existing resource and its resource ID.
2. If no resource exists, register it through the agreed storage process, following the relevant no-basis profile. Ambiguous matches must be reconciled; do not choose the first result or create a duplicate.
3. Use the stored resource's reference in the clinical record. The receiving service must check that the target exists and conforms to an allowed profile.

The profiles enforce the reference form and permitted targets. They do not perform identity matching or prove that a target already exists on a particular server. Registration, matching and access handling belong to the storage integration. The retired DigiDOT Practitioner Reference helpers are not used.

Person, qualification and participation

The current Appointment, Encounter, EpisodeOfCare and ServiceRequest profiles permit no-basis-PractitionerRole in selected fields. Finance drafts also retain role targets. Use it only where the target field permits it and the source records that organisational context. The example scenario includes one optional clinic assignment, reused by both Appointment and Encounter participants. It connects Robin to the county and clinic; findings, procedures and journal-note authors still reference Practitioner directly. The national profile is reusable across systems; a role instance describes a particular assignment and can be reused across patients and visits. A separate role record is not required by these profiles.

"qualification": [{
  "code": {
    "coding": [{
      "system": "urn:oid:2.16.578.1.12.4.1.1.9060",
      "code": "TL",
      "display": "Tannlege"
    }],
    "text": "Dentist"
  }
}]

The local Personnel Types — Unbound Draft is a comparison list. No active DigiDOT profile binds it. Do not insert its codes into a Reference or treat it as a required selection list. Activating it would require an agreed field, code mapping and terminology owner; national qualification and function vocabularies should be considered first.

Preserving source identity

Keep a known stable source business identifier with its assigning namespace. A booking identifier identifies the booking, not its patient; an episode identifier is not shared by every record in that episode. Preserve the same identity when resubmitting the same logical record.

Appointment, Encounter, EpisodeOfCare, ServiceRequest, Condition, Procedure and Observation permit business identifiers to be absent. When supplied, their profiles require both system and value. Other profiles have their own requirements: Dental Contact Note, for example, requires its source note identifier.

Do not fabricate source identifiers to fill optional fields. Resource-ID assignment, lookups, duplicate prevention and creation/update permissions belong to the integration agreement. Adding a later verified identifier to the same correctly matched Practitioner does not require replacing the person's clinical references.

Bundles in the examples

The downloadable clinical cases are collection Bundles: containers for reading related records together. They do not request server writes. A transaction Bundle represents an atomic set of server interactions and requires request instructions. References to new entries can match their Bundle.entry.fullUrl values, for example a urn:uuid: value.

Bundle choice and supported server operations require an exchange agreement. The current example collections are not ready-made transaction requests.

References: FHIR R4 references, resource identity and transactions.