FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

2.1.1.1 Best Practices

FHIR Infrastructure icon Work GroupMaturity Level: N/AStandards 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.

Appointment
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.

StructureDefinition
sdf-26 The root element of a 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 determined by the element referencing a type. The designer of a StructureDefinition cannot know all circumstances in which a type or profile might be used