SNOMED on FHIR

Page tree

SNOMED CT's release format, RF2, and its content can undoubtedly be improved to allow richer/better/easier use through terminology services.

This page (and subpages if they are warranted) is designed to capture these initiatives so they may be documented and communicated to the appropriate group in SNOMED International for action. These initiatives may become obvious through review and revision of the Using SNOMED CT with FHIR page or other work of the group.

Examples to start with are

  1. The Using SNOMED CT with FHIR page defines Implicit ValueSets however there is no way to GET an implicit ValueSet resource which would be a good way to expose metadata about a reference set (for example name, title, status, description, publisher, purpose, copyright, intensional definition...etc). This metadata for reference sets currently has no place in RF2, however is useful generally and usually gets documented outside the terminology and has been the topic of other discussion (and even others too). This suggestion is to work on defining a set of metadata attributes and their location in RF2 so they may be exposed by services like implicit ValueSets and online documentation generated from RF2 files rather than maintained separately.
  2. Reference sets that represent maps in SNOMED CT can be represented as Implicit ConceptMaps in FHIR. However one missing part of the metadata which accompanies SNOMED CT reference sets operating as maps is they fail to identify the code system the map is to - it is obvious to a human reading the name of the reference set, but for the purposes of writing software you "just have to know" the target code system and hard code that for the particular reference sets as assumptions. Clearly this would be better as machine processable metadata and would help with realising Implicit ConceptMaps in FHIR which are quite useful. This may be a specialised case of point 1 above, however this focusses on machine used metadata as opposed to metadata for human consumption.

Please indicate if there is interest in working on the above items, and/or other suggested items.

  • No labels

14 Comments

  1. Peter Jordan

    Some thoughts on point 1...

    a. Do FHIR Implicit Value Sets actually exist until created by an expansion operation?

    b. Making a GET request for all the Value Sets held by a particular server may return implicit value set definitions (mine does this) - but I'm not sure what information they would provide that isn't in the specification. Unless expanded with a filter, these value sets effectively represent the relevant edition and version of SNOMED CT in its entirety. In fact, you'll probably get more information from a GET request on the CodeSystem resource for SNOMED CT.

    c. Although the Implicit ValueSet syntax contains a filter that facilitates the expansion of SCT Reference Sets, for practical purposes these are functionally equivalent to Intensional Value Sets and can be implemented as such, along with the relevant metadata.

    1. Dion McMurtrie

      Thanks for the comments Peter Jordan.

      I realise there are some practical issues to consider - for example there are basically an infinite number of implicit value sets.

      For point 1, I'm really looking for some way to expose metadata about reference sets in SNOMED CT via their implicit ValueSet rendering. At the moment that metadata isn't present in the SNOMED CT RF2 content at all, and there is no standard place for it. In Australia the NCTS provides a page which lists our reference sets and provides metadata about them.

      I'm not actually a big fan of this page's rendering or the metadata fields it provides (some of them are OK, others are a bit dubious IMHO). But the concept of providing access to metadata like this for reference sets (and possibly other artefacts like maps) is good - an online searchable set of content.

      Unfortunately the metadata on this page is authored separately and maintained in a different system to the terminology server (Ontoserver) which is also a bit of a pain, for example it gets versioned outside the terminology so changes need to be coordinated. I'd like to pack it into the RF2 release and then expose it on web pages like this generated dynamically from that content.

      So it would be nice to have

      1. an extensible, standardised set of metadata attributes for a reference set in SNOMED CT
      2. a standard way to extend them if needed
      3. a standard way to represent them in a SNOMED CT release (RF2)

      Then point 1 takes this idea further to suggest that there may be a way to render out this metadata from a FHIR terminology server loaded with a SNOMED CT release that is aware of this metadata via ValueSet read operations.

      At the moment I'm not sure there is a way to read a SNOMED CT implicit ValueSet? You said your server does? Could you provide an example? That would be really useful.

      But if that could be worked out, it could provide a nice vehicle for that metadata to be rendered by a FHIR terminology server hosting SNOMED CT content.

      That way I could replace the system currently managing this metadata for the NCTS by getting this content from our FHIR terminology server (Ontoserver) that's aware of this content in a standard way.

      ...alternative to all of the above, we could decide that this idea doesn't really work and if you want to achieve what I'm talking about above the right way to do that is create an explicit ValueSet for each reference set with the metadata I'm talking about and a trivial intensional definition of the content of the reference set. However this wouldn't meet the objective of containing and therefore versioning the metadata within the SNOMED CT release, so there'd be the SNOMED CT release and the explicit ValueSet resources to manage and sync.

      What do you think is feasible?

    2. Michael Lawley

      Note that one issue about intensional ValueSets (in general) is that it may not be possible to express their "definition", so a GET may not be able to return anything much that is sensible.

      For example, http://snomed.info/sct?fhir_vs=refset 

      1. Rob Hausam

        Isn't that just a level of indirection - it's however the refset is defined, so the GET returns the refset and then you can figure it out?

      2. Dion McMurtrie

        That's right some formal definitions will be illusive, but it might still be possible to include some metadata, for example explaining what the thing is.

  2. Peter Jordan

    GET http://its.patientsfirst.org.nz/RestService.svc/Terminz/ValueSet  will return the definitions of all the ValueSets on my server, including the implicit ones for SNOMED CT and LOINC. It would also be possible to assign these value sets with names or other means of identification that would enable their definitions to be requested individually but (possibly until now!) I haven't seen a use case for doing so.

    I tend to favour the use of intensional value sets in FHIR rather than RF2 Reference Sets, I see the later as a maintenance nightmare in waiting. WRT to editions and versioning, there are probably better patterns for managing that at the application, rather than persistence, layer.

  3. Michael Lawley

    The only SNOMED one I see there Peter Jordan is http://itp.patientsfirst.org.nz/ValueSet/sct/refset/450970008 .

    How do you decide which ones appear there?

    1. Peter Jordan

      The only RF2 formatted Reference Set 'officially' exposed on my server is that one (GP/FP from the International Edition). There are a few others, taken from other domains, that are there purely to inform NZ design of corresponding artefacts and not officially discoverable in case of licensing violations.  We are in the very early stages here in NZ and activity will only ramp up next year when we start using our own national extension. My server remains purely an exemplar and I take what's given - no real decision-making involved! (smile)

      I also have Intensional Value Sets for each of the main SCT hierarchies - simple stuff. When time permits, I intend to implement more ECL-based filtering capabilities.

  4. Michael Lawley

    Regarding an authoring / distribution format that supports metadata etc, why invent something new?  Why not just use the FHIR ValueSet format?  If it needs to be an RF2 artefact, then the JSON serialisation of the ValueSet definition could be stored in a refset, and the expansion (only) could also be distributed using the current RF2 ReferenceSet form.

    See also discussion here: Intensional reference sets versus intensional ValueSets


    1. Dion McMurtrie

      Fair point, we could define a profile of ValueSet for this purpose, that would meet my needs I think.

      How would you attach it to the reference set? Dare I say it...but an annotation reference set referencing the reference set concepts with the JSON?

      1. Michael Lawley

        I would just expect the url element in the ValueSet to be the same as the implicit URL for the corresponding reference set.

        It may also be useful to name the files as [refsetId].json

        This provides a SNAPSHOT view, but doesn't help with is tracking changes across versions.

  5. Dion McMurtrie

    How do people feel about point 2 above?

    Should we be adding in a way in SNOMED CT to express the target code system for a reference set that is a map in metadata?

    Or is this just a more specific case of point 1 and could be solved by attaching a ConceptMap resource serialisation (which have a target specified) to reference sets that are maps as opposed to ValueSet resources? Bearing in mind the target specified in a ConceptMap is a ValueSet not a code system, not that it is a deal breaker.

  6. Brian Carlsen

    Dion, for my 2c, it's always bothered me that more metadata about maps isn't explicitly in SNOMED. And the "destination" terminology in particular isn't something that you can (reliably) programmatically extract.  I'll also point out that you need to know the version of the destination code system which I don't think is actually anywhere in the release.

    And as a secondary point, I hear what Michael is saying about avoiding creating new infrastructure to represent value set/concept map metadata, but the idea of putting JSON FHIR into an RF2 document raises some red flags for me.  For one, we'd need additional metadata indicating the version of FHIR used for that JSON.  Second, we'd be embedding structure in a relational table format which would cause usage divergence from all of the other RF2 files.  My preference on that front would be to just make metadata refsets that had columns matching the FHIR fields (e.g. target, targetVersion, targetUri, etc) and connect it to a referencedComponentId that is the refset concept id.

    1. Michael Lawley

      We're already planning to put structure in the OWL Axioms reference sets.

      I take your point about FHIR versions, but then we get another issue if we map the fields through to columns; if there are are new fields added then we'd need to add a new column to the reference set.  I suspect it would be better to use columnar approach with a field column and a value column