Interoperability Support at BCBSKS

This page provides third-party application developers with access to information and tools to connect with BCBSKS FHIR APIs, as required by the CMS Interoperability and Patient Access Rule (45 CFR §156.221). We are supporting API access for our active Qualified Health Plans (QHP) on the Federally Facilitated Exchange (FFE) and Medicare Advantage (MA) populations at this time.

New to BCBSKS APIs?

Follow our Quick Start Guide to register your app and begin integration testing with our FHIR APIs.

https://api-developer.secure.bcbsks.com/interop-quick-start

API Overview

BCBSKS supports the following APIs for CMS interoperability compliance:

Patient Access API - Access to member, clinical and claims data

• Sandbox: https://api.secure.bcbsks.com/bcbsks-sandbox/fhir-server/api/v4/

• Production: https://api.secure.bcbsks.com/bcbsks/fhir-server/api/v4/

Provider Directory API - Directory of in-network providers

• Sandbox: https://api.secure.bcbsks.com/bcbsks/fhir-prov-dir-sandbox/api/v4/

• Production: https://api.secure.bcbsks.com/bcbsks/fhir-prov-dir/api/v4/

Formulary API - Prescription drug coverage and cost-sharing information

• Sandbox: https://api.secure.bcbsks.com/bcbsks/fhir-prov-dir-sandbox/api/v4/InsurancePlan

• Production: https://api.secure.bcbsks.com/bcbsks/fhir-prov-dir/api/v4/InsurancePlan

For full documentation and a 'Try it now' feature refer to our APIs section.

Authorization

The Patient Access API uses SMART on FHIR, leveraging OAuth 2.0 and OpenID Connect (OIDC) to support secure, standards-based access.

• Sandbox Auth Endpoint:https://api.secure.bcbsks.com/smart-fhir-sandbox/api/authorize?aud=https://api.secure.bcbsks.com/smart-fhir-sandbox

• Sandbox Token Endpoint:https://api.secure.bcbsks.com/smart-fhir-sandbox/api/token

• Production Auth Endpoint:https://api.secure.bcbsks.com/smart-fhir/api/authorize?aud=https://api.secure.bcbsks.com/smart-fhir

• Production Token Endpoint:https://api.secure.bcbsks.com/smart-fhir/api/token

We provide additional public docs for our SMART on FHIR services to help developers understand and connect with BCBSKS APIs. The Provider Directory APIs are unique because they do not require a subscription or authorization because they provide publicly available content.

Sandbox:

• https://api.secure.bcbsks.com/smart-fhir-sandbox/api/metadata

• https://api.secure.bcbsks.com/smart-fhir-sandbox/api/.well-known/smart-configuration

Production:

• https://api.secure.bcbsks.com/smart-fhir/api/metadata

• https://api.secure.bcbsks.com/smart-fhir/api/.well-known/smart-configuration

Documentation and Implementation Guides

• SMART on FHIR

• Auth Code Flow with OIDC

• HL7 US Core

• CARIN Blue Button

• Da Vinci PDex

• Da Vinci Plan-Net

• Da Vinci Formulary

Privacy & Security Commitment

BCBSKS is committed to protecting member health data. Our implementation adheres to CMS and HIPAA standards, including:

• Encryption in transit and secure OAuth 2.0 authorization

• Access restricted to registered and approved applications

• Monitoring and risk mitigation practices

• Role-based access control

• Third-party compliance with privacy and breach notification rules

BCBSKS staffs a 24/7 security incident response team that reacts to perceived malicious activity targeting our APIs. We maintain a formal Computer Incident Response Team (CIRT) policy and follow defined event procedures for any attacks involving our Interoperability APIs. If a developer's API interactions are identified as the source of a security incident, their subscription may be flagged as “at risk.”

At-Risk Subscription Policy

Our goal is to identify dormant or risky registrations without negatively impacting applications that are actively maintained, even when usage volume is low.

Developer subscriptions may be flagged as at risk for the following reasons:

• Malicious activity: Examples include brute force attacks, credential stuffing, or password spraying.

• Inactivity: No successful SMART on FHIR authorization and no API usage for 60+ days, with no response to outreach. See the Keeping Your Subscription Active section below for recommended patterns to avoid unintended inactivity.

• Security breach notifications: Alerts from RiskRecon or internal security monitoring.

Inactivity Policy

If no activity is detected for two months, BCBSKS will follow the process below.

Keeping Your Subscription Active

Some applications experience seasonal or low volume member traffic. To avoid being flagged as inactive, your application should complete at least one successful SMART on FHIR authorization and one FHIR API call within every rolling 60 day period for each environment you want to keep active.

You can satisfy this requirement in either of the following ways

Member driven traffic

When real members sign in and complete the standard SMART on FHIR authorization flow, the resulting authorization and FHIR API activity counts as usage for the inactivity threshold

Automated health checks

If long gaps between member logins are expected, you may implement an automated health check that periodically completes the SMART on FHIR flow and calls a lightweight FHIR endpoint such as /metadata. This can be done using a synthetic Okta sign in pattern.

A health check pattern should:

• Use your registered client identifier and redirect URI.

• Authenticate through Okta using an account your organization manages solely for monitoring.

• Request only the minimum scopes required to complete the authorization code flow.

• Discard any returned FHIR data and use the result only to confirm connectivity and authorization.

A common approach is to schedule a synthetic Okta sign in and a lightweight API call every 30 days for each active environment. This helps keep your subscription clearly active and provides early warning if configuration, certificate, or connectivity changes disrupt your integration.

If you plan to implement automated health checks and have questions about account setup, scopes, or recommended endpoints, contact the BCBSKS interoperability support team using the contact information provided in this portal before enabling the pattern in production.

Security Best Practices for Developers

• Use HTTPS and TLS for all communication

• Store data securely; do not persist credentials locally

• Follow OWASP best practices:

  • OWASP Top 10 – Web Applications

  • OWASP Top 10 – Mobile Applications

If RiskRecon alerts BCBSKS to a breach, the impacted developer may be invited to collaborate on remediation. In any case of suspicious or confirmed malicious activity, BCBSKS reserves the right to initiate a CIRT response and suspend API access.

By registering an app and using our APIs, you agree to uphold the security and privacy of BCBSKS members.

For additional details, please visit our official Developer API Policy page.

Developer Support

Need help? Email interop.support@bcbsks.com
Support hours: Monday–Friday, 8am–5pm CST