We typically use the Family History archetype to capture these details, along with SNOMED CT disorder codes .
Essentially using Post Coordination through the information model and the FH archetype to capture this data . i.e a disorder code of Diabetes Mellitus with the FH archetype which uses the FH situation code.
What is the consensus on instead using SNOMED CT situation codes. (which are essentially precoordination: FH of Diabetes Mellitus)
How do these mechanisms of data capture affect reporting or dashboarding.
For eg. wanting to find all patients with a particular disorder vs wanting to find all patients with a particular family history and not confounding these results.
What would also happen to data integrated into an OpenEHR CDR from an EHR that captured this data as the stiuation code? Would that then be deconstructed and mappd to the FH archetype with disorder codes?
I know what i’ve been doing in practice and the diffeence between using the archetypes to search in AQL, but i want a clear /unbiased? answer to share with someone who isn’t as familiar.
Super quick response, I think we’ve discussed in the past that both the precoordinated “fh of disorder” and the basic “disorder” terms can be used in the “Family history” archetype. But the “fh of disorder” terms should never be used in the “Problem/diagnosis” archetype. I don’t think we’ve documented this anywhere, and I may misremember it. @heather.leslie, what are your thoughts?
The archetype has been designed to avoid the need for pre-coordination, but that doesn’t mean you can’t use it, especially for integration purposes.
I have always designed for the principle that if we can design a high-quality value set for all conditions, then they can be reused in both Problem/Diagnosis and Family history and anywhere else that is clinically relevant. Reuse always!
Pre-coordination is almost always problematic in my experience as part of the desired value set usually missing. That said pre-coordination is brilliant for body-site/anatomical location as there is a fixed number of sites and it is a pain to select laterality and site every, single, time…
Thanks for bringing this up (again). It remains a highly relevant topic. Just wanted to share this related topic from time ago. Where @mikael taught me about snomed ct default context. Semi structured narrative data - #31 by joostholslag
This was one of my concerns, that in many cases the pre-coordination in SNOMED is not exhaustive, we certainly encountered that in the case of laboratory values also that with the archetypes you can essentially add granularity to the data collection as needed that you might not get with pre-coordination. There are definitely use cases for both.
Concern has been expressed about analytics being confounded by the disorders that could be listed in Diagnosis/Problem vs Family History. My thought was that AQL would essentially preclude this, as you search based on the archetypes which are distinct in this case. How would that carry over for analytics using a tool like Apache Superset?
@joostholslag was there supposed to be a link to a topic?
I think it is semantically safe to do like this, but also that mixing “fh of disorder” and “disorder” concepts in a “Family history” archetype would probably only complicate things. Since there are 580 “Family history of clinical finding” concepts (<< 416471007 |Family history of clinical finding (situation)|) and 120 295 “Clinical finding” concepts (<< 404684003 |Clinical finding (finding)|) in the current international SNOMED CT release and it would surprise me if there are any “Family history of clinical finding” concepts without a corresponding “Clinical finding” concepts, I would say that it would be easier to only use “Clinical finding” concepts in “Family history” archetypes.
Technically I guess we could be actually asserting a family history of a ‘fh of disorder’ to use those concepts within a FHx archetype, which then potentially requires further processing
However, we will come across “Family history of clinical finding” concepts during integration and that requires a human intervention such as mapping. There is no simple, straighforward answer for all situations.
All (or at least close to all) “Family history of clinical finding” is modelled using the same pattern with a relationship of type |Associated finding| that points out the related “Clinical finding” concept for the “Family history of clinical finding” concept. (See an example with the concepts 160377001 |Family history: Asthma (situation)| and 195967001 |Asthma (disorder)| below.)
It is therefore possible to use a good terminology service to automatically “convert” from a “Family history of clinical finding” concept to a “Clinical finding” concept without manual mapping.
I certainly agree, and using the “Associated finding” relationship of any “family history of …” terms encountered would probably make for better quality data. But it should still be valid (though a bit messy) to enter the “family history of …” term into the “Family history” archetype, in case there’s no available terminology service, or the terminology used doesn’t have this kind of relationship.
I think that we need to have a commonly agreed implementation guide here.