Introduction

Introduction / Overview text goes here. This page will be structured based on the Architecture Design Standards Document. The content can be divided into multiple pages if desired.

Architecture Representations

High-level expectations of the development and maintenance of architecture representations, or “views”, are provided in the following subsections. Each module vendor will be expected to develop similar representations for each of their modules. Specific documentation and diagramming formats and templates should be elaborated and agreed upon with IDHW prior to the start of architecture development.

Business Architecture

Business Architecture is a visual representation of IDHW’s business capabilities and organizational structures, and the relationship between these capabilities, business groups, and other stakeholders such as members and providers. Knowledge and definition of the business architecture is a prerequisite to the architecture work outlined in the following sections, as it is key to determining and demonstrating the business value of MMIS modernization activities.

The objectives of capturing Business Architecture are to:

• Develop a high-level vision of the capabilities and business value to be delivered as part of the proposed future state MMIS architecture
• Develop the future state business architecture, describing operations needed to achieve the identified capabilities and business value

The Business Architecture representations should capture the following areas across all MMIS modules:

• Business Areas-Capabilities View: High-level business capabilities and the business areas they are associated with (see sample in Figure 1)
• Business Areas-Information View: Business functionality areas and the high-level business information exchanged between them (Figure 2 demonstrates this view, using the current MMIS solution as an example)

Module Architecture

Module Architecture is a representation of the MMIS modules, their associated vendors, and how they relate to business areas and capabilities. Knowledge and definition of the module architecture is critical to the management of MMIS modernization, as it is used to determine any gaps and impacts of the intermediate steps of module modernization that may occur during the project. This knowledge will give IDHW the needed information to make effective procurement decisions, as well as the ability to make key architectural decisions during project implementation to accommodate previously unforeseen circumstances.

Current-state and future-state module architecture should be developed, as both will be needed to identify gaps and to manage the implementation of updated modules. Diagrams and artifacts from existing and prospective vendors should be used as inputs to creating the module architecture. Figure 3 below provides an example view of business areas related to modules and vendors. When the System Integrator and new modules join the project, updated/additional view(s) should be created to depict the integration between modules, accounting at a high-level for the types of data exchanged and the frequency with which it is exchanged between modules.

The objectives of capturing current- and future-state Module Architecture are to:

• Describe and demonstrate how the recommended modular architecture enables the business architecture and business capabilities identified in Section 2.1 Business Architecture
• Facilitate analysis of potential intermediate modular architecture states which may occur during modernization
• Identify and document any gaps which may occur in intermediate states during vendor transition(s)

The Module Architecture representations should capture the following areas across all MMIS modules:

• Business Capabilities-Module View: Linkage between modules, their vendors, and the business capabilities identified in Section 2.1 Business Architecture (see sample in Figure 2)
• Module-Integration View: All integrations between modules, accounting at a high level for data types, data standards, and exchange frequencies

Application Architecture

The Application Architecture design representations of the individual modules will include detailed diagrams of the structure for each module. This will include showing interactions between any applications within the module, including the data exchanged and the business process supported. This will include clearly diagramming how the module (and applications that are components of the module) are organized.

An additional required layer of documentation will be design representations that show how each module will interact with the other modules, the other MMIS components, and the system users.

Application Architecture is essentially “…a structural map of how an organization's software applications are assembled and how those applications interact with each other to meet business or user requirements. An application architecture helps ensure that applications are scalable and reliable, and assists enterprises identify gaps in functionality.”1 This should include describing how the applications interact with other solution components such as an application integration platform.

The objectives of capturing Application Architecture are to:

• Develop the future-state MMIS application architecture, capturing the flow of interactions within and across each MMIS module
• Identify and document gaps between prospective MMIS module capabilities and the needed functionality identified in Section 2.1 and Section 2.2

Information Architecture

The purpose of Information Architecture is, as described by ARMA International as “…the art and science of making information usable, findable, manageable, and securable. This is accomplished by applying information science to enterprise information environments to model and design logical systems for organizing, labeling, navigating, and searching information.” 2 Gartner describes it similarly, as “…activities that define a company’s business information assets, as well as the assets’ sources, structure, classification, and associations. Information architecture enables understanding and utilizing enterprise data and analytic assets to achieve desired business outcomes.”

Capturing information architecture at the level of detail required by IDHW, across all modules comprising the MMIS solution, is key to integrating various “systems of record” into a cohesive MMIS solution. Utilizing good data lineage practices (e.g., understanding where and how data is stored, which software and systems have access to that data, and how the data is used) is essential to the effective integration and management of modules.

The DMSF provides information architecture approaches in relation to the management of IDHW data assets. Modular vendors should be informed by and in compliance with the DMSF during the entire MMIS modernization project lifecycle.

The objectives of capturing Information Architecture are to:

• Develop the future-state MMIS information architecture, capturing the high-level flow of information contained within each MMIS module
• Identify and document gaps between prospective MMIS module capabilities and the needed functionality identified in Section 2.1 and Section 2.2
• The Information Architecture representations should capture the following areas across all MMIS modules:
• Information View: A explanation of how the data in the solution is classified and structured, as well as a high-level view of the structure

Technical Architecture

Technical Architecture representations of the modules will clearly diagram the technology components and layout of each MMIS module, as well as any integration technologies or tools determined necessary to facilitate the secure exchange of information between modules.

The objectives of capturing Technical Architecture are to:

• Develop the future state MMIS technical architecture, capturing technology components including hosting, infrastructure, and security components
• Identify and document gaps between prospective MMIS module capabilities and the needed application and information capabilities

The Technical Architecture representations should capture the following areas across all MMIS modules:

• Technology View: Hosting and infrastructure specifications within modules and between modules
  • Hosting platform(s)
  • Network interconnections and tunnels
  • Middleware, COTS, and GOTS products required for integration

The Technical Maturation Vision and Roadmap deliverable will provide additional guidance on the technical architecture and strategy.

Security Architecture

Security Architecture representations of the security components of each MMIS module will be required for each module. These representations will provide context and clarify on the proposed security design for each module. As with Application and Information Architecture, some module-specific information may be considered vendor proprietary. IDHW, however, will have the right to view key details about a vendor’s technical and security architecture to evaluate and mitigate performance and security concerns. Examples include where and how module’s software is hosted, as well as necessary integration details such as mutually agreed upon secure interfaces or network tunnels used to exchange information between modules.

The objectives of capturing Security Architecture are to:

• Develop the future state MMIS security architecture, including hosting, infrastructure, and security components
• Identify and document gaps between prospective MMIS module capabilities and the needed application and information capabilities

The Security Architecture representations should capture the following areas across all MMIS modules:

• Security View: Location and data flow for security components, including encryption information
  • Identity and Access Management components, such as authorization services and user directories
  • Security Incident and Event Monitoring (SIEM) services
  • Log collection and monitoring

Architecture Goals and Constraints

This section describes the high-level goals and constraints which have significant impact on the MMIS future state architecture. These areas are key inputs to the implementation of modernized MMIS modules and supporting tools and should be considered and accommodated as part of MMIS modernization to ensure successful implementation and integration of modules.

Compliance Goals and Constraints

The objectives of capturing compliance goals and constraints are to:

• Ensure the future state MMIS solution is always in compliance with current, relevant IDHW, State, and Federal policies
• Ensure security and privacy requirements are continually met across all modules, as well as necessary performance measures, audit requirements, and internal controls

Table 4 provides a sample of the compliance standards and requirements areas that should be considered as part of the future system architecture development described in Section 2.

Design and Implementation Constraints

The objectives of capturing design and implementation constraints are to:

• Ensure the future state MMIS solution, and intermediate transition states of the MMIS solution, can integrate with existing IDHW and partner systems
• Ensure continued operation of MMIS solution during intermediate transition states to the future MMIS solution architecture

The following design and implementation constraints should be considered as part of the future state architecture development described in Section 2:

• Contract timeframes: Throughout the project, it will be critical for the joint project teams (PMO, IDHW, SI, and module vendors) to be aware of the contract timeframes for the legacy components and implications of that to implementation timing of each module

Capacity and Performance Requirements

The objectives of capturing capacity and performance requirements are to:

• Ensure the future state MMIS solution can meet “non-functional” business requirements for the expected load of data and system users
• Provide a starting point for the development of service level agreements for future state modules

The following capacity and performance requirement areas should be considered as part of the future architecture development described in Section 2:

• Scalability: Each module will need to be sufficiently able to scale such that it will meet performance requirements for the duration of the life of the module, including accounting for increased member or user loads, peak-user times, etc.
• Availability: Each module will need to continually meet availability measures and standards for system uptime in relation to expected functionality
• Extensibility: Modules should have the ability to extend their solution by adding new functionality or modifying existing functionality. Enhancing functionality is to be accomplished via configuration, while custom development is to be minimized. Aligned to this principle, module extensions should be incorporated and scheduled into major and minor releases for the underlying product and not be “one-offs” for the MMIS solution
• Resiliency: Modules must have the ability to gracefully recover from system failures including malicious attacks, internal faults, or catastrophic events i.e., disaster recovery
• Observability: Each module must log and report information about system performance, program execution, and interaction with other MMIS modules

Software Development Life Cycle Standards

This section describes high-level guidelines and requirements for software development lifecycle (SDLC) standards used by MMIS Modernization vendors. IDHW recognizes that MMIS module vendors are positioned to work under their own development and operational methodologies. IDHW must ensure that minimum industry standard development and integration practices are accounted for in the vendors’ methodologies but without being unnecessarily prescriptive.

Integration Standards and Practices

The objectives of capturing integration standards and practices are to:

• Ensure integrations between modules are well-documented and follow industry standards wherever possible
• Ensure integration activities are well planned, coordinated, and tested to prevent unexpected impacts to MMIS business operations

The following integration standards and practices should be considered during the planning and procurement of modernized MMIS modules and tools, and documented as part of the future state architecture development described in Section 2:

• Use of interoperability industry standards wherever possible. There are several layers of consideration for this – the data layer, the transport layer, and the appropriate security protocols to be applied.
  • Data content standards for consideration include:
    • Fast Healthcare Interoperability Resources (FHIR)
    • Health Level Seven (HL7 v2)
    • Accredited Standards Committee X12 (ASC X12)
    • National Council for Prescription Drug Programs (NCPDP)
    • Consolidated Clinical Document Architecture (C-CDA)
    • Digital Imaging and Communications in Medicine (DICOM)
  • Transport layer standards for consideration include:
    • Simple Object Access Protocol (SOAP)
    • Hypertext Transfer Protocol Secure (HTTPS)
    • Secure File Transfer Protocol (SFTP)
  • Security protocols that can be considered for integration include:
    • Internet Protocol Security (IPsec) Virtual Private Network (VPN)
    • Mutual Transport Layer Security (Mutual TLS)
    • Open Authorization (OAuth)
    • JavaScript Object Notation (JSON) Web Token (JWT)
  • The InMP will speak to the topic of module integration in greater detail
• Use of standardized data exchange frequencies (real-time, daily, weekly, monthly)
  • The timing of each exchange needs to be mutually agreed-upon and documented, as well as response procedures when an exchange does not arrive at the set time
    • The IDMP will provide more detail regarding parameters to be documented as part of the interface design process
• Robust, comprehensive integration change coordination processes
  • It will be critical for changes to be well-coordinated across the Medicaid Enterprise, including with the eligibility system
    • Changes made in an “upstream” system and not communicated to, or understood by, downstream systems will adversely impact data integrity and even business function
    • The ReMP will provide more information on this topic

Modular Development Minimum Standards

The objectives of capturing development minimum standards for the modules are to:

• Ensure development processes promote stable, high-performing code with low defect rates and in compliance with security safeguards
• Promote a preference for approaches that result in:
  • Efficient, effective development
  • Minimization of custom development

The following development areas should be considered during the planning and procurement of modernized MMIS modules and tools, and documented as part of the future state architecture development described in Section 2:

• Documented and State-approved quality development standards
  • IDHW’s technology division, ITSD, has published standards for Java development (ITSD to provide the SharePoint location), many of which are applicable to wider use and speak to some of the topics noted in this section. It will be required of vendors to align as much as possible with these and any other state standards that may be published in the lifetime of the project. This section will need to be updated in future iterations with those standards.
• Developer training and assessment processes
  • Module vendors must provide an overview of their development training and certification procedures to allow IDHW to assess whether the procedures are sufficiently comprehensive and technically adequate
• Code repository platforms
  • Module vendors will also be required to provide an overview of their configuration management processes, allowing IDHW to assess whether the procedures are sufficiently complete and technically adequate
  • The vendor’s approach must comply with the Configuration Management Plan, which will provide more comprehensive information on this topic
• Code quality processes and tools
  • A code quality inspection tool is recommended (e.g., SonarQube, Crucible)
  • Processes/procedures that support code quality, such as peer reviews (or similar) and robust code testing protocols, will be required
  • The ITMP will provide additional context and detail regarding required test approaches for integration-related testing
    • The ITMP will also include an outline of expectations for the required module vendor test plans, such as:

User Experience and User Interface Standards

The objectives of setting user experience and user interface standards are:

• To ensure a logical and consistent user experience across the MMIS system
• To ensure that the system usability accommodates all users
• To ensure that the system works across multiple platforms and conditions (mobile, PC, etc.).

It is likely that each of the modules for the new MMIS will be pre-existing systems with their own “look and feel.” Given that, there may be limited opportunity to create a fully common standard view across the entire MMIS. However, there are some user experience/interface standards that must be met by all modules (e.g., Section 508 of the Rehabilitation Act). Additionally, wherever possible, the new modules will need to align with the IDHW Style Guide and other relevant standards.

User experience/interface standards that should inform module design efforts include:

• Compliance with section 508 of the Rehabilitation Act/Web Content Accessibility Guidelines (WCAG) 2.0 AA (latest version)
• Adherence to industry standard technologies as set forth in the World Wide Web Consortium (W3C) and are based on the W3C level 2 accessibility guidelines
• IDHW Style Guide