20:00 UTC on Tuesday 14 August 2018 - 90 minutes.
- FHIR Terminology Services and Resources
Peter G. Williams, Dion McMurtrie, Rob Hausam, Jane Millar, Peter Jordan, Scott M Robertson, Reuben Daniels, Daniel Karlsson, Jim Case, Anne Randorff Højen, Carmela Couderc, David Sperzel, Michael Lawley, Pamela Banning
|Owner||Notes & Actions|
|1||Welcome and introductions||5|
Recording, notes & attendance.
SNOMED on FHIR meeting planned during the business meeting - closed session (observers space dependent).
|2||October Expo - Vancouver||5|
|3||Summary of previous week||5|
|4||Work suggestions from last meeting|
Proposals for expand
Options for validate code - mapping between various data issue scenarios and true/false result flag.
|5||Zulip discussion on Post Coordinated expressions||50|
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.
Update: Difference between two positions - when expanding value sets defined intensionally, expectation that any existing pre-coordinated concept or PCE would be included. Graham expects server to return "Too Costly" as logical behaviour would be to return every possible PCE.
Questions / Discussion
Update 26 June
PJ: Could change excludePostCoordinated to includePostCoordinated (and default to false) in operation-valueset-expand.html to better reflect the current capabilities of 99% of systems. Option for finer grained enumeration ("PostCoordination" / "Composition Behaviour"?)for varying efforts in PCE generation. RH: Remember these changes would apply to all code systems.
|6||SNOMED with FHIR||30||Rob Hausam|
All participants are invited to review this local copy of that page.
Note this discussion is specific to the response to Term during validation.
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.
14 Aug Update - Discussion planned for Vancouver Meeting Agenda. Note that Grahame Grieve stated "already done" on tracker item 11 Aug.
|8||Main item for discussion||30||SNOMED CT Canonical CodeSystem resource|
Update: URIs populated. Intention to provide short URLs for normalForm and normalFormTerse to point to appropriate definition of terms.
Update 14 August See draft (doesn't specify particular normal forms) :
|10||Mechanism for working with Languages.||15||Reuben Daniels|
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.
|11||Review of TS Collaborative Work||5||Collaborative Work|
Any other business
Next Meeting: Tuesday 28 August
Actions for next week: