There is or was!!) actually a separate relative position archetype as that can become highly complex , particularly in histopathology and radiology reporting - we split it out just because it would overload the much more common and simple use-case, but I tend to agree that it might help if we loosened the scope.
As this type of vague description is common in healthcare, we’re in no place to disallow their use. 
However, although they describe where in or on the body something is to be performed or occurred, they’re not anatomical locations in the sense we’re using the phrase in the archetype. This archetype, and its siblings for relative locations and circular locations, is intended to be used to describe the location of a mole, but not that the pain is all over the body or that the eye examination should be performed on both eyes.
1 Like
Hi Pedro,
Totally agree with the maximal data set mantra - it’s the fundamental difference between openEHR archetypes and other information modelling.
The issue here is actually about identifying if describing ‘Anatomical location’ identifying a site related to surface anatomy (as per it’s concept description) so that we can identify a mole or lump unambiguously, is a subtly different concept to the body site that needs to support identification of what operation was performed or what the diagnosis might be which may be both in or on the body, usually targeting sites such as limbs or organs within the body such as ‘both tonsils’.
Even as I write this last sentence it is helping me to differentiate the different use cases…
Semantics are not always easy to put into words 
I like this.
Perhaps there is a more generic version - a ‘body location’ or similar, including bilateral/unilateral left/unilateral right to distinguish its different purpose, and that might be used for the purposes of identifying a site on or within the body (so a clearly different intent to Anatomical location) - used for diagnoses, orders, procedures, including a target for radiotherapy.
I think we are still trying to find the vocabulary/semantics to describe what we ‘know’ as clinicians but are finding are subtly different when computing…
We could munge it all into one archetype but I don’t think we are doing anyone a favour - we’ll get munged data back 
Absolutely - relative anatomical location and circular anatomical location. And they fit well as more specific versions of CLUSTER.anatomical location, are intended to work alongside the current archetype and are published and working quite well, I think.
The precision one remains in draft, in the too hard basket until we identify requirements and demand for the model.
Hmmm - replying to myself is not good…
I’ve just remembered speaking to someone recently who was looking at the circular anatomical location model, but they needed to model explicitly where a lump was in 3D. The use case is imaging of breast lumps.
They need to not only identify the ‘circular location’, but also a depth within the breast, such that they can identify one lump from another where there are multiple lumps present, and also to still potentially identify them if the breast is compressed.
This is anatomical location within the body, so it is a requirement that might need us to challenge the Anatomical location being about a surface anatomy/macroscopic level of description.
1 Like
I think that was supported in the ‘precise’ anatomical location archetype by the use of x,y,z coordinates + a reference location, drawn from imaging standards, probably DICOM. Of course there may be other variants.
I’m sensing a semantic separation between:
-
Anatomical location with the current scope of a single site, although we need to ensure that we can do simple 3D descriptors including depth and working up the ‘Precise anatomical location’ using x,y,z, coordinates. This model will be used to record the detail of physical examination lesions or a single lesion on an imaging report (where a ‘thing’ was found), operation/procedure reports (where a ‘thing’ was done),
PLUS -
Body site (or some such similar name) which is intended for ‘coarser grained’ locations in the body - ie regions and organs, including unilateral left, unilateral right and bilateral. This will be used to record the level of detail required for scheduling a procedure, diagnosis at organ/region level or overall imaging report findings ie where all the ‘things’ will be done or were found.
Note: If we need to identifying the detailed location of a single lesion amongst the diagnosis of a multi-lesion condition will still use ‘Anatomical location’, so we should consider whether we need model a SLOT to carry the ‘Anatomical location’ within ‘Body site’).
Is this making sense to others?
Does the ‘Body site’ notion work for registries? What other attributes might be required at region/organ level or groupings of ‘things’?
1 Like
I still find that a really subtle distinction, which I think will cause a plot of confusion on which is the correct pattern to use and , sorry I just don’t understand the utility of separating these ideas into different archetypes, or the practical downside of combining them. At what point does the granularity of the location necessitate a switch from one archetype to another?
I am obviously missing something but where someone does not want or need to say ‘bilateral’ etc, then that can be removed in templating. An alternative might be to make ‘body site’ a specialisation of ‘anatomical location’ to add those values that you feel are not appropriate, that gives some semantic separation but I would still be pretty uncertain as to which was most appropriate.
e.g Problem-diagnosis - in a GP system this could be as granular as left toenail or generic as ‘bilateral pneumonia’ - how/ and when do I decide, and given that this will mostly be a run-time decision, how do we explain to developers which option to choose.
I’ll be interested in Bjorn’s response - my understanding is that as part of their ophthalmology module they need to be able to search for ‘eye’ things, making use of being able to query on the CLUSTER, regardless of its parent. That is going to be almost impossible to do with out searching on both variants.
What’s the downside of using the same archetype? I’m still really unclear about what the practical downsides are to widening the scope of anatomical location. What would go wrong with data quality or querying?
1 Like
It is easy to talk in general terms, so let’s be specific…
- Widening to what concept?
- Exactly what do you propose to change in the model? To support what new use cases?
- What is the upside/downside that you can identify in each specific use case?
- How does it provide more clarity?
- How will people know how to use it consistently if it covers a broader scope?
We’ve reverted the Anatomical location archetype to the latest published version, without the “left and right” option.
We’ll need to continue exploring how to best represent the more vague and/or bilateral locations. For now, our hypothesis is that these can be represented using the diagnosis name for diagnoses, procedure name or a CLUSTER for “Procedure target” or similar for procedures.
It seems to me that the solution to this conundrum depends, first, on agreeing about the scope of the archetype(s). There is an obvious conflict between applicability and simplicity of any archetype.
We use anatomical terms (with all their granularity and semantic relationships), as well as laterality and ‘circularity’, as ontologies for characterizing the broader concept of ‘location within a body’. Also, superficial, less precise definitions, as @heatherleslie noted, can/should be allowed, if we want patients to enter useful data into their own records.
Looking at it that way, it feels odd to separate different expressions of a single concept into different archetypes.
Thinking about different clinical scenarios (point of care, patient self data entry, pathology or imaging requesting or reporting): locating something is one of the most commonly used qualifiers. By referencing all the envolved templates to this one archetype, and then restraining the allowed ontologies in each case, wouldn’t be a more consistent solution?
Also, if the concept was color, how would we allow for expression of that same concept in natural language, rgb code, relative expressions (lighter/darker), etc?
I am not aware of the degree of archetype technology implementation in non-clinical scenarios. But maybe we could take a look into other use cases, beyond healthcare, when defining these ‘human communication reference model’ concepts. 
Thanks Heather,
I’ll give it a go!!
- Widening to what concept?
Broadening the scope of ‘anatomical location’ to cover those situations where ‘bilateral’ and/or ‘left and right’ are justifiable
- Exactly what do you propose to change in the model? To support what new use cases?
I’m not sure we need anything else other than the addition of ‘bilateral’ to laterality. I think the approach to slot in the more detailed ‘precise anatomical location’ archetype where required applies regardless of the approach we take. The existing archetype worked pretty well for quite detailed histopathology work we did a few years ago, and I would expect this would apply to other ordering/reporting requirements.
I don’t think we can rely on ‘bilateral’ being supported in underlying terminologies and in the registry use-case, left, right, bilteral is commonly requested as a separate attribute, so I don’t think the ‘hypothesis’ holds.
- What is the upside/downside that you can identify in each specific use case?
The upside is that we have a single archetype that can be used for single, well-defined locations ‘Bronchoneumonia, left lower lobe’ as well as ‘Bronchopneumonia’, as well as reporting and ordering.
- How does it provide more clarity?
- How will people know how to use it consistently if it covers a broader scope?
The only real difference that I see between 2 different archetypes is the ability to express ‘bilateral’. There are clearly parts of the record where that is not appropriate but others where it is perfectly appropriate but very difficult to pin down outside the context of use, or infer the correct archetype to use.
As an example, I am likely to be looking at Cataract dataset modelling. There may well be places where I want to pin down ‘problem-diagnosis’ or ‘procedure’ to either left or right - to support operational use but there may be other parts of the system where bilteral is required for reporting. I’m happy to manage that by preventing use of bilteral at template level where it is clearly inappropriate or unsafe. That seems much siompler and easier to explain and implement thatn having two otherwise identical archetypes one that supports 'bilateral, and one that does not.
So for unilteral use-case I might have …
Examination of an eye / anterior segment
Result of tests,
Diagnoses, procedures
Should I use anatomical location when I am certain that the locaiton is specific (and how specific does that have to be ) at what point do I need to revert to a potential new ‘body site’ archetype and will the next modeller/developer make the same judgement?
And what will go wrong if I use the same archetype for both, I can always use templates to control use of ‘bilateral’ and querying can differentiate the context of use and whether I want to exclude bilateral.
and yes, agree with @Leuschner!!
1 Like
It’s really a long thread and I might not see the whole picture. Anyway:
The problem discussed seems to be related to the laterality and if we want right, left and bilateral classification. I think it’s great to have the possibility to express laterality this way. For some use-cases you want to express a phenomen using the bilateral qualifier. If you talk about the elbow and the extenstion is limited both in right and left elbow - you might say it is bilateral. That’s fine.
Laterality is not the only problem with location. It get’s even worse when you go into the compositional nature of anatomical location. When you talk about pain in the knee. And you find that the patient locates the pain to the proximal part of patella. How would you express this in the data?
I think there are several ways to store such information in the data. Which in turn makes it harder to reuse the information. For human it will be no problem to read and understand. For machines you need some kind of AI to reason over the data. Very soon you’ll see that you left the situation with simple AQL and reuse. You need more complex reasoning on the content. That’s fine with me. But someone has to take the cost one day
And the to come back to laterality. If you express redused extension in the elbow using right and left, or using the bilateral qualified doesn’t really matter. The software has to reason about anatomical location any way.
That’s my five cents on this topic. Hope I didn’t misundertand everything…
Hi Bjorn,
The key question here is I guess whether we need separate archetypes one for where the location is single and fairly precise, and another for where bilateral is allowed and for other broad locations like x-ray + ‘Chest’ .
I agree about the deeper challenges of anatomical location but Ithink we should steer well clear of trying to go down that road - if that is needed I would absolutely point people to SNOMED-CT , both as solution and as a pointer to the complexity. At that, level anatomy is a biomedical truth and for me, very much the strength of an ontological approach.
IMHO we only need one archetype for anatomical location.
About the deeper challenges:
Yes you need a terminology or ontological vocabulary.I think that’s obvious, unless we are thinking about modelling the core body parts with openEHR archetypes. When using terminologies you need to think careful about the information model in the archetype versus the combined (pre-/post coordinated) expressions in the terminology used. This is what we discuss the most internally - which granularity to use for a given use-case. I guess that is outside the scope of this thread.
This might be an issue/challenge what our two-level modelling method has to deal with as the method push pretty much complexity into domain content modelling. One component of the challenge is that it would be difficult to determine the scope of an archetype in order to produce it as a separate and reasonable “max data set”.
I agree. Other than the current discussion, I am pretty happy with e approach to anatomical location. Arguably laterality could be pushed to SNOMED but lateraility is a very common attribute and many implementers with not have access to SNOMED legally, or have the tech capacity to use it right now.
The issue that Bjorn brings up is if/when we want to get more smart about using detailed knowledge of anatomical relationships and terminology to do smarter processing. To me that just replicates work that has been done in various ontologies elsewhere. The representation is kinda ugly in SNOMED-CT but that mostly reflects the complexity - not something I’d want to ‘own’
1 Like
The key question to me is still understanding the use cases for bilateral. I think clinicians often talk about things being bilateral without wanting for a second that it be recorded that way. Then there are registries and questionnaire where data gets messy for no good reason but just the reality we have to grapple with. Then diagnoses or reporting bilateral findings for tests or ordering bilateral procedures.
If we understand the use cases then bilateral options might need to be represented in various ways. One possiblity is a higher level archetype - it was just thinking out loud and the challenge will be to clearly explain how to use it. This possibility for confusion is a good reason to not consider it as a solution, but at the same time doesn’t justify munging/shoehorning ‘bilateral’ into the Anatomical Location CLUSTER that has been deliberately and, IMO, very successfully modelled explicitly as a single site. In most situations multiple sites for physical exam and test results should be represented by using multiple instances of the single site, which is pure & correct for most EHR data. It is the registries and legacy data where semantics have often not been considered carefully that cause us grief.
Perhaps another more viable interim solution is to specialise Anatomical Location for the messy data, while preserving the published archetype to support best practice.
Personally, I’ve not come across the need to record ‘bilateral’ very often, or I’ve demonstrated how it’s not good data modelling. I have had the use case where audiology testing had to be done on the left ear, right ear or both simultaneously and it was modelled into the archetype directly with absolutely no need for ‘anatomical location’ CLUSTER.
I don’t have enough background use cases to make an informed decision at present… I suspect that more possible situations than we suspect will be managed as per the ‘audiology test’ method. And so our challenge is to identify the outliers.
1 Like