Breast Screening NZ FHIR Implementation Guide
1.1.4 - Release

Breast Screening NZ FHIR Implementation Guide - Local Development build (v1.1.4) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Compliance Tests

Ref Test Category Expectation Mandatory? Evidence Required
BCC-01 Authentication & Credentials The application securely authenticates with the API using issued credentials (e.g. client ID, secret, tokens). Credentials must not be hardcoded or exposed, and all requests must be authenticated. Mandatory
  • Screenshots/config showing secure credential storage (sanitised)
  • Logs demonstrating successful authenticated calls
BCC-02 User Identity Propagation Every API request includes a valid, unique identifier representing the end user (e.g. HPI, user ID). The identity must reflect the actual logged-in user, not a shared/system account. Mandatory
  • Request samples showing user identifier
  • Logs linking requests to specific users
  • Description of how user identity is sourced
BCC-03 User Context Switching The application correctly updates the user identity in API requests when different users access the system. No reuse of a previous user's context. Mandatory
  • Test with at least two users
  • Logs/screenshots showing different user IDs in requests
  • Evidence of session/user switching
BCC-04 Role-Based Access Control (RBAC) Access to API functionality and data is restricted based on user roles. Users can only perform actions and view data appropriate to their role. Mandatory
  • Role definitions/configuration
  • Test cases showing permitted vs restricted actions
  • Screenshots/logs demonstrating enforcement
BCC-05 Audit & Traceability Each API interaction is traceable end-to-end using unique identifiers (e.g. correlation ID). The system must support auditing of who did what and when. Mandatory
  • Request/response headers with correlation IDs
  • Logs showing traceability across components
  • Example of tracing a single transaction
BCC-06 Error Handling (API Resilience) The application handles API errors gracefully (e.g. validation errors, timeouts, 4xx/5xx responses). Users receive meaningful messages, and the system avoids crashes or data corruption. Mandatory
  • Screenshots showing user-facing error messages
  • Logs capturing API errors
  • Evidence of retry or fallback behaviour (if applicable)
BCC-07 Input & Output Handling The application correctly captures user input, constructs valid API requests, and accurately displays API responses. Data must not be truncated, misrepresented, or lost. Mandatory
  • UI screenshots showing input and output
  • Sample request/response payloads
  • Evidence of correct data mapping
BCC-08 Test Execution Evidence The vendor provides a complete and structured set of test results covering all required scenarios. Evidence must be clear, reproducible, and time-stamped. Mandatory
  • Test report covering all scenarios
  • Timestamps on all evidence
  • Clear mapping between test cases and results
BCC-09 Use of Test Data Only approved test data is used during compliance testing. No production or real patient data is used in non-production environments. Mandatory
  • List of test identifiers used (e.g. NHI test IDs)
  • Sample payloads showing test data
  • Confirmation statement from vendor
BCC-10 Terms of Use / Legal Compliance The application presents applicable terms of use and captures user acceptance where required. Use of the API complies with legal and policy requirements. Mandatory
  • Screenshot of terms presented in UI
  • Evidence of acceptance capture (e.g. checkbox, audit record)
  • Description of how acceptance is stored
BCC-11 Security Controls The application implements appropriate security controls, including secure transport (HTTPS), protection of credentials, and prevention of unauthorised access. Sensitive data is handled appropriately. Mandatory
  • Architecture or design summary (security controls)
  • Evidence of HTTPS usage
  • Description of credential handling and access controls
BCC-12 Data Validation The application validates key identifiers and required fields before sending requests to the API. This includes format validation (e.g. identifier structure), mandatory fields, and basic business rules. Invalid data should be prevented from being submitted or clearly flagged to the user. Mandatory
  • Screenshots or video showing validation in the UI (e.g. invalid identifier rejected)
  • Sample request payloads (valid vs invalid)
  • Logs showing rejected submissions
BCC-13 Rate Limiting Behaviour The application detects and appropriately responds to API rate limiting (e.g. HTTP 429). It should implement backoff/retry strategies and avoid overwhelming the API.
  • Logs showing handling of 429 responses
  • Evidence of retry/backoff logic (e.g. increasing delay)
  • Description of retry strategy (config or design excerpt)
BCC-14 Logging & Monitoring The application logs key events required for audit, troubleshooting, and monitoring. This includes request/response activity, errors, and user actions, while ensuring sensitive data is handled appropriately.
  • Sample log extracts (sanitised if needed)
  • Description of what is logged (e.g. request ID, user ID, timestamp)
  • Evidence logs can be used to trace a transaction end-to-end
BCC-15 Data Integrity Systems consuming Diagnostic Report information via the API must ensure that content cannot be edited by end users. Mandatory
  • Evidence to show Diagnostic Report content is displayed as view only
BCC-16 Data Integrity Systems consuming the API must ensure the integrity and accuracy of the information displayed to end users. Mandatory
  • Evidence to show data returned from the API for a Diagnostic Report is the data shown to end users
BCC-17 End User Notifications Where a draft report is returned then the rendered report document must clearly identify the report as being in a draft state. Mandatory
  • Evidence to show that when a draft report is opened it is clear for users they are looking at a draft, e.g. a draft watermark is applied
BCC-18 End User Notifications Diagnostic reports returned must clearly display the status of the report. Mandatory
  • Evidence to show that when a report is displayed for selection by a user the report status is clearly defined