SNOMED on FHIR

Page tree

TODO:  Pull this into textual discussion.



HL7 Vocab Item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15806

ML: Supplement would hopefully only add additional descriptions that are not described in the base content.

Precedence (fallback) for multiple language reference sets only really discussed in Languages Group for ECL - other use cases not yet brought to light.

Update 28 Aug: Keen to see an implementation using Supplements to see how it would actually work. Option to explore this at Baltimore Connectathon?

Update 11 September: Do we need a parameter for the expand operation for this - Reuben looking into this currently.

Update 11 Dec: HTTP Headers RFC 5646 (Tags for identifying languages). Suggestion that where dialects are to be referenced which do no have a standard code, one could be constructed, either using new letters or the language reference set id directly eg en-nz-x-12345601 Note also that requested language/dialect could be an ordered list for gradual fallback where descriptions may or may not be available.

Can also be passed in the language parameter passed to an expansion operation.

Language reference set could be an implicit code system supplement.

Update 8 Jan: Note that SNOMED CT Language Reference sets do not indicate if they relate to a dialect, language or context of use. GG suggested FHIR could address that more directly than using a reference set SCTID to supply that desired context. Include someone in a non-English speaking country!

Update 5 March: Reuben suggesting plan of action to ensure we have a solid proposal to take to the Montreal Connectathon (4-5 May 2019). Languages working group code for "consumer friendly terms" - Rob says that a harmonization proposal is in the pipeline




  • No labels

12 Comments

  1. Peter G. Williams

    In http://build.fhir.org/valueset-operation-expand.html could the "designation" parameter be used to specify a "use"  by specifying a language refset - be that a dialect or patient friendly terms?

    1. Michael Lawley

      I think you're on to something here.  I've done a lot of thinking about different mechanisms to wedge SNOMED's cross-language language-refset mechanism in to the existing FHIR machinery and this seems by far the simplest and most accessible approach.

      To do this we would need to document that the system http://snomed.info/sct with a code that is the SCTID of a language reference set is the mechanism select the appropriate display text.

      We would probably also want to say something about whether all language reference set entries are also returned via the designations element in the expansion.contains element, and similarly for the $lookup operation.


  2. Daniel Karlsson

    "A token that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return"

    I assume that we as a group can state that language refset codes is one way of using the designation element when SNOMED CT is used.

  3. Zac Whitewood-Moores

    A discussion paper I put together for the UK.  In no means policy but some of the challenges and benefits of using SNOMED CT, but also of ensuring modelling supports pre or post-coordination.  This may be significantly different but could enable rendering in the patient's language within an application, especially for multi-language nations like Canada.

  4. Peter Jordan

    This is the approach that I've taken, in the R4 version of Terminz, to  facilitate requests for patient-friendly terms from the NZ Edition of SNOMED CT and LOINC. 

    The Token type search parameter needs to be used in the context of the parent search type designation parameter, which is string - see the complete section of the FHIR spec quoted above by Daniel - 3.1.1.4.10 (hl7.org/fhir/search.html#token).

    My interpretation of this is that this is a string to be used for exact matching which, for SNOMED CT, might mean the relevant Language Reference Set ID; I would then place this within the context of the Code System value contained in the relevant element of the Value Set. However, I'm happy to hear alternative interpretations.

    Also of significance is that the cardinality of the designation parameter is 0..*, which obviously allows the use of multiple language reference sets. It would be useful to create a working example with a country that has multiple languages and dialects.  It also means that patient/consumer friendly terms can be requested with regard to Value Sets that encompass more than one Code System.

    1. Michael Lawley

      Note also that if multiple designation parameters are supplied, you can't read anything in to their order (because HTTP libraries); they're all equally important/significant.

  5. Peter G. Williams

    See ongoing trackers:  22490 and 19960 - additional term for "Consumer Terms" ready for implementation R5 (Q4 2020 at the earliest).

    1. Zac Whitewood-Moores

      Consumer friendly terms should not put at risk disambiguation, to have a complex unambiguous term is better than a dumbed down term which makes it more challenging to search.  It would be better that a wider range of definitions or url link partnership with an appropriate medical dictionary.  Plain English and consistent editorial guidelines help, however this is a clinical terminology to  ensure patient safety, not a patient vocabulary which may put them at risk. 

  6. Peter Jordan

    An amusing example of the interplay between clinical terminology and plain English - not to mention 'old school' patient care!

    1. Michael Lawley

      clearly 72406003 is the bloody code

  7. Zac Whitewood-Moores

    Of course English (plain or otherwise) is not much use if you are from the non-English speaking world! Even within one nation many dialects exist and what makes sense in one place, may be entirely incomprehensible a few miles up the road.  https://www.mirror.co.uk/news/uk-news/barnsley-not-at-home-tha-must-246726 Thus patient friendly terms may be chasing unicorns I suspect.

  8. Elaine Wooler

    This topic has seemed to crop up every few years and was recently discussed at Member Forum and I know some countries are going ahead with adding this type of term.  The wider discussion at Member Forum looked at some of the barriers and summarised perfectly by Jeremy Rogers:

    1. Unexpected difficulty achieving true clarity and scope of the requirement
    2. The discovery by those who have actually tried that it turns out to be surprisingly hard to do; oversimplification of the clinical meaning is a real risk and so, medicolegally, you probably have to also always ship the clinical jargon term anyway.
    3. Research results (1,2) suggesting that patients actually value accessible long explanations of clinical jargon over ‘word substitution’ approaches. They mostly don’t want to be spoken down to, and prefer being skilled up. They also find it MUCH easier to search online for detailed relevant information about their condition if they have the jargon term to throw at Google – which is also now the de facto standard approach by which patients decode clinical jargon into accessible explanations.

     

    [1] Towards Consumer-Friendly PHRs: Patients’ Experience with Reviewing Their Health Records

    [2] A classification of errors in lay comprehension of medical documents


    Ed Cheetham also pointed me to some UK experience from the Clinical Terms project some 15 years earlier:

    The UK carried out a scoping study on consumer terminology during the development of Clinical Terms Version 3 (CTV3) in the UK in the 1990s. Requirements identified at that time included people being able to understand what is written in records and having help to explain their diagnosis, treatment and prognosis accurately to relatives. Key findings of the study were:

     

    1. The majority of ‘terms’ required by clients are translations or descriptions of the professional terms, not colloquial synonyms

    2. Identifying universally acceptable patient-friendly synonyms would be problematic, for example, patient-friendly synonyms could be found for about 25% of the sample of terms examined by a consumer terminology working group but there was no agreement that they were essential...