# Anatomical location **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2020-05-13 02:28 UTC **Views:** 2871 **Replies:** 56 **URL:** https://discourse.openehr.org/t/anatomical-location/677 --- ## Post #1 by @heather.leslie 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'](https://ckm.openehr.org/ckm/archetypes/1013.1.587/changerequests). 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](https://ckm.apperta.org/ckm/archetypes/1051.32.639) 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'.](https://ckm.openehr.org/ckm/archetypes/1013.1.587/discussion) 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](https://ckm.openehr.org/ckm/archetypes/1013.1.587/), 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. --- ## Post #2 by @varntzen 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. --- ## Post #3 by @ian.mcnicoll 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. --- ## Post #4 by @heather.leslie 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. --- ## Post #5 by @Leuschner 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](mailto:discourse@openehr.org)> escreveu: --- ## Post #6 by @ian.mcnicoll 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). [quote="heather.leslie, post:4, topic:677"] 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. [/quote] 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. --- ## Post #7 by @ian.mcnicoll 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. --- ## Post #8 by @siljelb [quote="Leuschner, post:5, topic:677"] 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? [/quote] 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. --- ## Post #9 by @heather.leslie 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: --- ## Post #10 by @heather.leslie [quote="ian.mcnicoll, post:6, topic:677"] So we need something identical to anatomical location (in pattern) that is not restricted to describing something within a physical examination. [/quote] 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: --- ## Post #11 by @heather.leslie 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. --- ## Post #12 by @heather.leslie 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. --- ## Post #13 by @ian.mcnicoll 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. --- ## Post #14 by @heather.leslie 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 1. **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'? --- ## Post #15 by @varntzen @bna Any views on this, from DIPS? --- ## Post #16 by @ian.mcnicoll 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? --- ## Post #17 by @heather.leslie [quote="ian.mcnicoll, post:16, topic:677"] I’m still really unclear about what the practical downsides are to widening the scope of anatomical location. [/quote] 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? --- ## Post #18 by @siljelb 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. --- ## Post #19 by @Leuschner 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: --- ## Post #20 by @ian.mcnicoll 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!! --- ## Post #21 by @bna 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.... --- ## Post #22 by @ian.mcnicoll 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. --- ## Post #23 by @bna 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. --- ## Post #24 by @linforest 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". --- ## Post #25 by @ian.mcnicoll 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' --- ## Post #26 by @heather.leslie [quote="ian.mcnicoll, post:22, topic:677"] 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’ . [/quote] 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. --- ## Post #27 by @ian.mcnicoll Some examples of use of bilteral This is the Genomics England Cancer schema that asked for 'bilateral' as part of an 'imaging event' whfor which we wanted to use the 'Imaging report' archetype. |Anatomical Site|*IMAGING CODE (NICIP) and/or *IMAGING CODE (SNOMED CT) and/or *CANCER IMAGING MODALITY and IMAGING ANATOMICAL SITE and ANATOMICAL SIDE (IMAGING) is required. A classification of the part of the body that is the subject of an Imaging Or Radiodiagnostic Event. |0..1 |No|imagingAnatomicalSite |IMAGING ANATOMICAL SITE| |---|---|---|---|---|---| |Anatomical Side|The side of the body that is the subject of an Imaging or Radiodiagnostic Event. |0..1 |No|anatomicalSide(imaging) Enumerations L:Left R:Right M:Midline B:Bilateral 8:Not applicable 9:Not Known |ANATOMICAL SIDE (IMAGING)| SNOMED terms where bilateral is used... https://browser.ihtsdotools.org/?perspective=full&conceptId1=371825009&edition=MAIN/2020-03-09&release=&languages=en Now if you have SNOMED license you may be ok but even then there is no guarantee that the particular core anatomical site has a pre-coordinated term which includes 'bilateral' . These would be used in contexts of Diagnoses 425414000 | Bilateral renal artery stenosis (disorder) | Procedures 287662009 | Bilateral vasectomy (procedure) | Sign/symptoms 12241791000119109 | Bilateral red eyes (disorder) | Imaging 43204002 | Bilateral mammography (procedure) | Now I wouldn't necessarily defend the use of bilteral in all these situations, but for good or bad, we are often not in a position to force change, technically or clinically. So my question back is what would be the practical down side of simply adding 'bilateral' to the current valueset, given that it can be excluded again at template-level if local circumstances can enforce more semantically precise recording e.g for something like 'bilateral hip replacement'. I'm still not clear what practical issue we are trying to solve/avoid by adhering to the current scope of the archetype. --- ## Post #28 by @heather.leslie [quote="ian.mcnicoll, post:27, topic:677"] M:Midline B:Bilateral [/quote] Thanks. Can you provide examples of expected data here for an imaging request or a report? * Bilateral what? * Midline what? --- ## Post #29 by @heather.leslie [quote="ian.mcnicoll, post:27, topic:677"] SNOMED terms where bilateral is used [/quote] This link gives me a finding that the patient is on oxygen... --- ## Post #30 by @heather.leslie [quote="ian.mcnicoll, post:27, topic:677"] Now I wouldn’t necessarily defend the use of bilteral in all these situations, but for good or bad, we are often not in a position to force change, technically or clinically. [/quote] Totally agree. I wonder if specialising the current for this purpose might be a solution? Where bilateral is part of existing data but really is not good modelling, and certainly not how we'd choose to promote as valid for future modelling. This is a real tension - reality vs good data design - and how we choose to represent it. --- ## Post #31 by @heather.leslie [quote="ian.mcnicoll, post:27, topic:677"] I’m still not clear what practical issue we are trying to solve/avoid by adhering to the current scope of the archetype. [/quote] The revision that we reverted tried to do that but we had to change all of the semantics, so much so that the archetype lost it's integrity - definitions made no sense. Literally part of the archetype is designed for a single location and some parts for more than one. I couldn't get it to make enough sense so that I could explain it credibly to others. You are welcome to try again. Maybe you'll be more successful. Or think about specialising and adding your 'bilateral' to the existing model to support your use cases. I think that in most cases, this modelling is the result of poor data design in existing systems. I'm still not seeing many examples where bilateral is best practice representation of the data. And I'm increasingly inclined to agree with Sam's early suggestions that precoordinating left and right to appropriate anatomical location is probably good modelling, similarly for bilateral. So maybe the solution is not just for the information model, but an example of the grey zone, where we need to find the semantic sweetspot, using terminology as well. We have not done so before but we could consider requesting SNOMED codes here. Midline is actually modelled in the 'Anatomical line' attribute. --- ## Post #32 by @ian.mcnicoll Oops sorry for the duff link - the SCT browser was not doing what I expected. If you search for bilateral, you get a long list of codes e.g. .... ![2020-06-03_09-52-19|484x500](upload://jY3VnVjInMS4LxXS9WvRV9DliK5.png) ![2020-06-03_09-52-19 (1)|382x500](upload://zJ5SZhfhjIHK7GorQ0ENZnDbroy.png) --- ## Post #33 by @siljelb I think the main question to ask is what is the purpose of these concepts? I believe we need to conceptually differentiate between 1. uniquely identifiable anatomical locations 2. body site designations where it's a. unimportant to uniquely identify specific locations, or b. the designations will be further specified at a later point, for example when a planned procedure is changed into a set of specific orders I think these SNOMED CT concepts are only useful for item 2. --- ## Post #34 by @ian.mcnicoll I agree in principle but I'm still not sure how you really know in practice whether to use (1) or (2), or the actual benefit (or dis-benefit of using different archetypes). What is it that worries you about using the same archetype? I am building a GP system. I need ot be able to record diagnoses where sometimes the body site is uniquely specific 'Left' and other times it may be 'Bilateral' - which should I use (1) or (2)? What do I tell the developers? I actually do not know exactly if anyone will use 'bilateral' but we know people do. Similalrly with a bofdy site for an imaging test - this might be quite specific and a good candidatefor (1) but in other circumstances, folks might ask for 'bilateral mamography' . I cannot predict ahead of time whether to use (1) or (2). So in practice, I am always going to use (2), since it is a superset of (1). If there are situations where bilateral is clearly not applicable, well for that template, we just constrain it out. Same goes for anatomical path reports, or surgical procedures 'Bilateral vasectomy' Now the one place where I can see that (2) might always be inapplicable is when describing an examination but I'm struggling to understand what goes wrong if I use (2) with 'bilteral' constrained out. Heather's suggestion of specialisation does help but I'd still be using (2) in the vast majority of cases, simply because in practice you often cannot be sure that (1) only applies. --- ## Post #35 by @heather.leslie [quote="ian.mcnicoll, post:34, topic:677"] I need to be able to record diagnoses where sometimes the body site is uniquely specific ‘Left’ and other times it may be ‘Bilateral’ [/quote] Looking at the SNOMED example you provided - structures usually are recorded as both in the preferred/FSN, although bilateral is often available as a synonym. I certainly don't usually talk or record body sites as bilateral ears or bilateral hips, rather both ears or hips. 'Both palatine tonsils' is not an option, only 'bilateral palatine tonsils' but I'd suggest that's a SNOMED issue and an outlier - at least it is plural! 'Bilateral middle ear', singular, makes less sense. ![body structure|690x436](upload://v04fdeHx4x7zxIEQAPPghurEf76.jpeg) ![both|690x436](upload://6xYasgIIyNLhxLYZQD7qRDPSQiG.jpeg) ![finding|690x436](upload://tUDjT9slZTlNYNJyzgKNtZEtCKM.jpeg) ![procedure|690x436](upload://btjzyLJx5yJ6MR77QF5KWYnWM78.jpeg) Recording 'Bilateral pneumonia' is different to recording 'Pneumonia' in the left and right lungs. Currently the Problem/Diagnosis archetype allows recording of: 1. Diagnosis name = "Pneumonia" | Body site (0..*) = left lung ( SCTID: 44029006) +/- right lung ( SCTID: 3341006) 2. Diagnosis name = "Pneumonia" | Body site (0..*) = both lungs ( SCTID: 74101002) 3. Diagnosis name = "Pneumonia" | Structured body site SLOT/CLUSTER.anatomical_location (0..*) - Body site name = Lung | Laterality = left or right 4. Diagnosis name = "Pneumonia" | Structured body site SLOT/CLUSTER.anatomical_location (0..*) - Body site name = Lung | Specific site = Base of right lung ( SCTID: 51785002) Laterality = left ( SCTID: 7771000) or right ( SCTID: 24028007) 5. Diagnosis name = "Pneumonia" | Structured body site SLOT/CLUSTER.anatomical_location (0..*) - Body site name = Lung | Specific site = Base of lung ( SCTID: 10024003) Laterality = left or right So we can record Pneumonia found in the left lung, right lung (#1) or both lungs (per #2), but we don't record pneumonia in 'bilateral lungs' at least not in common parlance. But adding 'bilateral' or 'both' to the 'Laterality' data element in anatomical location is not actually helping you record 'Bilateral pneumonia' as an entity. **I propose we should a qualifier of 'Side' for the Problem/Diagnosis name in the Problem/diagnosis archetype with the values Left/Right/Bilateral**, if it is not available as a pre-coordinated diagnosis term (see green box in mind map, below). And CLUSTER.anatomical_location remains unchanged as a the way to record details about a single body site. I think it is the same in principal for Procedure (see mind map) - **I propose we should a qualifier of 'Side' for the Procedure name in the Procedure archetype with the values Left/Right/Bilateral**, if it is not available as a pre-coordinated procedure term Re Service request - at present we don't really have any way of addressing a side eg to order bilateral mammography if this is not already available as a pre-coordinated term. We do have SCTID: 43204002 for Bilateral mammography, so not a good example, but we need a way to represent those that aren't pre-coordinated. We could do the same thing, but it makes little sense to see Side and Body site in a Service request in the broadest sense, but perhaps makes more sense if we specialise it for Procedures/Investigations etc and add Side and Body site to align with my proposal for ACTION.procedure. CLUSTER.specimen correctly carries one anatomical site per specimen, so needs no further modification. Lab findings (eg in CLUSTER Anatomical pathology) will be related to the specimen, so not likely requiring left/right/bilateral/both. Imaging findings may need left/right/bilateral. Although I suspect each finding should be recorded and described individually eg multiple lesions of different shape/size/location. Lab and Imaging diagnosis will be similar to Diagnosis. However there may be multiple findings, so the we may need to look at creating an internal cluster 'diagnosis group' to handle the Left/right/bilateral qualifer per lab/imaging diagnosis (see orange box in mind map) [2020 06 04 Bilateral_Anatomical location.xmind|attachment](upload://2bIF0xH0kTwSTtMWhh46GmZHq2m.xmind) (212.3 KB) ![Bilateral_Anatomical location|397x500](upload://7r38YQNQ1xoChnqok4OVelOIQ25.png) Thoughts? --- ## Post #36 by @siljelb If I understand you correctly, the essence of this is "it's the diagnosis/procedure/request that's bilateral, not the location". This makes sense to me, and I support recording this on the level of the entry concept. I think this is a good reason to specialise the Service request archetype for procedure requests as well. --- ## Post #37 by @ian.mcnicoll That's going to break one of the use-cases for the reusable Cluster - @bna - the DIPS requirement to be able to query for 'left eye' things, irrespective of the parent Entry. Still think we are creating a very complex problem space where if we changed the anatomical archetype scope. I still have not heard the argument that we need the current scope to be so tight, other than as a theoretical construct. What goes wrong if we loosen the scope to 'stuff I might want to say that includes references to anatomical things' which is basically the SNOMED scope'. Genuinily do not understand the practical argument here, sorry :( --- ## Post #38 by @siljelb [quote="ian.mcnicoll, post:37, topic:677"] That’s going to break one of the use-cases for the reusable Cluster - @bna - the DIPS requirement to be able to query for ‘left eye’ things, irrespective of the parent Entry. [/quote] If you're thinking of the Examination clusters based on https://ckm.openehr.org/ckm/archetypes/1013.1.218, I don't think that's quite correct. Those archetypes mainly differentiate using the "System or structure examined" element, where for example "Both eyes" is perfectly relevant to use. See for example the difference between Examination of both eyes (https://ckm.openehr.org/ckm/archetypes/1013.1.3777) and Examination of an eye (https://ckm.openehr.org/ckm/archetypes/1013.1.3786). For these archetypes, the "Body site" and "Structured body site" elements are mostly relevant only when examining larger organs such as the skin (https://ckm.openehr.org/ckm/archetypes/1013.1.3933). --- ## Post #39 by @heather.leslie Hi Ian, I think we both agree that the values of 'left'/'right'/'bilateral' are qualifiers, and this is aligned with SNOMED's view of the world. My proposal is based on the understanding that left/right within the context of CLUSTER.anatomical_location are only intended to be qualifiers of the Anatomical location that has been identified using the mandatory 'Body site name' (at0001). They aren't intended to be qualifiers for the terms used to describe diagnoses, procedures, imaging requests etc. If you want to record the side of the Diagnosis the qualifiers it makes sense for it to be recorded within the semantic context of Problem/Diagnosis archetype, and that is why I've suggested adding the qualifiers in that archetype. Same for Procedure, Imaging request etc. If you want to record where the diagnosis was found, eg multiple sites of psoriasis on the body, then this is the purpose of the Anatomical location archetype - one instance for each site. It seems you are operating from a different assumption that 'side' can only be recorded in one archetype, but I am increasingly of the view that it is simply a qualifier that is used and defined wherever it is contextually relevant, including the use of value sets including addition of 'bilateral' or 'left and right' where it makes absolute clinical sense. More akin to our reuse of 'Description' and'Comment' in many archetypes. regards Heather --- ## Post #40 by @siljelb When you say "bilateral [something]", you're not really supplementing the statement of the [something] with a location. The location/organ is implied in the name of the thing, for example "cataract" or "mastectomy". The "bilateral" is a qualifier saying "it's both of bilateral symmetrical organs specified in the name". Or are there examples where "bilateral" is used without specifying a specific organ? --- ## Post #41 by @ian.mcnicoll There will definitely be cases where bilateral is used as a qualifier, without a specific organ location e.g 'bilateral mastectomy'. And I do appreciate that conceptually this is different from an actual physical location. My worry is that it is going to be a very fine distinction for most people I guess the use-case which is making me try to stick with the single way of 'doing anatomy' is @bna DIPS Opthalmology example where they wanted to identify 'all things about the left eye', using SNOMEDCT irrespective of the containing Entry i.e to include orders procedures, diagnoses etc. Current AQL implementations let us do that on CLUSTERS, but not on ELEMENTS. In that case I would ensure that a statement like 'bilateral cataract' did have the organ location 'Eyes' held in anatomical location as well as 'bilateral'. or the unilateral equivalent. this is horrible!! --- ## Post #42 by @heather.leslie [quote="ian.mcnicoll, post:41, topic:677"] I guess the use-case which is making me try to stick with the single way of ‘doing anatomy’ is @bna DIPS Opthalmology example where they wanted to identify ‘all things about the left eye’, using SNOMEDCT irrespective of the containing Entry i.e to include orders procedures, diagnoses etc. Current AQL implementations let us do that on CLUSTERS, but not on ELEMENTS. [/quote] This is definitely an ambitious use case. But it seems more sustainable to refine AQL or the algorithm/logic rather than munge the archetypes. For the use case I'd suggest again that you specialise for your purpose. In the meantime we have identified a need to extend the archetypes with 'Side', including 'bilateral' as a value and unless there are objections will make CRs with the intent to update them accordingly. --- ## Post #43 by @ian.mcnicoll I'm happy with that approach. It is a messy area and we may just have to live with a bit of variation to suit differing circumstances. In some ways, Silje's earlier suggestion about using SNOMEDCT and pre-corrdinated terms or even post-coordination limited to 'laterality + xyz' would be the best solution, but that would mean SNOMED relaxing their license. Perhaps it is worth discussion (with SNOMED ? FHIR) --- ## Post #44 by @heather.leslie Seems like we have a plan for the archetypes, at least. Thanks for the robust discussion everyone :star_struck: --- ## Post #45 by @ian.mcnicoll Nothing better than a decent brawl, underpinned by [Marquis of Queensbury Rules](https://en.wikipedia.org/wiki/Marquess_of_Queensberry_Rules) for Gentlefolk :slight_smile: --- ## Post #46 by @siljelb I strongly object to rule #2. 😂 --- ## Post #47 by @ian.mcnicoll Yes - I see your point - perhaps I used the wrong sport. Rule 2 is what we do. Ok - do we need a new archetype based on Rule #2, or can we blend it alongside the other rules (and constrain out) or are we back to specialisation as a compromise? :space_invader: :space_invader: --- ## Post #48 by @heather.leslie A wrestling archetype? Or am I totally lost? :woozy_face: --- ## Post #49 by @ian.mcnicoll My entirely arbitrary use of the space invaders emoji may have over-loaded an already convoluted and over-stretched 'meta-joke'. So apologies, my bad, but yes you are lost ;) Quite probably along with everyone else - it made sense to me at the time :joy: --- ## Post #50 by @heather.leslie It's a familiar feeling... :confounded: --- ## Post #51 by @Colin_Sutton Shouldn't bilateral just be a user interface artefact to select both left and right to be recorded? --- ## Post #53 by @siljelb In some use cases this could well be a good solution! :grinning: --- ## Post #54 by @Leuschner Hi, Good point, Colin. You can get around the problem that way, but I am afraid that doesn't solve the connundrum about expressing localization in human sorts, while being precise as we must be. Please don't take my thoughts as more than a go in keeping the discussion alive. I am not sure at all about the right way to express this. For laterality, you can assume it after picking left and right sides. That still means one more click, or engineering an UI-wise way of recording both in a go. For most cases, this is a useful way of summarizing a bilateral problem, albeit it doesn't seem to accommodate for assimetry. 'Bilateral' may be seen as a short expression of a kind of laterality. Maybe it should be viewed (and represented in the IM) as a coarser, though informative, way of localizing something. Other examples would be 'diffuse muscle pain', 'centrifugal progression of an exanthema', etc. IMHO, UI artifacts can help to keep accordance to a consistent information model, but the IM must express those human-readable forms in a logical way. Best regards, A segunda, 10/08/2020, 09:03, Silje Ljosland Bakke via openEHR <[discourse@openehr.org](mailto:discourse@openehr.org)> escreveu: --- ## Post #55 by @bna Coming late to the party (sorry). I think that bilateral eye is not a anatomical location. It's actually two anatomical locations. The human body has in fact two eyes if you didn't loose one. When it comes to defining anatomical location within the body we should be specific enough. I approve the suggestion from Colin about leaving bilateral to the user-interface. It's a situation when you create data which are equal for two different parts of the body. --- ## Post #56 by @bna Sorry for opening this thread again. Just want to share some thoughts on the bilateral issue. First a metaphor. “**Life is like a box of chocolates, you never know what you're going to get.** ” –Forrest Gump. Bilateral is not like Forrest Gump describes it. Bilateral is a box where you know what you get. You get two similar *chocolates* - or a more clinical example is two identical attributes of both eyes, knees or any other pair-organ. For INSTRUCTION and ACTION you get a *box* with two identical requests or procedures performed. Depending on the level-of-details the two *items in the box* might be identical or have minor difference. I.e. you might have a *box* defining *decreased bilateral knee flexion* . Looking in the details the right knee might be worse then the left. Bilateral is therefore a complex and hard semantic term. The interpretation of it will depend. Anatomical location should be used to define a "locatable point" in the human body. Bilateral can not be used for this. This will be more related to some "organ classifier". Like the eye, knee or hip. In this context we are not talking about a "point of interest" - but more about a function of the body. --- ## Post #57 by @AAM Have you thought about co-opting the Foundational Model of Anatomy. In it Ears has a different number to Left Ear and Right Ear. It is already a fully specified ontology. A --- ## Post #58 by @mar.perezcolman Hello everyone. Apologies for re-opening this discussion. I replied to an old Change request and Silje directed me to this thread, which I have read and I hope to have understood. I am very new to the openEHR world, so there are some things I don't fully understand, and my biggest doubt in this is what is the harm of having 'bilateral' as an option. Whenever I have come across laterality, the options tend to be left, right, bilateral, midline, unknow. I understand that it could be a UI implementation and store in the background left+right, however, to be honest, we are pointing to an external reference data set with those values. I believe there are use-cases in which describing something as 'bilateral' (or 'left and right' as SNOMED describes it) is relevant. For example: - bilateral symptoms and signs may point to one disease and discard others which are typically unilateral (ie Guillain Barré typically has bilateral and symmetrical muscle weakness or CHF has bilateral oedema in the legs and crackles in chest examination). - bilateral presentation may also trigger different treatments (ie a bilateral inguinal hernia may prompt a laparoscopic repair rather than conventional hernia repair or unilateral pain in a leg may be a DVT but it would be rare for it to be bilateral and a Doppler US may be requested in one and not the other). - metastasis can be bilateral as a simple description with no further requirements to clarify on them (ie bilateral lung metastasis on a rectal cancer, or bilateral node involvement). - COVID 19 was typically described as bilateral and the difference was established depending on how much of the lungs were affected. - CLIS as a risk factor for breast cancer can be bilateral. I understand the theory of 'things' being only in one place at a time, but given that we tend to group in the descriptions, wouldn't that justify having bilateral as an option and disabling it depending on the use-case? Thanks! --- **Canonical:** https://discourse.openehr.org/t/anatomical-location/677 **Original content:** https://discourse.openehr.org/t/anatomical-location/677