FHIR R4 Flag API

Overview

This asset is a component of MuleSoft Accelerator for Healthcare.

MuleSoft Accelerator for Healthcare enables healthcare providers to unlock critical patient data to build a patient 360 within Salesforce Health Cloud, faster and easier than ever before. The solution includes pre-built APIs, connectors, integration templates, and a prescriptive end-to-end reference architecture to bring patient demographics information and COVID-19 test results from any EHR into Health Cloud using HL7 V2 or FHIR standards.

The solution also provides a library of United States Core Data for Interoperability (USCDI) and FHIR R4 resources to help healthcare developers adhere to interoperability needs and jumpstart the development of healthcare digital transformation initiatives.

Use case covered

A flag is a warning or notification of some sort presented to the user - who may be a clinician or some other person involve in patient care. It usually represents something of sufficient significance to warrant a special display of some sort - rather than just a note in the resource. A flag has a subject representing the resource that will trigger its display. This subject can be of different types, as described in the examples below:

• A note that a patient has an overdue account, which the provider may wish to discuss with them - in case of hardship for example (subject = Patient)
• An outbreak of Ebola in a particular region (subject=Location) so that all patients from that region have a higher risk of having that condition
• A particular provider is unavailable for referrals over a given period (subject = Practitioner)
• A patient who is enrolled in a clinical trial (subject=Group)
• Special guidance or caveats to be aware of when following a protocol (subject=PlanDefinition)
• Warnings about using a drug in a formulary requires special approval (subject=Medication)
• etc.

A flag is typically presented as a label in a prominent location in the record to notify the clinician of the potential issues, though it may also appear in other contexts; e.g. notes applicable to a radiology technician, or to a clinician performing a home visit. For patients, the information in the flag will often be derived from the record, and therefore, for a thorough and careful clinician, who has the time to review the notes will be redundant. However, given the volume of information frequently found in patients' records and the potentially serious consequences of losing sight of some facts, this redundancy is deemed appropriate. As well, some flags may reflect information not captured by any other resource in the record. (E.g. "Patient has large dog at home")

In line with its purpose, a flag is concise, highlighting a small set of high-priority issues among the much larger set of data in the chart. Readers who want more detail should consult the chart or other source of information. Caution should be exercised in creating Flag instances. If entries are created for information that could be gleaned in a sufficiently timely fashion by reviewing the patient record, the flag list will itself become overwhelming and will cease to serve its intended purpose.

Flags are expected to persist in a record for some period of time and are, at most, targeted to particular types of practitioners or to practitioners in particular system.

Examples of Patient related issues that might appear in flags:

• Risks to the patient (functional risk of falls, spousal restraining order, latex allergy)
• Patient's needs for special accommodations (hard of hearing, need for easy-open caps)
• Risks to providers (dog in house, patient may bite, infection control precautions)
• Administrative concerns (incomplete information, pre-payment required due to credit risk)

Examples of issues that should not appear only in flags:

• Potential allergy or drug interaction to planned therapy (use DetectedIssue)
• Known adverse reaction to a substance (use AllergyIntolerance)

Note that we include "latex allergy" in the "in scope" list, and "allergy" in the "not in scope" list. The Flag resource is not designed to replace the normal order checking process, and one should not expect to see all allergies in Flags. However, if there is an activity that might occur prior to careful evaluation of the record (e.g. donning of latex gloves) and that activity might pose a risk to the patient, that is the sort of eventuality the Flag is intended to support.

Specific guidelines about what type of information is appropriate to expose using Flag, as well as what categories of individuals should see particular flags, will vary by interoperability community.

This API uses FHIR R4 Flag Library.

More information about FHIR R4 Flag specification can be found here.