Page tree

SNOMED International currently has a tool used by SNOMED International and the wider community to create and manage SNOMED CT reference sets. The tool has been in use for a number of years but the organization wishes to procure and develop the next evolution of tooling for the management of SNOMED CT reference sets in order to meet the requirements of a growing product and community, who are looking for more collaborative solutions.

The objective of this Request for Proposal (RFP) is to request proposals from vendors for a solution which will deliver the following:

  • the provision or the design, development, testing and deployment of a SNOMED CT Reference Set Management tool;
  • project management of the end to end solution development and delivery process;
  • support and maintenance of the solution once deployed.

This RFP is published on 5th November 2020 and responses are required to be submitted to rfp@snomed.org by 12h00 UTC on Monday 30th November 2020.

SNOMED International expects to inform the successful bidder by Wednesday, 9th December 2020 subject to receiving feasible proposals.


RFP Questions Received & Answers Sent

Below are the questions sent to the rfp@snomed.org inbox by potential bidders and the subsequent answers from the SNOMED International team. Please send any further or follow on questions to rfp@snomed.org. 

  1. Who is on the hook for needed Snowstorm enhancements? We assume SNOMED will be responsible for this. 
    1. A: Any changes to Snowstorm needed will be in the scope of this work and would be the responsibility of the winning bidder, not SNOMED International. The SNOMED International team will assist and guide in this.
  2. What features of the application must be available for non-logged-in users? 
    1. A: All view & search features for 'published' or public reference sets within the directory would be expected for anonymous users, including the specifics detailed in 2.1.7.E. Any collaboration is expected to be done by authenticated users. Anonymous users may be able to give feedback on published/public reference sets with the caveat of their details (name, email address) must be recorded.
  3. What specific IMS user info is available (such as name)?
    1. A: The IMS currently returns last, first name and email address. We would be open to proposals including further data being stored within IMS or other suitable authentication approaches.
  4. For question 2.1.4.E: What is this item doing in the “extensional” section of the specification?
    1. A: Thank you for making us aware of that. It is relevant to intentional refsets and is in the wrong section. However, if an extensional reference set was created using ECL, storing the original ECL to re-run would be a useful requirement
  5. For question 2.1.6. B: Does self-publishing mean that the tool itself actually creates publication files? Or that publication happens entirely external to the tool (e.g. in some external NRC system)?
    1. A: Using the export from the terminology server, the platform would be expected to manage the workflow from the initiation of the process to making available on MLDS (but only for those relevant member country NRCs who currently use MLDS, not for all users).
  • No labels