Personnel Management - Organization Registry Topic

ANSI/HL7 V3 PM, R1-2005
HL7 Version 3 Standard: Personnel Management, Release 1
10/28/2005

Content Last Edited: 2010-05-08T12:30:03

3.1  Introduction
3.2  Storyboards
3.3  Application Roles
3.4  Trigger Events
3.5  Refined Message Information Models
3.6  Hierarchical Message Descriptions
3.7  Interactions

The Organization topic area includes all messages related to the management of Organizations including Organization Registries, Repositories and Master File tables. This topic area includes notification, request/response and query/response message environments.

Go To Top

► Storyboards (Sorted by Title)

▼ Storyboards (Sorted by Display Order)

	Add Provider Organization Request (PRPM_ST405000UV01)
	Update Provider Organization Request (PRPM_ST406000UV01)
	Query Provider Organization Details (PRPM_ST407000UV01)
	Hospital Organization Maintenance (PRPM_ST401000UV01)
	Provider Group Maintenance (PRPM_ST402000UV01)
	Organization Registry Notifications (PRPM_ST403000UV01)
	Organization Registry Query (PRPM_ST404000UV01)
	Query Preformatted Report (PRPM_ST408000UV01)

Reference

For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.

Introduction

The following storyboards demonstrate the business processes within an Organization Registry environment. The storyboards are drawn from the HL7-Netherlands and Western Canadian actual implemenations of an Organization Registry as well as expected implementations from other active International Affiliates and the USA.

Purpose

This storyboard demonstrates the addition of a new provider organization in a source system that wants the information added to an organization registry system. The organization registry system will respond with a confirmation including information required by the sender for future interactions with the registry.

Diagram

**Interaction List**
Add Organization Request	PRPM_IN401030UV01
Add Organization Response	PRPM_IN401031UV01

Narrative Example

Introduction:

The jurisdictional provider organization registry system (JPORS) is a centralized source of information about healthcare provider organizations. Data feeds to the JPORS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Pharmacists that use the publish and subscribe services, and query and report capabilities of the JPORS to make their data available to subscribing organizations. Access to the data is governed by contractual agreements between individual sources (who 'own' the data in the JPORS) and consumer organizations.

Story Event:

The College of Pharmacists, a licensing body that is a primary source organization for the JPORS, receives a request from People's Pharmacy for acceptance/License to operate as a registered pharmacy in the Ann Arbour region. The request includes a completed set of information forms and supporting documentation as specified by the College of Pharmacists. People's Pharmacy is accepted to operate and its data entered into the College of Pharmacists's registry database.

A portion of the People's Pharmacy registration information is to be made available to approved consumers of this data via the JPORS system.

Message Flow:

An Add Organization Request (PRPM_IN401030) is sent to the Jurisdictional Provider Organization Registry System describing the pharmacy role for People's Pharmacy in the Ann Arbour region.
The JPORS returns an Add Organization Response (PRPM_IN401031) indicating that the add was accepted and including a number of object identifiers that were created by the system including:
- a unique organization identifier;
- a secondary role identifier (i.e., in addition to the College of Pharmacists license number); and
- instance identifiers for selected data objects (e.g. Notes, Work Locations, Disciplinary actions) that don't already have identifiers supplied by the College of Pharmacists.
The identifiers returned by the JPRS are stored by the College of Pharmacists for use in subsequent transactions (updates, searches) with the JPORS system.

Purpose

This storyboard demonstrates the updating of an organization record in a source system that wants the change reflected in an organization registry system. The organizaiton registry system will respond with a confirmation including information required by the sender for future interactions with the registry.

Diagram

**Interaction List**
Update Organization Request	PRPM_IN403010UV01
Update Organization Response	PRPM_IN403011UV01

Narrative Example

Introduction:

The jurisdictional provider organization registry system (JPORS) is a centralized source of information about healthcare provider organizations. Data feeds to the JPORS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Pharmacists, that use of the publish and subscribe services, and query and report capabilities of the JPORS to make their data available to subscribing organizations. Access to the data is governed by contractual agreements between individual sources (who 'own' the data in the JPORS) and consumer organizations.

Story Event:

The College of Pharmacists, a licensing body that is a primary source organization for the JPORS, receives has received updated contact information (contact person, email, phone) from People's Pharmacy that it wants to add to the JPORS. A record for People's Pharmacy has already been created on the JPORS by the College of Pharmacists using the College of Pharmacists license number as the primary identifier.

A portion of the People's Pharmacy registration information is to be made available to approved consumers of this data via the JPORS system.

Message Flow:

The College of Pharmacists sends an Update Organization Request (PRPM_IN403010) to the JPRS, using the College of Pharmacists license number to identify the target record. The update message describes the contact information that the College of Pharmacists uses to contact People's Pharmacy.
The PRS confirms the id and permissions for the update submitter against its 'source' profiles and sends a response message indicating that the update was successful Update Organization Response (PRPM_IN403011). The response message includes the JPRS' secondary identifier for People's Pharmacy, which the College of Pharmacists has the option of using on subsequent communications to identify People's Pharmacy record, instead of its license number

Purpose

This storyboard is an example of an ad hoc query request for provider organization details from a jurisdictional provider registry system.

Diagram

**Interaction List**
Organization Detail Query	PRPM_IN406010UV01
Organization Detail Query Response	PRPM_IN406110UV01

Narrative Example

Introduction:

The jurisdictional provider organization registry system (JPORS) is a centralized source of information about healthcare provider organizations. Data feeds to the JPORS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Pharmacists, that use of the publish and subscribe services, and query and report capabilities of the JPORS to make their data available to subscribing organizations. Access to the data is governed by contractual agreements between individual sources (who 'own' the data in the JPORS) and consumer organizations.

The Organization Details query is a comprehensive query request that will return any and all registry information about an organization, both current and historical. Details for multiple organizations can retrieved with one query request. To support a broad range of possible uses the query supports many types of input parameters.

Story Event:

Good Health Hospital is a subscriber to the Organization Registry from which it receives routine updates of Pharmacy organization information. The hospital is conducting a study and requires information on Pharmacies. Instead of adding this group of organizations to its registry subscription the hospital decides to run a one-time query and use the results to populate its research database.

Message Flow:

Good Health Hospital sends a Organization Details Query (PRPM_IN406010) to the JPORS. The request specifies that all Pharmacies registered in the past 6 years and operating in the city of Ann Arbor are to be returned in the query results.
The JPORS processes the query request, filters the resulting output according to the hospital's data permissions, and returns the query results Organization Details Query Response (PRPM_IN406110).

Purpose

This storyboard demonstrates the maintenance of an organization masterfile within an acute care hospital environment.

Diagram

**Interaction List**
Add Organization Notification	PRPM_IN401010UV01
Update Organization Notification	PRPM_IN403030UV01
Nullify Organization Notification	PRPM_IN402010UV01

Narrative Example

Introduction

This storyboard demonstrates the maintenance of a cardiology services group within a hospital where the organization information is maintained in a central system and broadcasts the information in notifications to all other hospital systems.

Notification of New Organization

A new cardiology services group is being added to the hospital. The system administrator adds the new cardiology service group, and the system also sends messages to other systems whose organizational masters need to be updated Add Organization Notification (PRPM_IN401010)

Notification of Revision to Organization

Some aspects of the cardiology services are being changed (e.g. phone numbers, etc). The system administrator updates the cardiology service group with these changes, and the system also sends messages to other systems whose organizational masters need to be updated. Update Organization Notification (PRPM_IN403030)

Notification of Suspension of Organization

The telemedicine diagnostic services group of the hospital is having its facilities renovated over the next two weeks, and the group needs to be (temporarily) inactivated within the system, so that no new appointments can be scheduled during that period. The system administrator inactivates the telemedicine diagnostic services group, and the system also sends messages to other systems whose organizational masters need to be updated. Update Organization Notification (PRPM_IN403030)

Notification of Resumption of Suspended Organization

The renovation of the facilities of the telemedicine diagnostic services group of the hospital has been completed, and the group needs to be reactivated within the system, so that new appointments can be scheduled again. The system administrator reactivates the telemedicine diagnostic services group, and the system also sends messages to other systems whose organizational masters need to be updated. Update Organization Notification (PRPM_IN403030)

Notification of Cancellation of Organization

The telemedicine diagnostic services group of the hospital lost its funding before being activated, and the organizational record needs to be deleted from the system. The system administrator deletes the telemedicine diagnostic services group, and the system also sends messages to other systems whose organizational masters need to be updated. As per prior arrangments it is assumed that the recipient systems are aware of the organization being cancelled from prior messages; consequently it is only necessary to send the key identifier information in the message rather than all the information known about the organization. Nullify Identified Organization Notification (PRPM_IN402010)

Purpose

This storyboard demonstrates the maintenance of a provider group as part of a healthcare organization. This maintenance includes the establishment of a new Physician Group, the addition of physicians to the group and the removal of physicians from the group.

Diagram

**Interaction List**
Add Organization Notification	PRPM_IN401010UV01
Update Organization Notification	PRPM_IN403030UV01

Narrative Example

Introduction

This narrative describes the management of a provider group within the Kaiser Permanente environment in the USA. The narrative may differ for other environments or nations.

Establish New Physician Group

The Level Seven HealthCare, Inc. contracts with the DoctorsTogether Physician Group to provide care for its members in SmallCommunity, California. The group's tax ID information is used as Level Seven Healthcare's ID for the group. DoctorsTogether consists of three physicians: Dr. Fay Family, Dr. Flora Fern, and Dr. Karen Kidder. Upon entry of DoctorsTogether in the Provider administration system, a notification is sent to all interested applications that the group is available for referral. DoctorsTogether is granted admission privileges to Level Seven HealthCare's GoodHealth Hospital - Add Organization Notification(PRPM_IN401010 ).

Add Physician Group

The Level Seven HealthCare contracts with a second physician group, The DoctorsApart Physician Group, for members in nearby NextDoorTown. As above, the group's tax ID is used as their identifier. The providers in DoctorsApart include Dr. Flora Fern of DoctorsTogether. Upon entry of DoctorsApart in the Provider administration system, a notification is sent to all interested applications that the group is available for referral - Add Organization Notification (PRPM_IN401010 ). DoctorsApart, since it is not in SmallCommunity, does not have admitting privileges at GoodHealth Hospital.

Remove Physician from Group

Dr. Fern decides to reduce her workload and resigns from the DoctorsTogether physician group while remaining at the DoctorsApart group. Her privileges are adjusted and the physician group information is updated accordingly. Upon entry of DoctorsApart in the Provider administration system, a notification is sent to all interested applications Since Dr Fern is no longer associated with DoctorsTogether, her privileges at GoodHealth Hospital are terminated - Update Organization Notification (PRPM_IN403030 ).

Purpose

This storyboard demonstrates the notification interactions supported by an Organizational Registry system. Interactions include the addtion, revision and deletion of an organization.

Diagram

**Interaction List**
Add Organization Notification	PRPM_IN401010UV01
Update Organization Notification	PRPM_IN403030UV01
Nullify Organization Notification	PRPM_IN402010UV01

Narrative Example

Add Organization

The Good Health Hospital takes over responsibility for 2 regional Nursing Homes. The new organization is called the Good Nursing Home. The systems manager responsible for the organization management system enters the details of the organization into the system Add Organization Notification (PRPM_IN401010 ).

Update Organization

The registration clerk discovers that the address of the Good Nursing Home, one of the partner organizations of the Good Health Hospital, is wrong. He changes the address of the Good Nursing Home Update Organization Notification (PRPM_IN403030).

Delete Organization

The manager responsible for the organization management system discovers that the Good Nursing Home, one of the partner organizations of the Good Health Hospital, has been registered twice. After making sure that the erroneous entry isn't referred to any more by any other item in the various hospital systems he deletes the erroneous entry Nullify Organization Notification (PRPM_IN402010).

Purpose

This storyboard demonstrates the query/response interactions supported by an Organizational Registry system. Interactions include Query Candidates and response and Query details and response.

Diagram

**Interaction List**
Organization Candidate Query	PRPM_IN405010UV01
Organization Candidate Query Response	PRPM_IN405110UV01
Organization Detail Query	PRPM_IN406010UV01
Organization Detail Query Response	PRPM_IN406110UV01

Narrative Example

Organization Registry Find Candidates

Dr. Harold Hippocrates decides to send his discharge note related his patient, Adam Everyman, to his home care organization, Good Home Health. Within his patient record system Dr. Hippocrates enters "Good" and the type of organization. A query is sent to the organization manager system with this qualifying information Organization Candidate Query (PRPM_IN405010). The organization manager system returns a candidate list Organization Candidate Query Response (PRPM_IN405110) allowing Dr. Hippocrates to refine the query for Good Home Health, if desired.

Organization Registry Get Details

Dr. Harold Hippocrates decides to send his discharge note related his patient, Adam Everyman, to his home care organization, Good Home Health. His system displays a list of all organizations whose name starts with "Good".

Dr. Hippocrates selects the correct organization from the list. This triggers a "get organization details" query to the organization manager system Organization Detail Query (PRPM_IN406010). The organization manager system returns Good Home Health's current details Organization Detail Query Response (PRPM_IN406110 ). Dr. Hippocrates uses the contact details of Good Home Health to send the discharge note.

Purpose

This storyboard is an example of query request from a subscribing system for a print-ready report from an organization registry system. The reports are preformatted and consequently the request includes the report identifier.

Diagram

**Interaction List**
Organization Report Query	PRPM_IN406030UV01
Organization Report Query Response	PRPM_IN406031UV01
Organization Administrative Report Query	PRPM_IN406040UV01
Organization Administrative Report Query Response	PRPM_IN406041UV01

Narrative Example

Introduction:

The jurisdictional provider organization registry system (JPORS) is a centralized source of information about healthcare provider organizations. Data feeds to the JPORS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Pharmacists, that use of the publish and subscribe services, and query and report capabilities of the JPORS to make their data available to subscribing organizations. Access to the data is governed by contractual agreements between individual sources (who 'own' the data in the JPORS) and consumer organizations.

The JPORS supports a variety of print-ready organization and usage reports that are run upon request, using a query request mechanism. The registry supports input parameters on the report request and these parameters will vary depending upon the type of report being requested. Output formats are fixed. All of the reports are formatted (e.g. html) for viewing or printing, but cannot be readily parsed. Consequently these reports are not appropriate for subscribers requiring parsable data for loading into their systems. Query reports have a lower priority than standard queries and if a report request is too large it will be processed as a deferred request for later return to the requester. The completed report is returned to the requester as an attached document or may be re-directed to an alternate delivery service such as ftp.

Story Event:

Health Authority West is a subscriber to the Organization registry from which it receives routine updates of Pharmacy information. The Health Authority is conducting a study and requires a summary report of hospital based pharmacies (these organizations are not in the health authority's usual data feed from the registry). A Standard registry report will suffice and will alleviate the need to convert the data into a readable format.

Message Flow:

The Health Authority West sends a Organization Report Query (PRPM_IN406030) to the JPORS. The request specifies that all hospital based pharmacies currently registered in the jurisdiction are to be included and that the report be sorted by name. The Report Identifier Parameter in the query identifies the desired preformatted report as being the "Organiztion Summary" report. The request indicates that the results are to be returned in an HL7 message.
The JPORS responds with an accept acknowledgement to indicate that the query request was received.
That evening the report is created and a standard document transport message Organization Report Query Response (PRPM_IN406031) containing the "Organization Summary" report as an attachment and is sent to the Health Authority West system.

The Health Authority West sends a Organization Report Query (PRPM_IN406030) to the JPRS. The request specifies that all hospital based pharmacies currently registered in the jurisdiction are to be included and that the report be sorted by name. The Report Identifier Parameter in the query identifies the desired preformatted report as being the "Organization Summary" report. The request indicates that the results are to be returned in an HL7 message.
The JPRS responds with an accept acknowledgement to indicate that the query request was received.
That evening the report is created and a standard document transport message Organization Report Query Response (PRPM_IN406031) containing the "Organization Summary" report as an attachment and is sent to the poll queue. The Health Authority West system routinely checks the poll queue for messages and retrieves the report. Refer to the for a discussion of polling.

Narrative Example

Introduction:

The jurisdictional provider organization registry system (JPORS) is a centralized source of information about healthcare provider organizations. Data feeds to the JPORS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Pharmacists, that use of the publish and subscribe services, and query and report capabilities of the JPORS to make their data available to subscribing organizations. Access to the data is governed by contractual agreements between individual sources (who 'own' the data in the JPORS) and consumer organizations.

Query reports have a lower priority than standard queries and if a report request is too large it will be processed as a deferred request for later return to the requester. The completed report is returned to the requester as an attached document or may be re-directed to an alternate delivery service such as ftp.

Story Event:

The College of Pharmacists, a primary data source for organization information to the JPORS is conducting a review of its member services and as part of this review would like to examine the distribution of pharmacies information throughout the country. The college's director of information services requests a report from the JPORS detailing the volume number of organization records retrieved by or distributed to subscribers of the JPORS.

Message Flow:

The College of Pharmacists sends an Organization Administrative Report Query(PRPM_IN406040). The request specifies that all access to College information that has been provided to subscribers either by distribution or in response to queries over the past year be itemized. The Report Identifier Parameter in the query identifies the desired preformatted report as being the "Consumer Usage" report.
The JPORS responds with an accept acknowledgement to indicate that the query request was received.
That evening the report is created and a standard document transport message Organization Administrative Report Query Response (PRPM_IN406041) containing the "Consumer Usage" report as an attachment and is sent to the College system.

The College of Pharmacists sends an Organization Administrative Report Query (PRPM_IN406040). The request specifies that all access to College information that has been provided to subscribers either by distribution or in response to queries over the past year be itemized. The Report Identifier Parameter in the query identifies the desired preformatted report as being the "Consumer Usage" report.
The JPRS responds with an accept acknowledgement to indicate that the query request was received.
That evening the report is created and a standard document transport message Organization Administrative Report Query Response (PRPM_IN406041) containing the "Consumer Usage" report as an attachment and is sent to the poll queue. The College system checks the poll queue for messages the next morning and retrieves the report. Refer to the Infrastructure Management domain, Message Remote Polling Topic for a discussion of polling.

Go To Top

► Application Roles (Sorted by Artifact Code)

▼ Application Roles (Sorted by Display Order)

	Organization Comprehensive Placer (PRPM_AR400003UV01)
	Organization Comprehensive Fulfiller (PRPM_AR400004UV01)
	Organization Comprehensive Informer (PRPM_AR400001UV01)
	Organization Comprehensive Tracker (PRPM_AR400002UV01)
	Organization Comprehensive Query Placer (PRPM_AR400011UV01)
	Organization Comprehensive Query Fulfiller (PRPM_AR400013UV01)

Reference

For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.

Introduction

The Application Roles for the Organization Topic have been created to support the current Organization Registry messaging requirements that have been identified. Additional Application Roles may be added as specific requirements are identified.

Description

An application that is capable of submitting source information about any significant event that is tracked by an Organization Registry.

This application will expect an appropriate response from the Organization Registry system indicating an acknowledgment of the reciept of the information and processing results including necessary identification keys. An example would be a primary or secondary source system for Organization Registry information.

Description

An application that is capable of receiving a request from a Placer application and responding with the appropriate acknowledgment. An example would be an Organization Registry system that is responsible for maintaining a registry of organization information from multiple sources.

Description

An application that is capable of notifying another application about any significant events within an Organization Registry but does not expect any action on the part of the receiver. An example would be an Organization Registry system that is responsible for informing subscriber systems of updates to organization information.

Description

An application that is capable of receiving information about any significant event within an Organization Registry, but is not expected by the SENDER to perform any action.

Description

An application that is capable of sending any Organization Registry Queries to another application, and expects the receiver to take action.

Description

An application that is capable of receiving any Organization Registry Query from a Placer application and responding with the appropriate Query Fulfilment.

Go To Top

► Trigger Events (Sorted by Title)

▼ Trigger Events (Sorted by Display Order)

	Add Organization Confirmation (PRPM_TE401011UV01)
	Add Organization (PRPM_TE401010UV01)
	Activate Organization (PRPM_TE404010UV01)
	Update Organization Confirmation (PRPM_TE403011UV01)
	Update Organization (PRPM_TE403010UV01)
	Suspend Organization (PRPM_TE407010UV01)
	Resume Organization (PRPM_TE407110UV01)
	Terminate Organization (PRPM_TE408010UV01)
	Reactivate Organization (PRPM_TE408110UV01)
	Delete Organization (PRPM_TE402010UV01)
	Organization Administrative Report Query (PRPM_TE406015UV01)
	Organization Administrative Report Query Response (PRPM_TE406115UV01)
	Organization Candidates Query (PRPM_TE405010UV01)
	Organization Candidates Query Response (PRPM_TE405110UV01)
	Organization Details Query (PRPM_TE406010UV01)
	Organization Details Query Response (PRPM_TE406110UV01)
	Organization Report Query (PRPM_TE406014UV01)
	Organization Report Query Response (PRPM_TE406114UV01)

Reference

For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.

Description

Type:

Interaction based

This trigger event happens when the receipt and processing results for an Add Organization Request(PRPM_IN401030) message including necessary identification keys are acknowledged.

Description

Type:

This trigger event happens when an Organization record has been created thus establishing the credentials of the organization within a source system.

Description

Type:

This trigger event happens when an Organization record has been activated.

Description

Type:

Interaction based

This trigger event happens when the receipt and processing results for an Update Organization Request(PRPM_IN403010) message including necessary identification keys are acknowledged.

Description

Type:

This trigger event happens when an Organization record has been revised.

Description

Type:

This trigger event happens when an Organization record has been suspended.

Description

Type:

This trigger event happens when an Organization record has been resumed from a suspended state.

Description

Type:

This trigger event happens when an Organization record has been terminated.

Description

Type:

This trigger event happens when an Organization record has been reactivated from an inactive state.

Description

Type:

This trigger event happens when an Organization record has been nullified.

Description

Type:

User request

This trigger event happens when a user requests a print-ready adminstrative report from an Organization Registry system based on a defined parameter list.

Description

Type:

Interaction based

This query response trigger event happens when an Organization Adminstrative Report Query (PRPM_IN406040) is received and processed.

Description

Type:

User request

This trigger event occurs when a requestor requires a list of organization candidates, based upon a defined list of selection parameters, from an Organization Registry system.

Description

Type:

Interaction based

This query response trigger event happens when an Organization Candidates Query(PRPM_IN405010) is received and processed.

Description

Type:

User request

This trigger event occurs when the requestor requires detailed organization information, based on a defined list of selection parameters, from an Organization Registry system.

Description

Type:

Interaction based

This query response trigger event happens when an Organization Details Query(PRPM_IN406010) is received and successfully processed.

Description

Type:

User request

This trigger event happens when a user requests a print-ready report for an Organization (or multiple organizations) from an Organization registry system based on a defined parameter list.

Description

Type:

Interaction based

This query response trigger event happens when a Organization Report Query (PRPM_IN406030) is received and successfully processed.

Go To Top

► Refined Message Information Models (Sorted by Title)

▼ Refined Message Information Models (Sorted by Display Order)

	Add Organization (PRPM_RM401000UV01)
	Activate Organization (PRPM_RM404000UV01)
	Update Organization (PRPM_RM403000UV01)
	Delete Organization (PRPM_RM402000UV01)
	Organization Admin Report Query (PRPM_RM406600UV01)
	Organization Admin Report Query Response (PRPM_RM406700UV01)
	Organization Candidate Query (PRPM_RM405000UV01)
	Organization Candidate Query Response (PRPM_RM405100UV01)
	Organization Detail Query (PRPM_RM406000UV01)
	Organization Detail Query Response (PRPM_RM406100UV01)
	Organization Report Query (PRPM_RM406200UV01)
	Organization Report Query Response (PRPM_RM406300UV01)
	Organization Confirmation (PRPM_RM409000UV01)

Reference

For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Add Organization R-MIM specifies the information model required to support messaging necessary to report that a new record was added, or should be added, to an Organization registry system.

The Add Organization R-MIM is derived from the Personnel Management D-MIM (PRPM_DM000000); please refer to the documentation of the D-MIM for a detailed walkthrough of the diagram. Following are highlights of the R-MIM and notes of changes or constraints that have been placed on the D-MIM model for this R-MIM.

The entry point to this RMIM is to the RoleChoice box with an additional constraint that messages must start with the AssignedEntity Role.

From the RIM definition, an assigned role is an agent role in which the agent is an Entity acting in the employ of an organization. The focus of this RMIM is on the functional role performed by the organization on behalf of an organization, unlike the Employee role where the focus is on the 'Human Resources' relationship between the employee and the organization. For more information on the Human Resources model please refer to the Human Resource Topic Area within the Personnel Management domain.

The following specific notes apply to the classes in the R-MIM:

PrinicipalOrganization (entity): Identification of playing entity is optional (0..1) to support the case in which information directly related to the playing party is not needed.
AssignedEntity (role): The role class, assigned organization, captures the critical information of the organization playing the role of interest. This includes an identifier for the role, mailing address, phone number, and the time within which the role is played (may be open ended). The scooping organization, which may be omitted if not needed, provides the organizational context for the entity that actually plays the role. For example, the role scoper will normally be the party that assigns the identifier for the role.
LicensedEntity (role): The subject organization may have zero to many Licensed Entity roles. These roles capture information regarding licenses that may be relevant, and that have been issued to the organization. It is also possible to identify the organization that issued the license, i.e., the scoping organization.
Member (role): The subject organization may have zero to many membership roles. Membership captures information regarding the organization's membership in Resource Groups. The vocabulary for the Membership.Code, "MemberRoleType" has been submitted for harmonization but is not currently defined as an HL7 vocabulary domain. The Member role is scoped by a single Resource Group Entity. This entity represents the Membership organization.
OtherRole (role): The subject organization may be known by a variety of identifies from analogous or related roles. The OtherRole class allows these identifiers to be listed as simple references.
QualifiedEntity (role): This role describes specific qualifications that may be held by an Entity (Person, Animal or Device) as a result of training or experience, but having no legal force. Example: a medical degree or diploma. The current model does not include role attributes such as name, addr and telecom because there are no known use cases in this domain where this role is 'contactable'.
LanguageCommunication: This class models the language information for the subject organization. LanguageCode has been made mandatory in this model.

The following constraints have been placed on the original D-MIM in the formation of this R-MIM:

ActDefinitionOrEvent: effective time constrained from GTS to TS; moodCode constrained to DEF.
Affiliate: effectiveTime and code constrained from 0..1 to 1..1
ContactParty: Constrain added - Addr, Telecom or contactPerson must be non-null.
ContactPerson: Constrain added - Either name or played role must be non-null
DisiplinaryAction: confidentiality constrained from SET<CE> 0..* to CE 0..1
InformDefintion: negationInd and effectiveTime constrained from 0..1 to 1..1; effectiveTime constrained from GTS to TS
InformRequest.Subject: moodCode constrained from 0..1 to 1..1
InformRequest: code constrained from 0..1 to 1..1
Jurisdiction: code constrained from 0..1 to 1..1
LanguageCommunication: languageCode constrained from optional to mandatory.
Note: text and effectiveTime constrained to 1..1 Place: name constrained from BAG<EN> 0..1 to EN 1..1
PrincipalOrganization: name constrained from BAG to LIST
Privilege: effective time constrained from 0..1 to 1..1
PrivilegeCategorization: code and value constrained from 0..1 to 1..1
QualifiedEntity: effectiveTime and code constrained from 0..1 to 1..1
RoleActivation: moodCode constrined to EVN
SubjectOf2: Blocked path from Act to Role.
TerritorialAuthority: code constrained from 0..1 to 1..1

Audit enabled on all Addr and Telecom attributes throughout the R-MIM.

Contained Hierarchical Message Descriptions
Add Organization	PRPM_HD401010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Activate Organization R-MIM specifies the information model required to support messaging necessary to indicate that a record was activated, or should be activated, to an Organization registry system.

This R-MIM consists of an entry point to the AssignedOrganization Role. This role includes the required id and code attributes that are used to identify the organization to be activated. The optional effectiveTime and certificateText may also be included allowing for the communication of the time that the activation is effective and any certificates/licenses that may be necessary.

The AssignedOrganization role is played by the assignee drawn from the PrincipalChoice choice box and constrained to be an organization with only an optional name attribute. The scoper is defined using the E_Organization [universal] CMET.

The following element changes have been made from the D-MIM:

AssignedEntity class renamed to AssignedOrganization.
AssignedOrganization.Id changed to required to ensure that organization to be activated is identified appropriately.
AssignedOrganization.code changed to required to ensure that the role in the organization to be activated is identified appropriately.

Contained Hierarchical Message Descriptions
Activate Organization	PRPM_HD404010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Update Organization R-MIM specifies the information model required to support messaging necessary to report that a record was updated, or should be updated, within an Organization registry system.

Except where noted below, this R-MIM is the same as described in the Add Organization R-MIM (PRPM_RM401000) walkthrough.

Differences from Add Organization R-MIM:

none

Contained Hierarchical Message Descriptions
Update Organization	PRPM_HD403010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Delete Organization R-MIM specifies the information model required to support messaging necessary to indicate that a record was deleted/ nullified, or should be deleted/nullified, to an Organization registry system.

This R-MIM consists of an entry point to the AssignedOrganization Role. This role includes the required id and code attributes that are used to identify the organization to be deleted. The optional addr, telecom, effectiveTime and certificateText may also be included allowing for the communication of the post-deletion address and telophone information as well as the time that the deletion is effective and any certificates/licenses that may be necessary.

The AssignedOrganization role is played by the assignee drawn from the PrincipalChoice choice box and constrained to be an organization with a required name attribute. The name is changed to required to ensure that the organization to be delted is identified appropriately.

The scoper is defined using the E_Organization [contact] CMET.

The following element changes have been made from the D-MIM:

AssignedEntity class renamed to AssignedOrganization.
AssignedOrganization.Id changed to required to ensure that organization to be activated is identified appropriately.
AssignedOrganization.code changed to required to ensure that the role in the organization to be activated is identified appropriately.
Unnecessary attributes removed from classes.

Contained Hierarchical Message Descriptions
Delete Organization	PRPM_HD402010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Administrative Report Query R-MIM specifies the information model required to support submitting a query to an organization registry system for preformatted administrative report.

This query supports specifying the SortControl allowing the query to request a response sorted by a specific element name and direction (e.g. alphabetical or reverse alphabetical). The ControlActProcess class is only included in the R-MIM because it is required by tooling. It is not used by this query.

The Administrative Report Query includes a parameter to specify the precise preformatted report that is being requested as well as parameters to filter the type of information included in the report and sort criteria etc. This query contains the following input parameters:

Audit: This is fulfiller-supported audit attributes, specifying name-value pairs for each parameter for which the query is searching.
For Example: CustodianId:123, dbCommitDate:01252005, InactiveRecords:True.
CustodianId: The identity of the custodian for which the query is searching. The custodian is the person identified as responsible for the management of the source data within the owning organization
Jurisdiction: The jurisdiction in which the provider is licenced/registered for which the query is searching. Note that in the response model this is deemed to be the jurisdiction of the role scoper. A maximum number of one jurisdiction may be specified.
OrganizationId: This is the identifier for the organization for which the query is searching. Multiple id's can be specified through repetition of this parameter.
ReportId: This is the published identifier for the preformatted report for which the query is searching. It is a mandatory parameter as the value will be used by the recipient to identify the report being requested.
RoleEffectiveDate: This is the interval of role effective dates/times for which the query is searching.
RoleType: This is one or more role types for which the query is searching. This parameter is constrained to values from the HealthCareProviderRoleType and AssignedEntityRoleType vocabulary domains.
TransactionType: This contains the type of transaction for which the query is searching. It is used to request an adminstrative report for transaction volumes of a particular type. Examples include: Query transactions, Notification transactions or Request transactions.

Contained Hierarchical Message Descriptions
Organization Admin Report Query	PRPM_HD406610UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Administrative Report Query Response R-MIM specifies the information model required to support responding to a Administrative Report Query. This R-MIM, and messages derived from it, should be used only to exchange preformatted reports such as those ready for printing. It should not be used to exchange discrete data elements or dynamically formatted reports where there are other more appropriate query/response messages.

This R-MIM consists of an entry point to the DocumentEvent Act class. This class represents the Documentation event and as such as a fixed classCode of "DOC" that is required and a mandatory moodCode of "EVN".

Additionally, the class contains the optional elements as follows:

id: The identification of the attached report
code: The code indicating the type of report
text: The apyload content; either represented inline or by reference to the Message.;attachmentText.
confidentialityCode: The code identifying the level of confidentiality that should be applied to the document as drawn from the Confidentiality vocabulary.

Contained Hierarchical Message Descriptions
OrganizationAdminReportQueryResponse	PRPM_HD406710UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Candidate Query R-MIM specifies the information model required to support submitting a query to an organization registry system for a list of candidate organizations.

This query supports specifying the SortControl allowing the query to request a response sorted by a specific element name and direction (e.g. alphabetical or reverse alphabetical).

The ControlActProcess class is only included in the R-MIM because it is required by tooling. It is not used by this query.

The Organization Candidate query includes parameters to filter the list of candidate organizations that is returned in the response. This query contains the following parameter items:

OrganizationAddress: The address of the organization for which the query is searching. Searches for partial addresses are supported through use of appropriate AddressPartType, within the AD datatype, as well as address fragments (by site agreement).
OrganizationName: This is the name of the organization for which the query is searching. Searches for partial names are supported through use of appropriate EntityNameParts, within the EN datatype, as well as name fragments (by site agreement).

Contained Hierarchical Message Descriptions
Organization Event Candidate Query	PRPM_HD405010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Candidate Query Response R-MIM specifies the information model required to support responding to an Organization Candidate Query.

The entry point for this R-MIM is throught he AssignedEntity role class. This class is used to describe the candidate organizations that are being returned in response to the query. Each candidate organization has a required id and code element to identify and describe (in coded format) the role of the organization. Additionally the name, addr and telecom elements allow for the inclusion of the organization's address and telecommunication information to assist in differentiating the candidate organizations.

The AssignedEntity role class is played by the PrincipalOrganization, a constrined choice from the PrinicpalChoiceList in the DMIM. This class includes the required name element to support the inclusion of the candidate organization's name in the query response.

The AssignedEntity role is scoped by the E_Organization [contact] CMET allowing for the communication of the contact information of the represented organization.

Contained Hierarchical Message Descriptions
Organization Event Candidate Query Response	PRPM_HD405110UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Detail Query R-MIM specifies the information model required to support submitting a query to an organization registry system for detailed organization information. This query allows details for multiple organizations to be retrieved with one query request.

The ControlActProcess class is only included in the R-MIM because it is required by tooling. It is not used by this query.

This query supports specifying the SortControl allowing the query to request a response sorted by a specific element name and direction (e.g. alphabetical or reverse alphabetical)

The Organization Detail query is a comprehensive query request that supports a range of possible uses via input parameters. This query contains the following input parameters:

Audit: This is fulfiller-supported audit attributes, specifying name-value pairs for each parameter for which the query is searching.
For Example: CustodianId:123, dbCommitDate:01252005, InactiveRecords:True.
Confidence: The confidence level, expressed as an integer, that indicates the degree of certainty with which the returned records match the supplied search criterion. Primarily of use for applications that support probabilistic matching.
History: This is a Boolean (Yes/No) output parameter to indicate whether historical records should be included in the query response.
Jurisdiction: The jurisdiction in which the provider is licenced/registered for which the query is searching. Note that in the response model this is deemed to be the jurisdiction of the role scoper. A maximum number of one jurisdiction may be specified.
OrganizationAddress: The address of the organization for which the query is searching. Searches for partial addresses are supported through use of appropriate AddressPartType, within the AD datatype, as well as address fragments (by site agreement).
OrganizationId: This is the identifier for the organization for which the query is searching. Multiple id's can be specified through repetition of this parameter.
OrganizationName: This is the name of the organization for which the query is searching. Searches for partial names are supported through use of appropriate EntityNameParts, within the EN datatype, as well as name fragments (by site agreement).
Qualification: This is the qualification of the providers for which the query is searching. ReportId: This is the published identifier for the preformatted report for which the query is searching. It is a mandatory parameter as the value will be used by the recipient to identify the report being requested.
ResponseObject: This is an optional output control parameter. Sender indicates via coded values which class or class attributes in the response model are to be valued in the response. By site agreement codes can be based upon local object model, or alternatively, the classes and attributes from the query response model, as in the example below. Example: requestor wants provider identifier, name and service delivery location data returned so ResponseObject is valued as follows:
<ResponseObject><value code="HealthCareProvider.id"/></ResponseObject>

<ResponseObject><value code="PrincipalPerson.name"/></ResponseObject>

<ResponseObject><value code="ServiceDeliveryLocation"/></ResponseObject>
RoleEffectiveDate: This is the interval of role effective dates/times for which the query is searching.
RoleType: This is one or more role types for which the query is searching. This parameter is constrained to values from the HealthCareProviderRoleType and AssignedEntityRoleType vocabulary domains.
RoutedDocType: This is the code for the type of document that is the subject of an Inform Request for which the query is searching. For example: Xray, Chart etc.
sdlcAddress: This is the Service Delivery Location address for which the query is searching. Searches for partial addresses are supported through use of appropriate AddressPartType, within the AD datatype, as well as address fragments (by site agreement).
sdlcld: This is the Service Delivery Location Identifier for which the query is searching.
sdlcType: This is the Service Delivery Location type for which the query is searching. For example: Clinic, Hospital etc.
Status: This is a Role Status (coded per role state machine) for the selected role class and type for which the query is searching.
Telecom: This is the telecommunication information (e.g. telphone number, email etc) for which the query is searching.

Contained Hierarchical Message Descriptions
Organization Detail Query	PRPM_HD406010UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Detail Query Response R-MIM specifies the information model required to support responding to an Organization Detail Query(PRPM_RM406000).

Except where noted below, this R-MIM is the same as described in the Add Organization R-MIM(PRPM_RM401000) walkthrough.

Differences from Add Organization R-MIM:

none

Contained Hierarchical Message Descriptions
Organization Details Query Response	PRPM_HD406110UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Report Query R-MIM specifies the information model required to support submitting a query to an organization registry system for preformatted organization report.

This query supports specifying the SortControl allowing the query to request a response sorted by a specific element name and direction (e.g. alphabetical or reverse alphabetical). This parameter is also mandatory and at least one must be provided.

The ControlActProcess class is only included in the R-MIM because it is required by tooling. It is not used by this query.

The Organization Report Query includes a parameter to specify the precise preformatted report that is being requested as well as parameters to filter the type of organizations included in the report and sort criteria etc. This query contains the following input parameters:

Audit: This is fulfiller-supported audit attributes, specifying name-value pairs for each parameter for which the query is searching.
For Example: CustodianId:123, dbCommitDate:01252005, InactiveRecords:True.
Confidence: The confidence level, expressed as an integer, that indicates the degree of certainty with which the returned records match the supplied search criterion. Primarily of use for applications that support probabilistic matching.
History: This is a Boolean (Yes/No) output parameter to indicate whether historical records should be included in the query response.
Jurisdiction: The jurisdiction in which the provider is licenced/registered for which the query is searching. Note that in the response model this is deemed to be the jurisdiction of the role scoper. A maximum number of one jurisdiction may be specified.
OrganizationAddress: The address of the organization for which the query is searching. Searches for partial addresses are supported through use of appropriate AddressPartType, within the AD datatype, as well as address fragments (by site agreement).
OrganizationId: This is the identifier for the organization for which the query is searching. Multiple id's can be specified through repetition of this parameter.
OrganizationName: This is the name of the organization for which the query is searching. Searches for partial names are supported through use of appropriate EntityNameParts, within the EN datatype, as well as name fragments (by site agreement).
Qualification: This is the qualification of the providers for which the query is searching.
ReportId: This is the published identifier for the preformatted report for which the query is searching. It is a mandatory parameter as the value will be used by the recipient to identify the report being requested.
ResponseObject: This is an optional output control parameter. Sender indicates via coded values which class or class attributes in the response model are to be valued in the response. By site agreement codes can be based upon local object model, or alternatively, the classes and attributes from the query response model, as in the example below. Example: requestor wants provider identifier, name and service delivery location data returned so ResponseObject is valued as follows:
<ResponseObject><value code="HealthCareProvider.id"/></ResponseObject> <ResponseObject><value code="PrincipalPerson.name"/></ResponseObject> <ResponseObject><value code="ServiceDeliveryLocation"/></ResponseObject>
RoleEffectiveDate: This is the interval of role effective dates/times for which the query is searching.
RoleType: This is one or more role types for which the query is searching. This parameter is constrained to values from the HealthCareProviderRoleType and AssignedEntityRoleType vocabulary domains.
sdlcAddress: This is the Service Delivery Location address for which the query is searching. Searches for partial addresses are supported through use of appropriate AddressPartType, within the AD datatype, as well as address fragments (by site agreement).
sdlcType: This is the Service Delivery Location type for which the query is searching. For example: Clinic, Hospital etc.
Status: This is a Role Status (coded per role state machine) for the selected role class and type for which the query is searching.
Telecom: This is the telecommunication information (e.g. telphone number, email etc) for which the query is searching.

Contained Hierarchical Message Descriptions
Organization Report Query	PRPM_HD406210UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Report Query Response R-MIM specifies the information model required to support responding to a Organization Report Query.

This R-MIM, and messages derived from it, should be used only to exchange preformatted reports such as those ready for printing. It should not be used to exchange discrete data elements or dynamically formatted reports where there are other more appropriate query/response messages.

id: The identification of the attached report
code: The code indicating the type of report
text: The payload content; either represented inline or by reference to the Message.attachmentText.
confidentialityCode: The code identifying the level of confidentiality that should be applied to the document as drawn from the Confidentiality vocabulary.

Contained Hierarchical Message Descriptions
OrganizationReportQueryResponse	PRPM_HD406310UV01

Diagram

Parent:

Personnel Management (PRPM_DM000000UV)

Description

The Organization Response R-MIM specifies the information model required to support responding to any fulfillment request message regarding an organization record.

Contained Hierarchical Message Descriptions
Organization Response	PRPM_HD409010UV01

Go To Top

► Hierarchical Message Descriptions (Sorted by Title)

▼ Hierarchical Message Descriptions (Sorted by Display Order)

	Add Organization (PRPM_HD401010UV01)
	Activate Organization (PRPM_HD404010UV01)
	Update Organization (PRPM_HD403010UV01)
	Delete Organization (PRPM_HD402010UV01)
	Organization Admin Report Query (PRPM_HD406610UV01)
	Organization Admin Report Query Response (PRPM_HD406710UV01)
	Organization Candidate Query (PRPM_HD405010UV01)
	Organization Candidate Query Response (PRPM_HD405110UV01)
	Organization Detail Query (PRPM_HD406010UV01)
	Organization Detail Query Response (PRPM_HD406110UV01)
	Organization Report Query (PRPM_HD406210UV01)
	Organization Report Query Response (PRPM_HD406310UV01)
	Organization Confirmation (PRPM_HD409010UV01)

Reference

For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.

Description

The Add Organization HMD specifies the information model required to support messaging necessary to report that a new record was added, or should be added, to an Organization registry system.