OHA / ODHS Technical Reference Architecture Framework

Oregon Health Authority / Oregon Department of Human Services Technical Reference Architecture Development Contract Number: OHA Contract #164928 Task Order #2

September 20, 2024 | Document Version 1.0

S-44300-00017151- Medicaid Enterprise System (MES) System Integration Services AttIa

Client Name: OHA / ODHS Project Name: Technical Reference Architecture Development Document Title: TRA Framework

Document history

Contents

Client Name Project Name Document Title

5.6 Federated vs Replicated Data Models 34

© 2024 NTT DATA Americas, Inc. | All rights reserved. | Proprietary and ConfidentialPage 2 of 7

Exhibits

Introduction Oregon Health Authority / Oregon Department of Human Services (OHA/ODHS) takes an enterprise view of their modernization strategy, focusing primarily on capabilities that support the MMIS but that also can be leveraged to the larger Medicaid Enterprise System (MES). The MES is a combination of systems and programs that, taken together, represent the Enterprise enabling publicly funded healthcare in Oregon.

The Technical Reference Architecture (TRA) of OHA/ODHS encompasses the breadth of standards, policies, operational activities, vendor requirements and governance processes which impact the development, deployment and operations of the OHA/ODHS Medicaid Enterprise Systems program. The OHA/ODHS TRA is detailed in two related documents. The TRA Framework (this document) offers specific requirements as well as links to pertinent regulations, policies, industry standards and Agency guidance. It is supported by the TRA Standards document which organizes the collection of links to the applicable standards, policies and guidance which affect the MES. Both documents recognize that the Agency architecture is transitioning from an infrastructure largely supported by a state data center into a cloud hosted Software as a Service model. Therefore, the documents share a future expectation as well as describe existing capabilities. The TRA Framework presents policy and technical guidance to all Agency business partners wishing to develop, transition, and maintain information systems that interact with the OHA/ODHS Processing Environments. Generally, the term TRA used in this document reflects the larger, more encompassing definition of Technical Reference Architecture. The terms TRA Framework or TRA Standards will be used if the specific document is being referenced.

The Oregon MES is on a transformative modernization journey that will see the data center centric infrastructure migrate to cloud-based Software as a Service focused architecture. In concert with the modernization journey for the systems, OHA/ODHS is evaluating changes in information technology governance to match the anticipated multi-vendor, multi-platform integrated MES. One of the planned changes to IT governance will be the introduction of the OHA/ODHS Technology Standards Board (TSB). The TSB is expected to be responsible for overseeing the MES modernization and the maintenance and updates to the TRA Framework and TRA Standards documents. Section 3 Governance Structure describes some of the existing or planned governance components. The TRA Framework describes the expected activities of the TSB.

The TSB or OHA/ODHS assigned staff will be responsible for reviewing solution alignment to the TRA as well as granting any waivers or deferrals as appropriate during the modernization activities. The TRA Framework supports the planning and enablement of the modernization strategy by identifying and mandating architectural principles and standards be followed as new capabilities and processes are introduced into the MES architecture. Existing systems won’t need to be retrofitted to match the TRA, but new or modified interfaces or components will be expected to align to the TRA or receive a deferral or waiver from the TSB (once established) or OHA/ODHS.

While the TRA Framework is primarily a technical document, the purpose of the technology is to meet the business need of OHA/ODHS and the citizens, providers and external partners they serve. Business need will drive many technical capabilities such as scalability and performance. Therefore, the outcomes and measures may be defined in business operational terms, not simply technical numbers and metrics.

The term “Agency” used throughout this document refers to OHA and ODHS. The terms will be used interchangeably.

Purpose The TRA embraces modern, cloud-native architectural approaches while continuing to support the integration of more legacy applications. The Agency is not requiring Service Oriented Architecture (SOA) in its pure form, but rather embraces the principles of loose coupling, reusability and interoperability. There is a preference for microservices and serverless architectures represented by Function as a Service (FaaS), and Application Programming Interfaces (APIs). Adhering to the TRA improves interoperability of services across the enterprise, supporting the goal of providing high-value services at lower cost, with higher availability, reduced implementation times, and improved maintainability. This architectural transition aligns with the Agency’s emphasis on improving the Medicaid Information Technology Architecture (MITA) maturity for the Business, Information and Technical architecture dimensions of the MES by having vendors and solution developers conform to guidance in the TRA Framework. The architecture supports improvement in modularity, security, data integration and management, and business and technical outcomes which are key MITA maturity measurements.

The TRA Framework is intended to guide system architects, business owners, system maintainers, and security auditors working with the OHA/ODHS technical environment. The TRA Framework informs the development of the Agency MES and provides a foundation for the design and implementation of processing components and computing environments across the MES. Ensuring the secure operation of all processing environments is a primary architectural consideration. Following and adhering to the standards, processing and requirements throughout this TRA Framework will enable OHA/ODHS to progress to higher levels of MITA Maturity.

The MES TRA Framework will be maintained through new or established Agency IT Governance processes and approved by the TSB team or Agency designee.

The Agency supports the following guiding principles for the TRA:

Alignment with Business Goals Principle: The TRA should align with the organization’s business objectives and strategic goals.

Security and Compliance Principle: Security and compliance must be integral to the architecture.

Interoperability and Integration Principle: The architecture should support seamless interoperability and integration across systems and platforms.

Scalability and Performance Principle: The architecture should be designed to scale efficiently and maintain high performance under varying loads.

Modularity and Reusability Principle: The architecture should promote modularity and reusability of components.

Flexibility and Agility Principle: The architecture should be flexible and agile, allowing for quick adaptation to changing business needs and technological advancements.

Cost-Effectiveness Principle: The architecture should balance performance and functionality with cost-effectiveness.

Technology Standardization Principle: The architecture should promote the use of standardized technologies and practices.

Data-Driven Decision-Making Principle: The architecture should support data-driven decision-making by ensuring that data is accessible, accurate, and actionable.

User-Centric Design Principle: The architecture should prioritize the needs and experiences of end-users.

Sustainability and Environmental Responsibility Principle: The architecture should consider sustainability and minimize environmental impact.

Continuous Improvement and Innovation Principle: The architecture should support continuous improvement and innovation.

The TRA encourages projects to consider sustainability as a critical element of architectural solutions. Projects should apply appropriate attention to future scale, cost, security, operational efficiency, technology, and vendor support. The long-term viability of applications and data products must be considered when integrating any solution into the MES processing environments. Risk and mitigation planning for sustainability should address personnel (technical expertise), operational processes (automation), adherence to Service Level Agreements, and total cost of ownership.

In cloud environments, the sustainability for cost, scalability and service level agreements can be achieved by adoption of cloud native features like dynamic scaling of resources based on usage, use of shared instances vs reserved instance and optimal sizing of resources.

Document Scope The TRA Framework describes the MES architecture model and how it applies to the MES modernization activities. It documents standardized review processes for new solutions that will be integrated into the MES. The TRA Framework focuses on strategic policies, standards and security expectations rather than detailed implementation guidance.

The TRA Framework presents an abstract blueprint that provides references for the MES integration architecture, rather than documentation of the MES solution architecture itself. Scores of links in the TRA Framework document provide access to supporting Federal, State, Agency or Industry standards and policies. These standards and policies are incorporated by reference but will not be maintained within the TRA Framework document. The links within the TRA Framework are also available in the TRA Standards document.

Overview of the MES Ecosystem The MES is in the process of modernizing and modularizing. It will continue to evolve to meet the business needs of the Agency. From a systems perspective, the MES currently includes the following modules, systems and applications.

Exhibit 1 identifies the significant modules, systems and applications within the OHA/ODHS MES in 2024. Throughout the modernization process, the specific list of modules and systems will evolve. A solution inventory and details of the systems which make up the MES are available in other documents. As a part of the MES Modernization Roadmap, OHA/ODHS intends to contract with a Systems Integrator (SI) to support data communication between modules. The resources and responsibilities of the SI may lead to changes in the TRA Framework.

Exhibit 1:MES Scope Audience and Use The TRA Framework and TRA Standards documents are system reference resources as well as a communication channel to share the technical capabilities, standards and solution policy expectations of OHA/ODHS.

These documents should be used as a resource for the Agency’s projects during procurement, design, development, and implementation. The TRA Framework and TRA Standards are living documents used for planning, communication and standardization of solutions to support OHA/ODHS. They will be used to communicate with state staff, vendors and partners. The TRA Framework and TRA Standards documents will be made available as reference material to vendors during the solicitation and procurement of systems as well as to the authors of Request for Proposal (RFP) documents to help align the expectations of OHA/ODHS and the supporting vendor community.

The TRA Framework’s purpose is to provide technical guidance and reference materials for the Agency technical teams, Program Management Office (PMO), modular vendors and other partners of the Agency.

The key consumers of the TRA Framework are:

OHA/ODHS Change Approval Board and Technical Governance Councils.

Future MES Module Vendors, Systems Integration (SI) Vendor, or other organizations interfacing with MES.

Development teams designing or implementing MES applications or solutions.

Teams operating or supporting MES.

OHA/ODHS teams that may use these architecture standards in non-MES projects.

The TSB and the Agency will utilize the TRA Framework as a tool for communication and coordination to guide MES solution development.

The TRA documents should be used by OHA/ODHS technical governance to evaluate proposed changes to the MES to promote alignment, leverage, reuse and interoperability of system capabilities to meet the business needs of partners.

The TRA documents support the State’s Cloud Forward strategy and direct the alignment of new and updated systems to coincide with the network and security expectations of the Agency.

TRA Overview The Medicaid Enterprise System exists to provide services in helping Oregonians achieve health, well-being, and independence. In support of this mission, the Agency provides information technology systems and services that help to:

Determine client eligibility.

Provide medical, housing, food and job assistance.

Provide addiction, mental health and vocational/rehabilitative services.

Protect children, seniors and people with physical and/or developmental disabilities.

Process claims and benefits.

Manage provider licensing and state hospital facilities.

Promote and protect the state’s public health.

Support internal Agency administrative functions, including human resource, finance and procurement programs.

Therefore, the TRA must support the systems, data, and operational platforms which enable the business activities of the Agency. The focus is not on the technology. It is on the business outcomes enabled by technology.

OHA/ODHS and the Oregon Enterprise Information Services (EIS) division within the Oregon Department of Administrative Services (DAS) have established many policies and standards related to the development, deployment and operations of software and solutions. These policies apply equally to all partners and modules in the MES solution. The TRA Framework allows these policies and standards to be shared with the module vendors during procurements via the bidder library and during the Design, Development and Implementation (DDI) and operations phase of the project. The procurement library will include a requirement that vendors adhere to the policies, standards and guidance within the TRA Framework. The documented policies must be followed, even during the frenetic activity of a system implementation. OHA/ODHA has documented the Strategic Technology Plan – Comprehensive Overview (internal link) to share their vision, strategies, drivers and priorities. The technology plan also identifies key IT projects already underway as part of the modernization exercise.

TRA Scope The MES is an ecosystem of many state-developed and vendor supplied modules and applications. There are a variety of components of various scope, size, complexity and processing requirements.

The scope of the TRA includes providing guidance and references to direct the design, procurement, and implementation of the MES. The TRA Framework defines architectural requirements but does not identify specific products to implement the architecture unless it is a leveraged product that is expected to be reused across modules.

It is not expected that existing components will be retrofitted to ensure TRA compliance, but all new technical architecture decisions arriving through the MES’ governance process are expected to align to the TRA.

The TRA Framework and TRA Standards documents provide links to a variety of state, federal and industry policies, standards, legislation and documentation that are included by reference in the TRA but are maintained outside of the TRA. Vendors and external partners are expected to abide by these references.

Alignment with other Technical Architectures The architectural diagrams shown in Exhibit 2 depict two meta-models for enterprise architecture. On the left side is the Centers for Medicare & Medicaid Services (CMS) Medicaid Information Technology Architecture (MITA). The right side is a similar architecture based on the Federal Enterprise Architecture Framework (FEAF) and The Open Group Architecture Framework (TOGAF) which are not specific to Medicaid. The lines between them show the mapping between the two frameworks. CMS is very comfortable with the right-hand architectural representation of a MES system.

Exhibit 2: Enterprise Architecture Models This document structure is based on the framework on the right, which depicts a more detailed perspective. What is listed as the Information Architecture is named Data Architecture in some frameworks such as FEAF. The TRA covers the Information, Application, and Technology layers as well as the System Integration, Governance, Outcomes and Performance, and Security components that span all layers. Since this document is a technical reference architecture document, the scope focuses on these three layers of the architecture. The business layer is referenced and presented as a context diagram showing how business requirements are supported by MES data and technical capabilities without detailing the business requirements themselves. The Strategy layer is outside of the domain of the technical references and is not included in this guide. However, it is depicted on the diagram to provide a frame of reference for a holistic view of the architecture.

TRA Modification and Maintenance The TRA Framework and TRA Standards documents are intended to change and be modified over time. They will be adjusted and updated as the MES Ecosystem evolves and as changes in standards, technologies or policies dictate. When established, the Technology Standards Board will have the ultimate approval authority for changes to the TRA documents although the recommended updates will come from the Change Approval Board, the Information Systems Management Committees (ISMCs) or other partners.

As described in Section 3 Governance Structure, OHA/ODHS has a shared IT Governance structure. As OHA/ODHS shifts toward more active MES modernization activities, there are plans to introduce a Technology Standards Board for architectural oversight. As an industry best practice, the TSB will establish an architectural governance process to manage and communicate architectural direction to Agency and vendor partners.

Changes to the TRA Framework will be submitted to TSB through the future MES architectural governance process. The TSB approves changes to the TRA Framework before they are adopted. Triggers for TRA Framework modifications should include:

If the TRA Framework does not provide enough direction to the TSB or the Agency for a solution or topic under review.

As new technologies and vendor offerings emerge.

When Federal or State technology mandates are published or updated.

If material changes in business need, posture, or activities necessitate an update.

When MES module developers or vendors request deviations from documented TRA standards.

One year from the date of the last approved modification.

Since new MES procurements will require alignment with the MES TRA, careful consideration must be given when changes are made to the TRA documents to understand the impact on existing procurements and contracts.

Governance Structure Oregon has a technology governance process which aligns the MES solutions within the strategy and framework established by the Oregon Department of Administrative Services and executive agencies. OHA/ODHS extends and supports the policies, practices and standards related to technology, data communication and security through a tiered governance structure. The IT Governance used by OHA/ODHS today focuses on the MES modules which are maintained and enhanced by a series of Agency-approved projects.

As described in the OHA/ODHS IT Governance Page, (internal link) IT governance is the discipline of deciding what technology investments will optimize business value while managing resources and risk. Best practices in IT governance involve close collaboration between IT and the business, and documented structures, processes, and metrics. This collaboration supports informed decisions through reliable measures of feasibility, cost, risk and benefit.

The goal of technology governance is to:

Ensure accountability and transparency.

Assure that investments generate measured business value.

Ensure IT investments align with business needs, priorities and strategic plan.

Mitigate IT-related risks.

Both ODHS and OHA have Information Systems Management Committees (ISMCs) which review all work requests and prioritize small to medium efforts for individual systems. Agency IT Governance Councils (ITGCs) provide strategic guidance and prioritization on larger efforts, based in part on recommendations provided by the ISMCs.

Exhibit 3 shares the current governance structure of the Agency.

Exhibit 3:OHA ODHS Governance Structure Office of Information Services (OIS) OIS consists of the Office of the Chief Information Officer (OCIO) and nine core IT business units that provide vital functions to accomplish the operational and strategic goals of ODHS and OHA. Organizationally, OIS has facets of a traditional IT organization and newer functional groups not always seen in a traditional IT organization, such as Business Engagement Services and Vendor Managed Services, to adapt to the changing needs of technology and business. OIS delivers technology solutions and services to ODHS and OHA and the MES. OIS is largely responsible for maintaining the IT systems and networks and for the development and deployment of many of the systems and modules which make up the MES.

The Office of the Chief Information Officer (OCIO): OCIO provides leadership for all aspects of the organization's information technology and systems. The OCIO is accountable for setting overall technical direction, including strategic technology planning, performance management, and continuous modernization initiatives.

Information Security & Privacy Office (ISPO): ISPO protects personal and confidential information within the system. ISPO accomplishes this by supporting agency programs with awareness, education, privacy, and security controls to ensure that the confidentiality, integrity, and availability of the information we are entrusted with is protected and that risks are communicated and remediated. ISPO also provides Policy and Procedure Development (Privacy and Security); Privacy and Security Incident Management and Breach Notification Support; Risk Management Oversight; Information Exchange (Third-Party Access); eDiscovery and Litigation; Awareness and Education (Privacy and Security); Vulnerability Management; Audit and Security Support Services; and Cyber Risk and Incident Response Support.

Enterprise Architecture (EA): The Enterprise Architecture unit provides ODHS and OHA with enterprise architecture services, which includes project consultation and assessment, IT reference models, and technology standards and exceptions. EA also manages IT portfolio reporting and the OIS service catalog.

Technology Engineering, Development and Support (TEDS): TEDS consists of seven units that provide comprehensive implementation and support services throughout the technology lifecycle, from solution design and implementation to operations and support. TEDS’ mission within OIS is to leverage advanced technologies to design, implement, and support innovative solutions that streamline processes, enhance data integrity, and improve the accessibility and efficiency of health and human services for all people in Oregon.

Vendor Management Services (VMS): VMS is leading the efforts, in collaboration with our federal and state partners, to modernize OHA/ODHS Medicaid systems through management of the Medicaid Enterprise Systems Modernization program. VMS also provides technical oversight of and liaison services between vendors and State of Oregon resources supporting two of the largest vendor‐based solutions of the agency (ONE and MMIS) to meet evolving business requirements. Additionally, VMS provides contract management support through a consultation perspective for many large ODHS and OHA IT procurements and associated IT projects by providing an in‐house team of IT contracting experts.

Project Solutions (PS): PS project managers coordinate with other project resources to manage and control the project from initiating through closing. PS uses proven project management tools and processes to streamline projects and provide the following services: Project Management; Risk and Issue Management; Estimating, Budget and Cost Management; Resource Management; Contract and Deliverable Management; Project Reporting; Change Management; and Communications.

Business Engagement Services (BES): BES provides solution engagement ensuring that technology solutions align with the strategic ODHS and OHA and business direction. BES also manages the intake and governance processes that ensure OIS is working on the right things at the right time in support of both agencies.

Business Operations (Biz Ops): Biz Ops provides central administrative support for OIS, including budget coordination, HR workforce management, payment processing, legislative management, facilities coordination, and financial and position management. Biz Ops also manages all ODHS and OHA technology assets, including computers, printers, and software.

Health and Service Equity Transformation Program: Health and Service Equity Transformation Program focuses on implementation of Race, Ethnicity, and Language Disability / Sexual Orientation and Gender Identity (REALD/SOGI) demographics data collection. The team is involved in implementation of solutions, interoperability of systems and integration of data working with vendors, state agencies, providers, and community groups.

MES Modernization Governance As the MES modernization effort nears, OHA/ODHS intends to embrace the industry best practice of establishing additional architectural governance to evaluate, communicate and enforce architectural standards and policies and to create a forum to coordinate and communicate with participating MES vendors. The technical governance best practice for MES modernization includes four governing bodies to allow for proper focus and activity coordination.

1. Technical Standards Board sets strategic technical direction and approves Agency-wide technical and architectural standards and policies.

2. Program Technical Design Committee provides a tactical decision-making forum for Agency and vendor staff to ensure the MES modernization conforms to TSB guidance and all participants align, particularly at the integration points.

3. Change Approval Board reviews production level requests and ensures testing, release management and failover/backout requirements are met.

4. Data Governance Council provides the authoritative structure for escalating and making decisions around the Agency’s use, re-use, retention, disposal, and management of data.

As new governance is developed and documented, changes may be necessary to the TRA Framework to reflect the resulting governance structure.

Technology Standards Board (TSB) OHA/ODHS is creating a Technology Standards Board to support the architectural evolution of the MES. The TSB is intended to be a formal committee responsible for reviewing, evaluating, and guiding the alignment of architectural designs and changes in IT architecture. The TSB is expected to ensure that the organization's IT architecture remains consistent, supports business objectives, and adheres to established standards and best practices. The TSB will be composed of technology leaders with decision making authority who possess deep technical expertise. As an industry best practice, the TSB will evaluate the evolution and harmonization of MES architecture as well as agency modules and components that operate therein. Critical in this oversight will be to ensure the solution adherence and alignment with the OHA/ODHS business goals including the Health Equity North Star as described in Section 4 Business Reference Model. The architectural designs for components of systems that will become an integrated part of Oregon must conform to the enterprise architecture standards to ensure that all components and technology decisions will lead to highly compatible systems, components, information, and capabilities.

The TSB is expected to provide strategic leadership and have decision authority over high priority/impact items; maintain an enterprise-level view of MES priorities, the Strategic Roadmap, and ensure strategic alignment between vendors, program, project, and IT priorities.

There are discreet tasks that the TSB is expected to conduct on a regular basis to ensure that all aspects of the project have sufficient oversight and alignment to the architectural vision. These tasks include:

Provide project engagement to resolve technology conflicts.

Monitor adherence to technology standards and vision.

Resolve and publish decisions at an expeditious pace.

Define/enforce integration /interfaces frameworks and planning.

Resolve Disputes in Technical Architecture or Design.

Support the Security Access Framework.

Define and enforce technology standards within the governance framework.

Evaluate the alignment of solution design and components with the enterprise architecture and with technical deliverable standards.

Review and appropriate adoption of emerging technologies.

Support technology audits.

Program Technical Design Committee (PTDC) While the TSB sets the strategic direction and architectural framework, as an industry best practice, the Program Technical Design Committee is charged with the responsibility of tactical architectural governance and vendor communication. The PTDC is a joint Agency / Vendor forum and decision-making body which supports the technology foundation of the MES portfolio and serves as the link between the MES architecture implementation and the TSB architectural strategy and vision.

The PTDC is comprised of a team of senior architects, project managers, and vendor technical leads who represent different architectural and agency perspectives. The purpose of the PTDC is to ensure alignment with business strategy and conformance to all business, information and technology architectures and their underlying designs.

The PTDC is expected to implement and enforce the decisions of the Technology Standards Board and the Data Governance Council. The PTDC should address technology issues covering the following architecture domains:

Business Architecture Information Architecture Integration Architecture Application Architecture Technology Architecture Security Architecture There are discreet tasks that the PTDC may be responsible to conduct on a regular basis to ensure that all aspects of the project have sufficient oversight and alignment to the architectural vision. These tasks include:

Provide Agency/vendor engagement for implementation approaches.

Enforce adherence to technology standards and vision.

Define/enforce integration /interfaces frameworks and planning.

Evaluate alignment of solution design and components with the architecture and technical deliverable standards.

Resolve and publish decisions at an expeditious pace.

Resolve disputes in technical architecture or implementation approaches or escalate to higher governance.

Direct responsibility for updates of technical deliverables.

Support the Security Access Framework.

Review Enterprise Role Based Access Controls (RBAC).

To ensure transparency in its operations, all actions and decisions should be documented and shared with MES participants.

Change Approval Board (CAB) The Change Approval Board (CAB) provides operational direction to the MES and facilitates the Enterprise Change Management Process. This board reviews production level requests for changes and grants permission to the technical team to make the change. The type and classification of the change dictates what approval and documentation processes are used to implement the change. The CAB ensures that risks, conflicts and environmental considerations are evaluated prior to approving a requested change.

The CAB oversees the processes outlined in the Information Technology Change Management Policy.

The purpose of the Enterprise Change Management Process is to support the governance of the technology environment, improve the maturity level of operations, and increase the quality of the services provided to OHA/ODHS. The Change Management Process (internal link) ensure standardized methods and procedures are in place for efficient and prompt handling of all systems changes and avoidance of negative impact on OHA/ODHS technology customers. Specifically, processes confirm that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner and that necessary steps are taken towards a corrective action.

Data Governance OHA/ODHS has established a data governance program to manage this key asset. The Data Governance and Stewardship process is being refined and strengthened based on guidance from a data management consulting engagement. Designed in a tiered structure in a Federated model, the data governance organization supplies the range of data management from the strategic to the tactical. Exhibit 4 highlights the OHA/ODHS Data Governance Structure.

Exhibit 4: OHA/ODHS Data Governance

Exhibit 5 shares the defined roles and responsibilities for OHA/ODHS Data Governance Program.

Ensures alignment between OHA data goals and the DGC.

Approves DGC activities.

Facilitates the DGC meetings and helps to ensure decisions are communicated to OHA data partners.

Prioritizes DGC initiatives.

Aligns business goals to data strategies and plans.

Facilitates and monitors cross-functional data workgroup initiatives.

Monitors and guides tactical data governance/management initiatives.

Data Workgroup and Data Partners

Participates in defining data governance rules, policies, and processes.

Workgroups are cross-functional teams that deliver on DGP projects, initiatives, and ad-hoc review committees.

Exhibit 5: Data Governance Roles and Responsibilities

Executive Leadership Team Data is one of the most valuable assets entrusted to the State of Oregon. OHA/ODHS has an obligation to hold it and use it securely, responsibly, ethically and in a manner consistent with principles of equity, justice and anti-racism. The ODHS Data Strategy (internal link) documents the vision, strategy and intended actions to improve data maturity at ODHS. The State Chief Data Officer has established a statewide approach to data governance and has established the State Data Strategy principles of:

Governance and Effective Management.

Ethical Use.

Data-informed culture.

The Data Governance Executive Leadership Team (ELT) sets the vision, mission and goals of data usage and supports the Data Governance Council in achieving these goals. The ELT also identifies key strategic initiatives and outcomes for the agency and the data needed to support those initiatives.

Data Governance Council OHA/ODHS Data Office (internal link) has empowered a Data Governance Council (DGC) to provide the authoritative structure for escalating and making decisions around the agency’s use, re-use, retention, disposal, and management of data throughout its lifecycle.

The DGC provides oversight to ensure that all solutions adhere to their responsibilities for agency data, including:

Preserving and upholding the ongoing quality, integrity, and reliability of the data and information they create, use, retrieve, edit, and delete within agency information systems.

Abiding by established statewide and agency level data governance policies, standards, and practices.

The Data Governance Council is also responsible to:

Leverage identified roles and responsibilities to ensure data is accurate, consistent, secure, and aligns with overall agency objectives.

Establish guidance for managing data assets throughout their lifecycle, including creation, preservation, classification, retention, and deletion/disposal.

The DGC, through a workgroup, publishes an Enterprise Data Dictionary that names, describes, lists valid values and explains business rules for each data attribute contained within the list of data assets. The DGC performs an annual review of the published Enterprise Data Dictionary and sets up periodic intake cycles to process additional data assets for standardization, adoption and inclusion into the Enterprise Data Dictionary.

Data Governance Steering Committee The Data Governance Steering Committee (DGSC) works with vendors and agency staff to ensure compliance with DGC standards and provides tactical insight into data-related issues. The committee also provides guidance for data quality for identified critical data assets. The DGSC works to resolve any disputes or discrepancies related to the cross-functional responsibility for data translations, transformations or processing. Any disputes not able to be resolved by the DGSC will be escalated to the DGC.

Solution Vendors Under the governance structure, vendors will be required to demonstrate how they will:

Ensure alignment of technology, data, software and security with the TRA.

Ensure alignment of business goals and objectives with the goals of OHA/ODHS.

Align data governance with Agency established standards.

Conform to the Agency and DGC standards for data schemas, definitions and valid values.

Provide data steward representation to the DGC.

Establish and track data usage metrics.

Provide transparency with respect to data origination and destination.

Implement a data classification strategy that supports use and re-use of data across modules.

Receive and share the results of quality audits from a third party.

Attest to the ownership of data, specifically that all data is owned by the Agency and the State of Oregon.

Ensure communications will use the agency’s established lexicon.

Meet all required federal and state government data standards as well as widely adopted industry standards.

Comply with all Agency Data Management Policies including:

Data transport.

Data security.

Data privacy.

Data retention.

Delivery of Agency data within a system upon request.

All solution vendors must follow the architectural principles of the MES. This guidance is expanded and detailed throughout the TRA Framework but consolidated here for quick reference.

1. Data Encryption:

At Rest and In Transit: All sensitive data, particularly patient health information (PHI), must be encrypted both at rest and during transmission between state systems and third-party providers. This ensures that data remains secure even if intercepted during transmission or in case of unauthorized access to storage systems.

Guidelines: Use encryption algorithms that meet or exceed the standards recommended by the National Institute of Standards and Technology (NIST), such as Advanced Encryption Standard AES-256 for data encryption.

2. Access Control and Authentication:

Role-Based Access: Implement role-based access control (RBAC) to ensure that only authorized individuals can access patient data based on their role and responsibilities within the organization.

Multi-Factor Authentication (MFA): Ensure all users accessing PHI must pass through multi-factor authentication, especially when accessing systems remotely or through third-party applications.

Audit Logs: Maintain detailed audit trails to track access and changes made to patient data. This provides accountability and helps in identifying and responding to potential data breaches.

3. Data Minimization:

Limiting Data Sharing: Only share the minimal amount of patient data necessary for the transaction. For instance, a transportation provider may not need full medical records, just the relevant details for delivering services like scheduling or transportation logistics.

Guidelines: Establish clear protocols for what data each entity in the system (broker, direct billing, etc.) can access, ensuring compliance with HIPAA’s minimum necessary standard.

4. Secure APIs and Data Sharing Protocols:

Standardized APIs: Define secure APIs for data exchange between state systems and third-party platforms. Use secure communication protocols like HTTPS and require API authentication tokens.

Data Sharing Agreements: Formalize data-sharing agreements between the state and any contracted third-party providers. This ensures all parties adhere to the same security protocols and regulatory standards.

5. Data Integrity and Validation:

Data Validation: Implement validation checks at various points in the data transmission process to ensure that the information being shared is accurate, complete, and consistent.

Integrity Checks: Use cryptographic hash functions to confirm data integrity, ensuring that data is not tampered with during transmission.

6. Third-Party Vendor Compliance:

Business Associate Agreements (BAAs): Ensure that all third-party providers, whether under a broker-based model or direct billing, sign BAAs that bind them to the same HIPAA obligations as the state. This includes maintaining confidentiality, integrity, and availability of patient data.

Vendor Security Audits: Periodically audit third-party vendors to ensure compliance with security protocols and data protection standards. Vendors should provide evidence of their security practices through certifications like Systems and Organization Controls SOC 2 Type II or Health Information Trust Alliance (HITRUST).

7. Incident Response and Breach Notification:

Breach Notification Protocols: Establish clear procedures for breach detection, reporting, and response in compliance with HIPAA’s breach notification rule. Any data breach involving PHI must be reported to affected individuals, the Department of Health and Human Services (HHS), and potentially the media if it affects more than 500 individuals.

Response Plan: Develop a comprehensive incident response plan that includes steps for mitigating any data breaches and preventing future incidents.

8. Training and Awareness:

HIPAA Training: All staff, both within the state agencies and third-party contractors, must undergo regular training on data protection and HIPAA compliance.

Security Awareness: Implement continuous security awareness programs to educate users about potential threats such as phishing and social engineering attacks.

9. Data Retention and Disposal:

Retention Policies: Establish data retention policies that ensure patient data is kept only as long as necessary for legal, financial, or operational purposes, in line with HIPAA guidelines.

Secure Disposal: Define methods for the secure disposal of patient data when it is no longer needed, such as through degaussing, shredding, or secure digital wiping of electronic records.

Governance Process Collectively, the various levels of IT Governance for OHA/ODHS work together to enable a structured process for establishing guidance and managing change to the programs and systems that support the health, safety and independence of Oregonians. This includes authoring and approving the policies and standards that support these systems and programs. Exhibit 6 describes how policies, standards and governance support the TRA.

Exhibit 6: How policies, standards and governance are facilitated by the TRA Business Reference Model First and foremost, the Medicaid Enterprise System must support the strategic plans, fulfill the business needs and deliver the expected outcomes of the two agencies responsible for public health and public healthcare in Oregon. Each agency has a different focus but a common purpose in equitably serving the health and safety of Oregonians.

Strategic Plans…