STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

Operation-patient-match

This is the narrative for the resource. See also the XML or JSON format.

Find patient matches using MPI based logic

OPERATION: Find patient matches using MPI based logic

A Master Patient Index (MPI ) is a service used to manage patient identification in a context where multiple patient databases exist. Healthcare applications and middleware use the MPI to match patients between the databases, and as new patient details are encountered. MPIs are highly specialized applications, often tailored extensively to the institution's particular mix of patients. MPIs can also be run on a regional and national basis.

To ask an MPI to match a patient, clients use the "mpi" query, which takes either a candidate patient resource, or a set of normal search parameters defined for patient. The data provided is interpreted as an MPI input and passed to an MPI algorithm of some kind that uses them to determine the most appropriate matches in the patient set.

Note that different MPI matching algorithms have different required inputs. The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but may implementations will have a set of minimum information, which may be declared in their definition of the $match operation

URL: [base]/Patient/$match

Parameters

UseNameCardinalityTypeBindingDocumentation
INpatient0..1Patient

Use this to provide an entire set of patient details for the MPI to match against (e.g. POST a patient record to Patient/$match). If a patient record is not provided, then one or more of the other parameters must be provided

INfamily0..1string

The family name for matching

INgiven0..1string

The given name for matching

INgender0..1string

The gender for matching

INbirthdate0..1string

The birth date of the patient for matching

INidentifier0..1string

An identifier to use for the matching

INtelecom0..1string

Some kind of telecom to use for the matching

INphone0..1string

A phone number to use for matching

INemail0..1string

An email address to use for matching

INpostcode0..1string

A postcode to use for matching

INuserid0..1string

This optional parameter is used to pass the user details from a trusted client to the MPI. This may be used by the MPI to restrict the possible matches that are returned, based on the user's rights. For example, a staff member covered by policies, etc., may well get a different result than a patient trying to find their own record. Note that this parameter is used where the user would not be expected to log in to the MPI directly; whether this is appropriate or not is a deployment choice.

INcount0..1integer

The maximum number of records to return. If no value is provided, the server decides how many matches to return. Note that clients should be careful when using this, as it may prevent probable - and valid - matches from being returned

OUTreturn1..1Bundle

A bundle contain a set of Patient records that represent possible matches

The response from an "mpi" query is a bundle containing patient records, ordered from most likely to least likely. If there are no patient matches, the MPI SHALL return an empty search set with no error, but may include an operation outcome with further advice regarding patient selection. All patient records SHALL have a search score from 0 to 1, where 1 is the most certain match, along with an extension "match-grade" that indicates the MPI's position on the match quality.

 

 

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.