Patient Access API
Patient resources
The Patient Access API supports search using certain data elements. See the table below for a detailed list of supported search parameters and links to implementation guides. We only support the resources mentioned here; wildcards are unsupported.
| Patient Resource | Search Parameter(s) Supported | Link to Implementation Guide |
| patient/Patient | id birthdate family gender given identifier name | HL7 US Core IG CARIN IG for Blue Button® |
| patient/Coverage | coverage_payor identifier | CARIN IG for Blue Button® |
| patient/ExplanationOfBenefit (Pharmacy, Inpatient, Outpatient, Professional) | id lastUpdated identifier patient type service_date | CARIN IG for Blue Button® |
| patient/Organization | - | CARIN IG for Blue Button® |
| patient/Practitioner | name identifier | HL7 US Core IG CARIN IG for Blue Button® |
| patient/Observation (Laboratory Results, Smoking Status, Vital Signs) | status category code date patient | HL7 US Core IG HL7 FHIR Da Vinci PDex IG |
| patient/Procedure | status patient date code | HL7 US Core IG HL7 FHIR Da Vinci PDex IG |
| patient/List | id profile identifier | HL7 FHIR Da Vinci – PDex US Drug Formulary IG |
| patient/MedicationKnowledge | profile DrugName DrugPlan* DrugTier code id | HL7 FHIR Da Vinci – PDex US Drug Formulary IG *DrugPlan is a custom search for BlueCross BlueShield of South Carolina. See documentation below. |
Custom search: DrugPlan
First, read coverage.identifier with patient.indentifier + 'MED'.
- If not found, no MedicationKnowledge data is available for this patient.
- If found:
- Obtain the Coverage.class.value that is associated with a Coverage.class.code of "Group"
- Read MedicationKnowledge.DrugPlan where DrugPlan equals the Coverage.class.value obtained above
Authorization code flow
The BlueCross BlueShield of South Carolina FHIR server supports Proof Key for Code Exchange (PKCE) and Client Credentials authorization flows. We recommend using PKCE for the authorization flow if your app supports it. PKCE provides an important security enhancement to applications by mitigating the risk of an authorization code being stolen by malicious applications installed on the device.
Authorization endpoint
The /authorize request is used to interact with the member for authorization to access their health care data. Refer to the table below for supported types and any limitations.
| Parameter | Description |
| response_type | Only code is supported. |
| response_mode | Only query is supported. |
| client_id | ID of the third party application. Provided upon application onboarding. |
| redirect_uri | Successful response from authorize endpoint will be redirected to this url. Must match the value provided in onboarding application. |
| code_challenge | Challenge for PKCE. The challenge is verified in the access token request. |
| code_challenge_method | Method to derive the code challenge for PKCE. Only S256 supported. |
Token endpoint
The token is used by applications to exchange authorization code for access token and refresh token. Only "authorization_code” and “refresh_token” grant_type are supported.
Error handling
HTTP status code will be returned from the endpoints if there are authorization or configuration failures.
Production endpoints
- SMART configuration
https://fhir.bcbssc.com/r4/patientaccess/.well-known/smart-configuration
- Capability statement
- https://fhir.bcbssc.com/r4/patientaccess/metadata
- Patient Access API
- https://fhir.bcbssc.com/r4/patientaccess
Developer sandbox endpoint
- Sandbox: SMART configuration
https://fhir.bcbssc.com/r4/sandbox/.well-known/smart-configuration
- Sandbox: Capability statement
- https://fhir.bcbssc.com/r4/sandbox/metadata
- Sandbox: Patient Access API
- https://fhir.bcbssc.com/r4/sandbox
Use these synthetic users to test your application workflow in sandbox environment:
| Name | Username | Password |
| User01 Sandbox | sandbox01 | P@ssw0rd123 |
| User02 Sandbox | sandbox02 | P@ssw0rd123 |
| User03 Sandbox | sandbox03 | P@ssw0rd123 |
The Patient Access API is based on the FHIR SMART app framework, and utilizes OAuth 2.0 specification and the OpenID Connect Core 1.0 standard for securing connections.