ServiceRequest storage scope and element use

Central-storage contract

DigiDOT ServiceRequest stores one planned, proposed or ordered dental service as a searchable FHIR R4 resource.

The profile defines the minimum interoperable planning meaning, limits references to agreed resources and closes fields that would create an ungoverned duplicate model. It is a constrained central-storage profile, not a closed payload for every EHR use case.

MustSupport means implementations must be able to populate, accept, preserve and return an element. It does not make an optional element mandatory when the source does not know it.

Clinical meaning and workflow

Information Representation Rule
Request lifecycle ServiceRequest.status Authoritative lifecycle of the plan or request. It is distinct from Appointment and Procedure status.
Request intent ServiceRequest.intent Use plan for a normal dental plan and recall. Use order only for an actual order to another performer or service.
Workflow category ServiceRequest.category Required one-code marker: recall, treatment, diagnostic or follow-up. It is not the clinical planned-service code.
Planned clinical service ServiceRequest.code with required SCTpre One direct, versioned SNOMED CT concept identifies the planned service.
Additional clinical precision optional SCTpost Valid SNOMED CT compositional grammar that supplements the planned-service concept. It must not contradict structured status, code or anatomy.
Recall due date, window or cadence occurrence[x] Required for dental-recall. The exact booked time belongs in Appointment.
Clinical reason reasonReference DigiDOT Condition or Observation that justifies the service.
Selected decision context supportingInfo Only context that directly affects this request. It must not duplicate the full patient history or the structured clinical reason.
Planned anatomy bodySite Direct, versioned SNOMED CT anatomy. Tooth and surface use the DigiDOT ValueSets and surface-to-one-tooth rule.

Element decisions

Element Current decision Reason
identifier Permitted, MustSupport Retains the stable source EHR business identifier for traceability, de-duplication and idempotent import. It is not the local FHIR resource id.
basedOn, replaces Permitted, MustSupport; DigiDOT ServiceRequest only Preserves plan fulfilment, refinement and replacement relationships without introducing generic request targets.
requisition Permitted Preserves a stable source composite request identifier when the source uses one to group related services. It does not replace individual identifiers or create a second plan model.
status, intent, category, code, subject Required, MustSupport Defines the minimum interoperable planning meaning.
priority Permitted, MustSupport Preserves source-recorded clinical priority.
encounter, authoredOn, requester, performer, locationReference Permitted, MustSupport Retains the source contact, request creation, request origin, preferred service and requested place when known.
occurrence[x] Permitted, MustSupport; required for recall Represents requested timing, due window or cadence, not a booked appointment.
reasonReference Permitted, MustSupport Links a planned service to a DigiDOT Condition or Observation that justifies it.
supportingInfo Permitted, MustSupport; explicit target list Carries only selected episode, patient-safety, clinical or source-document context that directly affects the request.
bodySite Permitted, MustSupport Preserves structured planned anatomy. Populate it when the source records specific anatomy.
note Permitted Limited narrative that cannot be represented in structured planning elements.
patientInstruction Permitted Patient-facing instruction that directly concerns this request.
doNotPerform 0..0 Cancellation is represented by status = revoked. No separate do-not-perform workflow is agreed.
orderDetail, quantity[x], asNeeded[x] 0..0 No governed dental terminology or mapping is agreed. Use one ServiceRequest per planned service.
performerType, locationCode, reasonCode 0..0 No governed DigiDOT terminology is agreed. Use the constrained performer, location and reason references instead.
insurance 0..0 Coverage, reimbursement and claim information belong in the finance model.
specimen 0..0 No current public dental-service specimen workflow or mapping is agreed.
relevantHistory 0..0 Provenance, source and import responsibility are handled by the Central Storage integration design.

Core reference targets

Element Permitted target profile or resource Use
subject no-basis Patient Patient receiving the planned service.
basedOn, replaces DigiDOT ServiceRequest Related request that this request fulfils, refines or replaces.
encounter DigiDOT Encounter Contact in which the request was created.
requester no-basis Practitioner, PractitionerRole, Organisation, Patient or RelatedPerson Person or organisation that initiated the request.
performer no-basis Practitioner, PractitionerRole, Organisation or HealthcareService Preferred or assigned performer/service for the plan.
locationReference no-basis Location Requested place for the planned service.
reasonReference DigiDOT Condition or Observation Structured clinical reason for the planned service.
supportingInfo Explicit list of DigiDOT, no-basis, SFM and selected standard FHIR context resources Relevant episode, allergy, clinical, medication, safety, document, report, imaging or summary context.

Generic base-resource targets are removed where DigiDOT or no-basis defines the canonical representation. The supportingInfo exception is intentional: several source-aware context resource types do not yet have a DigiDOT child profile, but their use is explicitly listed and limited.

Extensions

FHIR extensions are the standard mechanism for additional published information. No ServiceRequest extension is in scope for the current draft, so root extension and modifierExtension are 0..0. Extensions are also closed on category, code and bodySite to prevent unmanaged parallel representations of workflow category, planned-service meaning and anatomical context.

A future extension requires a documented dental use case, a named and governed definition, an EHR mapping rule and an explicit profile change. Unknown modifier extensions are prohibited because they can alter the meaning of the request.

External source responsibility

External clinical context in supportingInfo remains source-aware. Central Storage must retain source, freshness, provenance and update responsibility according to the integration design. A fetched allergy, medication record, alert, document or imaging reference does not become a local dental assertion merely because it is shown with a planned service.

Discussion points for later validation

  1. Confirm whether all four workflow categories are sufficient and whether any category must be split or retired.
  2. Validate the current temporary recall SNOMED CT concept and the recall intent = plan convention with dental users and terminology governance.
  3. Confirm source mappings for plan revisions, composite requisitions, priority, requester, preferred performer, location and patient instructions.
  4. Review the explicit supportingInfo target list with EHR, medication, imaging and governance stakeholders. Add no new context type without a documented reason and source-responsibility rule.
  5. Confirm that orderDetail, quantity, as-needed and patient-specific performer-type models are not needed for the current dental workflows.
  6. Validate dental procedure, tooth and tooth-surface terminology against the agreed Snowstorm service and Norwegian SNOMED CT release.

References