Bundled Procurement RFI - Rackcdn.com

The State of Oregon, Oregon Health Authority Issues the Following Request for Information (RFI) #3857

For Provider Directory, Clinical Quality Metrics Registry, and Systems Integrator

Date of Issuance: November 18, 2014 Responses Due:

December 18, 2014, by 3:00 P.M., Pacific Time, at the Issuing Office

Issuing Office and Sole Point of Contract: Office of Contracts and Procurement Traci Friedl, Contracts Specialist 800 NE Oregon Street, Suite 640 Portland, OR 97232 Telephone: 503-602-3257 Email: [email protected]

-1-

TABLE OF CONTENTS 1. CONTENTS 1.0 Introduction………………………………………………………………………………………………..- 4 2.0 Understanding this Request……………………………………………………………………………….- 4 2.1 RFI Response Options................................................................................................................................. - 5 3.0 Scope of Request…………………………………………………………………………………………………………………………………..- 5 3.1 Systems Integrator....................................................................................................................................... - 6 3.1.1 Project, Risk, and Issues Management ................................................................................................ - 6 3.1.2 Interfaces.............................................................................................................................................. - 7 3.1.3 Single access solution .......................................................................................................................... - 7 3.2 Provider Directory ....................................................................................................................................... - 8 3.2.1 HIT environment ................................................................................................................................. - 8 3.2.2 Goals .................................................................................................................................................... - 9 3.2.3 Key functions ....................................................................................................................................... - 9 3.2.4 Minimum initial functionality ............................................................................................................ - 10 3.2.6 Business Operational Requirements .................................................................................................. - 12 3.3 Clinical Quality Metrics Registry ............................................................................................................. - 12 3.3.1 HIT Environment ............................................................................................................................... - 12 3.3.2 Goals .................................................................................................................................................. - 12 3.3.3 CQMR Key Functions ....................................................................................................................... - 13 3.3.4 Minimum Functionality ..................................................................................................................... - 14 3.3.5 Business Operational Requirements .................................................................................................. - 14 3.4 Other Considerations (Optional)…………………………………………………………………..….- 15 3.4.1 Patient/Provider Attribution (PPA) .................................................................................................... - 15 3.4.2 Fiscal Agent Services......................................................................................................................... - 15 4.0 General Terms, Conditions, and Procedures…………………………………………………….…...- 17 5.0 How to Respond…………………………………………………………………….………………..- 17 6.0 Confidential or Trade Secret Information…………………………………………………………….- 17 7.0 Contact Information…………………………………………………………………….…………….- 18 8.0 Disclaimer……………………………………………………………………………………….……- 18 9.0 Presentations…………………………………………………………………………….……………- 18 10.0 Project Dates and Milestones…………………………………………………….…………………- 18 Attachment 1: Vendor Information and Response Reference Sheet…………………….………………..- 20 Attachment 2: Systems Integrator Solution Details……………………………………………………….- 22 -

OHA RFI #3857

-2-

Attachment 3: Provider Directory Solution Detail………………………………………………….…….- 25 Attachment 4: Clinical Quality Metrics Registry Solution Details……………………………………….- 30 Attachment 5: Oregon Health IT Background…………………………………………………………….- 35 Attachment 6: Oregon Health IT Products & Vendors……………………………………………..…….- 40 -

OHA RFI #3857

-3-

Section 1: Introduction On behalf of the Oregon Health Authority (OHA), Office of Health Information Technology (OHIT), the Office of Contracts and Procurement issues this Request for Information (RFI) on three solutions for Oregon: Systems Integrator (SI); Provider Directory (PD); and Clinical Quality Metrics Registry (CQMR). These solutions will address significant components of a portfolio of Health Information Technology (HIT) related work to support healthcare delivery and payment reform in Oregon. Through this RFI, vendors have the opportunity to provide input on technology solutions and implementation. Vendors can choose to respond to any of the components or parts thereof in whatever combination represents the vendor’s recommendation for how to best utilize its capabilities. The responses to this RFI will inform one or more Request for Proposals (RFP) for the SI, PD, and CQMR solutions. OHIT anticipates a “bundled” procurement that will accommodate vendor proposals for one, two, or three of the requested solutions. This RFI will not in itself result in any kind of contract, nor will it obligate OHA to procure goods or services of any kind or from any particular vendor. The responses will be used to evaluate the state of the market and to identify functional requirements and system capabilities from vendors, or combinations of vendors, into a project scope; however, these responses will not result in specifications targeted to a specific vendor. Vendors are strongly encouraged to read Attachment 5: Oregon’s Health HIT Landscape: Background and Attachment 6: Oregon’s Health HIT Landscape: Products and Vendors to understand the background and context for which this RFI is being issued.

Section 2: Understanding This Request Each topic (PD, CQMR, SI) has several components to which responses can be made. Vendors can pick and choose those components in any of the three topics for which they wish to respond. In other words, information about partial solutions is welcome as OHA wants to identify vendors and solutions available in the marketplace for the components of the desired solutions as well as information about complete solutions. Vendors are also welcome to partner with other vendors in submitting a response. OHA intends to contract for business operations for the PD and CQMR solutions, where the selected vendor(s) will operate those solutions for OHA, including the hosting of the technology/systems involved and the business operations and support. It is not necessary for the business operations vendor to also supply the technology solution for PD or CQMR. Attachment 1 is a vendor information and response sheet. OHA asks each responding vendor (or partnered vendors if such is the case) to use this table to specify exactly which components of which solutions you are responding to. Each solution is identified along with its components, and there is a reference to the sections of the response

Scope of OHIT Initiatives that are included in this RFI: • A State-level Provider Directory services – to support analytics that rely on attribution of providers to practice settings; to enable the exchange of patient health information across different organizations and technologies; and to provide efficiencies for operations, oversight, and quality reporting. • A Statewide Clinical Quality Metrics Registry – to enable Coordinated Care Organization (CCO) and Meaningful Use clinical quality metrics to be gathered for quality measurement and incentive payment. • Systems Integrator services – to provide project management, risk management, act as fiscal agent, and provide the responsibility for data management and interfaces that may be required between components in the procurement and other systems.

-4-

forms for each solution that apply to the component chosen for response. Attachments 2, 3, and 4 then provide direction for responding to the SI, PD, and CQMR solutions respectively.

2.1 RFI Response Options The vendor response table is repeated here as a reference to understanding this section of the RFI (see Attachment 1 for full table): Systems Integrator (Section 3.1, Attachment 2) Project and Risk management Operations Interfaces Access Solutions X Financial Considerations Provider Directory (Section 3.2, Attachment 3) Operation Solution and Technology X Costs X Optional: Fees Clinical Quality Metrics Registry (Section 3.3, Attachment 4) Operation Solution and Technology X Costs X Optional: Fees Other/Optional (Section 3.4) Patient/Provider Attribution Fiscal agent As an example of OHA’s interest, a responding vendor may describe a way to support the business operations of both the PD and CQMR, as well as offer fiscal services, but may not be prepared to recommend the technical solution. Conversely, considering the PD entries, a responding vendor may want to recommend the technical solution but is not prepared to engage in the business operations of the solution. These examples should explain our stated interest in learning more about vendor capabilities on a granular level. Section 3 of this RFI has separate sections for each topic (SI, PD, and CQMR) in the Scope of Work explaining OHA’s intent for the three topics. The SI solution is covered in section 3.1, the PD solution is covered in section 3.2, and the CQMR solution is covered in section 3.3. There are two “Other/Optional” potential topics that are briefly described in this RFI. These appear in the table above as Patient/Provider Attribution and Fiscal Agent. These topics are expanded on in Section 3.4 of the RFI. For these topics, which are not specified in detail at present, OHA is interested in learning more about what vendors in the marketplace can offer by way of comment as well as information on any solutions vendors may want to bring forward. Bear in mind, though, that responding to these optional topics is entirely at the option of the vendor. OHA’s primary interest for now is in the response to the first three specific topics in section 3 of the RFI (SI, PD, CQMR). Sections 4 - 11 of this RFI details the instructions and information for submitting a response.

Section 3: Scope of Request The purpose of this RFI is to elicit ideas and recommendations regarding the implementation of SI, PD, and CQMR solutions. This includes allowing responding vendors flexibility to suggest or describe partnerships to achieve solutions to the topics in this RFI that can be implemented simultaneously and more cost effectively. There is a projected timeframe (See Attachment 5) for topics in this RFI, but respondents should suggest their OHA RFI #3857

-5-

own timeline for the solution(s) they are offering. There is a diagram of interfaces and data flows with web portals for user access (Figure 2 in Attachment 5), but respondents should make their own suggestions for how these systems work together while meeting the requirements for the operation of each solution. OHIT’s approach to implementing the SI, PD, and CQMR solutions is as follows: • The RFI responses will inform an RFP or RFPs to procure solutions addressing the topics of this RFI. • RFP(s) that are subsequently released will identify minimum, first phase, requirements. Minimum requirements that we have been able to identify now are included in the solution response sections of this RFI. • OHIT anticipates subsequent development or enhancement cycles following the initial implementation of each solution. • Vendors responding to any section(s) of this RFI are requested to describe how they will organize for and manage for ongoing incremental implementation. This description would ideally include descriptions of the functional content of such incremental implementations and the vendor’s strategic or tactical thinking in grouping the work into these phases.

3.1 Systems Integrator OHA is seeking input from vendors on available solutions for Systems Integrator functions related to the implementation of state-wide PD and CQMR solutions, as referenced in this RFI. Currently, OHA does not have sufficient staff or expertise to provide its own systems integrator functionality and such functionality is essential to securing successful implementation of these solutions. OHA expects a SI to provide project management, risk and issues management, and interfaces as needed for the topics described in this RFI. Please use the Scope of Request information for PD (Section 3.2 of this RFI), for CQMR (Section 3.3 of this RFI), and for Other Considerations (Section 3.4 of this RFI) to inform your response to this SI section of the RFI.

3.1.1 Project, Risk, and Issues Management OHA anticipates there will be initial required systems integration functionality as follows: 1) Participation in contract negotiation with the selected vendors for the PD and CQMR solutions. These vendors will be operating solutions for OHA to provide these services. Contracted scope of work in each case will include: 2) The implementation of a solution that meets the scope expectations as outlined previously in this RFI (and likely expanded in the RFP to follow) 3) The ongoing support and operations of each solution as a service 4) Software licensing (initial and ongoing) 5) Service Level Agreements 6) Project Management and technical support services to ensure the successful implementation of the selected vendor solutions for PD and CQMR: 7) Oversight of each solution implementation for technical performance, full implementation of scope and features as contracted, data management, compliance with desired architecture, data privacy, system and data security, 8) Oversight of a process to consider use of the State Data Center for either or each solution depending on technical architecture elements of the solutions; 9) Oversight of acceptance testing for each solution, to include unit and end-to-end testing; 10) Oversight and management of the solution implementation projects within constraints of scope, schedule, and contracted cost; OHA RFI #3857

-6-

11) Oversight, development, and management of processes to manage issues, change, and risk for the two solutions, within an OHA defined governance model. OHA anticipates there may be future SI needs for project, risk, and issues management as additional projects are defined for the HIT portfolio. For instance, a resolution of the patient-provider attribution question is still being developed, but it is likely there will be interface and data feed work required to support a solution, and there is also the possibility that a solution will be procured.

3.1.2 Interfaces OHA anticipates that the Systems Integrator will be responsible for providing solution interfaces. OHA has identified one required interface for the PD solution which is a part of this RFI. The known interface requirement is to feed provider information from the Common Credentialing solution to the Provider Directory. See Attachment 5 for a description of the Common Credentialing solution, which is being procured separately. Other interfaces between the solutions included in this RFI, or between these solutions and other systems at OHA or in the state, are being considered and some of these may become current or future requirements. Background related to other potential interfaces is described here: • CQMR – PD potential interface: The CQMR solution will have patient-identified measure data linked to healthcare organizations and/or providers. The PD will have provider information linked to organizational entities. In the future there may be a need to share certain data in either of these solutions with the other solution. • All Payer All Claims (APAC) database potential interfaces: OHA currently operates an APAC which contains claims-based data which can potentially help to associate providers to healthcare entities, and to associate providers to patients. The claims details in this database may also add value to the data in the CQMR. In the future there may be interface needs between the APAC and either the CQMR or the PD solutions. • OHA has a Medicaid Management Information System (MMIS). The Common Credentialing solution will have significant provider information for those providers required to have credentials to provide services in Oregon. This credentialing data may have value for the provider enrollment function in the MMIS. In the future there may be an interface need between the MMIS and the Common Credentialing solution. • An organization external to OHA is in the process of developing a statewide hospital notifications system using the vendor Collective Medical Technologies (CMT). The notifications system will have patientidentified event and other data linked to local or regional HIEs, healthcare systems, health plans, and providers. The data in the notifications system may have value in associating providers with patients. In the future there may be interface needs between the CMT solution and the CQMR solution. • Patient-Provider Attribution (PPA) is introduced briefly in section 2.1 above and in more detail in section 3.4.1 later in this document. Information in many of the systems and solutions just described in this interface section (PD, CQMR, APAC, MMIS, and Notifications) could potentially be of value in arriving at definitive patient-provider attribution. In the future there may be interface requirements associated with resolving the patient- provider attribution problem.

3.1.3 Single access solution OHA envisions a common access solution through which users can access solutions to the topics in this RFI. OHA currently anticipates separate solutions for the PD and the CQMR. OHA also anticipates that each solution will have its own user interface and an access portal of some kind. Minimal functionality for an access portal would be a user logon screen to input user id and password information. OHA perceives that a common portal or access point, provided by the SI, would benefit users of these solutions as they try to incorporate these new

OHA RFI #3857

-7-

solutions into their existing workflows and processes. The functionality OHA expects from this common portal or access point is described here: A. Minimum initial functionality: 1) Each of the two solutions in this RFI (PD and CQMR) is envisioned to have portal access for users to interact with the systems and to access the data in the systems. 2) OHA wants users authorized to access both the PD and CQMR via their portals to be able to authenticate to either of the portals and have access to the other without having to resupply their authentication credentials. 3) OHA requests that the respondent describes how their solution will achieve such access to the PD and CQMR portals, whether it is through another portal or access point, some form of single sign on, or another method. 4) How does the solution provides identity verification and access control to the other solutions based on individual profiles? 5) OHA does not anticipate that a common access point or portal will aggregate content of the individual solutions. 6) OHA does not expect that the individual solutions with web portal access will change their access functionality or design to accommodate the common access solution described here, but they should collaborate on resolving security, user profiles and access levels, and account user id and password management. B. Future Considerations for Accessing Solutions: 1) Figure 3 (See Attachment 5) provides a view of the portals and solutions that will be part of the HIT/HIE enabling infrastructure at the projected time of implementation for PD and CQMR. As depicted in this figure, all users of any of these solutions will have access to all of these solutions through one access point. 2) OHA requests that the respondent describes how their solution will achieve this, whether it is through another portal or access point, some form of single sign on, or another method. 3) The explanation should include how the solution provides identity verification and access control to the other solutions based on individual profiles. 4) At some future point in time OHA may want a common portal to provide enhanced content alternatives and features, beyond access functionality.

3.2 Provider Directory OHA is seeking input from vendors on available solutions that support the implementation of state-level PD services to collect and route health care practitioner information. Currently, OHA and others in Oregon’s healthcare landscape use a multitude of isolated provider directories, spread across state and non-state systems. Those directories are often limited in scope and data accuracy, and are costly and burdensome to maintain. They also may or may not meet nationwide Provider Directory standards in place today or evolving such as HPD, HPD Plus, and Federated HPD.

3.2.1 HIT environment There is a limited ability for health care providers to exchange health information (HIE) outside their CCO, clinic, organization, or system using Direct secure messaging because a common HIE directory containing Direct addresses and other electronic service information does not exist. State-level PD services will seek to leverage OHA RFI #3857

-8-

data existing in current provider databases and add critical new information and functions, such as HIE “addresses” for providers, and provider affiliation to practice settings. OHA is interested in state-level PD services now because of the following needs and opportunities: 1) CCOs and other providers have told the Oregon Health Authority (OHA) a statewide PD is needed for foundational, near-term needs. The CCOs would prefer a single solution that can be leveraged by all CCOs, rather than having each CCO maintain 16 different instances of the same data 2) Common Credentialing efforts that place standards and requirements for data are underway in Oregon. This would allow use of common credentialing data and allow other authoritative provider data sources in the PD. 3) Emerging national healthcare provider directory standards for data models and protocols are currently being solidified (2014). These standards enable users of disparate EHRs and electronic systems to access provider directories using their systems and within their workflows. 4) In the coming months, data governance policies will be developed with the input and participation of stakeholders to the PD. Once adopted by OHA, these policies will set data quality standards from all data contributors (not just common credentialing) and will ensure that confidence in the state-level directory remains high and encourages use.

3.2.2 Goals Desired outcomes for the state-level PD services include the following: 1) Create efficiencies for operations, analytics, oversight, and quality reporting for Medicaid and OHA programs, as well as for CCOs, local health plans, health systems, and providers. 2) Establish an accurate source of key provider information such as demographics, practice locations, specialty, licenses, and common core credentialing documentation. (Data from the Common Credentialing solution will be reflected in the PD solution. The user population of the PD will consider the PD as a source for this information, even though this data originates in the Common Credentialing solution). 3) Support community, CCO, OHA and health plan analytics that rely on attributing providers to clinics. 4) Enable the exchange of patient health information across different organizations and technologies 5) Enhance care coordination across disparate providers and around transitions of care by providing easy access to provider information.

3.2.3 Key functions Oregon’s PD will be developed in phases, starting with three key use cases (health information exchange, operations, analytics) and expanded over time to serve other use cases. Refer to the Provider Directory Subject matter expert workgroup summary for more details on uses, key functions, and data 1. The PD will include all types of providers and organizations that participate in these use cases, not just physical health providers and hospitals. At a minimum, components of the PD services will include:

http://healthit.oregon.gov/Initiatives/Documents/Provider Directory Subject Matter Expert Workgroup Summary Final 2014-06-17.pdf. 1

OHA RFI #3857

-9-

1) Current and historical core authoritative healthcare provider data stored from contributions of external data sources such as common credentialing data files and other approved data sources 2) A “router” and a single lookup point (e.g., web-portal) that distribute lookup requests to provider directories at community and organizational HIEs and health systems and returning aggregated responses. 3) State data on facilities such as Primary Care Patient Centered Homes.

3.2.4 Minimum initial functionality A. Initially, the minimum functionality of the PD should include the following requirements. Functionality will be expanded in later iterations. (See Section C, below.) 1) Storage and management current as well as historical data 2 elements required by the Oregon Practitioner Credentialing Application (OPCA) 3 and the Federated-HPD model 4: a. Providers (e.g., individual healthcare professionals of all types): identifying information such as name, profession, specialization, addresses (legal, billing, postal), and contact information (phone, fax, email, Direct address and URLs for query endpoints), and additional information such as status (primary, other, inactive) b. Organizations (e.g., clinics, plans, hospitals, hospital systems): identifying information such as name, legal address, and contact information (phone, fax, email, Direct address and URLs for query endpoints), and additional information such as languages supported pointers to Services c. Relationships/Memberships (1) affiliations between individuals and organizations (2) contact and services information for the individual specific to the affiliation (3) role within a care team d. Credentials: information about where a provider is credentialed (includes credentialed date and expiration) and professional qualifications (e.g., degrees, certifications) 2) Integration with the Common Credentialing solution and other approved data sources (using an API or flat-file extraction) with automatic, periodic importation of their data. 3) Allow authenticated parties that meet data quality standards to securely submit flat file extracts of their directories. Submitted data should be automatically processed, stored, and aggregated together along with data from the state-level directory. Authenticated parties should be able to securely access a flat file extract containing the aggregated data. 4) Flat file data extracts to subscribers 5) Assessment and display of quality ranking for the data, indicating the degree of accuracy and reliability of that data element/data source 6) Secure web interface that, for authenticated users, supports searches of the directory as well as external directories (see the bullet below regarding federation). 7) Support of federation by orchestrating queries and responses, including: a. Routing queries from users (blue in the Diagram) to other Oregon directories and directories outside Oregon, and providing an aggregated response.

2

Historical data include data on Providers, Organizations, Relationships/Memberships, and Credentials that has changed from its current state with a demarcation of when those data were applicable (e.g., storing dates of previous affiliations between individuals and organizations)

3

http://www.oregon.gov/oha/OHPR/ACPCI/docs/2012/2012credappglossary.pdf

4

http://modularspecs.siframework.org/Provider+Directories+Homepage

OHA RFI #3857 -

- 10

b. Routing queries from other Oregon directories to other Oregon directories and to directories outside Oregon, and providing an aggregated response. c. Routing queries from directories outside Oregon to other Oregon directories, and providing an aggregated response. 8) Support directory queries and federation using industry standards: HPD, HPD Plus, or Federated HPD. 9) Storage of HIE endpoints such as Direct secure messaging addresses and other secure messaging addresses. 10) Robust safeguards for personal data and any protected health information such as a practitioner’s Social Security Number. 11) Processes to protect data integrity (e.g., protections against creating duplicate records, data validation, records retention, offsite back-ups, etc.); 12) Full accessibility and availability for users. The Provider Directory should be accessible 24 hours a day, so reliability and scheduled maintenance windows are considerations for availability. 13) Ability to add system components or requirements or to easily change business processes or rules as necessitated by new policy directives or other means. B. Diagram 1 below depicts the environment (entities, systems, networks, data sources) in which the state’s PD solution will operate. Points to consider when considering this diagram: 1. Federal Healthcare Provider directory HPD standards are in place with criteria on how these data are stored and shared in EHRs 2. The Common Credentialing database will be beginning to capture credentialing data (fully functional in mid-2016) 3. Stand-alone healthcare directories will be connected via Federated-HPD services, such as a a. Web Portal, b. Orchestrator “Hub”, or c. Centralized database for some components. 4. Users with HPD capabilities can connect to the network of Oregon directories and Interstate Directories 5. Users without HPD capabilities can interact via flat-file exchange with the centralized components of the directory. Diagram #1: State-Level Provider Directory Environment

OHA RFI #3857 -

- 11

C. Future Functionality will include the receipt, storage, and management of additional data elements that are not included in the standard data model for Federated HPD or OPCA. The Provider Director shall also support geocoding for physical locations and provide a data entry interface for data elements that may not come from other sources.

3.2.5 Business Operational Requirements Beyond the technical aspects, OHA is also interested in management of day-to-day operations that support the program, including: 1. Managing the technical instance of the solution, whether hosted, Software as a Service, or cloud-based, including appropriate backup and test instances. 2. In coordination with the System Integrator, a. Providing outreach and assistance to potential data source contributors b. Managing the onboarding process and ongoing management of participation for permitted data contributions (interfaces) c. Managing data, including handling data source discrepancies (e.g., when two data contributors submit a different data element for the same person or entity) 3. Providing user support and technical assistance including: a. Providing outreach and training to new and potential users b. Writing, publishing, and maintaining user manuals and other training documentation c. Providing help desk support to resolve issues and answer user questions 4. Managing the onboarding process and ongoing management of participation for permitted users 5. Ensuring data access and permitted uses of the Provider Directory are being followed 6. Assessing policy compliance and take action for non-compliance 7. Maintaining program communications including information on expected outages or updates

3.3 Clinical Quality Metrics Registry OHA is seeking input from vendors on available solutions that support the implementation of a state-level CQMR to collect, aggregate, display and export Clinical Quality Measure (CQM) data. The use of standardized CQMs facilitates the aggregation of clinical information. CQMs are process and outcomes measures used to measure the current quality of patient care and identify opportunities for improvement. Health plans, CCOs, health systems and providers all need CQMs to achieve the triple aim of better health, better care and lower costs.

3.3.1 HIT Environment Performance measurement using clinical data through CQMs has increased substantially in the last decade; however, significant technology disparities affect the access that providers, health systems, health plans and CCOs have to clinical information beyond individual patient records – amassed for their population of patients or members. Historically, access to clinical data for quality measurement has been expensive and burdensome to collect (e.g., through manual chart audits). As electronic access to information becomes more available, medical chart audit reviews for accreditation and regulatory requirements will no longer be needed. Time gaps between collection, review and the ability to act will decrease, making the information more valuable to providers, health systems, CCOs, health plans and the State.

3.3.2 Goals Outcomes for the CQMR include the following: 1. Enabling a ‘report once’ strategy to streamline reporting requirements among multiple quality programs 2. Decreasing administrative burden of data collection and reporting 3. Improving data transparency and availability

OHA RFI #3857 -

- 12

3.3.3 CQMR Key Functions Oregon’s CQMR will be developed in phases, starting with 3 key use cases and expanding over time to serve other use cases. In the initial phases, the CQMR will be used to: 1. Collect data on CCO Incentive measures to determine CCO performance and associated payment eligibility 2. Collect data on Meaningful Use CQMs in order to: a. Anticipate federal requirements for the on-going collection of Meaningful Use electronic Clinical Quality Measure (eCQM) data b. Determine incentive payment eligibility for providers and hospitals participating in the EHR Incentive Program 3. Improve CCOs’ access to CQM data and the ability to utilize standardized data for analytics/quality improvement initiatives A high-level diagram of the state-wide CQMR environment follows: Diagram #2: State-Level Clinical Quality Metrics Registry Depiction

OHA RFI #3857 -

- 13

3.3.4 Minimum Functionality A. Data Ingestion. The CQMR must have the following data capture capabilities: 1. Ability to capture data from various transport methods (Direct secure messaging, etc.) 2. Ability to capture data from disparate original sources (multiple EHR products) 3. Ability to capture data from disparate intermediate sources (HIE platforms, etc) 4. Ability to capture, transform, and load data in both individual patient and aggregate levels 5. Ability to capture, transform, and load source data in various formats: XML, CSV, etc. 6. Ability to capture, transform, and load source data that utilizes recognized standards such as HL7 CCDA (CCD, QRDA I and III, etc.) 7. Ability for the solution to identify and correctly parse/classify by payer info 8. Ability for the solution to store historical data B. User Interface. The user interface of the CQMR must include the following capabilities: 1. Solution includes a secure web based portal for data upload 2. Solution includes a secure web based portal for data display 3. Interface supports role-based access 4. Interface supports parent/child hierarchical relationships to facilitate ‘drill-down’ and ‘roll-up’ stratifications of the data in the following dimensions (at a minimum): a. Coordinated Care Organization (CCO) b. Clinic/health system c. Clinic/health system, by Site (if applicable) d. Provider e. Patient 5. Interface supports the display of data ‘over time’ (e.g. run chart format) with applicable benchmarks for each measure C. Data Export. The CQMR must have the following data export capabilities: 1. Ability for users to query the data repository for results using a front end user interface (i.e. a webbased portal or other access solution) 2. Account and Access Management features that allow all end users to create and manage their account, security, and access to the clinical quality data repository. 3. Ability to export data from the solution in machine readable format 4. Ability to export data from the solution in human readable format such as HTML, PDF, Excel. In addition to the uses as outlined above, OHA is seeking input from vendors on additional functionality available through a CQMR solution that may provide value to OHA, the CCOs, or provider stakeholders. Please see Attachment 4 for additional details.

3.3.5 Business Operational Requirements Beyond the technical aspects, OHA is also interested in contracting for the management of day-to-day operations that support the clinical metrics program including: 1) Managing the technical instance of the solution, whether hosted, Software as a Service, or cloud-based, including appropriate backup and test instances. 2) Managing the onboarding process and ongoing management of network participation for 3) Authorized users such as State agencies and employees, users at practices; and CCOs 4) Permitted data contributions (flat-file, EHR generated messages) 5) Ensuring data access and permitted uses of the CQMR are being followed 6) Assessing policy compliance and take action for non-compliance 7) Providing user support and technical assistance 8) Updating technical assistance or help manuals and other training documentation OHA RFI #3857 -

- 14

9) Communicating about the program including information on expected outages or updates

3.4 Other Considerations (Optional) Respondents to this RFI are encouraged to indicate if your solution does or can provide any of the services described in this section.

3.4.1 Patient/Provider Attribution (PPA) PPA is one of the major components of the Phase 1.5 portfolio as described in the HIT Final Business Plan Framework referenced in Attachment 5 and listed in the Roadmap Chart (Figure 2 of Attachment 5). PPA is needed to associate patients with providers across multiple healthcare delivery locations and settings for quality reporting, to support care coordination, and to support new payment methods. There are several potential sources of data that should be useful to resolving the PPA needs. For example: 1. There are elements of provider-to-location or provider-to-entity relationships in the envisioned PD solution. 2. There are elements of provider-to-patient relationships in the quality reporting that will occur in the CQMR solution. 3. The state is also participating in the planning for a Notifications system, although that system will not be developed as a state-owned system. A notifications system will have patient-provider relationships to support its primary function and could be a source of data for patient/provider attribution needs elsewhere. As currently being planned, the notifications database will grow incrementally over time as new subscriptions are added to the service. 4. There are also provider-to-entity and provider-to-patient relationships indicated in records in the APAC Database and in the state’s MMIS. OHA is considering how to structure a solution to the PPA needs, but has not yet determined if another solution needs to be specified and procured. At a minimum, though, OHA needs tools to enable the use of data from existing and planned HIT solutions as described above. OHA requests that responders provide their thoughts and/or describe their solutions to resolving these PPA needs. There are also a few future considerations for patient-provider attribution, namely: 1. The ability to integrate new data sources as interfaces to new solutions are implemented. 2. The ability to provide electronic service information, such as Direct addresses and query endpoints, for possible locations of patient health information in response to electronic requests, i.e., ability to act as a Record Locator Service (RLS).

3.4.2 Fiscal Agent Services The state intends that the vendors providing the CQMR and the PD services will also operate those services for OHA. A third solution, not part of this RFI, will provide Common Credentialing services and will also be provided by a vendor operating that solution for OHA. The expenses for the Common Credentialing solution are to be covered by fees. There may be other fees or subscription charges associated with either the CQMR or the PD, or other services in the future. The state is considering the services of a fiscal agent to serve as a central service / clearinghouse to consolidate service charges by provider or entity into a single invoice, receive revenues, allocate receipts appropriately to individual accounts for each service covered, and report results to the state as required.

OHA RFI #3857 -

- 15

Figure 1: Fiscal Services Schematic

SECTION 4: GENERAL TERMS, CONDITIONS AND PROCEDURES 1) Ownership of all data, material and documentation originated and prepared for OHA pursuant to this RFI response will belong exclusively to OHA. 2) OHA is not responsible for any expenses and/or costs incurred by Respondent in submitting their response to this RFI. Each Respondent does so solely at that Respondent’s own cost and expense. 3) OHA encourages respondents to provide a budgetary cost estimate on an annual basis over a seven (7) year period of product licensing, implementation, maintenance and operation to follow best practices demonstrating total cost of ownership. 4) All Respondents understand and agree that OHA is not obligated to include any Respondent in any future solicitation process by distributing an RFI or RFP to them, nor is OHA obligated to contract with any Respondent. 5) News releases pertaining to this RFI or the services, or project to which it relates shall not be made without prior OHA approval.

SECTION 5: HOW TO RESPOND Each vendor or vendor team who would like to submit a response and participate should complete and submit the attached Attachment 1 – “Vendor General Information”. Depending on which topics vendors choose for response, vendors are requested to complete one or more of the remaining response templates: Attachment 2 “Solution Details: SI”; Attachment 3 - “Solutions Details: PD”; Attachment 4 - “Solutions Details: CQMR”. Vendors are requested to submit two (2) hard copies and one (1) electronic copy on CD-ROM. Response should arrive by courier (USPS, FedEx, UPS, etc.) or hand delivery. Delivery and cost of delivery is the sole responsibility of Respondent. Vendors may submit electronic responses that are no larger than 4 megabytes. Vendors choosing to submit electronic responses are responsible for managing their submission within this size restriction and understand that the State is not responsible for electronic responses that are not received for any reason, including mail filtering, size limits, etc.. Electronic submissions must be transmitted with sufficient time to ensure receipt by the required date and time for submissions (see below). OHA RFI #3857 -

- 16

FAX (facsimile) responses will not be accepted. Respondent must identify the title of the Response, date of Response, name of Respondent, address, telephone number, fax number, e-mail address, and name of primary contact. Your response must be received by December 18, 2014 3:00 P.M., Pacific Standard Time. Responses should be delivered to: Traci Friedl, Contract Specialist Office of Contracts & Procurement 800 NE Oregon St, Suite 640 Portland, OR 97232 [email protected]

SECTION 6: CONFIDENTIAL OR TRADE SECRET INFORMATION Respondents are advised that most documents in the possession of OHA are considered public records and subject to disclosure under the State Public Records Law (ORS 192.410 to 192.505). An exemption from disclosure is provided for trade secrets. If any part of the information given is considered a trade secret, the vendor must clearly designate that portion as confidential in order to protect it from disclosure. Simply marking a section “confidential” will not ensure protection. Vendor must be prepared to advance the reasons why the material is a trade secret; OHA agrees to maintain information deemed a trade secret confidential to the extent permitted by law.

SECTION 7: CONTACT INFORMATION For any questions regarding the content of this RFI, vendors may send their questions by e-mail (only) to the single point of contact for this RFI. All questions regarding this RFI must be e-mailed no later than 5:00 PM Pacific Standard Time, December 2, 2014, to the Sole Point of Contact at [email protected]. Please note that e-mail attachments cannot exceed 4MB. OHA will post responses to questions received on the ORPIN website (see below). Depending on the volume and nature of questions received OHA may schedule a vendor call to respond to certain questions. Notifications of questions answered or scheduled vendor calls will be posted on ORPIN under this RFI 3857. All RFI 3857 documentation is also listed on the ORPIN web site: http://orpin.oregon.gov/open.dll/welcome, using RFI number 3857. VENDORS SHOULD CONSULT THE ORPIN SYSTEM REGULARLY, UP TO AND INCLUDING THE CLOSING DATE AND TIME, TO ASSURE THAT YOU HAVE NOT MISSED ANY RFI ANNOUNCEMENTS VENDORS ARE RESPONSIBLE FOR ENSURING THAT THEIR CONTRACTOR INFORMATION IS CURRENT AND CORRECT: OHA IS NOT RESPONSIBLE FOR INCORRECT OR INCOMPLETE CONTRACTOR INFORMATION ON ORPIN.

SECTION 8: DISCLAIMER This RFI is issued solely for information and planning purposes; it does not constitute a solicitation. There will not be an evaluation or scoring of the material submitted. Information received in response to this RFI will not be returned. Responses to this notice are not considered an offer and cannot be accepted by the State of Oregon to form a binding contract. All costs submitted with the RFI are for OHA budget purposes only and are not considered to be a bid. Responders are solely responsible for all expenses associated with responding to this RFI. Respondents will not be notified as a result of this RFI or interviews. Participating OHA RFI #3857 - 17 -

in this RFI and any related presentations is not a requirement for responding to the RFP and does not affect the ability to participate in the RFP process.

SECTION 9: PRESENTATIONS Formal demonstrations are not planned at this time. However, OHA reserves the right to schedule demonstrations among potential vendors. Vendors who, at the sole assessment of the State, respond in a manner indicating they possess the knowledge, skills, and capabilities may be invited to make a presentation or be provided an opportunity to demonstrate their system capabilities in an open public forum. NOTE: It is at OHA’s sole discretion to schedule demonstrations among vendors submitting a response to this RFI. OHA discourages uninvited requests to provide presentations.

SECTION 10: PROJECT DATES AND MILESTONES •

RFI posted on November 18, 2014

•

RFI Questions concerning the RFI due on December 2, 2014 by 5:00 PM

•

Answers to Questions posted on December 8, 2014 (Estimated date)

•

RFI responses due on December 18 , 2014 by 3:00 PM o

NOTE: The State reserves the right to modify these dates at any time.

INTERESTED VENDORS SHOULD CONSULT THE ORPIN SYSTEM REGULARLY, UP TO AND INCLUDING THE CLOSING DATE AND TIME, TO ASSURE THAT THEY HAVE NOT MISSED ANY RFI ANNOUNCEMENTS.

OHA RFI #3857 -

- 18

ATTACHMENT 1: Vendor information and response reference sheet

Vendor Name:

Date:

Contact Name: Contact Address: Contact E-mail: Contact Telephone: Website address: Other contact address: Year Company was Founded: Number and Location(s) of Employees:

Vendor “About us” 1) Is your solution operated and maintained by your company or is it hosted or managed by another company? 2) Describe how your organization remains current with and manages changes in national standards. 3) List any related applications or services that you offer that you feel should be considered in this section.

Vendor Approach Suggested Solution: Please indicate in Table 1 below the components that you are addressing in your response with a brief summary of your approach in a few bullets. Table 1: Response Reference Sheet RFI Select the components from this RFI that your Component company or product can address Project & Risk management (Attachment 2 – A; C) Operations (Attachment 2 – D) Systems Interfaces (Attachment 2 – C; E) Integrator Access Solutions (Attachment 2- C; E) X Financial Considerations (Attachment 2 – F) Operation (Attachment 3 – C) Provider Solution & Technology (Attachment 3 – B; D) Directory X Costs (Attachment 3 – E) X Optional: Fees (Attachment 3 – F) Operation (Attachment 4 – C) Clinical Quality Solution & Technology (Attachment 4 – B; D) Metrics X Costs (Attachment 4 – E) Registry X Optional: Fees (Attachment 4–F) Patient/Provider Attribution (Section3. 4.1) Other/Optional: Fiscal agent (Section 3.4.2)

Briefly summarize your approach to the components you selected in a few bullet points

- 19 -

Overall Approach (how do the selected components fit in with a total solution for this RFI)

OHA RFI #3857 -

- 20

ATTACHMENT 2: Systems Integrator Solution Details

Section A: Program Management Structure Please submit a RACI diagram of the program management structure that will demonstrate the accountability for delivery of the Provider Directory and CQMR solutions as well as the SI requirements defined in this RFI.

Section B: Architecture / Interfaces Please include a supporting narrative that answers the following: 1) The technology used for the required interfaces including programming languages and database management system. 2) The scalability of your interface solution and database including the number of systems that could be integrated with the solution and the level of effort required. 3) Can your solution resolve the requirements as defined? Please clearly indicate no if it cannot. 4) What incremental development may be required to achieve the solution? 5) How would you resolve the defined requirements utilizing the other solutions described in this RFI? 6) Indicate your experience in providing a solution that meets the requirements. 7) Include descriptions and details of your approach to the functionality as defined. 8) Please indicate how you would provide such services, and what data flows and interfaces would be required to support the execution of such services, including but not limited to existing data sources such as APAC and MMIS.

Section C: Functions Please complete Table 2 below that outlines desired functions of the SI. Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. o

For vendors responding to the SI portion of this RFI, please indicate how you would resolve the PPA requirements (see discussion in Section 3.4.1) utilizing the other solutions described in this RFI, with or without additional data sources such as APAC and MMIS, and identify any necessary interfaces. Also indicate if you are not prepared to resolve the PPA requirements as part of your described SI services.

Table 2: Systems Integrator Functions

Function

Yes

No

# Years of experience

Contract Negotiation Program Management Project Management Risk Management Integrating Government Agencies Operated Systems with External Systems Integrating Claims and Clinical Data Single Access Solution Management Across Systems Multiple system interfaces - 21 -

Data Management

Section D: Operations Please indicate your experience for each operational component in Table 3 Please complete each row. If a component is not applicable to your response, please indicate this with an N/A for that row. Note that the vendor(s) who will ultimately provide the PD and CQMR solutions are expected to provide the ongoing operation of those solutions for OHA. The SI experience in similar operational situations will help OHA to determine the extent to which a SI might have oversight responsibilities for these solutions once they enter the operational phase. This note also applies to our request for experience with Information Security in Section 4 below. Note also that OHA anticipates ongoing additional incremental implementation of these solutions following the initial implementations and that the SI will have an ongoing role of contracting and project management oversight of those incremental implementations, along with any additional interface or interoperability requirements. Table 3: Systems Integrator Operational Components

Type of operational component


Manage and oversee the onboarding process including access and approvals for users of the system (data access, data use, and network participation) Manage and oversee ongoing user support and maintenance Manage the onboarding process for the integration of new data sources for the PD and CQMR (interfaces) Manage the day to day operations to ensure interfaces are running properly Assess quality of the data and data sources in both the PD and CQMR (both initially and ongoing) Assess and take action for non-compliance with PD and CQMR policies Serve as a central service / clearinghouse to consolidate service charges by provider or entity into a single invoice, receive revenues, allocate receipts appropriately to individual accounts for each service covered, and report results to the state as required. Please respond to the following questions, noting the component as outlined in Table 3 As applicable, please reference specific systems or standards that the solution utilizes. 1. The onboarding process for new users. Please include what steps are taken to ensure access to the solutions is appropriate. 2. How your organization would ensure appropriate use of the solutions over time. 3. The onboarding process for new data sources that will be incorporated into the solutions. Please include what types of processes are in place to ensure the data source meets quality standards. 4. How your organization would ensure the quality of data meets quality standards over time. 5. Does your organization have a Quality Assurance Plan and how it is audited for performance? 6. What approach would your organization use to achieve successful implementation and quick adoption of the solutions? 7. Please provide a high-level timeline showing system development steps to achieve a successful implementation of the PD by mid-2016, and of the CQMR by spring, 2016. 8. What are types and frequency of training, communications, and support your organization could provide for end-users? 9. How would your organization ensure a partnership with OHA and conduct regular policy research in order to identify changing needs that could benefit from the services to be delivered through the SI? 10. What types of user support are offered, including normal support hours, where support staff is located, response time, etc.? 11. How would your organization engage end-users to provide input on the solutions? OHA RFI #3857 -

- 22

12. What business continuity plans does your organization have in place? 13. The state is considering the services of a fiscal agent to serve as a central service / clearinghouse to consolidate service charges by provider or entity into a single invoice, receive revenues, allocate receipts appropriately to individual accounts for each service covered, and report results to the state as required. a. Please indicate how you would provide such fiscal services, and what data flows and interfaces would be required to support the execution of such services. 14. Strategies that could be used to backup data (including frequency) to minimize any loss during unplanned events that interrupt service; 15. How significantly the end-user performance must deviate before an alert is generated. 16. What tools exist for validating or disputing the presence of a problem when degradation is reported; 17. What tools exist for isolating exactly what part of the solution (application server, database server, network, workstation, etc.) is responsible for degraded performance; 18. What monitoring and measurement reports would be available to validate your last six months of system up-time and consistent performance of the service.

Section E: Information Security Please complete Table 4 below that outlines desired functions of the SI integration. Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. Table 4: Systems Integrator Information Security

Component

Yes

No

Comments/Clarifications, including notes on future version potential – include appropriate dates/details

Industry standard security safeguards for data and HIPAA-compliance for any protected health information Use Authentication Database Connectivity Password Validation Encryption Please respond to the following questions, noting the component as outlined in Table 4. As applicable, please reference specific systems or standards that the solution utilizes. • Describe the physical, system, and network security policies and controls in place, including but not limited to firewalls, intrusion detection, administrator authentication and authorization, operating system and software patching, malware and virus detection, etc.

Section F: Financial Considerations Describe the licensing, implementation, maintenance, operation, and any other related costs estimated on an annual basis over a seven (7) year period to follow best practices demonstrating total cost of ownership. If you are responding to more than one component (e.g., SI, PD, CQMR, Other, Fiscal Agent, Patient-Provider Attribution), describe each separately and include how the costs may be pooled with multiple solutions.

OHA RFI #3857 -

- 23

ATTACHMENT 3: Provider Directory Solution Detail

Section A: Architecture Diagram and Narrative 1. Please submit a diagram that depicts how your solution meets the Provider Directory requirements. 2. Please include a supporting narrative that answers the following: a. Please describe the key uses that would be addressed in each release of functionality and how you would recommend the prioritization and order of releases. b. The scalability of your solution and database including the number of providers that could be serviced with the solution and the number of simultaneous sessions and users the solution could support. c. Your experience with working with multiple data contributors and vendors to receive, aggregate, and share data. Please include years of experience, number of projects, and description of the work you performed. d. Your organization’s Quality Assurance Plan and how it is audited for performance. e. The ability of the solution to be modified, enhanced, and adapted to meet changing needs, including how your solution can add new fields after the system has been implemented. f. How transmission interruptions (e.g., transmission failure, partial data updates, etc.) between your solution and data consuming sites are managed and resolved. g. Reporting capabilities (standard and ad hoc) of the solution and examples of reports for various users. h. The technology your solution is built upon including programming languages and database management system.

Section B: Functions Please complete Table 5 below that outlines some of the initial and future desired functions of the Provider Directory solution (see NOTE below). Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. Table 5: Provider Directory Functions Function

Comments/Clarifications, including notes on future version potential – include appropriate dates/details Minimum Initial Functionality (as described in section 3.3.4) Yes

No

Data access and storage Store and manage relationships between individuals and organizations when affiliated Store and manage general demographics information associated with an individual such as provider, including name, address, phone, NPI, specialty. Store and manage general demographics information associated with an organization, including name, addresses, phone, etc. Store historical information Integrate with the common credentialing solution (using an API or flat-file extraction) so that data elements from the OPCA can be integrated into the PD and kept current. Integrate with other authoritative data sources so that those data can be integrated into the PD and kept current. Provide a secure web portal for authenticated users that enables searches of the directory as well as external directories within the federation

OHA RFI #3857 -

- 24

Function

Yes

No


Provide a feature to produce and export data to subscribers for larger returns of data sets. Store electronic service information for individuals and organizations needed to facilitate exchange of health information, including Direct addresses and URLs for query endpoints. Support federation by orchestrating queries and providing aggregate responses. Orchestrate queries and responses from users to other directories both inside and outside Oregon. Orchestrate queries and responses from other directories both inside and outside Oregon to other Oregon directories, and providing an aggregated response. Orchestrate queries and responses from other Oregon directories to directories outside Oregon, and providing an aggregated response Data Standards Support directory queries and federation using IHE HPD (supporting CP 601or later) Support directory queries and federation using HPD Plus (v1.1 or later) Support directory queries and federation using Federated HPD Data Quality Provide and present a data quality assessment for data sources and elements to users. Provide a data cleansing or de-duplication process Assess quality of data and data sources contained in the directory Other Ad hoc query and reporting capabilities Capability to add additional system components or requirements or easily change business processes or rules, including the capability to add additional data fields, as influenced by new legislation or policy directives. Accessibility with very high availability – requires 99.99% reliability and minimal scheduled maintenance windows Use of business rules and data standards to protect data integrity Future Stage: (as described in section 3.3.6)

OHA RFI #3857 -

- 25

Function

Yes

No


Receive, store, and manage additional data elements that are not included in the standard data model for Federated-HPD or OPCA such as: - After-hours (nights/weekends), - Multiple types of contact information (e.g., Twitter, Facebook, etc.), - Patient-Centered Primary Care Home (PCPCH) tier Support geocoding for physical locations Provide a data entry interface and storage for data elements that may not be available from other data sources. NOTE: initially the PD is focusing efforts to be inclusive of all data elements in the Federated-HPD data model (http://modularspecs.siframework.org/Provider+Directories+Homepage) and OPCA (http://www.oregon.gov/oha/OHPR/ACPCI/docs/2012/2012credappglossary.pdf) with the potential for other additional elements. We would anticipate additional elements are added in later iterations and phases. The components identified in Table 5 are those we would like to see in the PD and may be included in Federated-HPD, OPCA, or neither.

Please respond to the following questions, noting the function as outlined in Table 5 As applicable, please reference specific systems or standards that the solution utilizes. 1) How the web portal displays records and how it manages the display of data when multiple data sources return information for an individual or entity in response to federated directory requests. 2) How your system handles multiple relationships of a provider to their clinics, groups, organizations, locations, specialties, hospitals, etc., including how those data are structured and kept current. 3) How your solution manages Direct addresses and other electronic address endpoints, affiliations, and preferences for health information exchange and if/how that information is verified. 4) The technology and data formats available with your solution to enable data-consuming sites to receive both current and historical data from the PD. 5) How your solution stores and manages historical provider information, including how historical data could be accessed and analyzed. 6) For both data management and access approaches, what, if any, phased approaches does your solution provide?

Section C: Solution and Technology Operations Please indicate your experience for each operational component in Table 6 Please complete each row. If a component is not applicable to your solution, please indicate this with an N/A for that row. Table 6: Provider Directory Operational Components Type of operational component (refer to section 3.3.5 Business Operational Requirements)


Manage the technical instance of the solution, whether hosted, Software as a Service, or cloud-based, including appropriate backup and test instances. Manage and oversee the onboarding process including access and approvals for users of the system (data access, data use, and network participation) Manage and oversee ongoing user support and maintenance Coordinate with a SI to provide outreach and assistance to potential data source contributors manage the onboarding process for the integration of new data sources for the directory (interfaces) Coordinate with a SI to manage the onboarding process and ongoing management of participation for permitted data contributions (interfaces)

OHA RFI #3857 -

- 26

Type of operational component (refer to section 3.3.5 Business Operational Requirements)


Coordinate with a SI to manage data, including handling and resolving data source discrepancies (e.g., when two data contributors submit a different data element for the same person or entity) or other data quality issues. Coordinate with a SI to manage the ongoing interfaces to ensure they are running properly and providers are able to access the directory. Assess and take action for non-compliance with PD policies Provide user support and technical assistance including: • Outreach and training to new and potential users • Writing, publishing, and maintaining user manuals • Help desk support to resolve issues and answer user questions Maintain program communications including information on expected outages or updates

Please respond to the following questions, noting the component as outlined in Table 6 As applicable, please reference specific systems or standards that the solution utilizes. 1) For the onboarding process for new users, please describe what steps are taken to ensure access to the directory is appropriate. 2) How your organization would ensure appropriate use of the directory over time. 3) How your organization would ensure the quality of data meets quality standards initially and over time (e.g., how you warrant that data are accurate, especially when some data elements change frequently). 4) How your organization reconciles data dissimilarities, when different data exist between two sources for the same data element. 5) What approach would your organization use to achieve successful implementation and quick adoption of the solution? 6) Please provide a high-level timeline showing system development steps to achieve a successful implementation by mid 2016. 7) What are types and frequency of training, communications, and support your organization could provide for end-users? 8) How would your organization ensure a partnership with OHA and conduct regular policy research in order to identify changing needs that could benefit from PD services? 9) What types of user support are offered, including normal support hours, where support staff is located, response time, etc.? 10) How would your organization engage end-users to provide input on the solution?

Section D: Information Security Please complete Table 7 below that outlines desired functions of the PD solution. Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. Table 7: Provider Directory Information Security Component

Yes

No


Industry standard security safeguards for data and HIPAA-compliance for any protected health information Data management procedures to corroborate that data has not been altered or destroyed

OHA RFI #3857 -

- 27

Audit trail capabilities Role-based access and rights

Please respond to the following questions, noting the component as outlined in Table 7 As applicable, please reference specific systems or standards that the solution utilizes. 1) Audit capabilities of your solution that may log activity to provide a complete audit trail of the specific user or practitioner record, describing the data elements that may be logged and how reports of activity could be available to system administrators. 2) Describe the physical, system, and network security policies and controls in place, including but not limited to firewalls, intrusion detection, administrator authentication and authorization, operating system and software patching, malware and virus detection, etc.

Section E: Financial Considerations Describe the licensing, implementation, maintenance, operation, and any other related costs estimated on an annual basis over a seven (7) year period to follow best practices demonstrating total cost of ownership. If you are responding to more than one component (e.g., SI, PD, CQMR, Other, Fiscal Agent, Patient-Provider Attribution), describe each separately and include how the costs may be pooled with multiple solutions.

Section F: Fees If you have participated in solutions that involved fees for any of the services listed, include an example of a fee structure for participation fees or subscription charges that supports financing sustainability of the system and program. If you don’t have specific experience with fee structures for such services you can (optional) describe a fee structure to demonstrate how you would approach the fee question.

OHA RFI #3857 -

- 28

ATTACHMENT 4: Clinical Quality Metrics Registry Solution Details

Section A: Architecture Diagram and Narrative Please submit a diagram that outlines the current architecture of the CQMR solution, identifying major components (integration engines, databases, etc.) by product, vendor, and version name where applicable. Please include a supporting narrative that answers the following: 1) Please describe the key uses as outlined in Section 3.4 that would be addressed in each release of functionality and how you would recommend the prioritization and order of releases. 2) The scalability of your solution and database including the number of providers that could be serviced with the solution and the number of simultaneous sessions and users the solution could support. 3) Your experience with working with multiple data contributors and vendors to receive, aggregate, and share data. Please include years of experience, number of projects, and description of the work you performed. 4) Your organization’s Quality Assurance Plan and how it is audited for performance. 5) The ability of the solution to be modified, enhanced, and adapted to meet changing needs, including how your solution can add new fields after the system has been implemented. 6) How transmission interruptions (e.g., transmission failure, partial data updates, etc.) between your solution and data consuming sites are managed and resolved. 7) Reporting capabilities (standard and ad hoc) of the solution and examples of reports for various users. 8) The technology your solution is built upon including programming languages and database management system.

Section B: Functions Please complete Table 8 below that outlines desired functions of the CQMR solution. Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. Table 8: CQMR Functions Function

Comments/Clarifications, including notes Currently Not currently on future version potential – include available available appropriate dates/details

Minimum functionality Data Ingestion Ability to capture data from various transport methods (Direct secure messaging, etc.) Ability to capture data from disparate original sources (multiple EHR products) Ability to capture data from disparate intermediate sources (HIE platforms, etc) Ability to capture, transform, and load data in both individual patient and aggregate levels Ability to capture, transform, and load source data in various formats: XML, CSV, etc. Ability to capture, transform, and load source data that utilizes recognized standards such as HL7 CCDA (CCD, QRDA I and III, etc) Ability for the solution to identify and correctly parse/classify Medicaid patient data from nonMedicaid patient data Ability for the solution to store historical data User Interface

- 29 -

Function

Comments/Clarifications, including notes Currently Not currently on future version potential – include available available appropriate dates/details

Solution includes a secure web based portal or other access solution for data upload Solution includes a secure web based portal for data display Solution supports role-based access Solution supports parent/child hierarchical relationships to facilitate ‘drill-down’ and ‘rollup’ stratifications of the data • Coordinated Care Organization (CCO) • Clinic/health system • Clinic/health system, by Site (if applicable) • Provider • Patient Data Export Ability for users to query the data repository for results using a front end user interface (i.e. a web-based portal) Account and Access Management features that allow all end users to create and manage their account, security, and access to the clinical quality data repository. Ability to export data from the solution in machine readable format Ability to export data from the solution in human readable format such as HTML, PDF, Excel Future stage (known) Ability to capture, transform, and load measure data for other quality program reporting; this may include measures from HEDIS, NCQA, UDS, etc. Additional descriptive analytics capabilities such as parsing by race, ethnicity, zip codes, etc. Future stage (potential) Predictive analytics capabilities End- user access to database/ data warehouse for additional ad-hoc analysis Ability for users to query the data repository for results using a structured database query (e.g. SQL Management Studio). Ability to interface with existing OHA databases (All Payer All Claims, Medicaid Management Information System, etc.)

Please respond to the following questions, noting the functions as outlined in Table 8. As applicable, please reference specific systems or standards that the solution utilizes.

Infrastructure 1) What are some examples of data sources the solution utilizes or could utilize? OHA RFI #3857 -

- 30

2) Is the solution able to mitigate for data in non-standard formats? If so, how? 3) Does the solution support data ingestion via both data-push and data-pull models? a. Alerting providers to negative result trends based on data submitted over time and identifying clinics and hospitals that are in danger of not meeting established quality levels of service.

Measures 1) How does the CQMR solution currently support collection, aggregation, display, and export of the following eCQMs? a. NQF 0418 b. NQF 0018 c. NQF 0059 2) How does the CQMR currently support collection, aggregation, display, and export of all 93 eCQMs utilized by Eligible Professionals and Eligible Hospitals participating in the EHR Incentive Program? If the solution supports some but not all of the 93 eCQMs, please provide a list. 3) How does the CQMR currently support collection, aggregation, display and export of measures included in other quality measure reporting programs? e.g., HEDIS, NCQA, UDS, etc.

Analytics 1) Please provide an overview of additional analytics services your solution provides. This may include the following (please note these items are not requirements of the CQMR solution): a. Configurable automatic notification system for providers, clinics, and hospitals to receive alerts based on defined data results and thresholds from the submitted clinical quality data. b. Alerting providers to negative result trends based on data submitted over time and identifying clinics and hospitals that are in danger of not meeting established quality levels of service.

Section C: Solution and Technology Operations Please indicate your experience for each operational component in Table 9 Table 9: CQMR Operational Components Type of operational component


Manage the technical instance of the solution, whether hosted, Software as a Service, or cloud-based, including appropriate backup and test instances. Manage and oversee the onboarding process including access and approvals for users of the system (data access, data use, and network participation) Manage appropriate collection and distribution of patient level information to various stakeholders (OHA, CCOs, providers) Manage and oversee ongoing user support and maintenance Manage the onboarding process for the integration of new data sources for the solution (interfaces) Manage the day to day operations to ensure the solution is are running properly Assess quality of the data and data sources in the solution (both initially and ongoing) Assess and take action for non-compliance with solution policies

Please respond to the following questions, noting the component as outlined in Table 9. As applicable, please reference specific systems or standards that the solution utilizes. OHA RFI #3857 -

- 31

1) The onboarding process for new users. Please include what steps are taken to ensure access to the CQMR is appropriate. 2) How your organization would ensure appropriate collection and distribution of patient level information to various stakeholders’ (OHA, CCOs, providers) use of the CQMR over time. 3) The onboarding process for new data sources that will be incorporated into the CQMR. Please include what types of processes are in place to ensure the data source meets quality standards. 4) How your organization would ensure the quality of data met quality standards over time. 5) What is your organization’s Quality Assurance Plan and how is it audited for performance? 6) What approach would your organization use to achieve successful implementation and quick adoption of the solution? 7) Please provide a high-level timeline showing system development steps to achieve a successful implementation by spring, 2016. 8) What are types and frequency of training, communications, and support your organization could provide for end-users? 9) How would your organization ensure a partnership with OHA and conduct regular policy research in order to identify changing needs that could benefit from CQMR services? 10) What types of user support are offered, including normal support hours, where support staff is located, response time, etc.? 11) How would your organization engage end-users to provide input on the solution? 12) What business continuity plans does your organization have in place? 13) Strategies that could be used to backup data (including frequency) to minimize any loss during unplanned events that interrupt service; 14) How significantly the end-user performance must deviate before an alert is generated. 15) What tools exist for validating or disputing the presence of a problem when degradation is reported; 16) What tools exist for isolating exactly what part of the solution (application server, database server, network, workstation, etc.) is responsible for degraded performance; 17) What monitoring and measurement reports would be available to validate your last six months of system up-time and consistent performance of the service

Section D: Information Security Please complete Table 10 below that outlines desired functions of the CQMR solution. Please complete each row. If a function is not applicable to your solution, please indicate this with an N/A for that row. Table 10: CQMR Information Security Functions Function

Yes

No

Comments including notes on future version potential – include dates/details as appropriate

Industry standard security safeguards for data and HIPAAcompliance for any protected health information Data management procedures to corroborate that data has not been altered or destroyed Audit trail capabilities Role-based access and rights

Please respond to the following questions, noting the component as outlined in Table 10 As applicable, please reference specific systems or standards that the solution utilizes. OHA RFI #3857 -

- 32

1) Audit capabilities of your solution that may log activity to provide a complete audit trail of the specific user or practitioner record, describing the data elements that may be logged and how reports of activity could be available to system administrators; 2) Describe the physical, system, and network security policies and controls in place, including but not limited to firewalls, intrusion detection, administrator authentication and authorization, operating system and software patching, malware and virus detection, etc.

Section E: Financial Considerations Describe the licensing, implementation, maintenance, operation, and any other related costs estimated on an annual basis over a seven (7) year period to follow best practices demonstrating total cost of ownership. If you are responding to more than one component (e.g., SI, PD, CQMR, Other, Fiscal Agent, Patient-Provider Attribution), describe each separately and include how the costs may be pooled with multiple solutions.

Section F: Fees If you have participated in solutions that involved fees for any of the services listed, include an example of a fee structure for participation fees or subscription charges that supports financing sustainability of the system and program. If you don’t have specific experience with fee structures for such services you can (optional) describe a fee structure to demonstrate how you would approach the fee question.

OHA RFI #3857 -

- 33

ATTACHMENT 5: Oregon Health IT Background Oregon is on an extraordinary path to transform the delivery of health care to improve health outcomes, quality of care, and reduce costs. This “health system transformation” effort is premised on a model of coordinated care that includes new methods for care coordination, accountability for performance, and new models of payment based on outcomes and health. To succeed, the coordinated care model relies on new systems for capturing, analyzing, and sharing information about patient care and outcomes, quality of care, and new modes of sharing care information amongst all members of care teams. (This background discussion is excerpted from Oregon’s Business Plan Framework for Health Information Technology and Health Information Exchange (2014-2017), Health Information Technology Task Force Recommendations, Oregon Health Authority, May 30, 2014 http://www.oregon.gov/oha/OHPR/HITOC/Documents/HIT_Final_BusinessPlanFramework_ForRelease_201405-30.pdf ), hereafter referred to as the “HIT Framework”. In 2012, the Oregon Health Authority (OHA) focused first on its Medicaid population, implementing the coordinated care model through new coordinated care organizations (CCOs). These regional care networks bring all types of health care providers (physical health, behavioral health and dental) together to deliver coordinated care, while being held accountable for outcomes. CCOs now operate in every county in Oregon, and cover more than 90 percent of Oregonians on Medicaid. Moving forward, Oregon is working to accelerate and spread the coordinated care model beyond the Medicaid population to public employees, Medicare, and private payers. Because HIT/HIE services are necessary to support health system transformation, OHA has worked closely with a wide range of stakeholders to identify HIT/HIE needs, and specifically identify how the State and statewide services could address some of those needs. In fall of 2013, OHA convened an HIT Task Force to synthesize stakeholder input and develop a HIT/HIE Business Plan Framework to chart a path for statewide efforts over the next several years. This stakeholder process led to a vision for Oregon of a transformed health system where HIT/HIE efforts ensure that the care Oregonians receive is optimized by HIT. “HIT-optimized” health care is more than the replacement of paper with electronic or mobile technology. It includes changes in workflow to assure providers fully benefit from timely access to clinical and other data that will allow them to provide individual/family centric care.

Oregon’s HIT-optimized health care system: • Providers have access to meaningful, timely, relevant and actionable patient information to coordinate and deliver “whole person” care. • Systems (health systems, CCOs, health plans) effectively and efficiently collect and use aggregated clinical data for quality improvement, population management and incentivizing health and prevention. In turn, policymakers use aggregated data and metrics to provide transparency into the health and quality of care in the state, and to inform policy development. • Individuals and their families access their clinical information and use it as a tool to improve their health and engage with their providers. •

Oregon’s Phased Development of HIT/HIE services: • The first phase of development (2010-2013) saw the advent of a statewide strategic plan and the launch of CareAccord®, Oregon’s State HIE. • The next phase is upon us (2014-2016): OHA is currently working with CCOs and stakeholders to develop and implement statewide HIT/HIE priority elements that are necessary to support health system transformation. The SI, PD, and CQMR solutions are a part of the work in this phase. • The Business Plan Framework envisions a following phase (2016 and beyond) that expands statewide services and anticipates new partnership governance structures to implement and operate statewide HIT/HIE efforts. OHA RFI #3857 -

- 34

Oregon’s HIT/HIE Roadmap See the Roadmap chart below for an outline of these phases. Figure 2: HIT/HIE Roadmap

Note that in the roadmap figure the Provider Directory is a component of the Enabling Infrastructure and that the CQMR is a component of the Services for Medicaid, both components being included in the Technology and Services layer in Phase 1.5.

Anticipated Integration or Interfacing of Services Other HIT/HIE vendors and systems that will need to be considered in the implementation of the solutions in this RFI are included in Attachment 6. It is anticipated that respondents will consider the technology landscape from which users will be accessing the described solutions when planning for an integrated implementation. In addition to the solutions covered in this RFI there are other solutions currently in service or expected during the period the RFI solutions will be operational that need to be included in planning for a successful implementation. Some of these systems may be vital data sources, others may rely on data from the RFI solutions, and all of them are potential partners for a solution to reduce the workflow burden to access the solutions. In the Scope of Request section for each of the solutions the minimum initial requirements and some expected future requirements, will specify the systems each solution must interoperate with at which stage.

OHA RFI #3857 -

- 35

Figure 3: Interfaces and Data Flows

HIE, Direct Secure Messaging, and CareAccord® The HIT Framework recommends that Community / Organizational HIEs and health systems will provide HIE coverage to some (there are several such HIEs currently operating), that there should be common services to provide baseline HIE capabilities to others, and that a statewide enabling infrastructure should tie these components together. Oregon is supporting a vision of statewide Direct secure messaging to create the ability to share key health information electronically across organizational and technological boundaries. This approach will exploit the availability of Direct secure messaging as a core service within each certified EHR, once these EHRs are upgraded to 2014 standards. The state operates the CareAccord® program which provides Direct secure messaging (https://www.careaccord.org/) to facilitate the secure exchange of health information between Oregon’s health care organizations and providers. CareAccord is currently operational in Oregon and is operated by Harris Healthcare Solutions in collaboration with Mirth and EasyStreet. This program and the utilization of Direct secure messaging in Oregon will benefit from the Provider Directory, which will provide Direct secure messaging addresses as part of the provider information in the directory.

Common Credentialing With the passage of Senate Bill 604 in the 2013 regular Legislative session, the Oregon Health Authority (OHA) is required to establish a program and database for the purpose of providing credentialing organizations access to OHA RFI #3857 -

- 36

information necessary to credential all health care practitioners in the State. More specifically, the legislation permits OHA, in consultation with the health care practitioners, credentialing organizations, and health care regulatory boards, to determine the source data that must be submitted by health care practitioners and utilized by credentialing organizations. Currently a Request for Proposals for a Common Credentialing solution is being prepared and will be posted this winter. Common Credentialing and Provider Directory efforts have many opportunities for synergies; OHA intends to achieve all possible alignment between these efforts. . SB 604 requires the Common Credentialing solution to be operational by in 2016. OHA intends to have this solution in production to provide sufficient time to populate the underlying database. Common Credentialing can provide an excellent data source for the Provider Directory.

Statewide Hospital Notifications OHA is participating with the Oregon Health Leadership Council to bring Emergency Department Information Exchange (EDIE) technology to all hospitals in Oregon in 2014. The EDIE project will provide emergency departments with key care summaries for patients who have high utilization of emergency department services, with the goal of reducing unnecessary hospital services and improving outcomes. Statewide hospital notifications will leverage the data collected in EDIE, which will become available starting in 2015, by notifying providers, CCOs, health plans, and care coordinators when their members or patients have been seen in any hospital in the State. The EDIE technology is provided by Collective Medical Technologies, Inc. More information about this initiate is available at http://www.orhealthleadershipcouncil.org/our-current-initiatives/emergency-departmentinformation-exchange-edie . Additional comments about Hospital Notifications as related to the Systems Integrator portion of this RFI are included in Section 3.1.2.

Additional Phase 1.5 Components While not appearing on the diagram above, the following are important components of Phase 1.5 of the HIT Framework: • Patient/Provider Attribution (PPA) - PPA is needed to support care coordination and new payment methods, to accurately determine patient volume threshold percentages for eligibility to the Medicaid EHR Incentive Program, and to associate patients with providers across multiple healthcare delivery locations and settings for quality reporting. There are elements of provider-to-location or entity relationships in the envisioned Provider Directory solution, and there are elements of provider-to-patient relationships in the quality reporting that will occur in the CQMR solution. There are other systems and solutions that may contribute to a PPA solution. PPA is discussed further in Section 3.4 - Other Considerations in this RFI. • Technical Assistance to Eligible Providers – Oregon has obtained Medicaid funding to provide technical assistance to Medicaid providers to support them in the Meaningful Use of their EHRs. Technical assistance will help providers to effectively use their EHR technology and realize the benefits of their investments in EHRs. By helping providers use workflows that support accurate entry of information into their EHRs, technical assistance increases the reliability of clinical data extracted from EHRs, improving the credibility of EHR data, in turn, bolsters provider confidence in clinical quality measures. Technical assistance also supports the aim of promoting EHR adoption and Meaningful Use, and will help Medicaid providers meet requirements to qualify for EHR incentive payments. In particular, this assistance can help further goals of achieving statewide Direct secure messaging by assisting providers seeking to meet Meaningful Use Stage 2 requirements related to using Direct secure messaging. Technical assistance contracts are anticipated to be in place in spring, 2015, contingent upon CMS approval.

OHA RFI #3857 -

- 37

Timing of Phase 1.5 Solutions • Operational dates for all Phase 1.5 solutions will be more accurately determined as project plans are finalized with selected vendor solutions. The following notes describe the relative timing of these solutions: CareAccord® is the state’s program for Direct secure messaging and is already operational. Future efforts are focused on expanding the usage of this service and enhancing its features. • Statewide Hospital Notifications has been described in section 3.4.1 above. The initial EDIE implementation for hospitals will be largely completed by yearend 2014. Enhanced features of the notifications solution, called EDIE Plus and PreManage, will be implemented in 2015. • Technical Assistance, to be provided through a vendor selected through an RFP process, is projected be begin in 2015. • The Common Credentialing solution is actively being pursued for procurement and an RFP release is anticipated this winter and OHA expects operations to begin in 2016. • The Provider Directory and CQMR projects are part of the bundled procurement described in this RFI and will be pursued in parallel procurement and implementation paths. OHA anticipates implementation being underway by the third quarter of 2015, with service operational in spring, 2016 for CQMR and in mid-2016 for PD. • Patient Provider Attribution requires more planning to determine a specific solution path, though service in 2016 is anticipated.

OHA RFI #3857 -

- 38

ATTACHMENT 6: Oregon Health IT Products & Vendors Oregon’s Health Information Technology (HIT) vendor landscape is varied. Oregon providers utilize more than 90 EHR vendors while 10 EHR vendors are in use by Oregon’s hospitals. Three unique platforms are utilized by Oregon’s four operating Health Information Exchanges (HIEs). In addition, a number of CCOs, health systems, and regional HIEs utilize ‘off-the-shelf’ products as well as custom solutions for population management, care coordination, and quality/analytics. Considering interoperability between products at the organization, community and state level will continue to be important as the HIE/HIT environment and investments in Oregon evolve.

Electronic Health Records and Meaningful Use The Office of the National Coordinator for Health Information Technology (ONC) Certification Program helps to ensure that Electronic Health Record (EHR) technologies meet the standards and certification to allow providers to meet Meaningful Use requirements and participate in the Centers for Medicare & Medicaid Services (CMS) EHR Incentive Programs. Certification ensures that the EHR technology providers choose to adopt offers the necessary Meaningful Use capabilities, functionalities, and security. Meaningful Use is phased into three stages, with each stage seeing an increase in program and technology requirements. In 2014, additional functionality was required in order to enable the electronic submission of CQM data. Requirements for Stage 3, expected in begin in 2017, may include a Meaningful Use measure regarding provider directories which will be accompanied with updated Provider Directory certified EHR Technology (CEHRT) standards 5. The charts below provide the number of providers and hospitals in Oregon participating in either the Medicare or Medicaid EHR Incentive programs. Since the inception of the Incentive programs in 2011, Oregon providers and hospitals have received over $288m. Oregon Providers Receiving Medicaid or Medicare EHR Incentive Program Payments 6, Unique providers, total as of August 2014 Meaningful Use (all payments are Stage 1) 5057 Medicaid Adopt, Implement, or Upgrade (AIU) Only 7 852 Total Unique Providers 5909 Oregon Hospitals Receiving Medicaid and/or Medicare EHR Incentive Program Payments, Unique hospitals, total as of August 2014 Meaningful Use (all payments are Stage 1) 42 Medicaid Adopt, Implement, or Upgrade (AIU) Only 13 Total Unique Hospitals (out of 59 total Oregon hospitals) 55

5

New Provider Directory Standards, called ‘Federated HPD’, were recently adopted by IHE (Integrating the Healthcare Enterprise). The standard will be part of the upcoming v12.0 of IHE's Technical Framework and will be part of future IHE connect-a-thons (next scheduled in 2015). The Office of the National Coordinator may formalize these standards for provider directories in future stages of Meaningful Use. Sources: Oregon Medicaid EHR Incentive Program data, dated 8/12/2014; Medicare data: http://www.cms.gov/Regulations-andGuidance/Legislation/EHRIncentivePrograms/DataAndReports.html; “June 2014 State Registrations and Payments; “Unique Count of Providers by State January 2011 – June 2014”. 6

7

Providers counted here as “AIU Only” includes providers participating in the Medicaid EHR Incentive who have received an initial payment for adopting certified EHR technology but who have not yet received a payment for Meaningful Use.

OHA RFI #3857 -

- 39

The diagram below depicts both the current landscape and the roadmap for Oregon’s HIT-Optimized Healthcare. This diagram incorporates supporting and/or enabling capabilities with technology services or tools, as well as governance, at the national, state, and local levels for current and future timeframes. Figure 4: Oregon’s HIT-Optimized Healthcare Roadmap

The charts below depict the various certified EHR systems (by EHR vendor) that are in use by Oregon providers and hospitals that have received either a Medicaid or Medicare EHR Incentive Payment (as of August 2014): Providers: Top 10 EHRs in use by Oregon providers receiving either a Medicare or Medicaid EHR incentive payment (unique providers; 2011-Aug 2014). About 82% (n = 4912 of 6007) of providers used one of these 10 vendors (based on most recent payment). A total of 116 EHR vendors were represented across all providers receiving an incentive.

OHA RFI #3857 -

- 40

Chart A: Providers

Hospitals: EHRs in use by Oregon hospitals receiving EHR Incentives (unique hospitals; 2011-2014). Includes 56 out of 59 hospitals (based on most recent payment). Chart B: Hospitals

Health Information (HIE) * DenotesExchange vendor also has 2014 CEHRT version in use

Health systems in Oregon are utilizing various technologies to enable the exchange of health information. Through regional and/or statewide HIE platforms, providers can access meaningful, reliable, actionable patient information shared across organizations and differing technologies. There are four HIEs currently operational within the state of Oregon:

OHA RFI #3857 -

- 41

HIE

Vendor

CareAccord

Mirth and Harris

Central Oregon HIE

Relay Health

Gorge Health Connect

Medicity

Jefferson HIE

Medicity

Location/Service Area Operated by OHA, serving providers and healthcare related entities statewide. Based out of Bend, serving Central Oregon. Based out of The Dalles, serving the greater Mid-Columbia River Gorge region

Based out of Medford, serving Southern Oregon.

Services • Direct secure messaging • Interoperable with other Direct secure messaging vendors through DirectTrust & NATE • Community health record • • • • •

Direct secure messaging Referrals Direct secure messaging, Closed-loop referral, Patient search & discrete data retrieval • EHR integration • Alerts

Other health systems within the state are also developing regional HIE solutions. Intercommunity Health Network (IHN) CCO, based in Corvallis, OR is leading the Regional Health Information Collaborative (RHIC). The RHIC technology will include a single source repository with the ability to aggregate data from multiple providers and health care systems. The Bay Area Community Informatics Agency (BACIA) based in Coos Bay, Oregon is also evaluating HIE capabilities in their community. BACIA acts as the governance and policy-making body, while technology is delivered through Bay Area Hospital and Western Oregon Advanced Health CCO. In addition to community HIE platforms, the exchange of health information may be enabled by: • Organization-specific HIEs, where larger health systems have invested in HIE technology • Vendor-specific functionality such as Epic CareEverywhere • Use of Direct secure messaging within EHRs, including provider and hospital systems seeking to meet Meaningful Use Stage 2 requirements to send Transition of Care summaries outside their organizations via Direct secure messaging and other protocols

Provider Directories Myriad entities in Oregon maintain individual provider directories, including but not limited to: • HIEs • EHRs • Health plans and CCOs • Health systems, hospitals, clinics, and practices • Professional associations • Data intermediaries and researchers • State agencies and programs OHA’s Office of Health Information Technology has recently implemented a simple Direct secure messaging address sharing directory, called the Flat File Directory, to collate and share monthly files between organizations using Direct secure messaging services offered by Direct Trust, fully accredited vendors.

OHA RFI #3857 -

- 42

Population Management, Care Coordination, and Quality/ Analytics Solutions A number of vendor products for population management, care coordination, and quality/analytics are utilized in Oregon to inform care delivery – with adoption and use varying by each organization. While some solutions are intended for use solely by a CCO or health plan, others extend actionable information to providers at the point-ofcare. Some of the vendor products our CCOs or their partners have invested in include: Vendor* Altegra Health Arcadia Healthcare Solutions Inovalon Intelligenz InterSystems Essette MedImpact Milliman McKesson MZI Healthcare Optum The Advisory Board Company

Product(s) Where Known* HealthCare Analytics (suite of modules available) Arcadia Analytics 2.1

MedInsight PRM Analytics VITAL EZ-CAP Impact Intelligence (suite of modules available) Crimson Care Management Crimson Care Registry Crimson Population Risk Management Care Team Connect

Truven Health Analytics VistaLogic Clara *Please note this list is not all-inclusive of vendors/products in place in Oregon

END OF RFI

OHA RFI #3857 -

- 43

Bundled Procurement RFI - Rackcdn.com

Bundled Procurement RFI - Rackcdn.com

Suggest Documents

Bundled Procurement RFI - Rackcdn.com

RFI

pdf bundled

pdf bundled

787 RFI

RFI - NITRD

RFI - Buyandsell.gc.ca

RFI - unops

RFI - Buyandsell.gc.ca

rfi - Core

RFI - unops

Bundled Prices - CiteSeerX

rfi(x) - Semantic Scholar

rfi - Buy and Sell

rfi - Buy and Sell

rJ:snrnnrucn::unr:rir rfi unr:aoudn 16onr.gnna rfi a rrirdnur '[unruci6rn ...

RFI - Indian Navy

BuST-Bundled Suffix Trees - CiteSeerX

Bundled Payments - BDO USA, LLP

RFI Letter - Northrop Grumman

Thermographs and RFI

rfi(x) - Semantic Scholar

RFI - Buy and Sell

rJ:snrnnrucn::unr:rir rfi unr:aoudn 16onr.gnna rfi a rrirdnur '[unruci6rn ...