Patient Access API usage reports count members and applications over a reporting period. Each Patient Access API request produces one FHIR_REQUEST transaction log event, which carries the data needed to build these counts.

Data Captured per Request

Data Point	Transaction Log Field	Source
Request date and time	`initialTimestamp`	Recorded by Smile CDR for every event.
Patient Access API request	`endpointModuleId`	The module ID of the dedicated Patient Access API FHIR endpoint.
Request type and outcome	`subType`, `outcome`	Recorded by Smile CDR for every event (for example, `FHIR_READ` and `SUCCESS`).
Member Patient ID	`additionalJson.patient_id`	The `patient` claim of the access token.
Requesting application	`additionalJson.client_id`	The client ID claim of the access token (`client_id`, or `azp` for IdPs such as Keycloak).
Member user identifier	`additionalJson.subject`	The `sub` claim of the access token.

The additionalJson values are added by an interceptor and depend on the claims your IdP includes in its access tokens. See Usage Event Format for a complete event.

Building the Metrics

A reporting consumer can derive the CMS metrics from the events for a reporting period:

Unique members whose data was transferred – Count distinct patient_id values across successful events.
Unique members whose data was transferred more than once – Count distinct patient_id values with more than one transfer. Smile CDR does not define what counts as a separate transfer; for example, you might count requests made on different days.
Requests per application – Group events by client_id for operational reporting.

Limitations

Contract identifiers are not captured. CMS metrics may need to be reported per contract or plan. The transaction log records the member's Patient ID only, so the reporting consumer must correlate each Patient ID with the member's contract using the payer's enrollment data.
Multiple Patient IDs per member. If a member has more than one Patient resource, counts based on patient_id may count that member more than once. Use the IdP's sub value or an enterprise member identifier to deduplicate where needed.
Requests without a session. Requests that fail authentication have no user session, so their events carry no additionalJson values.

Actors, Roles & Data Flow Security