I’m opening this topic because it may be relevant beyond a single disease context and could apply to various use cases. Clinical guidelines often include “red flags” as checklists to guide actions or modify clinical workups. This approach is common in scenarios like chest pain, headaches, and low back pain. For reference, here are a couple of examples:
In my specific use case, I’m modelling a scenario where clinicians record the presence or absence of red flags for low back pain. Each red flag is assessed individually, and I’m exploring the best way to structure this in a template.
Here’s my current challenge:
The “Precaution” archetype could work, but it would require adding multiple instances of the archetype (one for each red flag), renamed to identify each flag. However, this approach doesn’t allow grouping the flags as a single entity.
Creating a new, use-specific archetype for low back pain red flags doesn’t feel right, as red flags are a broader concept applicable to other conditions.
Potential Solutions I’m Considering:
Developing a generic archetype for red flags that could be customised for various checklists.
Proposing a change request for the “Precaution” archetype to allow the “Condition” data element to have cardinality of 0..*.
I’d love to hear your thoughts or suggestions. Has anyone encountered a similar challenge?
Now I’m thinking that a screening questionnaire (problem/diagnosis or sign/symptom) could also work although some red flags are related to demographics (age, gender), family history…
Yes, looked into this one too! My first thought was that this red flags are sometimes for referral or for specific management protocols without a specific condition being the risk. But I suppose this is the best one and probably expand the description of that element. Thanks as always! And so quick!
Note that the Health risk assessment archetype has its Risk assessment element outside of the internal repeating Cluster, where each risk factor is recorded. So if you want to assess each risk factor / red flag, then you will either need one instance of the Health risk assessment for each red flag, or make a change request to add a risk assessment element within the Cluster. If approved, the existing Risk assessment will need to change to Overall risk assessment.
There is a change request from 2020 about clarifying the difference between Health risk assessment and the screening questionnaires, which are tailored to rule in or rule out a number of issues/questions. Present/Not present questions. There are similarities between a general Symptom/Sign screening and this Health risk assessment. The Health risk assessment were originally made with a specific “disease, condition or health issue” in mind and a number of additional elements to elevate the risk factors.
There might be a need for a new screening questionnaire archetype about “health risks” in general (with smoking, obesity, low income, low physical activity, poor sanitary installations, enviroment issues, ++++) not specific for an identified disease, condition or health issue. There will be some overlap, but the difference is that EVALUATION archetypes are meant for persistence, in opposition to more informal, maybe self-registered, surveys.
Yes, completely agree. I feel there is a need for some type of modification/new development to capture these clinician led assessments (clinical reasoning) that are not actually a stratification of the risk of a condition. I will gather insights from other modellers and clinicians and propose solutions! Thanks for contributing!
If the overall “Health risk assessment” concept isn’t a mismatch, I think it makes sense to be able to enable a “sub-assessment” for each risk factor, and change the current “Risk assessment” to “Overall risk assessment”.
That is a pattern we would recommend for other screening-type archetypes. For e.g. Activities of Daily Living, we found that there was quite variable levels of nesting between different categories e.g Mobility vs continence etc, and it was useful to have at least one-level of nesting, as is being suggested here. As long as
As I understand it, this activity supports the documentation of clinical screening for possible underlying causes of headache, specifically to identify red and orange flags that may require further investigation. These flags reflect differing degrees of urgency.
Red flags relate to acute onset or trauma and may warrant immediate follow-up.
Orange flags relate to chronic or historical issues that may still indicate a need for investigation.
This seems to be an ‘in the moment’ clinical activity, conducted at the time of headache assessment, screening for more serious underlying causality. It is not designed to draw conclusions but rather to provide a consistent method for screening/identifying potential warning issues that may trigger downstream clinical decisions, such as ordering tests or referrals and with an appropriate sense of urgency.
Importantly, from a clinical POV:
This screening activity is time-bound - only relevant at the point in time of headache assessment.
Repeatability needs to be built into the process: clinicians may re-screen as needed during subsequent encounters to observe changes or emerging concerns, or use it in the presentation of every presentation of a headache
Modelling Implications:
Given the need for point-in-time recording and repeatability, the appropriate modelling class is an OBSERVATION.
Note: Use of an EVALUATION especially a risk assessment implies ongoing risk factors that are persisted and is more useful in documenting things like assessment of the risk of cardiovascular disease and identifying mitigating factors for each risk factor. Because it represents a persisting and evolving risk state, a risk assessment EVALUATION can be recorded once and then updated as the individual’s risk factors change. This is not the case for the headache screening.
The screening family of OBSERVATION archetypes could be used, especially symptom/sign screening and problem/diagnosis screening. We could use a combo of both archetypes and represent these flagged issues/conditions into one or either of them. However the flag outlier is clearly ‘older age’ - neither usually a symptom/sign or diagnosis.
However, in this context of a screening purpose of identifying underlying causes of headaches, I’d suggest the Problem/Diagnosis screening could be used alone, framing all the flags as potentially problems or issues which fits with the purpose of “To create a framework for recording answers to pre-defined screening questions about issues, problems or diagnoses.”
Thank you for these valuable insights and the suggested template! I favoured EVALUATION because I view these red flags as components of clinical reasoning, helping to decide whether further management is necessary. However, I hadn’t considered the aspect of repeatability, which is indeed essential.
To complicate matters further, in an ideal scenario where all data is standardiaed, these red flags could potentially be “automated” and flagged for supervision. This would require linking to the actual data such as age, symptom characteristics, physical examination findings, etc. which should be incorporated into this archetype. This falls into CDS, and it’s probably still too early to determine how we can model all these elements in conjunction.
I interpret the identification of these conditions or issues as the evidence on which to make the clinical decisions and reasoning, hence OBSERVATION makes sense to me. If my interpretation of your use case is inaccurate, then please correct me so I may change my recommendation.
History and symptoms, physical examination, test results all are represented using the OBSERVATION class (including CLUSTERs for the finer detail), but the Diagnosis, identification of Adverse reaction, Precautions, Contraindications, Recommendations (the EVALUATION family) comes from the clinical synthesis and reasoning, based on these OBSERVATIONs as evidence.
Pre-existing records of age, recent symptoms and exam findings need to be present in the EHR, probably associated with business rules re the currency/recency(?) to feed into the decision support process about whether there is further investigation required.
If any of these conditions are found to be present, by clinician questioning or CDS querying, then I’d suggest further details using the CLUSTER.symptom or Exam findings family can be recorded, perhaps even in the same commit to the EHR, maybe in the same or a different COMPOSITION. But not in the same archetype, because then we would be duplicating content of the archetypes, which goes against all our principles of archetype design. Associations between clinical data concepts needs to be handled in templates or commits or links etc