2. Does AASLD have a commercialization model in mind for support in funding the registry? Yes, AASLD plans to commercialize data and reports.

Size: px
Start display at page:

Download "2. Does AASLD have a commercialization model in mind for support in funding the registry? Yes, AASLD plans to commercialize data and reports."

Transcription

1 Responses to Vendor Questions: Request for Proposal (RFP) to create a disease registry software platform Cirrhosis Quality Collaborative (CQC) an initiative of the American Association for the Study of Liver Disease (AASLD) 1. Is the vendor expected to provide an automated mechanism for data acquisition directly from multiple EMRs? If so, can the vendor ask the Hospital/clinic sites to identify submit data based on a pre-specified format? Answer: Automation should be maximized, per Section 3, sub-bullet i. AASLD will ask all sites to standardize data submission. 2. Does AASLD have a commercialization model in mind for support in funding the registry? Yes, AASLD plans to commercialize data and reports. 3. We are assuming that AASLD has a standard survey for collecting Patient Reported data? Please confirm. Are there any other expectations? AASLD Practice Metrics Committee will create and provide a standardized survey. 4. Please provide additional detail on narrative to discreet data conversion via Smart Notes or similar application. Every site will use a standardized format to capture and submit discreet and Smart Note data. 5. Is there a need to build a Universal Master Patient Index (UMPI)? If the patient exists in multiple EMRs? Or has visited/admitted to multiple facilities? This will be discussed with the selected vendor post award but it is not needed at this time. 6. What parts of the platform need to be portable? Anything other than the database, reports? The entire system to include application and data needs to be portable. This is specified in multiple areas of the RFP. Specifically in Section 5, Directions to Vendors sub-bullet 5.14 and Appendix C, Section 2: Data Standardization, Requirement Regarding pre-visit planning, are you looking for a checklist or form? Yes, AASLD will provide a standardized survey for the patient reported data. Data will be collected via a patient portal and combined with discrete data to include labs, and imaging then presented to clinicians via a dashboard. 8. We will use it proprietary technology to develop and provide the solution for AASLD. We understand that AASLD would have ownership of programs materials developed for AASLD under this RFP but we would continue to keep our technology proprietary. Is this acceptable? 1

2 The intent of the solicitation is to create a system that is wholly owned by AASLD. The use of proprietary tools has been addressed in the RFP see Question 6 above. 9. With data from an EMR, is there a preferred vendor (Epic, etc.) to try to integrate with for piloting or are importable CSV exports acceptable to start? The RFP addresses the specific EMR vendors for the initial effort in Section 3: Scope of Word, bullet i. 10. Based on the number of initial centers and projected growth, can you please provide some rough estimation as to the number of users per center? A general approximation of total users and concurrent users would be idea. AASLD estimates that each center will have 5-10 clinicians with approximately 100 patients per clinician with the expectation that user volume will grow over time. Access to the system will be role-based. 11. With the exception of meeting HIPAA requirements and NIST , are there any reservations in using Open Source technologies for the solution? The use of Open Source tools is acceptable as long as they meet or exceed the defined data security standards. 12. Is there a budget range for the overall effort? Yes, there is a budget. 13. Are there technology platform preferences for the solution? LAMP,.Net, Java, etc.? AASLD does not maintain any preferences; they are seeking innovative contemporary solutions from bidding vendors. 14. What AASLD team resources will be engaged during the build and later support phases of the project? AASLD will have their project manager and availability of clinical SMEs. 15. Are there specific project management tools or processes AASDL mandates using or can we propose our best practices and tools? This is addressed in Section 5: Directions to Vendor, bullet Page 5(e): Can you further detail what support the national network implies? Is this solely support for the digital tools and reporting created as part of this engagement or is the expectation that additional custom reporting, data sources etc. could be requested by Center and/or Network users in the future? AASLD is seeking a bid that is solely based on the tools and tasks as outlined with any additional work to be discussed and negotiated post award as a contract addendum. The system must be scalable. 17. Scope page 5(g): Are there specific requirements around the data/reports supplied to Pharma companies? 2

3 No, there are no specific requirements or interfaces for Pharma. Any requests for information will come directly to AASLD. 18. Regarding Business Analyst hours to work with the AASLD to further derive and refine functionality and requirements, is their SME skill level expectations for the analyst? Will AASLD have SME s available with liver clinical knowledge for these sessions? AASLD will have SME s with specific clinical knowledge available; however the vendor will need to provide a business analyst with the knowledge, skills, and abilities necessary to capture gaps in functionality. A clinical background may be useful. 19. Is it expected that the patient portal will require single sign on with external sites? Single sign on is not an initial requirement. 20. What is the expectation on number of sites that will not be able to automate data feeds? All sites should be able to feed data automatically. 21. In section 3.2, when is it stated "b) limited laboratory data uploaded on a daily basis", does this signify a manual upload process is required? AASLD prefers that this be an automated process this is a frequency (batch file vs. continuous feed, etc.) requirement, not automatic vs. manual. 22. In section 3.2 "a) discrete data from the electronic medical record, obtained from diagnoses, laboratory results, Smart Notes and other sources, uploaded on a monthly basis", is there a functional reason for monthly feed? Is there something preventing more frequent feeds? There is nothing preventing more frequent feeds, the monthly upload is the minimum acceptable. Again, this is a frequency requirement some solutions may be based on monthly batch files or more frequent feeds. Monthly is the minimum acceptable. 23. In section 3.2, is the pre-visit planning feature initiated by patient, clinician, or site system? Is it expected that the patient portal be embedded in the clinicians EHR UI? The patient will receive a tickler via text or to log into the portal prior their visit and complete the patient survey which will be fed into the clinician s portal. Clinical staff will use that data to complete the pre-visit plan. There needs to be an automated process for clinic staff to generate a notification to the patient to complete the survey It is not expected for the portal to be embedded into the EHR UI. 24. In section 5.7, will the centers have SLAs for data feeds or will vendor be responsible for supporting interfaces at each center This would be vendor supported under maintenance, updates, and growth. The vendor will be responsible for data use agreements with each of the sites. 25. Is there a ROM on number of patient, encounters, labs, etc.? What is anticipated volume of data? 3

4 Please see Question Is there an expectation for medical imaging to be stored in the registry? Not at this time. 27. In Appendix A "Only the bolded measures will be included as data elements in the registry at golive", does this signify that all the metrics in Appendix A will be live within the 3 year POP but only the bold measures are designated for go live at 6 months? Only the bolded measures will be used during the initial delivery. The other measures are for future growth and expansion. 28. Regarding Appendix A, it is expected that the sites/centers will have the appropriate data recorded in their EHR for proper measure analysis? Or will AASLD users abstract? The solution needs to extract the data from the EHR s, AASLD will not abstract data. The initial solution will need to include the 3 EHR s stated in the RFP, but AASLD anticipates other system will need to be included as the registry grows after the initial 3 year contract term. 29. Regarding Req#1.2 "ability to interface with Epic, Cerner, and VA CPRS platforms at a minimum": These systems have API's and we can supply the ability to interface, however is it expected that the vendor needs to configure interface at each site/center instances? The need for the vendor to configure will depend on the size of the site and their resources. The vendor will be expected to work with site-based technical staff to ensure proper operation at each site. However, should there be an exception that would need to be addressed with AASLD program staff at that time. Additionally, each site will have a Clinical Champion who will facilitate support for the vendor. 30. Regarding Req#1.2 "ability to interface with Epic, Cerner, and VA CPRS platforms at a minimum", is there an expectation of a UI in those instances? The expectation is that the solution will extract from those systems, not seeking to provide UI into those systems at this time. 31. Are there AASLD specific requirements regarding data retention, data archive/retirement, or federal reporting? There is no federal reporting expected during the initial 3 year contract period, however AASLD anticipates MACRA reporting in Phase 2. All data will be retained for the 3 year contract period After 3 years, the data can be archived. 32. Is the AASLD able to specify the amount of funds available for this project? Funding will not be specified. 4

5 33. In connection with the privacy and security requirements listed, does the scope of work envisaged for this contract include the need for a Business Associate Agreement with any of the entities to be included? Yes, BAA s will need to be included. 34. Does AASLD have an active Patient Safety and High Reliability Organization Program and how would the elements of these programs be incorporated into LHN? Patient Safety and HRO efforts will be site-specific and there may be overlap with the requirements of the HLN. All data that is exchanged must be encrypted in transit at all points with encryption technology sufficient to meet or exceed all HIPAA and NIST standards. 35. Since LHN will be operating with Federal EHRs will there be a requirement on the LHN to receive Authority To Operate from a Federal Designated Approval Authority under the FEDRAMP Program? This approval will be needed. 36. What is the extent to which AASLD has involved the academic community in the requirements analysis for the CQC? What academic institutions are part of an AASLD consortium? RFP and the requirements were developed in collaboration with the AASLD Practice Metrics Committee that includes academic leaders representing 8 institutions. 37. What are the ten pilot sites? The ten pilot sites have been identified and will be announced after the RFP process. 38. What is the geographic distribution of the ten pilot sites? Geographic distribution is not definite at this time but all are in the U.S. 39. Does AASLD have a contract with each of the ten pilot sites? This is not germane to the solicitation. 40. Will the ten pilot sites contribute resources to the HLN? This is not germane to the solicitation. 41. Is there funding available for pilot sites to assist them with connecting to and implementing the LHN? This is not germane to the solicitation. 42. How did the AASLD arrive at 10 pilot sites? This is not germane to the solicitation. 43. Would fewer be acceptable? The solicitation has defined 10 sites as the initial roll-out. 44. Is there any CMS Data Registry or CMS QCDR Registry currently gathering any data on the CQMs and other clinical data that will be expected to be gathered pursuant to this RFP? No, there will be no interface to CMS or CMS data collection. 5

6 45. Who is responsible for training additional sites beyond the pilot stage and what delivery mode is envisioned (online, user manual)? The vendor is responsible for creating training materials with the delivery of training method being self-learning that does not require classroom training. User manual and/or training aids will be required. Training materials should be sufficient to allow AASLD to train additional sites. 46. Can you describe the requirements for the "manual verification/activation" step of the ascertainment method in more detail? Patients for inclusion will be identified via billing codes and then validated manually by site staff to ensure appropriate inclusion. The solution needs to provide the trigger mechanism for manual review based on the billing codes. There must be a process to capture patients who have opted out in a more limited format. This refinement could be part of the post-award requirements review process. 47. Is there an approved FY18 budget for the LHN and what is the source of that funding? Will this design, development, deployment and operation of this project and the resultant Registry be selffunded by AASLD? Have there been any plans developed for the on-going sustainability of this undertaking once the Registry is operational? In preparation of this RFP has AASLD made any cost projections or established an anticipated budget for this project? AASLD has completed detailed sustainment plans and long term budgeting. 48. Are any federal or state governmental agencies or organizations involved in the design, development and future operation of this Registry? Yes, AASLD has already defined the Veteran s Administration as part of the pilot phase. Please review RFP for more detail. 49. Between the Registry and the sites from which data will be exchanged, how flexible will the time frames be for the exchange of CQMs and other data? For instance, aside from time spent on the exchange of Data Use Agreements what allowance for the submission, review and approval Clinician Review Boards from data source locations? Timeframes can be more frequent than specified in the solicitation but cannot exceed the specified timelines. 50. Does the AASLD anticipate issuing a Firm Fixed Price (FFP) or Time & Materials (T&M) based contract? The AASLD anticipates receiving a Firm Fixed Price bid for the first 3 year project phase. 51. Page 7, section 5.6 of the RFP states, Discuss current business and financial models, and provide financial statements for the last 3 years. Can you please describe in more detail what type of information you would like to receive related to business and financial models? The vendor needs to provide their financial statements for the past three years. AASLD wants to ensure the financial stability of the selected vendor. 6

7 52. Could you please clarify how you would like pricing information? Is it correct that you would like a single price for year 1 to include implementation, testing and onboarding 10 pilot sites? Years 2 and 3 would be continued support for the system plus a price per additional site? Or would you prefer a certain number of additional sites in years 2 and 3 included in a single cost for each year? The first 6-9 months will be building and testing. The end of year 1 as well as years 2-3 includes the onboarding of 10 sites and implementation of the Learning Network. It would be desirable to quote pricing to onboard additional sites at a per site price. As stated in the solicitation, pricing for additional sites may be structured as cost for small, medium, or large sites. 53. On page 7, 5.7 The scaling of sites, including hardware, software, and technical assistance is mentioned. However, there is no mention as to how the sites will be on boarded. Could you explain the process of site selection and onboarding process, including who is responsible for what, necessary data use agreements, training, etc.? AASLD will select the sites. Onboarding of sites will be performed by the vendor. See questions 52 and 45 for more information on onboarding and training. 54. What are the timelines surrounding the 10 pilot sites, as well as the subsequent expansion sites? Are the 10 pilot sites expected to be fully on boarded by end of year 1? How would delays outside of the control of the vendor be handled by AASLD? AASLD does want 10 sites on boarded by the end of year one. Delays outside of vendor control will be handled via negotiation with AASLD and the change order process. 55. What would the vendor s role be (if any) in the IRB process? The Vendor will not be involved in the IRB process 56. Please provide information or a link to information on Smart Notes referenced in 3.b on page 4. Please see Question On page 5, it says that the registry must support pre-visit planning. Do you have any more specifics on what is required there? Please see Questions 19 and Please elaborate the support team you plan to have in place on your side? (Program managers, project managers, business analyst, architects, etc.) Please see Question Please explain the review/audit and acceptance process? Do you have a team or 3rd party outsourced for periodic reviews, handle change management, etc. AASLD use of resource, staffing or third parties is not germane to the solicitation. 60. Overall please explain how your team plans to remain engaged with the vendor during the various phases of software development process AASLD has a program manager and clinical SME s that will be involved. 61. Do you expect the vendor to be involved in onsite classroom trainings (FTF)? Please see Question 45. 7

8 62. Will AASLD manage Domain registration, maintenance and SSL certificates? These will be the responsibility of the host. 63. Will AASLD manage licensing of software (Database, third party software and SDKs)? These will be the responsibility of the host. 64. Will there be a need to host each site on a dedicated server? It is not preferable, but it depends on the solution. 65. What is the data retention period? Please see Question Do you expect the platform to get external certifications (for e.g. HITRUST) Yes, external certifications are expected and subject to third party audits engaged by AASLD. 67. What kind of average data volumes can we expect per site? Please see Question On average how many concurrent users do you expect to access the system per site? Please see Question Will AASLD require support center infrastructure ( , Phone and Onsite support) Please see Appendix C: Sections 14 and Can the production support be from outside of US, with the hosting done on US servers? No, production support and hosting need to be in the U.S. Please see HIPAA and NIST requirements. 71. Does AASLD have partner programs or agreements with the EHR vendors such as Epic, Cerner, and VA CPRS? This question requires additional information from the vendor. 72. Is the narrative data based on the speech or text that is entered in the encounter notes? Yes both formats should be supported. 73. Does the vendor responding to this RFP need to be a registered entity in the US? Yes see HIPAA and NIST regulations 74. Are you willing to consider commercial off the shelf (COTS) products, customized to your requirement? Yes, that would be acceptable. 75. What kind of service level agreements (SLAs) can we expect? Need more information from the vendor. 76. What are the financial implications of meeting/ not meeting these SLAs? Penalties will be negotiated with AASLD post-award. 8

9 77. Do you expect any insurances/ bank guarantees to be provided by the vendor? Yes, the vendor must demonstrate financial stability and resources to engage in the delivery of the solicitation. 78. Do you have any policies for use of open source software in the final product? See Question Can the Vendor have resources outside US for implementation and production support after Go Live? See Question Extrapolate discrete data from an EHR - Would be nice to have more information on the input data. How many sources are expected? Are these sources dynamic? Data elements are described in Appendix A and Section 3: Scope of Work. Sources are described in the solicitation in Section 3, bullet i. 81. Convert narrative data to discrete data via Smart Notes or similar application - Kindly provide more details on the narrative data. Please see Question What would be the expected size and how many sources Support a national network with multiple sites to identify variations in care, high performing sites, and promulgate best practices - Kindly provide more information. Please see Question 20 and It would be nice to know the national network referred here Will a patient input data directly to the system through a secure login? Please see Section 3: Scope of Work bullet c. Also see HIPAA and NIST regulations regarding secure login. 84. Provide support for research to include research data needed for pharmaceutical industry - How is this planned? Do we have to provide API? Please see Question Support identified quality measures. - Are these quality measures static in nature or change frequently? The attached Quality measures have undergone extensive development and validation but may be subject to minor changes as the project moves forward. 86. During the requirement gathering phase, is there any onsite hours planned? Or can we work offshore with the help of video calls & screen sharing? This may be acceptable only in the requirements gathering and development phase provided the time zone of AASLD staff is accommodated by the vendor. However, during the production, deployment and hosting phases, all work must be U.S. based. 9

10 87. Under the Scope of Work: Section 3 item a. Do you mean to use extract vs. extrapolate. The example lab values, vital signs are discrete data and so we would extract these, conversely we would extrapolate them if we were asked to pull these items from a narrative? Can you clarify? Yes, the data will be extracted. 88. Under Section 3.2 population management: "lab results, Smart Notes and other sources uploaded monthly this is followed by b. limited lab data uploaded daily. What is the use case for this daily lab upload? An example use case would be Basic Metabolic Panel drawn after adjustment of diuretics for ascites. If such data were only uploaded monthly, it would not be actionable. 89. Also under 3.2. Is the tickler function providing reminders of items/goals that patients should have done, completed or achieved prior to a scheduled visit? Yes, that would be the purpose of the tickler function. 90. Section Is monthly billing required? What alternative are you proposing? 91. Under the Appendix 2 AASLD Requirements Matrix Item 2 Data Standardization: As AASLD will retain ownership of the system, it must be built using portable, commercially available software without use of vendor proprietary technologies. Our platform is proprietary but the data is owned by the customer, so if they want to move to another environment or use their own in-house developed environment they can do this but if our agreement is for 3 years then you can t access our software if you are not paying the support fees, we have an export function so that you can have your data at the end of an agreement. Does that make sense? I think we may need to discuss this. Please see Question Our firm has developed certain services and algorithms for utilization in registry projects and health message translation and transformation. Would a permanent non-transferable license of this technology to AASLD be adequate to meet the requirements of ownership specified in the RFP? It sounds like this solution may be adequate. The objective of AASLD is to develop and have a wholly owned system; however, you can present a business case related to your proposal of a non-transferable license with greater detail of what that entails and the limitations of the licensing agreement which will be considered during the evaluation process. 93. Regarding question 35, FedRAMP is a process for providing provisional-ato to IaaS, PaaS, and SaaS cloud products. Is it the intent of AASLD that the final provided solution (Registry) receive this accreditation, or merely that platforms used for hosting (Azure, AWS, etc.)? have ATO? As stated in the RFP, the system will interface with and collect / host data from the U.S. Veterans Administration. This relationship requires that all federal privacy and security standards governing patient data (HIPAA and NIST) are met for the application and hosting platform. 10

11 94. What level of FedRAMP Certification is Required? See Question 93 above as determined by NIST and HIPAA standards 95. Who will serve as AO to provide a final ATO approval for the Registry system? The U.S Veterans Administration will serve as the AO for the ATO 96. What level of support (digital service desk, phone support, 24-hours) is required once the system is in production. How many AASDL users (as opposed to patients or site users) will be supported? The initial Registry will not be considered a mission critical system. Use question 10 numbers as a basis for your estimate. As the Registry matures, any increasing levels of support will be negotiated with AASLD and follow the contract modification process. 97. Are there intended users beyond patients, site-based care providers, and AASDL users who will require ongoing support? No, not at this time 98. Is SmartNotes a COTS or AASLD-provided product? SmartNotes refers to customized end-users Smart Phrases to optimize clinician data entry functionality relating to the utilization of electronic documentation features within the EHR such as Epic, to include templates, SmartText, SmartPhrases and macros for auto-population. 99. And a follow-up to Question 33: 33. In connection with the privacy and security requirements listed, does the scope of work envisaged for this contract include the need for a Business Associate Agreement with any of the entities to be included? Yes, BAA s will need to be included. i. Is it expected that the vendor manages PMO activities of Business Associate Agreements, Service Level Agreements, Data Use Agreements, and Data Sharing Agreements process between AASLD and the source sites? Or is the thought that the vendor will be considered data owner during the 3-year contract period? AASLD will always be the owner of the data. The vendor as the contracted host and manager of the Registry will function as an agent for AASLD and responsible for managing the agreements outlined over the contract period. 11