Release 4 FHIR CI-Build

This page is part of the Continuous Integration Build of FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ) in it's permanent home (it will always (will be available incorrect/inconsistent at this URL). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see times).
See the Directory of published versions icon . Page versions: R5 R4B R4

2.1.1 2.1.1.1 Best Practices

Maturity Level : N/A
Responsible Owner: FHIR Infrastructure icon Work Group Standards Status : Informative

The base FHIR specification is used across the world in many different contexts, with a great variety of use cases. There are many existing restrictions from common practice and regulation that constrain the agreements that the specification represents. In particular there are large amounts of existing data in legacy record stores that need to be represented and exchanged using FHIR resources.

The requirements analysis that occurs during the design of the FHIR process often leads to a clear understanding of how information should be represented, but also can make clear that for a variety of reasons, such best practices cannot be imposed as standards requirements in all contexts. However, it is useful for the FHIR standard to be able to document what are known best practices.

Committees can document best practice by one of two different ways:

  • defining invariants and marking them as best practice rules
  • adding narrative that defines best practices

When using the FHIR validator , implementers are able to ask for best practice rules to be enforced if they wish.

This page indexes the best practices documented in this specification:

DomainResource
dom-6 A resource should have narrative for robust management

When a resource has no narrative, only systems that fully understand the data can display the resource to a human safely. Including a human readable representation in the resource makes for a much more robust eco-system and cheaper handling of resources by intermediary systems. Some ecosystems restrict distribution of resources to only those systems that do fully understand the resources, and as a consequence implementers may believe that the narrative is superfluous. However experience shows that such eco-systems often open up to new participants over time.

Condition Appointment
con-3 app-6 An appointment may have an originatingAppointment or recurrenceTemplate, but not both

For a recurring series of appointments, the originating appointment should have the recurrenceTemplate defining the details of the overall recurrence. Each occurence should refer back to the originatingAppointment as the single source of truth for the details of the recurrence.

CodeSystem
Condition.clinicalStatus SHALL csd-7 caseSensitive SHOULD be present provided

There is scope for unsafe interpretation of codes if verificationStatus it's not known whether the CodeSystem is case sensitive or not entered-in-error

ConceptMap
cmd-12 If ConceptMap.group.element.noMap is present and category has a value of 'true', there SHOULD be some comments, unless the status is problem-list-item 'draft'

Encourage documentation when noMap is true explaining why

cmd-1 If the map is source-is-broader-than-target or not-related-to, there SHOULD be some comments, unless the status is 'draft'

Encourage documentation when map is source-is-broader-than-target or not-related-to is true explaining the ramifications

cmd-13 If ConceptMap.group.unmapped is present, there SHOULD be some comments, unless the status is 'draft'.

Most systems will expect Encourage documentation when noMap is true explaining why

StructureDefinition
sdf-26 The root element of a clinicalStatus profile should not have mustSupport = true

It is bad practice to set the root element of a profile to 'mustSupport' as mustSupport should always be valued for problem-list-items that are managed over time, but might not need determined by the element referencing a clinicalStatus for point type. The designer of a StructureDefinition cannot know all circumstances in time encounter-diagnosis. which a type or profile might be used