Request for Proposals Data Warehouse/Data Analytics

Transcription

1 Request for Proposals Data Warehouse/Data Analytics Issued: November 9, 2012 Proposals Due: January 7, 2013 A Letter of Intent to Respond (LOI) to this RFP is required (See Section 4.1) NYeC RFP - Data Warehouse Data Analytics Solution Page 1 of 27

2 Contents 1. Purpose of Request for Proposals (RFP) Background on NYeC Current State Terms used within the RFP 8 2. RFP Scope Statement Proposal Instructions Proposal Contents Submission Details Timeline Submission Method Proposal Evaluation Criteria 25 Attachment A: Letter of Intent to Respond (LOI) 26 Attachment B: NYeC Master Services Agreement 27 NYeC RFP - Data Warehouse Data Analytics Solution Page 2 of 27

3 1. Purpose of Request for Proposals (RFP) New York ehealth Collaborative (NYeC) is seeking a vendor to help establish a Data Warehouse/Data Analytics (DW/DA) solution that can manage the information provided by the New York State (NYS) Regional Health Information Organizations (RHIOs), and to work with the RHIOs and their members to develop meaningful and actionable outputs such as reports, metrics, and analytics. In addition to the specific requirements for the solution described in this RFP, NYeC would like proposers to consider the following: Security and privacy concerns related to a repository of patient data Existing RHIO policies for data exchange established with their members RHIOs and their members preferences and restrictions on access to and sharing of data The variety and complexity of the data sources that feed data into NYeC that includes hospitals, EMR s, labs, etc. Scalability required for future needs (as additional RHIOs connect to the SHIN-NY) 1.1 Background on NYeC NYeC ( is a public-private partnership that serves as a focal point for health care stakeholders to build consensus on state health Information Technology (IT) policy priorities and to collaborate on state and regional health IT implementation efforts. Working collaboratively with the New York State Department of Health and other key constituents, NYeC is further developing the Statewide Health Information Network for New York (SHIN-NY), a statewide health information technology network that allows providers to share patient health information in a timely and secure manner, which will improve health care quality and reduce health care costs. Founded in 2006 by healthcare leaders, NYeC, an independent non-profit organization, receives funding from state and federal grants to serve as the nexus for HIT in New York State. NYeC facilitates interoperable health information exchange through the SHIN-NY, supporting the establishment of health information policies, standards and technical approaches and aiding stakeholders at the regional and local levels to implement such policies and standards. NYeC s goal is for patients and their healthcare providers, wherever they need and provide treatment in New York State, to be able to obtain fast, secure, accurate, and accessible information with appropriate protections regarding access to and use of the data. As more providers adopt health IT, there is a greater opportunity for sharing patient data between those entrusted with patient care. The creation, expansion, security and management of this network is an important undertaking for New York State; a connected health IT system in New York will offer better, safer, and faster treatment for all patients. As healthcare technology adoption grows, new policies must be written and technology expanded. An essential undertaking of NYeC is to develop and improve NYeC RFP - Data Warehouse Data Analytics Solution Page 3 of 27

4 policies and standards governing access to and uses of data, and ensure complete protections for patient privacy and security. 1.2 Current State RHIOs RHIOs participate in setting information policies through a statewide policy framework and governance process, implementing policies, and ensuring adherence to such policies with a mission of governing its use in the public s interest and for the public good to improve healthcare quality and safety and reduce costs. To fulfill this mission, RHIOs require commitment from multiple healthcare stakeholders in a geographic region including physicians, hospitals, long term care and home care providers, patients, insurers, purchasers and government. RHIOs are responsible for enabling interoperability through which individual stakeholders are linked together both organizationally and technically through the SHIN-NY in a coordinated manner for health information exchange and quality and population health reporting. Clinicians and other entities wishing to access data from outside their organization connect to a local RHIO to enable data exchange. The RHIOs across New York State will be connected to each other via the SHIN-NY technical infrastructure. New York State has 11 RHIOs that, together, cover the patient population for the entire state. The diagram below provides a geographic distribution of the 11 RHIOs. Recently, two RHIOs merged to form HEALTHIX. In New York State there are two types of technical models for the RHIOs; Service RHIOs and Connect RHIOs. A Service RHIO has its technical infrastructure and data managed by NYeC. NYeC is responsible for all technology associated with RHIO activities and manages upgrades and software enhancements. A Connect RHIO manages its technical infrastructure by itself. Once they are connected to the SHIN-NY they will be able to send data to and receive data from any other participating RHIO. At this time the focus of the data warehouse and related analytics services will be to support the Service RHIOs needs. NYeC RFP - Data Warehouse Data Analytics Solution Page 4 of 27

5 SHIN-NY Architecture The initial deployment of the Data Warehouse/Data Analytics (DW/DA) solution will utilize the data collected by the RHIOs using the Service Health Information Exchange (HIE) technical platform. It may eventually also incorporate data from the RHIOs using the Connect HIE platform to ultimately fully function as a state-wide Data Warehouse. Much of the data will be Admit, Discharge and Transfer (ADT) messages, as well as the clinical data elements captured as part of the Continuity of Care Document (CCD). These will come from a variety of providers including hospitals, ambulatory and primary care practices, physician offices, home care and long term care organizations that are connected to a RHIO. Data from the RHIOs will be the primary source of data to be loaded into the Data Warehouse and the RHIO participation agreements will dictate all access to and uses of the data. At a future date, these data may be augmented with other sources of data. NYeC RFP - Data Warehouse Data Analytics Solution Page 5 of 27

6 The Service RHIOs will act as data collection points using various interfaces from hospitals, ambulatory practices, home care services and long term care agencies. Data is cumulated and accessed via the platform API or IHE standard XCA (Cross Community Access) ESB (Enterprise Service Bus) from the Connect RHIOs. Below is a process diagram depicting a facility (hospital, practice) sharing/retrieving data with/from the RHIO. For facility interactions, they will retrieve documents using the PIX query to search for Patients and associated documents in the Document Registry. Documents are retrieved via XDS.b Retrieve. Facilities will provide Patient data and documents via the PIX Add, Revise, Resolve/Merge and either XDS.b or XDR Provide and Register. NYeC RFP - Data Warehouse Data Analytics Solution Page 6 of 27

7 NYeC Current Data Sources and Description For the RHIOs using the Service HIE technical platform, data are collected primarily with HL7 version 2.x interfaces with some version 3 CCD interfaces. The RHIO HIE platforms consolidate the data at the RHIO level. NYeC is working towards consolidating these data across RHIO platforms, which will be the initial source for the DW. There will also be a consolidated Master Patient Index across the Service RHIOs. Examples of data collected: Admit, Discharge, Transfer data including Patient Demographics, Encounter, Allergy, Problems/Diagnosis Discrete Result Information Discrete Labs and Vitals Documents/Reports - Radiology, Endoscopy, Discharge Summaries, Encounter Summaries, and Progress Notes Current Data Volumes The largest RHIO using the Service HIE technical platform in New York State has data on over 8 million patients and approximately 3 Terabytes (TB) of data for approximately 3 years of data collection. Currently these RHIOs have a combination of over 13.5 million patients total so the initial data volume should be approximately 4.5 TB of data. There will be analysis needed to determine the subset of data (if not all) that will be brought over to the Data Warehouse, including the data shared by all RHIOs statewide. Anticipated Growth The RHIOs using the Connect HIE technical platform will continue to add providers and collect data for additional patients at a growth of approximately 2 million patients per year, but we expect this to approach a limit and flatten out over time. Individual patient records will vary in the amount of clinical data available that becomes part of the DW. A list of the specific data elements to be included will be part of the initial discussions with the vendor chosen via this procurement. The RHIOs using the Connect HIE technical platform in their current state would add 16.5 million patients with a growth of approximately 1 million patients per year. NYeC anticipates that this will increase the data storage requirement. New York State has an estimated 9 million Emergency Room visits and 2.4 million inpatient admissions per year. NYeC anticipates the number of ambulatory electronic medical records systems contributing data through the RHIOs to the SHIN-NY to increase dramatically over the next 5 years. NYeC RFP - Data Warehouse Data Analytics Solution Page 7 of 27

8 Total Data Volume Estimate NYeC expects to incorporate a subset of the 4.5 TB of the RHIOs using the Service HIE technical platform, and to build to accommodate additional RHIOs in the future. Initial build should accommodate 30 million lives, and must support at least 6 TB of data. Anticipated Number of Users Standard report users An estimated 200 users initially within over 100 Hospitals that are members of the Service RHIOs. Ad hoc/custom report users - These will be key users from NYeC, each of the participating RHIOS and a few other major stakeholders. Initially 50 and growing to 100 over time. Term Clinical Document Architecture (CDA) Clinical Viewer Continuity of Care Document (CCD) Continuity of Care Record (CCR) Data Mart De-Identified Data 1.3 Terms used within the RFP Definition The Clinical Document Architecture (CDA) is an Health Level Seven International (HL7) XML-based markup that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA documents derive their machine-processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. CDA itself is not a specific document, but can be used to express many types of documents based on various use cases, such as Patient Summary (HITSP C32), Lab Report (HITSP C37), Encounter Summary (HITSP C48), History and Physical (HITSP C84). A CDA document can contain many data sections, all of which contain narrative text, and some of which contain structured data elements, some of which are coded. A web-based portal for access to RHIO clinical data. The RHIO members log in to the portal for access to patient data, available patient documents, consent details, medication details, alerts, messages, etc. The Clinical Viewer allows RHIO members to access patient information available across all the participating hospital and provider locations as per relevant consent and privacy policies. The Continuity of Care Document (CCD) is a joint effort of HL7 International and ASTM. CCD fosters interoperability of clinical data by allowing physicians to send electronic medical information to other providers without loss of meaning and enabling improvement of patient care. CCD is an implementation guide for sharing Continuity of Care Record (CCR) patient summary data using the HL7 Version 3 Clinical Document Architecture (CDA), Release 2. CCD establishes a rich set of templates representing the typical sections of a summary record, and expresses these templates as constraints on CDA. These same templates for vital signs, family history, plan of care, and so on can then be reused in other CDA document types, establishing interoperability across a wide range of clinical use cases. The Continuity of Care Record (CCR) is ASTM XML-based markup that contains the most relevant and timely core health information about a patient, and allows it to be sent electronically from one caregiver to another. It contains various sections such as patient demographics, insurance information, diagnoses and problem list, medications, allergies and care plan. These represent a snapshot of a patient's health data that can be useful or possibly lifesaving, if available at the time of a clinical encounter. A copy or subset of the DW that may be used by NYeC to support the use of data for analytics, reporting, or transformation purposes. In some cases, a data mart may be accessed by a customer/stakeholder to support specific analytics use cases, but would require privacy and security protocols consistent with user rights. NYeC expects to have a large variety of stakeholders with unique demands from the DW/DA solution. As a result, data within the DW will need to be stored in ways that are extremely sensitive to the privacy and security of patient data. We expect the DW to accommodate: 1) De-identified data that no longer meets the definition of Individually Identifiable Health Information (IIHI) according to HIPAA ( (a) and (b)) NYeC RFP - Data Warehouse Data Analytics Solution Page 8 of 27

9 Term De-Identified Health Information Electronic Medical/Health Records (EMR/EHR) Enterprise Master Patient Index (EMPI) Health Information Exchange (HIE) Health Information Technology (HIT) HITSP C83 HITSP C32 Meaningful Use Protected Health Information (PHI) Regional Health Information Organization (RHIO) RHIO Service Definition Personal Health Information that has been scrubbed so that it neither identifies nor provides a reasonable basis to identify an individual in a way that adheres to all applicable statutes and regulations. The electronic systems providers use to store patients' health information. These have replaced the paper records that providers traditionally used. An EMR/EHR contains data gathered from a variety of clinical services, including laboratory data, pharmacy data, patient registration data, radiology data, surgical procedures, clinic and inpatient notes, preventive care delivery, emergency department visits, billing information, and so on. The EMPI is an enterprise-level identifier for linked records from two or more source systems that each have their own distinct identifiers. EMPIs are generated at multiple hubs within the SHIN-NY: at the RHIO (or shared RHIO); at the source when a member is itself a system of individual facilities; and, eventually, statewide when RHIO-level data is linked. The DW solution will have to be able to work with EMPIs that change over time. The sharing of clinical and administrative data across the boundaries of healthcare institutions and other health data repositories. Many stakeholder groups (payers, patients, providers, and others) realize that if such data are shared healthcare processes would improve with respect to safety, quality, cost, and other indicators. The use of computers and computer programs to store, protect, retrieve, and transfer clinical, administrative, and financial information electronically within healthcare settings. HITSP CDA Content Modules (HITSP C83) describes a library of sections that can be combined into various CDA document types. In addition, a document type can include additional sections, even those not a part of it. So for example a CCD could add a Reason for Referral section added and still be a valid CCD. In addition, the sections in C83 can contain structured data, described as Entry Content Modules that are being assembled into a HITSP Data Dictionary that describes the data elements and the constrains (optionality, repeatability, and value sets) for each data element. HITSP Summary Document Component C32 (HITSP C32) is the patient summary document that describes the document content summarizing a consumer's medical status for the purpose of information exchange. The content may include administrative (e.g., registration, demographics, insurance, etc.) and clinical (problem list, medication list, allergies, test results, etc.) information. Any specific use of this Component 32 by another HITSP specification may constrain the content further based upon the requirements and context of the document exchange. This specification defines content in order to promote interoperability between participating systems. Any given system creating or consuming the document may contain much more information than conveyed by this specification. Such systems may include Personal Health Records (PHRs), EHRs (Electronic Health Records), Practice Management Applications and other persons and systems as identified and permitted. The American Recovery and Reinvestment Act of 2009 specifies three main components of Meaningful Use: 1. The use of a certified EHR in a meaningful manner, such as e-prescribing. 2. The use of certified EHR technology for electronic exchange of health information to improve quality of health care. 3. The use of certified EHR technology to submit clinical quality and other measures. Any information about health status, provision of healthcare, or payment for healthcare as defined in statute and regulation that can be linked to a specific individual. This is interpreted rather broadly and includes any part of a patient's medical record or payment history. A non-governmental organization that exists as a New York State not-for-profit corporation to enable interoperable health information exchange via a common Statewide Health Information Network for New York (SHIN-NY). A RHIO whose technical infrastructure and data is managed by NYeC. NYeC is responsible for all technology NYeC RFP - Data Warehouse Data Analytics Solution Page 9 of 27

10 Term HIE Technical Platform RHIO Connect HIE Technical Platform Stakeholders Statewide Health Information Network for New York (SHIN-NY) Subscribe and Notify Two Factor Authentication (TFA) Definition associated with RHIO activities and manages upgrades and software enhancements. A RHIO whose technical infrastructure is managed by the RHIO itself. Once they are connected to the SHIN-NY they will be able to send data and receive data to and from other RHIOs. There are two essential tiers of stakeholders at this time. Tier 1 includes the RHIOs and their participating health care providers who will contribute to and receive clinical information from the Warehouse pursuant to policies and procedures governing access to and use of the data. Tier 2 includes the New York State Department of Health, policy-makers, researchers, quality improvement organizations, public health departments, national agencies such as the Centers for Disease Control, and other entities that have an interest in reviewing, studying, and improving the care quality in the State of New York. A statewide health information exchange that allows for data sharing between clinicians and other entities within and across regions of New York State using standard interoperability protocols. The technical infrastructure will connect all RHIOs in order to allow clinicians and consumers to make timely, fact-based decisions that will reduce medical errors and duplicate tests and improve care coordination and the quality of care. Participating organizations connected to the RHIOs include medical facilities, ambulatory care centers, physician offices, labs, long term care centers and nursing homes. Subscription, event detection and notification services - An automated service that monitors a cohort of patients based on a predetermined list (panel subscription) or a set of inclusion and exclusion criteria (analytics subscription) for the occurrence of predefined types of events (event detection) and then delivers specific information regarding the event to a user or list of users through various means (notification service). As an example, a S+N system for frequent ED users ( 4 ED visits in 30 days): any patient with 3 or more ED visits across the HIE in the prior 30 days (analytics subscription) has a 4th visit within 30 days (event) and a notice is sent to a case manager at the current site in real-time via her EHR in-basket and via text message (notification). NYeC is in the process of procuring and implementing a Statewide Two Factor Authentication Solution based on National Institute of Standards and Technology(NIST) publication guidelines for Level 3 access. Some aspects of the DW/DA solution would require a strong authentication mechanism to verify user identity. NYeC expects the DW/DA vendor to be able to work with the Statewide TFA Solution vendor to implement the appropriate controls. NYeC RFP - Data Warehouse Data Analytics Solution Page 10 of 27

11 2. RFP Scope Statement NYeC envisions that the NYS healthcare community s needs for outputs from the DW/DA solution will continue to grow. As a result, NYeC wants to ensure that the foundations of the DW/DA are robust enough to accommodate the growth in user needs and is seeking a vendor that can provide the following outcomes: Design the architecture for the DW/DA solution that can accommodate existing needs and provide scalability. Provision but not purchase the hardware and software. NYeC is particularly interested in cost information for software to assess whether to purchase directly or through the vendor. Provide human resources to build, manage, and support the development and articulation of the DW/DA solution. Develop a foundational DW that can ingest data from our member RHIOs and is scalable to support structured and unstructured data from future sources such as labs, pharmacies, radiology department, etc. through the RHIOs. Provide terminology services to standardize data by mapping to existing standards before it is fed into the DW, and provide terminology services that allow data already existing in the DW to be mapped to new standards as they evolve in the future. Develop data marts based on the specific needs of the member RHIOs. Incorporate the industry standard terminology to allow for standardized outputs. Work with RHIOs and their participating stakeholders to gather the requirements for the outputs required from the DW. Design and develop the desired outputs from the DW based on stakeholder requirements. Support robust knowledge transfer processes for all aspects of the DW/DA solution. NYeC is expecting a comprehensive proposal from applicants that meets all requirements detailed in Section 3.1 of the RFP. NYeC understands that a comprehensive solution that meets all the technical and business needs stipulated in the RFP may require collaboration between a few vendors and will accept proposals that demonstrate a successful partnership between vendors. It must be noted, however, that irrespective of the subcontracting or partnership arrangement, NYeC requires one lead vendor to present the proposal and to bear all responsibility for the outcomes described in this initiative. NYeC RFP - Data Warehouse Data Analytics Solution Page 11 of 27

12 3. Proposal Instructions Proposers must respond to ALL items contained in section 3.1 below (A-J and subsections thereof), as well as adhere to the page limits. Every page in the proposal, including all appendices, exhibits and attachments, must be numbered consecutively. Each section must be clearly labeled with the title, letter and number of the section. Proposals should be single-spaced, contain one-inch margins, and be typed in Times New Roman 12-point font. 3.1 Proposal Contents The proposal contents must be organized in the following order: A. Cover Letter and Company Overview (1-page limit) a brief overview of the vendor s organization and contact information to direct future inquiries regarding the proposal. The cover letter must be signed by an officer authorized to bind the vendor to the terms of the proposal. B. Executive Summary (3-page limit) - a brief narrative that demonstrates the vendor s understanding of the services requested by this RFP and the scale and complexity of this initiative. The Executive Summary should demonstrate the strengths of the vendor s proposed approach, the key features that distinguish its proposed solution to meet the requirements and the major benefits it offers. If the vendor is collaborating with other vendors, identify instances where the prime vendor has worked with the proposed subcontractors. C. Approach for Data Warehouse/Data Analytics Implementation (10-page limit) a detailed description of the approach the vendor proposes to use to implement its solution, including detailed descriptions of all components of the effort that will be outsourced. 1. Please describe the software platform you will use for your data warehouse: a) If your proposal includes a relational database built in one of the industry standard software platforms (e.g., SQL Server, Oracle), please describe the industry-standard best practices in terms of referential integrity, constraints, index structure, normalization, etc. you intend to adhere to; b) If your proposal does not include a relational database and/or uses a nonstandard platform, please describe: Why the platform is a better fit for this warehouse than a more standard software platform; and How you will ensure that your warehouse achieves a comparable standard of data integrity, index structure, normalization, etc. 2. Describe the requirements gathering process for new outputs from the DW and to expand on existing requirements NYeC RFP - Data Warehouse Data Analytics Solution Page 12 of 27

13 3. Describe your Data Mart development methodology, overall system functionality and flexibility, including ease of use and support for loading multiple Data Marts. Include the process and frequency of the data refresh 4. Please describe your approach for integrating data from the variety of sources described above in section Describe your approach to error reporting and resolution, particularly where errors are resolved at different levels. a) Standard data consistency checks b) Standard data format checks c) Process for error resolution d) Internal data compatibility checks For example, if an upstream provider identifies a problem in a medical record and corrects it, how does this information get recorded in the warehouse? How will the warehouse identify that a record has been updated with new information? Will the warehouse identify and/or resolve incompatible conditions (e.g. pregnant and male, female with prostate cancer, etc.) How will the warehouse decide which record wins? e) Primary Care Provider attribution logic (if available). Traditional Medicare and other fee for service insurance options do not require a beneficiary to formally identify a primary care provider. Nonetheless, it is often possible to attribute a patient to a primary care provider base on claims/data volume or the frequency of visits, etc. NYeC is interested in learning more about this, and whether you have successfully addressed this issue in other situations. D. DW/DA Detailed Narrative (20-page limit) Provide a detailed narrative of your experience and approach for each of the items listed in the DW/DA Detailed Narrative section below. Each item in the table has a cross reference to specific Technical or Business Requirements provided in subsections 2 and 3 below. Vendor responses to the items in the table should address the identified requirements. Vendors are also encouraged to find areas of overlap between their responses and other Technical or Business requirements. 1. DW/DA Detailed Narrative: DW/DA Detailed Narrative Describe your experience building warehouses of similar size and complexity. Be sure to identify the number of data sources, the bulk historical load process, and the number of on-going data feeds. See Technical Requirements 1, 2, 3, and 4. Also address separately, Technical Requirement 27 Warehouse data access must support scaled access to types of reports, details, etc. Describe the process for creating categories of data access and whether there are any limits on the number of categories. See Technical Requirement 4, 8, 9, 20, 24, and 26. NYeC RFP - Data Warehouse Data Analytics Solution Page 13 of 27

14 3. DW/DA Detailed Narrative Describe your experience developing and maintaining technical infrastructure that adequately supports reporting functions in a manner that is consistent with scaled privacy and security rights. See Technical Requirements 4, 8, 9, 20, 24, and Describe your experience supporting cross platform compatibility. See Technical Requirement Identify the tools (Reporting, BI, and query) you support, and the one(s) you would recommend for the DW/DA solution described in your proposal. Additionally, describe your experience supporting both the use of ad hoc reports, standard (i.e. canned) reports, and data extracts. Where possible, include sample reports you have created, particularly where they are based on clinical data (include samples in an appendix to your submission). See Technical Requirements 5, 6, 8, 9, 11, 24, and 25. Describe your experience with and provide examples of engagements where you have developed comprehensive documentation and training to support the transition of operational functions to others. See Technical Requirements 10, 16, 17, 18, 19 and 21. Identify the tools you support for providing clinical concepts, and the one(s) you would recommend for the DA/DW solution described in your proposal. See Technical requirement 11. It is expected that the DA/DW solution you propose will be consistent with the latest terminology, messaging, and document standards as identified in Technical Requirements Describe your experience working with these standards, your approach for implementing these standards, and how you recommend structuring the DA/DW to support the evolution of the standards. Describe your experience developing data access protocols and operations (e.g. reports, queries, and data extractions), including comprehensive audit logs that conform to HIPAA requirements, and any other data elements that you have found important. See Technical Requirements 15, 20, 24, 25, and 26, adding or subtracting elements based on your experience and applicable statue. Describe your experience developing and implementing procedures to support linking and unlinking of records, for example, updates to an EMPI. See Technical Requirement 22. Describe your experience working with clinical data to develop a concept around supporting encounter-based care. See Technical Requirement 23. Describe your experience developing comprehensive training materials and documentation for reporting functions. This description should address the unique challenges of a train-the-trainer model. See Technical Requirement 21. Provide recommendations for the following phases and how Implementation services should be utilized: Requirements Gathering, Physical Environment build, Data Modelling, ETL implementation, OLAP Cube Design, Front End Development and Report Development. See Business requirements 1, 2, 3, 4. Describe work you have done supporting the development of governance policies, processes, and procedures. See Business Requirements 3, 5, 7. Describe your experience developing and deploying a strong data rights framework, particularly as regards efforts to prevent any data misuse, such as for fraud, marketing or other purposes. See Business Requirement 5 and 8. Describe your experience gathering requirements from diverse stakeholders and satisfying their data needs through reports, data feeds, etc. See Business Requirements 1, 2, 4, and 9. NYeC RFP - Data Warehouse Data Analytics Solution Page 14 of 27

15 DW/DA Detailed Narrative Describe your experience doing data mining and engaging in predictive modelling, particularly using clinical data. How have you validated your findings? See Business Requirements 6. Describe your approach to data acquisition such that the warehouse is capable of recording contributing source and producing reports by source. See Business Requirement 8. Sub sections 2 and 3 below list the Technical and Business requirements referenced in the table above. Vendors submitting proposals in response to this RFP are attesting that the DW/DA solution they are proposing is capable of meeting all these elements. 2. Technical Requirements: The technical requirements listed below have been organized in two sections. The first section titled Initial Deployment identifies those requirements that NYeC expects the vendor to meet within the first 5-6 months of project start. The second section titled Future Deployments identifies the requirements that NYeC would like addressed. Vendors must address all initial deployment criteria in the first 5-6 months; and may choose to address Future Deployments in this time frame as well, should it be advantageous operationally or functionally. In all cases, the proposed DW/DA solution must be CAPABLE of supporting future requirements Technical Requirements Initial Deployment The DW will initially be based on incoming data from participating RHIOSs and their members in the form of CCDs and ADT feeds o Bulk historical load from existing RHIOs o Interfaces to support loads form hospitals and RHIOs The initial build size of the warehouse must support at least 6 TB of data and be infinitely horizontally scalable. 3. Warehouse must support at least 200 standard report users and 50 ad hoc report users 4. Support for multiple data marts with different categories of privacy and security rights to be determined by NYeC and approved by DOH. For e.g. a CEO of a hospital may have a different category of access compared to a provider focused on research. o Please note that data in the DW is intended to be both Identified or de-identified in nature 5. Provide a compatible BI tool to support predictive modeling and other analytical purposes. 6. Provide, develop and design a web-based portal for canned and custom analytical reports. o Reports/data extracts should not be on live data 7. Support a web-based user interface through which data extractions can be requested. Must support web browsers: o Microsoft Internet Explorer versions 7 and later versions; o Mozilla Firefox versions , , and later versions; o Apple Safari versions and later versions; and o Google Chrome versions 14 and later versions. NYeC RFP - Data Warehouse Data Analytics Solution Page 15 of 27

16 Technical Requirements o Mobile Platforms (e.g. iphone/ipad, Android) 8. Provide a compatible reporting medium (e.g. Crystal Reports, XML) 9. Tools that allow authorized users to write queries against the database. Some super users must be able to run ad hoc queries directly against the data set. Please describe if this needs to be accommodated through a separate data store for performance or other reasons Create and maintain a data dictionary for NYeC, the RHIOs and their stakeholders, which includes: o Common language definition/description of each type of data element in the DW o Type and length of each data element (i.e. string, 14 character limit) o Relationship of each data element to other data elements o Origin of each data including site, source system and contact information for person responsible at site Format and translation/mapping history. Provide a compatible system capable of summarizing information into clinical concepts (e.g. Diabetes, Ischemic Heart Disease, ED encounter, hospital admission, medication error, etc.) for review and analytical purposes. System must be clinically validated and updatable as codes change and new information becomes available Support existing data document standards as well as their evolution and development. Supported standards may include: o o o HL7 Clinical (Medications/Radiology Results/Lab Results/Allergies/Discharge Meds/Discharge Summaries) HL7 CDA CCD: HITSP C32 Patient Summary Document HITSP C35 Lab Result Terminology HITSP C37 Lab Report Document HITSP C48 Encounter Summary Document (XDS-MS) HITSP C80 Clinical Document and Message Terminology HITSP C83 CDA Content Modules Support existing terminology standards as well as their evolution and development. Supported standards should include (but are not limited to): o o o o o o SNOMED LOINC ICD-9 ICD-10 RadLex RXNorm Support existing messaging standards as well as their evolution and development. Supported standards should include (but are not limited to): o o HL7 v2.x,v3.0 (ADT) IHE IT Infrastructure Integration Profiles (PIX,PDQ,XDS.b,XDR) 15. Audit logs that include, for example: o Time/date stamp o Length of time in record o Who accessed, and for how long. o Monthly/weekly/daily Transaction Volume 16. Provide and maintain a database schema with documentation adequate for an in-house DBA to understand the DW structure and provide support. NYeC RFP - Data Warehouse Data Analytics Solution Page 16 of 27

17 Technical Requirements 17. Provide full documentation of ETL process, custom programming, query logic and other design elements for final DW. The DW should support multiple refreshes of data intervals from once every 24 hours to every 15 min. 18. Provide a process for archiving and/or destroying data in conformance with NYeC data governance policies and subject to applicable federal and state laws Provide a back-up procedure, timeframe, and infrastructure requirements for the warehouse, including routine maintenance procedures. Store data securely in conformance with NYeC policies, HIPAA, and other relevant privacy laws and regulations (to be provided to vendor selected for this initiative). Prepare and deliver training using a train-the-trainer model on the reporting functions. Efforts should focus on supporting report access, definitions of variables, user experience, etc. Future Deployments System must be able to absorb updates due to linking and unlinking of records in the source systems. Support NYeC in developing a conceptual and operational model to define hospital and ambulatory encounter (i.e. an episode of care that may have multiple sequential or overlapping visit records) based on the data NYeC has at its disposal from participating RHIOs. 24. Access to data consistent with Two Factor Authorization vendor/requirements Data must be capable of being extracted consistent with rights status of the user, and must be capable of supporting variables as defined by the user. At a minimum, data must be available in the following formats: o XML Each row in the table is exported with an identifying XML element and each column entry is identified by an XML element that matches the column name. This format also includes a commented header documenting the SQL SELECT statement used to retrieve the data. o XML Structure Each row in the table is exported with an identifying XML element that matches the exported table name. This lets you preserve table hierarchies and relationships when you export from more than one database table. o CSV Each row is exported as plain text, with multiple delimiter and newline options. o HTML Each row is exported with HTML coding to form an HTML table that can be opened in a Web browser or incorporated into a larger HTML page. Excel Each row is exported directly to a Microsoft Excel spreadsheet file. o Support an automatic daily extract from the warehouse to each RHIO including real-time or nearreal-time data access by RHIOs. Support future growth and development of the warehouse to include items such as: o New data sources through the RHIOs a. scanned images b. Rx data from Surescripts/Other sources c. Lab data from Quest/LabCorps /Hospitals d. Other State data sources as they are identified o Non-structured formats like free text o Expansion of participating RHIOs Expansion of number of records 3. Business Requirements: The Business Requirements listed below are the major roles and functions NYeC expects to serve in the community. The vendor and the proposed DW/DA solution must support these outcomes. NYeC expects that the technical and infrastructural NYeC RFP - Data Warehouse Data Analytics Solution Page 17 of 27

18 framework to support all the Business Requirements listed below will be available by the end of Business Requirements Support the development of and have available reports that address NYS, NYeC and RHIO goals pursuant to policies and procedures governing access to and uses of the data. Have defined appropriate ETL logic though work with individual stakeholders such as RHIO leadership, hospital staff, providers, etc. Have a fully functioning data governance committee managed by DOH and NYeC. Support for the data governance process that DOH and NYeC will develop, specifically concerning the data quality checks and the resolution of data quality/consistency problems. NYeC has responsibility for defining the data standards, approved by DOH, that are enforced by vendor. However, vendor is expected to work collaboratively with NYeC to resolve data issues, for example, through data explorations. Recommendations for implementation service utilization including: o ETL Implementation o OLAP Cube Design Have developed and regularly produce dashboards for data summary. Examples may include: o Measures related to HEAL Grants o Meaningful Use Reporting o HEDIS or HEDIS-like measures o Physician Quality Reporting Initiative (PQRI) measures reporting o Public Health Reporting o Reporting on indicators for Medicaid and other public health insurance programs Have defined and deployed strong controls (including access and query rights) to prevent any data misuse, such as for fraud, marketing or other purposes 6. Ability to mine last 10 years or more of available data Have develop a minimum data set required from all connected nodes to facilitate "apples-toapples" comparison Identify records in the warehouse by contributing source, and to produce list of all available data to allow RHIOs and their participating members to know of the details Have developed and regularly produce benchmarks on performance and quality using available data that can be used by RHIOs and their participating members to assess their own performance E. Architecture (5-page limit) provide a diagram (along with the necessary descriptions) of the proposed architecture for the overall solution. 1. The response to this section should consider an architecture that can accommodate existing needs and provide the scalability to be a statewide solution. 2. This should also demonstrate how data will flow into the warehouses, and where the warehouse will perform various checks on data quality and integrity. 3. Vendor must provide a proposed schema and data structure. Diagram/description of the data architecture should be consistent with content from the cost worksheet(s). F. Hardware/Software Requirements (5-page limit) Please describe the hardware and software requirements to support this system. The proposal should describe the number and specifications of servers, memory, software licenses, terminals, etc. Furthermore, the description should clearly identify any component NYeC RFP - Data Warehouse Data Analytics Solution Page 18 of 27

19 described in this RFP particularly where it affects the business and technical requirements that will require NYeC expenditures above and beyond those included in this bid. Please note that the warehouse will be physically hosted by the NYeC Data Center. 1. Use the records count provided in the table in the Business and Pricing section below to provide details on the incremental hardware needs based on the number of records in the DW. a) Hardware specifications Application Servers Reporting Servers Database servers for minimal installation and how this can be scaled for a larger Data Warehouse. What are the inflection points in terms of scalability: Costs increases Beyond which the solution is no longer possible 2. Specifications for underlying database software. a) Define Database Platforms and Operating Platforms supported. Address requirements for scalability of the database. b) Specify whether database software will need to be procured separately or included as part of the Data Warehouse. 3. Vendor must identify items that are proprietary in nature. 4. Details on system software used for ETL, OLAP and Reporting. Specify any vendor software recommendations and whether they need to be procured separately or are included in the Proposal. G. Team (8-page limit) detailed overview of the vendor s and any proposed subcontractors team members who will staff the project if vendor is selected. This section should identify all key team members by name and role (NYeC may at its discretion choose to interview some or all key team members during the selection process). The response to this section should describe staff involved in building this system, creating interfaces, importing data, running data checks, and documenting procedures in support of the goal of a well-functioning, high quality DW/DA solution. Note: NYeC is seeking a vendor that is able to complete the Initial Deployment and a significant portion of the Future Deployment related development of the DW by the end of 2013; vendors should take this into account when considering the team size and makeup. 1. Organization Chart: In addition to identifying all team members (including any subcontractors) by name (for key members) and roles the chart should identify all roles, teams and governance groups that the vendor expects NYeC to provide for the implementation. NYeC RFP - Data Warehouse Data Analytics Solution Page 19 of 27

20 2. Name, role and brief experience of key members of the team (include key subcontractor positions). 3. Descriptions for ALL roles identified within the Organization Chart. 4. Resumes of all key members (to be included as an Appendix the 5-page limit for this section does not include resumes). H. Other Services (5-page limit) identify and provide details for other supporting services that will be provided for the overall implementation and maintenance. These include: 1. Help Desk Services: NYeC expects to provide Tier 1 support for reports and the Warehouse. Vendor is expected to support for Tier II/III. 2. Knowledge Transfer Services: Vendor must develop comprehensive database management documentation and be prepared to train NYeC regarding the operation and maintenance of the DW/DA solution to allow NYeC in assuming these functions in totality and without reliance on the Vendor. 3. Service Level Agreements (include standard SLA documents as an appendix) 4. Software Support (including upgrades and maintenance) I. Project Implementation Timeline (5-page limit) provide a timeline for the overall implementation. Identify the key tasks, milestones and deliverables within the timeline. Any assumptions used in developing the timeline should be identified in this section. If there are specific tasks that NYeC will be responsible for, they should be identified clearly within the timeline. (Assume a March 29, 2013 start date) Note: The Project Implementation Timeline should consider a strong desire at NYeC to complete significant development of the DW/DA solution by the end of J. Business Model and Pricing 1. Costs for all required components (including services and any other costs) must be included using the pricing table below. All areas are required to be addressed. If an area is non-applicable a reason must be provided as to why there is no price. If a cost for an area is included within other costs please mark the item as included and specify in the Comments column where the cost is covered. 2. In the Hardware/software table, vendors should articulate specific hardware/software requirements along with pricing and unit requirements. NYeC expects to negotiate and purchase items independent of vendor, but reserves the right to purchase through the Vendor if price and/or support is advantageous. 3. Vendors must indicate if their proposed solution requires collaboration with any other entities not included as subcontractors and must clearly state if these are ongoing or new relationships. 4. Vendors must clearly identify components of the DW/DA solution that are proprietary in nature. NYeC RFP - Data Warehouse Data Analytics Solution Page 20 of 27

21 5. Vendors may add additional rows within the table as required. This includes adding sub-components to an existing line to provide a more detailed breakdown of a cost or adding new rows to identify a cost component not identified in the table. Please be sure to indicate the creation of a new sub-component or row within the Comments column and to provide an explanation for why it was included. 6. Vendors should identify assumptions about the project in their cost proposal. In particular, vendors should define assumptions for various bulk historical loads (complex, moderately complex, and simple). Solution Item: Year 1 Year 2 Year 3 Year 4 Year 5 Warehouse Development/Deployment Planning Requirements (e.g. discussions stakeholders, development of data standards, discussion(s) with data sources about the extract we should receive, etc.) Design Development Testing Implementation Other: Please Specify Regular DW Maintenance Bulk Historical Loads. 1 complex 1 moderately complex 1 simple Analytic Solution Development/Deployment Planning Requirements (e.g. discussions with stakeholders, articulation of needs, data requirements, etc.) Design Development Testing Implementation Other: Please Specify Regular Report Production Other: Please Specify NYeC RFP - Data Warehouse Data Analytics Solution Page 21 of 27

22 Hardware/Software Requirement (Please specify product, manufacturer, technical requirements, and/or version as appropriate) Units Required example: Oracle DB v Please specify unit (e.g. users, servers, etc.) licenses (1/box) Purpose: Build/Maintain/Both both If the item will not be required long-term, over what term will it be needed? COMMENTS e.g.: Given your desire for scalability, you should explore an enterprise license which will allow you to use this for up to XX boxes. NYeC RFP - Data Warehouse Data Analytics Solution Page 22 of 27

23 7. Financial Report - Due to the breadth and scope of the project, the proposer is required to submit its most recent audited financial statement and management letter. In the event that the proposer is a wholly owned subsidiary or is otherwise a subordinate of another entity, the most recent audited financial statement and management letter of the proposing company is expected- not that of the parent company. 8. In-Kind Service Details: Any In-Kind services and the value of those services should be noted in this section. In-kind services are those services provided at no cost yet have an intrinsic value or worth. Descriptions of what is included in the cost including support model and hours of coverage must be noted. If your cost excludes certain fees or charges, you must provide a detailed list of the exclusions with a complete explanation of the nature of those fees. While In-Kind services are not a requirement of the RFP, proposers are encouraged to include them since they demonstrate to NYeC the proposers commitment to providing the highest value for the public funds being used for this effort. NYeC RFP - Data Warehouse Data Analytics Solution Page 23 of 27

24 4. Submission Details All communication regarding this RFP must be in writing and addressed to: The subject line of all communications must include: DW/DA Proposal and your company name Timeline RFP Issued: November 9, 2012 Letter of Intent to Respond due: November 19, 2012; 11:59pm EST Written Questions due: November 19, 2012; 11:59pm EST Written Responses to Q&A Available no later than: December 7, 2012 Proposals Due: January 7, 2013; 12noon EST Requested Vendor Demonstrations/Presentations Held: February 14-15, 2013 Award Notification: February 22, 2013 Anticipated Contract Start Date: March 29, 2013 In order to effectively manage the process, NYeC is requiring all interested vendors to submit a Letter of Intent to Respond (LOI) to [email protected] no later than 11:59pm EST on November 19, LOIs must contain the address of the vendor s contact person. Submitting an LOI will not bind a vendor to submitting a proposal, but will be used to notify the vendor of any changes and any additional information related to this RFP. (See Attachment A - Letter of Intent to Respond). All questions must also be submitted via to [email protected] and must be received by 11:59pm EST on November 19, Responses to questions received by this deadline are expected to be posted on the NYeC website no later than December 7, Proposers are advised that the Authorized Contact Person for all matters concerning this RFP is the RFP Contact address. Proposers may not contact any NYeC staff, NYeC board members, the NYS Department of Health staff, NYC Department of Health and Mental Hygiene staff, or any other stakeholder regarding this project in the period between the issue of this RFP and the notice of award. Any oral communication will be considered unofficial and non-binding with regard to this RFP and subsequent award. 4.2 Submission Method Proposal submission method ( ) to: [email protected] Include DW/DA Proposal and your company name in the subject line Format: PDF or MS Word NYeC RFP - Data Warehouse Data Analytics Solution Page 24 of 27

25 4.3 Proposal Evaluation Criteria Proposals will be evaluated based on the following criteria: Experience in successfully supporting warehouse builds similar to the one required for this DW/DA solution Comprehensive approach to this DW/DA solution Ability to meet the technical and business requirements in a timely manner Scalability of the proposed solution Experience and commitment to knowledge transfer Experience and skill sets of the proposed team Relevant experience for similar efforts in healthcare Financial strength of the company Cost and In-Kind Services Ability to adapt and grow with the project NYeC RFP - Data Warehouse Data Analytics Solution Page 25 of 27

26 Attachment A: Letter of Intent to Respond (LOI) Instructions The LOI form must be completed and returned to notify NYeC that you intend to respond to this Request for Proposals (RFP). Any information relating to this RFP will be ed to the person designated as the point of contact (POC) on this form. the completed form to Letter of Intent to Respond Our organization intends to respond to the NYeC Request for Proposals for the DW/DA. Organization Name: Address: POC Name: POC Title: POC POC Telephone: NYeC RFP - Data Warehouse Data Analytics Solution Page 26 of 27

27 Attachment B: NYeC Master Services Agreement A sample NYeC Master Services Agreement (MSA) is provided separately, which vendors should review carefully. The selected vendor will be expected to execute the MSA in substantially the form attached. Except for provisions that are not applicable to the Scope of Work or an agreement containing substantially similar provisions, NYeC will not consider changes to the MSA. NYeC will not engage in protracted contract negotiations. NYeC RFP - Data Warehouse Data Analytics Solution Page 27 of 27