 HL7 PA, R2-2010 HL7 Version 3 Standard: Patient Administration, DSTU Release 2 Update February 2010 Update to DSTU Release 2 |
Content Last Edited: 2011-06-17T13:44:56
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
The Person topic reflects an update that was passed in the 2010May ballot.
The 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 attributes that would likely be collected only for persons in the role of patient -- organDonorInd, educationLevelCode, disabilityCode, religiousAffiliationCode, raceCode and ethnicGroupCode. Those attributes are included in Person within the Patient information model.
HL7v3 describes three interoperability paradigms - messages, structured documents and services. This specification defines information interchanges only for the message paradigm.
Information interchanges can be broadly categorized by the goal of the interchange - notification (no specific receiver responsibility), query (receiver expected to return information meeting query criteria) and action request (receiver expected to take requested action). This specification defines message interchanges 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 work group invites implementers with additional requirements to submit content proposals for future releases of the standard.
The 2010 May DSTU Update included a number of information model changes to the 2009 Sep DSTU Update:
- The Citizen class added the code attribute constrained to CitizenRoleType domain
- The Employee class added the code attribute constrained to EmployeeRoleType domain
- The ContactParty class changed the constraint on the code attribute from ContactRoleType domain to PersonalRelationshipRoleType domain
- The Guardian class added the code attribute constrained to GuardianRoleType domain
- The guardianEntityChoice association from Guardian to EntityChoice was changed from 1..1 to 0..1
- The Member.effectiveTime datatype was changed from IVL<TS> to GTS
- A second Member class was added to support navigation from Group to Person
- A new ObservationEvent class was added with Member as the subjectOf the observation
- A new CareProvisionEvent was added
|
||||||||||||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
| 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.
| 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].
| 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].
| 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].
| 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.
| 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.
| 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.
| 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].
| 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.
|
||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
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.
This application role represents applications that initiate state transition requests to person registries.
This application role represents the responsibility of person registries to respond to state transition requests.
This application role represents the responsibility of person registries to notify systems of state transitions (such as add, revise, nullify) on records it holds.
This application role represents the responsibility to receive state transition notification messages from person registries.
This application role represents applications that initiate queries to person registries.
This application role represents the responsibility of person registries to respond to queries.
|
||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | State-transition based |
| State Transition: | RegistrationEvent (MFMI_RM700700UV01) |
This trigger event signals that a record was added to a person registry.
| Type: | User request |
A source system sends a person record to a person registry with a request to add the record to the registry.
| Type: | Interaction based |
This trigger event signals that a person registry has accepted a request to add a new record.
| Type: | Interaction based |
This trigger event signals that a person registry has rejected a request to add a new record.
| Type: | State-transition based |
| State Transition: | RegistrationEvent (MFMI_RM700700UV01) |
This trigger event signals that a record was revised in a person registry.
| 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.
| Type: | Interaction based |
This trigger event signals that a person registry has accepted a request to revise information it holds for a specified person.
| Type: | Interaction based |
This trigger event signals that a person registry has rejected a request to revise information it holds about a person.
| Type: | State-transition based |
| State Transition: | RegistrationEvent (MFMI_RM700700UV01) |
This trigger event signals that a record was nullified in a person registry.
| Type: | State-transition based |
| State Transition: | PriorRegistration (MFMI_RM700700UV01) |
This trigger event signals that duplicate records were resolved in a person registry.
| Type: | User request |
A user initiates a query to a person registry requesting records that match a set of demographic information.
| 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.
| Type: | User request |
A user initiates a query to a person registry requesting the demographic information the registry has recorded for a specified person.
| 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.
| Type: | User request |
A user initiates a query to a person registry requesting the identifiers the registry has recorded for a specified person.
| 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.
|
||||||||||||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Patient Administration (PRPA_DM000000UV) |
The Person Activate R-MIM defines the payload message used for state-transition requests and notifications for adding new records in a person registry.
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 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.
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 name 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.
PatientCareProvisionEvent
A care provision arrangement whereby a ResponsibleParty agrees to take on whole or partial responsibility for, or attention to, the safety and well-being of the subject. For example, day care or before or after school care. The effectiveTime conveys when the care provision is in effect, for example, "week days from 3:30 pm to 6:00 pm."
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, a code value that can qualify the person's employment relationship (such as paid employee, consultant or volunteer), 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 , a code value that can qualify the person's legal status within the nation (such as non-country member with residence permit or asylum seeker) 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 organizationor household.
ObservationEvent
Observations about a person's living situation in a household, for example, "child resides in father"s household only on weekends because father often travels during the week."
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 conveyed by a specialization of contact (CON), either emergency contact (EMER) or next of kin (NOK). The relationship of the contact person to the focal person, such as spouse or parent, can be conveyed by a code value drawn from the PersonalRelationshipRoleType domain. The telecom attribute is required and mandatory. The statusCode and effectiveTime attributes can differentiate between current and former contacts. 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. The code attribute can qualify the type of guardianship (such as natural guardian, legal guardian, limited guardianship). 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.
| Person Activate | PRPA_HD101301UV02 |
| 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. All other attributes and associations can take on any normally allowed update mode.
| Person Revise | PRPA_HD101302UV02 |
| 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
| Person Nullify | PRPA_HD101305UV02 |
| 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
| Person Demographics | PRPA_HD101303UV02 |
| 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.
| Person Registry Find Candidates Response | PRPA_HD101310UV02 |
| 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
| Person Identifiers | PRPA_HD101304UV02 |
| Parent: | Patient Administration (PRPA_DM000000UV) |
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.
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 PersonBirthPlaceName 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). Typically a query that includes this parameter would not include the PersonDeceased parameter too.
- PersonDeceased - a Boolean (true/false) value. If the value is false, the response is limited to persons that are alive, i.e. Person.deceasedInd equals false and Person.deceasedTime does not have a value. If the value is true, the response is limited to persons that are deceased, i.e. Person.deceasedInd equals true and/or Person.deceasedTime holds a value. If the parameter is omitted, both living and deceased persons are returned based on the other criteria.
- 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).
- GroupId - This is the identifier for a Group of which a person may be a Member. For example a person may belong to an administrative region within a country and that region is not necessarily derivable from the person's postal address.
- 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.
| Person Registry Query By Demographics | PRPA_HD101306UV02 |
| 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.
| Person Registry Query By Identifier | PRPA_HD101307UV02 |
|
||||||||||||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
The Person Activate payload message is used in state-transition notifications and state-transition requests for adding new records to a person registry.
| E_PersonInformational | COCT_MT030207UV07 |
| E_PersonInformational | COCT_MT030207UV07 |
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| E_OrganizationUniversal | COCT_MT150000UV02 |
| E_OrganizationIdentified/confirmable | COCT_MT150002UV01 |
| E_OrganizationInformational | COCT_MT150007UV |
| E_OrganizationInformational | COCT_MT150007UV |
| E_PlaceInformational | COCT_MT710007UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| Person Activate | PRPA_MT101301UV02 | |
The Person Revise payload message is used in state-transition notifications and state-transition requests for revising existing records in a person registry.
| E_PersonInformational | COCT_MT030207UV07 |
| E_PersonInformational | COCT_MT030207UV07 |
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| E_OrganizationUniversal | COCT_MT150000UV02 |
| E_OrganizationIdentified/confirmable | COCT_MT150002UV01 |
| E_OrganizationInformational | COCT_MT150007UV |
| E_OrganizationInformational | COCT_MT150007UV |
| E_PlaceInformational | COCT_MT710007UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| Person Revise | PRPA_MT101302UV02 | |
The Person Nullify payload message is used in the state-transition notification reporting nullification of an erroneously-entered record in a person registry.
| E_OrganizationContact | COCT_MT150003UV03 |
| E_PlaceInformational | COCT_MT710007UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| Person Nullify | PRPA_MT101305UV02 | |
The Person Demographics payload message is used to return a complete or partial record from a person registry in response to a query.
| E_PersonInformational | COCT_MT030207UV07 |
| E_PersonInformational | COCT_MT030207UV07 |
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| E_OrganizationUniversal | COCT_MT150000UV02 |
| E_OrganizationIdentified/confirmable | COCT_MT150002UV01 |
| E_OrganizationInformational | COCT_MT150007UV |
| E_OrganizationInformational | COCT_MT150007UV |
| E_PlaceInformational | COCT_MT710007UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| Person Demographics | PRPA_MT101303UV02 | |
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.
| E_PersonInformational | COCT_MT030207UV07 |
| E_PersonInformational | COCT_MT030207UV07 |
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| E_OrganizationUniversal | COCT_MT150000UV02 |
| E_OrganizationIdentified/confirmable | COCT_MT150002UV01 |
| E_OrganizationInformational | COCT_MT150007UV |
| E_OrganizationInformational | COCT_MT150007UV |
| E_PlaceInformational | COCT_MT710007UV07 |
| A_SpatialCoordinateUniversal | COCT_MT960000UV05 |
| Person Registry Find Candidates Response | PRPA_MT101310UV02 | |
The Person Identifiers payload message is used to return all identifiers associated with a record in a person registry in response to a query.
| E_OrganizationIdentified/confirmable | COCT_MT150002UV01 |
| E_OrganizationContact | COCT_MT150003UV03 |
| E_OrganizationInformational | COCT_MT150007UV |
| Person Identifiers | PRPA_MT101304UV02 | |
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.
| Person Registry Query By Demographics | PRPA_MT101306UV02 | |
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.
| Person Registry Query By Identifier | PRPA_MT101307UV02 | |
|
||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
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_MT101301UV02 |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
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_MT101301UV02 |
| 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 |
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_MT101304UV02 |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
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 Request 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 Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Person Activate | PRPA_MT101301UV02 |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| 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_MT101302UV02 |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
| Receiver | Person Registry Revision Tracker | PRPA_AR101307UV02 |
| 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_MT101302UV02 |
| 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 |
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_MT101303UV02 |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
| Trigger Event | Person Registry Revise Request Rejected | PRPA_TE101316UV02 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Person Revise | PRPA_MT101302UV02 |
| Sender | Person Registry Request Fulfiller | PRPA_AR101306UV02 |
| Receiver | Person Registry Request Placer | PRPA_AR101305UV02 |
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_MT101305UV02 |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
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_MT101303UV02 |
| Sender | Person Registry Informer | PRPA_AR101301UV02 |
| Receiver | Person Registry Tracker | PRPA_AR101302UV02 |
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_MT021001UV |
| Query Definition | Person Registry Query By Demographics | PRPA_MT101306UV02 |
| 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 |
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_MT101310UV02 |
| Query Definition | Person Registry Query By Demographics | PRPA_MT101306UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
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_MT021001UV |
| Query Definition | Person Registry Query By Identifier | PRPA_MT101307UV02 |
| 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 |
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_MT101303UV02 |
| Query Definition | Person Registry Query By Identifier | PRPA_MT101307UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
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_MT021001UV |
| Query Definition | Person Registry Query By Identifier | PRPA_MT101307UV02 |
| 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 |
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_MT101304UV02 |
| Query Definition | Person Registry Query By Identifier | PRPA_MT101307UV02 |
| Sender | Person Registry Query Fulfiller | PRPA_AR101304UV02 |
| Receiver | Person Registry Query Placer | PRPA_AR101303UV02 |
| Return to top of page |