This page is part of the FHIR Specification (v3.3.0: R4 Ballot 2). 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

• Content
• Examples
• Detailed Descriptions
• Mappings
• Profiles & Extensions
• Operations
• R2 Conversions

8.1.1.1 Operation $match on Patient

Patient Administration Work Group

Maturity Level: 5

Normative

Compartments: N/A

Normative Candidate Note: This page is candidate normative content for R4 in the Patient Package. Once normative, it will lose it's Maturity Level, and breaking changes will no longer be made.

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 "$match" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and passed processed by an algorithm of some kind that uses the data 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 by specifying a profile on the resource parameter, indicating which properties are required in the search. The patient resource coming into the operation does not have to be complete, nor does it need to pass validation (i.e. Mandatory fields don't need to be populated), but it does have to be a valid instance. This is due to the resource being used for reference data to match from, and not being stored.

The official URL for this operation definition is

 http://hl7.org/fhir/OperationDefinition/Patient-match

Formal Definition (as a OperationDefinition).

URL: [base]/Patient/$match

This is an idempotent operation

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.

8.1.1.1.1 Examples

Patient match using patient resource: (Request):

POST /open/Patient/$match
[some headers]

{
  "resourceType": "Parameters",
  "id": "example",
  "parameter": [
    {
      "name": "resource",
      "resource": {
        "resourceType": "Patient",
        "identifier": [
          {
            "use": "usual",
            "type": {
              "coding": [
                {
                  "system": "http://hl7.org/fhir/v2/0203",
                  "code": "MR"
                }
              ]
            },
            "system": "urn:oid:1.2.36.146.595.217.0.1",
            "value": "12345"
          }
        ],
        "name": [
          {
            "family": [
              "Chalmers"
            ],
            "given": [
              "Peter"
            ]
          }
        ],
        "gender": "male",
        "birthDate": "1974-12-25"
      }
    },
    {
      "name": "count",
      "valueInteger": "3"
    },
    {
      "name": "onlyCertainMatches",
      "valueBoolean": "false"
    }
  ]
}

Results from imaginary MPI algorithm (Response):

HTTP/1.1 200 OK
[other headers]

{
  "resourceType": "Bundle",
  "id": "26419249-18b3-45de-b10e-dca0b2e72b",
  "meta": {
    "lastUpdated": "2016-03-18T03:28:49Z"
  },
  "type": "searchset",
  "total": 2,
  "entry": [{
    "fullUrl": "http://server/path/Patient/example",
    "resource": {
      "resourceType": "Patient",
      "id": "example",
      .. snip ...
    },
    "search": {
      "extension": [{
        "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
        "valueCode": "certain"
      }],
      "mode": "match",
      "score": 0.9
    }
  },{
    "fullUrl": "http://server/path/Patient/292",
    "resource": {
      "resourceType": "Patient",
      "id": "292",
      .. snip ...
    },
    "search": {
      "extension": [{
        "url": "http://hl7.org/fhir/StructureDefinition/match-grade",
        "valueCode": "possible"
      }],
      "mode": "match",
      "score": 0.2
    }
  }]
}

For more information about operations, including how they are invoked, see Operations.