This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "SNOMED Submission Process Draft Outline"

From HL7Wiki
Jump to navigation Jump to search
Line 25: Line 25:
  
 
*  
 
*  
 +
 +
== Who can Validate Domain Specific Requests? ==
 +
 +
* Clinical review is necessary to validate content.
  
 
== What is the Communication Plan in HL7 wrt the Status of Requests ==
 
== What is the Communication Plan in HL7 wrt the Status of Requests ==

Revision as of 14:57, 17 May 2010

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.

What is the Communication Plan in HL7 wrt the Status of Requests

When

Where