Standards Selection Guide
Purpose
This document provides an overview of available standards and a recommended approach to support the requirements identified below. The intent is to simplify standards selection decisions in future projects and, in turn, to promote standardization of solutions across projects by providing useful information to support decision making in a readily consumable format.
Content in this guide was generated using information from the Alberta Provider Domain Implementation Guide (R020403.AB.PM.01) and PRS HL7 Messaging Implementation Guide - AB MR2009.
Business Context
The Provider Registry (PR) is a foundational component of the Electronic Health Record (EHR) which provides a trusted and centralized source of regulated health service provider information to authorized consumers. Health Service Provider Identifiers (HSPID) within the PR enable unique identification of individual health care providers across the systems participating in the EHR. Demographic and licensing information for all providers is stored within the PR for validation and/or retrieval by source and consumer systems and organizations.
This Guide relates to the messaging standards used to provide and maintain the information in the Provider Registry as well as those used to access it from consumer applications.
Typical Use Cases
The use cases outlined below are intended to provide context and frame the needs that the candidate standards must meet.
The use cases identify different activities related to a provider registry:
Source Systems Sources systems, such as the Alberta College of Physicians and Surgeons, provide information to the registry. | Consumer Systems Consumer systems, such as electronic medical records systems used at the point of care, receive and consume information from the registry, either as notifications or in response to a query. |
UC-1 Maintain provider information
Data received from source systems (such as information from the Alberta College of Physicians and Surgeons) is used to add or update provider information within the registry, including secondary identifiers and licensing information.
Multiple business events relate to provider maintenance including:
- Addition of a new provider
- Update of provider demographic information
- Association of a license with a provider
- Nullification of a license with a provider
Information updates in the registry then trigger notifications to distribute updated provider information to client systems UC-4.
UC-2 Logically delete provider record
Identify and logically delete a provider added to the registry in error.
Information updates in the registry then trigger notifications to distribute updated provider information to consumer systems UC-4.
UC-3 Merge provider records
Two provider records are combined in the registry.
Information updates in the registry then trigger notifications to distribute updated provider information to consumer systems UC-4.
UC-4 Notify consumer of information updates (passive)
Events in the PR trigger notification messages which are distributed to subscribing applications.
- Add provider
- Update provider
- Merge provider
- Nullify license
UC-5 Consumer search for provider information (active)
A consumer system sends a query to the provider registry:
- Get provider details using HSPID
- Get provider details using License and Role
- Identify provider using License when HSPID role isn't known
- Find candidate providers matching a set of search criteria
If the request is authorized, the PR responds with the requested information.
UC-6 Request transaction history
A source system requests a history of provider record changes by date range or other criteria.
If the request is authorized, the PR responds with the requested information.
Evaluated Standards
This guide focuses on the selection of messaging standards to support the in scope use cases. Due to differences in business requirements, the standards evaluation is broken into two sets of standardization requirements:
- Consumer messaging
- Source messaging
Consumer messaging
A primary role of the Provider Registry is to enable provider identification within consumer systems contributing data to or consuming data from provincial EHR solutions. The predominant means for exchanging data with the EHR is HL7 version 3 messaging.
Standard | Fit for Purpose | Stewardship | Quality | |||||
Fits | Implementation | Vendor Support | Canadian | SDO | Complexity | Standard | Training, Support and Tooling | |
AB MR2009 (HL7 v3) |
| Production |
| Yes (AB) | Localized | 
| High |  |
pan-Canadian MR2009 (HL7 v3) |  | Production in Canada | | Yes | Localized | | High | |
PRS XML Messaging |
| Production |
| Yes | No |
| High |
|
Architectural Constraints and Considerations | Secondary Benefits | |||||||
Use of HL7v3 conforms with the architectural design of Canada's digital health blueprint. AB MR2009 extends the Canadian specification with the ability to merge and logically delete providers. HL7v3 messaging does not provide the means to transmit a the history of changes to a provider records. The PRS XML Messaging specification is proprietary to the registry solution but is shared across several provinces. | Standardizing on MR2009 across EHR applications reduces complexity within the infostructure and for implementers by minimizing variability in models and vocabulary. | |||||||
| Recommendation | Supporting Rationale | |||||||
| AB MR2009 (HL7 v3) | The AB MR2009 specification was designed to meet the in-scope use cases for PRS consumers and conforms with the architectural design of Canada's digital health blueprint. It extends the Canadian specification with the ability to merge and logically delete providers. | |||||||
Source messaging
Source messaging provides the means to transmit information from systems used at various licensing agencies, professional colleges, etc. to the Provider Registry.
Standard | Fit for Purpose | Stewardship | Quality | |||||
Fits | Implementation | Vendor Support | Canadian | SDO | Complexity | Standard | Training, Support and Tooling | |
PRS XML Messaging |
| Production |
| Yes | No | 
| High |  |
| AB MR2009 (HL7 v3) | | Production in Canada |  | Yes (AB) | Localized | | High | |
pan-Canadian MR2009 (HL7 v3) | | Production in Canada | | Yes | Localized | | High | |
Architectural Constraints and Considerations | Secondary Benefits | |||||||
Source systems are not typically EHR consumer systems. HL7v3 messaging does not provide the means to transmit a the history of changes to a provider records. (UC-6) The PRS XML Messaging specification is proprietary to the registry solution but is shared across several provinces. |
| |||||||
| Recommendation | Supporting Rationale | |||||||
| PRS XML Messaging | The PRS XML specification was designed to meet the in-scope use cases for PRS source systems. Although the specification is proprietary to the specific provider registry solution used in Alberta it is relatively straightforward to implement. | |||||||
Recommended Standards
Standardization Requirement | Options | Choice | Rationale |
Consumer Messaging
| AB MR2009 (HL7 v3) | X | The AB MR2009 specification was designed to meet the in-scope use cases for PRS consumers and conforms with the architectural design of Canada's digital health blueprint. It extends the Canadian specification with the ability to merge and logically delete providers. |
pan-Canadian MR2009 (HL7 v3) |
| ||
| PRS XML Messaging | |||
Consumer Messaging | PRS XML Messaging | X | The PRS XML specification was designed to meet the in-scope use cases for PRS source systems. Although the specification is proprietary to the specific provider registry solution used in Alberta it is relatively straightforward to implement. |
| AB MR2009 (HL7 v3) | |||
| pan-Canadian MR2009 (HL7 v3) |
Implementation Resources
Community Pages
Matters related to Provider Registry messaging in Canada are handled through the following Community on InfoCentral.
Implementation Guides and Specifications
The PRS HL7 Messaging Implementation Guide - AB MR2009 is available to organizations using the PRS solution.
The HL7 Explorer structural specifications for the AB MR2009 HL7v3 messages referenced in this document are available in the for Alberta R02.04.03 specification. This web-friendly documentation is very useful for those familiar with HL7v3 messaging.
Technical Resources
Infoway Message Builder allows developers to focus on their business problem by providing APIs that fosters quick and easy creation, population and access to HL7v3 requests and responses.
Developers of clients for the PRS HL7 Interface can use Message Builder API which fosters quick and easy creation, population, validation, and access to HL7v3 requests and responses that are conformed to the jurisdictional specification. Further details can be found in the Message Builder section on InfoCentral (https://infocentral.infoway-inforoute.ca/3_Tools_and_solutions/Message_Builder).
For further technical support please contact project teams listed in the header section or seek support through the community site.
Existing Implementations
| Implementing Organization | Contact Information | Notes |
|---|---|---|
Alberta Health | Craig Mowat Manager, Systems Development | |
Sierra Systems | Kris Lewis Technology Principal | The content of the guide reflects functionality that is available to all users of the WHIC PRS system although not yet deployed in all provinces. |