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

7.9 7.10 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 7.10.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" "must-support" in the profiles that apply to my system
5. All resources in use are valid against the base specification and the profiles that apply to my system (see note about the correct run-time use of validation )
6. For each resource that my system handles, my system handles the full Life cycle (status codes, currency issues, and erroneous entry status)
7. My system can render narratives properly and securely (where they are used)
8. My system has documented how distributed resource identification works in its relevant contexts of use, and where (and why) contained resources are used
9. My system manages lists of current resources correctly
10. My system makes the right Provenance statements and AuditEvent logs, and uses the right security labels where appropriate
11. My system checks that the right Patient consent has been granted (where applicable)
12. 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
    • For search, my system will display warnings returned by the server to the user
13. 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
14. My system ensures that system clocks are synchronised synchronized using a protocol like NTP or SNTP, or my server is robust against clients that have the wrong clock set
15. My system ensures checks for patient links (and/or merges) and handles data that is linked to patients accordingly
16. My system publishes a Capability Statement with StructureDefinitions , ValueSets , and OperationDefinitions , etc., so other implementers know how the system functions
17. My system checks for timezones, and adjusts times appropriately. (note: timezones are extremely difficult to get correct - see W3C Timezone Advice , and note that some fields should be timezone corrected, and others should not be)
18. My system renders dates safely for changes in culture and language (the date formats D-M-Y and M-D-Y are not differentiated for many dates, and this is a well known source of confusion. Systems should use the month name, or otherwise be specific for each date when rendering, unless there is solid confidence that such confusion cannot arise, even in the future when information/narrative from resources will be shared much more widely)

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 appropriately enabled (many clients are javascript Javascript apps running in a browser)
2. JSON is supported (many clients are javascript 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 The _format header is supported correctly
5. Errors are trapped and an OperationOutcome returned