This page is part of the FHIR Specification (v3.0.2: STU 3). 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 R3

7.9 Clinical Safety

FHIR Infrastructure Work Group

Maturity Level: N/A

Ballot Status: Informative

This specification defines data elements, resources, formats, methods and APIs for exchanging healthcare data between different participants in the healthcare process. As such, Clinical Safety is a key concern with regard to the specification and its many and various implementations.

STU Note: This page, and the concept of safety in an API specification, needs further development.

Feedback is welcome here .

7.9.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 labeled 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 caters for parameters that have missing values when doing search operations, and responds correctly to the client with regard to erroneous search parameters
13. My system ensures that system clocks are synchronised using a protocol like NTP or SNTP, or my server is robust against clients that have the wrong clock set
14. My system ensures checks for patient links (and/or merges) and handles data that is linked to patients accordingly
15. My system publishes a Capability 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.

In addition, server developers should check these specific additional checks for client convenience:

1. Server: CORS (cross-origin resource sharing ) is enabled (many clients are javascript apps running in a browser)
2. JSON is supported (many clients are javascript apps running in a browser; XML is inconvenient at best)
3. JSON is returned correctly when errors happen (clients often don't handle HTML errors well)
4. the _format header is supported correctly
5. Errors are trapped and an OperationOutcome returned