Overview and Objective - CRISP – Chesapeake Regional ... · Web view2016/06/22 · CRISP and our...

Medicare Data Vendor: Data System and Provider Analytics

Engine Request for Proposal

RFP Issue Date: June 22, 2016

Proposal Due Date: July 29, 2016

Chesapeake Regional Information System for our Patients

7160 Columbia Gateway Drive, Suite 230

Columbia, Maryland 21046

Medicare Data Vendor: Data System and Provider Analytics Engine - RFP

1. Overview and ObjectiveIn this Request for Proposal, the Chesapeake Regional Information System for Our Patients, Inc. (CRISP) seeks proposals for solutions from vendors with a proven ability to deliver actionable Medicare data reports to health care providers. CRISP aims to contract with one or more vendor partners to 1) build/provide a Medicare Data System and 2) build/provide an Analytics Engine. The Medicare Data System is the data system that will land, transform, and enable consumption of Medicare data. The Analytics Engine will provide actionable information to end users, mostly health care providers.

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.

A. CRISP Overview and BackgroundCRISP is a sustainable, dependable, and well-utilized regional HIE serving health care providers in Maryland and the District of Columbia. CRISP, which is a private entity chartered and governed to pursue health IT projects best pursued cooperatively, is the state designated HIE for Maryland. We are an independent not-for-profit 501(c)3 membership corporation. Our participants include each of the 48 acute general care hospitals in Maryland and most hospitals in the District of Columbia, as well as numerous other facilities and providers of care.

i. Care Coordination Workgroup and Integrated Care NetworkAs the State Designated HIE for Maryland, CRISP is increasingly acting as a provider of state-level infrastructure to support population health care initiatives, especially 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). Detailed next steps leading toward implementation of an Integrated Care Network (ICN) infrastructure were outlined in a report issued by the Care Coordination Workgroup, convened to provide advice to the Health Services Cost Review Commission (HSCRC) on accelerating strategies to meet the goals of the modernized hospital payment system.1 This report outlined the need for individually identifiable Medicare data to support provider care coordination efforts. Specifically, data is needed to support the identification of individuals who may benefit from care coordination and then to coordinate and manage their care. In addition to securing a vendor to receive and prepare reports for providers, CRISP was charged to further develop and implement a broad range of shared IT infrastructures described in the Care Coordination Report.

At the same time there is increasing recognition that as a result of the State’s All-Payer Model, health systems and hospitals need aggregated utilization data that enable these organizations to monitor their performance in terms of both quality and utilization and to be able to make changes in strategic priorities and allocation of resources based upon their meeting defined performance targets. 1 http://www.hscrc.maryland.gov/documents/md-maphs/wg-meet/cc/Care-Coordination-Work-Group-Final-Report-2015-05-06.pdf2 http://www.hscrc.maryland.gov/documents/commission-meeting/2014/05-14/post/04-hscrc-data-infrastructure-report-to-commission-recommendations-on-data-requirements-for-monitoring-the-all-payer-model-2014-05-14.pdf

Chesapeake Regional Information System for our Patientswww.crisphealth.org

2

http://www.hscrc.maryland.gov/documents/commission-meeting/2014/05-14/post/04-hscrc-data-infrastructure-report-to-commission-recommendations-on-data-requirements-for-monitoring-the-all-payer-model-2014-05-14.pdf

http://www.hscrc.maryland.gov/documents/commission-meeting/2014/05-14/post/04-hscrc-data-infrastructure-report-to-commission-recommendations-on-data-requirements-for-monitoring-the-all-payer-model-2014-05-14.pdf

http://www.hscrc.maryland.gov/documents/md-maphs/wg-meet/cc/Care-Coordination-Work-Group-Final-Report-2015-05-06.pdf

http://www.hscrc.maryland.gov/documents/md-maphs/wg-meet/cc/Care-Coordination-Work-Group-Final-Report-2015-05-06.pdf


Subsequent to the Care Coordination Workgroup’s report, there has been further development of potential federal and state approaches for care coordination and alignment among different health providers. For example, CMS has recently announced a Comprehensive Primary Care program. The state has been working on an amendment to the All Payer Model contract to provide federal approvals for care delivery improvement activities and alignment approaches focused on hospital episodes and complex and chronic care management. These strategies require Medicare data for planning, ongoing operations and oversight. The vendor selected for this procurement would ensure the assembly of Medicare data reporting on behalf of Maryland hospitals and other providers as required by this Care Redesign Amendment to the All Payer Model.

ii. Medicare Data Acquisition GoalsFollowing the recommendations of the Care Coordination Workgroup, the HSCRC has engaged CRISP to implement infrastructures and plans described in the report. A major area of focus is the acquisition of Medicare fee-for-service (FFS) data for the State of Maryland.

The State is looking to Medicare data for several major purposes:

1. Patient Identification: Support provider care coordination efforts through the identification of individuals who may benefit from care coordination, including risk stratification strategies.

2. Care Coordination: Support provider care coordination efforts by providing comprehensive, custom patient-level data, identifying gaps in care based on geographies, enrollment, attribution or other techniques.

3. Performance Measurement: Support efforts to measure the goals of the All Payer Model and monitor the progress of strategies to achieve its goals.

4. Support Developing Alignment Initiatives: Deliver information to providers for active care coordination, episode analysis, and performance information under developing care improvement programs. Maryland providers are and will be operating in financial environment requiring similar data needs as ACOs or Medicare Advantage providers. CMS has also outlined requirements for Chronic Care Management and Comprehensive Primary Care.

5. Reporting and Oversight: Provide required information to the HSCRC for monitoring performance, administering payments, and evaluating effectiveness for programs developed in conjunction with the State’s All-Payer Model, including delivering information based on geography, enrollment, or other designation techniques, as defined by payment or monitoring polices. While the state currently obtains Medicare data in Medicare’s Chronic Condition Warehouse, it is envisioned that some of the ongoing efforts to utilize the data would be transitioned to the CRISP environment, consistent with HSCRC’s hospital data strategy.2

Maryland has been working closely with CMMI to develop the approach through which Medicare data for all Maryland beneficiaries can be made available to the State for these purposes. As CMS clarifies and solidifies Maryland’s data pathway, including any specification of file formats (e.g., LDS, CCLF, COBA), CRISP will issue updates to this RFP via our website.

All approaches will need to be developed in compliance with all federal and state regulations governing the protection of sensitive healthcare data.

2 HSCRC is focused on producing data it needs in an environment where hospitals and other appropriate providers or parties will be able to have access to appropriate data outputs. This will optimize the cost of data production, reduce investments by hospitals and others to obtain information that is already being produced for HSCRC, and reduce reconciliation efforts between data sources.


3


B. Engagement ObjectiveTo support State efforts, CRISP is requesting proposals from vendors with the intent to contract with one or more vendors. We seek long-term technology partners that we believe are the best in class for providing effective and efficient solutions. We seek partnerships that benefit and grow both organizations while delivering excellent value to our users.

Vendors may partner or provide RFP responses with partial solutions. Based on these RFP responses, CRISP will ask selected vendors to provide in-person demonstrations/proofs of concept. CRISP will then issue final specifications for final bids among selected vendors.

Under this engagement, the vendor will be responsible for developing the components discussed below across several phases of effort (in total referred to as ‘the solution’ or ‘Medicare Data Solution’). In addition to demonstrated technical knowledge, CRISP is seeking a vendor partner that brings proven Medicare data competency, including a deep understanding of Medicare reimbursement and policies. CRISP will rely on the vendor’(s) expertise in finalizing the Medicare Data Solution design. Therefore, a vendor minimum qualification for response to this RFP is at least three deployed Medicare data solutions (of similar size and complexity as this engagement). Please note that the approximate number of Medicare Beneficiaries in Maryland in 2015 was 1 million. As discussed later in this RFP, the optimal system will have the capable of growing to at least the size of the entire state of Maryland population of 6 million.

Figure 1 provides our conceptual model and Figure 2 suggests a table of deliverables for the first year of effort. This model is not intended to prescribe a required architecture but rather create a framework for articulating and segmenting the analytics design pattern such that proposed functionality and solutions may be equivalently evaluated. Based on expertise and experience, especially experiences in Medicare data solutions, vendors may provide RFP responses with innovative solutions that fall outside of this conceptual model and timetable while meeting CRISP’s objectives. We discuss the components of the conceptual model in more detail in the following sections.

Figure 1: Medicare Data Solution Conceptual Model


4


Figure 2: Table of Phases of Contract: Year One

Phase / Timeframe

Proposed Major Deliverables

Phase 1:

Project Initiation

- through -

Month 3

Develop and deliver a Medicare Data System, with the ability to land, transform, and enable consumption of data

Develop and populate an Analytics Engine(s) to:o Provide/develop and deliver a hospital information delivery product and

make this product available to hospital providers o Make available limited data to hospitals and HSCRC for administration of

alignment programs and ensure the assembly of Medicare data reporting on behalf of Maryland hospitals as required by the Care Redesign Amendment to All Payer Model. For example: track total cost of care, in multiple aggregations such as geography or hospital designation.

Phase 2:

Month 4

- through -

Month 9

Refine and provide ongoing operational support to the Medicare Data System Further develop the Analytics Engine(s) for:

o Refinements and ongoing support to the hospital information delivery product

o Allowances for certain data extracts for connecting to a provider’s system, as permissible.

o Additional providers and settings, such as ambulatory physician practiceso Data and analytics related to program administration for the HSCRC and

other program administration entitieso Analytics for hospitals and HSCRC administration/ monitoring and

integrate these analytics with other CRISP tools, with CRISP staff

Phase 3:

Month 10

- through -

Month 12

For the Medicare Data System:o Refine and provide ongoing operational support to the Medicare Data

System o Conduct training and knowledge transfer, with documentation, to allow

for CRISP to operate the Medicare Data System Continue to provide/develop and deliver reporting capabilities to providers and

other users, while refining and providing ongoing support for existing information delivery products

Phase 1: Medicare Data System and Hospital Provider Information Delivery Product By the end of Phase 1, the vendor will have established:

1. Medicare Data Solution to land, transform, and enable consumption of Medicare claims data, 2. Analytics Engine to provide Medicare data/information/reports to hospitals and the HSCRC.

The vendor will have a hospital information delivery product (“Analytic Set #1”) operational and delivering product to hospital users. The vendor will also be providing limited data for HSCRC administrative and


5


monitoring functions, which will also be available for hospital users (“Analytic Set #2”). CRISP anticipates three months for this phase of engagement.

A) Medicare Data SystemTo provide ongoing information to a variety of users, a core component of this engagement is for a vendor to develop a Medicare Data System. By the end of the engagement, CRISP anticipates having the option to control and operate the Medicare Data System environment. CRISP will determine at that time if system administration/operations will be transferred to CRISP staff or if CRISP will further engage a vendor to operate and maintain the Medicare Data System.

CMS file format remains to be determined. For RFP response development, we have established several scenarios:

1. CCLF data package provided to ACOs and other innovation programs. This would include monthly Part A/Part B/Part D/Beneficiary files for Maryland beneficiaries from calendar year January 1, 2013 going forward. Assume monthly update files that may include data to be appended, changed, deleted.

2. Limited Data Set (LDS) Final Action Claims. Assume quarterly updates and 100%, not 5% random samples, where possible for Maryland and adjacent Medical Trading Areas.

3. As an alternative, CRISP would also like to understand the cost and feasibility of using a set of X12 files (sourced by Maryland providers instead of Medicare). Assume this would be X12 837 claims and X12 835 remittances, as well as a periodic load of X12 834 data to manage enrollment and attribution data. In the X12 model, there would be multiple X12 files (likely copies of the files that submitted / received daily from payer or clearinghouses). Assume all X12 files are in 5010 format (and would be preprocessed as needed to be of a common format and layout).

Conceptually, the Medicare Data System should perform the following functions:

Landing Zone – a mirror image of source data landed to provide a staging area for transformationThe solution should land Medicare data in a secure repository where it is accessible for desired downstream uses. While this procurement requires a solution for Medicare data, the solution should have the capacity to land and incorporate other datasets, such as Maryland’s HSCRC hospital inpatient and outpatient case mix data in the future.

The vendor must design and specify the required hardware, software, and connectivity necessary to host and operate the proposed solution. While CRISP seeks vendor guidance on data hosting solutions (e.g., CRISP self-hosted environment on-premise, a vendor hosted environment, a cloud setting, a hybrid environment, etc.), at the conclusion of the procurement, CRISP anticipates having the option to control and operate the Medicare Data System environment.

Transformation Zone – the normalized, source of truth from which data marts are spawned for analytic purposesData transformation should integrate multiple data sources as appropriate and normalize the data into consistent, standard elements according to healthcare industry standards and data management best practices. Effective master data management, security and privacy, and data quality rules processing are essential to this process. The vendor must be able to disambiguate various reference data elements, including provider or patient identity, in order to match claims data with identities maintained in the CRISP Master Patient Index (MPI) and apply CRISP opt out indicators. Successful data transformation will take into account potential policy and industry changes that affect the underlying meaning of the data; for example,


6


effective dating vocabularies and code sets enabling ICD-9 to ICD-10 codes comparisons for longitudinal analysis.

CRISP will rely on the vendor’s expertise and experience to enhance the Medicare data with value-added information not obtained in CMS’ data. These may include values such as APR DRGs/CMS DRGs, product lines, classification systems, risk scoring, and episode groupers.

While the scope of this engagement concerns Medicare data, CRISP’s most desired solutions will provide for an extensible transformation zone allowing later addition of other datasets.

Consumption Zone – data marts aggregated and organized by subject area for self-service analytics and populating analytics enginesThe consumption of data may occur through several methods. CRISP does not have a predefined solution for downstream users to access analytic products. Data and reports should be consumable through custom inquiries, extracts, visualization tools, or other proven methods and interact with the Analytic Engine(s). Data must be accessible for extraction from the database in a common format (for use by CRISP or HSCRC, if needed).

Data Integration – functionality enabling the modeling and secure flow of timely, auditable, and accurate data across the entire lineage of the Medicare Data System The data integration components must provide the following functionality:

Multiple format and source integration Extensible data model for future landing, transformation, and consumption needs Security and privacy protocols Audit capabilities Metadata management Master data management including the patient domain Data quality rules processing

B) Analytics Engine(s) Phase 1 requires the vendor to provide/develop/apply an Analytics Engine(s) to generate a suite of reports to hospital providers and to provide data for analytics to the HSCRC.

Analytic Set #1: Program Operations - Hospital Information Delivery: The vendor will provide/develop and deliver hospital reports to support care coordination use cases. The reports should be based on industry best practices and reporting suites used by other providers engaged in performance- and outcomes-driven payment mechanisms, such as reports delivered to Accountable Care Organizations or Medicare Advantages customers. The specifications and logic should be pre-defined to the extent possible to diminish the customization required by CRISP and providers.

Examples of reports we envision in this deliverable include at least those listed below. CRISP will rely on the vendor expertise to determine the suite of information most relevant and actionable for providers, including which enhanced values should be included in the reporting (e.g., risk stratification, episode grouping):

o $PMPM with the ability to segment/pivot/filter. Extensive capabilities to produce more detailed views of data is critical. The vendor should address its approach to cost and utilization segmentation.

o Utilization reports, including Admits/1000, CMA Admits/1000, ED/1000, Re-admits/1000, Specialists and PCP/1000., etc.


7


o Population by diagnosis, chronic diseaseso Length of stay analyticso Potentially avoidable utilization and costs3 (as defined by HSCRC)o Gaps in health and care within a longitudinal view of care per patient and per population

segmento Quality measurement (initially in line with NCQA, AHRQ, and other national standards, and

later for Maryland-specific alignment programs)o Episode reports o Total Cost of Care, including ongoing analysis of changes in cost by segment, per beneficiary,

risk adjusted comparisons, etc.

Analytics Set #2: Program Oversight - Data for hospital and HSCRC Administrative and Monitoring Functions: In Phase 1, the vendor will produce a limited number of administrative reports for hospitals and HSCRC administrative and monitoring of total cost of care and potentially other uses under Maryland’s All Payer model including ensuring the assembly of Medicare data reporting on behalf of Maryland hospitals as required by the Care Redesign Amendment. Data specifications will be determined early in the Phase of effort, but it can be assumed to be a subset of those in Analytics Set #1.

Phase 2: Ongoing Support and Further Development of the Analytics Engine(s)In Phase 2, the vendor will support and refine ongoing functions from Phase 1, while further developing the Analytics Engine(s) to reach more types of providers, provide greater information for program monitoring, and work with the CRISP team to develop integration strategies with existing HIE services. CRISP anticipates six months for this phase of engagement.

A) Refine Operations of the Medicare Data System During Phase 2, the vendor’s team will maintain and refine the Medicare Data System. The vendor will work closely with CRISP during this phase of effort. The close working relationship will provide CRISP’s team an understanding of the System’s operations. Support may include items such as:

User credentialing and connection with CRISP’s unified landing page Troubleshooting Downtime investigating Validating data and results Metadata reporting Tools and techniques for data integration Data protection/security and encryption

B) Expand the Analytics Engine(s) to Provide Information Delivery Products for Ambulatory Practices and Other UsersIn Phase 2, the vendor will continue to refine the hospital information delivery product deployed in Phase 1 and expand analytics information delivery to additional users. Throughout the engagement, CRISP will gather feedback from staff and stakeholders and provide guidance for potential refinement and development of reporting, capabilities, and tools. CRISP would work with the vendor to assess and prioritize work in this Phase.

3 http://www.hscrc.state.md.us/documents/HSCRC_Initiatives/GBR-PAU/Components-of-Potentially-Avoidable-Utilization.pdf


8

http://www.hscrc.state.md.us/documents/HSCRC_Initiatives/GBR-PAU/Components-of-Potentially-Avoidable-Utilization.pdf

http://www.hscrc.state.md.us/documents/HSCRC_Initiatives/GBR-PAU/Components-of-Potentially-Avoidable-Utilization.pdf


Analytics Set #1: Hospital Information Delivery Product: The vendor will provide refinements and ongoing support to the hospital information delivery product. Allow for certain data extracts for connecting to a provider’s system, as permissible by CMS.

Analytics Set #2: Data for HSCRC Administrative and Monitoring Functions: As the Maryland-specific alignment programs become defined and evolve, analytics will be required for program monitoring and administration by hospitals and the HSCRC and other program administration entities. Data will be in a form to allow HSCRC to conduct analytics. HSCRC and CRISP will determine data specifications early in the Phase of effort.

Analytics Set #3: Information Delivery Product for Other Providers: Ambulatory practices and other non-hospital providers will require information as they work with hospitals to provide population-based care. The vendor will provide/develop and deliver reports to support care coordination use cases. This information delivery model may be an extension of the hospital information delivery product or a separate, while aligned, product/engine.

Analytics Set #4: Information for CRISP Functions: The vendor will provide analytics for CRISP administration/monitoring of the solution through metadata. Also, CRISP intends to integrate Medicare data with other CRISP tools. The vendor will work with the CRISP team conceptualize integration strategies.

Phase 3: Ongoing Support and TransitionThe vendor will provide refinements and ongoing support of the Medicare data solution and, if required by CRISP, provide for the formal transition of the Medicare Data Solution to the CRISP team. Successfully providing for the transition of the ongoing system support does not preclude the vendor from establishing a long-term, mutually beneficial relationship with CRISP.

TransitionNearing engagement month 10, CRISP will determine if it is advantageous to transfer solution operations to internal CRISP team members or if CRISP intends to issue a continuing contract for ongoing operations support. If CRISP determines to transfer the solution to internal operations, the vendor will provide training to CRISP team members in ongoing operations. The vendor will also provide full documentation and knowledge transfer to enable CRISP to maintain service without interruption.

Integration into Ongoing and Future CRISP Data ArchitectureCRISP intends for the Medicare data solution to work within CRISP’s current and future design architecture. As such, we intend for the vendor in this award to work collaboratively as part of our CRISP team as they develop and implement the Medicare Data Solution. In addition to the efforts to be awarded in this RFP, CRISP is seeking long-term partners for other ongoing and future data engagement efforts.

Again, CRISP welcomes vendor partnerships (including vendors with partial solutions to be partnered with other vendors) and innovative solutions outside of this RFP conceptual model framework.


9


2. RFP Process and Submission Instructions

A. Contract TypeCRISP anticipates issuing a fixed price contact with scope in alignment with specific scenarios in Section 4 (the Financial Proposal section). We have also requested labor rates by category rates for any necessary add-on work to meet the scope of this RFP (for example, for customized or extended services).

Vendors are asked to explain their pricing models in Section 4 and are welcome to propose and justify other contract types if deemed appropriate. CRISP will issue full contract specifications as part of the final procurement process as outlined in the RFP timeline below.

B. RFP Process OverviewThis RFP requires vendors to set forth their Medicare Data Solution(s) and costing information (including licensing models and fees, typical implementation costs, and labor category rates). Based on responses, CRISP will select multiple vendors for in-person interviews and solution/product demonstrations and conduct reference reviews. Following the interviews, CRISP will issue refined specifications and ask selected vendors to provide a final response and financial bids.

CRISP expects to issue the final vendor award approximately two months of issuing this RFP.

i. RFP TimelineFigure 3, the Procurement Timetable, represents CRISP’s best-estimated schedule for this procurement. All dates, including the contract start date are subject to change.

Figure 3: Procurement Timetable

Event Approximate Dates Notes

CRISP Issues RFP June 22, 2016 Any proposal updates will be issues on the CRISP website

Bidders Conference June 29, 2016 1pm ET

WEBEX LINK

Teleconference: 1-650-479-3208

Access code: 299 606 327

Intent to Respond July 8, 2016 Email to Laura Mandel [email protected]

Clarifications and Q&A July 15, 2016 Ongoing then finalized on CRISP website

Vendor RFP Responses Due to CRISP July 29, 2016 Email proposals by 5pm ET to Laura Mandel [email protected]

Vendor Interviews and August 15, 2016 CRISP will contact selected bidders to Chesapeake Regional Information System for our Patients

www.crisphealth.org

10

mailto:[email protected]


https://crisphealth.webex.com/crisphealth/onstage/g.php?MTID=ea580c7ed938aaae8ed3ca9129c0d4544


Demonstrations, Reference Review schedule interviews

CRISP Issues Final Specifications August 26, 2016 Final specifications emailed to selected bidders

Vendors Submit Final Response and Financial Bid/BAFO

September 2, 2016 Responses submitted to Laura Mandel [email protected]

Vendor Selection and Contracting September 9, 2016

CRISP will work in good faith to provide adequate and equal opportunity for all participating vendors. However, CRISP reserves the right to adjust or modify the Procurement Timetable at any point, as deemed necessary, in the process.

ii. Bidders Conference and Requests for ClarificationCRISP will hold a bidder’s conference on June 29, 2016 at 1pm ET.

In addition, CRISP will routinely answer and post to our website questions and answers related to this procurement. It is assumed that all Q&A will be finalized by July 15, 2016. Please email questions and requests for clarification to: Laura Mandel [email protected].

iii. Vendor PartnershipsCRISP welcomes proposals developed by multiple vendors in a partnership for the solution. The lead partner should submit the joint RFP response. Prior history of working with other vendors/solutions should be included in the response. Any combined responses must include a Service Level Agreement (SLA) with specific roles and responsibilities between the partners (this should be further detailed and included in Section 3C of the response).

iv. Vendor SpecializationCRISP welcomes proposals that serve only a component of this procurement. For this engagement, we could envision a vendor with a specialized end product for an analytics engine (e.g., provider reporting/ visualizations) to submit a response inclusive of that component of the solution. In this case, CRISP would envision either suggesting vendor partnerships or segmenting the work efforts into multiple contracts.

v. Innovation CRISP has set forth in this RFP our planned concept for Medicare data efforts. However, we understand that through ongoing work efforts, vendors are rapidly developing innovative solutions. CRISP welcomes RFP responses that meet State objectives that rely on innovative concepts outside of our identified framework.

vi. Terms and Conditions and ConfidentialityAll responses become the property of CRISP and will not be returned to responders. Responses may be disclosed to CRISP and CRISP advisors as deemed appropriate by CRISP. All pricing information will be treated confidentially.


11




CRISP expressly reserves the right to make any decision regarding future direction or future technology partners. This includes the right to not award a contact pursuant to this RFP process. CRISP also reserves the right to:

Accept or reject any and all proposals or parts of proposals received in response to this RFP Amend or modify the RFP or cancel this request, with or without the substitution of another RFP Waive or modify any information, irregularity, or inconsistency in proposals received Request additional information from any or all respondents Follow up on any references provided Negotiate any terms of contract or costs for any proposal Request modification to proposals from any or all contractors during review and negotiation Negotiate any aspect of the proposal with any individual or firm and negotiate with multiple

individuals or firms at the same time

Submission of a proposal in response to this RFP constitutes acceptance of the all conditions of this procurement process described here and elsewhere in the RFP.

A bidder receiving a positive response to their RFP proposal should be prepared to immediately begin negotiation of final terms based on the RFP and other mutually agreed terms and conditions, provided that terms described by bidder in their response may be rejected in whole or in part and/or other otherwise negotiated by CRISP in the contracting process. In addition, a positive response from CRISP does not assure that a contract will be entered into; CRISP may discontinue negotiations with a bidder at any time, in its sole discretion. Until and unless a formal contract is executed by CRISP and responder, CRISP shall have no liability or other legal obligation to a responder whatsoever, relating to or arising from this RFP, the RFP process, or any decisions regarding pursuit of a formal solicitation.

In no event will CRISP be responsible for damages or other remedies, at law or in equity, arising directly or indirectly from any decisions or any actions taken or not taken in response to or as a result of this RFP or response by a vendor. All responder’s costs of response preparation and any negotiation will be borne by the responder.

C. Submission InstructionsResponses to this RFP should be submitted by July 29, 2016 (5pm ET) to Laura Mandel [email protected] in the format describe below.

i. Submission FormatProposals will be accepted via email in .pdf or .doc(x) formats (.docx is preferred). We prefer vendors submit the proposal as one file with all content included. However, it is acceptable for vendors to send separate files for Appendices A – F.

The maximum size for all files should be <15MB. Therefore, please compress screenshots or diagrams.

To assist our team in proposal review, please preserve the section and question numbering scheme in the RFP response as illustrated below in Figure 4:

Figure 4: Proposal Numbering Scheme ExampleChesapeake Regional Information System for our Patients

www.crisphealth.org

12



ii. Proposal Content Vendors should submit responses following the outline described in Figure 5. CRISP discourages and will look unfavorably at responses that are merely marketing collateral.

1. Cover Letter The RFP response must be accompanied by a cover letter signed by an individual authorized bid by the vendor (1 page).

2. Executive Summary CRISP requests up to two pages for an Executive Summary. The summary should introduce a responder’s company, any relevant offerings, and should provide the key highlights and a summary of the technical solution(s) being proposed.

3. Technical Proposal The content of the technical proposal is addressed in Section 3.

4. Financial ProposalThe content of the financial proposal is addressed in Section 4.

5. AppendicesAdditional information relevant to this procurement should be submitted in the appendices. Vendors may submit appendices as separate files from the other components of the RFP response submission.


13

Figure 5: Proposal Content and Page Limit

1. Cover Letter 1

2. Executive Summary 2

3. Technical ProposalA. SummaryB. Company OverviewC. Proposed SolutionD. Project Mgmt and Work Plan

33207

4. Financial Proposal 3

5. AppendicesA. Technical DiagramsB. Project PlanC. Customer ReferencesD. Pricing SpreadsheetE. Analytics ListingF. Standard Contract

1053545


D. Proposal EvaluationCRISP shall review RFP responses for (but not be limited to) evaluation of the solution, price review, and a review of synergies between the organizations. Responses shall be reviewed against other responders. The evaluation process will comprise at least:

Vendor meeting minimum qualification of three deployed Medicare data solutions A preliminary examination to determine completeness of response An evaluation of the Medicare Data Solution, including the project management plan and team A review of how the Medicare Data Solution offered works within team-able approaches Reference review Review of estimated price in the financial proposal


14


3. Technical ProposalThe technical proposal provides CRISP with an understanding of your company, proposed solutions, and your project management plan. The following sections describe the technical requirements to which each vendor must respond, as well as the suggested format of the response. We expect responses to be brief. Where relevant, we have indicated the expected length of the response. Additional information for specific sections attached as appendices to the vendor’s response.

A. SummaryProvide a summary of the technical proposal for the proposed solutions for the Medicare Data System and Analytics Engine (2-3 pages; technical diagram(s) are suggested and can optionally be added into Appendix A).

B. Company OverviewIn this section, provide a company overview including product and services offerings, industries served, size, and other relevant information, including a description of similar solutions and client references. Please align responses to the headings below (2-3 pages).

i. Company HistoryDescribe the history and evolution of your company (3-5 sentences).

ii. Industry ExpertiseDescribe the primary industry segment in which your company operates. CRISP understands that a mix of product and services companies may be engaged for this effort (3-5 sentences).

iii. Financial ViabilityDescribe the overall financial health and long term viability of your company. CRISP may request an audited financial statement (3-5 sentences).

iv. Partnering ApproachIf you are partnering with other vendor(s) to offer a solution, describe your partnering approach, including any past performance with this partnership. Generally, describe the intended breakdown of efforts. Further details should be provided in the Project Management Plan section (3-5 sentences, if applicable).

v. Medicare Data Expertise and CompetencyDescribe your company’s work with Medicare data. Are Medicare data engagements core to your company’s business? Describe engagements where understanding of Medicare payment methodologies and policies were critical to the design and implementation of the solution (3-5 sentences).

vi. Minimum Qualification: Define and Describe Similar SolutionsCRISP will require a vendor with proven ability to execute within the parameters and timeframes required in this RFP. Please provide three examples of similar solutions for other clients with Medicare data. Complete


15


responses to this question are a minimum qualification for a vendor’s response to this RFP. Please provide brief descriptions here. Include 1 page for each reference in Appendix B.

vii. Client ReferencesThe vendor should provide three customer references (use table format in Figure 6) for the “similar solutions” described above. CRISP reserves the right to contact these references and discuss the client's level of satisfaction with the vendor and its solutions/products.

Figure 6: Client References

Client Name

Client Contact Client Phone and e-mail

Implementation Start/GoLive

Dates

Approximate Cost of Engagement

Current Size

(#Members)

1.

2.

3.

C. Proposed SolutionsIn this section, the vendor must respond to all requirements listed when describing the proposed Medicare Data Solution. In addition to the response components requested, vendors are encouraged to add additional items needed for a comprehensive solution. Please align the responses to the heading numbers below.

i. Overview of the Complete Medicare Data Solution The desired Medicare Data Solution includes a Medicare Data System that will ultimately populate a variety of reports, visualizations, and analysis tools through an Analytics Engine(s) to meet stated goals. Based on the three-phased approach, as well as all components and functionality of the conceptual model described above, provide an overview of the vendor’s complete Medicare Data Solution including the following points, and building upon the response in the Executive Summary (3.A.) (5-7 pages, graphics are encouraged and can optionally be presented and referenced in Appendix A).

A. Clearly specify which components are your licensed software products, third party licensed software products, data/systems integration effort, or complete custom development effort.

B. Describe the system architecture, information architecture and data model, data integration capabilities, and means by which the Medicare Data System and the Analytics Engine(s) pair to form an integrated system.

C. Describe the technical architecture recommended including all required hardware, software, and connectivity necessary for the proposed solution and recommendations for cloud, on-premise, or hybrid deployment.

D. Provide highlights on the development roadmap for your product (not licensed products): what is your release cycle? What major features were included in your latest version? What features are currently under development?


16


E. If you have recommended a software product that you license, please explain the product feature roadmap describing features and functionality planned for release over the next two to three years. Also describe the cycle of major version updates as well as frequency of point releases and patches.

F. If the solution includes integration or custom development consulting services, please describe the recommended approach for identifying these resources.

G. Describe your approach to data security, access management and monitoring, and encryption.H. Describe your Solution Architecture: where is business logic applied, on inbound integration and

aggregation side versus the outbound analytics side? Or both? What happens where and why?I. Describe management of Medicare Data attributes: how do you aggregate costs for similar but

different data attributes? For example, costs associated with Hospital vs. Ambulatory Procedures or combining costs from Hospital vs. Ambulatory visits?

J. Describe the Data Model: how do you aggregate similar but different data concepts? For example, can the data model support a “Problem” from a CCD, a “Diagnosis” from an ADT, and a “Diagnosis” from an adjudicated claim? Given they all have ICD10 coding, how is the different temporal meaning managed in the data model (or, is the data model specifically designed align with specific types of administrative data only)?

K. Describe support for a “data divorce” scenario where it becomes necessary to completely remove a block of Medicare data (i.e. for a specific TIN or NPI). How would you handle this and does your systems have any limitations in this area?

L. Describe Terminology management: does your solution include a Terminology Server? Is this included in the price? Are all terminology codesets licenses included? Are updates included in the pricing? What is the codeset update mechanism? How often is this done at your sites? Are updates also included in the Pricing?

M. Describe code crosswalks: how does your system handle codeset mappings? For example, if a data attribute (a specific medication) was tagged as “sensitive” using a NDC-to-DataSensitivity lookup, and if this medication was later deemed not sensitive, how would this update propagate within the system? Is this included in the Pricing?

N. Describe support for Role-Based Access Control: describe how your system is able to control access to data at the data attribute level? For example, how could a sensitive medication be filtered depending on the role of the user querying the system?

O. Describe support for De-Identification: what’s the approach to de-identifying data? Has your algorithm been certified by any 3rd party?

ii. Medicare Data SystemPer the functionality described above, the objective of the Medicare Data System is to land source data for transformation in to a normalized source of truth such that purpose-built data marts may be rapidly produced for consuming information in a variety of manners. Data integration best practices are expected across the data lineage such that a secure and auditable flow of data is modeled, including singular points of reference data being recognized/mastered. The solution also must capture appropriate metadata and invoke required data quality rules.

CRISP has conceptualized this three-zone design pattern per best practices in analytics; however, we recognize these zones have a variety of logical and physical manifestations. Please include any information you feel is necessary for us to understand your solution architecture. Vendors may diverge from these constructs to propose a different conceptual model based on best practices and experience. The response should also highlight not only the vendor’s technical abilities, but also the vendor’s competency with CMS payment methodologies and Medicare data.


17


Describe your ability to meet the landing, transformation, and consumption functionality described above including the following specific functional capabilities and requirements: (5-7 pages, graphics encouraged).

A. Ability to land Medicare claims data received from CMS (assuming a CCLF data package and file formats). The package will include monthly Part A/Part B/Part D/Beneficiary/Attribution files for Maryland beneficiaries from calendar year January 1, 2013 going forward. Assume monthly update files that may include data to be appended, changed, and/or deleted. This scope should align with Pricing Scenarios #1, 2, 3.

B. Ability to land the Limited Data Set (LDS) Final Action Claims. Assume quarterly updates and 100%, not 5% random samples, where possible for Maryland and adjacent Medical Trading Areas. This scope should align with Pricing Scenario #4.

C. Ability to land X12 837 claims, 835 remits, 834 enrollment data. Does your data model support this format? Can the same basic set of analytics be run against X12 source data versus CCLF? This scope should align with Pricing Scenario #5.

D. Ability to land and incorporate additional datasets, such as Maryland’s HSCRC hospital inpatient and outpatient case mix data in the future.

E. Ability to land and incorporate patient satisfaction HCAPS or CAHPS in the future.F. Ability to transform data to take into account potential policy and industry changes that affect the

underlying meaning of the data.G. Ability to consume transformed, trusted data through custom inquiries, common format extracts,

visualization tools, or other proven methods. For example, could a 3rd party visualization tool be allowed to access the data? For example, can an extraction query be run to pull data if given a 100,000 members and a set of data attributes? Are there any limitations in this area (running specific times of the day)?

H. Ability to transform data for consumption in a various data marts organized by subject area and aggregated to meet potential future needs for self-service analytics and analytics engines.

I. Multiple format and source integration: Ability to transform and integrate multiple data sources and formats as appropriate and normalize the data into consistent, standard elements according to healthcare industry standards and data management best practices.

J. Extensible data model: Per future needs, the ability to augment and extend relational data models and other data structures used to house data meet landing, transformation, and consumption requirements.

K. Security and privacy protocols: Ability to implement security and privacy protocols across landing, transforming, and consumption of data, while at rest and in motion, including authentication, authorization, and access to data adhering to federal (HIPAA and 45 CFR Parts 160-164) and state laws and regulations (COMAR 10.25.18) protecting health information.

L. Audit capabilities: Ability to audit data and access to data across the all solution zones.M. Metadata management: Ability to identify, store, manage, and leverage for transformation both

technical and business metadata, or data about data, enabling lineage of data from source to end user consumption.

N. Master data management: Ability to master and manage various reference data elements, including disambiguation from different sources, including provider or patient identity. Examples include the ability to match claims data with identities maintained in the CRISP Master Patient Index (MPI) and apply CRISP opt out indicators and the ability to conduct analysis over time taking in to account the changing ICD code set vocabularies.

O. Data quality rules processing: Ability to validate data elements against references data sets and apply various transforming data quality rules to enhance, correct, map or cross-walk, calculate, aggregate,


18


etc. to enable purpose-built views of data to meet various consumption needs including analytics engine population.

iii. Analytics Engine(s)Describe your ability to meet all phases of analytics engine functionality described above including the following specific functional requirements (5-7 pages, graphics encouraged; use Appendix E for additional information). The response should also highlight not only the vendor’s technical abilities, but also the vendor’s competency with CMS payment methodologies and Medicare data. CRISP will rely on the vendor’s expertise for most report specifications and details. This may include enhancing the Medicare data with additional analytics, such as risk adjustment and episode grouping.

Analytics Set #1: Program Operations - Hospital-Specific Analytics:

A. Please include in Appendix E the complete listing of analytics you have included in the pricing which aligns with “Analytics Set #1” (understanding that the vendor may have a package of analytics which approximately matches or exceeds the listing in this section).

B. Ability to deliver a hospital information delivery product with a recommended suite of information most relevant and actionable for providers to support care coordination use cases per industry best practices and including, but not limited to, the following examples. Conceptually, these are similar reports delivered to Accountable Care Organizations or Medicare Advantages customers (specific analytics are described below).

C. $PMPM with the ability to segment/pivot/filter. Extensive capabilities to produce more detailed views of data is critical. The vendor should address its approach to cost and utilization segmentation.

D. Utilization reports, including Admits/1000, CMA Admits/1000, ED/1000, Re-admits/1000, Specialists and PCP/1000., etc.

E. Population by diagnosis, chronic diseasesF. Length of stay analyticsG. Potentially avoidable utilization and costsH. Gaps in health and care within a longitudinal view of care per patient and per population segmentI. Quality measurement (initially in line with NCQA, AHRQ, and other national standards, and later for

Maryland-specific alignment programs)J. Episode reports K. Total Cost of Care, including ongoing analysis of changes in cost by segment, per beneficiary, risk

adjusted comparisons, etc.L. General description of any dimensional analytics cubes (a listing of facts, dimensions, measures).

Analytics Set #2: HSCRC-Specific Analytics:

M. Please include in Appendix E the complete listing of analytics you have included in the pricing which aligns with “Analytics Set #2” (understanding that the vendor may have a package of analytics which approximately matches or exceeds the listing in this section).

N. Ability to produce limited reports for hospital and HSCRC administrative and monitoring of total cost of care and potentially other uses under Maryland’s all payer model.

O. Ability to empower HSCRC analysts to consume and conduct self-service analytics using various industry standard query, analysis, and visualization tools.

Analytics Set #3: Program Operations (non-Hospital):


19


P. Please include in Appendix E the complete listing of analytics you have included in the pricing which aligns with “Analytics Set #3” (understanding that the vendor may have a package of analytics which approximately matches or exceeds the listing in this section).

Q. Ability to deliver a non-hospital information delivery product with a recommended suite of information most relevant and actionable for providers to support care coordination use cases per industry best practices and including, but not limited to, Analytics Set #1, but tuned for non-Hospital providers (Ambulatory, SNFs, etc.).

Analytics Set #4: Production Control & Metadata Analytics:

R. Please include in Appendix E the complete listing of analytics you have included in the pricing which aligns with “Analytics Set #4” (understanding that the vendor may have a package of analytics which approximately matches or exceeds the listing in this section).

S. Ability to deliver information to the administrators of the system, which may include the following types of analytics specifically for system operation.

T. System Usage: who is using the system? Which types of reports / analytics and what frequency and user role, type and organization affiliation?

U. System Validation: as data are periodically loaded and updated, what data integrity and quality reports / analytics are available?

V. System Monitoring: is there a dashboard that shows the overall system status? Processes that are running or that are “down”, or tracking data as it flows through the system?

W. System Troubleshooting: what tools, reports, analytics exist to aid administrators with troubleshooting the system? Is there clear lineage / traceability as data flows through the system?

Additional Questions:

X. Are the analytics extensible? If during Phase2 there is a need to refine the out-of-the-box analytics delivered in Phase1, is this supported and what’s the process for extending the analytics?

Y. Please describe the data visualization solution – is it proprietary or a 3rd party? CRISP has experience with Tableau – how does the proposed solution compare?

Z. Please describe the overall architecture of the analytics engine: are data from various sources loaded into analytics view or an analytics cube to support out-of-the-box analytics? For example, for $PMPM analytics, can the source data come in different formats (CCLF or X12) or is there a specific analytics cube for each specific data source?

AA. Self-Service – can external users bypass the analytics and attach directly to the data via APIs or data connectors (oData, OLEDB, ODBC, or direct SQL access) to achieve self-service information? It is assumed that this access would be for a limited number of power users who may be tasked with developing new analytics or doing basic data discovery to specify new analytics (or to join with other data sources).

iv. Ongoing SupportDuring the first year of the CRISP-vendor partnership, the vendor will be responsible for ongoing support of the Medicare Data System and Analytics Engine(s). In Phase 3 of the engagement, CRISP will determine if the vendor will transition the system environment and operations to the CRISP team. In this section, describe the ongoing support, and if/when the vendor transition system operations to CRISP. This support model should also align with the ongoing pricing for Years 2 and 3 (use Figure 7 below and limit responses to 2-3 sentences).


20


Figure 7: Ongoing Support Capabilities

Item Response

How does the CRISP team interface with the vendor’s support team?

Process of initiating a service request

Hotline (e.g., help desk, problem resolution processes)

Location and hours of support

How are product changes/upgrades communicated with CRISP and the users?

Who does the upgrades? Are they included in the pricing?

If there are multiple vendors, what is the SLA and roles/responsibilities between vendors? Please confirm CRISP corresponds with one “Prime” vendor.

v. TransitionDescribe ability to fulfill the following requirements and/or describe the details around its models/methods. This transition model should also align with the ongoing pricing for Years 2 and 3 (use the Figure 8 below and limit responses to 2-3 sentences).

Figure 8: System Environment and Operations Transition to CRISP

Item Response

Documentation & training availability

On-site training (describe qualifications/certifications of trainers)


21


E-learning/training (live and/or on-demand)

Online documentation

D. Project Management and Work PlanCRISP values strong partnerships and collaboration. In this section we would like an understanding of your overall project management approach, team members for key roles, core competencies, and proposed work plan.

i. Implementation MethodologyProvide an overview of your implementation methodology and the project management approach recommended. Include team member roles and organization (1 page).

ii. Consulting ServicesProvide an understanding of other staffing resources. Are you consulting for Medicare data expertise or Maryland-specific expertise? Off shore resources? Describe your recommended use of consulting services to meet the implementation scope and timeline described herein. Specify between the use of your own consulting resources and/or partner implementation/consulting services and roles/responsibilities where pertinent (1 page).

iii. Proposed Project Plan and TimelineProvide a proposed project plan and timeline with project milestones for the three Phases of Effort. Indicate key task dependencies and responsible parties for each task (for both vendor and CRISP tasks).

CRISP and our State partners place a high importance on delivering Phase 1 within the three-month timeline; therefore, the proposed project plan and timeline should be most developed for the Phase 1 efforts.

Please acknowledge this key Phase 1 timeline milestone in your response.

Include time points of work components including requirements, specifications, design, configuration/program, test, and implementation. Please align the project plan or Work BreakdownStructure to fit within main project deliverables illustrated below in Figure 9 (2-3 pages; an electronic version of a project plan (.mpp) or WorkBreakdownStructure (.mpp or .xlsx) should be included in Appendix C).

Figure 9: Phases and Main Project Deliverables


22


iv. Team Members and Key Roles Using Figure 10 below, name individuals for the project team specifying from which organization, including CRISP, you recommend team members. Several roles are listed below for illustration. For each role, identify the percent effort over the first year of effort and if there is more than one individual required in the role (1 page).

Figure 10: Team Members and Key Roles

Organization Role %Effort Experience/Area of Specialization

Project Manager

CMS Data Subject Matter ExpertData Architect

ETL Developer

System Administrator…

…


23


v. Communication ApproachDescribe your communications approach. It is essential to maintain consistent and effective communication with CRISP. How often do you intend to have staff working onsite at CRISP (3-5 sentences)?


24


4. Financial ProposalCRISP requests a pricing proposal to understand the total cost of ownership (TCO) of the solution. The TCO quantifies the total cost to CRISP across three years for developing and operating the solution. Please limit the narrative to 3 pages. Outline your financial proposal in an Excel spreadsheet and include it as an Appendix D.

Include the initial cost of implementation and any on-going subscriptions or licensing fees (including any 3 rd party licenses or expected system hosting fees).

If the solution is hosted on-premise, include estimates for all hosting environments (Production, Disaster Recovery, Staging, Testing, Development, as well as any separation of servers for Presentation/Web, Application and Database servers). Please include a hosting topology diagram in Appendix A.

Please document any other costs that CRISP may incur in doing business with your company for this area of work (or list assumptions for any items NOT included in the pricing (i.e., CMS’s dataset fees). Also include the hourly expense for each resource type that may be engaged in this effort.

Please include a copy of your standard contract with this proposal in Appendix F.

Please note: All responses, assertions, and commitments made in this proposal will be part of any contract.

A. Pricing ModelPlease describe the dimensions of the pricing model, whether it is based on the #Members, #Citizens, #Data Sources, #Analytics, #CPUs, #Users, or however pricing is scaled. The description should include both install pricing and ongoing pricing models (1 paragraph).

B. Pricing DetailsFor the five scenarios outlined in Figure 11, complete the pricing Excel pricing template in Appendix D. We have provided an annotated pricing template in Figure 12.

Figure 11: Pricing Detail Scenarios

Scenario #Members Data Sources

Scenario #1 100,000 CCLF Only

Scenario #2 1,000,000 CCLF Only


Scenario #4 1,000,000 LDS Only (**)

Scenario #5 1,000,000 X12 834, 837 (P&I), 835 (*)

(*) Assume for the same 1,000,000 members, CRISP uses X12 claims data instead of CCLF data. Specifically, assume a directory of files of X12 837 claims (Professional and Institutional), X12 835 remittances, X12 834 enrollment files. In this scenario all of the X12 files would be provided in 5010 version (but delivered from many source systems).


25


(**) Assume for the same 1,000,000 members, CRISP uses LDS Final Action Claims instead of CCLF or X12 data. Assume quarterly updates and 100%, not 5% random samples, where possible for Maryland and adjacent Medical Trading Areas.

Figure 12: Annotated Pricing Template

C. Services CostsFor services costs (for custom or extended services outside of the fixed price components), we have provided a table below in Figure 13 for responses for hourly rate by labor category. If vendors provide services pricing using a different method, please respond using text and/or a modified table.

Figure 13: Labor Category Rates

Labor Category Labor Category Description Hourly Rate

Project Manager

CMS Data Subject Matter Expert

Data Architect

Analyst

CMS Data Subject Matter Expert


26


D. Costing SummaryBased on CRISPs Medicare Data Solution needs and the vendor’s experience with similar procurements, provide a costing summary with one-time and recurring costs using the template in Figure 14.

Vendors may also include a narrative response explaining the all-in estimates and summarizing any financial risks with an approximate percent impact on the price (1 page).

Figure 14: All-In Costs

Pricing Scenario

# of Members

Data Sources

1-Time Costs (A)

Recurring Costs/Yr (B)

3 Yr TCO (A+3*B)

Scenario #1 100,000 CCLF Only



Scenario #4 1,000,000 LDS Only

Scenario #5 1,000,000 X12 Only


27


5. AppendicesA. Technical DiagramPlease include any technical diagrams that help describe your solution, including a hosting topology diagram (limit to 3 pages).

B. Description of Similar Solutions and Customer ReferencesPlease include summarizes of each of the reference sites (1 page each).

C. Project PlanPlease include an electronic project plan (or WorkBreakdownStructure) with no more than ~100 rows of detail (and with deliverables which align with the illustration in Section 3D).

D. Pricing SpreadsheetPlease update the spreadsheet template with the granular details of the pricing proposal. Vendors may add as many detailed rows, but please preserve the roll-up sections numbered 1-5 (and column headers for Year1-3 and TCO).

E. Analytics ListingPlease include a listing of analytics that are included in the proposal, as aligned with Analytics Set #1, #2, #3, #4, defined in 3.C.iii, and included in the pricing.

F. Standard ContractPlease include a copy of your company’s standard contract (ideally inserted as an electronic object, or include as an extra file and reference it by file name in this section).


28

Date post:	13-Oct-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Overview and Objective - CRISP – Chesapeake Regional ... · Web view2016/06/22 · CRISP and our...

Documents