Is there a designated archetype for blood group information (potentially a work in progress) accounting for different blood group systems and potential factors influencing blood type status? The only one I’ve found so far that is heading towards what I’m looking for is this one: Clinical Knowledge Manager. Although blood types are inherited, they can change (i. e. after a bone marrow transplant). So it might be reasonable to include such “change factors” explicitly in the archetype.
1 Like
@videhasharma is leading some work on data models to support Living Donor management of a Kidney transplant service , and blood groups came up there. For now, while getting some expert opinion, we are using the generic lab test archetypes.
From my (ancient) clinical practice, we were always told never to trust historical blood grouping/typing, but to retest every time. The idea of a ‘blood group’ as a persistent record was definitely discouraged.
2 Likes
Hi Sarah, welcome to the openEHR community (aka “congregation” 
)
The Blood matching archetype you linked to in the Apperta CKM were uploaded from the international CKM in 2016. Since then, it has been rejected in Sept 2018 with the reason: “Outdated pattern, now part of OBSERVATION.laboratory_test_result.”
If there are good reasons NOT to use the OBS.laboratory_test_result, it would be interesting to know the requirements. It can’t be ruled out that it some time will be developed an archetype for a summary information about blood group and other information related to that. But it needs thorough investigations on the requirements, and concrete use cases that supports them.
Can you share a bit of your needs, and how the archetype should be used?
2 Likes
The Blood matching archetype started life in the international CKM but was rejected in favour of including it as part of the Laboratory test result family, which means that the group, RH, antibodies etc should be represented in a separate CLUSTER archetype. I suggest not to reuse the analyte cluster but actually model it explicitly because the data is safety-critical.
If the results change post-transplant then these can be recorded accurately and queried safely.
In addition, ABO et al is usually confirmed pre-transfusion to minimise any potential mismatch with donated blood.
I’d like to understand more about what you mean about ‘change factors’, although suspect that if they are not a part of the test result itself, there needs to be another place to record it. Perhaps alongside the details about the transplant in Problem/Diagnosis?
2 Likes
This is also my experience, before blood transfusion, I’d need two test for blood group, one of which had to be recent (48hours I believe).
But a single place to find a ‘persistent’ blood group together with other persistent data like medical history still makes sense to me. It could contain a physicians statement about the individuals blood group, links to relevant lab results, and a last updated date_time. But I do feel the risk of this is currently bigger than the use, compared to blood group as part of cumulative historical lab results view. Risks are, misunderstanding the data, duplication (and all it’s problems), and specifically the risk the user accidentally records a persistent blood group that is different than the observed blood group from a test.
So I agree with Vebjørn it needs thorough investigation. Specific usecases are crucial here. So I hope @Snee and Ians companions will provide them.
I also like the statement from heather it should be a specific cluster, not the normal cluster.analyte_result. But maybe it would be nice to specialise that cluster.analyte_result?
Edit: had a go at the specialisation pattern I described (might be some adl1 vs 2 goofs in there): GitHub - joostholslag/blood-group-archetypes
1 Like
Recording Blood group is interesting. Clearly ABO group is not going to change, but other factors might. For example, as a woman goes through pregnancy the Rh antibody status may change.
Clinical practice requires easy access to the blood group for emergencies, especially regarding universal donor etc, but elective transfusion will require a new test prior to administration of any blood product to minimise transfusion reactions.
From RCPA Manual - BLOOD GROUP AND ANTIBODY SCREEN:
- Routinely performed with blood group prior to blood transfusion. The presence and nature of antibodies determine selection of donor blood for compatibility testing.
- Component of routine Antenatal screening, to predict and define possible haemolytic disease of the newborn.
- Used in defining specificity of antibodies in immune haemolytic anaemia."
Theoretically, it should be safe to persist the blood group but NOT the associated Rhesus and other antibody results. And of course, if we record the ABO group in an OBSERVATION, we know that the class is intended as event-based & not for persistence in the same way an EVALUATION might be recorded.
If we rely on copying of data from OBS to EVALs for persistence we run the risk of errors or duplication etc and this should be avoided.
While we always want to see the latest test result, I’m wondering if we can engineer a ‘relative persistence’ - to present the result of a query for the latest ABO test result and store it within a dedicated persistent COMPOSITION.
Thoughts?
1 Like
Thanks for hooking me in to this really interesting discussion.
I just picked up the phone and spoke to the transfusion lab scientist here in Manchester (benefits of being on call) - so they actually describe ABO and Rhesus status as something that is persistent for life, ie. based on your genome. Indeed the main exception is bone marrow transplant where someones ABO/Rhesus status may transition to the donor’s status over a period of time. Also, a rhesus status result may come back different to the baseline rhesus status if someone has just received a transfusion or during/shortly after pregnancy - however this would transition back to the baseline rhesus status over time.
With this in mind, I wonder whether there is a need to record ABO/Rhesus in two ways - one persistent result representing the patients baseline status and one to represent the latest lab result (which typically used for confirmation of the baseline prior to potential transfusion or transplantation as part of workflow).
Happy to have a chat about this and engage any other domain experts if helpful. We are doing similar work with HLA type, which has similar nuances in terms of modelling.
Thanks!
4 Likes
I guess the critical question would be "why not just look for the most recent result?’ - what is the value in persisting the baseline, particularly if it might take a while to return to (or if ever). Presumably the ?headline need is to understand the patient’s current status
3 Likes
If the baseline ABO group can (in rare circumstances as outlined above), change, then I tend to agree with Ian and others that persisting it as part of an EVAL has limited value, given that it will always be tested prior to a planned transfusion, except in the case where an emergency transfusion of unmatched O-ve is required.
Do we also need to consider what happens at donation centres? Clearly, they record the donor’s ABO and rhesus status on a ‘donor card’, at least they do in the UK. Would their requirements for a persistent record be different from, or separate to the patient’s EHR?
One could just record the observation (design pattern discussed above) in a persistent (probably episodic) composition. It would be a ‘duplicate’ since the original data is off course event based. But I think that’s acceptable in this case (and many others). It does relate to the other discussion going on: https://discourse.openehr.org/t/how-accurately-do-we-model-copied-data
@johngrant4est would you be able to supply a copy of the current “donor card”? There’s often a lot of context to learn from an exact copy I find.
2 Likes