CRISP is seeking to procure a National Network OnDemand Document Solution. The main purpose of this solution is to create OnDemand Documents which conform to the C-CDA R2.1 – HL7 CDA R2 Implementation Guide and can successfully pass eHealth Exchange Content testing requirements. Connections would be easily made to a variety of downstream systems to include RESTful APIs and SOAP messaging protocols. Data connections may be configurable and filtered by Sending Source, Receiving Source, or Original Data Source. Must have an ability to accept and respond to ITI-18/ITI-38/ITI-43/ITI-39 messages.
CRISP has a strong preference for a solution that is open-source or has clear and transparent list pricing. Further, CRISP has strong preference for a solution which fits within our existing Azure framework. It should also have standard logging capabilities (timestamp, requestor, patient, documents returned, success/fail) and be able to interact with CRISP’s accounting of disclosures service. Any solution introduced into the CRISP environment must conform to CRISP security policies, performance standards, and code review.
| Event | Dates | Notes |
| RFP Released | 24 February 2021 | RFP will be posted on CRISP’s public website. |
| Clarifications / Q & A | 26 February 2021 | Last day for vendor to submit questions |
| Vendor Responses Due | 8 March 2021 | Last day to respond to the RFP. |
| Vendor selection & contracting | 19 March 2021 | CRISP will review vendor responses. |
| Contract Execution | 26 March 2021 |
The due date for submissions is March 8th, 2021 at 5pm. Please submit questions and responses to candice.titus@crisphealth.org. Please keep responses under 15 pages, ideally under 10 pages. For submissions, please also include transparent pricing for delivery of the solution as outlined below.
| Task | Timeframe | Proposed Major Deliverables |
| Detailed technical SOW and implementation plan | 5 April 2021 | Vendor must be able to support the project immediately upon selection and will work with stakeholders to finalize requirements and begin project kick-off. |
| Development Start | 7 April 2021 | Necessary development or configuration, load testing, user testing, performance testing, demonstration of testing to CRISP |
| Implementation | 30 June 2021 | CRISP will perform a code review using standard security practices and deploy within CRISP Dev and Test environments. Vendor will help CRISP IT team understand how to deploy in Production and will be available to assist with the deployment. |
| System Training and handoff to CRISP IT Team | 16 July 2021 | Vendor will be expected to make available some documentation and training so that support can be provided inhouse at CRISP going forward. |
| Inform updates on the requirements/standards | 23 July 2021 | Vendor will be expected to make necessary updates/standards as per Sequoia. |
For a diagram explaining a potential data flow, click here.
OnDemand Document Query FAQ
Q: The instructions in the spreadsheets reference an Attachment “A” and have different dates for questions submissions. Can you verify the correct instructions and that we have everything necessary?
A: Each initiative as two related documents: one word document with an overview and dates, and one excel workbook. Each excel workbook has two tabs: “Requirements“ and “Requirements as Use Case”. Please complete the both tabs. Proposals are due Monday, March 8th.
Q: You are asking for a solution that creates an on-demand document “on the fly”; after querying for and receiving information from different federated sources. You do not specifically mention an existing document repository being used. Can you confirm the data flow below – or correct it where we have this misunderstood?
A: The high-level data flows as we are interpreting the RFP would be:
–Incoming ITI (IHE based) query type transaction occurs from eHealth or Carequality (or another trusted IHE endpoint) – Yes
-This triggers an outbound “do you know this patient” type federated query to your participants / data sources. An EID is sent in the ITI-38/18 request. An interaction with an MPI is required to get a list of all available patient ids. Then subsequent calls are made to internal downstream data systems with required patient id(s) (ei EID or Source/MRN).
-The proposed solution then consumes any returned data; normalizes it and transforms it, to meet CCDA content testing standards.
-The proposed solution then returns the on-demand CCDA to the query initiator.
-We assume there is a need to interact with your current EMPI as part of the data flows.
For a visualization of this flow, click here.
Q: What is the expected volume of fulfilled patient documents returned from the requests to the National Network(s)?
A: The solution should be able to scale up or down depending on the need. There is no set number of requests.
Q: Would CRISP prefer being a certified implementer with the national networks themselves by developing that functionality and owning it inhouse or would on-ramping through an already established implementer be an option?
A: We are open to solutions.
Q: Can you please provide more detail about the scenario described in the requirements row 34 about “downstream system” availability?
A: Data sources that provides information to create a CDA document come from various systems. The solution should be capable of generating a success with or without a system handing the data being available.
Q: Can you please provide more detail about the scenario described in the requirements row 34 about “downstream system” availability?
A: Data sources that provides information to create a CDA document come from various systems. The solution should be capable of generating a success with or without a system handing the data being available.
Q: How many unique patients are expected to possibly have data put into On-demand documents by the solution?
A: There is no set number, the solution should be scalable.
Q: What formats/protocols/APIs does CRISP currently support to supply patient data to the creation of the On-demand documents? (i.e. what interfaces would the proposed solution have available to leverage?)
A: The solution should accept common data formats like JSON, XML, etc from RESTful and SOAP web services. The solution should be able to translate and map the data and not depend on leveraging existing interfaces outside of this solution.
Q: Does CRISP currently have any patient aggregation (longitudinal record creation) capabilities?
A: No.
Q: Is all the patient data expected to be used in these On-Demand documents already in CCD form, or are there multiple source data formats/forms (and if multiple forms, which forms)?
A: No, they are not in CCD form. The source data will be in various formats like JSON, XML etc.
Q: How many different sources of data would be supplying-data/connecting-to the proposed solution?
A: This solution should be scalable to multiple data sources.
Q: How many documents are expected to be created and sent?
A: This solution should be scalable up and down to adjust to number of requests.
Q: How many requests for non-existent patients are expected?
A: This solution should be scalable.
Q: Is a service that fulfills the needs/requirements of both the On-Demand Document RFP and the National Network Query Initiator RFP as a single solution of interest to CRISP?
A: No, we are looking for one solution per RFP. We will consider other solutions.
Q: What data repository does CRISP use today?
A: CRISP has patient data stored in various repositories including but not limited to (PII /PHI /HIPAA compliant Azure data storage, FHIR servers, and various storage mechanisms.
Q: Does the data repository consist of data from CRISP Maryland, CRISP:DC, CRISP:WV, FL, CT, others?
A: Yes.
Q: Is the national network the eHealth Exchange?
A: It is Carequality and eHealth Exchange. An ideal solution would be configurable to allow to add and implement a new network if one comes available
Q: Is there a preference for vendors pre-certified on eHealth Exchange?
A: It is a benefit.
Q: Describe the on-demand query workflow as best you can?
A: Please see attached diagram for the basic workflow.
Q: What integration engine does CRISP prefer?
A: No preference.
Q: What time are proposals due Monday, March 8?
A: 5 P.M.
Q: Other than a “holding in cache” request – it does not sound like you want to store the documents long term. Can you confirm? Also – do you have any specific “time to live” (TTL) contractual requirements? We are unsure what you mean by a “refresh” solution.
A: Yes, unless is it stored in an audit trail (request/response). We did not want to limit proposals and tried to pick language that did not give a solution. Our thought was the document would need to be retrieved by the specified doc id, responded with in the DQ. Really the solution just needs to be able to produce the document based on that id in the DR.
Q: Are there existing CRISP data repositories that would be queried as part of this data flow? (Versus querying external participants / partners via federated IHE)
A: At this time, we are expecting all queries to occur internally, but we would not want to limit future possibilities of integrating with a different MPI and/or external data sources to create section data.
Q: Please clarify the following RFP requirement (OnDemandDocument): Row 48 in “Requirements” tab regarding ability to return OnDemand document based on patient consent API. Is CRISP referring to the ability for a patient member to authorize access to their PHI via their provider or is the “patient consent API” something CRISP exposes?
A: CRISP will provide an API to check patient consent.
Q: Please clarify the following RFP requirement (OnDemandDocument): Row 65 in “Requirements” tab regarding the ability to regulate incoming requests to the system. Any additional context as to what kind of regulation will be required around secure access requests would be helpful. Is CRISP asking the selected vendor to limit the number of secure access methods/requests?
A: CRISP will need to be able to provide secure and reliable access to this document creator. This security and reliability can be in various forms as mentioned in Row 65 of the “Requirements” tab. We would be open to evaluate all of your recommendations.
Q: Pease clarify the following RFP requirement as a use case (OnDemandDocument): Use case #13 regarding regional patient consent policies. Is CRISP referring to the ability for a patient member to authorize access to their PHI and allow CRISP to receive the OnDemand document on their behalf? We do not track whether or not regional patient consent policies are being followed.
A: CRISP will provide an API to check patient consent.
Q: Please clarify the following RFP requirement as a use case (OnDemandDocument): Use case #2 regarding multiple stakeholders’ ability to generate a CDA document based on data source. Who are the stakeholders in this case? Is CRISP referring to the individual provider members that belong to the CRISP HIE? Does “Data Source” refer to other providers that are a part of the National Networks or is “Data Source” something CRISP owns?
A: Stakeholders are any organizations or systems that want to receive CDA documents from CRISP. CRISP Shared Services represents multiple HIEs as stakeholders. This RFP is not to connect to a National Network. The data sources mentioned in this RFP are CRISP owned APIs and other sources that will provide data. This data will be used to generate a CDA document that will pass eHealth Exchange content testing and also is compliant with Carequality CDA documents.
General FAQ
Q: Would CRISP like two separate, 10-page proposals for the National Network Query Initiator RFP and OnDemand Document RFP? Or would CRISP like one 10-page proposal that addresses both RFPs?
A: One document per RFP.
Q: Does CRISP intend to list each provider within their network onto Carequality? Or is CRISP looking to have one global listing to Carequality? If the former, how many provider organizations is CRISP looking to list on Carequality?
A: CRISP Shared Services represents multiple HIEs as stakeholders. CRISP is looking be able to Initiate Queries from any system to Carequality, eHealth exchange network, and each other. CRISP will list organizations in the Carequality directory depending on the Implementation needs.
Q: Is there a scoring rubric that will be used?
A: Yes.
Q: Do responders need to respond to both RFPs?
A: No.
Q: Will responses/answers to questions be shared publicly?
A: Yes.
