FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

8.14 Resource Flag - Content

Patient Care icon Work GroupMaturity Level: 1 Trial UseSecurity Category: Patient Compartments: Device, Patient, Practitioner

Prospective warnings of potential issues when providing care to the patient.

A flag is a warning or notification of some sort presented to the user - who may be a clinician or some other person involved 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 a 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, prepayment required due to credit risk)

Examples of issues that should not appear only in flags:

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.

Flags may highlight a highly condensed view of information found in the AllergyIntolerance, Condition, Observation, Procedure and possibly other resources. A common extension allows the linkage of a Flag to the supporting detail resource. The purpose of these other resources is to provide detailed clinical information. The purpose of a Flag is to alert practitioners to information that is important to influence their interaction with a Patient prior to detailed review of the record.

Flags are not used to convey information to a specific individual or organization (e.g. an abnormal lab result reported to the ordering clinician, reporting of an adverse reaction to a regulatory authority). These are handled using the CommunicationRequest and the Communication resources.

Flags are not raised as a result of a reported or proposed action (e.g. drug-drug interactions, duplicate therapy warnings). These would be handled using DetectedIssue.

No references for this Resource.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Flag TUDomainResourceKey information to flag to healthcare providers

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierBusiness identifier

... status ?!Σ1..1codeactive | inactive | entered-in-error
Binding: Flag Status (Required)
... category Σ0..*CodeableConceptClinical, administrative, etc
Binding: Flag Category (Example)

... subject Σ1..1Reference(Patient | RelatedPerson | Location | Group | Organization | Practitioner | PractitionerRole | PlanDefinition | Medication | Procedure)Who/What is flag about?
... period Σ0..1PeriodTime period when flag is active
... encounter Σ0..1Reference(Encounter)Alert relevant during encounter
... author Σ0..1Reference(Device | Organization | Patient | RelatedPerson | Practitioner | PractitionerRole)Flag creator
... supportingInfo 0..*Reference(Condition | Procedure | AllergyIntolerance | Observation | RiskAssessment)Extra information to use in context of the flag


doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

Flag (DomainResource)Business identifiers assigned to this flag by the performer or other systems which remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]Supports basic workflow (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)FlagStatus! »Allows a flag to be divided into different categories like clinical, administrative etc. Intended to be used as a means of filtering which flags are displayed to particular user or in a given contextcategory : CodeableConcept [0..*] « null (Strength=Example)FlagCategory?? »The coded value or textual component of the flag to display to the usercode : CodeableConcept [1..1] « null (Strength=Example)FlagCode?? »The patient, related person, location, group, organization, or practitioner etc. this is about record this flag is associated withsubject : Reference [1..1] « Patient|RelatedPerson|Location|Group| Organization|Practitioner|PractitionerRole|PlanDefinition| Medication|Procedure »The period of time from the activation of the flag to inactivation of the flag. If the flag is active, the end of the period should be unspecifiedperiod : Period [0..1]This alert is only relevant during the encounterencounter : Reference [0..1] « Encounter »The person, organization or device that created the flagauthor : Reference [0..1] « Device|Organization|Patient| RelatedPerson|Practitioner|PractitionerRole »Additional information that may be relevant to the flag, such as why the flag was created or how to guide management of the flagsupportingInfo : Reference [0..*] « Condition|Procedure| AllergyIntolerance|Observation|RiskAssessment »

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Flag;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business identifier
  fhir:status [ code ] ; # 1..1 active | inactive | entered-in-error
  fhir:category  ( [ CodeableConcept ] ... ) ; # 0..* Clinical, administrative, etc
  fhir:code [ CodeableConcept ] ; # 1..1 Coded or textual message to display to user
  fhir:subject [ Reference(Group|Location|Medication|Organization|Patient|PlanDefinition|Practitioner|
  PractitionerRole|Procedure|RelatedPerson) ] ; # 1..1 Who/What is flag about?
  fhir:period [ Period ] ; # 0..1 Time period when flag is active
  fhir:encounter [ Reference(Encounter) ] ; # 0..1 Alert relevant during encounter
  fhir:author [ Reference(Device|Organization|Patient|Practitioner|PractitionerRole|RelatedPerson) ] ; # 0..1 Flag creator
  fhir:supportingInfo  ( [ Reference(AllergyIntolerance|Condition|Observation|Procedure|RiskAssessment) ] ... ) ; # 0..* Extra information to use in context of the flag
]

Changes from both R4 and R4B

Flag
Flag.subject
  • Type Reference: Added Target Types RelatedPerson, PractitionerRole
Flag.author
  • Type Reference: Added Target Type RelatedPerson
Flag.supportingInfo
  • Added Element

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

See R4 <--> R5 Conversion Maps (status = See Conversions Summary.)

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Flag TUDomainResourceKey information to flag to healthcare providers

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierBusiness identifier

... status ?!Σ1..1codeactive | inactive | entered-in-error
Binding: Flag Status (Required)
... category Σ0..*CodeableConceptClinical, administrative, etc
Binding: Flag Category (Example)

... subject Σ1..1Reference(Patient | RelatedPerson | Location | Group | Organization | Practitioner | PractitionerRole | PlanDefinition | Medication | Procedure)Who/What is flag about?
... period Σ0..1PeriodTime period when flag is active
... encounter Σ0..1Reference(Encounter)Alert relevant during encounter
... author Σ0..1Reference(Device | Organization | Patient | RelatedPerson | Practitioner | PractitionerRole)Flag creator
... supportingInfo 0..*Reference(Condition | Procedure | AllergyIntolerance | Observation | RiskAssessment)Extra information to use in context of the flag


doco Documentation for this format icon

See the Extensions for this resource

UML Diagram (Legend)

Flag (DomainResource)Business identifiers assigned to this flag by the performer or other systems which remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]Supports basic workflow (this element modifies the meaning of other elements)status : code [1..1] « null (Strength=Required)FlagStatus! »Allows a flag to be divided into different categories like clinical, administrative etc. Intended to be used as a means of filtering which flags are displayed to particular user or in a given contextcategory : CodeableConcept [0..*] « null (Strength=Example)FlagCategory?? »The coded value or textual component of the flag to display to the usercode : CodeableConcept [1..1] « null (Strength=Example)FlagCode?? »The patient, related person, location, group, organization, or practitioner etc. this is about record this flag is associated withsubject : Reference [1..1] « Patient|RelatedPerson|Location|Group| Organization|Practitioner|PractitionerRole|PlanDefinition| Medication|Procedure »The period of time from the activation of the flag to inactivation of the flag. If the flag is active, the end of the period should be unspecifiedperiod : Period [0..1]This alert is only relevant during the encounterencounter : Reference [0..1] « Encounter »The person, organization or device that created the flagauthor : Reference [0..1] « Device|Organization|Patient| RelatedPerson|Practitioner|PractitionerRole »Additional information that may be relevant to the flag, such as why the flag was created or how to guide management of the flagsupportingInfo : Reference [0..*] « Condition|Procedure| AllergyIntolerance|Observation|RiskAssessment »

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Flag;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:identifier  ( [ Identifier ] ... ) ; # 0..* Business identifier
  fhir:status [ code ] ; # 1..1 active | inactive | entered-in-error
  fhir:category  ( [ CodeableConcept ] ... ) ; # 0..* Clinical, administrative, etc
  fhir:code [ CodeableConcept ] ; # 1..1 Coded or textual message to display to user
  fhir:subject [ Reference(Group|Location|Medication|Organization|Patient|PlanDefinition|Practitioner|
  PractitionerRole|Procedure|RelatedPerson) ] ; # 1..1 Who/What is flag about?
  fhir:period [ Period ] ; # 0..1 Time period when flag is active
  fhir:encounter [ Reference(Encounter) ] ; # 0..1 Alert relevant during encounter
  fhir:author [ Reference(Device|Organization|Patient|Practitioner|PractitionerRole|RelatedPerson) ] ; # 0..1 Flag creator
  fhir:supportingInfo  ( [ Reference(AllergyIntolerance|Condition|Observation|Procedure|RiskAssessment) ] ... ) ; # 0..* Extra information to use in context of the flag
]

Changes from both R4 and R4B

Flag
Flag.subject
  • Type Reference: Added Target Types RelatedPerson, PractitionerRole
Flag.author
  • Type Reference: Added Target Type RelatedPerson
Flag.supportingInfo
  • Added Element

See the Full Difference for further information

This analysis is available for R4 as XML or JSON and for R4B as XML or JSON.

See R4 <--> R5 Conversion Maps (status = See Conversions Summary.)

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

PathValueSetTypeDocumentation
Flag.status FlagStatus Required

Indicates whether this flag is active and needs to be displayed to a user, or whether it is no longer needed or was entered in error.

Flag.category FlagCategory Example

Example list of general categories for flagged issues. (Not complete or necessarily appropriate.)

Flag.code FlagCode Example

Example list of detail codes for flagged issues. (Not complete or necessarily appropriate.)

The Flag resource is sometimes used as "patient notes" and MAY be used to warn of issues such as:

  • Issues that impact on the patient's ability to receive/respond to care the care provision process itself (e.g., poor language comprehension, low compliance expected)
  • Issues that impact on the ability to provide care (e.g., patient has a big dog at home)
  • Financial matters (e.g., patient is a bad debtor)

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionExpressionIn Common
authorreferenceFlag creatorFlag.author
(Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson)
categorytokenThe category of the flag, such as clinical, administrative, etc.Flag.category
datedateTime period when flag is activeFlag.period26 Resources
encounterreferenceAlert relevant during encounterFlag.encounter
(Encounter)
29 Resources
identifiertokenBusiness identifierFlag.identifier65 Resources
patientreferenceThe identity of a subject to list flags forFlag.subject.where(resolve() is Patient)
(Patient)
66 Resources
statustokenactive | inactive | entered-in-errorFlag.status
subjectreferenceThe identity of a subject to list flags forFlag.subject
(Practitioner, Group, Organization, Medication, Patient, PlanDefinition, Procedure, PractitionerRole, RelatedPerson, Location)