Client Registry Implementation Guide
0.1.0 - ci-build
Client Registry Implementation Guide
0.1.0 - ci-build
Client Registry Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Registration of a new Client SHALL use the base FHIR Restful create interaction.
POST [base]/Patient
To read a Client record users SHALL invoke a deterministic read interaction using an identifier or id search token to find matching Clients.
For example:
GET [base]/Patient?identifier=http://example.com/fhir/identifier/mrn|123456
GET [base]/Patient?_id=123
GET [base]/Patient/123
This Restful request is a standard FHIR read and will return a Bundle of Patients with zero or more entries. It is possible that more than a single Patient is returned and this may indicate a problem with Client duplication or an error.
The POST version of read is not supported.
The vread interaction SHALL be supported for Patient Resources.
GET [base]/Patient/123/_history/3
This is roughly based on IHE mPDQ and is a FHIR search interaction. This interaction SHALL be used to search for Patients using search parameters.
This query may return more than a single Patient. For example, searching by address alone may return any of the individuals currently residing at that address. To minimize such situations the more parameters used in the search the more likely a definitive single match is found. A list of FHIR R4 search parameters available for Patient queries is here. This set is reduced to the following:
Improvement: 🔎 This is a proposed list, which will need to be refined during later design stages. It is based on the National eHealth Guidelines and Standards document.
| Parameter |
|---|
| active |
| address |
| gender |
| birthdate |
| family (name) |
| given (name) |
| name prefix |
| name suffix |
| telecom |
| photo |
| marital status |
🔎 Prefix, suffix, photo and marital status are not standard FHIR search parameters for Patient; the general 'name' parameter could replace family, given, suffix and prefix.
Improvement: 🔎 Specific combinations of search parameters will reduce the number of matches, ideally to 1. For example, phone number with address and name will tend to give few matches. These preferred combinations should be specified in the future as some experience with data quality would benefit this choice.
An example search,
GET [base]/Patient?address=123%20Main%20St&family=Perera&given=Lashith&gender=male
Given that the Patient to update has already been found, this is a standard FHIR Restful interaction that SHALL be used for updates. This function necessitates that CR users SHOULD search before using the Update interaction.
PUT [base]/Patient/123
With a body of Patient resource.
Update as create is not supported. This guide describes an operation that shall be used to only create Clients.
The merge interface is currently not in scope, the requirement is marked as Future. Some design is present in this guide for reference only.
This operation is based on the FHIR R5 merge operation. The guide specifies FHIR R4 and the interface to the R5 merge operation will be mimicked - same parameters in and out.
Assuming a duplicate Client record has been found this Operation SHALL be used to merge two records, one surviving and one not surviving. The surviving instance is updated, with any information from the non-survivor as required by requirements. The non-survivor instance is deactivated.
POST [base]/Patient/$merge
If users search (identifier, id or demographics, any search) and a non-surviving record is found, the survivor record SHALL be returned with a warning that a survivor record has been returned instead of a non-survivor.
This operation is a simple request to the Client Registry to link two Patient records and SHALL be used to link Clients. Using parameters a user can also request the Patient's links be broken.
POST [base]/Patient/$linkClients
FHIR does have a Patient.link element that may be used to link Patient records, with a 'seealso' type code. The link process for Sri Lanka allows users to create links between Patients and there are validation and confirmation routines that should be executed, as such, this requirement is more suited to an operation. As well the linking operation is considered a distinct and separate workflow from say updating demographics and designing as an operation reinforces this distinction. The Patient resource instances will not show which Patients are linked (not populate Patient.link), instead users are required to use the GetIdentifierList operation.
This roughly based on IHE mPIX.
This operation returns a list of FHIR Identifiers across source systems that are associated with an individual and SHALL be used for cross domain identifier searches.
POST [base]/Patient/$getIdentifierList
This operation is dependent on linking as described here and the merge operation. The Identifier list operation SHALL return all identifiers, even those that are related to non-survivor records. This is crucial as systems that may already have stored, say, a non-survivor PHN like the National Electronic Health Record repository, will have encounter Resources related to Patient records with non-surviving PHNs.