Difference between revisions of "PA Interdependent Registries"
(56 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | <!-- RETURN PATHS --> | ||
+ | Return to [[Patient_Administration]] work group page<br/> | ||
+ | Return to [[Service_Oriented_Architecture]] work group page<br/> | ||
+ | |||
+ | |||
==Introduction== | ==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 | + | 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 to PA at the Rio WGM here [http://gforge.hl7.org/gf/download/docmanfileversion/6006/7827/20100518InterdRegistriestoPAdmin.ppt Ron Parker presentation on Interdependent Registries]. |
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: | 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: | ||
Line 7: | Line 12: | ||
*Patient topic (DSTU in Patient Administration domain) | *Patient topic (DSTU in Patient Administration domain) | ||
*Service Delivery Location (DSTU in Patient Administration domain) | *Service Delivery Location (DSTU in Patient Administration domain) | ||
− | *Provider topic (Normative R1 in Personnel Management domain) | + | *Provider topic (Normative R1 in Personnel Management domain; R2 last balloted 2009Jan) |
− | *Organization topic (Normative R1 in Personnel Management domain) | + | *Organization topic (Normative R1 in Personnel Management domain; R2 last balloted 2009Jan) |
Also, the Canadian Notional Architecture includes two additional registries for which a standard has not been defined. We need to do more research to determine whether these registries should be defined within Patient Administation. Defining interactions that would also include these registries could present a technical challenge. | Also, the Canadian Notional Architecture includes two additional registries for which a standard has not been defined. We need to do more research to determine whether these registries should be defined within Patient Administation. Defining interactions that would also include these registries could present a technical challenge. | ||
Line 15: | Line 20: | ||
*Health Program | *Health Program | ||
− | ==Business | + | |
− | #[http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=50&PrefixAlpha=1&APrefix=IS&PrefixNumeric=03 HITSP/IS03 Consumer Empowerment and Access to Clinical Information via Networks] identified three standards gaps: | + | '''Basic definitions'''<br/> |
− | #*IER | + | ''From [http://www.xmlhandbook.com/06c-ebus.pdf Goldfarb and Prescod, XML Handbook, 5th Ed]'' |
− | #*IER | + | # '''Directory:''' a catalog in which things may be listed with or without their owners’ overt participation (or even knowledge!) |
− | #*DR | + | # '''Registry:''' a catalog whose participants must request participation, either explicitly or as a by-product of organization membership, legal action, etc. |
+ | # '''Repository:''' a place where things are stored, often in conjunction with a registry or directory | ||
+ | |||
+ | == Project Scope Statement == | ||
+ | [http://gforge.hl7.org/gf/project/patient-admin/docman/?action=DocmanFileEdit&id=7004 Interdependent Registries Project Scope Statement]<br/> | ||
+ | |||
+ | ==Business Requirements== | ||
+ | #[http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=50&PrefixAlpha=1&APrefix=IS&PrefixNumeric=03 HITSP/IS03 Consumer Empowerment and Access to Clinical Information via Networks V3.1] identified three standards gaps: | ||
+ | #*IER 13 – Request/receive provider information | ||
+ | #*IER 14 – Access/select provider information | ||
+ | #*See section 4.2 GAPS WHERE THERE ARE NO STANDARDS, page 90: | ||
+ | #**''Major gap in the specification of a provider registry (if using the HIE variant); its content, privacy issues, organization-provider relationship(s), and organization-organization relationship(s). Also, if this is related to addressing the permissions issue then are there other. organizations/individuals that we need to cover as well. This provider list is required for inclusion in /association to the permissions/access control entries'' | ||
+ | #**''1. Need to do query/retrieve access with a provider registry (assumes that one exists and is maintained) or do pt-to-pt request (in-person, phone) to a healthcare entity. The entity pushes this info to the consumer (using HITSP/C32).'' | ||
+ | #**''2. Consumer creates and is capable of communicating this list to others (method for building the relationship to permissions?)'' | ||
+ | #**''Consider payor-provided portals to provider lists for its members as a source of provider list content'' | ||
+ | #*DR 13 – Provider identification (consumer oriented '''terminology''' for provider type role) | ||
+ | #**''Provider identification, details, location'' | ||
+ | #**''Superset of HITSP/C32 - Summary Documents Using HL7 Continuity of Care Document (CCD) & C37 - Lab Report Document provider identification, and additional elements as needed for entity resolution'' | ||
+ | #**''Consistent representation of practice sites, nature of practice, all alternatively presented in lay person friendly terms'' | ||
#[http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=13&PrefixNumeric=121 HITSP/CAP121 Communicate Referral Request Capability] identified a gap: | #[http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=13&PrefixNumeric=121 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.'' | #*''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.'' | ||
#[http://healthit.hhs.gov/blog/faca/index.php/2010/09/21/hit-policy-committee%E2%80%99s-information-exchange-workgroup-seeks-comments/ The Health Information Technology Policy Committee's Information Exchange Workgoup] has identified Provider Directories as a key enabler for nationwide health information exchange. | #[http://healthit.hhs.gov/blog/faca/index.php/2010/09/21/hit-policy-committee%E2%80%99s-information-exchange-workgroup-seeks-comments/ The Health Information Technology Policy Committee's Information Exchange Workgoup] has identified Provider Directories as a key enabler for nationwide health information exchange. | ||
− | #[http://www.hl7.org/ehr/downloads/index_2007.asp HL7 EHR System Functional Model] see IN.3 Registry and Directory Services | + | #[http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_12811_954626_0_0_18/hitpc-ilpd-recommendations-05-11-11.ppt HIT Policy Committee - Provider Directory Final Recommendations 5/11/2011] |
+ | #[http://www.hl7.org/ehr/downloads/index_2007.asp HL7 EHR System Functional Model] see [[PA_EHR_IN3|IN.3 Registry and Directory Services]] | ||
− | ==Use Cases== | + | ==Business Use Cases== |
+ | The following are business use cases that rely on interactions between person, patient, provider and organization registries. | ||
#[http://www.hhs.gov/healthit/usecases/consumeraccess.html Consumer Empowerment: Consumer Access to Clinical Information] ONC Use Case | #[http://www.hhs.gov/healthit/usecases/consumeraccess.html Consumer Empowerment: Consumer Access to Clinical Information] ONC Use Case | ||
#[http://www.hhs.gov/healthit/usecases/reftx.html Consultations and Transfers of Care] ONC Use Case | #[http://www.hhs.gov/healthit/usecases/reftx.html Consultations and Transfers of Care] ONC Use Case | ||
#[http://www.hhs.gov/healthit/usecases/sched.html Scheduling] ONC Use Case | #[http://www.hhs.gov/healthit/usecases/sched.html Scheduling] ONC Use Case | ||
+ | #[[PA_Registries_HSD_Use_Case|Healthcare Service Directory Use Cases from OMG RFP]] ''- new 2010-12-27'' | ||
+ | #[http://wiki.directproject.org/User+Stories NHIN Direct User Stories] - these business use case assume the existence of a Healthcare Provider Registry for organizations and individual providers. | ||
+ | # [http://gforge.hl7.org/gf/download/docmanfileversion/6200/8166/ScenariosdrawnfromHCSPD.doc Scenarios Copied from HCSPDIR R1] - ''added 2001-03-22'' | ||
− | == | + | ==Related Standards== |
#ASC X12 274 Health Care Provider Directory | #ASC X12 274 Health Care Provider Directory | ||
#ANSI/HL7 V3 Personnel Management, Provider topic - message specification | #ANSI/HL7 V3 Personnel Management, Provider topic - message specification | ||
Line 39: | Line 67: | ||
#[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 | #[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 | + | #[http://www.medbiq.org/working_groups/professional_profile/ProfessionalProfileServices.pdf Medbiquitous Healthcare Professional Profile Schema] |
+ | #[http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf OASIS ebXML Registry Information Model v2.0] -''new 2010-12-23'' | ||
+ | #[http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf OASIS ebXML Registry Services Specification v2.0] -''new 2010-12-23'' | ||
+ | # [http://gforge.hl7.org/gf/download/docmanfileversion/6145/8023/10006%252BHPI%252BCode%252BSet%252Bv%252B1.2%252BJuly%252B2008.pdf New Zealand HISO 10006 HPI Code Set] - ''new 2011-02-16'' | ||
+ | # [http://gforge.hl7.org/gf/download/docmanfileversion/6144/8022/10005%252BHPI%252BData%252BSet%252Bv1.2%252BJuly%252B2008.pdf New Zealand HISO 10005 HPI Data Sett] - ''new 2011-02-16''' | ||
==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://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] | #[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] | ||
+ | #[[PA_Registry_State_Model|Analysis of Registry Behavior]] - ''new 2010-12-20'' | ||
+ | # [http://www.hl7.org/Library/Committees/pafm/HSCPDIR_white_paper.pdf HL7 Healthcare, Community Services and Provider Directory mapped to HL7 V3 message standards] - ''new 2011-03-22'' | ||
+ | |||
+ | ===May 2010 Ballot: Domain Analysis=== | ||
+ | The use cases that specify the main use cases regarding the use of registries in complex, inter-dependent ways: | ||
+ | * [[Registry_Use_Cases#May_2011|Registry Use Cases]] | ||
+ | *[http://gforge.hl7.org/gf/download/docmanfileversion/6098/7957/AdditionalUseCases-eReferralContentAuthoringProgramEnrolment.doc Infoway Use Cases] ''new 20110111'' | ||
+ | * [[Registry Actors]] | ||
+ | * [[Glossary of Registry Terms]] | ||
+ | * [http://gforge.hl7.org/gf/download/docmanfileversion/6187/8130/InterdepentRegistriesDAM.pdf Domain Analysis Model] | ||
+ | |||
+ | ==Related Proposals== | ||
+ | #[[Proposal:_Patient_Registry,_add_Find_Candidates_query_parameters|Patient Registry Additional Query Parameters]] - approved | ||
+ | #[[PRPM_-_AORTA_use_cases|AORTA Application Registry Use Case]] | ||
+ | #[[Proposal:_Person_Registry,_add_AdministrativeObservation_parameter|Person Registry Additional Query Parameter]] - approved | ||
+ | |||
+ | ==Meeting Minutes== | ||
+ | *[[:Category:Interdependent_Registries_Minutes|Interdependent Registries Project Meeting Minutes]] | ||
+ | |||
+ | |||
+ | [[Category:Interdependent_Registries|Interdependent Registries Project]] |
Latest revision as of 19:11, 17 May 2011
Return to Patient_Administration work group page
Return to Service_Oriented_Architecture work group page
Contents
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 to PA at the Rio WGM here Ron Parker presentation on Interdependent Registries.
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; R2 last balloted 2009Jan)
- Organization topic (Normative R1 in Personnel Management domain; R2 last balloted 2009Jan)
Also, the Canadian Notional Architecture includes two additional registries for which a standard has not been defined. We need to do more research to determine whether these registries should be defined within Patient Administation. Defining interactions that would also include these registries could present a technical challenge.
- Health Service
- Health Program
Basic definitions
From Goldfarb and Prescod, XML Handbook, 5th Ed
- Directory: a catalog in which things may be listed with or without their owners’ overt participation (or even knowledge!)
- Registry: a catalog whose participants must request participation, either explicitly or as a by-product of organization membership, legal action, etc.
- Repository: a place where things are stored, often in conjunction with a registry or directory
Project Scope Statement
Interdependent Registries Project Scope Statement
Business Requirements
- HITSP/IS03 Consumer Empowerment and Access to Clinical Information via Networks V3.1 identified three standards gaps:
- IER 13 – Request/receive provider information
- IER 14 – Access/select provider information
- See section 4.2 GAPS WHERE THERE ARE NO STANDARDS, page 90:
- Major gap in the specification of a provider registry (if using the HIE variant); its content, privacy issues, organization-provider relationship(s), and organization-organization relationship(s). Also, if this is related to addressing the permissions issue then are there other. organizations/individuals that we need to cover as well. This provider list is required for inclusion in /association to the permissions/access control entries
- 1. Need to do query/retrieve access with a provider registry (assumes that one exists and is maintained) or do pt-to-pt request (in-person, phone) to a healthcare entity. The entity pushes this info to the consumer (using HITSP/C32).
- 2. Consumer creates and is capable of communicating this list to others (method for building the relationship to permissions?)
- Consider payor-provided portals to provider lists for its members as a source of provider list content
- DR 13 – Provider identification (consumer oriented terminology for provider type role)
- Provider identification, details, location
- Superset of HITSP/C32 - Summary Documents Using HL7 Continuity of Care Document (CCD) & C37 - Lab Report Document provider identification, and additional elements as needed for entity resolution
- Consistent representation of practice sites, nature of practice, all alternatively presented in lay person friendly terms
- 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.
- HIT Policy Committee - Provider Directory Final Recommendations 5/11/2011
- HL7 EHR System Functional Model see IN.3 Registry and Directory Services
Business Use Cases
The following are business use cases that rely on interactions between person, patient, provider and organization registries.
- Consumer Empowerment: Consumer Access to Clinical Information ONC Use Case
- Consultations and Transfers of Care ONC Use Case
- Scheduling ONC Use Case
- Healthcare Service Directory Use Cases from OMG RFP - new 2010-12-27
- NHIN Direct User Stories - these business use case assume the existence of a Healthcare Provider Registry for organizations and individual providers.
- Scenarios Copied from HCSPDIR R1 - added 2001-03-22
Related Standards
- ASC X12 274 Health Care Provider Directory
- ANSI/HL7 V3 Personnel Management, Provider topic - message specification
- CMS National Provider Identifier page 3457
- 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
- OASIS ebXML Registry Information Model v2.0 -new 2010-12-23
- OASIS ebXML Registry Services Specification v2.0 -new 2010-12-23
- New Zealand HISO 10006 HPI Code Set - new 2011-02-16
- New Zealand HISO 10005 HPI Data Sett - new 2011-02-16'
Analysis Documents
- HITSP Information Interchange Subcommittee Interface to Provider Directory/Registry Harmonization Project
- Healthcare, Community Services and Provider Director Service Functional Profile, Release 1 mapped to HL7 Personnel Management
- Analysis of Registry Behavior - new 2010-12-20
- HL7 Healthcare, Community Services and Provider Directory mapped to HL7 V3 message standards - new 2011-03-22
May 2010 Ballot: Domain Analysis
The use cases that specify the main use cases regarding the use of registries in complex, inter-dependent ways:
- Registry Use Cases
- Infoway Use Cases new 20110111
- Registry Actors
- Glossary of Registry Terms
- Domain Analysis Model
Related Proposals
- Patient Registry Additional Query Parameters - approved
- AORTA Application Registry Use Case
- Person Registry Additional Query Parameter - approved