Appendix K SA0019_TRA_Technical_Framework_Plan_v5 - Amended5-5-5-2025.pdf

I D A H O D E P A R T M E N T O F H E A L T H A N D W E L F A R E

M M I S P R O C U R E M E N T

T E C H N I C A L R E F E R E N C E A R C H I T E C T U R E P L A N

V E R S I O N 5 S T A T U S : F I N A L

D A T E : A P R I L 8 , 2 0 2 5

MMIS Procurement

Technical Reference Architecture Plan

April 8, 2025 Page 2

Document Information

Document Title Technical Reference Architecture

Version 4

Author NTT DATA Team

Owner (if different from Author) Shawn McFadden, Enterprise Architect

The primary copy of this document is available in the Project Library at PMO - Shared Documents All Vendors. Hard copies are for information purposes only and are not subject to document control.

Amendment History

Document Version

Date Author/Reviewer Modification

(include references to Decisions in DevOps for revisions after Version 1.0)

.01 09/20/2024 NTT DATA Team Full TRA

1 11/13/2024 NTT DATA Team Responded to IDHW comments and made applicable updates

1.1 12/02/2024 NTT DATA Team Responded to IDHW comments and made applicable updates

2 12/02/2024 NTT DATA Team Final

2.1 01/06/2025 NTT DATA Team

Created new SecƟon 4.1 DQAA Updates to SecƟon 7 for Data Quality Agreements and AutomaƟon Added/updated Interface Control SpecificaƟons reference

3 2/28/2025 NTT DATA Team Created new SecƟon 10 Policy and Governance Compliance Framework per decision 17035 which captures the decision to include the Framework in the TRA. Created the Compliance Library. RegulaƟon and Standards, which were previously in the appendices, moved to the Compliance Library. Checklists for Security, Design Review, and ADA SecƟon 508 compliance created and added to Compliance Library.

4 4/2/2025 NTT DATA Team Response to Comments provided to IDHW.

5 4/8/2025 NTT DATA Team Response to comments provided by IDHW.

April 8, 2025 Page 3

TABLE OF CONTENTS

1 Overview

1.1 Purpose

1.2 Architecture Goals and Constraints

1.2.1 Compliance Goals and Constraints

1.2.2 Design and Implementation Goals and Constraints

1.2.3 Capacity and Performance Goals and Constraints

1.3 TRA Publishing and Maintenance

1.3.1 TRA Publication

1.3.2 TRA Modification Schedule

1.4 Relationship to IDHW Procurements

1.5 Architecture Compliance

2 Architecture Overview

2.1 Business Architecture

2.2 Application Architecture

2.3 Information Architecture

2.4 Technical Architecture

2.5 Security Architecture

2.6 Integration Architecture

2.7 Module Architecture

2.8 Testing Framework

2.9 Architecture Design Standards

3 Business Architecture

3.1 Business Environment

3.2 Performance Measures

3.2.1 Key Performance Indicators

3.2.2 Service Level Agreements

3.2.3 Other Performance Measures

3.3 Integration Approach

3.4 Environments

3.4.1 Primary Environments

3.4.2 Part-Time Environments

3.4.3 DDI Only Environments

3.5 Enterprise Document Management System

April 8, 2025 Page 4

3.6 Release Management

3.7 Data Retention

3.8 Business Continuity

4 Information Architecture

4.1 12.2 Data Standards (List of Standards) Data Quality Agreements and Automation

5 Application Architecture

5.1 Application Interface Patterns

5.1.1 Synchronous Data Exchanges

5.1.2 Asynchronous Data Exchanges

5.1.3 Publish/Subscribe Model

5.1.4 Additional Supported Interfaces and File Exchanges

5.1.5 Application Interface Standards

5.1.6 Configuration of Interfaces

5.1.7 Cloud Native Application Architecture

5.1.8 Interfaces with COTS tools

5.2 Application Security

5.2.1 Identity and Access Management

5.2.2 Single Sign-On (SSO)

5.2.3 Role Based Access Control

5.3 Application Performance and Scaling

5.4 Performance Measurement

5.4.1 Scaling Requirements

5.4.2 Scaling in Cloud Environments

5.4.3 On-Premises Hosted Systems

5.5 Capacity Management Monitoring, Reporting, and Remediation

5.6 Centralized Monitoring and Logging

5.6.1 Centralized Logging

5.6.2 Modular Performance Monitoring and Logging

5.6.3 Platform Performance Monitoring

5.6.4 Security Event Monitoring and Logging

5.7 Release Management

5.8 Systems Development Life Cycle (SDLC)

5.9 Data Retention

6 Technical Architecture

April 8, 2025 Page 5

6.1 Hosting Architecture

6.1.1 Cloud Hosting Architecture

6.1.2 On-Premise Hosting Architecture

6.1.3 Current Hosting Architecture

6.2 Performance and Scaling

6.2.1 Performance

6.2.2 Scaling

6.3 Capacity Management Monitoring, Reporting, and Remediation

6.4 Monitoring and Logging

6.5 Release Management

6.6 Data Retention

6.7 Data Backups

6.8 Network Architecture

6.8.1 Network Naming and Addressing

6.8.2 Encrypting Data in Transit

6.9 Email Integration

7 Integration Architecture

7.1 Integration Overview

7.2 High Level Interface Strategies

7.3 Interface Data Strategies

7.3.1 Data Strategies for Interface Development

7.3.2 Selecting Data Standards

7.3.3 Data Translation During Data Exchanges

7.4 Interface Documentation Minimum Standards

7.5 Interface Design and Management Oversight

7.5.1 Roles and Responsibilities

7.5.2 Interface Design

7.6 Creation and Maintenance of Interface Inventory

7.7 Interface Best Practices

7.8 Interface Capacity and Performance

7.9 COTS Tool Integration

8 Security Architecture

8.1 Introduction

8.1.1 Review of Security or Privacy Controls

April 8, 2025 Page 6

8.1.2 Security and Privacy Regulatory Background

8.1.3 Information Security Goals and Objectives

8.2 Technical Security Architecture

8.3 Identity and Access Management (IdAM)

8.4 Auditing and Logging (SIEM)

8.5 Log Storage Retention and Disposal

8.6 Single Sign-On (SSO)

8.7 Monitoring and Maintenance

8.8 Documentation and Training

8.9 Information and Data Security

8.10 Federal Security Compliance

8.11 State Security Compliance

9 Architecture Impact to Testing

9.1 Data Permitted in Testing Environments

9.2 Regression Testing

9.3 Testing Tools and Documentation Management

9.4 Security Testing

9.5 Performance Testing

10 Policy and Governance Compliance Framework

10.1 Introduction

10.1.1 Scope of Policy and Governance Compliance Framework

10.1.2 Assumptions

10.1.3 Relationships to Other Processes and Frameworks

10.1.4 Roles and Responsibilities

10.1.5 Compliance Requirements and Checklists

10.1.6 Requirements and Guidance

10.2 Regulations and Standards

10.2.1 Monitoring Regulations and Standards

10.2.2 Applying Regulations and Standards

10.3 Governance Process

10.3.1 Introduction

10.3.2 Integration with Existing Governance

10.3.3 Governance Process Triggers

10.3.4 Detailed Governance Processes

April 8, 2025 Page 7

10.3.5 Procurement and DDI Governance Activities

10.3.6 Operations Governance Processes

10.3.7 Change Control

10.4 Compliance Framework

10.4.1 Compliance Assessment Overview

10.4.2 Compliance Assessment Process Details

10.4.3 Post Assessment Processes

11 Appendix A - Glossary

TABLE OF TABLES

Table 1: Architecture Representations

Table 2: Business Environment Factors and Their TRA Impact

Table 3: Primary Environments Used Throughout DDI and M&O

Table 4: Part-Time Environments Used During DDI and M&O

Table 5: DDI Environments Used During DDI

Table 6: EDMS “As Is” and “To Be” Solutions

Table 7: Scenarios Where Custom Application Code May be Acceptable

Table 8: Benefits and Techniques of Cloud Native Applications

Table 9: Current Hosting Architecture of Modernized MMIS Components

Table 10: Participants and Responsibilities for Interface Design

Table 11: Defense In-Depth Mapping

Table 12: State Security Policies

Table 13: Use of PHI and Synthetic Data in Environments

Table 14: Security Testing Tools and Frequencies

Table 15: Documents Referenced in the Policy and Governance Compliance Framework

Table 16: Responsibilities of the Architecture Review Board

Table 17: Responsibilities of the Data Governance Review Board

Table 18: Regulation and Standards with MMIS-Wide Impact

TABLE OF FIGURES

Figure 1: Synchronous Request / Response Pattern

Figure 2: Asynchronous Request / Acknowledgement Pattern

April 8, 2025 Page 8

Figure 3: Publish / Subscribe Pattern

Figure 4: Composite Services Batch Pattern

Figure 5: Managed File Transfer Pattern

Figure 6: Secure External Third-Party Exchange Pattern

Figure 7: Defense In-Depth Strategy

Figure 8: Process for Changes to Regulations and Standards

Figure 9: Process for Requests for Governance Support

Figure 10: Process for Compliance Findings

April 8, 2025 Page 9

1 OVERVIEW

The Idaho Department of Health and Welfare (IDHW) Medicaid Management Information System (MMIS) Technical Reference Architecture (TRA) provides the authoritative design expectations for all technical aspects of MMIS Modernization Project. The TRA prescribes technologies, standards, patterns, and tools approved for use in building and operating the MMIS technical architecture.

The TRA includes:

Descriptions of architecture domains for the MMIS Modernization Project

Business requirements that impact technical architecture

Definition and requirements for the information architecture

Requirements for the application architecture for module integration, identity and access management, performance and capacity management, logging, and release management

Technical architecture standards including cloud implementations, and technical aspects of performance and capacity management, logging, and release management

Integration Architecture requirements and patterns which MMIS modules must implement

Security architecture definition, standards, and requirements

Architecture impact to testing covering testing tools, security testing and performance testing

1.1 Purpose

The purpose of the TRA is to provide consistent guidance to IDHW and module vendors developing and / or implementing business and technical systems which are part of the MMIS. The TRA includes strategies, requirements, and standards. Vendors and systems provided by vendors must comply with the architecture defined in the TRA.

1.2 Architecture Goals and Constraints

The primary goals of the TRA are to:

Define the requirements and standards which enable business modules of the MMIS to work together

Provide IDHW with the capabilities to manage the architecture of MMIS modules by predefining requirements for the module architecture

Comply with Federal and State regulations

1.2.1 Compliance Goals and Constraints

The TRA supports the capability of the modernized MMIS to meet compliance requirements including, but not limited to:

Health Insurance Portability and Accountability Act (HIPAA) privacy, security, and transaction standards

Medicaid Information Technology Architecture (MITA)

April 8, 2025 Page 10

Affordable Care Act (ACA) Section 1104 Operating Rules

Minimum Acceptable Risk Standards for Exchanges (MARS-E) security controls

21st Century Cures Act – Interoperability and Patient Access Rules

The MMIS Modernization Project architecture must consider the following constraints:

New regulations and changes to existing regulations

MMIS business modules may be provided by different vendors

State and Federal procurement rules

Need to obtain Centers for Medicare and Medicaid (CMS) Certification for 90/10 funding

1.2.2 Design and Implementation Goals and Constraints

The TRA supports the capability of the modernized MMIS to meet the following Design and Implementation Goals:

Modularity

Flexibility

Cost efficiency

Positive experience for members and providers

Ability to respond quickly to regulatory changes or program needs

Design and implementation constraints include:

Federal and / or State funding limitations

Modernization project schedule changes

Staffing limitations

1.2.3 Capacity and Performance Goals and Constraints

Capacity and performance are related concepts used to measure operations. The TRA uses the following definitions:

Performance: A measure of system or module operations over a specific time. Performance metrics are typically based on the time required to complete a distinct operation or the time to complete a set of related operations. Multiple performance metrics are generally required to view the overall performance of a system or module.

Capacity: The resources available to operate the system or module. Capacity represents a maximum level of resource availability. At any point in time, the system may be using a subset of the total capacity. The system may be able to adjust resources to improve performance, until it uses the maximum available capacity of the resource. When the needs of the system exceed the current capacity, additional resources must be purchased or provisioned.

Module vendors must support the following goals for delivery of a satisfactory experience for users and effective operation of the Medicaid program:

Ability to operate with scheduled changes of resource demands

April 8, 2025 Page 11

Ability to respond rapidly to changing resource demands

Minimize the cost associated with operating at varying capacity levels

Maintain required response times for the User Experience/User Interface (UX/UI)

Complete real time requests within required response times

Forecast future capacity needs

1.3 TRA Publishing and Maintenance

The TRA will be updated, reviewed, and published throughout the life of the MMIS Modernization Project and the MMIS operations and maintenance phases. The Architecture Review Board (ARB) must approve the initial version of the TRA and subsequent updates.

1.3.1 TRA Publication

The TRA will be published as an Adobe PDF file on the Project Management Office (PMO) SharePoint site.

Each new version will be assigned a unique version number.

The TRA will be available for inclusion in the procurement libraries of future Request for Proposals (RFPs) to provide a reference for the permissible technologies, standards, patterns, and tools for components of the IDHW architecture.

1.3.2 TRA Modification Schedule

Triggers for TRA updates include:

A change to the reference architecture approved by the ARB

A change in the documentation, but not the reference architecture, is required for clarity

New technologies and vendor offerings emerge

New or updated Federal or State technology mandates are published

In addition to the above triggers for TRA updates, the TRA will be reviewed periodically as follows:

By the end of the first month of every quarter, the TRA will be reviewed to determine if any updates are required. If updates are required, a new version will be published.

When the TRA is updated and approved by the ARB, a notification will be sent to all state and vendor stakeholders with a link to the current version of the TRA.

1.4 Relationship to IDHW Procurements

All IDHW module and integrator procurements will include requirements for vendors to comply with the TRA to realize the vision of a modular, modernized MMIS and attain IDHW’s business goals. Compliance will be demonstrated by formal vendor deliverables, technical documentation, or other information as requested by the System Integration Technical Advisory Team (SITA) or IDHW. The System Integrator (SI) Hub will be built to align with and be implemented and operated according to the TRA under the supervision of the SITA team and IDHW staff.

The SITA vendor has reviewed the TRA against the National Association of State Procurement Officials (NASPO) claims and provider requirements and IDHW participating addenda to ensure it does not conflict

April 8, 2025 Page 12 or add scope for module vendors. The TRA is intended to provide the next level of detail for implementing existing integration requirements to support IDHW’s overall vision. Module vendor requests for waivers from TRA standards will be addressed on an as needed basis by the ARB.

1.5 Architecture Compliance

MMIS modules and supporting systems must comply with this Technical Reference Architecture.

Exceptions must be approved by the ARB. The process for requesting exceptions is documented in the ARB Charter.

April 8, 2025 Page 13

2 ARCHITECTURE OVERVIEW

There are multiple aspects of the architecture of the MMIS, and these must be considered holistically.

Industry architectures such as the MITA, The Open Group Architecture Framework (TOGAF), and Federal Enterprise Architecture Framework (FEAF) recognize four (4) primary architecture domains. Some architectures combine some domains but still identify the four (4) core architecture areas. The four (4) core domains are:

Business Architecture

Application Architecture

Information Architecture

Technical Architecture

There are additional architecture domains that overlap the four (4) core domains. For the MMIS Modernization Project, these are:

Module Architecture

Integration Architecture

Security Architecture

Additional information can be found in the Architecture Design Standards document on the IDHW SharePoint site.

2.1 Business Architecture

The business architecture is developed to support IDHW specified goals and objectives of the Medicaid program. A summary of the business architecture relevant for the TRA is:

The MMIS will be comprised of various modules that each address specific business domains.

IDHW may potentially procure modules independently from various vendors.

A SI Hub will serve to integrate MMIS Modules, providing for standardized and open exchange of data.

The SI Hub will provide performance reporting for the business modules based on data submitted by the modules to the SI Hub.

2.2 Application Architecture

The internal application architecture of the MMIS will vary between modules. Vendors may define the internal application architecture, but the module must conform to IDHW requirements defined in Section 5, Application Architecture.

2.3 Information Architecture

The MMIS requires an integrated information architecture including Data Management and Data Governance. Module vendors must participate in the Data Management and Data Governance activities.

April 8, 2025 Page 14

Data Management and Data Governance applies to data within applications and data exchanged between modules.

2.4 Technical Architecture

The technical architecture of the MMIS will vary between modules but each module must meet the requirements specified in Section 6, Technical Architecture.

2.5 Security Architecture

IDHW requires vendors to comply with a common set of security requirements and regulations. The scope of the security architecture impacts the business, information, application, and technology architecture domains. Section 8, Security Architecture provides the detailed requirements.

2.6 Integration Architecture

As with the security architecture, the integration architecture impacts the business, information, application, and technical architecture domains. The business aspects include the requirement for modularity while still integrating the modules in a well-defined framework. Section 7, Integration Architecture, presents the specifications which all modules must comply with.

2.7 Module Architecture

Each module must be designed, built, and implemented independent of other modules. The only permitted operating interaction between modules is through pre-defined interfaces which use the SI Hub.

This applies to scenarios in which a vendor provides multiple modules. Requests for exceptions can be brought to the ARB.

Module vendors must provide architecture documentation. The content required in the documentation will be defined by IDHW. The architecture content will include, but not be limited to:

Context diagrams which show the incoming and outgoing information for each module including its source and destination. The diagram will include all inputs and outputs even if the same vendor provides both modules exchanging information.

Interface Control Specifications (ICSs) using formats defined by IDHW. ICSs are required even if the same vendor provides both modules exchanging information.

List and description of capabilities provided by the module to support other module requirements.

Capabilities required from other modules.

Compliance with integration standards for enterprise supporting components such as the SI Hub, Identity and Access Management/Single Sign On (IdAM/SSO), and Electronic Document Management System (EDMS).

Information about the organizations using the module.

Key Performance Indicators (KPIs) and measurement approaches.

Approach to meeting Service Level Agreements (SLAs).

April 8, 2025 Page 15

Information, defined by IDHW, supporting the requirements of the other architecture domains.

Section 2.9 provides guidance on representing the architecture of a module.

2.8 Testing Framework

The testing framework is not a traditional architecture domain, but the TRA impacts testing requirements.

Section 9, Architecture Impact to Testing presents the requirements for testing to ensure modules comply with the TRA.

2.9 Architecture Design Standards

The contents of architecture views must be appropriate to the stakeholder.

Diagrams for business stakeholders should be based on boxes for elements or key concepts and connectors depicting relationships and data flow. The diagrams must omit technical information such as hosting locations, servers, networks, and locations.

Diagrams for data focused stakeholders may show the data flow between modules but without networks or other technical information. Data models and schemas require an association to an individual interface, but only data items should be included on the diagram. Data schemas should include only the data without concern to the method of data exchange.

Architecture design standards address the methods of representation of the architecture to stakeholders.

Architectural designs must be presented to stakeholders in a way that communicates information on a particular topic. Different stakeholder groups will likely require different representations of the same architecture topic. When presenting information on module integration, business owners need to understand which information is sent from one (1) module to another, what triggers the communication, and how is the information kept up to date. Technical staff may be interested in the required communication between clouds required to support the communication. Representations for these two

(2) stakeholders will differ significantly.

Architecture frameworks use the terms views and viewpoints to describe the architecture representations. The TRA uses the following descriptions of these and related terms:

Architecture viewpoint: a perspective of the architecture relevant to a particular stakeholder and topic

Stakeholder: a person impacted by the architecture of the system

Topic: An aspect of the system or architecture that must be understood. “Concern” is used instead of descriptions of viewpoints

Views: A common way of representing the architecture

View Specification: a standards-based framework for building views

An architecture view is often a diagram but may be a list, a spreadsheet, or a document. A standard set of views is necessary to maximize communication and an understanding of the architecture. Module vendors use a context diagram to communicate data exchange with business stakeholders. The context diagrams should look similar, regardless of which module vendor creates the context diagram.

The View Specification defines the standards to follow when building a view. Following the standards has two (2) benefits. The first is to provide guidance to create the artifacts consistently which makes the

April 8, 2025 Page 16 representation understandable to stakeholders. The second benefit is that standards enable organizations to exchange electronic versions of artifacts so they can be used with multiple diagramming or modeling tools. For example, IDHW and vendors may use different tools to create context diagrams, but standards enable exchange of the content between tools.

Table 1 presents guidance for common viewpoints representing stakeholders and potential topics of interest. These representations are likely to be needed for all modules which are part of the MMIS Modernization. Vendors may have alternative representations, and these should be evaluated on their effectiveness in making the information understandable, and their alignment with standards that support exchange of artifacts between architecture software tools. As the needs for every module are different, this list is for guidance rather than a comprehensive list of artifacts required for every module.

Table 1: Architecture Representations

Architecture Viewpoint Standard Architecture Views

View Specification

Stakeholders Topic

Business Owner Module definition and integration

Module Context Diagram

Information Exchange

High-level System Components

UML Class Diagram UML Information Flow (with information item details) Data Flow Diagrams UML Components Diagrams

Business Owner Functional module requirements

Requirements List

Requirements Relationships

Requirements Traceability

Excel or Requirements Management tool UML Requirements diagrams showing aggregation and composition Requirements traceability diagram

Business Owner Functionality Use Cases

Business Processes

UML Use Case Diagram BPMN Process Diagrams (associated to use cases)

Business Owner Integration staff Developer

Exchange of data Interface description

Conceptual Model of interface data

Logical Model of interface data

Interface list Interface Control Document UML Class Diagram UML Class Diagram

Integration Developer

Data structure and format Physical data model XML Schema JSON Schema Data file specifications

Security Staff Single Sign On

Layers of security protection

Technical architecture for penetration testing

Interaction between systems during sign on

Diagram representing the layers and their relationship.

Infrastructure diagram

UML Sequence Diagrams

UML Component Diagram

April 8, 2025 Page 17

Architecture Viewpoint Standard Architecture Views

View Specification

Stakeholders Topic

IT Staff System components Networks Environments

Infrastructure diagrams with varying level of detail

April 8, 2025 Page 18

3 BUSINESS ARCHITECTURE

While most aspects of business architecture are outside the scope of Technical Reference Architecture, all architecture domains must support IDHW business goals and objectives. This section presents attributes of the business architecture that impact the remaining architecture domains.

3.1 Business Environment

The business environment for the MMIS Modernization is complex and driven by multiple factors. Each aspect of the business environment impacts the TRA. Table 2 presents key business factors and their impact on the TRA.

Table 2: Business Environment Factors and Their TRA Impact

Business Factor Impact on TRA

IDHW Organization The modules must have the ability to adapt to changes in the IDHW organization, roles, and responsibilities. Organizational changes impact system ownership, data stewardship, and user roles that define privileges for individual users.

MMIS Modernization Project The MMIS architecture must include the flexibility to support changes in schedule to the multi-year modernization project.

MMIS Procurements Successful procurements require a well-defined reference architecture including publishing the reference architecture for potential bidders.

Federal, State, and IDHW security and privacy regulations including HIPAA and

MARS-E

Defines requirements which must be complied with by the security architecture.

MITA MITA requires a modular MMIS system which must be supported by the integration architecture.

CMS Outcomes Based Certification Applications must support outcomes by tracking KPIs.

State Legislative Requirements Requires flexible modules to support the MMIS changes needed to implement new legislation.

CMS Interoperability Rules Defines requirements for the integration architecture.

Requires the information architecture to support exchanging the appropriate data with external systems.

Requires the application architecture to support the required interface services.

April 8, 2025 Page 19

3.2 Performance Measures

Vendors must provide an acceptable level of system performance to meet IDHW business goals and objectives. System performance is more than system response time and includes standards that must be realized to meet operational goals.

Accurate measurement of performance requires that metrics are collected through functionality provided by a module’s application or technical framework. These measures are either reported on within a module or passed to the SI Hub for reporting.

The types of performance measures which impact the architecture are:

KPIs – Important metrics that provide an objective representation of the effectiveness of systems and processes needed to achieve business goals

SLAs – Contractual metrics that define a minimum performance level a vendor must meet

Other Performance Measures – Additional metrics that may be specified by IDHW or vendors to measure and determine the performance of system components

3.2.1 Key Performance Indicators

KPIs represent measures of performance that directly impact the ability to meet business goals and objectives. They are often defined prior to system design and implementation and may be included in Advance Planning Documents (APDs) submitted to CMS for funding.

Support for KPI measurement must be built into the applications of each module. The measurement capability must be flexible to support changes to KPIs or KPI thresholds. KPI measurements must be available in reports, dashboards, or within a modules User Experience/User Interface (UX/UI), based on requirements specified by IDHW. Each module must send KPI data to the SI Hub, compliant with specifications approved by IDHW. Vendors must provide IDHW with the ability to review source data for KPI measurement when requested.

3.2.2 Service Level Agreements

SLAs are minimum standards for aspects of system performance such as response time or system availability. SLAs are typically included in contracts between IDHW and a module vendor. Contracts may define penalties for failure to meet the SLAs.

SLAs measurement should be performed by a module application delivered to IDHW via reports, dashboards, within a modules UX/UI, based on requirements specified by IDHW. If measuring SLA performance within a module is not feasible, IDHW may permit vendors to develop reports outside of the module using either automated or manual processes. Each module must send SLA data to the SI Hub, compliant with specifications approved by IDHW. Vendors must provide IDHW with the ability to review source data when requested.

3.2.3 Other Performance Measures

IDHW and module vendors may identify additional performance metrics that support operation and delivery of services. These other measures may be permanent, or they may be used for a limited period of time to assess the impacts of a specific problem.

IDHW must approve the metrics and the way performance is measured.

April 8, 2025 Page 20

3.3 Integration Approach

Modularity is a requirement for applications that are part of the MMIS Modernization Project and modularity requires a successful approach to integration. The following are key elements of the integration approach which impact other domains of the TRA:

Use of an SI Hub which facilitates the exchange of data between modules

Use of data management and data governance processes

Well-defined and reusable interfaces for exchanging data with a module

Interface documentation as defined in Section 7.4 Interface Documentation Minimum Standards

Additional information can be found in Section 7 Integration Architecture

3.4 Environments

IDHW requires module vendors to provide multiple environments to support implementation and maintenance activities. Each environment must be independent from other environments so that the activities in one (1) environment do not impact others.

The following subsections present the environments in three (3) categories:

1. Primary Environments – These will be used daily throughout Design, Development and Implementation (DDI) and Maintenance & Operations (M&O).

2. Part-Time Environments – These will be used during DDI and M&O but will not be used on a daily basis. These environments may be turned off when not in use, as determined by

DHW.

3. DDI Environments – Environments that are only needed during DDI. They can be shutdown when determined by DHW after modules go into the M&O phase.

3.4.1 Primary Environments

Table 3 presents the primary environments used throughout DDI and M&O.

Table 3: Primary Environments Used Throughout DDI and M&O

Business Function

Description System Integration Requirements

Architectural Components

Availability Minimum Capacity

PHI Per-mitted

Development Single module development

None As needed for development and testing of a single module.

Driven by vendor needs

Small No

System Integration Testing

Integration and module functionality testing.

Full SI Capabilities

All Project working hours with approved maintenance windows

Medium No

April 8, 2025 Page 21

Business Function

Description System Integration Requirements

Architectural Components

Availability Minimum Capacity

PHI Per-mitted

User Acceptance Testing

Formal test cases for approval

Full SI Capabilities

All Project working hours with approved maintenance windows

Medium Yes

Production Production operations

Full SI Capabilities

All 24 x 7 Full production capacity

Yes

3.4.2 Part-Time Environments

Table 4 presents the part-time environments used during DDI and M&O. They will only need to be available as needed and approved by DHW.

Table 4: Part-Time Environments Used During DDI and M&O

Business Function

Description System Integration Requirements

Architectural Components

Availability Minimum Capacity

PHI Per-mitted

Performance Testing

Validates new or modified system meets KPIs and SLAs prior to implementation.

Limited based on testing needs

All As needed with approved maintenance windows

Full production capacity

No

Training Staff Training. Limited based on training needs

TBD during

DDI

As needed with approved maintenance windows

Medium No

3.4.3 DDI Only Environments

Table 5 presents the environments used only during DDI and can be turned off after systems go live and DHW approves.

Table 5: DDI Environments Used During DDI

Business Function

Description System Integration Requirements

Architectural Components

Availability Minimum Capacity

PHI

Per-mitted

Conversion Testing

Build and test data conversion and load into new system

None Database and associated tools at a minimum

Project working hours with approved maintenance windows

Full production capacity

Yes

April 8, 2025 Page 22

Business Function

Description System Integration Requirements

Architectural Components

Availability Minimum Capacity

PHI

Per-mitted

Parallel Policy Testing

Validate the new system produces the same results as the existing system unless changes expected based on design.

Limited based on testing plan

All As needed with approved maintenance windows

Full production capacity

Yes

3.5 Enterprise Document Management System

The existing MMIS has four (4) components that are referred to collectively as “EDMS”. These components were added to the MMIS at the same time and consist of:

1. Document Management – responsible for storinge a variety of document types and associating them with aspects of the MMIS such as Provider Enrollment. Enables staff to retrieve documents when needed.

2. Workflow – capability to develop a process defined as a series of steps with routing from one (1) step to another. Each step can be performed by an individual or group and the items in active workflows can be managed and reassigned.

3. Letter Management – capability for creating, printing, and sending letters to a provider.

4. Capture Management / Scanning – used primarily for scanning paper documents received in the mailroom and adding them to the EDMS for use in MMIS operations.

In the modernized MMIS, these four capabilities must be delivered in whole or in part by vendor solutions. The capabilities will not be managed centrally by the SI Hub.

Some current MMIS module solutions on the market do not include some or all of these capabilities.

Future MMIS procurements must consider which capabilities are necessary for the system vendor to provide to IDHW as part of the solution. All interfaces to COTS tools providing these capabilities must use APIs.

Implementation of these capabilities, including any COTS tools, must comply with the TRA.

Table 6 provides an overview of the legacy ‘as is’ and ‘to be’ solution architectures for the components referred to by IDHW as “EDMS”.

Table 6: EDMS “As Is” and “To Be” Solutions

ExisƟng EDMS Capability “As Is” “To Be”

Document Storage Vendor’s MMIS EDMS is used for documents created or received by the business operations processes.

ITSD uses LaserFiche for provider grievance and appeal documentation

All vendor solutions must specify the approach to document management in proposals and contracts.

Vendors must provide their own document management capabilities.

April 8, 2025 Page 23

ExisƟng EDMS Capability “As Is” “To Be”

Document Scanning Capture Manager If a vendor’s solution requires document scanning, the vendor must specify the approach to document scanning in proposals and contracts. The approach must address storing documents after they are scanned.

Vendors must provide their own document scanning capabilities.

Workflow and Rules Management

Process Manager & Workflow Rules

If a vendor’s solution uses workflow or rules management capabilities, the vendor must specify the approach to providing workflow and rules management in proposals and contracts. The approach must address storing and retrieval of documents used in workflows.

Vendors must provide their own workflow and rules management capabilities.

Correspondence GeneraƟon

Letter Manager If a vendor’s solution creates correspondence to any outside entities including, but not limited to, members, providers, employers, and drug manufacturers, the vendor must specify the approach for correspondence generation in proposals and contracts. The approach must address storing documents after they are scanned.

Vendors must provide their own correspondence generation capabilities

3.6 Release Management

Release management processes must support the modular architecture of the MMIS. It is a business requirement to implement functional or policy changes in all modules at the same time. However, because vendors are delivering some modules using a COTS or Software as a Service (SaaS) models, they may release changes for all of their customers at the same time. DHW may not be able to control the release schedule.

Release plans must accommodate different release schedules from each vendor and the schedules may differ in both production and non-production environments.

Because each module vendor will have its own release management framework, the primary need is coordination across modules when implementing changes. The following factors are the challenges of release management in a multi-vendor environment:

Related system changes from multiple modules must “go live” at the same time

Vendors have different internal release processes

April 8, 2025 Page 24

Vendors of COTS and SaaS tools may define a release schedule that all clients must follow, leaving less flexibility for IDHW to coordinate releases

To support IDHW’s business needs for implementing changes across modules at the same time, vendors must take the following approach:

Modules must implement configuration controls turning on and turning off functionality added or changed in a new release. This approach enables vendors to release applications but provide the ability for DHW to configure the changes to take effect at a later time.

Release schedules for every environment (other than development environments used only by a module vendor) must be approved by IDHW.

Releases must be made first into the System Integration Testing (SIT) environment, then into the User Acceptance Test (UAT) Environment. Releases in any of these environments require IDHW approval.

Releases into UAT must precede releases to the other environments (excluding development and SIT environments) listed in Section 3.4 Environments.

Updates to COTS tools, including operating systems must be implemented and tested in environments in the same order as other releases.

Vendors must provide sufficient time for testing releases and regression testing in non-production environments prior to release into production. The time required will be defined by DHW through the change management process. Changes may impact multiple modules, and the vendors must support the time required for integrated testing.

DHW approval is required prior to moving a release into production. DHW may deny approval if there are outstanding defects or insufficient time to complete testing.

Additional details can be found in Section 5.7 Release Management covering application architecture and Section 6.5 Release Management covering the technical architecture.

3.7 Data Retention

An effective archiving and backup strategy are critical for ensuring data integrity, compliance, and operational continuity when issues arise. The SI HUB platform requires the backup and archival of not only MMIS module data, but also system logs, usage information, transaction history, performance monitoring, metadata, analytic data, and data files. This strategy takes into consideration the following types of data files/data movement:

Data moved from one (1) module to another

Incoming data from external organizations including CMS

Publishing (or sending) data outside the platform. This data must be backed up and/or archived in order to maintain the system should issues require it to be rebuilt or restored.

Primary business requirements for this strategy include regulatory compliance, data retention, accessibility, security, and even cost efficiency. Regulatory compliance mandates that specific data are retained for predefined periods of time to meet standards such as HIPAA and Health Information Trust (HITRUST); ensuring historical data is preserved and can be retrieved for audit and legal purposes.

Accessibility and security dictate archived data should be indexed and stored in a manner which allows

April 8, 2025 Page 25 for quick and efficient retrieval based on search parameters. Additionally, these strategies must ensure that data can be restored quickly and accurately in the event of data loss or corruption, minimizing downtime and maintaining business continuity. Cost efficiency is also a key consideration as the organization seeks to balance a robust data protection need with the financial implications of storage and maintenance. For clarity, backup refers to the process of creating copies of data at regular intervals to protect against data loss, while archiving refers to moving data that is no longer actively used to a separate storage system for long-term retention. It is the intention of IDHW to retain data for the life of the system rather than delete or purge records.

3.8 Business Continuity

Most aspects of business continuity planning are outside the scope of a TRA. Two (2) critical business requirements for business continuity are:

Recovery Time Objective (RTO) – the amount of time acceptable between the loss of processing and the restoration of processing

Recovery Point Objective (RPO) – the amount of acceptable lost processing. Examples are recovering all but the last five (5) minutes of processing and recovery to the beginning of the nightly batch processing

The RTO and RPO must be defined for each module and potentially for specific functions within each module.

Module vendors must design their applications, processes, and infrastructure to meet the RTOs and RPOs.

RTOs and RPOs may be included in existing Disaster Recover Plans, RFP text, RFP requirements, contracts, the Technical Reference Architecture, or system change orders. IDHW may provide the requirements for RTOs and RPOs through other means.

April 8, 2025 Page 26

4 INFORMATION ARCHITECTURE

Information Architecture is currently covered in the Data Management Strategy Framework (DMSF) and Data Governance Plan.

Information Architecture subjects that overlap with other architecture topics are covered in the following sections:

3.7 Data Retention (business architecture)

5.9 Data Retention (application architecture)

6.6 Data Retention (technical architecture)

6.7 Data Backups (technical architecture)

7.3 Interface Data Strategies (infrastructure architecture)

8 Security Architecture (security architecture)

9.1 Data Permitted in Testing Environments (architecture impact to testing)

4.1 12.2 Data Standards (List of Standards) Data Quality Agreements and Automation

IDHW is implementing Data Quality Agreements and Automation (DQAA) in the MMIS. DQAA is an approach to managing and implementing interfaces and will be applied throughout the MMIS. The team designing the interfaces will include IDHW, vendors, data SMEs, and others identified by IDHW. The team will apply DQAA principles to the design of new interfaces and to changes to existing interfaces. IDHW will determine when inclusion of DQAA will begin.

During interface design, the team performing the design will consider the needs of processes that will perform automated validation of data exchanges. These needs include specifications, traditionally documented on an Interface Control Document (ICD) and other specifications required for DQAA. DQAA requires that specifications are stored in a software tool which manages the validation and automation processes. Information stored in the software tool supporting DQAAs will be made available to IDHW and the stakeholders supporting these processes. The collection of specifications, stored electronically in the DQAA tools and those stored outside the system is called Interface Control Specifications (ICS). The structure of the ICS, stored both inside and outside the DQAA tools, will be determined by IDHW and managed by IDHW or designated individual supporting DQAA processes.

DQAA validations defined in the ICS occur in the SI Hub during data exchanges. Specifications for validation include, but are not limited to, the data schemas exchanged, validation rules, the frequency and timing of the exchange, versioning, and rules for exception processing and notifications. IDHW will define which details are required and participants in interface design will include these details in the specifications.

IDHW staff or designees from the team designing the interface must present interface specifications, that include the content defined by IDHW, to the Data Governance Board and the Architectural Review Board to ensure the specifications meet the requirements established by both boards. IDHW will define the required specifications and formats that must be used when presenting to each board for review.

April 8, 2025 Page 27

5 APPLICATION ARCHITECTURE

MMIS module applications must meet the following criteria and provide evidence, as defined by IDHW, that it meets the criteria:

Uses widely accepted design patterns

Developed using integrated development environments

Highly configurable

Meets IDHW UX/UI standards

Avoids use of capabilities such as stored procedures that require a specific database product

Uses a real time build process that includes security analysis of all code

Applications must rely primarily on configurability to implement DHW requirements, with custom application code only being used for specific scenarios where use of configuration would potentially degrade system performance or hinder maintainability. Table 7 provides a list of the most common scenarios where custom application code may be acceptable.

Table 7: Scenarios Where Custom Application Code May be Acceptable

Scenario Description Example

Complexity When the functionality is of a high level of sophistication and logical intricacy, requiring program logic to address in way that is maintainable and/or performant.

Developing complex calculation logic based on specific indicators and data sources to comply with Federal Regulations.

Customization When specific business requirements cannot be met by out-of-the-box solutions.

Extending an off the shelf Case Management System to incorporate unique client specific business processes.

Integration When integrating with other systems or applications that require custom code.

Developing custom APIs to connect an ERP system with a third-party logistics provider.

Performance Optimization

When performance improvements are needed that cannot be achieved through configuration alone.

Writing custom code to optimize database queries for faster report generation in an approach recommended by the Database product vendor.

Security When additional security measures are required that cannot be achieved through configuration alone.

Implementing custom encryption algorithms to protect sensitive data in a way that is necessary to fully comply with Security control guidelines.

Integration with Third-Party COTS Product

When integrating with a COTS product that requires custom code.

Developing custom connectors to integrate a COTS product with existing enterprise systems in a product vendor supported way.

April 8, 2025 Page 28

Applications must rely on configurability to implement DHW requirements. Custom application code should only be used for complex requirements. The following items should be configurable:

UX/UI features such as field names, page and subpage names, colors, graphics, icons, page headers and footers

Role Based Access Control, including the quantity and names of roles and the permissions defined for each role. This requirement includes core module components and functionality such as workflow, document management

Service names, versions, network addresses, and ports for services provided by the system

Service names, versions, network addresses, and ports for services called by the system

Which activity must be logged, and which activity must be submitted to central logging servers

Information unique to environments such as database names, number of instances for individual components, minimum and maximum instances for scaling, thresholds that trigger scaling

Business rules including dates and times for implementation of individual business rules and processes

Workflow queues, groups, and the groups that information is routed to

Field edits

Valid values for data fields

Use of custom application code, rather than configuration, must be approved by the ARB

5.1 Application Interface Patterns

MMIS modules will have multiple approaches to interfacing with each other including service-based interfaces and file-based interfaces. The available interface patterns are described in the subsections below.

5.1.1 Synchronous Data Exchanges

Synchronous exchanges require an executing process in the source system to wait for confirmation from the receiving system prior to executing the next sequenced activity.

The…