FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

Example OperationDefinition/Patient-match (Narrative)

Patient Administration Work GroupMaturity Level: N/AStandards Status: InformativeCompartments: Patient, Practitioner, RelatedPerson

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

Note that this is the formal definition for the match operation as an OperationDefinition on Patient. See the Operation documentation

Generated Narrative: OperationDefinition Patient-match

URL: [base]/Patient/$match

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
IN resource 1..1 Resource

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).

IN onlySingleMatch 0..1 boolean

If there are multiple potential matches, the server should identify the single most appropriate match that should be used with future interactions with the server (for example, as part of a subsequent create interaction).

IN onlyCertainMatches 0..1 boolean

If there are multiple potential matches, the server should be certain that each of the records are for the same patients. This could happen if the records are duplicates, are the same person for the purpose of data segregation, or other reasons. When false, the server may return multiple results with each result graded accordingly.

IN count 0..1 integer

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

OUT return 1..1 Bundle

The bundle type is "searchset"

A bundle contain a set of Patient records that represent possible matches, optionally it may also contain an OperationOutcome with further information about the search results (such as warnings or information messages, such as a count of records that were close but eliminated) If the operation was unsuccessful, then an OperationOutcome may be returned along with a BadRequest status Code (e.g. security issue, or insufficient properties in patient fragment - check against profile)

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 "http://hl7.org/fhir/StructureDefinition/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.