- Created by Peter G. Williams, last modified on 2022-Jan-17
See also SNOMED CT, post coordination and ValueSet $expand
General
In general a PCE can be used wherever a SNOMED code is indicated, both within resources and in, say, GET url parameters.
Close to User Form would be presented with the same syntax, so any indication that it is in fact, of that nature would need to be communicated 'out of band'. PCE documentation allows for CTUF and suggests transformations that could be applied.
PCEs that are stored can become equivalent to pre-coordinated concepts as they become
CodeSystem
| Operation | Statements and Issues | Considerations and decisions |
|---|---|---|
| $lookup | If we can pass in a PCE then what does that mean? The point of lookup is to get further information about a code - what further information could be gained . Could we get a full decomposition. We'd need to classify to then work out the parents and children, relationships that are inferred as part of that classification (may not be obvious from parentage due to presence of GCIs, etc) | We could say we expect validate-code to be called (or a subset of that functionality) as a matter of course to ensure the PCE is well formed and all component elements exist in the default / specified substrate. Would we want to see logically generated display text (suggests we'd have to match a template to an expression, with a priority order). The spec indicates that previously received text could be used. |
| $validate-code | "Validates that a coded value is in the code system" and we say that PCE already exist in the CodeSystem - if all their component elements are valid and present. Is close to user form acceptable? Eg A disorder with both a body structure and a laterality attribute is considered "user form" and is a) contrary to the MRCM and b) not normalized ie we'd expect to see a body structure that is already lateralized. A transformation can be performed to normalize the expression to make it correct. What to do with inactive concepts used within an expression. Validate code only checks that the code is in the system. It does not consider inactive concepts to be invalid which suggests that a PCE that uses an inactive code should also be valid. It would not classify in a meaningful way. A structured response could be used to indicate to the calling code that a replacement (eg through historic association) should be sought. Is there a way to indicate what we're doing with the concept in order to decide if MRCM validation should be performed or not. We should assume that the context is one of 'end user' rather than authoring content. | Same issues as above in generating display text. Additional out parameters can be used to give more detailed information about each component element. |
| $subsumes | Yes, expected to work. | Yes, we'd expect classification to be performed (potentially on 2 PCEs) and the result given as normal. |
ValueSet
| Operation | Statements and Issues | Considerations and decisions |
|---|---|---|
| $validate-code | Classification would need be performed and the resulting concept checked against the definition of the ValueSet 'contains' element to determine membership. Filters may need to be applied. Note that validate-code would return true for a PCE that would NOT (by default) be included in the expansion of the same ValueSet since we don't return all PCEs by default. Note that flag says if its valid to return these or not. It is not requesting that they all be returned. | |
| $expand | Valuesets tthat contain other ValueSets PLUS filtering conditions PCEs in a CodeSystemSupplement that the ValueSet references. | |
| $expand - PCEs in the definition of the ValueSet (compose include/exclude) | If Pre and Post coordinated equivalent concepts can be evaluated (or even two Post Coordinated but syntactically different) would we expect both to be returned? | |
ConceptMap
| Operation | Statements and Issues | Considerations and decisions |
|---|---|---|
| $translate | Should a PCE that is equivalent to an existing map source ALSO map to the same target? | We could translate a PCE containing inactive concepts with the Historical Association Refset in order to obtain an 'updated' version(s) |
Notes from SNOMED on FHIR Working Group
Post coordination - primitive <<< syntax, what does this mean in practice, in context of use.
The problem is that, without FSNs, any two concepts with lexically identical structures must be assumed to be siblings because we can't detect equivalence. Eg two concepts both defined as <<< 64572001 |Disease (disorder)|
How do these behave with $subsumes (answer: you say they're not related) and $closure (trickier, you want to indicate that they're distinct but there are no identifiers to make this apparent).
Is this a case of - in practice - the client needing to check if an expression already exists and then making a decision if they can reuse that one, or need to create a new one. But given that we can't tell them apart without another identifier, how would that be useful. Upshot of this is that primitive PCEs are not terrible useful to use in an EHR. Use SD instead === the symbols here are optional and taken as the default when not present.
Could we make use of the display field in this situation? The end user will have some idea in mind when they create the expression. PCEs are often advertised as a way to allow existing/new medical concepts to be entered into systems at runtime.
TODO Discuss how should PCE Libraries be represented in FHIR? For example, do we include them in a ValueSet expansion? Surely yes, but possibly not by default. CodeSystem supplement? 8 Sept ML favours this approach (one CodeSystemSupplement per library). Although CodeSystem Supplements should not add new content, PCEs already exist in the CodeSystem. Why not Fragments? - might isolate content.
8 Sept: Discussion on what identifiers might be used. It really has to be the full expression as the identifier otherwise we cannot detect equivalence between any two PCE libraries eg in different countries (and even then when the <<< primitive indicator is used). See also GitHub Issue.
Is it valid for a server to normalize the order of terms? Will we do close-to-user-form transformations eg to show the semantic equivalence between Left leg vs Leg + Left role grouped. Note that the order of operations described in the spec influences the result, which is a concern. Suggestion that you could detect close-to-user-form by doing the transformation and seeing if anything changes! However a syntactic marker might be helpful here. Best practice: "PCEs should always be authored from templates."
22 Sept: FHIR says that Post Coordination "Is supported" so that leaves something of a gap given that our implementations are not quite there yet. Page: SNOMED CT Post Coordination in FHIR
10 Oct: ML posted questions/responses on PCE as part of the Expo platform. RH suggests posting to the SNOMED Zulip stream to continue the discussion. Request for access to expression library capabilities. To be discussed on next languages call.
13 July 2021:
$validate-code: ML Transformations of Close to User Form happen under the hood of the TS. You might want to see normalized form, although it will be dependent on the particular edition in use. Current Snowstorm development is WIP / experimental rather than a ratified spec. Order of transformation is important + existing issues with negation in hierarchy subsuming in unwanted ways. PJ Essential to have first pass attempt to bottom out issues, highly beneficial.
$subsumes
What about ValueSet $expand - return Normalized form or original input? Classification will be needed before membership of ValueSets can be determined.
$find-matches could be used to find / check PCEs / Normalized equivalencies. Alternatively, deprecate this operation altogether!
$translate could return normalized forms of CTUF. ML Syntactic differentiator needed?
Sander Mertens has completed a multilingual tool for creating concepts based on template: https://postco.test-nictiz.nl/#/ (source: https://github.com/mertenssander/postco)
- No labels