If somebody wants to create a mixed high-fidelity architecture, I’m sure they’re also willing to fund and guide the mapping efforts.
We first need to finish the basics like IPS and EHDS, unless this is done its a nice discussion.
Documentation is a thing, the data type mappings can fill 20 pages (“simple mapping guidance”), you need to manifest this things into tooling its way to much.
Also there is no single place for documentation i spend good amount of time collecting this stuff from everywhere.
This is why im pushing here for FHIRconnect also to collect these bits (@Ian_Bennett is currently working on a better integrated documentation).
I agree - all I’m suggesting is that we make it clear that the current mappings re suitable for low-fidelity scenarios and for ‘sharing out’ but highlight issues which might cause problems importing to high-fidelity envirnments. Important to get the initial work done with a realistic scope but also important that we highlight that is is not fully done (or possibly even doable) for all situations.
2 Likes
Agree, if you encounter this cases, please raise an issue on the FHIRconnect mapping library.
We will try to add more documentation for users, i want this “guidances” to just contain the bits that are the edge-cases.
So they get a standard set, but also the information how to deal with cases.
I will map this status.
How do we deal with the case users not having an exclusion and differential archetype in their template.
Imagine you map this against a template where people didnt think of an exclusion or differential archetype.
What should happen ? No mapping at all ?
Mapping it with a different status code ?
I enjoy your certainty, but it does have something to do with the clinical process, because the fact that something was wrongly asserted due to record keeping errors is a real fact of clinical relevance if/when it may or did lead to the wrong treatment. In such cases, the fact that it was asserted wrongly is a true fact that remains relevant to the care process.
If it was truly wrong and that was never relevant to the care process, then it would just be deleted.
This was our real process in the lab where I worked, btw.
Grahame
I agree, what tom isnt saying here we have an audit and version process to capture technical “stuff”.
The VERSIONED_OBJECT as an technical workflow, at least as far as i understand.
Which has change_types:
As part of the audit you can also provide a description:
It might be valuable to add “entered-in-error” in a more standardized way, rather than just as free text as part of a deletion.
But is deletion even the correct approach here?
As Grahame mentioned, an entry marked as entered-in-error could still have resulted in subsequent treatments that are linked to this (now “deleted”) object. I’m also wondering how to handle those treatments, they’re based on something entered in error, but they still happened and shouldn’t be considered non-existent.
Is it enough to link them to the “deleted” entered-in-error composition.
Also that would need to be made visible to the users.
and that is true but I think what Graham is saying (and I agree) is that in a disconnected message-driven system there is not necessarily a clean technical approach which can safely say - entered-in-error notification → automatically just create a DELETE/UPDATE in openEHR.
Ultimately that is where it will probably land, but I would expect some sort of clinical review in most cases, except in simple secondary uses read-only/registry.
So both perspectives are IMO correct.
-
If you want to properly redact an erroneous record reported from elsewhere, it is not as simple as just setting an Entered-in-error attribute on that record if it is going to be used for ongoing care especially if it is some sort of primary record.
-
Re-versioning the record as per openEHR is IMO a much safer way of managing this, but equally in many case re-versioning/logical delete etc is not likely to be a wholly automatic process in the context of what is essentially an external notification of error. And that will also happen in openEHR between CDRs unless they are already very tightly co-governed.
1 Like
It’s not that it’s not a real thing (erroneous data entry) it’s just that ‘entered-in-error’ is not a possible value of the status of a clinical diagnosis. It is a possible reason for a new version of some data (i.e. ‘error correction’). The way it is done in the HL7 term set is mixing two completely different aspects of real world activity into the one value space.
1 Like
Sorry to be late to the conversation.
’Refute’ - my local FHIRman, Brett Esler, tells me “I think refuted is, like most things, not very well defined so expect it is used in all ways including both stating a negation without a prior assertion or negating a previous assertion…”
To make an assumption of mapping our archetype values to one definition or the other seems dangerous and if we don’t clearly know the intent it should probably not be mapped from a clinical safety point of view. openEHR exclusions are only valid at the time of recording and negations of existing data has a whole lot of other implementation/workflow implications. Feels like a red flag moment to me.
’Entered in error’ is something we all need to do all the time. In openEHR systems it is usually part of the implementation ie a reason for ‘removal’ of a record ie effectively inactivated. In messages it is another important piece of information, but feels uncomfortable to conflate to a ‘Status’ as done in FHIR; it has never been modelled in any of the archetypes.
2 Likes
Another is to align the two approaches.
I certainly see inconsistency in our archetypes that could be improved eg Adverse reaction event CLUSTER has values of:
-
Unconfirmed [It has not been objectively verified that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’.]
-
Confirmed [It has been objectively verified that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’. This may include clinical evidence by testing, re-challenge or observation.]
-
Refuted [It has been disputed or disproven that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’, with a sufficient level of clinical certainty to justify invalidating the assertion. This may include clinical evidence by testing, re-challenge or observation.]
Diagnostic certainty in EVAL.problem_diagnosis has the values of:
-
Suspected [The diagnosis has been identified with a low level of certainty.]
-
Probable [The diagnosis has been identified with a high level of certainty.]
-
Confirmed [The diagnosis has been confirmed against recognised criteria.]
There are others.
We’ve known these qualifiers are messy for a long time, and put it a lot of work already, but we can probably do even more to improve the situation. Careful documentation of each of these inconsistencies and issue provides us with more context of the problem that needs to be solved. There are many qualifiers/statuses that are used loosely and inconsistently. Here is a chance to align the FHIR/openEHR approaches and to improve future data.
I suspect if we can deconstruct these qualifiers, present them in a logical manner with each separate axis identified and defined and justify the differences, clinicians would potentially agree and use these terms more specifically and consistently. It would be a global public good! 
I know we’ve tried this previously with the Problem/Diagnosis qualifier and we definitely made progress within that single archetype, but now we’re confronted with similar value sets in other archetypes and in FHIR models. Perhaps we now have the context to make better choices and definitions and offer guidance on how to use the terms better. Then building semantically consistent mappings also become easier.
It seems to me that we have a number of choices:
- Build CLUSTER archetypes that are purpose built for FHIR status integration but will create at least some level of openEHR/clinical semantic/technical debt eg for ‘entered in error’
- Long term: Work on better designing this messy data, get clinical consensus, lead by identifying best evidence clinical practice/definitions and potentially influence FHIR resources/profiles.
- Short term: Map between existing FHIR and openEHR artifacts. Some are clear mappings and clinically sound, some are not. At the moment it feels like we are dealing with a number of square peg, round hole situations and this is a red flag moment for me. Maybe it is a practical short term solution but it comes at a cost.
No, I like the way you are thinking. We can do better, I think.
1 Like
I think this will give us the best long-term outcome though!
1 Like