Anatomical location

Clinical
1

Dear informatics colleagues,

A tricky semantic conundrum for you.

The Anatomical location archetype was published initially in 2015 and then republished in 2017 as 1.1.0 - https://ckm.openehr.org/ckm/archetypes/1013.1.587/18. The intent was to be able to identify a specific place on the body, at a surface anatomy/macroscopic level, where we observed tenderness or a lump, lesion, burn, laceration, bruise or similar as part of physical examination. In that context it only made sense that a lump could only be in one place, and if there were multiple lumps then we need to be able to describe the location of each lump in sufficient detail so that we could tell one lump from another on physical examination or accurately record which lump we had excised.

Confusion starts to arise when people want to express clinical findings the other way around in some circumstances. We wouldn’t usually say bilateral lumps or burns, but describe the findings specific to each lump. But it is not unreasonable to want to describe that there was bilateral pneumonia as part of an assessment on an Xray or as a diagnosis. Or to schedule a ‘Bilateral myringotomy’ procedure to be put on the surgical wait list - both ears to have grommets inserted. Or a problem list might record bilateral hip replacements as being done, even though they were done a year apart and would have been recorded as separate operations at the time. There have been occasions where modellers have wanted to use the anatomical location archetype to support these kinds of use cases, especially in the messy areas of secondary use of data eg in a registry, but they are subtly (and importantly) different.

In Mar 2017, a change request was made - CR-149 ‘Left and right are not sufficient for laterality’. You can see in the notes that I pushed back quite strongly, and we eventually agreed that the data was messy in registries. I think that this resulted in the creation of the ‘Anatomical side’ archetype in the Apperta CKM as a means to resolve the local registry data representation.

In July 2019, there was an additional request to add ‘a body part’ with the ability to specify if it is ‘left / right / both sides / middle / unknown’ - see Discussion thread entitled ‘Laterality’. The clinical context was another data registry requiring recording of the part of the body irradiated - for example ‘Irradiated target: palatine tonsils; Position of the target area: bilateral.’

In 2019, we decided to try to embrace this repeatedly stated need, despite the fact that it broke our original intent. We added ‘left & right’ as a value to ‘Laterality’ and added the ‘Occurrence’ data element with values ‘Unilateral’ and ‘Bilateral’. This archetype is currently our latest revision, in the ‘Reassess’ state meaning that it needs to go through a review to ratify or amend the new content before republishing.

However as I’ve considered starting a new review, I’m increasingly uncomfortable with the new content. It is hard to express it precisely, but changing the scope/intent of the archetype has compromised it’s original integrity. It is hard to explain/justify the changes to outsiders, which raises a red flag that this is not a semantically sound model.

It is interesting to note that we have created a modelling pattern that has been used successfully in many archetypes now, but started in the Blood Pressure model where we added both a data element for ‘Location of measurement’ and then also a SLOT to carry the ‘Anatomical location’ archetype if we needed to describe the site in more precise details. For 99% of situations we anticipate that the simple coded value set has been adequate, and I certainly haven’t ever had the need to fill the SLOT. IMO the key point here is that we identified that while we were more recording the method of taking the BP using a general body site value set, recorded as part of Protocol rather than a precise anatomical location within the Data itself - this is an important, but subtle difference.

So when we consider how to record a target for irradiation, it is also more a method rather than purely describing where something was on the body. So in an INSTRUCTION for radiotherapy it seems appropriate to record the ‘Target area’ as ‘bilateral palatine tonsils’ rather than the ‘Anatomical location/site’ of bilateral tonsils. If a precise area needed to be described then a SLOT for use of Anatomical location might be useful to describe each site accurately (as per the BP pattern).

Similarly ‘bilateral pneumonia’ or ‘bilateral hip replacements’ are fine to be recorded as ‘Problem/diagnosis name’ or ‘Procedure name’.

So, currently the archetype’s reassess status needs resolution, and our usual way to do that is to send it out for another review, but in a review it is not easy to support reviewers to understand the history, context and specific issues needing resolution.

This is a long post, but the point of it is to request feedback on a proposal to revert the archetype back to the last published revision, focused on describing a single place on the surface of the body.

I’d appreciate your thoughts.

6 Likes
2

Thank you for a thorough and well formulated description of the issue!

I agree that an anatomical location should be restricted to only a single location, it doesn’t make sense to have two, or even more than two, as “here and there” and “all over”, which is a totally different concept. I don’t think anyone would suggest that, but it illustrates that an anatomical location should not be more than one. It doesn’t fit the concept.
I also agree that in diagnoses “bilateral” is suitable (example: 396286008 | Bilateral bronchopneumonia
(disorder)), and “target” for defining where a procedure should be performed is also a good suggestion (example: Both ears (body structure) SCTID: 34338003).

To be clear: I’m in favour of returning to the latest published version of Anatomical location.

1 Like
3

So if we revert, how do we handle the’ left/right/bilateral’ pattern because this is often how it is presented in registry-style settings and without any ability to use SNOMED pre-coordinated terms like ‘bilateral pneumonia’ (which) may not even exist for the particular condition specified?

I’m not too bothered about the difference between ‘bilateral’ as in ‘both at the same time’ vs. bilateral ‘true but in separate events’. I think it will be very hard to explain that difference, or in many cases it will not really matter.

2 Likes
4

Depends.
What’s the use case? Bilateral ‘XYZ’ in an order, procedure, diagnosis…? We need to collect these use cases and identify the patterns to solve them.
Anatomical location is not an archetype about laterality but is primarily describing how we describe where something is within the context of a physical examination.
We need to investigate how laterality can potentially exist in other archetypes, where bilateral/unilateral left/unilateral right is valid and expected.

1 Like
5

Hi,

I could be missing the point here, but here’s my take.
My grip of the archetype technology tells me that it should represent the maximal data set concerning a concept.
In that sense, any kind of description of an anatomical location should be flexible enough as to allow for different expressions of it. Either absolute or relative, either precise or as general description. For example, medial to or lateral to something is a common way of ascertaining a location for a clinical finding.
I find some clinical uses for these less precise concepts. For example, describing an exanthema, or diffuse myalgia.
Thus, shouldn’t we allow for this type of description?

A quarta, 13/05/2020, 13:56, Heather Leslie via openEHR <discourse@openehr.org> escreveu:

6

I think you outlined the use-cases pretty well. procedures, orders diagnoses. i.e in various places in existing archetypes that use ‘anatomical location’ to support ‘laterality’, there are some cases where modellers are asked to express ‘bilateral’ as a separate data point i.e not pre-coordinated. That may be reasonable report of what happened 'myringotomy - left/right/bilateral vs. arguably unreasonable hip replacement left/right/bilateral where this is a historical report and not an indication that both procedures were carried out at ‘as one’.

The suggestion to use pre-coordinated phrases is perfectly reasonably but we often do not have that choice - the Apperta example was from the Genomics England dataset - we had not control over how the data was being collected or reported but we wanted to use as many of the standard archetypes as we could e.g. procedure of ‘imaging result’ .

We need to express a body site with separate laterality, often in archetypes where ‘anatomical site’ is a perfectly good match (as long as bilateral is not required).

So we need something identical to anatomical location (in pattern) that is not restricted to describing something within a physical examination.

I think that implies either having a second ‘body site’ archetype for that purpose which includes things like bilteral , and loosening the slot e.g in procedures, imaging reports etc to allow the ‘body site’ archetype, or loosen the use of the original archetype.

7

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.

8

As this type of vague description is common in healthcare, we’re in no place to disallow their use. :sweat_smile:

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
9

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 :wink:

10

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 :anguished:

11

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.

12

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
13

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.

14

I’m sensing a semantic separation between:

  1. 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

  2. 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’?

2 Likes
15

@bna
Any views on this, from DIPS?

1 Like
16

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
17

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?
18

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.

1 Like
19

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 @heather.leslie 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. :slight_smile:

1 Like
20

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