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: What is/are the API(s) that CRISP has for your consent module?
A: CRISP will provide an API to check patient consent.
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: Does CRISP have existing data-sharing agreements with any national networks at this time?
A: Yes, Carequality and eHealth Exchange.
Q: Is CRISP looking for the selected vendor to connect directly to the eHealth Exchange or would connecting via Carequality be sufficient as long as the need is filled?
A: CRISP will need to able to connect to both networks. An ideal solution would allow us to implement other networks with minimal effort.
Q: What is your current approach and/or solution for searching Carequality and eHealth Exchange? What is it lacking that’s driving this RFP?
A: We are looking for a new fully integrated solution that can initiate queries out to the Carequality and eHealth Exchange networks. We are looking for solutions that can identify and initiate patient search based on various criteria like zip code, radius of search, state etc.
Q: Are you looking for a pre-existing solution (software package or SaaS solution) or do you think this is a custom-build?
A: We will consider all types of solutions.
Q: Do you already have part of the solution, for in place initiating requests, and if so, will this RFP extend that solution?
A: This will be the only solution for Initiating queries.
Q: Are you looking for the vendor to evaluate existing packages and make a buy vs. build recommendation?
A: We will consider evaluations on buy vs. build. We will decide based on the functionality offered by each solution.
Q: Will the vendor need to touch live PII data or can you provide anonymized data?
A: For testing and Implementation, a validation environment will be used that will contain non-PII data. The vendor will have to be open to provide support during Implementation of the solution in a live environment that will contain PII data.
Q: What is your expectation for the vendor providing operate and maintain (O&M) support after it is deployed?
A: We expect a handoff of the solution to happen once we have it live and deployed. Depending on the solution (SaaS, vendor built and coded), we will need operate and maintain support as required to be operational.
Q: Is it acceptable for the vendor to provide the technical expertise (software, data, cloud, security) to partner with your SMEs in HIE / HL7 standards?
A: Yes.
Q: What is driving the timelines to be complete by 7/23?
A: Multiple engagements from various States.
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.
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.
National Network Initiating Gateway FAQ
Q: What are the key business problems CRISP is trying to solve with this RFP?
A: Gaining the ability to identify and interact with gateways available through National Networks. The solution should be easy and cost effective to maintain and deploy.
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: What is/are the API(s) that CRISP has for your consent module?
A: CRISP will provide an API to check patient consent.
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 types of support would be expected as part of the proposed solution to acquire any National Network certification(s)?
A: We expect support on all aspects of the proposed solution.
Q: What is/are the API(s) that CRISP has for your consent module?
A: CRISP will provide an API to check patient consent.
Q: How many expected requests would be submitted to the various national networks?
A: The solution should be able to scale up or down depending on the need. There is no set number of requests.
Q: Is the driver of the initiating gateway to get ambulatory CCDAs from Carequality EHRs, or also from other eHealth Exchange?
A: Primary objective is to exchange all supported types of CDA documents from and between Carequality and eHealth Exchange networks.
Q: Is CRISP intending to only return documents to the CRISP CDR? How else is CRISP expecting to expose CCDAs to users?
A: We are expecting to return the CDA document to the system initiating the request. This solution will allow CRISP to query out to National Networks and provide the document available.
Q: Is CRISP expecting to parse incoming documents into FHIR resources, or otherwise parse data into the CDR?
A: No, at this point we are looking for the ability to query the National Networks and return a document to the query initiating system.
Q: For both initiating and responding transactions, what is the anticipated volume of Patient Discovery Queries per state?
A: This solution should be scalable and adjust to fluctuations in volume.
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. Questions are due by Friday, Feb 26th and Proposals are due Monday, March 8th.
Q: For Requirements as Use cases – Item #14 – EHR SSO/SAML Integration for a User Interface that would support IHE based queries: Do you assume that the EHR is going to be able to pass patient context, so that the Query Initiator User Interface is simply supporting the “make a query” and “return the documents” results back? Or – are you expecting a UI that would allow for patient demographic entry BEFORE making a query. (no patient context shared).
A: We would expect the patient demographics sent to the solution without the need to integrate with an MPI.
