Capability Statement

This Capability Statement summarizes the capabilities of the Longitudinal Record Access (LRA) Server. The LRA Server supports secure, standardized data exchange using FHIR-based RESTful interactions, operation-based access patterns, message-based submission, and retrieval of persisted source-system data.

The capabilities documented on this page vary by integration and use case. Some integrations expose RESTful search and read behaviour, while others use FHIR operations, FHIR messaging, or retrieval patterns based on reverse-includes.

The LRA Server:

• Supports RESTful and operation-based access patterns depending on the integration and use case.
• Implements RESTful behaviour according to the FHIR specification where RESTful interactions are supported.
• Follows the requirements documented in the Conformance Requirements.
• Supports FHIR JSON and XML formats for LRA interactions.
• Supports Turtle where advertised by the server.
• Supports message processing through the $process-message operation for notification workflows.

The table below summarizes the resource and profile capabilities supported by the LRA Server:

Capabilities by Resource

Integration / Use Case	Resource Type	Supported Interactions	Supported Searches	Supported _includes	Supported _revincludes	Supported Operations
Provincial Client Registry	Patient	search-type, read, create, update	identifier, family, given, address-city, address-country, address-line, address-postalcode, address-state, birthdate, death-date, email, gender, phone, _has. Supported search combinations include: family + given + birthdate family + given + address-line family + given + address-postalcode family + given + phone Optional additional parameters may include gender, address-city, address-country, and email.	-	-	$match, $merge
Coverage / MSP Eligibility	CoverageEligibilityResponse	search-type	patient.identifier, serviced-date	CoverageEligibilityResponse:patient:Patient	-	-
Coverage / MSP Eligibility using Client Registry Patient	Patient	search-type	identifier, _has	-	CoverageEligibilityResponse:patient	-
Provider and Location Registry	Practitioner	Operation-based query	Operation parameters include identifier, family, given, role, language, expertise, gender, status, status-reason, birthdate, address-city, address-country, and withHistory. Wildcard searches are supported for family and given names. Supported search criteria include: SHALL support searching by identifier. SHALL support searching using family + given and at least one of: birthdate, status, status-reason, address-city, address-country, gender, language, or expertise. SHOULD support searching using family + given + address-city. SHOULD support searching using family + given + gender. SHOULD support searching using family + given and any combination of status, status-reason, language, or expertise.	-	-	$entityQuery
Provider and Location Registry	Location	Operation-based query	Operation parameters include identifier, name, address-line1, address-city, healthAuthority, healthServiceDeliveryArea, localHealthArea, and communityHealthServiceArea.	-	-	$entityQuery
Provider and Location Registry	Organization	Operation-based query	Operation parameters include identifier, name, type, address-line1, and address-city. Wildcard searches are supported for name.	-	-	$entityQuery
Panorama Immunization Registry	Patient	search-type	identifier, _tag, _has	-	Immunization:patient ImmunizationRecommendation:patient AdverseEvent:subject MedicationRequest:subject RiskAssessment:subject CarePlan:subject Consent:patient	-
Panorama Immunization Registry	ImmunizationRecommendation	search-type	_lastUpdated, _tag Also returned using Patient search with _revinclude=ImmunizationRecommendation:patient.	-	-	-
LRA Notification Request Service	Bundle. For the BC Cancer notification use case, this includes LRA Notification MessageHeader, CommunicationRequest, DocumentReference, and Patient.	Message submission	-	-	-	$process-message

Additional Notes:

• The capabilities listed in this table are integration-specific. Support for a resource or interaction in one integration does not imply the same capability is available for all LRA integrations.
• A dash (-) indicates that the capability is not applicable to the integration pattern.
• The LRA Server implements SMART on FHIR security, supporting OAuth 2.0-based authorization where applicable. Token, introspection, and revocation endpoints may be available depending on the deployment and environment configuration.
• Supported formats for LRA interactions include application/fhir+json and application/fhir+xml
• The $process-message operation is supported by the LRA server, enabling the handling of FHIR messaging scenarios, which is essential for event-based communications like coverage eligibility requests or notification services.