2Person Topic HL7 PA PER HL7 Version 3 Standard: Patient Administration, Release 1 Last Ballot: May 2007  |
| Return to Domain Table of Contents | |
|
Content Last Edited: 2008-07-30T16:14:52 |
|
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
2.7 Interactions
2.A Update Mapped to DSTU
The Patient Administration Person topic defines messages exchanged with Person Registries. The Person information model defines common identifying and demographic data elements that might be collected for persons regardless of the roles they play. The model excludes Person attributes that would likely be collected only for patients -- organDonorInd, educationLevelCode, disabilityCode, livingArrangementCode, religiousAffiliationCode, raceCode and ethnicGroupCode. Those attributes are included in Person within the Patient information model.
This document includes message specifications for:
- Notifications for state transitions of activated, revised, nullified and obsolete (duplicates resolved)
- Queries for Find Candidates, Get Demographics and Get Identifiers
- Requests for adding and revising records
Possible future work includes:
- Notification messages for other state transitions such as suspended or terminated
- Request an identifier
- Representing person registry information in structured document and service profile specifications
The Patient Administration Technical Committee invites implementers with additional requirements to submit content proposals for future releases of the standard.
This document is a complete replacement for the existing Person Topic of Patient Administration DSTU that passed ballot in the 2006 January ballot cycle. The information model underlying message definitions for this update includes a number of substantive changes some of which are not backwards compatible with the existing DSTU. As a consequence all artifacts have new identifiers; an annex entitled Update Mapped To DSTU shows how the artifacts in this update relate to the original DSTU.
The following list identifies the specific changes were made to the Person information model in this update:
- A negative comment on the 2006 January ballot noted that a valid message could be constructed that included neither a Person.name nor Person.id. Both attributes were Required for conformance but the cardinality lower bound was 0. The Technical Committee found this
comment persuasive and agreed to raise the lower bound from 0 to 1 in the 2007 DSTU update. However, the TC received a 2007
January ballot negative comment which it also found persuasive arguing against Person.id being required because this conflicts with legal requirements in some countries. So the net changes for this update to the
universal standard are:
- Person: the id attributeis changed from Required for conformance to Optional.
- Person: the name attribute lower cardinality is changed from 0 to 1 so messages must send a Person.name or suitable null flavor such as temporarily unavailable or masked. Note this change is not backwards compatible because it tightens constraints in the model.
- The Person information models need to be able to express that the focal person does not have certain relationships such as employment. In the 2006 January DSTU this was conveyed by setting the negationInd attribute to true and sending no associated entity. For example, "Send an Employee with negationInd of true and no employerOrganization to convey that the focal person is not employed." This DSTU Update eliminates the conditional requirement by changing the
associations from Optional to Required for conformance with a cardinality of 1. Note that these changes are not backwards compatible because they tighten constraints in the model.
- Employee: The employerOrganization association from Employee is changed from Optional 0..1 to Required 1..1. To convey that the focal person is not employed set employerOrganization to not applicable null flavor and Employee.negationInd to true.
- PersonalRelationship: The relationshipHolder association from PersonalRelationship is changed from Optional 0..1 to Required 1..1. To convey that the focal person does not have a specific type of personal relationship set relationshipHolder to not applicable null flavor and PersonalRelationship.negationInd to true.
- ContactParty: The contactEntityChoice association from ContactParty is changed from Optional 0..1 to Required 1..1. To convey that the focal person does not have a specific type of contact relationship (next of kin or emergency contact) set the contactEntityChoice association and the ContactParty.telecom attribute to not applicable null flavor and ContactParty.negationInd to true.
- Guardian: The guardianEntityChoice association from Guardian is changed from Optional 0..1 to Required 1..1. To convey that the focal person does not have a guardian relationship set the guardianEntityChoice association to not applicable null flavor and Guardian.negationInd to true.
- ContactParty: The telecom attribute was Mandatory in the 2006 January DSTU but is changed to Required in this DSTU Update to support the change above.
- BirthPlace: The addr attribute had no constraints. This DSTU Update adds a constraint on the use property of BirthPlace.addr restricting it to PHYS to ensure that the address in BirthPlace is physical visit address and not a post office box type address. Also, the upper bound of the cardinality is reduced from * to 1 since only one address type can be sent . Note that these changes are not backwards compatible because they tighten constraints in the model.
- This DSTU Update replaces the contact and identified/confirmable variants of CMET with the less restrictive informational variant in places where requiring an identifier in the CMET is not a requirement. Note that these changes are not backwards compatible because they reduce the information in the model.
- Employee: The E_Organization CMET that is the scoping entity for the Employee role is changed from the contact variant to the informational variant
- Student: The E_Organization CMET that is the scoping entity for the Student role is changed from the contact variant to the informational variant
- ContactParty: The E_Person and E_Organization CMETs in EntityChoice for the playing entity of ContactParty role are changed from the identified/confirmable variants to the informational variants
- Guardian: The E_Person and E_Organization in EntityChoice for the playing entity of Guardian role are changed from the identified/confirmable variants to the informational variants
- This DSTU Update replaces the universal variant of CMET with the smaller informational variant in places where extensive information in the CMET is not necessary. Note that these changes are not backwards compatible because they reduce the information in the model
- BirthPlace: The E_Place [universal] CMET that is the playing entity for the BirthPlace role is changed to the informational variant.
- PersonalRelationship: The E_Person [universal] CMET that is the playing entity for the PersonalRelationship role is changed to the informational variant (see next item)
- PersonalRelationship: This DSTU Update adds the addr and telecom attributes to PersonalRelationship to because E_Person [informational] does not include the contact information that was in E_Person [universal]
- This DSTU Update adds AdministrativeObservation to convey observations about the focal person in the registry such as Preferred Contact Method, Preferred Contact Times, and Preferred Written Communication Format.
- This DSTU Update adds QueryMatchObservation to the Person Demographics model to convey degree of match for a 'find candidates' query response.
- Employee: At the January 2006 Work Group Meeting the Technical Committee approved addition of the occupationCode attribute to Employee to convey the person's occupation as opposed to Employee.jobCode which characterizes a particular job.
- IdentifiedPerson: the associations to the playing entity (identifiedPerson) and scoping entity (assigningOrganization) are set to Required for conformance. This was a technical omission in the previous DSTU.
The Person information model for this DSTU Update includes a number of changes that are not backwards compatible. See items 1, 2, 4, 5 and 6 above. Also, several vocabulary proposals are pending Harmonization approval.
|
Reference
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
Purpose
Diagram
| Person Registry Record Added |  PRPA_IN101301UV02 |
In August Neville Nuclear moved to Ann Arbor with his wife Nelda and their two children, Nancy and Ned. Nancy, an avid soccer player, persuaded Nelda to go with her to register for a fall soccer team. At the signup they found that Nancy needed to have a physical exam before the season started in September. Nelda took Nancy to a nearby Good Health Hospital clinic and learned that her daughter would need an appointment. Since the Nuclear family was new to the Good Health Hospital, the registration clerk gathered basic information (name, date of birth, address, telephone number) about them and entered the data into the registry beginning with Neville (See Financial Chapter regarding insurance information). Next the clerk added Nelda to the registry and noted her relationship to Neville. Then the registration clerk added Nancy to the registry, the relationship to her parents, contact information and school information. The system assigned a unique Person Identifier to each person's record. Three Person Registry Record Added interactions were sent from the registry to GHH's person tracking applications.
Purpose
Diagram
| Person Registry Record Revised | PRPA_IN101302UV02 |
Neville Nuclear took his daughter Nancy to the Good Health Hospital Pediatric Clinic for her physical examination. He also stopped by the registration desk to update the address and telephone number for Nancy, his wife Nelda, and himself because they had moved since giving the original information to the clerk two weeks before. [Person Registry Record Revised interaction].
Purpose
Diagram
| Person Registry Record Nullified | PRPA_IN101303UV02 |
Good Health Hospital recently implemented a Person Registry. The Registry was populated with person information extracted from GHH's existing systems. Shortly after the Registry began operation the record clerk, Christopher Clerk, found that an entry for the test person "John Q. Public" was mistakenly transferred to the Person Registry. Christopher marked the record as "entered in error" and GHH person tracker applications were sent a notification [Person Registry Record Nullified interaction].
Purpose
Diagram
| Person Registry Duplicates Resolved | PRPA_IN101304UV02 |
When adding Nelda Nuclear to the Good Health Person Registry the registrar did not find the pre-existing record for Nelda under her maiden name of Everywoman. When the error was later discovered, the registration for Nelda Everywoman was marked as "obsolete" and linked to the newer registration for Nelda Nuclear [Person Registry Duplicates Resolved interaction].
Purpose
Diagram
| Person Registry Find Candidates Query | PRPA_IN101305UV02 |
| Person Registry Find Candidates Query Response | PRPA_IN101306UV02 |
Dr. Harold Hippocrates, who has admitting privileges at Good Health Hospital, requested person demographics for his patient, Adam Everyman.
The GHH medical record clerk, Christopher Clerk, first determined whether Mr. Everyman was in the GHH Person Registry. Christopher went online and entered Mr. Everyman's last name, sex and approximate birth date and initiated a Person Registry Find Candidates Query query to the GHH Person Registry. The person registry returned a Person Registry Find Candidates Query Response with the collection of candidate records allowing Christopher Clerk to refine the query for Adam Everyman, if desired.
Purpose
Diagram
| Person Registry Get Demographics Query | PRPA_IN101307UV02 |
| Person Registry Get Demographics Query Response | PRPA_IN101308UV02 |
Dr. Alan Admit, who has admitting privileges at Good Health Hospital, notified the GHH Registration Office that his patient, Adam Everyman, would arrive at the hospital at a scheduled time, and that his office had performed a pre-admit on Adam Everyman.
As part of the admitting process, the GHH Registration clerk Alice Admitter entered Mr. Everyman's person identifier and initiated a Person Registry Get Demographics Query to the person registry. The person registry returned Mr. Everyman's current demographic information in a Person Registry Get Demographics Query Response and Alice confirmed this information with Mr. Everyman as she completed the admission process.
Purpose
Diagram
| Person Registry Get Identifiers Query | PRPA_IN101309UV02 |
| Person Registry Get Identifiers Query Response | PRPA_IN101310UV02 |
An enterprise registry will often store multiple system identifiers to allow consistent identification of a person across the enterprise.
Christopher Clerk works at Good Health Hospital's Record Management Office. The person registry that is in place in the Records Management office associates all the identifiers for a person in order to allow access to all the medical records within the enterprise for a person.
Christopher Clerk enters an identifier for Adam Everyman and initiates a Person Registry Get Identifiers Query to the Good Health Hospital Person Registry. The registry returns a Person Registry Get Identifiers Query Response with all identifiers associated with Adam Everyman in the person registry.
Purpose
Diagram
| Person Registry Add Request | PRPA_IN101311UV02 |
| Person Registry Add Request Accepted | PRPA_IN101312UV02 |
| Person Registry Add Request Rejected | PRPA_IN101313UV02 |
Nelda Nuclear delivers her baby son, Ned Nuclear, in Good Health Hospital. The hospital adds the newborn to the source system, assigning a medical record number for the baby, records the mother's unique identifier, mother's name, and newborn demographic data. An add client request is sent to the jurisdictional client registry system (JCRS) [Person Registry Add Request interaction].
The JCRS adds the new person information to the registry and generates a unique client identifier which is returned in the add client confirmation message sent to the source system [Person Registry Add Request Accepted interaction].
Shortly after the Nuclear family moved to their new home across town Nelda Nuclear went to the nearby Good Health Hospital walk-in clinic to get a flu shot. The clerk saw that Nelda was not already registered in the local system, collected identifying and demographic information and sent a request to add Nelda to the GHH enterprise person registry [Person Registry Add Request interaction]. The enterprise person registry responded with a confirmation message and Nelda's enterprise identifier [Person Registry Add Request Accepted interaction].
Shortly after the Nuclear family moved to their new home across town Nelda Nuclear went to the nearby Good Health Hospital walk-in clinic to get a flu shot. The clerk saw that Nelda was not already registered in the local system, collected identifying and demographic information and sent a request to add Nelda to the GHH enterprise person registry [Person Registry Add Request interaction]. The enterprise person registry responded with a rejection message indicating that Nelda was already registered under her maiden name and included her enterprise identifier [Person Registry Add Request Rejected interaction].
Purpose
Diagram
| Person Registry Find Candidates Query | PRPA_IN101305UV02 |
| Person Registry Find Candidates Query Response | PRPA_IN101306UV02 |
| Person Registry Get Demographics Query | PRPA_IN101307UV02 |
| Person Registry Get Demographics Query Response | PRPA_IN101308UV02 |
| Person Registry Revise Request | PRPA_IN101314UV02 |
| Person Registry Revise Request Accepted | PRPA_IN101315UV02 |
Shortly after the Nuclear family moved to their new home across town Nelda Nuclear went to the nearby Good Health Hospital walk-in clinic to get a flu shot. Nelda tells the clerk that she was previously seen at a GHH clinic in her old neighborhood. The clerk initiates a Person Registry Find Candidates Query to the GHH enterprise person registry using Nelda's name, birth date, and driver's license number. A candidate list is returned in the Person Registry Find Candidates Query Response, the clerk locates Nelda's record and sends a Person Registry Get Demographics Query using Nelda's GHH enterprise person id. The enterprise person registry returns the demographic information currently on file for Nelda in the Person Registry Get Demographics Query Response. The clerk reviews the information with Nelda and finds that her address needs to be updated. The clerk updates the address in the local system and sends a Person Registry Revise Request to update Nelda's address in the GHH enterprise person registry. The enterprise person registry accepts the revision and returns a Person Registry Revise Request Accepted.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Reference
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
| Structured Name: | Identified Person Event Revision Tracker |
This application role is responsible for receiving a single interaction -- notification that a record in a person registry has been revised. The application role was singled out to support systems such as lab systems that only need to track changes in person information.
| Structured Name: | Identified Person Event Comprehensive Placer |
This application role represents applications that initiate state transition requests to person registries.
| Structured Name: | Identified Person Event Comprehensive Fulfiller |
This application role represents the responsibility of person registries to respond to state transition requests.
| Structured Name: | Identified Person Event Comprehensive Informer |
This application role represents the responsibility of person registries to notify systems of state transitions (such as add, revise, nullify) on records it holds.
| Structured Name: | Identified Person Event Comprehensive Tracker |
This application role represents the responsibility to receive state transition notification messages from person registries.
| Structured Name: | Identified Person Event Query Placer |
This application role represents applications that initiate queries to person registries.
| Structured Name: | Identified Person Event Query Fulfiller |
This application role represents the responsibility of person registries to respond to queries.
|
Reference
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Structured Name: | Identified Person Event Activate Notification |
| Type: | State-transition based |
This trigger event signals that a record was added to a person registry.
| Structured Name: | Identified Person Event Activate Request |
| Type: | User request |
A source system sends a person record to a person registry with a request to add the record to the registry.
| Structured Name: | Identified Person Event Activate Confirmation |
| Type: | Interaction based |
This trigger event signals that a person registry has accepted a request to add a new record.
| Structured Name: | Identified Person Event Activate Rejection |
| Type: | Interaction based |
This trigger event signals that a person registry has rejected a request to add a new record.
| Structured Name: | Identified Person Event Revise Notification |
| Type: | State-transition based |
This trigger event signals that a record was revised in a person registry.
| Structured Name: | Identified Person Event Revise Request |
| Type: | User request |
A source system sends a request to a person registry to make specific changes to the information it holds for a specified person.
| Structured Name: | Identified Person Event Revise Confirmation |
| Type: | Interaction based |
This trigger event signals that a person registry has accepted a request to revise information it holds for a specified person.
| Structured Name: | Identified Person Event Revise Rejection |
| Type: | Interaction based |
This trigger event signals that a person registry has rejected a request to revise information it holds about a person.
| Structured Name: | Identified Person Event Nullify Notification |
| Type: | State-transition based |
This trigger event signals that a record was nullified in a person registry.
| Structured Name: | Identified Person Event Obsolete Notification |
| Type: | State-transition based |
This trigger event signals that duplicate records were resolved in a person registry.
| Structured Name: | Identified Person Event Find Candidates Query |
| Type: | User request |
A user initiates a query to a person registry requesting records that match a set of demographic information.
| Structured Name: | Identified Person Event Find Candidates Query Response |
| Type: | Interaction based |
A person registry responds to a Find Candidates Query request by returning records that match a set of demographic information sent in the query. Each returned record includes an observation reporting how well it matched the query parameters.
| Structured Name: | Identified Person Event Get Demographics Query |
| Type: | User request |
A user initiates a query to a person registry requesting the demographic information the registry has recorded for a specified person.
| Structured Name: | Identified Person Event Get Demographics Query Response |
| Type: | Interaction based |
A person registry responds to a Get Person Demographics Query request by returning the demographic information it has recorded for the person specified in the query.
| Structured Name: | Identified Person Event Get Identifiers Query |
| Type: | User request |
A user initiates a query to a person registry requesting the identifiers the registry has recorded for a specified person.
| Structured Name: | Identified Person Event Get Identifiers Query Response |
| Type: | Interaction based |
A person registry responds to a Get Associated Identifiers Query request by returning the identifiers it has recorded for the person specified in the query.
|
Reference
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Activate R-MIM defines the payload message used for state-transition requests and notifications for adding new records in a person registry.
Walk-through
IdentifiedPerson
The IdentifiedPerson class is the entry point to the R-MIM and contains one or more identifiers (for example an internal id used only by computer systems and an external id for display to users) for the Person in the Person Registry. It also includes the focal person's contact information (address and telephone). This is the information the assigningOrganization uses to communicate with the focal person in the context of the Person Registry. The Required statusCode represents the state of the record (for example active, nullified, obsolete). The effectiveTime specifies the time interval during which this record is in effect; an active record will have no ending time. The statusCode is fixed as "active" in the Person Activate message.
AdministrativeObservation
The AdministrativeObservation class conveys administrative information about the focal person that cannot be conveyed by other classes and attributes in the model. Examples of administrative observations are Shared Secret, Preferred Contact Method, Preferred Contact Times, Preferred Written Communication Format. The mandatory code attribute characterizes the type of administrative observation performed and the mandatory value attribute contains the result of the observation.
Person
The Person class contains identifying and demographic data elements for the focal person similar to those in the HL7 v2.x PID segment such as name, gender, date of birth, marital status and deceased indicator and time. The contact information (address and telephone) in Person is provided without context; it is provided without guidance for when it should be used. The nameand id attribute is required with a minimum cardinality of 1, meaning it must be valued or contain an appropriate null flavor such temporarily unavailable, not asked, masked.
OtherIDs
Identifiers used for the focal person by other registries are sent in the OtherIDs class; this could even be an identifier used by the same scoping organization as this Person Registry but in a different context. It includes statusCode and effectiveTime to support distinguishing active from inactive identifiers. The scoping organization for the identifier is sent in a required E_Organization [identified/confirmable] CMET.
BirthPlace
The focal person's place of birth can be sent in a BirthPlace class. The BirthPlace.addr is a physical address (address use =PHYS) and could be a full address or only known address components such as city or country. The BirthPlace.addr must be non-null if the E_Place.name is null. The geographic coordinates of the BirthPlace can be conveyed in an A_SpatialCoordinate observation.
LanguageCommunication
Information about what language(s) should be used to communicate with the focal person can be sent in the LanguageCommunication class.
Employee
Employment information for a person, including employee identifier and work address and telephone number, can be sent in an Employee class. The statusCode and effectiveTime attributes can differentiate between current and former employee relationships. Send an Employee with negationInd of true and employerOrganization of not applicable null flavor to convey that the focal person is not employed.
Citizen
Citizenship information for a person, including citizen identifier and effective time can be sent in the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code, is mandatory.
Student
Information for students, including student identifier and a boarding student's address and telephone, can be sent in a Student class. The statusCode and effectiveTime attributes can differentiate between current and former student relationships.
PersonalRelationship
Associations between persons in the Person Registry, such as spouse or parent, can be sent in a PersonalRelationship class. The exact nature of an association is described by the code attribute with a value drawn from the PersonalRelationshipRoleType domain. The statusCode and effectiveTime attributes can differentiate between current and former personal relationships, for example, a former spouse. Most associations can be represented in either of two ways depending on who is the player and who is the scoper. For example, the association between a father and his daughter can be represented by a code of father where the parent is the player and the child is the scoper, or by a code of daughter where the child is the player and the parent is the scoper. Send a PersonalRelationship with negationInd of true and relationshipHolder of not applicable null flavor to convey that the focal person does not have any known personal relationships.
Member
Membership of person in a group can be sent in the Member class. The statusCode and effectiveTime attributes can characterize the current status of the person's membership relationship. The group of which the person is a member can be further characterized by the Group.code attribute, for example religious organization.
ContactParty
A person or organization that provides or receives information regarding the focal person is sent in the ContactParty class. The type of contact is determined by a code from the ContactRoleType domain. The current values are next of kin and emergency contact. The telecom attribute is required and mandatory. The statusCode and effectiveTime attributes can differentiate between current and former contacts. If the relationship (e.g., parent, spouse, unrelated friend) of the contact to the focal person is of interest then a PersonalRelationship with the same persons as player and scoper should also be sent. Send a ContactParty with negationInd of true and contactEntityChoice of not applicable null flavor to convey that the focal person does not have a contact party.
Guardian
The Guardian class can send the person or organization (player) that is legally responsible for the care and management of the focal person (scoper). The statusCode and effectiveTime attributes can differentiate between current and former guardian relationships. A facsimile of the legal document establishing guardianship could be sent in the certificateText attribute. If the relationship (e.g., parent, spouse, unrelated friend) of the guardian to the focal person is of interest then a PersonalRelationship with the same persons as player and scoper should also be sent. Send a Guardian with negationInd of true and guardianEntityChoice of not applicable null flavor to convey that the focal person does not have a guardian.
| Identified Person Event Activate | PRPA_HD101301UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Revise R-MIM defines the payload message used for state-transition requests and notifications for revising records in person registry.
Walk-through
The Person Revise R-MIM differs from the Person Activate R-MIM in the following ways:
- IdentifiedPerson - the statusCode attribute can take on any of RoleStatusNormal values (excludes nullify) instead the fixed value of "active"
- The assigningOrganization association from IdentifiedPerson has a lower multiplicity of 0 instead of 1 since the receiver may already know the identity of the registry
- Update Mode - the revise message implements update mode to convey changes and the R-MIM specifies allowed update modes for certain attributes and associations.
| Identified Person Event Revise | PRPA_HD101302UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Nullify R-MIM defines the payload for a state-transition notification after a record in a person registry has been nullified.
Walk-through
IdentifiedPerson
- Mandatory id
- Mandatory statusCode with fixed value of "nullified"
- Non-mandatory assigningOrganization association
Person
- Optional id
- Required name
- Optional administrativeGender
- Optional birthTime
- Optional association to BirthPlace
| Identified Person Event Nullify | PRPA_HD101305UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Demographics R-MIM defines the payload message used for query responses that return a complete or partial record from a person registry.
Walk-through
The Person Demographics R-MIM differs from the Person Activate R-MIM in the following ways:
- IdentifiedPerson - the statusCode attribute can take on any RoleStatus values instead of the fixed value of "active"
- The assigningOrganization association from IdentifiedPerson has a lower multiplicity of 0 instead of 1 since receiver may already know the identity of the registry
| Identified Person Event Demographics | PRPA_HD101303UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Registry Find Candidates Response R-MIM defines the payload message used to return records from a person registry in response to a find candidates query. Each record includes an observation reporting how well the record matched the query parameters.
Walk-through
The Person Registry Find Candidates Response R-MIM is the same as the Person Demographics R-MIM with the addition of the QueryMatchObservation class.
| Identified Person Event Find Candidates Response | PRPA_HD101310UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Identifiers R-MIM defines the payload message used to return all identifiers associated with a record in a person registry.
Walk-through
The Person Identifiers R-MIM is a reduced version of the Person Demographics R-MIM with the following changes:
IdentifiedPerson
- Remove all attributes except id, statusCode and effectiveTime
- Remove administrativeObservation association
Person
- Remove all attributes except id and name
- Remove languageCommunication and birthPlace associations
Associated Roles
- Remove PersonalRelationship, ContactParty, and Guardian because the focal person is the scoping entity for those roles and their identifiers apply to the playing entity
- For the remaining Roles remove all attributes except id, statusCode and effectiveTime
- Constrain id to be Mandatory since the purpose of this model is to convey identifiers
- Remove all attributes except id, code, and name from Group
| Identified Person Event Identifiers | PRPA_HD101304UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
The Person Registry Query By Demographics R-MIM defines the payload for a query-by-parameter message sent to a Person Registry when the query placer knows a set of person demographics.
The response to a Query By Demographics may potentially return many records so the SortControl class and the responseModalityCode, initialQuantity and initialQuantityCode attributes of the QueryByParameter class are included in the information model.
Walk-through
QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller.
- queryId - Identifier for the query. It is used to associate this query instance with both the initial response message and with later query interactions. Valuing queryId avoids the need for the QueryContinuation and QueryAck classes to carry as much detail information as is carried in the initial query.
- statusCode - A value specifying the state of this query (based on the RIM Act class state machine), for example, active, aborted, completed.
- modifyCode - Indicates whether the subscription to a query is new or is being modified
- responseElementGroupId - Identifies the specific message type to be returned in the query response. The message type is constrained to the set of message types supported by the receiver responsibilities associated with the query interaction.
- responseModalityCode - Defines the timing and grouping of the response instances
- responsePriorityCode - Identifies the time frame in which a response is expected
- initialQuantity - Defines the maximum size of the response that can be accepted by the requesting application.
- initialQuantityCode - Defines the units associated with the initialQuantity
- executionAndDeliveryTime - Specifies the time the response is to be returned
SortControl - This class allows the query requester to specify the order in which the server should return multiple results.
- sequenceNumber - Specifies the order of this elementName in the sort
- elementName - Identifies the element upon which the response should be sorted
- directionCode - Specifies sort order (ascending, descending or none)
MatchCriterionList - This collection of parameter items convey instructions to the query fulfiller. The associated parameter items are joined with OR logic.
- MatchAlgorithm - This parameter conveys instructions to the query fulfiller specifying the preferred matching algorithm to use
- MinimumDegreeMatch - This parameter conveys instructions to the query fulfiller specifying the minimum degree of match to use in filtering results
- MatchWeight - This parameter conveys instructions to the query fulfiller specifying the desired weight to be assigned to parameter types in the matching process
ParameterList - This collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message can include any combination of the parameters. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic.
- PersonBirthPlaceAddress - this is a person's birthplace represented as BirthPlace.addr. This can be a full address or only known address components such as city or country. Typically a query would include either this parameter or the next one but not both.
- PersonBirthPlaceName - this is a person's birthplace represented as the name of a Place playing the role of BirthPlace.
- OtherIDsScopingOrganization - an identifier used for the focal person in a different registry is an instance of OtherIDs. The organization that manages that other registry is the OtherIDs.ScopingOrganization. This parameter can be used to find persons who have been registered by a particular organization.
- IdentifiedPersonStatusCode - this is the status of the person record in the target registry. The parameter is used to find records in a particular state such as "active" or "completed".
- PersonDeceasedTime - The death date/time parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).
- MothersMaidenName - Mother's maiden name is a common attribute for confirming the identity of persons in some person registries so it is included as one of the query parameters. But, it may not be obvious how that information is represented in the RIM. Mother's maiden name is the person name part of "family" with an EntityNamePartQualifier of "birth" for the person who is the player in a PersonalRelationship of type of "mother" to the focal person,
- PersonId - This is an identifier for the Person entity. The identifier has no context (scoping organization) other than the namespace from which the identifier was issued (OID root).
- PersonRoleId - This is an abstract concept representing any role class identifier where the focal person is the playing entity for the role; for example, Citizen.id, Patient.id, OtherIDs.id
- IdentifiedPersonTelecom - This is a telecommunications address for communicating with a person in the context of the target person registry. It could be a telephone number, fax number or even an email address.
- IdentifiedPersonAddress - This is a postal address for corresponding with a person in the context of the target person registry.
- PersonBirthTime -The birth date/time parameter can convey an exact moment (e.g., January 1, 1960 @ 03:00:00 EST), an approximate date (e.g., January 1960), or even a range of dates (e.g., December 1, 1959 through March 31, 1960).
- PersonAdministrativeGender - This parameter can limit the search to persons of a specific gender.
- PersonName - The HL7 PN (person name) data type is quite rich and the data type specification should be well understood before being used in a query. For example, the name use parameter can covey that a name is spelled phonetically or based on the SOUNDEX algorithm.
| Identified Person Event Query By Demographics | PRPA_HD101306UV |
Diagram
Click thumbnail above to open larger graphic in a new window
| Parent: | Patient Administration (PRPA_DM000000UV) |
Overview
This Person Registry Query By Identifier R-MIM defines the payload for a query-by-parameter message sent to a person registry when the query placer knows an identifier for person's record in the registry. Note that in practice it may be necessary to do a Person Registry Find Candidates Query to find an identifier for the person before using this message.
The response to a Query By Identifier will typically return a single record so the SortControl class and the responseModalityCode, initialQuantity and initialQuantityCode attributes of the QueryByParameter class are not included in the information model.
Walk-through
QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller.
- queryId - Identifier for the query. It is used to associate this query instance with both the initial response message and with later query interactions. Valuing queryId avoids the need for the QueryContinuation and QueryAck classes to carry as much detail information as is carried in the initial query.
- statusCode - A value specifying the state of this query (based on the RIM Act class state machine), for example, active, aborted, completed.
- modifyCode - Indicates whether the subscription to a query is new or is being modified
- responseElementGroupId - Identifies the specific message type to be returned in the query response. The message type is constrained to the set of message types supported by the receiver responsibilities associated with the query interaction.
- responsePriorityCode - Identifies the time frame in which a response is expected
- executionAndDeliveryTime - Specifies the time the response is to be returned
ParameterList - This collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message must include at least one IdentifiedPersonIdentifier parameter item and may include DataSource parameter items. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic.
- IdentifiedPersonIdentifier - at least one identifier for a person's record in a person registry
- DataSource - the identifier for a data source (system). This supports data locator/aggregator type registries that respond to queries by farming the request out to other registries that hold the requested information.
| Identified Person Event Query By Identifier | PRPA_HD101307UV |
|
Reference
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
Description
The Person Activate payload message is used in state-transition notifications and state-transition requests for adding new records to a person registry.
At this time there is no content for this section.
| Identified Person Event Activate | PRPA_MT101301UV |
|
Description
The Person Revise payload message is used in state-transition notifications and state-transition requests for revising existing records in a person registry.
At this time there is no content for this section.
| Identified Person Event Revise | PRPA_MT101302UV |
|
Description
The Person Nullify payload message is used in the state-transition notification reporting nullification of an erroneously-entered record in a person registry.
At this time there is no content for this section.
| Identified Person Event Nullify | PRPA_MT101305UV |
|
Description
The Person Demographics payload message is used to return a complete or partial record from a person registry in response to a query.
At this time there is no content for this section.
| Identified Person Event Demographics | PRPA_MT101303UV |
|
Description
The Find Candidates Response payload message is used to return records from a person registry in response to a find candidates query. Each record includes an observation reporting how well the record matched the query parameters.
At this time there is no content for this section.
| Identified Person Event Find Candidates Response | PRPA_MT101310UV |
|
Description
The Person Identifiers payload message is used to return all identifiers associated with a record in a person registry in response to a query.
At this time there is no content for this section.
| Identified Person Event Identifiers | PRPA_MT101304UV |
|
Description
The Query By Demographics payload message is used in query-by-parameter messages sent to a person registry when the query placer knows a set of person demographics.
At this time there is no content for this section.
| Identified Person Event Query By Demographics | PRPA_MT101306UV |
|
Description
The Query By Identifier payload message is used in query-by-parameter messages sent to a person registry when the query placer knows a person's registry identifier.
At this time there is no content for this section.
| Identified Person Event Query By Identifier | PRPA_MT101307UV |
|
|
Reference
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
| Structured Name: | Identified Person Event Activate Notification |
A person registry sends this notification after adding a record to the registry.
| Trigger Event | Person Registry Record Added | PRPA_TE101301UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Activate | PRPA_MT101301UV |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
| Structured Name: | Identified Person Event Activate Request |
A user initiates a request to add a record to a person registry.
| Trigger Event | Person Registry Add Request | PRPA_TE101311UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Person Activate | PRPA_MT101301UV |
| Reason | Trigger Event | Interaction |
| A Request Fulfiller application role is responsible for informing a requesting application role if its activation request is accepted. | PRPA_TE101312UV02 | PRPA_IN101312UV02 |
| A Request Fulfiller application role is responsible for informing a requesting application role if its activation request is rejected and why | PRPA_TE101313UV02 | PRPA_IN101313UV02 |
| Sender | Person Registry Request Placer | PRPA_AR101305UV02 |
| Receiver | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Structured Name: | Identified Person Event Activate Confirmation |
A person registry accepts a request to add a record and responds back to the requesting application. The payload contains the identifier assigned to the new person record.
| Trigger Event | Person Registry Add Request Accepted | PRPA_TE101312UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Identifiers | PRPA_MT101304UV |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| Structured Name: | Identified Person Event Activate Rejection |
A person registry rejects a request to add a record and responds back to the requesting application. The reason for the rejection is returned as a Detected Issue in the Master File / Reg Notif. Control Act, Role Subject wrapper. The payload returns the person record sent in the original request.
| Trigger Event | Person Registry Add Request Rejected | PRPA_TE101313UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Activate | PRPA_MT101301UV |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| Structured Name: | Identified Person Event Revise Notification |
| Trigger Event | Person Registry Record Revised | PRPA_TE101302UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Revise | PRPA_MT101302UV |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Revision Tracker | PRPA_AR101307UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
| Structured Name: | Identified Person Event Revise Request |
| Trigger Event | Person Registry Revise Request | PRPA_TE101314UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Person Revise | PRPA_MT101302UV |
| Reason | Trigger Event | Interaction |
| A Request Fulfiller application role is responsible for informing a requesting application role if its revision request is accepted. | PRPA_TE101315UV02 | PRPA_IN101315UV02 |
| A Request Fulfiller application role is responsible for informing a requesting application role if its revision request is rejected and why. | PRPA_TE101316UV02 | PRPA_IN101316UV02 |
| Sender | Person Registry Request Placer | PRPA_AR101305UV02 |
| Receiver | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Structured Name: | Identified Person Event Revise Confirmation |
A person registry accepts a request to revise an existing record and responds back to the requesting application. The revised person record from the registry is returned in the payload.
| Trigger Event | Person Registry Revise Request Accepted | PRPA_TE101315UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Demographics | PRPA_MT101303UV |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| Structured Name: | Identified Person Event Revise Rejection |
| Trigger Event | Person Registry Revise Request Rejected | PRPA_TE101316UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Revise | PRPA_MT101302UV |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| Structured Name: | Identified Person Event Nullify Notification |
A person registry sends this notification after nullifying an erroneously created record in the registry.
| Trigger Event | Person Registry Record Nullified | PRPA_TE101303UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Nullify | PRPA_MT101305UV |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
| Structured Name: | Identified Person Event Obsolete Notification |
A person registry sends this notification after resolving duplicate registrations in the registry. The surviving registration (RegistrationEvent.statusCode = "active") links via the replacementOf act relationship to the deprecated registration (PriorRegistration.statusCode = "obsolete"). A copy of the surviving person record is sent in the payload message.
| Trigger Event | Person Registry Duplicates Resolved | PRPA_TE101304UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Person Demographics | PRPA_MT101303UV |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
| Structured Name: | Identified Person Event Find Candidates Query |
A user initiates a query to a person registry requesting all records that match a particular set of parameters.
| Trigger Event | Person Registry Find Candidates Query | PRPA_TE101305UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Message Type | Person Registry Query By Demographics | PRPA_MT101306UV |
| Reason | Trigger Event | Interaction |
| A Query Fulfiller application role is responsible for responding to queries. | PRPA_TE101306UV02 | PRPA_IN101306UV02 |
| Sender | Person Registry Query Placer | PRPA_AR101303UV02 |
| Receiver | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Structured Name: | Identified Person Event Find Candidates Query Response |
A person registry responds to a query with all records in the registry that match the parameters in the query. The response may also include a score indicating the probability of match for each candidate.
| Trigger Event | Person Registry Find Candidates Query Response | PRPA_TE101306UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 |
| Query Response Type | Person Registry Find Candidates Response | PRPA_MT101310UV |
| Query Definition | Identified Person Event Query By Demographics | PRPA_MT101306UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
| Structured Name: | Identified Person Event Get Demographics Query |
A user initiates a query to a person registry requesting demographic information for a specific person.
| Trigger Event | Person Registry Get Demographics Query | PRPA_TE101307UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Message Type | Person Registry Query By Identifier | PRPA_MT101307UV |
| Reason | Trigger Event | Interaction |
| A Query Fulfiller application role is responsible for responding to queries. | PRPA_TE101308UV02 | PRPA_IN101308UV02 |
| Sender | Person Registry Query Placer | PRPA_AR101303UV02 |
| Receiver | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Structured Name: | Identified Person Event Get Demographics Query Response |
A person registry responds to a query with demographic information in the registry for the person specified in the query.
| Trigger Event | Person Registry Get Demographics Query Response | PRPA_TE101308UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 |
| Query Response Type | Person Demographics | PRPA_MT101303UV |
| Query Definition | Identified Person Event Query By Identifier | PRPA_MT101307UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
| Structured Name: | Identified Person Event Get Identifiers Query |
A user initiates a query to a person registry requesting all identifiers for a specific person.
| Trigger Event | Person Registry Get Identifiers Query | PRPA_TE101309UV02 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Message Type | Person Registry Query By Identifier | PRPA_MT101307UV |
| Reason | Trigger Event | Interaction |
| A Query Fulfiller application role is responsible for responding to queries. | PRPA_TE101310UV02 | PRPA_IN101310UV02 |
| Sender | Person Registry Query Placer | PRPA_AR101303UV02 |
| Receiver | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Structured Name: | Identified Person Event Get Identifiers Query Response |
A person registry responds to a query with all identifiers in the registry for the person specified in the query.
| Trigger Event | Person Registry Get Identifiers Query Response | PRPA_TE101310UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 |
| Query Response Type | Person Identifiers | PRPA_MT101304UV |
| Query Definition | Identified Person Event Query By Identifier | PRPA_MT101307UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
The Patient Administration Person Registry DSTU Update replaces all of the Patient Administration DSTU Person topic. Because some changes made to the underlying information model are not backwards compatible all artifacts have new identifiers. The following tables show which DSTU Update artifacts correspond to which existing DSTU artifacts.
| DSTU Update Storyboard | DSTU Storyboard |
|---|---|
| PRPA_ST101301 - Person Registry Record Added | PRPA_ST101001 - Add New Person |
| PRPA_ST101302 - Person Registry Record Revised | PRPA_ST101002 - Revise Person Information |
| PRPA_ST101303 - Person Registry Record Nullified | PRPA_ST101999 - Nullify Person |
| PRPA_ST101304 - Person Registry Duplicates Resolved | PRPA_ST101004 - Resolve Duplicate Person Registrations |
| PRPA_ST101305 - Person Registry Find Candidates Query | QUPA_ST101002 - Person Registry Find Candidates Query |
| PRPA_ST101307 - Person Registry Get Demographics Query | QUPA_ST101001 - Person Registry Get Demographics Query |
| PRPA_ST101309 - Person Registry Get Identifiers Query | QUPA_ST101003 - Person Registry Find Associated Identifiers Query |
| PRPA_ST101311 - Person Registry Add Request | PRPA_ST101201 - Add New Person Request |
| PRPA_ST101314 - Person Registry Revise Request | PRPA_ST101202 - Revise Person Information Request |
| DSTU Update Application Role | DSTU Application Role |
|---|---|
| PRPA_AR101301 - Person Registry Informer | PRPA_AR101001 - Person Comprehensive Informer |
| PRPA_AR101302 - Person Registry Tracker | PRPA_AR101002 - Person Comprehensive Tracker |
| PRPA_AR101303 - Person Registry Query Placer | QUPA_AR101101 - Person Registry Query Placer |
| PRPA_AR101304 - Person Registry Query Fulfiller | QUPA_AR101102 - Person Registry Query Fulfiller |
| PRPA_AR101305 - Person Registry Request Placer | PRPA_AR101201 - Person Comprehensive Placer |
| PRPA_AR101306 - Person Registry Request Fulfiller | PRPA_AR101202 - Person Comprehensive Fulfiller |
| PRPA_AR101307 - Person Registry Revsion Tracker | PRPA_AR101006 - Person Revision Tracker |
| DSTU Update Trigger Event | DSTU Trigger Event |
|---|---|
| PRPA_TE101301 - Person Registry Record Added | PRPA_TE101001 - New Person Added |
| PRPA_TE101302 - Person Registry Record Revised | PRPA_TE101002 - Person Information Revised |
| PRPA_TE101303 - Person Registry Record Nullified | PRPA_TE101999 - Person Nullified |
| PRPA_TE101304 - Person Registry Duplicates Resolved | PRPA_TE101004 - Duplicate Person Records Resolved |
| PRPA_TE101305 - Person Registry Find Candidates Query | QUPA_TE101103 - Find Candidates Query |
| PRPA_TE101306 - Person Registry Find Candidates Query Response | QUPA_TE101104 - Find Candidates Response |
| PRPA_TE101307 - Person Registry Get Demographics Query | QUPA_TE101101 - Get Person Demographics Query |
| PRPA_TE101308 - Person Registry Get Demographics Query Response | QUPA_TE101102 - Get Person Demographics Response |
| PRPA_TE101309 - Person Registry Get Identifiers Query | QUPA_TE101105 - Find Associated Person Identifiers Query |
| PRPA_TE101310 - Person Registry Get Identifiers Query Response | QUPA_TE101106 - Find Associated Person Identifiers Response |
| PRPA_TE101311 - Person Registry Add Request | PRPA_TE101201 - Add New Person Request |
| PRPA_TE101312 - Person Registry Add Request Accepted | PRPA_TE101202 - Add New Person Request Accepted |
| PRPA_TE101313 - Person Registry Add Request Rejected | PRPA_TE101203 - Add New Person Request Rejected |
| PRPA_TE101314 - Person Registry Revise Request | PRPA_TE101204 - Revise Person Information Request |
| PRPA_TE101315 - Person Registry Revise Request Accepted | PRPA_TE101205 - Revise Person Information Request Accepted |
| PRPA_TE101316 - Person Registry Revise Request Rejected | PRPA_TE101206 - Revise Person Information Request Rejected |
| DSTU Update R-MIM | DSTU R-MIM |
|---|---|
| PRPA_RM101301 - Person Activate | PRPA_RM101001 - New Person |
| PRPA_RM101302 - Person Revise | PRPA_RM101002 - Revised Person |
| PRPA_RM101305 - Person Nullify | PRPA_RM101003 - Nullified Person |
| PRPA_RM101307 - Person Registry Query By Identifier | QUPA_RM101101 - Query By Person Id |
| PRPA_RM101303 - Person Demographics | QUPA_RM101102 - Get Demographics Response |
| PRPA_RM101304 - Person Identifiers | QUPA_RM101106 - Find Associated Ids Response |
| PRPA_RM101306 - Person Registry Query By Demographics | QUPA_RM101103 - Query By Person Demographics |
| PRPA_RM101310 - Person Registry Find Candidates Response | QUPA_RM101104 - Find Candidates Response |
| DSTU Update R-MIM | DSTU R-MIM |
|---|---|
| PRPA_HD101301 - Person Activate | PRPA_HD101001 - New Person |
| PRPA_HD101302 - Person Revise | PRPA_HD101002 - Revised Person |
| PRPA_HD101305 - Person Nullify | PRPA_HD101003 - Nullified Person |
| PRPA_HD101307 - Person Registry Query By Identifier | QUPA_HD101101 - Query By Person Id |
| PRPA_HD101303 - Person Demographics | QUPA_HD101102 - Get Demographics Response |
| PRPA_HD101304 - Person Identifiers | QUPA_HD101106 - Find Associated Ids Response |
| PRPA_HD101306 - Person Registry Query By Demographics | QUPA_HD101103 - Query By Person Demographics |
| PRPA_HD101310 - Person Registry Find Candidates Response | QUPA_HD101104 - Find Candidates Response |
| DSTU Update R-MIM | DSTU R-MIM |
|---|---|
| PRPA_MT101301 - Person Activate | PRPA_MT101001 - New Person |
| PRPA_MT101302 - Person Revise | PRPA_MT101002 - Revised Person |
| PRPA_MT101305 - Person Nullify | PRPA_MT101003 - Nullified Person |
| PRPA_MT101307 - Person Registry Query By Identifier | QUPA_MT101101 - Query By Person Id |
| PRPA_MT101303 - Person Demographics | QUPA_MT101102 - Get Demographics Response |
| PRPA_MT101304 - Person Identifiers | QUPA_MT101106 - Find Associated Ids Response |
| PRPA_MT101306 - Person Registry Query By Demographics | QUPA_MT101103 - Query By Person Demographics |
| PRPA_MT101310 - Person Registry Find Candidates Response | QUPA_MT101104 - Find Candidates Response |
| DSTU Update Interaction | DSTU Interaction |
|---|---|
| PRPA_IN101301 - Person Registry Record Added | PRPA_IN101001 - New Person Added |
| PRPA_IN101302 - Person Registry Record Revised | PRPA_IN101002 - Person Information Revised |
| PRPA_IN101303 - Person Registry Record Nullified | PRPA_IN101003 - Person Nullified |
| PRPA_IN101304 - Person Registry Duplicates Resolved | PRPA_IN101004 - Resolve Duplicate Person Registrations |
| PRPA_IN101305 - Person Registry Find Candidates Query | QUPA_IN101103 - Find Candidates Query |
| PRPA_IN101306 - Person Registry Find Candidates Query Response | QUPA_IN101104 - Find Candidates Response |
| PRPA_IN101307 - Person Registry Get Demographics Query | QUPA_IN101101 - Get Person Demographics Query |
| PRPA_IN101308 - Person Registry Get Demographics Query Response | QUPA_IN101102 - Get Person Demographics Response |
| PRPA_IN101309 - Person Registry Get Identifiers Query | QUPA_IN101105 - Find Associated Identifiers Query |
| PRPA_IN101310 - Person Registry Get Identifiers Query Response | QUPA_IN101106 - Find Associated Identifiers Response |
| PRPA_IN101311 - Person Registry Add Request | PRPA_IN101201 - Add New Person Request |
| PRPA_IN101312 - Person Registry Add Request Accepted | PRPA_IN101202 - Add New Person Request Accepted |
| PRPA_IN101313 - Person Registry Add Request Rejected | PRPA_IN101203 - Add New Person Request Rejected |
| PRPA_IN101314 - Person Registry Revise Request | PRPA_IN101204 - Revise Person Information Request |
| PRPA_IN101315 - Person Registry Revise Request Accepted | PRPA_IN101205 - Revise Person Information Request Accepted |
| PRPA_IN101316 - Person Registry Revise Request Rejected | PRPA_IN101206 - Revise Person Information Request Rejected |
| Return to top of page |