DigiDOT ServiceRequest - Draft Review

Scope: DigiDOT ServiceRequest (NO), ServiceRequest Category, Dental Procedures, Teeth, and Tooth Surfaces.

This page explains the current DigiDOT ServiceRequest draft and provides a focused review record for clinical, business, terminology and EHR validation.

The profile is ready for structured review. It is not final approval, production implementation guidance, or a formal EHDS, Helse-NIM or legal conformance statement.

Summary

ServiceRequest is the DigiDOT planning layer for one dental service. It represents a plan, proposal or order before the service is scheduled or performed. The draft is constrained to preserve the planning relationships needed by the dental workflow while avoiding unbound coded details, generic core references and duplicate representations of clinical meaning.

The central principles are:

  1. Record the planned clinical service once in ServiceRequest.code.
  2. Record lifecycle in status, intent in intent, and the required workflow category in category.
  3. Use occurrence[x] for a due date, due window or cadence, and use Appointment for the actual proposed or booked time.
  4. Use structured FHIR references for patient, clinical reason, request relationship, contact, preferred performer and selected decision context.
  5. Use postcoordinated SNOMED CT only for additional clinical precision; it does not replace structured workflow fields or linked resources.

How the Profile Fits the Dental Workflow

Information DigiDOT representation Review question
Continuing course of care DigiDOT EpisodeOfCare Is the request part of a longer dental care course?
Planned or requested dental work DigiDOT ServiceRequest What service is planned, for whom, why and when is it due?
Recall need or cadence ServiceRequest with category = dental-recall Is this a recall due date, window or repeating cadence rather than a booked appointment?
Booked contact no-basis Appointment Has a proposed or booked time been created for the request?
Actual clinical contact DigiDOT Encounter Was the request created during a contact, or fulfilled in one?
Finding, diagnosis or problem DigiDOT Condition Is there a clinically significant reason for treatment?
Measurement or assessment DigiDOT Observation Does an assessment result justify or fulfil the request?
Performed clinical action DigiDOT Procedure What actually happened, when and by whom?

Typical path: a Condition or Observation is identified during an Encounter; a ServiceRequest plans treatment; an Appointment books the service; a Procedure records the actual action. A new ServiceRequest represents planned follow-up or the next recall.

Current ServiceRequest Design

Area Current decision
Resource Use FHIR R4 ServiceRequest for one dental service that is planned, proposed or ordered. Use Appointment for scheduling and Procedure for an action that was performed.
Required core status, intent, category, code and subject are required. code has one required SNOMED CT SCTpre coding.
Workflow category category is required and has exactly one canonical DigiDOT coding: recall, treatment, diagnostic or follow-up. It is not the clinical service code.
Clinical code SCTpre is the primary directly usable SNOMED CT planned-service concept. One optional SCTpost expression may add clinically relevant precision.
Recall Recall is a normal ServiceRequest with category = dental-recall, occurrence[x], normally intent = plan, and the interim SNOMED CT check-up concept. It is not a separate recall profile.
Timing occurrenceDateTime, occurrencePeriod or occurrenceTiming represent a due time, due window or cadence. Appointment holds the actual proposed or booked time.
References Core links use named DigiDOT or no-basis target profiles. Generic base-resource targets are not permitted where an agreed target profile exists.
Request origin and performer requester may be a person, role, organisation, patient or related person. performer may be a person, role, organisation or healthcare service because a plan can identify a service before the actual performer is known.
Clinical reason reasonReference can reference a DigiDOT Condition or Observation. reasonCode is closed because no governed DigiDOT reason terminology is agreed.
Supporting context supportingInfo is deliberately limited to an explicit set of episode, allergy, clinical, SFM and selected standard FHIR context resources. It must not copy the full patient history.
Anatomy bodySite is the structured planned anatomy. A surface requires exactly one tooth in the same bodySite. All bodySite codings are direct, versioned SNOMED CT concepts.
Extensions Root extensions and extensions on category, code and bodySite are 0..0. No named ServiceRequest extension is in scope.
Closed fields Ungoverned or unmodelled alternatives, including order detail, quantity, as-needed, performer type, location code, reason code, insurance, specimen and relevant history, are 0..0.

Recall Rules

The following profile rules apply when category is dental-recall:

Rule Current level Meaning
occurrence[x] is present Error A recall must express a due date, window or cadence.
intent = plan Warning Recall normally represents a dental care plan, not an external order.
SNOMED CT 185349003 is included in code Warning Interim check-up concept until terminology governance agrees a more precise dental recall concept.

Terminology Evidence

ValueSet or terminology Use in ServiceRequest Current decision Review required
DigiDOT ServiceRequest Category ServiceRequest.category Required one-code binding. Provides recall, treatment, diagnostic and follow-up workflow markers. Confirm category coverage and workflow use with dental and EHR stakeholders.
DigiDOT Dental Procedures ServiceRequest.code and SCTpre Extensible refset-based starting point. Use a refset concept when it covers the planned service; broader SNOMED CT is allowed only where the refset does not cover the meaning. Confirm planning coverage, Snowstorm expansion and release ownership.
DigiDOT Teeth bodySite.coding:tooth Required binding to the Norwegian dental teeth reference set. Confirm clinical coverage and terminology-release process.
DigiDOT Tooth Surfaces bodySite.coding:surface Required binding to the Norwegian dental surfaces reference set. Confirm clinical coverage and terminology-release process.
SCTpost Optional code coding Not bound to a ValueSet. Its grammar, concept validity and semantic coherence are checked in Snowstorm against the stated SNOMED CT release. Confirm the postcoordination patterns needed for planned dental services.

MustSupport and Source Population

The current MustSupport elements are identifier, basedOn, replaces, status, intent, priority, category, code, SCTpre, SCTpost, subject, encounter, occurrence[x], authoredOn, requester, performer, locationReference, reasonReference, supportingInfo and bodySite.

For this profile, MustSupport means that EHR and Central Storage implementations must be able to populate, accept, preserve and return an element. If the source holds information that maps faithfully to an optional MustSupport element, it shall populate it. If the information is not known, not relevant or cannot be mapped without changing meaning, it may be omitted. Systems must not invent data.

Validation Questions

  1. Workflow: Confirm that the ServiceRequest, Appointment, Encounter and Procedure boundaries work for recall, planned treatment, diagnostic services, emergency care and follow-up.
  2. Recall: Confirm the temporary recall SNOMED CT concept, the plan intent convention and use of Timing for recall cadence.
  3. Terminology: Validate Dental Procedures ValueSet coverage, ServiceRequest categories, tooth/surface value sets and postcoordinated expressions in Snowstorm using the agreed Norwegian release.
  4. EHR mapping: Check source mapping of identifiers, revised plans, composite requisitions, status, intent, priority, due window, requester, preferred performer, location, reason and patient instructions.
  5. Supporting context: Confirm the permitted supportingInfo types and identify which external information must be available at planning time versus retrieved through patient context.
  6. External data: Confirm source, freshness, provenance and duplication/caching behaviour for external allergy, medication, consent, alert, document and imaging context.
  7. Later scope: Confirm whether order details, quantities, as-needed requests, specimen workflows, insurance, dedicated report links or specific ServiceRequest extensions require a later model.

Technical Evidence Recorded

  • The active profile is maintained as an FHIR R4 differential; Forge/Simplifier renders the snapshot from that differential.
  • All 82 JSON artefacts in the Simplifier project parse successfully after the current profile and example changes.
  • Examples cover recall cadence and due windows, planned treatment with anatomy, diagnostic imaging request, revised treatment plan, treatment follow-up, references to reason Condition/Observation, and selected supporting context.
  • ServiceRequest examples use the required workflow category, a required SNOMED CT primary code and versioned SNOMED CT bodySite codings where anatomy is present.
  • Full package-context validation must be run in Forge/Simplifier after synchronization. Snowstorm validation is required for SNOMED CT ValueSet expansion and postcoordinated expressions.

References