This page is part of the FHIR Specification (v5.0.0-ballot: R5 Ballot - see ballot notes). 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.10 Clinical Safety

FHIR Infrastructure Work Group

Maturity Level: N/A

Standards 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.

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

Feedback is welcome here .

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. Note that for this list, safety is interpreted loosely, and the list covers security and privacy issues as well.

This safety check list is also available as a Code System to facilitate formal references to these check list items. For instance, application registration processes may wish to require applications to assert that they pass some of these checks. As an example, the formal URL for the first check item is http://hl7.org/fhir/safety-entries#life-cycle.

7.10.2 Conformance Related Safety Checks

These basic safety checks relate to using the FHIR specification correctly.

1. For each resource that my system handles, my system handles the full Life cycle (status codes, currency issues, and erroneous entry status)
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 "MustSupport" in the profiles that apply to my system
5. My system has documented how distributed resource identification works in its relevant contexts of use, and where (and why) contained resources are used
6. My system manages lists of current resources correctly
7. 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
8. My system ensures checks for patient links (and/or merges) and handles data that is linked to patients accordingly
9. My system publishes a Capability Statement with StructureDefinitions, ValueSets, and OperationDefinitions, etc., so other implementers know how the system functions
10. 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)
11. I've reviewed the Observation resource, and understand how focus is a mechanism for observations to be about someone or something other than the patient or subject of record.

7.10.3 Date / Timezone Related Safety Checks

Dates and timezone issues are well-known sources of confusion and safety issues in clinical applications.

12. My system checks for time zones and adjusts times appropriately. (note: time zones are extremely difficult to get correct - see W3C Timezone Advice , and note that some fields should be timezone corrected, and others should not be)
13. 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)

7.10.4 Search Related Safety Checks

These basic safety checks relate to managing the search process correctly. Mismatches in expectations between client and HTTP server (or search requester and search processor) can result in finding more resources than expected or appropriate, or much more seriously, missing resources out in search results that were expected to be present.

14. My system takes care to ensure that clients can (for servers) or will (for clients) find the information they need when content that might reasonably be exposed using more than one FHIR resource. Possible patterns: Support a single search across the applicable resources, or expose data through each applicable resource. See discussion on Wiki Page for further information
15. My client checks the names of search parameters and operation definitions in the HTTP server's CapabilityStatement to see if they have been renamed on the local system
16. My client application checks for the existence of pages in search results (Bundle.link of type next) in the response to a search. Note: failure to page through the data will cause an application or it's human user to be missing the full clinical picture for the patient
17. My server clearly documents how sorting works when performing searches, and how concurrency works when clients move between pages (e.g. if data in a page can change/duplicate across pages)

For clients

18. My system will display warnings returned by the server to the user
19. My system checks whether the server processed all the requested search parameter, and is safe if servers ignore parameters (typically, either filters locally or warns the user)

For Servers

20. 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
21. My system includes appropriate default filters when searching based on patient context - e.g. filtering out entered-in-error records, filtering to only include active, living patients if appropriate, and clearly documents these (preferably including them in the self-link for a search)
22. When clients have limited access to data for permission reasons (e.g. the data they receive might be SUBSETTED), my system handles update or create requests tagged in such a way by either rejecting them, or accepting them after carefully considering how to avoid accidental loss of data the updating client did not have access to, and taking into account the possibility that a client update might invalidate data the client was unaware of.

7.10.5 Deletion Safety Checks

Deleting records and/or marking records as no longer valid is a well known source of safety issues in all applications. This specification allows for resources to be deleted, but does not require systems to behave in any particular fashion.

23. For each resource, I have checked whether resources can be deleted, and/or how records are marked as incorrect/no longer relevant
24. Deletion of records (or equivalent updates in status) flow through the system so any replicated copies are deleted/updated
25. (If a server) my documentation about deleted resources is clear, and my test sandbox (if exists) has deleted/error record cases in the test data

7.10.6 Privacy Related Safety Checks

FHIR defines a set of capabilities to support data exchange. Not all the capabilities that FHIR enables may be appropriate or legal for use in some combinations of context and jurisdiction (e.g. HIPAA for exchange between institutions). It is the responsibility of implementers to ensure that relevant regulations and other requirements are met.

26. My system checks that the right Patient consent has been granted (where applicable)
27. My system sends an Accounting of Disclosure to the consenter as requested when permitted actions on resources are performed using an AuditEvent Resource

7.10.7 Security Related Safety Checks

Basic Context:

26. My system ensures that system clocks are synchronized using a protocol like NTP or SNTP, and my server is robust against clients that have the wrong clock set
27. My system uses security methods for an API to authenticate where Domain Name System (DNS) responses are coming from and ensure that they are valid

Communications:

30. Production exchange of patient or other sensitive data will always use some form of encryption on the wire
31. Where resources are exchanged using HTTP, TLS should be utilized to protect the communications channel
32. Where resources are exchanged using email, S/MIME should be used to protect the end-to-end communication
33. Production exchange should utilize recommendations for Best-Current-Practice on TLS in BCP 195

Authentication/Authorization:

Note: Users/Clients may be identified and authenticated in any way desired. For web-centric use, OAuth is recommended.

34. My system utilizes a risk and use case appropriate OAuth profile (preferably Smart App Launch ), with a clear policy on authentication strength
35. My system uses OpenID Connect (or other suitable authentication protocol) to verify identity of end user, where it is necessary that end-users be identified to the client application, and has a clear policy on identity proofing

Access Control:

36. My system applies appropriate access control to every request, using a combination of requester’s clearance (ABAC) and/or roles (RBAC)
37. My system considers security labels on the affected resources when making access control decisions

7.10.8 Narrative / Presentation Related Safety Checks

38. My system can render narratives properly and securely(where they are used)
39. When creating resources, careful consideration has been given for when the system should generate resource narrative to serve as a safe failback for other systems that do not recognised all elements and extensions in them (either because of lack of community agreement or because of non-simultaneous evolution of discrete data interfaces among community participants))
40. When generating narrative, careful consideration has been given to the human readability of the narrative, trying to appropriately highlight 'important' information to make it likely that human readers unfamiliar with the narrative organization will still find such information
41. When consuming resources, my system checks the Narrative.status element to inform whether the narrative should be made available in the user interface

With regard to #38, Systems SHOULD check the narrative status. Specifically, if the status is 'additional', then narrative SHOULD always be available for human consumption, if 'extensions' and the system does not render all human-relevant received extensions the narrative SHOULD be available and if 'generated' and the system does not render all human-relevant received core elements, the narrative SHOULD be available.

Integrity:

42. My system validates all input received (whether in resource format or other) from other actors so that it data is well-formed and does not contain content that would cause unwanted system behavior
43. My system makes the right Provenance statements and AuditEvent logs, and uses the right security labels where appropriate
44. My system manages decimal precision correctly when using JSON (see JSON representation of primitive elements)

7.10.9 Other Safety Checks

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:

44. Server: CORS (cross-origin resource sharing ) is appropriately enabled (many clients are Javascript apps running in a browser)
45. JSON is supported (many clients are Javascript apps running in a browser; XML is inconvenient at best)
46. JSON is returned correctly when errors happen (clients often don't handle HTML errors well)
47. The _format header is supported correctly
48. Errors are trapped and an OperationOutcome returned