Using DigiDOT ServiceRequest

Purpose

Use DigiDOT ServiceRequest for one planned, proposed or ordered dental service.

It covers dental recall, planned treatment, diagnostic services and follow-up. It does not represent a booked appointment, a completed clinical contact, a performed procedure, a clinical result or a diagnosis.

Workflow and lifecycle

Use the resources in their respective workflow roles:

  • ServiceRequest represents the plan, proposal or order.
  • Appointment represents a proposed or booked time and points back through Appointment.basedOn.
  • Encounter represents the actual dental contact.
  • Procedure represents a clinical action that was performed, attempted or stopped and points back through Procedure.basedOn.
  • Observation represents a measurement or assessment result.
  • Condition represents a clinically significant finding, diagnosis or problem.

ServiceRequest.status is the authoritative lifecycle state for the plan or request. Use active while it can be fulfilled, on-hold when it is paused, completed when it is fulfilled or closed, and revoked when it is cancelled before fulfilment. Do not use Procedure.status or an Appointment status for this purpose.

ServiceRequest.intent distinguishes a proposal, plan or order. A normal local dental care plan and a recall request normally use plan. Use order only where the source represents an actual request to another performer or service.

Core content and MustSupport

MustSupport does not make an optional element mandatory in every request. It means that an EHR and Central Storage implementation must be able to populate, accept, preserve and return it.

If the source has information that maps faithfully to an optional MustSupport element, it shall populate it. If information is not known, not relevant or cannot be mapped without changing its meaning, it may be omitted. Systems must not invent data.

Element How it is used
identifier Stable source business identifier when available. It supports traceability, de-duplication and idempotent import and is not the FHIR server resource id.
status, intent Required workflow lifecycle and request intent.
category Required coarse DigiDOT workflow category. It is not the clinical planned-service code.
priority Standard FHIR clinical priority when the source records it. Do not infer it from appointment availability.
code Required planned clinical service, with one required precoordinated SNOMED CT concept and one optional postcoordinated expression.
subject Required no-basis Patient.
basedOn, replaces Explicit relationship to another DigiDOT ServiceRequest when a request fulfils, refines or replaces it.
encounter Dental contact where the request was created, when known.
occurrence[x] Requested due time, due window or cadence. It is required for recall.
authoredOn When the request was created or signed in the source EHR.
requester Person or organisation that initiated the request.
performer, locationReference Preferred performer/service or requested place, when the plan identifies them.
reasonReference Relevant DigiDOT Condition or Observation that justifies the request.
supportingInfo Selected clinical or patient-safety context that directly affects this request.
bodySite Relevant tooth, surface or other dental anatomy. Populate it when the source records specific anatomy.

Categories and clinical coding

ServiceRequest.category contains exactly one coding from the DigiDOT ServiceRequest Category ValueSet:

  • dental-recall for recall need, next due date, due window or cadence.
  • dental-treatment for planned dental treatment.
  • dental-diagnostic for planned diagnostic work, such as imaging.
  • dental-follow-up for planned control after a finding or treatment.

The category supports workflow filtering, searching, display and exchange. It does not replace ServiceRequest.code.

ServiceRequest.code contains one required precoordinated SNOMED CT concept (SCTpre). Use the DigiDOT Dental Procedures ValueSet when it covers the intended service. The binding is extensible: a broader SNOMED CT concept remains permitted for clinical planning when the refset does not cover the intended meaning.

One optional postcoordinated SNOMED CT expression (SCTpost) may add clinical precision. It supplements, never replaces, SCTpre. It may express anatomy, method or request context, but must not contradict the structured request lifecycle, planned-service code or bodySite.

"code": {
  "coding": [
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "234789004",
      "display": "Insertion of composite restoration into tooth"
    },
    {
      "system": "http://snomed.info/sct",
      "version": "http://snomed.info/sct/51000202101/version/20260715",
      "code": "234789004:{363704007=36492000}{363704007=83473006}"
    }
  ]
}

Recall

Recall is not a separate profile. It is a ServiceRequest with category = dental-recall.

For recall:

  • occurrence[x] is required.
  • Use occurrenceDateTime for one due date, occurrencePeriod for a due window, or occurrenceTiming for a recall cadence.
  • The profile normally uses intent = plan.
  • Until a more precise dental recall concept is agreed, use SNOMED CT 185349003 | Encounter for check up (procedure) | in code.
  • The exact proposed or booked time belongs in no-basis Appointment, not in the recall ServiceRequest.

Relationships and supporting information

Element Permitted use
basedOn, replaces A related DigiDOT ServiceRequest only.
requester no-basis Practitioner, PractitionerRole, Organisation, Patient or RelatedPerson. Use a named Practitioner when the individual is known.
performer no-basis Practitioner, PractitionerRole, Organisation or HealthcareService. This is a preferred or assigned performer/service; the actual clinical performer is recorded in Procedure.
locationReference no-basis Location.
reasonReference DigiDOT Condition or Observation. A routine recall may have no clinical reason.
supportingInfo Selected EpisodeOfCare, no-basis AllergyIntolerance, DigiDOT Condition or Observation, or the explicitly permitted FHIR/SFM context resources for flags, consent, questionnaire data, medication context, device use, documents, reports, imaging and summary composition.

supportingInfo is intentionally selective. It must not carry a duplicate full patient history or repeat a reason already represented through reasonReference. External information remains source-aware; its source, freshness, provenance and update responsibility are handled by the Central Storage integration design.

Tooth and surface anatomy

Use ServiceRequest.bodySite for a structured planned anatomical context.

  • A bodySite may contain zero or more teeth when no surface is recorded.
  • A bodySite with one or more surfaces must contain exactly one tooth.
  • For surfaces on more than one tooth, create one bodySite per tooth.
  • All bodySite codings are direct, versioned SNOMED CT concepts. Tooth and surface slices use the required Teeth and Tooth Surfaces ValueSets.

The same anatomy may appear in SCTpost for semantic precision, but it must remain consistent with bodySite.

Fields not used in the current draft

The current profile does not use doNotPerform, orderDetail, quantity[x], asNeeded[x], performerType, locationCode, reasonCode, insurance, specimen or relevantHistory. These require a specific dental workflow, terminology and EHR mapping before they can be opened.

note remains available for limited planning narrative that has no structured representation. patientInstruction remains available for patient-facing information that directly concerns this request.

See ServiceRequest storage scope and element use for detailed element decisions and ServiceRequest validation review for review questions and technical evidence.

Examples