This capability statement describes the use cases that are supported by the BC FHIR implementation of the Client Registry when it is acting as a server.

• Find Candidates - used when a user would like to find a Patient, but without an identifier, typically with name, address or edge cases like mother's PHN.
• Get Demographics - used when a user would like to find a Patient and has an identifier that Client Registry recognizes.
• Revise Patient - used when a user is communicating a change or request for a new PHN to the Client Registry.
• Merge Patient - used when a user is communicating that an individual has multiple Patient records and which record should survive and which record(s) should be marked as non-surviving.
• Add Patient - used for newborns and 'force create' interactions

There are several versions of some of the above services. The Client Registry has created FHIR Operations for each of the above and their variations.

• $FindCandidates
• $GetDemographics
• $AddPatient
• $AddPatient.Async
• $RevisePatient
• $RevisePatient.Async
• $UpdatePatient
• $UpdatePatient.Async
• $MergePatient
• $MergePatient.Async

RESTful interactions of any type, beyond the Operations listed above, are not supported. Client Registry users SHALL use only the above FHIR Operations.

General Rules IN

There are several rules that apply to all interactions with the Client Registry:

• When adding a newborn or using 'force create' Client Registry users SHALL use the$AddPatient FHIR Operation. This is different from V3, where the user can use Revise to create or update a record in there scenarios.
• The Client Registry FHIR implementation only supports JSON format and the clients SHALL use JSON for all interactions. The MIME-type of application/fhir+json is the only one supported by the Client Registry.
• All interactions with Patient resources SHALL use one of the following profiles: ClientRegistryPatient or PatientUpdate.
• Any Parameters' profiles used SHALL be MetadataParametersIn or MetadataParametersOut.
• Only the 'resource type' FHIR Operation is supported by the Client Registry, e.g. "/Patient/$[Operation Name]"; not system "/$[Operation Name]" and not resource instance "/Patient/[id]/$[Operation Name]". Requesting users SHALL use only the resource type of FHIR Operation.
• All of the profiles include elements that are marked as Must Support. For the purposes of this guide, Must Support is intended to represent those fields that will be exchanged between client applications and the Client Registry server. Client applications who are receiving information SHALL be able to receive all fields marked as Must Support without raising an exception. When sending information to the Client Registry server, client applications SHOULD be able to send any fields marked as Must Support.
• The FHIR asynchronous pattern is not followed by this FHIR implementation. The existing pattern the Client Registry uses today will be mimicked. I.e.
  • User sends request
  • Client Registry responds with HTTP 202 Accepted
  • Later, the Client Registry sends request with information regarding the initial request to user's end point
  • User system responds with 202 Accepted
  Users SHALL follow the above asynchronous pattern when invoking an asynchronous version of a Operation.

General Rules OUT

Each Operation SHALL return a Bundle. The Bundles MAY be of type searchset or collection. The two searches, GetDemographics and FindCandidates SHALL return searchset bundles. The Add, Revise and Merge SHALL return collection Bundle resources. Each operation MAY use a unique Bundle profile in the response to enforce cardinalality rules.

In summary the response Bundles for every Operation SHALL be structured as follows:

• Entry of MetadataParametersOut
• If a search, the request Parameters are be echoed back in a MetadataParametersIn resource within the MetadataParametersOut resource
• One entry with OperationOutcome
• Zero or more entries of ClientRegistryPatient
• Zero or more entries of RelatedPerson

Data Absent Reason

If the Data Absent extension is present onn a Patient attribute, then History, for that attribute, SHALL not be returned. If data is absent it is primarly because the record is restricted and therefore returning History isn't permitted.

Error Handling

The Client Registry users SHALL monitor the HTTP response codes returned with a response. If the code is not 2xx the user SHALL examine the errors in the OperationOutcome resource in the response Bundle.

Search

Find Candidates

The FindCandidates FHIR Operation search SHALL use the following Bundles. This search MAY return zero or more Patients using the ClientRegistryPatient profile. Wildcards are not permitted.

Get Demographics

The GetDemographics FHIR Operation SHALL use the following Bundles. This search may return zero or one Patient using the Patient profile.

Revise Patient

The RevisePatient FHIR Operation SHALL use the following Bundles.

Add Patient

The AddPatient FHIR Operation SHALL use the following Bundles.

Update Patient

The UpdatePatient FHIR Operation SHALL use the following Bundles.

Merge Patient

The MergePatient FHIR Operation SHALL use the following Bundles.

The non-surviving Patient(s) SHALL be listed in the link attribute of Patient.