Reading the profiles
FHIR — Fast Healthcare Interoperability Resources — provides standard structures for health information. DigiDOT uses FHIR R4. The glossary gives the overall picture; the tables below help you recognise what you see on Simplifier.
FHIR glossary
| Term | What it means | Example in DigiDOT |
|---|---|---|
| Resource type | A standard kind of FHIR record. | Condition for a diagnosis or clinical problem. |
| Instance | One actual record of that type. | Condition/caries-finding in the example case. |
| Profile | Rules for using a resource or datatype in a particular context. | DigiDOT Condition specifies how a dental condition is recorded. |
| StructureDefinition | The FHIR definition resource that publishes those structural rules. | The profile definition you open on Simplifier. |
| Element | A field, including fields nested inside other fields. | Condition.code or code.coding.system. |
| Datatype | The structure of a field's value. | Quantity for a measurement with a unit; CodeableConcept for coded meaning. |
| Extension | An additional field with a defined URL, content and permitted use. | Health group in Encounter; the complex body-structure extension inside Dental BodySite. |
| Reference | A link to another resource instance. | Condition.subject points to the Patient. |
| Identifier | An assigned business identity, with an assigning system and value. |
An HPR number on Practitioner. |
| Canonical URL | The stable identity of a definition, such as a profile or ValueSet. | The profile's Canonical field on Simplifier. |
| CodeSystem | Defines codes and their meanings. | SNOMED CT. |
| ValueSet | Selects codes for a particular purpose. | The Condition category ValueSet. |
| Bundle (resource) | A FHIR resource that groups other resources. Its type specifies the purpose of the grouping. |
Complete clinical examples use type: collection to keep their linked records together. |
| Implementation guide (IG) | Guidance and definitions explaining how the model is used together. | This guide connects the profiles, rules and examples. |
| Package | A distributable set of definitions with a version and dependencies. | Norwegian base profiles are supplied in hl7.fhir.no.basis. |
A profile describes the rules; an instance contains the data. A resource profile keeps the standard resourceType, such as Condition. A datatype profile such as Dental BodySite describes an inline field value, with no separate patient-record identity.
References: FHIR R4 overview, StructureDefinition, extensions, Bundle types and implementation guides and packages.
Open a profile on Simplifier
Use the Profile guide to choose a profile. Its header identifies the definition you are reading:
| Header item | How to read it |
|---|---|
| Type | The resource or datatype being profiled: for example, Profile on Condition. |
| FHIR R4 | The FHIR specification release; it is separate from the profile's version. |
| Status: Draft | FHIR publication status. |
| Version | The revision identifier for this definition. Readiness is shown separately. |
| Canonical | The definition's stable identity. |
| Readiness: In review, for example | DigiDOT's assessment of development and review. See readiness definitions and current status. |
Select a field in Overview and read its definition, comments, cardinality, datatype and constraints together. Follow its binding and target-profile links for the permitted codes or referenced records. JSON shows the profile definition; the example scenario shows patient-record JSON.
| Tree view | What you see |
|---|---|
| hybrid | Inherited structure plus changes. Grey is inherited; black is set by this profile. Removed fields are crossed out. |
| diff — differential | The profile's changes and the parents needed to display them. |
| snap — snapshot | The resulting permitted structure; 0..0 fields are hidden. |
Missing from diff does not mean removed. Show common reveals common fields normally hidden in the tree. Hover over an icon for its element type.
References: StructureDefinition metadata and Simplifier's views, icons and flags.
Read fields and rules
Columns in the profile table
| Column | What to look for |
|---|---|
| Name | The field and its position in the hierarchy. Indented fields belong to the parent above. |
| Flags | Markers such as MustSupport or a constraint; see the symbols below. |
| Card. | How many occurrences are permitted. |
| Type | The datatype or permitted reference targets. |
| Description & Constraints | Meaning, bindings, fixed values and additional rules. Select the field for more detail. |
Cardinality: how many values?
| Cardinality | Meaning |
|---|---|
0..1 |
Optional; at most one occurrence. |
1..1 |
Required; exactly one occurrence. |
0..* |
Optional; may repeat. |
1..* |
At least one occurrence; may repeat. |
1..2 |
One or two occurrences. |
0..0 |
Not permitted. |
A required child applies when its parent is present. For example, ServiceRequest.code is 0..1; when present, its coding array must contain SCTextended. A conditional rule also requires code for requests other than general recall.
Notation and flags you will recognise
| What you see | Meaning | What to do |
|---|---|---|
[x], such as value[x] |
A choice of datatype. | JSON uses the selected name, such as valueQuantity. |
Slice, such as coding:SCTextended |
Rules for a named group of entries in a repeating field. | Check the group's minimum, maximum and discriminator. |
S — MustSupport |
A system-support requirement. | Read the DigiDOT population rules below. |
C — invariant |
An additional constraint affects this field. | Read the condition, including its error/warning severity. |
Σ — summary |
Included in a resource summary. | It does not indicate mandatory presence. |
?! — modifier |
Affects interpretation of the record. | Account for its meaning, including an entered-in-error status. |
Cardinality, datatype, bindings and invariants all apply together. Repeating FHIR fields stay JSON arrays even when a profile limits them to one entry.
Common datatypes and value rules
| Datatype | What it holds | Familiar example |
|---|---|---|
string, boolean, date, dateTime |
Text, true/false, a date or a date/time. | Patient birthDate uses date. |
code |
A controlled string. | Procedure.status, such as completed. |
Coding |
A code or expression with its system, optional display and version. | One entry in code.coding. |
CodeableConcept |
Coding entries and optional human-readable text. | Condition.code; its allowed content is constrained by the profile. |
Quantity |
A number with a unit. | Pocket depth of 4 mm. |
Period |
Start/end bounds. | The period of an Encounter. |
Timing |
A schedule. | The interval and first due date for recurring recall. |
Reference |
A link to a permitted resource. | The Patient referenced by a clinical record. |
Annotation |
A note, with optional author and time. | A clinically relevant comment in note. |
Narrative |
A human-readable resource summary, stored in text. |
This is separate from CodeableConcept.text and from a contact-note Composition. |
BackboneElement |
A nested group of related fields within a resource. | Appointment.participant groups its actor and participation status. |
| Label | Meaning |
|---|---|
| Binding | A ValueSet and the strength of its use. |
| Fixed Value | The specified value must be used when the field is present. |
| Pattern | Supplied data must match the specified pattern; additional content is allowed only within the other rules. |
| Example | An illustration, not a fixed value or default. |
References: FHIR R4 datatypes, resource narrative and element definitions and value constraints.
References: FHIR R4 profiling and slicing, table notation and JSON representation.
Recognise the coding slices
In Condition, Observation, Procedure and ServiceRequest, clinical coding uses these named slices whenever the containing clinical code is present:
| Part of the rule | Meaning in DigiDOT |
|---|---|
code.coding |
The array of clinical codings. |
| Discriminator: Coding.id | id selects which slice an entry belongs to. |
SCTextended — 1..1 |
Exactly one complete coding: a sufficiently specific concept or a postcoordinated expression. |
SCTpre — 0..1 |
An optional, compatible single-concept companion. |
| Closed slicing | Only the declared slices are permitted in this array. |
The slice names are not new JSON properties: use a coding entry with "id": "SCTextended". This Coding.id is a local element label, separate from the resource's id. The Clinical coding page explains the clinical meaning, release rules and postcoordination. Dental anatomy shows how the expression matches bodySite.
Codes and terminology bindings
| Term or field | Meaning |
|---|---|
Coding.system |
Identifies the code system, such as http://snomed.info/sct. |
Coding.code |
The machine-readable code or expression. |
Coding.display |
A human-readable term for that coding. |
Coding.version |
Identifies the code-system edition/release being used. |
CodeableConcept.text |
Human-readable wording of the overall clinical meaning. |
| Binding | Connects a field to a ValueSet and specifies its strength. |
| Binding strength | How to interpret it |
|---|---|
| Required | Use a suitable code from the ValueSet. For CodeableConcept, at least one coding must be from the set; other profile constraints still apply. |
| Extensible | Use the set when it contains an appropriate concept; otherwise an alternative must still follow the profile's rules. |
| Preferred | The ValueSet is recommended. |
| Example | Illustrates possible codes. |
A binding does not make an optional parent mandatory. Text or display does not replace a required coded value. DigiDOT's system, slicing and clinical-meaning rules apply even when a binding is extensible or preferred.
References: Coding field definitions, CodeableConcept and FHIR R4 binding strengths.
Keep identities and references distinct
| Item | Identifies |
|---|---|
| Profile canonical URL | The definition used to interpret or validate data. |
Resource id |
One record within its server and resource type: for example, caries-finding. |
Business identifier |
An assigned identity, such as HPR, with its system and value. |
Reference.reference |
Another record: for example, Condition/caries-finding. |
DigiDOT references reusable stored patient and provider records. Official identifiers belong on those records; identifier-only links are not an alternative to the required literal reference. The consuming field determines the permitted target profiles. See References and identifiers for worked examples.
Reference: FHIR R4 resource identity and references.
MustSupport in DigiDOT
MustSupport concerns implementation capability and handling available source information. It does not make an optional field mandatory in every instance.
| Role | DigiDOT population rule |
|---|---|
| Producer | Convey known, relevant source information that maps faithfully to permitted MustSupport fields. |
| Receiver and consumer | Accept, preserve and return it; process it without error and display or use it when relevant. |
| Unavailable source information | Omit an optional field only where cardinalities and invariants permit it. Record mapping gaps; do not invent values. |
A required field remains required without MustSupport. Validation cannot establish whether a sender omitted relevant information it actually held. FHIR R4 requires the guide/profile to define what MustSupport means.
Check a mapping
| Check | What it establishes |
|---|---|
| JSON parsing | The file has valid JSON syntax. |
| FHIR/profile validation | Structural rules are checked against selected profile versions and dependencies, within the validator's scope. |
| Terminology and clinical review | Code meaning, expression rules and anatomical consistency need their own checks. |
An instance's meta.profile states which definition it claims to follow; it is not a validation result. A server's meta.versionId identifies a stored resource revision, separate from the profile's version. The example overview records the supplied cases and check limits; Review status and releases explains readiness and versions.
References: FHIR R4 validation and resource metadata.