Welcome to the Interoperability Resources page for Montana’s Medicaid Enterprise Systems (MES) Platform! This Developer Documentation will provide the specific context and implementation details for you and your organization to successfully access and use the Montana State Medicaid Interoperability Application Programming Interfaces (APIs), which are based on the Health Level 7® (HL7) Fast Healthcare Interoperability Resources (FHIR®) 4.0.1 standards.

This documentation will:

• Describe the intended purpose of each Interoperability API
• Describe how your organization can contact and register with Montana State Medicaid
• Describe relevant HL7 FHIR implementation guides (IGs) and applicable deviations within the Montana State Medicaid implementation
• Provide endpoints and necessary connectivity details for the Production environment

The purpose of publishing developer documentation is to promote interoperable and secure health data exchange with greater accessibility, particularly for third-party developers building patient-facing or health-related applications.

The Centers for Medicare & Medicaid (CMS) released the “Interoperability and Patient Access Final Rule” (CMS-9115-F) in May 2020 and the “Interoperability and Prior Authorization Final Rule” (CMS-0057-F) in January 2024. Both Final Rules require impacted payers to implement a set of HL7 FHIR-based APIs for pre-defined use cases to standardize data access and exchange for patients, providers, and payers, including:

• Patient Access API: Give patients control of their health data (claims and clinical) through the use of patient-authorized third-party apps.
• Drug Formulary API: Publish a payer’s preferred drug list to more easily determine which drugs are covered by various payers through a third-party app.
• Provider Directory API: Publish a payer’s in-network provider directory to allow members to more easily find in-network providers for various payers through a third-party app.
• Provider Access API: Make a patient’s health data (claims and clinical) readily accessible to providers for the purposes of treatment.
• Payer-to-Payer API: Make a patient’s health data (claims and clinical) readily accessible to payers to support a patient’s movement between health plans.
• Prior Authorization APIs: Support electronic exchange of prior authorization requirements, clinical documentation, and determinations.

These APIs are collectively referred to as the Interoperability APIs; current platform support and applicable configuration for each API are outlined within the specific tiles below (which will be introduced on this page as each Interoperability API is implemented).

Each Interoperability API is built on the HL7 FHIR R4 standard and follows specific Implementation Guides (IGs) as explicitly defined in the relevant “Getting Started” section. For the purposes of conciseness, this documentation will not reiterate the expectations of the industry standards, but it will call out any minor deviations from the stated standard and other information deemed particularly useful to share with developers.

HL7 FHIR requests follow standard REST operations and HL7 FHIR orchestrations, including an asynchronous orchestration for the Provider Access and Payer-to-Payer APIs, which follow the HL7 FHIR Bulk Data Access IG. Each Interoperability API section below specifies which specific REST operations and FHIR operations are supported, as well as the specific endpoint. For example, an API may support GET requests to retrieve a specific resource, search for a specific set of resources, or execute a specific pre-defined operation:

GET [baseUrl]/[Resource-type]/[id]
GET [baseUrl]/[Resource-type]?[searchParameters]

Unless stated otherwise in the sections below, each Interoperability API supports all required search parameters defined in the base HL7 FHIR R4 and the relevant IGs. To confirm specific support, implementers can also query for the latest CapabilityStatement for each Interoperability API (as explained in the How to Connect section below). When executing a synchronous search, responses are shared in a Bundle which our solution limits to a maximum of 100 resources. Implementers should be prepared to use the pagination feature (i.e., _count) to collect the full set of data if the search response exceeds 100 resources.

The Interoperability APIs will follow the standard REST convention for HTTP response codes with an OperationOutcome message included for relevant errors:

The FHIR resources shared via the Interoperability APIs may use terminology code systems that resolve to this Developer Documentation page for certain Montana Medicaid-specific values (e.g., Montana Medicaid member identifiers, unique claim identifiers. These code systems support a FHIR-standardized implementation of referencing Montana Medicaid as the originating source of the information, and the code system URI serves as a stable reference for implementers seeking to understand the intended use and meaning of each identifier.

For details related to our Interoperability API configurations, developers can reference the documentation below.

Provider Directory API

View the Provider Directory API developer documentation, including endpoint details and integration guidance.

GO

Patient Access API

View the Patient Access API developer documentation, including endpoint details and integration guidance.

GO

Drug Formulary API

View the Drug Formulary API developer documentation, including endpoint details and integration guidance.

GO

For questions or additional information on any of the Montana MES Interoperability APIs, please contact us here: hhsmpathsiinterop@mt.gov