2021-03-11 - SLPG Meeting
Goals
Consider postcoordination use cases
Attendees
Chair: @Former user (Deleted)
Project Group: @Daniel Karlsson, @Peter Jordan (Unlicensed), @Kai Kewley, @michael lawley, @Ed Cheetham, @Rob Hausam, @Anne Randorff Højen
Apologies
Agenda and Meeting Notes
Description | Owner | Notes |
|---|---|---|
Welcome and agenda | @Former user (Deleted) |
|
Postcoordination Use Case Examples | All | Example 1 - Dentistry / Odontogram
Example 2 - Terminology binding
Example 3 - Mapping
Example 4 - Natural Language Processing
|
Postcoordination Guidance | @Former user (Deleted) , @Anne Randorff Højen , @Kai Kewley | Practical Guide to Postcoordination
|
Comments
Thanks Linda.
Regarding the 'historical' point, maybe they've got this covered but I think my question refers to a challenge that is complementary to any work the MAG and others are doing on how to handle inactive concepts & descriptions. Whilst reference data modelling changes should generally be expected to result in improved data retrieval over time, some kinds of changes to formal definitions will result in discrepancies between compositional expressions created in the past and their future reference data counterparts.
Using an old example (but I think the principle still holds for future changes), consider the concept 73632009 |Laparoscopy (procedure)|.
Since 2007 it's been modeled in accordance with this guidance:
In 2006 it was modeled like this:
Anyone creating a 'laparoscopy' compositionally in 2006 might reasonably have assumed that an expression based on the 'method'/'access'/'site' role group shown (refining a 'procedure' focus) would meet their needs and would be detected with a corresponding query predicate. However, since 2007 the reference 'retrieval' definition (and thus query predicate) is significantly different. Leaving aside the procedure site attribute and value changes, the significant change is that |Access| = |Endoscopic approach| has been 'REPLACED_BY' |Using device| = |Laparoscope| - and this sort of historical tracking isn't explicitly supported for retrieval.
I don't have a strong sense of how common 'retrieval-disrupting' model changes are, but if we agree that they are a thing then we can also assume that they will happen in the future. If post-coordination is going to be encouraged then there need to be processes either to predict, identify and mitigate against such changes when they happen, or consider mechanisms to limit post-coordination to more 'stable' areas of the data.
Ed
Hi Ed! Really good point! And I think this will impact our guidance on which expression-form to use for each step in the journey... for further discussion in a few hours (after some sleep). Linda.
That you very much Ed and Michael for your comments on this previous meeting page. I'm replying on this week's meeting page to keep this conversation current.
Ed - I completely agree with the points that you've made. We should (and will) discuss the broader postcoordination 'journey' from creation to classification and querying, to exchange, storage and display etc. And in doing this, we should consider how these activities should work for each use case (and what guidance to provide). This will be the focus of this week's meeting - however, it is likely to take several meetings to get through everything, so I appreciate your patience. WIth respect to the queries over 'historical expressions' - this is obviously a very important topic - however, this should probably wait until the MAG has provided some recommendations for querying historical precoordinated content first.
Michael - In the scenario that you and Ed have referred to - in which the clinician records the disorder or procedure with a laterality (as per the UI) - I actually think it's more likely that the clinical system records the disorder/procedure and laterality in separate data elements within the health record (in line with the UI), and only composes these into an expression when they need to squeeze this data into a single field for exchange (e.g. as per FHIR spec). The big question that I think we then have is which form should the expression be put into for exchange - should it be the close-to-user form which is closest to how the data was collected (e.g. |appendectomy|: |laterality| = |left|), the classifiable form (e.g. |appendectomy|: {|Procedure site - Direct| = (Appendix structure|: |laterality| = |left|),|Method = |Excision||, or the NNF form (?). My first instinct would be to use the close-to-user form for exchange (which I consider to be the 'source of truth', with respect to what the user stated). However, I assume you're suggesting that the classifiable form should be used for exchange (i.e. it's created using a specific version of SNOMED, and used in the FHIR resource)? I think the related question is - which expression form is given a unique identifier in the expression repository? My thought is that each close-to-user form expression should be assigned a separate unique expression identifier.
We can start to discuss these topics further at this week's meeting.