Release 5 Preview #1

This page is part of the FHIR Specification (v4.2.0: R5 Preview #1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4

2.1.1 Best Practices

FHIR Infrastructure 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-6A 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
con-3Condition.clinicalStatus SHALL be present if verificationStatus is not entered-in-error and category is problem-list-item

Most systems will expect a clinicalStatus to be valued for problem-list-items that are managed over time, but might not need a clinicalStatus for point in time encounter-diagnosis.