Identification

In the context of this specification, the process of assigning an ID or finding an ID based on knowing some traits about the RWE.
We are not using the term in the sense of a login scenario (in which the user is identifying himself or herself).

Not "login" identification

Real-World Entity (RWE)

A person or item of equipment in the real world, as distinct from its representation in an automated information system.

Identity

Identifier (ID)

A data value that represents the identity of a real-world entity.
Structurally, it is a sequence of characters (possibly but not necessarily numeric) that one or more systems in an ID Domain use to represent an entity and bind related information (as a trait set.)

Medical Record Number

Information Entity

The logical record that describes the entity in an application. Strictly speaking, the IXS stores traits to merely identity the entity, not describe it. However, an IXS configured with adequate traits can be used as a definitive source for demographics.

SFM App I DC.1.1.1, 1.1.4
IHE Patient Registry Record

ID Domain or Domain

Formally, the namespace in which an identifier is defined.
Practically, the contextual qualifier that restricts its scope of valid use.
As an email address is meaningless (invalid for any use) apart from its (Internet) domain name; a diagnosis code is meaningless apart from its code set, an ID is meaningless apart from an express or implied ID domain. See also Qualified ID

namespace

Domains of Interest

A requestor (client) might be interested identifiction information from more than one domain. This DOI argument enables the client to specify such.

Foreign Domain

An ID Domain other than the one in focus.

Parallel to relational database "foreign key" concept

Identifier Integrity

The identifier identifies exactly one Real-World Entity, and that Real-World Entity has only one Identifier in this domain.

Entity Integrity

The primary key identifies exactly one tuple (row) in a relation (table).

Qualified ID

An ID that includes its ID domain as (as in stelsewhere.patient.mrn.12345

Candidate

An entity returned by a matching process for a "find" operation. For example, if a clerk enters identifying information about an entity and searches a IXS system for a match, the IXS system returns one or more candidates along with indications of how well each candidate matches the entered information.

Source ID (SID)
or Local Id

An ID expressed or asserted by the client of an IXS or XEIS.
The shorthand is pronounced "Sid" as in "Sid Ceaser" (Not "S-I-D").
In a Simple IXS (single domain) scenario, both client and server are exclusively concerned with SIDs, not MIDs.

Medical Record Number,
HL7 instance identifier (II) applied to entities

Find vs. Get

We find when we are retrieving potentially multiple candidate identities for further inspection and consideration. We get when we expect exactly one based on a supplied SID or trait set.

Source ID Domain (SIDD)

The ID Domain of an ID. Verbally, "SID Domain", not to be confused with the SID.

xx

Bind

To logically attach or associate a profile of traits about an entity to an ID, permitting the use of the ID as shorthand for the profile.

Mediation

Generically: Providing communication or relationship among two or more otherwise independent entities

Correlation

An inferring of an association of SIDs either within a single ID domain or among multiple ID Domains.
To actually record the association the SIDs may be linked. The link durably expresses the correlation.
To actually correct the duplicate the SIDs may be merged (in the source, in the cross-reference, in a repository)

Cross-referencing
Cross-Domain
Linking

Cross-Reference

A cross-reference table that supports the lookup of corresponding SIDs.

IHE: Patient Identifier Cross-referencing (PIX)

Profile, Demographic

The set of traits bound to an identity in an ID domain, or the set of selector traits supplied for search purposes

Profile Base

The Database of demographic profiles that an IXS uses in its searches

Mediating ID (MID)

An ID functioning as the correlating domain of an XEIS, wherein that ID is NOT considered an Enterprise Master ID in local policy. In an XEIS (multiple source domain) scenario, the client submits and receives SIDs from the server, which uses MIDs as its mediating key.
The shorthand is pronounced "Mid" as in "Midway". Short for Mediating ID (or Master ID if appropriate)

Correlating Domain
Cross-Referencing Domain
IHE: XDS Affinity Domain

Master ID (MID)

An ID functioning as the correlating domain of an XEIS, wherein that ID is used not only to mediate (correlate) SIDS, but is also regarded and used as an Enterprise Master ID in local policy. Since all Master IDs are also mediating IDs, the mediating domain of an XEIS can always be called a MID, even if it is not functioning as a master ID as some define master.

MID Domain (MIDD)

The master or mediating domain

TBD

ISO OID for globally and uniquely identifying the identifier domain itself.

V2 namespace ID, V3 Assigning authority, PIDs Registration Authority

Confidence or Confidence Level

A matching algorithm's measure of the likelihood that a candidate represents the same RWE as that of its selector profile. When a matching process returns a list of candidates it also returns a confidence level value with each entry in the list of candidates. The range of values for the confidence indicator is 0.0-1.0 with 1.0 being the higher confidence (e.g., 100%).
In an XEIS or SEIS scenario, both the identities being compared have already been registered in their source systems. Since all past events have probabilities of one or zero, the calculation is one of likelihood and confidence rather than probability.
We have intentionally avoided called this a probability, for two reasons:

• In an XEIS scenario the bindings of SIDs to profiles is a past event, and probabilities apply only to future events. In other words, it is already determined whether the profiles in question were bound to the same real-world entity - and all that is uncertain is whether it was correct. If the matching in unattended, then it is also determined whether the algorithm will correlate them.
• Additionally, to call this element a probability would be to inappropriately disqualify implementers that do not provide probabilistic matching logic (Fellegy-Sunter, Bayesian distributions, Maximum Entropy, etc). The term "confidence" is fully correct without begging implementation or policy.

probability

Register

To represent a real-world person to a health information system, associating the person's demographic profile to a newly assigned identifier. From this point on the system may refer to the person by the identifier.

Demographic profile

List of demographic traits or attributes to be used in identifying entities. The term demographic is used loosely here. Obviously, if the entity type is "medical equipment" then its demographic profile does not consist of demographics in the common sense.
In the context of identifier management discussions (as opposed to software technology standards discussions), the term profile is understood to mean "demographic profile".

SSN, driver's license number, household IDs, location IDs, organization IDs

Overlay

In the client application, a case in which a SID is suspected to have been used by more than one real world entity (RWE or person). Contrast with Duplicate.
In the XEIS, a case in which a SID has been correlated to more than one MID (multiple MIDs per SID)

Collision, Reuse

Duplicate

In the client application, a case in which one real world entity (RWE or person) is suspected to be representing by (bound to) more than one SID.. Contrast with Overlay.
In an XEIS, a case in which a MID has been correlated to more than one SID (multiple SIDs per MID)

ID conflict

A duplicate or overlay. A conflict can be suspected (perhaps pending human adjudication) or it may be confirmed.

Merge

An operation on two or more IDs representing the same person in an ID Domain that deactivates all but one of them (the "surviving" ID; the rest are "non-surviving"). Merge operations are used to rectify the discovery of Duplicate ID's. Contrast with Linking, in which IDs are not deactivated, but merely related. Contrast with Correlation, which is just the detection that identities represent the same real-world entity.

Unmerge

To reverse the effects of a merge. To take an entity ID that has been merged with one or more other IDs and undo the merge, resulting in two or more person IDs. The person profiles are bound back to their original IDs before the merge. For example, suppose Person A has ID 1 and Person B with ID 2 had been merged into ID 1. A successful unmerge operation would restore Person A with ID 1 and Person B with ID 2. In practice it is essential that the implementation of unmerge includes both the entity (identity) unmerge and the content (participations and acts) unmerge.

Move

To move participations and acts amongst entities.

Split

To separate one identity and its content into two identities and correctly reallocated content. Might not have ever been merged

Not unmerge

Attended Matching

Matching - Matching that occurs as a result of human interaction. See Matching.

Identifier Traits

Traits that are either other IDs of the entity. An XEIS may (but is not required to) also represent these traits as first-class SIDs for explicit source domains.
Traits that are Entity IDs of secondary Entities

SSN, driver's license number
household IDs, location IDs, organization IDs

Attribute Traits

Traits that directly characterize the entity of interest. Only these are technically, "traits".

First/Given Name, Birth Date

Attended/unattended

Attended: A matching decision or cleanup act with the human in the Loop.

Active/passive identification service

Active: An identification service is active if its decisions constrain or preempt the registrar. It is passive if it is merely queried by the registrar or not used at all by the registrar.

Filter Matching

Matching in which, to qualify as a returned candidate, the traits of the candidate must match each and every corresponding trait of the selector profile. There is no notion of "confidence level" among candidates returned

Inadequate Confidence

The supplied trait set lacks enough data - or enough adequately selective data - to possibly find a match.

This is related to but distinct from "required traits not supplied"

Positive match or positive result

A match as opposed to "no match". It does not mean positive as in "certain".

A hit

Negative match

A match was attempted but failed. No match was found. It a result - not an exception

No hit

Ambiguous match

More than one result in an operation that expects zero or one. The client process must not be allowed to arbitrarily and unknowingly use only one of them.

Fuzzy Matching

Matching in which, to qualify as a returned candidate, the traits of the candidate need not match each and every corresponding trait of the selector profile. Accordingly, there is a notion of confidence or closeness for each candidate.

Control Traits (Pseudo traits)

Traits that are used to control or "hint" the matching process. Any information that may affect "how" the matching process operates on the other traits supplied.

MatchiingPolicyname, MultipleBirthIndicator

False Positives

A positive matching outcome (a "hit") that was false (erroneous). If content is being consolidated (not merely correlated) by MIDs then there must be a processes for separating content that has been erroneously consolidated, based on journals or versions.

False Negatives

A negative matching outcome (a "not-found") that was false (erroneous).

Conflict Case

A set of identifiers in which one ID in one domain has been mapped to multiple identifiers in one or more other domains, and these IDs have not been "linked". Either the first domain has an overlay or the second domain has duplicates.

Visibility

Whether or not a particular Identity (represented by its identifier) is visible to users of different purposes or interfaces.
IDs might have differing visibility for attended operations versus unattended; or differing visibility to management and query versus visibility to administrative operations.
Rather than modeling visibility in the interface, implementations (and their configurations) should determine visibility in various situations based on identifier state and integrity status described below.

SFM inactivate from general searches

Identifier State

• Temporary: Normally required thorough identification has not been conducted, but content may be attached to this identity. If the trait set is sparse (lacks values from important trait types) then perhaps it will be exempt from unattended matching
• Active: thorough identification has been conducted, and content may be attached to this identity.
• Inactive: Not permitted or not available for keying content
  In reality, the states are discrete. There are no degrees of activity.

Related to but distinct from integrity status

Integrity Status

• Intact: The entity integrity of the identifier is considered adequate for all normal operations.
• Suspect: There exist potential issues with the integrity for the identifier due to matching multiple other identities (ambiguous outcomes); due to known involvement in a suspected conflict; due to VIP or no-press status. IDs in this integrity state would normally be designated for manual review or adjudication.
• Conflicted: There exist confirmed issues with the integrity of the identifier.
  In reality, the integrity states are continuous and subjective, but we represent them as discrete in information systems. Further work could define confidences (of suspected conflicts or of links) , as is done in public safety applications.

Related to but distinct from identifier state

Client

Any system or application that accesses or requests service from an entity Identification Service. A subset of participants (below)

XEIS

Formally expanded as a "Cross-Domain IXS"
Casually pronounced "X-E-I-S"
Causally written as "an XEIS"
An EIS that can mediate identifiers across two or more ID domain (not merely track linkages within one domain). Since the XEIS must be able to mediate SIDs amongst disjoint or intersected RWE populations, it must utilize a distinct and explicit ID domain for the express purpose of tracking RWEs and mediating SIDs.
"The" principal domain of an XEIS is its correlating domain - its MIDs.
The XEIS can infer linkages across domains. That is the XEIS can assert them for itself in addition to merely recording client-asserted correlations.

PIDS Correlation Manager
IHE: Patient identifier Cross-refernce manager actor

SEIS

Formally expanded as "Single-Domain IXS"
Casually pronounced "S-E-I-S"
Casually written as "an SEIS"
An IXS that manages one domain or that mediates identifiers within exactly one ID domain (not across domains) The SEIS will support linking of SIDs within its domain, and might therefore even manage a mediating ID domain; however, all those mediated relationships are asserted, not inferred by its matching logic. Its job then includes mediation but not correlation. In other words, in an IXS scenario the client system is performing the correlations and expressing them as linkages; the server simply stores and retrieves those assertions. The linkages decisions are "attended", that is detected or at least asserted by humans.
The principal domain of an SEIS is its "only domain" - the ID domain that it manifests to its clients.
If an IXS product or implementation becomes able to mediate amongst multiple source domains, or becomes able and authorized to infer linkages in unattended mode, it is still "only an SEIS" unless it implements unattended correlation and implements the XEIS methods.

PIDS ID Manager

IXS

An SEIS or XEIS.

Dual-Mode IXS (DEIS)

An installation that implements (exposes) not only an XEIS Web Service but also a separate SEIS Web Service for its correlating domain. Its SEIS provides for explicit management of its MIDs. The two must not be implemented in the same service, since to do so would give rise to confusion as well as technical and political (enterprise policy-breaking) misuse.

Class Ancestry

LivingSubject/Person/Provider
LivingSubject/Person/Patient

Class/Role

The distinction among different classes and subclasses of "Entity". An IXS instance might support multiple classes. In various scenarios, the clients and servers need to agree on the scope of the identities that the clients register or that the server reports. Perhaps this will be specified as a list-of-acceptable as opposed to a list of required.

Issue

Participants

Clients and servers of the IXS; the actors that interact with the IXS.

IHE patient identifier cross-reference consumer; patient demographics consumer/supplier

Ancillary System

A subordinate, secondary, or auxiliary system within an organization. An ancillary system could have its own simple IXS and/or be sending requests to other IXS.

Laboratory Info System, Scheduling System, Pharmacy System, Radiology Systems

Component

A cohesive set of software services. In this specification, an IXS implementation is referred to as a component. A IXS component implements varying IXS interfaces as defined by IXS conformance levels. Hence a component is defined by its "Duty" or "Responsibility" (Singular). If a Components responsibilities cannot be summarized as one duty, it is conceptually multiple services, not one. Of course the overarching responsibility can be divided into multiple areas, yet it should expressible as one.

Naming Authority

Any organization that assigns names determines the scope of uniqueness of the names and takes the responsibility for making sure the names are unique within its name space. In the same way that ID values are meaningful only within the context of their ID Domains, names are unique only within the context of their naming authority.

Identifier assigning authority

MPI and EMPI

Master Patient Index, or "Master Person Index" and Enterprise Master Patient Index. In some cases the word enterprise denotes correlation amongst multiple identifier domains. In other cases the term master denotes merely the authority (as a "system of record" of one identifier domain. Since in practice the terms are ambiguous, the IXS specification instead employs the terms IXS and XEIS, and also defines the term "mediating" as critically distinct from "master".

Trait

An attribute "name-value" pair that can be used specifically for purposes of identifying an entity.
Examples of a trait include name, date of birth, gender, address, etc.

Trait Type

The name part of a trait, for example, "First"

PIDS: Trait Type

Trait Set

The (unordered) set of traits for a particular identity, or a set of traits used as criteria in a search operation. A given trait name can occur more than once in a trait set. For example, Last=Smith and Last=Jones are separate traits in the same trait set. This could also be expressed as a multi-valued trait (last=Smith, Jones) as the implementation may choose.

Common Terms: Demographic profile if in the context of searching for person identities.
PIDS: Profile

Matching

The process that determines from a set of traits whether an entity may already be known to a IXS; that is, present in its "profile base" (of demographic profiles) or cross-reference (of identifiers). The matching operation may return zero to many persons depending on the purposes of the operation, the algorithm, weights on traits, and threshold parameters used in the matching process.

Content Correlation vs. Consolidation

In a repository that receives content keyed from multiple source domains, a correlating facility may be used to correlate identifiers; SIDs, MIDs, or both. To key the content on SIDs constitutes "content correlation" (correlated through the identifier cross-reference). To key content on MIDs constitutes "content consolidation". Each approach has its benefits and drawbacks. Sites that perform timely cleanups can better afford to do content consolidation. If conflicts are many and cleanups are delayed, such a site should use only content correlation.

Unattended Matching

A matching process that occurs without human intervention. See Matching. For example, an automated process may be configured to run once a night to scan an ID Domain, searching for potential duplicate person entries. Also when profiles are added to an ID Domain and the IXS automatically determines if an ID already exists for the person.

SuppliedSID

Operations are named in a manner as to connote the fact that the client is issuing an imperative to the server. The client is "speaking" a request to the server, as it were. In the IXS the term s is added to operation names wherever it helps clarify that the client is supplying the SID to be allocated.

Source System

A system that is an IXS client (using query and management) in its normal operations.

participant
IHE actors: Identity feed, identity producer, consumer.

Optionally supplied versus Optionally Implemented

"Optionally supplied" refers to the clients choice whether to supply a value for a particular argument in a particular call.
"Optionally implemented" refers to the servers option to support a particular operation or process a particular argument.

Argument Interaction

In a "find" operation, the client might have no way to guage how many candidates might be returned. In such a scenario they client may assert various arguments (defaulting others) to suit purpose at hand.

• Specify the limit on result size and let the server dynamically determine the confidence - not default it.
• Specify the confidence threshold and let the server limit the result size
  
• Specify both to direct the server to discard all but the best N that have confidence above the threshold.

Client

Any process that requests a service from an IXS or other service component.

Problem Types

Special Cases (as distinct from platform failures or exceptions). Business conditions that are potentially of legitimate concern to the client process but do not prevent the operation from succeeding.
Exceptions (distinct from platform failures or warnings) - business rule conditions that prevent an operation from succeeding. The operation leaves no change of state in the server, that is, the operation has no effect. The condition is reported to the client. Exceptions do not include.
Technical failures (distinct from exceptions and special cases, though lines may blur)

Krafzig, Banke, Slama, Enterprise SOA. Prentice-hall 2005. Has good discussion of this subject.

Naming Authority

Any organization that assigns names determines the scope of uniqueness of the names and takes the responsibility for making sure the names are unique within its name space. In the same way that ID values are meaningful only within the context of their ID Domains, names are unique only within the context of their naming authority.

Identifier assigning authority

System

One of several applications that interact with each other, interact with the IXS or implement IXS. Examples of systems might include a hospital or clinical information system, an ancillary system such as a lab or radiology system, or a financial/administrative system.

Application
Participant

Unattended Matching

A matching process that occurs without human intervention. See Matching. For example, an automated process may be configured to run once a night to scan an ID Domain, searching for potential duplicate person entries. Also when profiles are added to an ID Domain and the IXS automatically determines if an ID already exists for the person.

Service Empowerment

The amount or characterization of authority vested in the automated logic of the service to enforce business rules. Rules are policy, but the levels and timings of its enforcement are also policy matters. A service should neither promote or preclude policy, but should support it with manageability and flexibility. For example the service may be empowered to
merely track or record, warn, advise, notify, or even autonomously correct and preempt.

Contrast with simple data processing concepts as create, read, update, delete.