FHIR Implementation Guide for the Norwegian Municipal Sector - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Conformance and Scope

This page defines how binding and guidance content should be interpreted across the IG.

What This Page Controls

The Conformance page controls:

• how requirement words are interpreted
• which parts of the IG are normative
• what is in and out of scope in this version

Normative Requirement Words

This IG uses these normative keywords:

• SHALL: mandatory requirement
• SHOULD: strong recommendation
• MAY: optional

If a statement is not expressed with SHALL, SHOULD or MAY, it is guidance.

Priority In Case Of Doubt Or Conflict

When the same topic is described in multiple places, interpretation follows this order:

1. Requirements expressed in profiles and other machine-readable artifacts (StructureDefinition, bindings, cardinality).
2. Statements using SHALL, SHOULD or MAY in normative sections.
3. Guidance text, examples and use case descriptions.

Interpretation Of MustSupport

This version of the IG does not use MustSupport in the municipal profiles.

• Important minimum requirements are expressed through cardinality and references.
• Use of MustSupport can be considered later when the profiles have been tested and anchored more broadly.

Scope And Boundaries In This Version

European And National Profile Layers

• This IG SHALL use no-basis as the direct Norwegian national baseline where relevant no-basis profiles exist.
• This IG SHOULD be assessed against HL7 Europe Base/Core before release or consultation when profile scope, shared actors, documents or EHDS-related content changes.
• HL7 Europe Base/Core is used as an external reference and source of modelling inspiration in this version, not as a package dependency or machine-enforced conformance layer.
• If no-basis and HL7 Europe Base/Core differ, the difference SHOULD be documented and handled through HL7 Norway governance before this IG introduces local divergence.

Included

• Municipal patterns for ServiceRequest, Encounter, EpisodeOfCare and CarePlan.
• Profiling based on no-basis where relevant profiles exist.
• Practical use through use cases, mapping and example chains.
• High-level API principles for search, versioning and documentation.

Not Included

• A complete national profile catalog for all municipal domains.
• New national code systems.
• A full testing regime with formal certification.
• A complete transport and security architecture.
• Alternative profiles, APIs or endpoints for measurement data already handled by Welfare Technology Hub (Velferdsteknologisk knutepunkt, VKP) or Patient's measurement data (Pasientens måledata, PMD).

Normative Boundaries

• New profiles and changes SHOULD start from documented needs and use cases.
• The work SHALL consider reuse of existing profiles, especially no-basis, before new variants are introduced.
• Deviations and new profiles SHOULD document consequences for interoperability and backwards compatibility.
• Changes SHOULD be anchored in an HL7 Norway process with open dialogue and consultation.

Page Classification In This IG

What This Page Does Not Do

• This page does not define all details of each profile.
• This page does not replace profiles or CapabilityStatement.

For those details, see Modelling and profiling and API.

Abbreviations Used In This IG (Guidance)

The main text explains abbreviations in context where this is important. This short list is included as a reading aid for abbreviations that occur across several pages.

References

• RFC 2119 - Key words for use in RFCs
• RFC 8174 - Ambiguity of Uppercase vs Lowercase
• ISO/IEC Directives - foreword supplementary information
• IG and documentation (HL7 Norway)
• HL7 Norway FHIR process