Using Norwegian base profiles

DigiDOT reuses the national hl7.fhir.no.basis package version 2.2.2 for information that has the same meaning across Norwegian health services. DigiDOT adds a profile only when dental care needs a stable constraint, terminology binding or relationship that the base profile cannot express.

Reused profile	DigiDOT use	Reuse decision
no-basis-Patient	Subject/patient for the dental journey.	Reused directly. No dental-specific patient constraint is agreed.
no-basis-Practitioner and no-basis-PractitionerRole	Requester, performer, contact participant and care manager.	Reused directly. Professional identity and role are national concerns.
no-basis-Organization and no-basis-Location	Service provider, clinic and treatment location.	Reused directly. No agreed dental-specific structure is needed in this draft.
no-basis-Appointment	Proposed, booked, fulfilled, cancelled or no-show scheduling.	Reused directly. The native R4 fields cover the current dental scheduling pattern.
no-basis-AllergyIntolerance	Allergy or intolerance that directly affects planned dental work.	Reused directly as source-aware context, for example through ServiceRequest.supportingInfo.
no-basis-Substance	Material or substance used or referenced in dental care.	Reused directly where a dental-specific Device or Procedure profile is not required.

Appointment pattern

Use the three resources for distinct responsibilities:

Responsibility	Resource and link
Planned dental work, recall due window or requested follow-up	DigiDOT ServiceRequest
Proposed or booked time, patient, practitioner and location	no-basis-Appointment with Appointment.basedOn -> ServiceRequest
Actual completed dental contact	DigiDOT Encounter with Encounter.appointment -> Appointment and, when applicable, Encounter.basedOn -> ServiceRequest

When a course of care is relevant, use Appointment.supportingInformation -> DigiDOT EpisodeOfCare. The no-basis Appointment profile also provides national extensions for an appointment group, a parent appointment and virtual service details. Use them when the scheduling workflow needs them.

The current examples apply this pattern for recall, treatment and follow-up appointments.

Applying the profiles

Resources created or maintained by DigiDOT should declare the relevant no-basis profile in meta.profile. A referenced record imported from another source may use the base FHIR resource when no-basis conformance is not known; keep its source and provenance rather than asserting a profile it has not been validated against.

The source remains responsible for person, professional, organisation and external clinical data. DigiDOT stores a local FHIR representation only when it is needed for the dental workflow, display, search or decision support.

When to derive a DigiDOT child profile

Create a child profile only when a confirmed dental workflow requires a machine-checkable rule that is not adequately covered by the reused profile. Record the evidence from clinical review and EHR data first. For Appointment, this would require an agreed dental-specific mandatory element, binding or relationship that must be validated for every local appointment. No such requirement is established in the current draft, so a DigiDOT Appointment profile is not created now.