Practitioner

  • *No FAST Identity specific profiles required*
  • No $match operation, search covers most scenarios
  • Use cases
  • Provider search
    • Names
    • Practicing locations -> PractitionerRole
    • Partial/Contains for string fields (like last name)
  • Care team discovery: Member of the care team, Dr. A, wants to update a care plan managed by another provider within the care team, e.g. the PCP Dr. B
    • Working session with Security focused on Care team discovery - Diana Ciricean to coordinate
      • Do you have to prove who is asking and also who they are affiliated with in order to be authorized to update a care plan? For e.g. what if they used to be part of the care team on behalf of Mayo clinic and then switched employers later?


Patient

  • $match operation

In Parameters:






Name

Cardinality

Type

Binding

Profile

Documentation

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

onlyCertainMatches

0..1

boolean



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.

Recommendations to ONC/CMS:

  • Industry derived consensus based metrics for matching - transparency and clarity in how these are calculated
  • How are multiple matches ranked? Are scores the best way to rank them?
  • Should there be a national reference database that reflects the population of the nation as a whole, with regional variations accounted for, that matching services can use to demonstrate their ability to meet these metrics?
  • Data Quality metrics should also be considered in addition to matching algorithm metrics

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 Parameters:






Name

Cardinality

Type

Binding

Profile

Documentation

return

1..1

Bundle



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)

Note: as this is the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource


  • Patient Profile for Matching

    • Patient resource must have at least one "name" attribute with at least one attribute within the name, preferably "family" aka last name
      • Catherine to look at stats for population with just a single name
    • USCDI profile for telecom (phone and email)
    • In the case of multiple births, we strongly recommend using the multipleBirth[x] attribute
    • contact
      • useful in cases where we may need an adult's information to identity proof and/or match a newborn/infant/minor
      • contact type value set needs to be expanded to specify more granular relationships like mother/parent instead of "next of kin"
    • communication - Not useful for matching, USCDI patient demo attribute
    • generalPractitioner
      • could be Practitioner/Organization name and/or identifier(s).
      • Useful when present, however, this data could be sensitive for e.g. in cases where a patient may list a specialist as their PCP. 
      • Propose changing the name of this attribute to "provider" instead of GP to allow for the use of specialists.
    • Attributes that could be of value in the future 
      • "photo"
        • <internal notes> This could be a really useful attribute in the future, when systems are capable of handling it across organizations and standards/specs associated with images are available. Use cases that could benefit greatly include manual verification/validation of populations like homeless, pediatric, etc.
      • race/ethnicity
    • We recommend that patient matching systems do not have access to PHI. Therefore, some attributes that may be used today within organizations are not recommended for matching across orgs/at scale. Examples are:
      • encounter data
      • clinical data e.g. blood type


  • No labels