Patient Access API

The Patient Access API lets members use a third-party application of their choice to retrieve their own health data from a payer. The application authenticates the member with the payer's identity provider, receives an access token scoped to that member, and then reads the member's records from the payer's FHIR server.

Regulatory Context

The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) requires impacted payers to make member data available through a Patient Access API. The CMS Interoperability and Prior Authorization Final Rule CMS-0057-F adds prior authorization data to the API and requires payers to report Patient Access API usage metrics to CMS each year, including:

• The number of unique members whose data was transferred to a health app designated by the member.
• The number of unique members whose data was transferred more than once.

Usage Reporting

To produce these metrics, each Patient Access API request must be attributable to a member and to the application that made it. By default, the Smile CDR transaction log records the authenticated user, but not the member's Patient ID or the requesting application's client ID as they appear in the access token.

Smile CDR captures this information with standard product features:

• A dedicated FHIR endpoint serves Patient Access API traffic, so that its requests can be identified by module ID.
• A SMART on FHIR Inbound Security module validates access tokens issued by the payer's identity provider. Its onAuthenticateSuccess callback script copies the member and application claims into the user session.
• An interceptor on the FHIR endpoint adds those values to each transaction log event.
• A Transaction Log Broker module publishes only the Patient Access API events to a dedicated Kafka topic for downstream reporting.

See Usage Reporting for details.

Standards & Technology

The API is built on HL7 FHIR R4. Members authorize applications using SMART App Launch and OAuth 2.0.