The Architecture for the SI Hub is built to meet the program's Architecture Design Standards.

The high-level technology architecture layers, components, and authorized Third Party integrations that comprise the SI Hub are depicted in Figure 14 below, along with any integration technologies or tools determined necessary to facilitate the secure exchange of information between modules. As a “Cloud-First” solution, the expectation is that the depicted technology stack will be deployed in a State licensed cloud environment.

Figure 14: High-Level SI Hub Technology Architecture Layers, Components, and Authorized Third Party Integrations

SI Hub Cloud Architecture

The high-level cloud architecture of the SI Hub ensures that the following objectives are met:

• The SI Hub architecture will use standard web-service interfaces to enable seamless integration with all modules in the SI Hub.
• The Agency will not prescribe the architecture of the SI Hub.
• Vendors can bid to build on any of three (3) IDHW available cloud platforms (AWS, Azure, GCP).
• Vendors can submit bids to build in one (1) IDHW cloud platform or any combination of the three (3).
• Vendors will respond with a list of cloud resources needed as part of their solution.
• As part of the proposal evaluation process, ITSD will work with the IDHW to review resource lists and estimate costs to the State for platform and ITSD support.

The SI Hub will support an ecosystem containing legacy and modern applications. The resulting architecture may require various middleware and API layers between the different components to join the software and hardware modules into one (1) cohesive infrastructure, enabling all the pieces to work as a whole.

Figure 15 depicts a high-level conceptual view of the hosting model for the current IDHW MMIS Enterprise. Figure 16 depicts the expected “cloud first” hosting approach that will be adopted for modules and supporting functionality introduced in Phase one (1) of the MMIS Modernization Project.

Figure 15: High-Level Diagram Depicting How the IDHW MMIS Environment is Currently Hosted

Figure 16: High-Level Diagram Depicting the “To-Be” Hosting Approach for the IDHW MMIS Modernization Project

The design and implementation of the hosting solution must meet the Agency’s expectations for uptime, Continuity of Operations, and Disaster Recovery. The solution shall meet the Agency’s SLAs while minimizing scheduled downtime. The hosting solution will remain flexible to incorporate new MMIS modules and accommodate new requirements and regulatory changes as the system matures over time. Additionally, the hosting solution will support the activities necessary to ensure the continuity and recovery of MMIS/business operations from possible disasters.

The System Integration Builder hosting solution shall support the Agency’s security requirements. At a minimum, the System Integration Builder must ensure all solution components and necessary environments comply with the security specifications as described in the Medicaid Enterprise Security Policy, which is based upon the Federal Office of Management and Budget (OMB) Circular A-130, National Institute for Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 200, NIST Special Publication 800-53: Security and Privacy Controls for Federal Information Systems and Organizations, and other applicable NIST publications. Temporary access to the Medicaid Enterprise Security Policy will be granted to qualified vendors for preparation of their response to this RFP.

The SI detailed Solution Architecture and Design and Business Requirements document will expand on the high-level SI Cloud Architecture through Technology Views, in accordance with the MMIS Modernization Project Architecture Standards.

The Agency requires solutions that leverage cloud-based hosting technologies for the SI Hub to provide a High Availability, scalable, and cost-effective infrastructure and offer the flexibility to integrate other MMIS modules as they become available. Cloud-based solutions enable the System Integration Builder to provide computing and data storage resources as needed to meet availability requirements.

4.7 SI Hub Security Architecture

This section describes the high-level Security architecture of the SI Hub with consideration for Identity and Access Management, Security Incident and Event Monitoring (SIEM) services, and Log collection and monitoring.

The SI Hub detailed the Solution Architecture and Design and Business Requirements document will expand on the high-level SI Security Architecture through use of Security Views, in accordance with the MMIS Modernization project Architecture Standards.

The modularity approach aligns with industry standards adopted by the Office of the National Coordinator for Health IT described in Final Rule (45 CFR part 170, subpart B). The security architecture of the overall platform and each component level conforms to CMS mandates.

Platform components interact with end users via the collective user interfaces in a device-neutral way. The SI Hub integrates the discrete security components and enables them to function as a single cohesive system, through the elicitation of requirements, incorporating the requirements into a system design, and implementing the orchestration of business functions within that system design. The public facing web interface provides delivery of Medicaid services by offering a unified, person-centered resource that increases ease of access and engagement.

Though the SI Hub implements recommended security standards, protocols, and practices, some of the interface partners may not be able to support the standards and instead support only a deprecated version of them. For example, some interface partners will only support Secure Sockets Layer (SSL), while the preferred standard for the Integration Platform is the successor of SSL, Transport Layer Security (TLS). Deprecated versions of protocols will lead to security risks like Man-In the-Middle-Attack (MITM). The vendor will prohibit the usage of deprecated connections, not allowing insecure connectivity into the platform.

Figure 17 below depicts a high-level conceptual view of the SI Security Architecture.

Figure 17: High-Level SI Security Diagram

Technical Security Architecture

The SI Hub Security architecture shall be based on a defense in-depth strategy to ensure that the confidentiality, integrity, and availability of the platform is secured and maintained. Defense in depth is comprised of six (6) functional segments that include the infrastructure, operating system, data, services, and access.

All software and hardware employed by the SI Hub shall implement all required security safeguards as specified in MARS-E (current version or equivalent) and best practices.

Figure 18 below depicts a universal strategic approach that employs multiple layers of security measures to fortify the environment against evolving threats. The Detailed SI Hub Solution Architecture and Design and Business Requirements will provide additional detail on the technical security requirements for the SI Hub.

Figure 18: Defense In-Depth Strategy

Identity and Access Management (IdAM)

The SI Hub Security Architecture shall provide a centralized IdAM framework. This capability provides identity management through IdAM rules and/or appropriate configuration to ensure appropriate constituent access to resources.

The IdAM system shall be tightly integrated with the SI Hub SSO functionality and with IDHW-administered identity provider services as a centralized security solution authentication, role-based authorization of user access to applications and application functionality, and SSO-enabled session management of SI Hub dashboards and MMIS Module user interfaces. The following architecturally significant requirements are addressed in this subsection.

• IDHW-administered user identity management: utilizes the Agency-administered Active Directory for State employees to manage user access for all SI components, as well as for establishing and managing “system accounts” that extend IdAM to interfaces, jobs, and other automated integration points. Active Directory security groups are employed so that for State employees there is no need for secondary user management within SI components.
• SI Hub integrated SSO and IdAM: implements user authentication, role-based authorization and auditing.

The IdAM system determines what resources are authorized to be accessed. These processes allow agencies to obtain a level of assurance for the identity of the individual attempting access to fulfill the following security compliance criteria:

• Authentication - Ensuring that all access is properly validated.
• Confidentiality - Ensuring that all access to information is authorized in terms of disclosure and non-disclosure.
• Integrity - Ensuring that all information is protected from unauthorized creation, modification, or deletion.
• Availability - Ensuring that authorized parties can access needed information.
• Non-repudiation - Ensuring the accountability of parties gaining access and performing actions.

Vendor shall provide, configure, support, update, and maintain a security solution for the SI that supports the following key components:

• Single sign-on - The capability to authenticate once and be subsequently and automatically authenticated when accessing various target systems.
• Identity and access control - Enables the right individuals to access the right resources at the right times for the right reasons.
• Federated identity management - Enables identity information to be developed and shared among several entities and across trust domains.