Difference between revisions of "PA Interdependent Registries"
Line 42: | Line 42: | ||
==Analysis Documents== | ==Analysis Documents== | ||
+ | #[http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Healthcare%20Informatics%20Technology%20Standards%20Panel/Standardization%20Committees/Foundations/Foundations%20Information%20Interchange%20SC/HITSP-IIsc-HarmonizationProject-ProviderDirectory-V10-ND-20091007.doc HITSP Information Interchange Subcommittee Interface to Provider Directory/Registry Harmonization Project] | ||
+ | #[http://www.hl7.org/Library/Committees/pafm/HSCPDIR_white_paper.pdf Healthcare, Community Services and Provider Director Service Functional Profile, Release 1 mapped to HL7 Personnel Management] |
Revision as of 01:53, 1 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