Terminology Server Procurement - RFP
HSPC Terminology Server RFP Posted June 24, 2019
HSPC Terminology Server Requirements Spreadsheet
HSPC Terminology Server RFP Cost Worksheet
Introduction
The Health Services Platform Consortium (HSPC) is seeking a terminology server and associated software products that will support an integrated HSPC terminology environment and its related dependent requirements.
The purpose of this Request for Proposal (RFP) is to solicit proposals from parties providing the terminology services capabilities and functionalities to meet the needs of HSPC. HSPC intends to include a terminology server within our architecture to support services and terminology related tools required for the development and testing of Clinical Information Modeling Initiative (CIMI) models, FHIR profiles, SMART on FHIR applications, and other applications within the HSPC sandbox. (For information on the HSPC Sandbox, please see https://developers.hspconsortium.org/build)
For more information please see the attached documents above.
Request for Proposal Q&A
| Date | Req# | Requirement Description | Question | Answer |
|---|---|---|---|---|
| 7/8/2019 | 10 | Ability to create concepts in a proposed status | Can you please elaborate on what is meant by this status? Is this status active, inactive, or related to workflow? | We will be linking the terminology server to the logical model creation tooling. We want to add concepts in a proposed status that have not yet been curated into the standard terminologies. |
| 7/8/2019 | 36 | Get code groups that a code belongs to or check if a code belongs | Is this requirement to return all the codes in a given refset/value set? | We want to know what value/reference sets a specific code is a member of. For example, breast may be a member of the pain body location as well as the cancer body location. |
| 7/8/2019 | 40 | Provides ability to notify content stewards any changes to content they govern or use. | Are the changes to "content" referring to updates to Standards or changes in value sets that are created in the authoring environment? Who are these content stewards? Are content stewards a defined role? | Content stewards will be the clinicians or clinical specialty that approve a logical model. For example, the Office of Population affairs is the steward for the Family Planning Annual Report (FPAR) models. If there are changes to the values in their value sets or data elements (such as an inactivated lab) they will be notified. |
| 7/8/2019 | 45 | Browse reference sets. | We interpret this requirement as the ability to view concepts that are in a reference set. Is this correct? | Yes, the user will be able to browse a reference set. |
| 7/8/2019 | 48 | Tool used to retrieve content based on terminology queries described above. | Can you please elaborate on this requirement - is this the ability to query/search for content as described by requirements 31-37? | Yes. "Described above" references 31-37. |
| 7/8/2019 | 5 | FHIR Batch API - multiple requests using batch. | Please provide a pointer to this API that is specific to batch + terminology. And can you provide a pointer to the Marketplace packaging spec? | For the FHIR API batch functionality listed in the requirements spreadsheet, we did not have a specific requirement for this. We just wanted to know from the vendors if they have the ability to support batch terminology operations, such as the ability to translate a list of codes in one call rather than having to do them one at a time. I don’t think this is actually supported by the FHIR API specification, so it probably shouldn’t be under the FHIR API row. |
| 7/8/2019 | N/A | Crosswalks | Are crosswalks just a data set that needs to be loaded (i.e. a map)? | Crosswalks are linkages between different namespace synonymous concepts. The namespace may be local or standard. For example, there is a SNOMED Observable for Edema as well as a LOINC code for edema. We want to query and retrieve the crosswalks between the two. |
| 7/8/2019 | N/A | N/A | We have functionality that is not listed in the requirements such as the ability to classify the terminology. Do you want us to list our additional functionality? | Yes, we are interested in your additional functionality. |
| 7/22/2019 | 12 | Supports collaborative authoring | Is there an expectation the vocabulary server would be used to author SOLOR content or is there a separate authoring environment that the terminology server will be linking to? | SOLOR content will be authored in a separate authoring environment. This content will be loaded into the HSPC terminology server. |
| 7/22/2019 | 13 | Types of content to author:
| Is there a workflow diagram available for how the terminology server will be used in the SOLOR content authoring workflow? | See above. The terminology server will only be used to load the SOLOR content, not for authoring it. We have not created a workflow diagram. |
| 7/22/2019 | RFP Scenario 1 | SOLOR using the procured terminology server: SOLOR has 3 release formats. Any one of these formats could be used for importing into the procured terminology server:
| Is there a SOLOR Object Format or SOLOR Relational Format specification? Is that documentation available for responders to use? | The Solor Object Format is not documented outside of the code itself. It is the “change set” format that the environment generates. The Solor relational format is aspirational, but is essentially SNOMED RF2 format, replacing SCTIDs with UUIDs (so systems other than SNOMED will work), and adding author and path (aka branch) columns to each of the relational files. |
| 7/22/2019 | RFP Scenario 5 | HSPC Toolchain: The HSPC modelling toolchain will require the creation of terminology and value sets for development and testing purposes via a REST based interface | What are the expectations of the types and formats of content that would be authored using the REST services? | The REST services should be simple CRUD services that support whatever types and formats the supplier uses for its terminology server for terminology and value sets. We have no specific expectations for the “types and formats” (assuming we have a common understanding of what that means) because we know this may vary between terminology server suppliers, but the services must be RESTful. |
| 7/22/2019 | RFP Scenario 7 | Authentication and Roles: Probe for user information using the provided OAuth endpoint for user information such as given name, family name, email etc. | What information is included in the token returned by the Keycloak 5 identity provider? | Besides what is available in the “openid” scope, the ID token has any demographic information as well as membership level(s). |
| 7/22/2019 | RFP Scenario 7 | Authentication and Roles: Support automated access token refresh | Is the token refresh needed for API authentication or authoring tool authentication? | We prefer both, but please let us know what is available. |
| 7/22/2019 | RFP Scenario 7 | Authentication and Roles: Support notification of logout to the provided OAuth endpoint upon explicit session termination events | Request clarification of what is meant by “explicit termination events”? What is the goal of the requirement? | This refers to an action taken by the user, or by an underlying service, to end (logout of) a current session, such as by clicking a “Logout” button, as opposed to an unexpected session termination such as system failure or lost connection. The goal of this requirement is to ensure that the authorization token and connection to the endpoint are properly closed for security purposes and to cleanup connections that are no longer needed. |
| 7/22/2019 | RFP Elements of Proposal | Implementation Timeline | What should be included in the description and timeline for “Implementation”? Development vs. Production Implementation? Sandbox vs. Authoring platform? Technical vs. non-Technical? | We leave this largely up to the supplier to determine what should be included in the timeline in order to cover all the requirements in this RFP. At a minimum we would expect each of the deliverable items described herein (explicitly or implicitly) to be included. The goal is to allow us to plan when given functionality will be available in a review, pilot and full production capacity. |
| 7/22/2019 | RFP Elements of Proposal | Training Plan | What should be included in the description and timeline for training? Technical? SMEs? Content Authors? Specific Delivery Methods, i.e. Web-based, Classroom, etc.? How many people? Locations? Timing? | We leave this largely up to the supplier to determine what should be included in the Plan because each supplier’s product/solution will be different and will require different training materials, methods and personnel. It should include whatever training the supplier feels is necessary in order to provide a usable, supportable product/solution within the Implementation Timeline. We would not expect our personnel to travel long distances for training, and we would not object to web-based training if this can be delivered effectively. The number of people receiving training may vary depending on the product/solution (for example, a cloud-based solution operated by the supplier may not require training of our own system admins), but we anticipate likely 10 or fewer personnel requiring training (initially). |
| 7/22/2019 | 45 | Support authorization of licensed terminologies (e.g. CPT) | Request clarification of the requirement to “Support authorization of licensed terminologies”. What support is expected in the terminology server? | If licensed terminologies are loaded in the terminology server, our expectation is that the server would be able to determine if a user has a license to access this terminology. We would also like to know alternative methods/strategies the supplier has to ensure that we can control access to licensed terminologies. |
Question: When are responses to the RFP due?
Answer: Responses are due 8 weeks after posting, Monday, August 5th, 2019.
Question: How do I submit questions about the RFP?
Answer: RFP questions should be submitted via email to susan.matney@imail.org or as a comment at the bottom of this page in Confluence.