Stream: implementers
Topic: Flag extension
Ashwin Djorai (Aug 24 2020 at 08:01):
After discussing in the linked topic, we are mapping our possible patient contraindications to Flag.
We need two extensions for our functional model to map to Flag. one for 'Comment' and one for 'Reason of closure' of the Flag.
Are there more use cases of these kinds of extensions to Flag? If so, perhaps it can be discussed to create core extensions for these functionalities or perhaps to even add them to core.
Ashwin Djorai (Aug 24 2020 at 13:40):
@Rik Smithies
Lloyd McKenzie (Aug 24 2020 at 14:36):
Possible patient contraindications would typically be handled using DetectedIssue. Flag is more for general warnings about the patient. E.g. "pregnant", "latex allergy", "Covid positive", "requires easy-open packaging" - the things you need to see/know before you visit/engage with the patient.
Jorn Duwel (Aug 25 2020 at 07:23):
The DetectedIssue scope states: "Similarly this resource is not to be used to capture clinical facts that may imply contraindications such as pregnancy, breast feeding, patient preferences, past procedures, etc. These would be represented using Condition, Procedure or other resources."
We are using a ValueSet that includes a wide range of potential contraindications like diabetes, but also pregnancy, the desire to have children, practising top sports, wearing contacts, etc. We would like to capture this wide range in one resource type.
Furthermore, we are under the impression that DetectedIssue would be used from the point that an interaction is detected by decision support - while we are capturing the possible contraindications before that point.
Richard Kavanagh (Aug 25 2020 at 10:13):
@Jorn Duwel - we intend to use Flag in exactly the same way
Josh Haskins (Sep 01 2020 at 17:47):
@Lloyd McKenzie - With the line that @Jorn Duwel quoted from DetectedIssue:
Similarly this resource is not to be used to capture clinical facts that may imply contraindications such as pregnancy, breast feeding, patient preferences, past procedures, etc. These would be represented using Condition, Procedure or other resources.
I can see that historically there was a Contraindication resource proposed as part of DSTU2. But when STU3 came around, it appears to be merged into DetectedIssue.
Wondering what you would suggest? Would using the method that @Jorn Duwel and @Richard Kavanagh be the best?
Thank you.
Lloyd McKenzie (Sep 01 2020 at 19:02):
Contraindications (assertions that an action may be problematic based on some other fact in the record) are captured using DetectedIssue. (The resource is broader because it can also identify issues with an action by itself independent of any other resource - e.g. dosage issue.) The individual facts that might result in a contraindication being triggered (age, gender, recent and planned procedures, current conditions, recent lab results, current medications, etc.) are expected to be captured using Observation, MedicationStatement, Patient, Condition and other appropriate resources. Flag is used to 'highlight' certain aspects of a patient's record (allergies, conditions, behavioral issues, etc.) that providers need to be aware of before engaging with a patient. The information represented in a Flag is typically also represented as another resource that provides more detail. The Flag just acts as a highlighted note on the outside of the patient folder to increase the likelihood of clinician awareness.
Josh Haskins (Sep 01 2020 at 21:52):
Lloyd McKenzie said:
Contraindications (assertions that an action may be problematic based on some other fact in the record) are captured using DetectedIssue. (The resource is broader because it can also identify issues with an action by itself independent of any other resource - e.g. dosage issue.) The individual facts that might result in a contraindication being triggered (age, gender, recent and planned procedures, current conditions, recent lab results, current medications, etc.) are expected to be captured using Observation, MedicationStatement, Patient, Condition and other appropriate resources. Flag is used to 'highlight' certain aspects of a patient's record (allergies, conditions, behavioral issues, etc.) that providers need to be aware of before engaging with a patient. The information represented in a Flag is typically also represented as another resource that provides more detail. The Flag just acts as a highlighted note on the outside of the patient folder to increase the likelihood of clinician awareness.
Thank you Llyod for clearing this one up for me.
Jorn Duwel (Sep 02 2020 at 09:59):
Thank you for your summary @Lloyd McKenzie.
DetectedIssue states:
This resource only applies to documenting a risk associated with a specific planned or ongoing action, not a general propensity to risk. The latter would be handled using AllergyIntolerance for substance-specific issues or Flag for other types of issues.
However, our functional model does indeed cover potential contraindications as a general propensity to risk before any medication is actually prescribed (e.g. before a 'specific [...] action'). The clinical fact that is the base of this notion is indeed captured elsewhere and referenced. We are wondering if there is some mismatch between our use of the phrase 'possible contraindication' in English to explain this difference in insight.
Jorn Duwel (Sep 02 2020 at 10:00):
@Richard Kavanagh Aside from the interesting discussion on the use of Flag, do you also recognize the need for the extensions mentioned in the original question?
Lloyd McKenzie (Sep 02 2020 at 13:12):
The fact a patient is diabetic is a Condition - and could be a Flag. The fact it's a bad idea to prescribe a particular medication because they're diabetic would be a DetectedIssue. You'd only get a DetectedIssue if there was some suggestion that the patient might end up starting or was already taking the drug in question. If you wanted to know that, irrespective of patient or timeframe, that a particular medication (or class of medications) was contraindicated for patients who are diabetic, that would be ClinicalUseIssue. Does that help?
Lloyd McKenzie (Sep 02 2020 at 13:15):
I.e. Simply picking the medication and the patient would be sufficient to spawn a DetectedIssue long before you get to the point of a completed signed prescription. However, you wouldn't automatically get DetectedIssues for all possible drugs that might ever be prescribed or voluntarily taken regardless of whether the patient was at risk of taking them just because you mark a patient as diabetic.
Jorn Duwel (Sep 03 2020 at 07:45):
Thanks for your insights Lloyd. I think I better understand the use of DetectedIssue (and ClinicalUseIssue for our future R5 needs). Our functional model starts with a situation where no medication has been picked yet. We want to pick a patient and retreive all 'patient states' (conditions, observations, etc) that could potentially interfere with any medication.
Lloyd McKenzie (Sep 03 2020 at 13:02):
That could be a very long list of information that wouldn't be relevant - especially if you're also identifying what they might interfere with. If the desire is just to pass all of the potentially relevant information to a decision support system (while avoiding non-relevant information), you could look at a custom operation. However, the general pattern is for the decision support system to pull the data via query rather than being pushed the information - because the set of potentially relevant factors is likely to continue to grow and evolve and also because once a candidate drug is selected, the decision support system can grab only the records relevant to that particular med.
Last updated: Apr 12 2022 at 19:14 UTC
