Operation-patient-match.xml

Operation Definition

<OperationDefinition xmlns="http://hl7.org/fhir">
  <id value="Patient-match"/> 
  <text> 
    <status value="generated"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">
      <h2> Find patient matches using MPI based logic</h2> 
      <p> OPERATION: Find patient matches using MPI based logic</p> 
      <p> The official URL for this operation definition is: </p> 
      <pre> http://hl7.org/fhir/OperationDefinition/Patient-match</pre> 
      <div> 
        <p> A Master Patient Index (
          <a href="http://en.wikipedia.org/wiki/Enterprise_master_patient_index">MPI</a>  ) 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.\n\nTo ask an MPI to match a patient,
           clients use the \&quot;$match\&quot; 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. \n\nNote 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.\n\nThe
           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.
        </p> 

      </div> 
      <p> URL: [base]/Patient/$match</p> 
      <p> Parameters</p> 
      <table class="grid">
        <tr> 
          <td> 
            <b> Use</b> 
          </td> 
          <td> 
            <b> Name</b> 
          </td> 
          <td> 
            <b> Cardinality</b> 
          </td> 
          <td> 
            <b> Type</b> 
          </td> 
          <td> 
            <b> Binding</b> 
          </td> 
          <td> 
            <b> Documentation</b> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> resource</td> 
          <td> 1..1</td> 
          <td> Resource</td> 
          <td/>  
          <td> 
            <div> 
              <p> 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</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> onlyCertainMatches</td> 
          <td> 0..1</td> 
          <td> boolean</td> 
          <td/>  
          <td> 
            <div> 
              <p> If there are multiple potential matches, then the match should not return the results
                 with this flag set to true.</p> 

              <p> When false, the server may return multiple results with each result graded accordingly.</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> IN</td> 
          <td> count</td> 
          <td> 0..1</td> 
          <td> integer</td> 
          <td/>  
          <td> 
            <div> 
              <p> 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</p> 

            </div> 
          </td> 
        </tr> 
        <tr> 
          <td> OUT</td> 
          <td> return</td> 
          <td> 1..1</td> 
          <td> Bundle</td> 
          <td/>  
          <td> 
            <div> 
              <p> 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)</p> 

              <p> 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)</p> 

            </div> 
          </td> 
        </tr> 
      </table> 
      <div> 
        <p> The response from an &quot;mpi&quot; 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 &quot;
          <a href="extension-match-grade.html">match-grade</a> &quot; that indicates the MPI's position on the match quality.
        </p> 

      </div> 
    </div> 
  </text> 
  <url value="http://hl7.org/fhir/OperationDefinition/Patient-match"/> 
  <name value="Find patient matches using MPI based logic"/> 
  <status value="draft"/> 
  <kind value="operation"/> 
  <date value="2019-10-24T11:53:00+11:00"/> 
  <publisher value="HL7 (FHIR Project)"/> 
  <contact> 
    <telecom> 
      <system value="url"/> 
      <value value="http://hl7.org/fhir"/> 
    </telecom> 
    <telecom> 
      <system value="email"/> 
      <value value="fhir@lists.hl7.org"/> 
    </telecom> 
  </contact> 
  <description value="A Master Patient Index ([MPI](http://en.wikipedia.org/wiki/Enterprise_master_patient_index)
   ) 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.\n\nTo ask an MPI to match a patient,
   clients use the \&quot;$match\&quot; 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. \n\nNote 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.\n\nThe
   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."/> 
  <code value="match"/> 
  <comment value="The response from an &quot;mpi&quot; 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 &quot;[match-grade](extension-match-grade
  .html)&quot; that indicates the MPI's position on the match quality."/> 
  <resource value="Patient"/> 
  <system value="false"/> 
  <type value="true"/> 
  <instance value="false"/> 
  <parameter> 
    <name value="resource"/> 
    <use value="in"/> 
    <min value="1"/> 
    <max value="1"/> 
    <documentation value="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"/> 
    <type value="Resource"/> 
  </parameter> 
  <parameter> 
    <name value="onlyCertainMatches"/> 
    <use value="in"/> 
    <min value="0"/> 
    <max value="1"/> 
    <documentation value="If there are multiple potential matches, then the match should not return the results
     with this flag set to true.

When false, the server may return multiple results with each result graded accordingly."/> 
    <type value="boolean"/> 
  </parameter> 
  <parameter> 
    <name value="count"/> 
    <use value="in"/> 
    <min value="0"/> 
    <max value="1"/> 
    <documentation value="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"/> 
    <type value="integer"/> 
  </parameter> 
  <parameter> 
    <name value="return"/> 
    <use value="out"/> 
    <min value="1"/> 
    <max value="1"/> 
    <documentation value="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)"/> 
    <type value="Bundle"/> 
  </parameter> 
</OperationDefinition>