Medicare Data Solutions RFP FAQ

Size: px
Start display at page:

Download "Medicare Data Solutions RFP FAQ"

Transcription

1 Medicare Data Solutions RFP FAQ Updated 7/13/2016 Q: Would CRISP prefer a full end-to-end vendor s solution, or can the respondent answer the analytic engine platform questions and still be considered for next step selection? A: Partial solutions are valid and acceptable. Q: Who are the estimated end-users for the analytics engine and self-service data abstracts? A: In phase one, all 46 acute care hospitals across Maryland will have a number of users of the system. We expect about 10 system users from each hospitals, with about 2-3 power users each. In phase 2, we expect to bring post-acute care providers, long term care providers, and other users onto the system as well. The users for all phases will be geographically dispersed across the state. Q: How much historical data will be loaded initially? A: The State of Maryland and CRISP continue to work with CMS both on data delivery and timeline. Our intent is to receive data going back to January 2013 as that is the baseline year for Maryland s All-Payer Model. Q: Is there a formal delivery schedule of Medicare files? A: The State of Maryland and CRISP continue to work with CMS both on data delivery and timeline. Q: Are population health analytics, such as care coordination and end-user visualizations, part of the intent of this RFP? A: CRISP would like to see a full range of what you intent to provide under the phases of the RFP. The State of Maryland s waiver focuses on population health, thus the best solution will provide a range of population health analytics. Q: Is the vendor responsible for practice transformation in Phase 3? A: Provider practice transformation is outside of the scope of this engagement. In phase 3, the vendor will be responsible for refining the solution and providing ongoing support. If CRISP determine CRISP would like to operate the system, the vendor is responsible for conducting training with CRISP staff. Q: Does CRISP have SLAs with the end-user community for transforming the monthly feeds to actionable analytics? A: Practice transformation is outside of the scope of this RFP but the most advantageous solutions will draw clear connection between data and actionability at provider level. Q: If a vendor proposes an on premise model, does CRISP have an expectation / preference that the vendor both procures the hardware and installs the software or that the vendor recommends the hardware and installs the software once the hardware is procured by CRISP? A: CRISP will rely on vendor judgment and recommendations for software/hardware. CRISP does not have a preference on hardware or software.

2 Proposal Format Questions Q: Please clarify where graphics should be provided. A: Graphics can be included within sections of the proposal, or in the appendices as noted in the RFP. The idea is to have a thumbnail-like understanding in the narrative and place any additional details into the appendices. Graphics for 3.c.i can be included as part of 3Ci or as part of Appendix A, and graphics for Section 3ciii can be included as part of 3ciii or as part of Appendix E. Q: Where should graphics for section 3.C.ii be placed? A: There was no corresponding Appendix listed for section 3 c ii in the RFP. Please place graphics within the narrative for this section or create an additional Appendix G, with a 3 page limit. Q: Are graphics included in the page counts for each Appendix? A: Yes. Any diagrams or figures are part of the page count for appendices. Q: Can all graphics be placed in a separate Appendix G? A: For ease of review, please place graphics either within the narrative or in the corresponding Appendix as indicated in the RFP. Q: What is the page count for the Technical Diagrams section? A: The Technical Diagrams section page count is 10 pages, as addressed in the bidders conference. We apologize for the typo in the RFP that erroneously lists the Technical Diagrams section as 3 pages. Q: What is the requested order of the project plan and customer references, as it varies throughout the RFP? A: Apologies for the confusion. Please order the customer references as Appendix B and project plan as Appendix C. While for ease of review we have asked for the proposal in a certain format, the content of your proposal is far more important to us than order of documents. Q: What should vendors use as the implementation start date for the proposed project plan and timeline requested in Section 3.D.iii and Appendix C? A: The implementation start date is up to the discretion of the vendor, but should be aligned with the contract start date. Dates are subject to change. Background on CRISP and RFP Q: Please describe CRISP s data-governance activities (data definitions, stewardship, etc.) and strategic alignment with this analytics engine platform. A: CRISP conducts data governance activities tailored to specific data sets and use cases. For this RFP, we are asking that the vendor propose an appropriate governance model keeping in mind extensibility. Q: Please describe CRISP s existing information technology (IT) staff available to support this enterprise activity. A: As this is a large and important solution, CRISP will use a blend of existing resources and newly hired resources to maintain the Medicare data system. During the engagement, CRISP management will deploy resources to oversee the engagement and coordinate with the vendor to review workflow and deliverables, 2

3 and serve as the primary point of contact for CRISP. As CRISP determines the long term operational strategy for the Medicare data system, CRISP will deploy and hire additional resources as needed. Q: Please describe CRISP s existing relationship with CMMI and partnership plans for the next 1-5 years. A: As the State Designated HIE for Maryland, CRISP is increasingly acting as a provider of state-level infrastructure to support care coordination and care management efforts that are being driven by Maryland s goals for quality improvement and cost control as defined by the State s All-Payer Model contract with the Centers for Medicare and Medicaid Innovation (CMMI). Q: How will CRISP review technology vendors who are world-class in analytic engine platforms with a partner ecosystem that includes multiple end-user visualization options? A: As in all CRISP s vendor partnerships, we seek long-term technology partners that we believe are the best in the business for providing effective and efficient solutions. We seek partnerships that benefit and grow both organizations while delivering excellent value to our users. Updated 7/6/2016 Q: Can qualifications and references from a sub or partner be included as part of the lead bidder s proposal to meet the requirements outlined in the RFP? A: Yes, it is acceptable for bidders who respond collectively to include shared qualifications and references so long as they adequately demonstrated their experience with projects of a similar size/scope. Partners are recommended to demonstrate that they have worked collaboratively on similar projects before. Q: Can vendors submit a brief bio for review to ensure specific Medicare experience meets RFP requirements? A: Yes, vendors may submit a brief bio and we will do our best to determine their eligibility. We are looking for 3 implementations of similar size and scope with Medicare data. Q: My firm is potentially interested in partnering with other firms for our response. Can you share any contact information for interested groups? A: CRISP will not release the names or contact information for potential responders without their permission. If any groups are interested in partnering, they may laura.mandel@crisphealth.org and she will share only the information amongst those groups. 7/1/2016 Procedural Questions Q: Can vendors submit multiple bids? A: Yes, CRISP will consider multiple bids. Q: Is a formal intent to respond letter required for the July 8 th deadline? A: A simple to laura.mandel@crisphealth.org listing your company, contact person, and contact information will suffice. CRISP does not require a formal letter. 3

4 Q: What is the funding mechanism for this RFP? A: The RFP is funded directly by CRISP. Q: Are there are any funding parameters or guidelines? A: No. Vendors should submit bids based on the cost templates provided. Q: Is there a governmental certification requirement? A: No. Vendor Background Requirements Q: Can you elaborate on the minimum requirement of three Medicare data implementations of similar size and scope? A: Vendors who submit bids for this RFP must have significant experience implementing Medicare data and analytics solutions that are comparable to the one described in the RFP. Because of the nature of the Medicare data, we require vendors to demonstrate significant prior use of Medicare datasets and file formats, such as CCLF (Claim and Claim Line Feed), LDS (Limited Data Set), X12, or other CMS prescribed datasets. Vendors submitting partial responses should demonstrate experience with the aspects of the RFP to which they are responding. Q: Can experience with other government datasets, such as Medicaid, be substituted for the Medicare requirement? A: No. This project requires demonstrated experience with Medicare data. Experience with other datasets is beneficial and definitely a plus, but cannot replace use of Medicare data. System Connections Q: What type of extensibility capabilities do you envision? A: While this project focuses initially on Medicare claims data and requires use of Medicare datasets, we envision being able to incorporate other datasets in the future. This may include Medicaid data, commercial data, and clinical data. Organizations may want to highlight experience or data solutions using these types of datasets in conjunction with Medicare data. Q: Should the system be able to run groupers or algorithms, such as case-mix or risk adjustments? A: The data solution should be able to manage complex data, but could achieve this by layering the algorithms on top of the data. Q: Should the system connect with a data visualization software, such as Tableau? A: For this RFP, we are not requiring or intending to connect the analytic set through Tableau; however, respondents may want to describe their experience with visualization software, including but not limited to Tableau. If you have another data visualization tool that you prefer, please let us know we are always looking for the best tools in the industry. Data Questions Q: Where will the Medicare Data System data come from? (Question received via .) 4

5 A: The Medicare data will come either directly from Medicare or via an organization who is part of a Medicare ACO (or similar initiative). The specific technical approach would depend on the data type (i.e. CCLF or LDS) and we expect the vendors to be familiar with these protocols and automation approaches. For X12, we assume this would come directly from the providers (we picture parallel processing of X12, 837, and 835 files). Q: What is the expected format of the Medicare Claim feeds? Will they come through as csv/flat files or X s? Or something else? (Question received via .) A: We expect either CCLF (Claim and Claim Line Feeds), LDS (Limited Data Set) or X s as described in the RFP. We expect the vendor to be intimately familiar with handling these types of Medicare data. Q: It was mentioned the Medicare Data System will transform the data to industry standards. Can you offer specifics on it please? (Question received via .) A: Regarding transformation, we would like to understand how the vendor solution approaches mastering specific data attributes to industry standards. This may include: Patient mastering to an MPI or Provider mastering to an NPI (and other standard provider taxonomy codes); mastering administrative concepts for Procedures and Diagnoses to industry standard groupers or classifications; and mastering Pharmacy data to industry standard drug classes or categories. Miscellaneous Q: Is this RFP related to the state s All-Payer Claims Database (APCD)? A: No, these RFPs are not related. The work for the APCD was awarded through the Maryland Healthcare Commission s formal procurement process. 5