These pages are currently transitioning into the SNOMED GitHub pages. See https://github.com/IHTSDO/snomed-ig
HL7 currently provide a daily build view of that which can be seen here: http://build.fhir.org/ig/IHTSDO/snomed-ig/
Design Notes specific to Client Applications
Option for "pass-through" terminology requests so that FHIR server acts as proxy for Terminology Server. Operations such as Expand may need to make calls on to Terminology before collating results.
SNOMED Specific profiles (clinical resources)
Assumptions and Audience
Introducing SNOMED to a FHIR audience and FHIR to a SNOMED Audience!Explanation of 4 levels of binding.
Code, Coding, Codeable Concept as specific to SNOMED CT (include link to introduction and points about display terms & multiple languages).
What is the scope of content for the guide? Targeting "Best Practice" for FHIR Implementers using SNOMED CT. Possible layered approach and potentially strict (for internal record keeping and communication) vs permissive profiles when . General guidance for bindings or specific details on each resource.
Audiences - Developer vs User of implemented services. ML Suggests single entry point document with multiple paths through the documentation.
Existing Documentation to Pull In
Comparable Implementation Guides
- Rob Hausamto supply
See also https://simplifier.net/guides
- Expand (Valueset)
- FHIR Frequently Asked Questions
- General Implementation Considerations
- Implementing Terminology Services with SNOMED CT
- Introduction to using SNOMED with FHIR
- SNOMED specific behaviours
- System Architects working with SNOMED and FHIR
- Terminology Binding
- Test Suites for using SNOMED with FHIR Servers
- Working with Language Reference Sets
- Working with Languages
- Working with ValueSets
Feedback for HL7
19 March 2019
These two pages seem to be very similar?
4 June - group agreed to target R4 in the first instance but to indicate any future changes inline. Also (PJ) suggested section on major changes from STU3 to R4 where relevant to SNOMED eg $compose is now $find-matches
2 July - PJ: question over specific content for different stakeholders (FHIR spec does this) and how we present that - separate pages for developers (details) vs architect (integration, general 'use' of terminology services eg off the shelf solution. Why use the FHIR API at all?) vs business level?
ML suggestion that we introduce SNOMED "through the lens of FHIR", so stay away from language reference sets and stick with what can be seen directly from FHIR resources. (But we can have links to the detail & implementation course - PJ)
- No labels