I’m Evelien and works in The Netherlands as CNIO (Chief Nursing Information Officer) in the elderly care (home care).
For a project about SNOMED CT coding of nursing diagnoses and the classifications system (Nanda and Omaha) i have a question to this group. Does someone used a archetype at this moment for Nursing Diagnosis (Risk, Current and prevention)? It doesn’t seem to fit in the archetype ‘Problem diagnosis’.
Currently I don’t think we have one single archetype that fits the whole spectrum of nursing diagnoses, especially if we’re including the “positive” diagnoses used for goals, evaluations and outcomes. I don’t know the Omaha system too well, but I’m fairly familiar with ICNP which I think is similar.
For most of the “actual” and “negative” diagnoses, I think Problem/diagnosis is fine, and for “potential” probably Health risk assessment. For “positive” diagnoses I think we only have Goal right now at a generic level. For “family” and “community” diagnoses I think we could maybe use Family history and related archetypes, as well as several of the archetypes in the Social context project.
I agree with this @siljelb I would say that the problem/diagnosis archetype is a pretty good for most of the categories - perhaps each category templated separately.
I’d also agree re Goal as a seperate archetype but I’d want to understand how the other categories e.g. family history /community are expected to work in the context of the wider record.
There might be an argument for just leaving family history / community diagnoses as simple codes in the Nursing diagnosis, if they are contextual to a nursing plan and not ‘authoritative’ to the overall record.
As a nurse from Slovenia, I am familiar with the NANDA classification, which divides nursing diagnoses into different domains (https://nurseslab.in/care-plan/nursing-diagnosis/nanda-nursing-diagnosis/). I am also new to modelling and am wondering if, when modelling nursing diagnoses following the NANDA classification, we can use the Problem/Diagnosis archetype and link the ‘Variant’ field to an external terminology that would be the NANDA codes for different types of domains? Under ‘Problem/Diagnosis Name,’ I would use coded text to list all the different domains. Would this approach make sense? If a patient has multiple nursing diagnoses, the user can enter several entries of the Problem/Diagnosis archetype.
We could use the problem/diagnosis archetype for many of the NANDA diagnoses. My preliminary thoughts would be to use the problem name for the coded diagnosis. The domain I think will be a nanda specific cluster under extension. I’ve created an early draft model here: Sign In with Auth0 (register for a free account before clicking the link.
The domain cluster hasn’t been added yet, for an example see: Sign In with Auth0
The key question Is wether the eval.problem/diagnosis is a good fit generally for nursing diagnosis, given that some categories of nursing diagnosis are clearly not a good fit, like ‘risk for’ or ‘potential’.
My current gut estimate it’s conceptually and practically too different from regular medical diagnosis the problem/diagnosis was designed for, so it deserves its own archetype. Somewhat similar to how it’s split off in the zibs. Does anyone remember wether this came up during the review process?
I’m curious for your thoughts on this. Especially @heather.leslie
I don’t have a simple answer for this. The nurses I speak with want to be able to record nursing diagnoses, but they are equally clear that this should not be confused with a formal medical diagnosis.
I am no expert, and any nurse is welcome to correct me, but my understanding is that a nursing diagnosis is not a single clinical concept in the way a medical diagnosis is.
I suspect our plan to develop the functional suite of archetypes that we developed in the SparkedAU project will support important aspects of nursing diagnoses:
EVALUATION.functional_impairment_summary (TBD) can capture the problem label, corresponding to the P in a PES statement. It may be appropriate to nest CLUSTER.symptom_sign within this archetype and to include a data element for aetiology, corresponding to the E in PES, which can reference relevant contributing conditions or diagnoses in a similar way to how clinical indication is recorded in other archetypes.
OBSERVATION.functional_ability captures the observable evidence, corresponding to the S in PES, as reflected in the revised concept that replaces the former ADL summary. This archetype is replacing the ‘ADL summary’ which is currently iterating through the review process.
EVALUATION.functional_independence_summary (TBD) captures the level of dependence and associated care requirement.
Once these three archetypes are reviewed and published, we will be better placed to identify any remaining gaps and address them as needed.
It will be really interesting to line these new impairment archetype proposals against our use case in London. It is really high value to nail this area down as best we can.
And, of course, there are very good arguments that the current approach to ‘Nursing Diagnosis’ munges several ideas that we would preferably carry in different parts of the patient record as the primary truth e,g. alerts, impairment, and communication issues.
However, I think you can defend the current Nursing diagnosis list if it is regarded as a contextual problem list, guiding the nursing team on the most important aspects of the patient’s background, in the ‘current episode’ i.e. it is not intended definitive, longitudinal record but essentially a summary of ’what matters’ right now. It also acts a siloed space where the nursing team can control their own list. Ideally, though this should be a lot smarter and interact with the wider record.
We had a similar issue in London, where historically clinicians had a fair bit of leeway on adding ‘alert codes’ but where the problem list was originally fixed to End of Life care . When we opened this up, we found that the alert list was essentially ‘misused’ with the addition of terms like ‘Sickle cell disease’ that in the new system, really needed to be carried as a problem, not an alert. In a way, this is partly just about existing recording methods maturing.
So, I’d be happy to treat Nursing diagnosis as a list of ‘problem/diagnosis’ archetypes in a contextual problem list, accept that it may include some concepts whose primary truth should ideally lie elsewhere, and start the discussion with nursing colleagues about how to move to a more coherent record that is both more accurate and less burdensome.
Sorry if I gave that impression. I thought I was suggesting just the opposite!!
There is clearly a place for a ‘nursing diagnosis list’ and it should be up to the nursing community to decide how this works based on long-standing practice.
However, I don’t see the structure of the ‘nursing diagnosis’ entry being different from current problem/diagnosis, and at least in UK GP systems, we see very similar assertions like ‘Poor mobility’ expressed as coded entries.
So I don’t have a problem in principle about a nursing diagnosis list whichg is quite distinct from a medical model of care. The only issue is that increasingly, some of the items currently carried as NANDA etc codes might be better represented in openEHR (and FHIR) with other structures, to reduce the burden of data entry and better support the wider team around the patient. That will challenge some assumptions about how ‘nursing diagnosis’ is recorded right now, but that discussion should come from within the nursing community.
I guess the wider issue is that every professional group and care service does have to erect some legitimate silos of data - not everything can be managed from a single global perspective. The challenge is to ensure those silos are purposeful and not imposed by organisational, commercial to technical barriers.
Not being a clinician, but having studied this particular question a few times in the past (including interrogating various nurse informaticists over the years), I have not previously thought that the technical data structure i.e. model as such, would be different for physician v nurse, just the content. I know the content can be ‘nursing problems’ such as activities of daily living related problems (home care), and so on - quite different.
I would still expect to use a distinct archetype, because semantically (i.e. at the level of clinical semantics), nursing Dx / problems are quite different, even though it would have the same structure (but almost certainly different coding & bindings). And if it turns out that different structure is needed, then you have a separate archetype already.
This will make life easier for querying, because if you are looking for ‘problems’ or ‘diagnoses’ in the usual sense, you almost certainly don’t want nursing problems / Dx; and if you do, you want to easily get just the nursing ones on their own.
The downside is that if some general improvement is made to the physician’s Problem/Dx archetype, it may have to be replicated to the nursing problem/Dx archetype. But…. this is health informatics after all. We wouldn’t want things to be too easy…
I’d question that assumption. Maybe as a hospital internist yes, but as a geriatrician or GP , I definitely want to be able to easily access the ‘nursing diagnosis’ list and potentially easily transfer it to my own contextual list or even a global problem list.
I’d be happy to see a case made for a specific Nursing diagnosis archetype but so far it feels like the same structure, the main problem being that it uses nursing terminology to ‘overload’ a list of coded tersm with concepts that we preferably handle in specific structures. Using a Nursing diagnosis archetype does not solve that problem as a far as I can see
Agree, I was thinking hospital in-patient - where I think you really don’t want it. The scenario I was thinking of is an aged person who has sporadic admissions, therefore in-patient time, but also nursing outside at home or facility.
In Portugal, we have been recording nursing diagnoses in the EHR since 2005 using the Beta version of the ICNP (we became crystallized in time ). Implementation in practice was not easy, but we realized the importance of having persistent nursing diagnoses in documentation, especially for chronic patients who use numerous health services.
I share Ian’s opinion regarding the existing capacity of the Problem/Diagnosis archetype to capture the spectrum of nursing diagnoses. If we look at the archetype’s concept definition, it aligns with the formal ICN definition: ‘a clinical judgment or label assigned by a nurse regarding a patient’s, family’s, or community’s actual or potential health responses, needs, or life processes.’ Despite the issue with outcomes, the truth is that the semantics present in a significant portion of them can be recorded using the Problem/Diagnosis qualifier archetype. There have already been some attempts to design an archetype for nursing diagnoses, but they focus heavily on being compliant with ISO 18104.
I also agree with Heather that, by default, it should be easy to separate them. But this issue with nursing diagnoses can occur with other health professions (pharmacists, nutritionists, psychologists
Just coming from an ontology and also querying perspective, although the above is clearly true (maybe nurses just got their act together better as a profession ;), the ‘master’ problem list represents (at least in theory) the current working basis for nearly all interventions that are going on. If a patient is being seen by cardiology with a suspicion of stable angina, but there is no ‘stable angina’ in the Dx list, then they are not (yet) a stable angina patient, and a query for people with angina should not find them. A query for (some) symptoms of angina probably should. They might never be an angina patient, if some other cause is found for the symptoms.
So the notional ‘master’ list really is a basis for what is going on treatment-wise, and reported symptoms (and maybe patient requests) with no matching Dx are a basis for what is going on investigation-wise. The master Dx list is the definer for treatment, outside of the annoying category of ailments that are more difficult to diagnose than treat, on an elimination basis. Here in Brazil I recently discovered that it’s common to give kids metronidazole just on vague GI symptoms that could be any of the usual suspects, without doing any microbiology. So ‘giardia’ or ‘shigellosis’ often doesn’t turn up on a Dx list, but there is treatment going on anyway. A physician looking at the meds list will however know what is going on (in fact, they might see nothing, because I think metronidazole is available without Rx here, like a lot of things). We all know this happens all the time, with antibiotics being the most common Rx with no Dx. But for serious Dx, I think my point stands.
I would therefore say it is important to be able to easily machine-distinguish between a master problem list (in the way that @ian.mcnicoll talks about it) and any other kind of problem list. Nursing and other problems are a bit different, since they will appear within a context that is already decided by primary diagnoses. For example a patient reacting to chemo is there having treatment because of a definitive cancer Dx.
All ‘problem lists’ therefore need to be marked in a very standard way if they are to be based on the same archetype, so that any one of them can be isolated in a portable query that will work across all openEHR systems, CDS solutions and so on. As long as that is achieved, I would not foresee problems.
I agree (at last!). Much better to focus on how we name or partition a Master Problem list (if it exists) - perhaps there is a case for a specific Master problem list composition? We are probably creeping very close to what that should look like with the IPS/EHDS work, and even a ‘standard openEHR template’
). Implementation in practice was not easy, but we realized the importance of having persistent nursing diagnoses in documentation, especially for chronic patients who use numerous health services.