8/26/2016 SCDHHS - Confidential Page 1 of 12

TRA – Technical Reference Architecture

Medicaid Enterprise System

Reference Architecture Overview for

Prospective Vendors

Version 0.3

10/17/2022

Prepared by

South Carolina Department of Health and

Human Services

PL 017

8/26/2016 SCDHHS - Confidential Page 2 of 12

Table of Contents

1 INTRODUCTION

2 INTENDED AUDIENCE

3 DISCLOSURE

4 TECHNICAL APPROACH

4.1 OVERVIEW

4.2 MES CORE

4.2.1 Integration Hub

4.2.2 Enterprise Data Services (EDS)

4.3 INTERFACE STANDARDS

4.3.1 Internal Interfaces

4.3.2 External Interfaces

4.4 IDENTITY, CREDENTIALS AND ACCESS MANAGEMENT (ICAM)

4.4.1 For Citizens

4.4.2 For SCDHHS Workforce Members

4.4.3 For Providers

4.4.4 For All Other Users

5 APPENDICES

5.1 REVISION HISTORY

5.2 ACRONYMS

Table of Figures

Figure 1: Target Application Architecture

Figure 2: Data Management Pipeline

Figure 3: MES Core Application Components

8/26/2016 SCDHHS - Confidential Page 3 of 12

1 INTRODUCTION

The South Carolina Department of Health and Human Services (SCDHHS) is implementing a modernized, modular Medicaid Enterprise System (MES) in accordance with the Medicaid Information

Technology Architecture (MITA) published by the Centers for Medicare and Medicaid Services (CMS).

This Technical Reference Architecture (TRA) document provides an overview of the technical approach of the solution as well as the standards and tools that govern its implementation and operation.

As SCDHHS implements components and adds new technologies or techniques, it will update the TRA with additional standards, guidelines, and governance structures as applicable.

2 INTENDED AUDIENCE

The SCDHHS TRA audience includes SCDHHS staff, trading partners and vendors who will be implementing, operating, managing, or integrating with the SCDHHS MES.

The SCDHHS TRA provides a reference model by which technologies and components of the SCDHHS

MES will be measured for development and implementation.

3 DISCLOSURE

SCDHHS expressly restricts the distribution of this document to include only those SCDHHS staff, SCDHHS processing environment contractors, or any entity given explicit access to this document with

SCDHHS executive or management approval.

(Continued on next page)

8/26/2016 SCDHHS - Confidential Page 4 of 12

4 TECHNICAL APPROACH

The SCDHHS MES is a collection of loosely connected, highly integrated components. With this modern approach, SCDHHS will be able to replace components without impacting the rest of the MES or (more importantly) disrupting Medicaid processing.

4.1 OVERVIEW

The future SCDHHS MES will be a distributed system that integrates and manages data across internal and trading partners systems, as illustrated in the diagram below.

Figure 1: Target Application Architecture

The MES application components can be classified into:

• MES business applications – application components that enable core business functions (e.g.

member eligibility determination, encounters processing, document management etc.) and helper functions (e.g. data validations, processing logging, etc.).

8/26/2016 SCDHHS - Confidential Page 5 of 12

• Trading Partner applications – application components owned by external organizations contracted to provide business services to SCDHHS (e.g. Managed Care Organizations, Pharmaceutical Benefits Administration, etc.), Federal and State agencies (e.g., Department of

Social Services, Social Security Administration, etc.) and other third party systems (e.g.

research organizations).

• MES Core – incorporating the Integration Hub and Enterprise Data Services (EDS) Hub, which will ultimately tie together all systems participating in the Medicaid enterprise while providing a single source of truth for all Medicaid data.

4.2 MES CORE

Data flows through the MES Core by means of a well-defined data management pipeline, consisting of the following activities:

• Access – Access data from source systems.

• Ingest – Transport data from its source and ingest, in raw format, into EDS.

• Materialize – Transform data into a canonical model for member, provider, reference, claims, and encounter data.

• Deliver – Expose data via web services, file exchange, and direct access (internal systems only) for processing and consumption.

• Consume – Process and present data throughout the enterprise.

Figure 2: Data Management Pipeline

The MES Core application components include the Enterprise Integration Hub and Enterprise Data

Services.

The integration hub exposes the data in the EDS framework to whichever system component or trading partner requires it, according to contractual obligations, data sharing agreements and appropriate use considerations for each entity.

Consume Deliver Materialize Ingest Access

8/26/2016 SCDHHS - Confidential Page 6 of 12

Figure 3: MES Core Application Components

4.2.1 Integration Hub

SCDHHS is transitioning to a service-oriented architecture (SOA) with system functionality implemented into loosely coupled components and subsystems. Loose coupling across the enterprise will allow SCDHHS to retire legacy components over time (as SCDHHS replaces legacy functionality), without impacting business operations or other components.

The MES Core interfaces and integration services that enable data exchanges between loosely coupled components and subsystems are collectively referred to as the integration hub.

The capabilities that the integration hub exposes include (but are not limited to):

• Data ingress and egress interfaces, file-based or REST APIs

• EDI X12 translation

• FHIR APIs

• Messaging (publish/ subscribe)

• File management

• System to system ICAM service

• Interface to the Enterprise Data Services, for CRUD (create, read, update, and delete) functions

4.2.2 Enterprise Data Services (EDS)

The MES Core uses NoSQL technology to ingest data in its source format to form a “data lake” of raw data (RDL). By using NoSQL technology, the EDS can accept data in any format without protracted data modeling and analyses.

https://confluence.scdhhs.online/pages/viewpage.action?pageId=361844 https://confluence.scdhhs.online/pages/viewpage.action?pageId=361844

8/26/2016 SCDHHS - Confidential Page 7 of 12

Materialized records are stored in an Operational Data Store (ODS), where records can be further correlated, cleansed, and consolidated to form a holistic (or 360-degree) view of members, providers, claims and encounters. The ODS could also generate analytics reports and periodically populate data marts, designed to serve business intelligence and reporting needs.

The capabilities offered by the EDS include (but are not limited to):

• Source / target mapping

• Data shape translation

• Data validation

• Data merging and harmonization

• Data mastering

• EDS process orchestration

• Data analytics and reporting

• Meta-data management

• Data archiving

• Data security and privacy controls

4.3 INTERFACE STANDARDS

Trading partners interact with the MES by:

• Consuming web services and file exchanges exposed by the MES Core integration hub

• Exposing their own web services, or file exchanges for consumption by the MES Core integration hub

SCDHHS’ goal is to use the following industry format standards for all data exchanges:

• ASC X12 version 5010 or later versions as required by SCDHHS

• NCPDP version D.0, 3.0

• HL7® FHIR®

The sections that follow provide more specific guidelines for internal and external interfaces, which is defined as below:

Internal interfaces External interfaces

Internal interfaces refer to instances where:

• The source and target systems are

SCDHHS internal systems, and

• SCDHHS controls all interfaces

External interfaces refer to instances where

SCDHHS systems need to exchange data with

Trading Partner systems.

https://confluence.scdhhs.online/pages/viewpage.action?pageId=361846

8/26/2016 SCDHHS - Confidential Page 8 of 12

4.3.1 Internal Interfaces

SCDHHS’s goal is to use the following interface protocols as standards for internal interfaces:

• Representational State Transfer (REST) transactional interface, using a payload of either:

• JSON (primary)

• XML (secondary)

• Simple Object Access Protocol (SOAP) transactional interface, using an XML payload

• File-based (SFTP): publish or fetch a file where the data format could be (in order of preference):

• JSON

• XML

• CSV or other delineations as agreed upon

• Custom

4.3.2 External Interfaces

For external interfaces, SCDHHS is obligated to comply with Health Insurance Portability and

Accountability Act (HIPAA) regulations, which specify standards for exchanging protected health information (PHI) or personally identifiable information (PII) with Covered Entities and Business

Associates. The table below provides descriptions of these entities and the corresponding interface standards.

Covered Entities: Business Associates:

External entity descriptions

• Health plans, including:

• Government programs that pay for health care, like

Medicare, Medicaid, and military and veterans’ health programs

• Health insurance companies

• Health management or health maintenance organizations

• Employer-sponsored health plans

• Providers of health services

• Clearinghouses

• Third-party administrators that assist health plans with claims processing

• Pharmacy benefits managers who manage health plans' networks of pharmacists

• Consultants that perform utilization reviews for hospitals

• Health care clearinghouses that translate claims from a nonstandard format into a standard transaction on behalf of health care providers, and forwards the processed transaction to payers

• Independent medical transcriptionists that provide transcription services to physicians

Interface standards

• HIPAA obligates SCDHHS to use the EDI ASC X12N 5010 protocol

Adhere to SCDHHS standards as defined for internal interfaces.

8/26/2016 SCDHHS - Confidential Page 9 of 12 and format, for exchanging data that includes PHI or PII.

• Where data exchanged does not include PHI/ PII, adhere to standards as for internal interfaces.

4.4 IDENTITY, CREDENTIALS AND ACCESS MANAGEMENT (ICAM)

4.4.1 For Citizens

Citizens accessing agency systems or applications will be directed to create a username and password with a SCDHHS appointed third-party identity provider. All systems or applications that provide citizen access on behalf of SCDHHS must integrate with the third-party identity provider (using either OIDC or

SAML ) so that citizen users can use their assigned username and password to authenticate. Multi-factor authentication (MFA) will be provided by the third-party identity provider.

Identity Proofing (the process whereby a user with a third-party identity provider account verifies their actual legal identity with SCDHHS) can be performed a number of ways by a number of third-party entities, but must be completed before a system or application allows access to that user.

4.4.2 For SCDHHS Workforce Members

SCDHHS Workforce Members include staff, contractors, and others that are defined in the SCDHHS

Internal Directory, operating at the behest of SCDHHS. Workforce Members undergo Identity

Validation and Proofing compliant with current MARS-E & NIST standards. SCDHHS uses Remote

Supervised or In-Person methods of Identity Validation and Proofing for members prior to issuance of

MFA credentials. The SCDHHS Web Authentication service supports SAML 2 authentication and may support other methods that meet compliance requirements.

4.4.3 For Providers

SCDHHS is working to establish appropriate methods and guidance in support of MFA for Medical

Providers. SCDHHS requires that all application users use approved MFA methods. All applicable mandated compliance requirements must be achieved.

4.4.4 For All Other Users

SCDHHS requires that all application users use approved MFA methods. All applicable mandated compliance requirements must be achieved.

4.5 Data Protection and Encryption of Data

SCDHHS’ requirement is to meet or exceed all related Federal and State laws, regulations, and mandates regarding the appropriate level of data protection while in transit (using current versions of industry standards for security protocols like SSL, TLS and IPSec, etc.) and at rest (using industry standards including encryption, access controls, etc.) while using the current approved level(s) of encryption. Complete details relating to SSL/TLS are available in the Certificate and Encryption

8/26/2016 SCDHHS - Confidential Page 10 of 12

Standards document, TRA06.11 available at: EA - TRA06.11 – SSL/TLS Certificate and Encryption

Standards - Enterprise Architecture - SCDHHS Confluence (clemson.edu). The type of data must be appropriately assessed to ensure acceptable Federal and State data protection requirements are being met.

https://cuihhsiutl12.clemson.edu/pages/viewpage.action?pageId=147620836 https://cuihhsiutl12.clemson.edu/pages/viewpage.action?pageId=147620836

8/26/2016 SCDHHS - Confidential Page 11 of 12

5 APPENDICES

5.1 REVISION HISTORY

Version number

Date Author(s) Description of change

0.1 7/12/2016 Gerhard Ungerer Initial draft

0.2 9/27/2022 Sarel van der Westhuizen

David Lohnes

Updates to incorporate changes to the reference architecture pertaining to the

SCDHHS portal (removed from the reference architecture), the MES Core, interface standards, as well as identity, credentials and access management.

0.3 10/17/2022 Sarel van der Westhuizen Various updates and refinements based on internal reviews.

5.2 ACRONYMS

Acronym Description

COTS Commercial-off-the-shelf products

EDI Electronic data interchange

HIPAA Health Insurance Portability and Accountability Act

ICAM Identity, credentials and access management

MARS-E Minimum Acceptable Risk Standards for Exchanges

MFA Multifactor authentication

MITA Medicaid Information Technology Architecture

MMIS Medicaid Management Information System

NIST National Institute of Standards and Technology at the U.S. Department of Commerce

NoSQL Non-SQL. Structured Query Language (SQL)

ODS Operational data store

OIDC OpenID Connect: an identity protocol and open standard built using OAuth 2.0 protocol

PHI Protected health information

PII Personally identifiable information

SAML Security Assertion Markup Language

SCDHHS South Carolina Department of Health and Human Services

SOA Service-oriented architecture

TRA Technical Reference Architecture

8/26/2016 SCDHHS - Confidential Page 12 of 12