FHIR Design Patterns

This is place-holder capturing what design patterns are needed. Eventually it will be updated to provide guidance for these and other FHIR modelling situations. The guidelines used to evaluate methodology guidelines and design patterns can be found in FHIR Methodology Process.

History

Sometimes there's a need to not only know the current value of a resource element (or collection of elements) but to also know historical (and occasionally expected future) values. For example historical names, addresses, etc. How should this be handled when such history is in the 80% (and when it's not)?

Comments

With many resources there's a need to capture ad-hoc comments about the resource. Should this be done with just a string area, a repeating string, a more complex structure or a reference to some sort of simple observation? Also, is this a construct that should exist pretty much everywhere, or only in certain places?

Recommendation

• Is the comment something that is maintained as part of the resource (something that will typically be specified when the resource instance is created, though it may be revised as the resource is updated?
  • If so, then a single comment string.
  • Don’t have a comment string with cardinality 0..*. If a user needs to add more, they edit the existing comment string. If there’s a need for multiple distinct strings, there needs to be a repeating structure where there’s a mandatory code, date, author or something. Consider linking to “Annotation” resource (see note below) instead.
• Is the comment providing a mechanism to capture “information not handled by core attributes”?
  • Create appropriate extensions, capture extension rendering in narrative
• Is the comment an assertion made about a resource instance by someone else that needs to be tracked, attested, etc. separately?
  • Use an “Annotation” resource.
  • Many scenarios that fall into this category are symptoms of problematic/broken workflow, so we’re using caution in introducing this use-case. (It’s also subject to significant potential for abuse.)

Note: We’re not creating an “Annotation” resource until we have clear use cases.