DSTU2 Ballot Source

This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

2.0 Implementation

Exchange Frameworks

Define how Resources are exchanged.

Support

Implementation Support.

FHIR Profiles & Implementation Guides

Adapting FHIR for specific usage.

2.0.0.1 Implementers Safety Check List

FHIR is as simple to implement as we know how to make it. However, due to the nature of healthcare, and healthcare processes, and cultural concerns, there are a number of features in FHIR that implementers are obliged to consider in order to implement safe systems.

This section is a check list to help implementers be sure that they've considered all the parts of FHIR that impact on their system design with regard to safety.

  1. Production exchange of patient or other sensitive data will always use some form of encryption on the wire
  2. For each resource that my system handles, I've reviewed the Modifier elements
  3. My system checks for modifierExtension elements
  4. My system supports elements labelled as "must-support" in the Profiles that apply to my system
  5. My system can render narratives properly (if/when they are used)
  6. My system has documented how distributed resource identification works in its relevant contexts of use
  7. My system uses the right security labels where appropriate
  8. When other systems return http errors from the RESTful API or from the Mailbox (perhaps using Operation Outcome), my system checks for them and handles them appropriately
  9. My system publishes a conformance statement so other implementers know what it does

Obviously this list is only a small part of the overall safety check list for an application, which will have checks regarding jurisdictionally mandated policies, internal integrity, etc.