 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
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 Provider Topic describes the activities associated with registering an individual health care practitioner or care giver in a Master File or registry environment. This topic area includes notification, request/response and query/response message environments.
|
||||||||||||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
The storyboards provided for comment in this section are taken from provider registry projects in Canada, and also reflects similar projects in the USA.
This storyboard demonstrates the addition of a new provider in a source system that wants the information added to a provider registry system. The provider registry system will respond with a confirmation including information required by the sender for future interactions with the registry.
| Add Provider Request |  PRPM_IN301010UV01 |
| Add Provider Response | PRPM_IN301011UV01 |
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers. Data feeds to the JPRS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Physicians, that make use of the publish and subscribe services, and query and report capabilities of the JPRS 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 JPRS) and consumer organizations.
Story Event:The College of Physicians, a licensing body that is a primary source organization for the JPRS, receives a request from Karen Kidder for acceptance/License to practice as a physician with a specialty in Pediatrics. The request includes a completed set of information forms and supporting documentation as specified by the College. Dr. Kidder is accepted to practice and her data is entered into the College's registry database.
A portion of Dr. Kidder's registration information is to be made available to approved subscribers of this data via the JPRS system.
Message Flow:- An Add Provider Request (PRPM_IN301010) is sent to the Jurisdictional Provider Registry System describing the Physician role for Dr. Karen Kidder, MD. with a specialty in Pediatrics.
- The JPRS returns an Add Provider Response (PRPM_IN301011)
indicating that the add was accepted and including a number of object identifiers that were created by the system including:
- a unique person identifier;
- a unique role identifier (i.e., in addition to the College 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.
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
Story Event:Several Health Authorities are collaborating to contribute data to the provider registry about Paramedics working in the Region.
Eric Emergency was graduated as a qualified nurse and his credentials were submitted to the JPRS by the Registered Nurse Association. Unable to find employment as a nurse, Eric obtained the certification of Emergency Medical Attendant and sought employment in this field.
Health Authority West has hired Eric Emergency as a part-time paramedic and has information about his Emergency Medical Attendant certification from documentation supplied to its employment office by the College of Paramedics. This information, along with Eric's employment details are submitted to the JPRS.
Health Authority East subsequently also hires Eric Emergency as a part-time paramedic and submits his Emergency Medical Attendant certification documentation to the JPRS along with his employment details.
Message Flow:- Registered Nurse Association sends an Add Provider Request (PRPM_IN301010) to the JPRS describing the Nurse role of Eric Emergency.
- The JPRS returns an Add Provider Response (PRPM_IN301011) indicating that the addition was accepted and including a number of object identifiers that were created by the system.
- Health Authority West sends an Add Provider Request (PRPM_IN301010) to the JPRS describing the Paramedic role of Eric Emergency, along with his employment related information (id and job title) in the health authority.
- The JPRS returns a processing results message Add Provider Response (PRPM_IN301011)indicating that a new Provider role has been created (Although it's not indicated in the response message, the new role has been associated with an existing record for Eric Emergency, as he is already present in the JPRS under his former role as a nurse.) The response includes the JPRS-created unique identifier for this role and the previously-created JPRS person identifier. Health Authority West stores these identifiers in case they need to supply future updates to the registry.
- Health Authority East sends an Add Provider Request (PRPM_IN301010) to the JPRS describing the Paramedic role of Eric Emergency, along with his employment related information (id and job title) in the health authority.
- The JPRS returns a processing results message Add Provider Response (PRPM_IN301011) indicating that an existing Provider record was found for Eric Emergency and the new employment information has been added to this record. The response includes the JPRS-created secondary identifier for this role and a JPRS-created person identifier. Health Authority East stores these identifiers in case they need to supply future updates to the registry.
This storyboard is an example of a general distribution from a provider registry system to subscriber organizations based on subscriber profiled requirements.
| Add Provider Notification | PRPM_IN301030UV01 |
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
The JPRS provides a distribution service so that regulatory bodies (like the College of Physicians) and other 'source' organizations can make their information about healthcare providers available to approved subscriber organizations. Add and update requests are sent from the source organizations to the registry and the registry propagates the information to subscribers. A registry-created record set of all new Add and/or Update notifications is distributed to subscribers by various mechanisms that include messaging.
Distributions are managed within the registry by subscriber distribution profiles that define the message content. An important feature of the profiles is that they regulate what data goes to whom. Subscriptions are governed by contractual agreements between source and subscribing organizations. Sources may choose to limit the kinds of data sent to different subscriber organizations.
Story Event:The JPRS receives a message from the College of Physicians, a primary source, containing a notification that Dr. Trudy Tumor has been licensed to practice as a physician with a specialty of Oncology. The Medical Services Plan (an insurer) and the Cancer Agency both subscribe to the JPRS to receive updates originating with the College. The College has specified that the Cancer Agency receive only notification regarding physicians with Oncology qualifications.
Message Flow:-
When the College's updates have been committed to the registry the JPRS immediately sends an Add Provider Notification (PRPM_IN301030) to MSP. Because Dr. Tumor is certified as an oncologist a similar notification is also sent to the Cancer Agency.
This storyboard demonstrates the updating of a provider record in a source system that wants the change reflected in a provider registry system. The provider registry system will respond with a confirmation including information required by the sender for future interactions with the registry.
| Update Provider Request | PRPM_IN303010UV01 |
| Update Provider Response | PRPM_IN303011UV01 |
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
Story Event:The College of Physicians, a primary source for the Jurisdictional Provider Registry System (JPRS), has received contact information (email, phone and fax) for Dr Hippocrates, MD that it wants to add to the JPRS. A record for Harold Hippocrates, and the role of Physician has already been created on the JPRS by the College, using the College's physician license number as the primary identifier.
Message Flow:- The College sends an Update Provider Request (PRPM_IN303010) to the JPRS, using the College's license number to identify the target record. The update message describes the telecommunication information that the College uses to contact Harold Hippocrates, Physician. (Dr. Hippocrates has separate contact numbers for each of his practice locations but these are not tracked by the College.)
- The JPRS confirms the id and permissions for the update submitter against its 'source' profiles and sends an Update Provider Response (PRPM_IN303011) indicating that the update was successful. The response message includes the JPRS' secondary identifier for Dr Hippocrates' Physician role, which the College has the option of using on subsequent communications to identify Dr. Hippocrates' record, instead of his license number.
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
Subscribers of the JPRS require ancillary information about health care practitioners that is not available from the regulatory bodies, but can be supplied by secondary sources. To support the requirements of these clients the JPRS accepts data from secondary sources which it stores as a separate dataset but also logically links to pre-existing Provider role information (as supplied by a primary source). Permission to create the links between the datasets is governed by agreements between the primary source (that 'owns' the healthcare provider role record) and the secondary source(s).
Story Event:
Several Health Authorities are collaborating to contribute data to the provider registry about Paramedics working in the Region.
Health Authority West had previously hired Eric Emergency as a part-time paramedic and had submitted information about his Emergency Medical Attendant certification to the JPRS. Eric Emergency recently completed an upgrade to his Emergency Medical Attendant certification. Qualifying for the upgrade, and having impressed his management with good judgment during an emergency, his position has changed to full time with additional responsibilities and privileges. Health Authority West submits the updated certification information and employment changes to the JPRS.
Message Flow:
-
The Health Authority West sends an Update Provider Request (PRPM_IN303010) to the JPRS, using a secondary identifier (a practitioner number already known to the JPRS) to identify the target provider record in the JPRS. The message describes the additional qualifications along with the change in employment conditions, responsibilities and privileges.
-
The JPRS returns a processing results message indicating that the update was successful Update Provider Response (PRPM_IN303011) .
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
Subscribers of the JPRS require ancillary information about health care practitioners that is not available from the regulatory bodies, but can be supplied by secondary sources. To support the requirements of these clients the JPRS accepts data from secondary sources which it stores as a separate dataset but also logically links to pre-existing Provider role information (as supplied by a primary source). Permission to create the links between the datasets is governed by agreements between the primary source (that 'owns' the healthcare provider role record) and the secondary source(s).
Story Event:
The Cancer Agency, a secondary source for the JPRS, has work location information for Dr. Tumor, MD that it wants to make available to JPRS clients in conjunction with Dr. Tumor's Physician (role) data. A provider role record for Trudy Tumor, Physician, has already been created on the JPRS by the College of Physicians. The College, as owner of the record, has given permission for the Cancer Agency to attach its ancillary information to the physician role record for Dr. Tumor.
Message Flow:
- The Cancer Agency sends an Update Provider Request (PRPM_IN303010) to the JPRS, using a secondary identifier (a practitioner number already known to the JPRS) to identify the target physician record to which the data is being attached. The message describes three service locations at which Dr. Tumor practices and the kinds of service she performs at each (that is of interest to the Cancer Agency).
- The JPRS returns a processing results message Update Provider Response (PRPM_IN303011) indicating that the update was successful. The response includes JPRS-generated Instance identifiers for each of the newly recorded work locations. These are stored by the Cancer Agency in case they need to supply future updates for these particular data objects.
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
Subscribers of the JPRS require ancillary information about health care practitioners that is not available from the regulatory bodies, but can be supplied by secondary sources. To support the requirements of these clients the JPRS accepts data from secondary sources which it stores as a separate dataset but also logically links to pre-existing Provider role information (as supplied by a primary source). Permission to create the links between the datasets is governed by agreements between the primary source (that 'owns' the healthcare provider role record) and the secondary source(s).
Story Event:
Dr. Tumor has started working at a new clinic recently opened by the Cancer Agency along with additional job responsibilities as part of a promotion within the organization. She is also enjoying a larger administration office at the Cancer Agency headquarters. The Cancer Agency, a secondary source for the JPRS, maintains work location information for Dr Tumor, MD that is linked on the Jurisdictional Provider Registry System (JPRS) to Dr. Tumor's Physician (role) data. The Cancer Agency has sole control of this work location data and wants to now supply updates to data it sent to the JPRS previously.
Message Flow:
- The Cancer Agency sends an Update Provider Request (PRPM_IN303010)
to the JPRS, using a secondary identifier (a practitioner number already known to the JPRS) to identify the target physician
record in the JPRS. The message describes the two work locations, the administrative office location that is being updated
and the new clinic location. The former is identified by a unique object identifier, previously created by the JPRS, and includes
a complete set of location data that reflects recent changes to the phone number for that work site.
- The JPRS applies updates to an identified work location in 'snapshot' mode but requires the work location unique object identifier.
- The new work location is also described in the message but does not have an assigned unique object identifier - this will be supplied by the JPRS once the entry is created.
- The JPRS returns a processing results message indicating that the update was successful Update Provider Response (PRPM_IN303011) . The response returns a JPRS-generated unique object identifier for the new work location.
This storyboard is an example of a general distribution from a provider registry system to subscriber organizations based on subscriber profiled requirements.
| Update Provider Notification | PRPM_IN303030UV01 |
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. These authoritative Primary sources typically maintain the system of record for the health care provider roles that they regulate. Primary sources may also be employer organizations that have ongoing relationships with individual practitioners and can (collaboratively) supply role information about them to the JPRS in the absence of an authoritative primary source. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
The JPRS provides a distribution service so that regulatory bodies (like the College of Physicians) and other 'source' organizations can make their information about healthcare providers available to approved subscriber organizations. Add and update requests are sent from the source organizations to the registry and the registry propagates the information to subscribers. A registry-created record set of all new Add and/or Update notifications is distributed to subscribers by various mechanisms that include messaging.
Distributions are managed within the registry by subscriber distribution profiles that define the message content. An important feature of the profiles is that they regulate what data goes to whom. Subscriptions are governed by contractual agreements between source and subscribing organizations. Sources may choose to limit the kinds of data sent to different subscriber organizations.
Story Event:
The JPRS receives an update message from the College of Physicians, a primary source, containing changes to the role record of Dr. Trudy Tumor, Physician. The Medical Services Plan (an insurer) and the Cancer Agency both subscribe to the JPRS to receive updates originating with the College. The College has specified that the Cancer Agency receive only notification regarding physicians with Oncology qualifications.
Message Flow:
- When the College's updates have been committed to the registry the JPRS immediately sends an Update Provider Notification (PRPM_IN303030) to MSP. Because Dr. Tumor is certified as an oncologist a similar notification is also sent to the Cancer Agency.
This storyboard is an example of an ad hoc query request for provider details from a provider registry system.
| Provider Details Query | PRPM_IN306010UV01 |
| Provider Details Query Response | PRPM_IN306011UV01 |
Introduction:
Introduction: The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
The JPRS provides a distribution service so that regulatory bodies (like the College of Physicians) and other 'source' organizations can make their information about healthcare providers available to approved subscriber organizations. Add and update notifications are sent from the source organizations to the JPRS and, on a pre-determined schedule, the registry propagates the information to subscribers based on the subscriber distribution profiles. Subscriptions are governed by contractual agreements between source and subscribing organizations. Sources may choose to limit the kinds of data sent to different subscriber organizations and subscribers may choose to limit the kinds of data that they receive.
Queries are an additional mechanism by which this information can be retrieved from the JPRS by subscriber organizations. Access to information by query is also governed by subscriber profiles.
The Provider Details query is a comprehensive query request that will return any and all registry information about a provider, both current and historical. To support a broad range of possible uses the query supports many types of input parameters. This allows details for multiple providers to be retrieved with one query request as well as the filtering to specify the type of provider information to be included in the response. The requestor may also ask for the inclusion of transaction history of a provider record in the JPRS as part of the response.
Story Event:
Good Health Hospital is a subscriber to the JPRS from which it receives routine updates of Physician information. The hospital is conducting a research study and requires information on Paramedics. Instead of adding this group of providers 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 Provider Details Query (PRPM_IN306010) to the JPRS. The request specifies that all Paramedics registered in the past 6 years and working in the capital region are to be returned in the query results.
- The JPRS processes the query request, filters the resulting output according to the hospital's data permissions, and returns the query results Provider Details Query Response (PRPM_IN306011).
This storyboard is an example of query request from a subscribing system for a print-ready report from a provider registry system. The reports are preformatted and consequently the request includes the report identifier.
| Provider Report Query | PRPM_IN306030UV01 |
| Provider Report Query Response | PRPM_IN306031UV01 |
| Administrative Report Query | PRPM_IN306040UV01 |
| Administrative Report Query Response | PRPM_IN306041UV01 |
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
The JPRS provides a distribution service so that regulatory bodies (like the College of Physicians) and other 'source' organizations can make their information about healthcare providers available to approved subscriber organizations. Add and update notifications are sent from the source organizations to the JPRS and, on a pre-determined schedule, the registry propagates the information to subscribers based on the subscriber distribution profiles. Subscriptions are governed by contractual agreements between source and subscribing organizations. Sources may choose to limit the kinds of data sent to different subscriber organizations and subscribers may choose to limit the kinds of data that they receive.
Queries are an additional mechanism by which this information can be retrieved from the JPRS by subscriber organizations. Access to information by query is also governed by subscriber profiles.
The JPRS supports a variety of print-ready provider 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, in that 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 Provider registry from which it receives routine updates of Physician information. The Health Authority is conducting a study and requires a summary report of Midwives (these providers 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 Provider Report Query (PRPM_IN306030) to the JPRS. The request specifies that all Midwives currently practicing 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 "Provider 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 Provider Report Query Response (PRPM_IN306031) containing the "Provider Summary" report as an attachment and is sent to the Health Authority West system.
- The Health Authority West sends a Provider Report Query (PRPM_IN306030) to the JPRS. The request specifies that all Midwives currently practicing 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 "Provider 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 Provider Report Query Response (PRPM_IN306031) containing the "Provider 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.
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers.
Data feeds to the JPRS come from a variety of primary sources and secondary sources. Primary sources may be licensing and regulatory bodies, like the College of Physicians, which certify individuals to practice in a particular health care profession or trade. Secondary sources are organizations that supply ancillary information about individual health care practitioners.
The JPRS provides a distribution service so that regulatory bodies (like the College of Physicians) and other 'source' organizations can make their information about healthcare providers available to approved subscriber organizations. Add and update notifications are sent from the source organizations to the JPRS and, on a pre-determined schedule, the registry propagates the information to subscribers based on the subscriber distribution profiles. Subscriptions are governed by contractual agreements between source and subscribing organizations. Sources may choose to limit the kinds of data sent to different subscriber organizations and subscribers may choose to limit the kinds of data that they receive.
Queries are an additional mechanism by which this information can be retrieved from the JPRS by subscriber organizations. Access to information by query is also governed by subscriber profiles.
The JPRS supports a variety of print-ready provider 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:
The College of Physicians, a primary data source for physician information to the JPRS is conducting a review of its member services and as part of this review would like to examine the distribution of college member information throughout the country. The college's director of information services requests a report from the JPRS detailing the volume number of provider records retrieved by or distributed to subscribers of the JPRS.
Message Flow:
- The College of Physicians sends an Administrative Report Query(PRPM_IN306040). 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 Administrative Report Query Response (PRPM_IN306041) containing the "Consumer Usage" report as an attachment and is sent to the College system.
- The College of Physicians sends an Administrative Report Query (PRPM_IN306040). 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 Administrative Report Query Response (PRPM_IN306041) 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.
This storyboard demonstrates a request for associated provider identifiers from a jurisdictional provider registry system (JPRS). The provider registry system will respond with all corresponding provider identifiers.
| Provider Associated Identifiers Query | PRPM_IN306050UV01 |
| Provider Associated Identifiers Query Response | PRPM_IN306051UV01 |
Introduction:
The jurisdictional provider registry system (JPRS) is a centralized source of information about individual healthcare providers. Data feeds to the JPRS come from a variety of primary sources, typically licensing and regulatory bodies like the College of Physicians, that make use of the publish and subscribe services, and query and report capabilities of the JPRS 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 JPRS) and consumer organizations.
Story Event:
A regional diagnostic imaging repository uses the JPRS generated identifier for management of ordering physician identification. The regional diagnostic imaging repository receives an image with a new ordering physician identifier that is not recognized as a known identifier to the imaging system. The regional diagnostic imaging repository sends a query to the JPRS using the provider identifier from the imaging system to request the regional provider identifier used by the regional diagnostic imaging repository.
The JPRS receives the query and responds with the appropriate matching identifiers.
Message Flow:-
A Provider Associated Identifiers Query (PRPM_IN306050) is sent to the JPRS with the provider identifier from the diagnostic imaging system.
-
The JPRS returns a Provider Associated Identifiers Query Response (PRPM_IN306051) with all corresponding provider identifiers.
|
||||||||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
The Application Roles for the Provider Topic have been created to support the current Provider Registry messaging requirements that have been identified. Additional Application Roles may be added as specific requirements are identified.
An application that is capable of submitting source information about any significant event that is tracked by a Provider Registry. This application will expect an appropriate response from the Provider Registry system indicating an acknowledgment of the receipt of the information and processing results including necessary identification keys. An example would be a primary or secondary source system for Provider Registry information such as the College of Physicians (a licensing body).
An application that is capable of receiving a request from a Placer application and responding with the appropriate acknowledgment. An example would be a Provider Registry system that is responsible for maintaining a registry of provider information from multiple sources.
An application that is capable of notifying another application about any significant events within a Provider Registry but does not expect any action on the part of the receiver. This would typically be a Provider Registry system that is responsible for informing subscriber systems of updates to provider information.
An application that is capable of receiving information about any significant event within a Provider Registry, but is not expected by the sender to perform any action. An example would be a subscriber to the Provider Registry system that receives notifications of updates to provider information such as a hospital.
An application that is capable of sending any Provider Registry queries to another application, and expects the receiver to take action. The query placer is responsible for generating query identifiers and matching them with responses. An example would be a subscriber to the Provider Registry system that relies upon this subscription for provider information.
An application that is capable of receiving any Provider Registry Query from a Query Placer application and responding with the appropriate Query Fulfillment. The query fulfiller is a manager role responsible for tracking each query request, assigning it a unique request id and returning the query results to the placer's network application id or to an alternate electronic address. An example would be a Provider Registry system that is responsible for responding to subscriber requests for information regarding providers.
|
||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | Interaction based |
This trigger event happens when the receipt and processing results for an Add Provider Request(PRPM_IN301010) message including necessary identification keys are acknowledged.
| Type: |
This trigger event happens when a Provider record has been added thus establishing the credentials of the individual as a healthcare provider within a source system.
| Type: | Interaction based |
This trigger event happens when the receipt and processing results for an Update Provider Request(PRPM_IN303010) message including necessary identification keys are acknowledged.
| Type: |
This trigger event happens when a Provider record has been modified.
| Type: | User request |
This trigger event happens when a user requests a print-ready usage report from a Provider Registry system based on a defined parameter list.
| Type: | Interaction based |
This query response trigger event happens when an Administrative Report Query(PRPM_IN306040) is received and successfully processed.
| Type: | User request |
This trigger event is initiated when a user requests associated identifiers for a provider (or multiple providers) from a Provider Registry system based on a defined parameter list.
| Type: | Interaction based |
| Type: | User request |
This trigger event happens when a user requests the details of a provider (or multiple providers) from a Provider Registry system based on a defined parameter list.
| Type: | Interaction based |
This query response trigger event happens when a Provider Detail Query (PRPM_IN306010) is received and successfully processed.
| Type: | User request |
This trigger event happens when a user requests a print-ready report for a provider (or multiple providers) from a Provider Registry system based on a defined parameter list.
| Type: | Interaction based |
This query response trigger event happens when a Provider Report Query (PRPM_IN306030) is received and successfully processed.
|
||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Add Provider R-MIM specifies the information model required to support messaging necessary to report that a new record was added, or should be added, to a provider registry system.
The Add Provider 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 HealthCareProvider 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 provider 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:
- PrinicipalPerson (entity): Identification of playing entity is optional (0..1) to supports the case in which information directly related to the playing party is not needed.
- AssignedEntity (role): The role class, assigned entity, captures the critical information of the provider 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.
- QualifiedEntity (role): This role describes specific qualifications that may be held the provider 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'.
- HealthCareProvider (role): This roles the specific Healthcare provider role such as a Physician, Nurse or other type of caregivers.
- LanguageCommunication: This class models the language information for the subject provider.
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
- Birthplace: class occurrences constrained from 0..* to 0..1; addr constrained from BAG<AD> to AD
- 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
- PrincipalPerson: name constrained from BAG to LIST; birthTime and administrativeGender constrained from 0..1 to 1..1
- 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 constrained to EVN
- ServiceDeliveryLocation: code constrained from 0..* to 0..1
- 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.
| Add Provider | PRPM_HD301010UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Update Provider R-MIM specifies the information model required to support messaging necessary to report that a record was updated, or should be updated, within a provider registry system.
Except where noted below, the constraint and usage notes for the R-MIM are the same as described in the Add Provider (PRPM_RM301000) R-MIM walkthrough.
Differences from Add Provider R-MIM:
- none
| Update Provider | PRPM_HD303010UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
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 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 parameter items:
- 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 licensed/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.
- ProviderID: This is the identifier for the provider 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.
- RoleClass: This is a role class for which the query is searching. This parameter is constrained to include the values Assigned Entity (ASSIGNED) and Healthcare Provider (PROV) only.
- 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 administrative report for transaction volumes of a particular type. Examples include: Query transactions, Notification transactions or Request transactions.
| Provider Admin Report Query | PRPM_HD306610UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
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 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.
| ProviderAdminReportQueryResponse | PRPM_HD306710UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Associated Identifier Query R-MIM specifies the information model required to support submitting a query to a provider registry system requesting a listing of all the associated identifiers for a provider.
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)
This query contains the following input parameters:
- AdministrativeGender: This is the gender of the person for which the query is searching. A maximum of one gender may be provided.
- 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.
- DOB: The date of birth of the provider for which the query is searching. Requestor may specify a specific date, or date range.
- Jurisdiction: The jurisdiction in which the provider is licensed/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.
- ProviderAddress: The address of the provider 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).
- ProviderID: This is the identifier for the provider for which the query is searching. Multiple id's can be specified through repetition of this parameter.
- ProviderName: This is the name of the individual 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).
- RoleClass: This is a role class for which the query is searching. This parameter is constrained to include the values Assigned Entity (ASSIGNED) and Healthcare Provider (PROV) only.
- 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.
| Provider Event Associated Identifiers Query | PRPM_HD306810UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Associated Identifier Query Response R-MIM specifies the information model required to support responding to a Provider Associated Identifiers Query requesting a listing of all the associated identifiers for a provider.
This model supports the inclusion of multiple identifiers associated with the provider. It is expected that this response message will return all associated identifiers. Since each identifier returned will have an Identifier Type associated with it (as part of the II data type), the receiving system can determine which identifiers are relevant to their scenario.
This R-MIM consists of an entry point into the RoleChoice choice box consisting of the AssignedEntity role (functional role in an organization) and the HealthCareProvider role (role specific to healthcare delivery). Both of these entry point roles contain the identifier, code (i.e. the role type), and the name of the provider in that role. These classes support the communication of all of the associated identifiers. A minimum of one AssignedEntity identifier is required.
The PrincipalPerson class is included as the playing entity for both of the roles and supports the communication of the provider's name and any identifiers associated with the person (as opposed to the role).
The Organization class is included as the scoper of the roles to support the communication of the identifier and name of the organization responsible for issuing the HealthCareProvider role and as the represented organization for the AssignedEntity role. The Organization class is also the scoper for the TerritorialAuthority class played by the Jurisdiction entity class. The Jurisdiction class supports the identification of the jurisdiction in which the associated identifiers are applicable.
| Provider Event Associated Identifiers Query Response | PRPM_HD306910UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Detail Query R-MIM specifies the information model required to support submitting a query to a provider registry system for detailed provider information.
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 Provider Detail query is a comprehensive query request that supports a broad range of possible uses with many input parameters. This query allows details for multiple providers to be retrieved with one query request as well as the filtering to specify the type of provider information to be included in the response. The RMIM also supports requesting the inclusion of provider history as part of the response.
This query contains the following input parameters:
- AdministrativeGender: This is the gender of the person for which the query is searching. A maximum of one gender may be provided.
- 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.
- DOB: The date of birth of the provider for which the query is searching. Requestor may specify a specific date, or date range.
- 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 licensed/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.
- ProviderAddress: The address of the provider 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).
- ProviderID: This is the identifier for the provider for which the query is searching. Multiple id's can be specified through repetition of this parameter.
- ProviderName: This is the name of the individual 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.
- 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>
- RoleClass: This is a role class for which the query is searching. This parameter is constrained to include the values Assigned Entity (ASSIGNED) and Healthcare Provider (PROV) only.
- 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. telephone number, email etc) for which the query is searching.
| Provider Detail Query | PRPM_HD306010UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Detail Query Response R-MIM specifies the information model required to support responding to a Provider Detail Query(PRPM_RM401000).
Except where noted below, this R-MIM is the same as described in the Add Provide R-MIM (PRPM_RM301000) walkthrough.
Differences from Add Provider R-MIM:
- relatedTo: Update mode enabled
- Note: All attributes made required 1..1; Update mode enabled
- InformDefinition: Changed class cardinality from 0..1 to 0..* to support multiple occurrences in query responses.
- DisciplinaryAction: Update mode enabled
- sequel: Update mode enabled
- location: sequenceNumber cardinality changed from 0..1 to 1..1; Update mode enabled
- PrincipalPerson: Update mode enabled;
- BirthPlace: addr constrained to mandatory
- Affiliate: Update mode enabled
- responsibleFor: Update mode enabled
| Provider Detail Query Response | PRPM_HD306110UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Report Query R-MIM specifies the information model required to support submitting a query to a provider registry system for preformatted provider report.
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 one or more SortControl(s) allowing the query to request a response sorted by specific element name(s) and direction(s) (e.g. alphabetical or reverse alphabetical).
The Provider Report Query includes a parameter to specify the precise preformatted report that is being requested as well as parameters to filter the type of providers included in the report and sort criteria etc.
This query contains the following input parameters:
- AdministrativeGender: This is the gender of the person for which the query is searching. A maximum of one gender may be provided.
- 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.
- DOB: The date of birth of the provider for which the query is searching. Requestor may specify a specific date, or date range.
- 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 licensed/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.
- ProviderAddress: The address of the provider 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).
- ProviderID: This is the identifier for the provider for which the query is searching. Multiple id's can be specified through repetition of this parameter.
- ProviderName: This is the name of the individual 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>
- RoleClass: This is a role class for which the query is searching. This parameter is constrained to include the values Assigned Entity (ASSIGNED) and Healthcare Provider (PROV) only.
- 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. telephone number, email etc) for which the query is searching.
| Provider Report Query | PRPM_HD306210UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Report Query Response R-MIM specifies the information model required to support responding to a Provider 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 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.
| ProviderReportQueryResponse | PRPM_HD306310UV01 |
| Parent: | Personnel Management (PRPM_DM000000UV) |
The Provider Response R-MIM specifies the information model required to support responding to any fulfillment request message regarding a provider record.
| Provider Response | PRPM_HD309010UV01 |
|
||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
The Add Provider HMD specifies the information model required to support messaging necessary to report that a new record was added, or should be added, to a provider registry system.
The Update Provider HMD specifies the information model required to support messaging necessary to report that a record was updated, or should be updated, within a provider registry system.
The Administrative Report Query HMD specifies the information model required to support submitting a query to a provider registry system for preformatted administrative reports. 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.
The Administrative Report Query Response HMD specifies the information model required to support responding to a Administrative Report Query.
The Associated Identifier Query HMD specifies the information model required to support submitting a query to a provider registry system requesting a listing of all the associated identifiers for a provider.
The Associated Identifier Query Response HMD specifies the information model required to support responding to a query requesting a listing of all the associated identifiers for a provider.
The Provider Detail Query HMD specifies the information model required to support submitting a query to a provider registry system for detailed provider information. The Provider Detail query is a comprehensive query request that supports a broad range of possible filters and thus has many input parameters. This query allows details for multiple providers to be retrieved with one query request. The RMIM also supports requesting the inclusion of transaction history of a provider record as part of the response.
The Provider Detail Query Response HMD specifies the information model required to support responding to a Provider Detail Query.
The Provider Report Query HMD specifies the information model required to support submitting a query to a provider registry system for preformatted provider report. The Provider Report Query includes a parameter to specify the precise preformatted report that is being requested as well as parameters to filter the type of providers included in the report and sort criteria etc.
The Provider Report Query Response HMD specifies the information model required to support responding to a Provider Report Query.
The Provider Confirmation Response HMD specifies the information model required to support responding to any fulfillment request message regarding a provider record.
|
||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
This interaction is used to send a notification that a provider has been added to a provider registry system. No response is expected from the recipient system.
| Trigger Event | Add Provider | PRPM_TE301010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Add Provider | PRPM_MT301010UV01 |
| Sender | Provider Comprehensive Informer | PRPM_AR300001UV01 |
| Receiver | Provider Comprehensive Informer | PRPM_AR300001UV01 |
| Receiver | Provider Comprehensive Tracker | PRPM_AR300002UV01 |
This interaction is used to request that a new provider record be added to a provider registry system. It is expected that the receiving application will respond with an Add Provider Response (PRPM_IN301011) interaction containing the appropriate identifiers assigned by the provider registry system.
| Trigger Event | Add Provider | PRPM_TE301010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Add Provider | PRPM_MT301010UV01 |
| Reason | Trigger Event | Interaction |
| Registry response including key identifiers | PRPM_TE301011UV01 | PRPM_IN301011UV01 |
| Sender | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
| Receiver | Provider Comprehensive Placer | PRPM_AR300003UV01 |
This interaction is used to confirm the receipt of the Add Provider Request (PRPM_IN301010) interaction. This interaction either confirms processing of the request and contains the appropriate identifiers assigned by the provider registry system; or will indicate that the request could not be fulfilled (with supporting reasons).
| Trigger Event | Add Provider Confirmation | PRPM_TE301011UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Provider Confirmation | PRPM_MT309000UV01 |
| Sender | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
| Receiver | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
| Receiver | Provider Comprehensive Placer | PRPM_AR300003UV01 |
This interaction is used to send a notification that a provider record has been updated in a provider registry system. No response is expected from the recipient system.
| Trigger Event | Update Provider | PRPM_TE303010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Notif. Control Act, Role Subject | MFMI_MT700701UV01 |
| Message Type | Update Provider | PRPM_MT303010UV01 |
| Sender | Provider Comprehensive Informer | PRPM_AR300001UV01 |
| Receiver | Provider Comprehensive Tracker | PRPM_AR300002UV01 |
| Receiver | Provider Comprehensive Informer | PRPM_AR300001UV01 |
This interaction is used to request that a provider record be updated within a provider registry system. It is expected that the receiving application will respond with an Update Provider Response (PRPM_IN303011) interaction containing the appropriate identifiers assigned by the provider registry system.
| Trigger Event | Update Provider | PRPM_TE303010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Update Provider | PRPM_MT303010UV01 |
| Reason | Trigger Event | Interaction |
| Registry response including key identifiers | PRPM_TE303011UV01 | PRPM_IN303011UV01 |
| Sender | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
This interaction is used to confirm the receipt of the Update Provider Request (PRPM_IN303010) interaction. This interaction either confirms processing of the request and contains the appropriate identifiers assigned by the provider registry system; or will indicate that the request could not be fulfilled (with supporting reasons).
| Trigger Event | Update Provider Confirmation | PRPM_TE303011UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Reg Request Control Act,Role Subject | MFMI_MT700721UV01 |
| Message Type | Provider Confirmation | PRPM_MT309000UV01 |
| Sender | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
| Receiver | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Fulfiller | PRPM_AR300004UV01 |
This interaction is used to request a preformatted Provider Administrative report. It is expected that the receiving application will respond with an Administrative Report Query Response (PRPM_IN306041) interaction.
| Trigger Event | Administrative Report Query | PRPM_TE306015UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Query Definition | Provider Admin Report Query | PRPM_MT306610UV01 |
| Reason | Trigger Event | Interaction |
| Query response with requested information. | PRPM_TE306115UV01 | PRPM_IN306041UV01 |
| Sender | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
This interaction is used to respond to an Administrative Report Query (PRPM_IN306040) interaction and will contain the preformatted report requested.
| Trigger Event | Administrative Report Query Response | PRPM_TE306115UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Query Control Act Response / Acknowledgement | QUQI_MT120001UV01 |
| Query Response Type | Provider Admin Report Query Response | PRPM_MT306710UV01 |
| Query Definition | Provider Admin Report Query | PRPM_MT306610UV01 |
| Sender | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Trigger Event | Provider Associated ID Query Response | PRPM_TE306041UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 |
| Query Response Type | Provider Associated Identifiers Query Response | PRPM_MT306910UV01 |
| Query Definition | Provider Associated Identifiers Query | PRPM_MT306810UV01 |
| Sender | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Trigger Event | Provider Associated ID Query | PRPM_TE306040UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Query Definition | Provider Associated Identifiers Query | PRPM_MT306810UV01 |
| Reason | Trigger Event | Interaction |
| Query response with requested information | PRPM_TE306041UV01 | PRPM_IN306051UV01 |
| Sender | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Sender | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Placer | PRPM_AR300003UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
This interaction is used to request details about a provider. It is expected that the receiving application will respond with the Provider Details Query Response (PRPM_IN306011) containing the requested information from the provider registry system.
| Trigger Event | Provider Detail Query | PRPM_TE306010UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Query Definition | Provider Detail Query | PRPM_MT306010UV01 |
| Reason | Trigger Event | Interaction |
| Query response with requested information | PRPM_TE306110UV01 | PRPM_IN306011UV01 |
| Sender | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
This interaction is used to respond to an Provider Details Query (PRPM_IN306010) interaction and will contain the requested records from the provider registry system.
| Trigger Event | Provider Detail Query Response | PRPM_TE306110UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Master File / Registry Query Response,Role Subject | MFMI_MT700711UV01 |
| Query Response Type | Provider Detail Query Response | PRPM_MT306110UV01 |
| Query Definition | Provider Detail Query | PRPM_MT306010UV01 |
| Sender | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
This interaction is used to request a provider preformatted report. It is expected that the receiving application will respond with an Provider Report Query Response (PRPM_IN306031) interaction containing the preformatted report.
| Trigger Event | Provider Report Query | PRPM_TE306014UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Query Control Act Request : Query By Parameter | QUQI_MT021001UV01 |
| Query Definition | Provider Report Query | PRPM_MT306210UV01 |
| Reason | Trigger Event | Interaction |
| Query response with requested information | PRPM_TE306114UV01 | PRPM_IN306031UV01 |
| Sender | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
This interaction is used to respond to an Provider Report Query (PRPM_IN306030) interaction and will contain the preformatted report requested.
| Trigger Event | Provider Report Query Response | PRPM_TE306114UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Query Control Act Response / Acknowledgement | QUQI_MT120001UV01 |
| Query Response Type | Provider Report Query Response | PRPM_MT306310UV01 |
| Query Definition | Provider Report Query | PRPM_MT306210UV01 |
| Sender | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Fulfiller | PRPM_AR300013UV01 |
| Receiver | Provider Comprehensive Query Placer | PRPM_AR300011UV01 |
| Return to top of page |