Must Support and conformance

DigiDOT uses a deliberately narrow mustSupport strategy, inspired by the restrained use of mustSupport in Norwegian base profiles.

The current package marks 29 differential elements as mustSupport across the digidot-* profiles. This is intended as a minimum implementation contract, not as a complete list of every element that may be useful in a dental record.

mustSupport does not mean that an element must be populated in every instance. It means that systems claiming support for the profile must be able to handle the element in the relevant workflow.

For DigiDOT:

  • servers should store and return supported elements when present
  • clients should read and display or use supported elements when clinically or operationally relevant
  • producers should populate supported elements when the information is known and relevant
  • empty elements can still be valid when the FHIR cardinality allows it and the information is unknown, unavailable or not relevant

Why Must Support is limited

Too much mustSupport makes the profile harder to implement and weaker as a contract. DigiDOT marks elements as mustSupport only when they are needed for:

  • the dental workflow
  • clinical interpretation
  • patient safety
  • location/anatomy
  • external decision context
  • reporting or finance
  • traceability between plan, contact, procedure and charge

Main rule

Use mustSupport for the minimum common implementation contract. Do not use it as a wish list for every element that might be useful later.

In practice this means that workflow anchors such as patient, status, code, contact, time, clinical reason, body site, performer and the most important cross-resource references are marked where they are needed. More optional administrative, financial or scenario-specific details are left as ordinary FHIR elements unless they become explicit implementation requirements.

Mandatory FHIR elements are normally not marked mustSupport just because they are important. Where cardinality already requires the element, that requirement is expressed through the profile itself.

Detailed Norwegian guidance is maintained in MUST_SUPPORT_GUIDANCE_NO.md.