This wiki has undergone a migration to Confluence found Here
SNOMED Submission Process Draft Outline
Jump to navigation
Jump to search
Contents
- 1 How is it Determined When a Content Change for SNOMED- is Needed?
- 2 How is it Determined that a Given Request is Valid for Submission?
- 3 How are Request Submissions Packaged?
- 4 Who within HL7 can Request a SNOMED Submission
- 5 Who within HL7 can Submit a SNOMED Submission
- 6 Who can Validate Domain Specific Requests?
- 7 What is the Communication Plan in HL7 wrt the Status of Requests
- 8 When
- 9 Where
How is it Determined When a Content Change for SNOMED- is Needed?
- Replacing HL7 internally created and curated content. (i.e. When an existing HL7 value set (or a constraint) is converted to SNOMED-CT content)
- When a value set is proposed that is only partially covered by SNOMED-CT and the requestor is a licensed SNOMED-CT user but does not have a national release center (i.e. if you have a national release center that is the organization to which applications for code extensions should be made).
How is it Determined that a Given Request is Valid for Submission?
How are Request Submissions Packaged?
- Is the domain valid for SNOMED
- Is the request provided in such a way that the intent of the request can be ascertained?
- Is it granular enough?
- Is the concept requested in the appropriate SNOMED hierarchy
- Does the concept already exist in SNOMED
- Is the requested content a synonym for existing content?
Who within HL7 can Request a SNOMED Submission
Who within HL7 can Submit a SNOMED Submission
Who can Validate Domain Specific Requests?
- Clinical review is necessary to validate content.
