Difference between revisions of "PA Interdependent Registries"
Line 37: | Line 37: | ||
#HL7 Healthcare, Community Services and Provider Directory - service functional model | #HL7 Healthcare, Community Services and Provider Directory - service functional model | ||
#HL7 V3 Patient Administration, SDLOC DSTU | #HL7 V3 Patient Administration, SDLOC DSTU | ||
− | #IHE Healthcare Provider Directory (based on LDAP and ISO 21091) - draft | + | #[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_HPD_Rev1-1_TI_2010-08-10.pdf IHE Healthcare Provider Directory] (based on LDAP and ISO 21091) - draft |
#ISO/DIS 21091 Health Informatics – Directory services for security, communications and identification of professionals and patients | #ISO/DIS 21091 Health Informatics – Directory services for security, communications and identification of professionals and patients | ||
#Medbiquitous Healthcare Professional Profile Schema | #Medbiquitous Healthcare Professional Profile Schema |
Revision as of 18:45, 2 October 2010
Introduction
The primary implementer of the HL7 V3 role-based registries appears to be Canada. Canada has production implementations of Client (AKA Patient) and Provider registries. At the May 2010 Working Group Meeting Ron Parker of Canada Infoway gave a presentation to the Patient Administration work group addressing lessons learned and future architectural plans for Canada. See Ron's presentation in the 20100517_PA_WMG_Attachements.zip file.
The most significant finding is that real world applications require that different types of registries work together. The challenge for Patient Administration is to define interactions that span a number of topics:
- Person topic (DSTU in Patient Administration domain)
- Patient topic (DSTU in Patient Administration domain)
- Service Delivery Location (DSTU in Patient Administration domain)
- Provider topic (Normative R1 in Personnel Management domain)
- Organization topic (Normative R1 in Personnel Management domain)
Also, the Canadian Notional Architecture includes two additional registries for which a standard has not been defined. It seems possible that these additional registries would fall under the scope of a work group other than Patient Administration. Defining interactions that would also include these registries could present a technical challenge.
- Health Service
- Health Program
Business Cases
- HITSP/IS03 Consumer Empowerment and Access to Clinical Information via Networks identified three standards gaps:
- IER 73 – Request/receive provider information
- IER 74 – Access/select provider information
- DR 73 – Provider identification (consumer oriented terminology for provider type role)
- HITSP/CAP121 Communicate Referral Request Capability identified a gap:
- Currently no standard available for a provider registry from which to select a provider based on patient preferences or on Health Plan Eligibility. Candidate standards in HL7 and ASC X12 are awaiting harmonization.
- The Health Information Technology Policy Committee's Information Exchange Workgoup has identified Provider Directories as a key enabler for nationwide health information exchange.
- HL7 EHR System Functional Model see IN.3 Registry and Directory Services
Use Cases
- Consumer Empowerment: Consumer Access to Clinical Information ONC Use Case
- Consultations and Transfers of Care ONC Use Case
- Scheduling ONC Use Case
Existing Standards
- ASC X12 274 Health Care Provider Directory
- ANSI/HL7 V3 Personnel Management, Provider topic - message specification
- CMS National Provider Identifier
- HITSP/C83 CDA Content Modules Component – HL7 V3 CDA Healthcare Provider module
- HL7 Healthcare, Community Services and Provider Directory - service functional model
- HL7 V3 Patient Administration, SDLOC DSTU
- IHE Healthcare Provider Directory (based on LDAP and ISO 21091) - draft
- ISO/DIS 21091 Health Informatics – Directory services for security, communications and identification of professionals and patients
- Medbiquitous Healthcare Professional Profile Schema