Patient Access API Access Guide
Patient Access API is a secured and public-facing API needed to meet CMS interoperability requirements and is built according to the Implementation guides. Authentication is required for any user to use the API.
Clinical Data: US Core FHIR R4 Implementation Guide 3.1.1, FHIR Version 4.0.1.
Claims & EOB Data: FHIR Version 4.0.1.
This API allows you to help customers by making information about patients easily accessible. It encourages consistency around how data access is accomplished between healthcare systems within and across organizations. This API also encourages consistency around what data is accessed and consistency around security standards.
By utilizing an approved Patient Access API applications, providers and customers are enabled to do the following:
- Use search parameters to filter practitioners by specialty, role and/or location
- Use search parameters to filter patient data by name, ID, address, gender
- Lookup patient medications, immunizations, diagnostic reports, conditions
- Find patients by type of observation (smoking status, vital signs, lab results, BMI for Age, height and weight)
- Lookup patients by location, encounter or procedures during hospitalization
- Retrieve patient’s claims & encounter data
Registration
To gain access to third party applications, and request third party application client credentials, first need to create account using http:
Part of the third-party application registration process includes requesting client credentials. The OAuth2 Authorization Server provides necessary details for establishing secure communication with the third-party application.
Environment
The FHIR base server URL for the live response production environment is: https://hdsworkspacedmzprodwus2-healthcomp.fhir.azurehealthcareapis.com
The live response production environment capability statement is available here: https://hdsworkspacedmzprodwus2-healthcomp.fhir.azurehealthcareapis.com/metadata.
The demo capability statement is available here: https://hdsworkspacedmzprodwus2-healthcomp.fhir.azurehealthcareapis.com/metadata.
https://login.microsoftonline.com/0b562f07-6404-4ceb-beb5-ee7b0bc57a02
grant_type: client_credentials
client_id: 890867d8-77e1-4875-8050-2aef95d97b85
client_secret: R-F8Q~x5gXvH5vci6-tjLBWqrVhGxBmjFa~GEcpl
resource: https://hdsworkspacedmzprodwus2-healthcomp.fhir.azurehealthcareapis.com
Our FHIR RESTful capabilities include:
- Support the US Core resource profiles – conformance expectation SHALL.
- Support the FHIR V4 Claim & EOB resource profiles – conformance expectation SHALL.
- Implement the RESTful behavior according to the FHIR specification.
- For all the supported search interactions in this guide, support the GET based search only.
- Return the following response classes (at a minimum):
- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scopes
- (Status 404): unknown resource
- Support JSON source formats for all US Core & FHIR V4
- Support the search parameters on each profile individually and in combination – conformance expectation SHALL.
Third party applications must be pre-registered. After account creation, the API will be walked through registering their application organization.
Cigna API requests often make use of patient-specific information which could be exploited by malicious actors resulting in exposure of patient data. For this reason, all Cigna patient access transactions must be secured appropriately, and directed by regulations, with access limited to authorized individuals, data protected in transit, and appropriate audit measures taken. Developers of third-party applications SHOULD be aware of these security considerations associated with FHIR transactions, particularly those related to:
API requests often make use of patient-specific information which could be exploited by malicious actors resulting in exposure of patient data. For this reason, all patient access transactions must be secured appropriately, and directed by regulations, with access limited to authorized individuals, data protected in transit, and appropriate audit measures taken. Third-party applications SHOULD be aware of these security considerations associated with FHIR transactions, particularly those related to:
- Communications
- Authentication
- Authorization/Access Control
- Audit Logging
- Digital Signatures
- Security Labels
- Narrative