This tutorial verifies that a Patient Access API request is published to Kafka with the member and application values, and optionally recorded in the CMS trace repository. It assumes the modules described in the How-to Guides are running.

1. Obtain an Access Token

Sign in to the payer's IdP as a test member through a registered test application, using the SMART App Launch authorization code flow. Decode the access token and confirm that it contains the claims the callback script reads:

{
  "iss": "https://idp.example.com/realms/patient-access",
  "sub": "d749550c-2f63-4c5a-9bf2-696b3af9d328",
  "azp": "example-health-app",
  "patient": "patient-005",
  "scope": "openid patient/*.read"
}

2. Call the Patient Access API

Read the member's Patient resource from the Patient Access API endpoint:

GET https://example.com/patient-access-fhir/Patient/patient-005

Headers:
Authorization: Bearer <access_token>
Accept: application/fhir+json

The server returns 200 OK with the Patient resource. A request for another member's Patient resource returns 403 Forbidden.

3. Read the Event from Kafka

Read the most recent message from the Patient Access API topic, for example with the Kafka console consumer:

kafka-console-consumer.sh --bootstrap-server <broker> \
  --topic channel_patient_access_txlog --from-beginning

Notes:

The message contains "endpointModuleId": "http_patient_access" and an additionalJson object with the patient_id, client_id, and subject values from the token. See Usage Event Format.
If additionalJson is missing, check the Smile CDR log for warnings from the callback script or the interceptor, and confirm the interceptor is registered on the Patient Access API endpoint.
If no message arrives, confirm that the event_whitelist module ID matches the endpoint's module ID.

4. Find the Communication in the Trace Repository

If you record usage in the trace repository, search the trace endpoint for the member's Patient Access API traces, as a user with read access to Communication:

GET https://example.com/trace-fhir/Communication?_tag=https://smiledigitalhealth.com/communication/category|patientaccess&identifier=https://smiledigitalhealth.com/communication/patientid|patient-005

Notes:

The search returns a Communication with the patient_id, subject, and client_id values as identifiers. See Usage Communication Format.
If the Communication is tagged error, its note holds the error raised by the transformer.
If no Communication is found, set the ca.cdr.camel.txlog logger to DEBUG and check the Smile CDR log for errors from the Camel route. See Troubleshooting.