This page is part of the FHIR Specification (v1.1.0: STU 3 Ballot 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

This is a frozen snapshot of the FHIR specification created for the purpose of balloting the GAO implementation Guide. It includes draft changes that may be part of the future DSTU 2.1 release but further change is expected. Readers should focus solely on the GAO implementation content, and FHIR DSTU 2 for other purposes.

2.0 Implementation

FHIR Infrastructure Work Group

Maturity Level: N/A

Ballot Status: DSTU 2

2.0.0.1 Implementer's 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. For each resource that my system handles, my system handles the full Life cycle (status codes, currency issues, and erroneous entry status)
6. My system can render narratives properly (where they are used)
7. My system has documented how distributed resource identification works in its relevant contexts of use, and where (and why) contained resources are used
8. My system manages lists of current resources correctly
9. My system makes the right Provenance statements and AuditEvent logs, and uses the right security labels where appropriate
10. My system checks that the right Patient consent has been granted (where applicable)
11. When other systems return http errors from the RESTful API and Operations (perhaps using Operation Outcome), my system checks for them and handles them appropriately
12. My system publishes a conformance statement with StructureDefinitions, ValueSets, and OperationDefinitions, etc., so other implementers know how the system functions

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.