You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 2
Next »
Objectives
- FHIR Terminology Services and Resources
Discussion items
Item | Description | Mins | Owner | Notes & Actions |
---|
1 | Welcome and introductions | 5 | | Recording, notes & attendance. Note: No meeting on Tuesday 24 July. Was due to be TS, postponed to 31 July ie skipping a week, but keeping turn-about fair |
2 | October Expo - Vancouver | 5 | | Call for abstract |
3 | Summary of previous week | 5 | | |
4 | Zulip discussion on Post Coordinated expressions | 10 | | Summary: Expressions filter on CodeSystem Resource - Dion asked Graham about origin of these two items. GG clarified true = permit PCE eg for use in validate-code and similarly for expand. Default = true also. Suggested that expand call should then return every possible post coordinated expression (!!) which is a) hard and b) probably not useful. Such expressions could be available if an expression library had been implemented. However, validate code should handle arbitrary PCEs since this will be a finite set. Note that people do post coordination for other code systems eg UCUM and MIME. Suggestions: - Possible useful use case in calculating lateralized expressions
- Principle could be applied that in general SNOMED Pre and Post coordinated expressions should be interchangeable.
- Incomplete response should be labelled as such.
- That we should return "published" content, which might include post coordinated content in some cases. ML suggested "at least" this content.
- We could make a statement in the "Using SNOMED with FHIR" page. Clarify with the HL7 Vocabulary group.
Questions - cIn the "membership" query, does a PCE that is equivalent to a pre-coordinated that is part of the value set match? RH: If the value set says that PCE is included, then yes it should handle that.
|
5 | $validate-code behaviour | 20 | | Current behaviour doesn't allow for distinction to be made in responding to quality of term queried. Note: Since server returns display term, if the query just checks for membership then the client could check its term against that returned. This waters down the usefulness of the server but would simplify if functionality is not in the 80% of features required. See GForge issue #17218 (ML's). Also #16586. See also https://chat.fhir.org/#narrow/stream/48-terminology/subject/Validation.20for.20foreign.20language.20resources |
6 | Main item for discussion | 60 | | SNOMED CT Canonical CodeSystem resource- Review and attempt to resolve detail questions
- Issue around extensions and what this CodeSystem resource actually represents
Update: URIs populated. Intention to provide short URLs for normalForm and normalFormTerse to point to appropriate definition of terms. |
7 | Current items | 10 | | - SNOMED CT "Universal" Edition
- Definitely useful to have a catalogue of all concepts ever issued if not a proper edition which may be much harder?
- Is this work for this group, or should this be handed on to a more appropriate SI group?
- Check and fix ECL in the FHIR spec
- Is there a way to systematically identify all ECL expressions in the FHIR spec?
- If we run these through validation is there appetite/volunteers to review and fix them as feedback to the spec?
- Is there a way to integrate ECL validation into the FHIR spec tooling to prevent recurrence?
- Rob Hausam to progress Michael's tracker item on this issue.
- Normal form and normal form terse definition
- Rob Hausam to progress returning NormalFormTerse to the page.
- Linda Bird to progress defining Terse Normal Form with the Family of Languages group (Rob Hausam confirms needed for July)
- SLPG agreed that the Languages group is not the appropriate forum for this definition. Instead, we believe this should be defined in the DL subgroup of the Modelling Advisory Group.
- Also agreed that the terms that need defining are "Canonical Normal Form" (which is terse by definition) and "Necessary Long Normal Form"
|
8 | Review of "Using SNOMED with FHIR" page
| 5 | | All participants are invited to review this local copy of that page. - Section 4.2.1.0.5 suggestion that we terse Normal Form properties (Peter J disagreed). Clarity needed on which Normal Form is being represented (eg breaking sufficiently defined concepts down to their primitive components, unlike what is supplied in the browser). Further discussion needed on what these properties are being used for. Perhaps only 1 is necessary since terms can be added/removed as required
- Supplements are a possible way to allow language reference set type functionality.
|
9 | Review of TS Collaborative Work | 5 | | Collaborative Work |
10 | Any other business
|
|
| Next Meeting: Tuesday 26 June Questions for next week: |
Meeting Files
No files shared here yet.