november 10, 2009 social security administration-hit support health it provider registry ihe...
TRANSCRIPT
November 10, 2009 SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT
Health IT Provider RegistryIHE Proposal Overview
Proposed Editor: Shanks Kande, Nitin Jain
(US Social Security Administration)November 10, 2009
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 2November 10, 2009
Health IT Provider Registry (HITPR) Profile Proposal
► The Problem domain
► Use Cases - Strategic Drivers
► HITPR Context Model
► HITPR Technical Approach
• Content Model
• Actors & Transactions
► Proposed Standards & Systems
► Challenges and Risks► Issues► Effort Estimate► Next Steps► Discussion Items
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 3November 10, 2009
The Problem domain Provider Identification Inefficiency:
► No standardized processes for electronically searching, using typical provider attributes, and with assurance, identifying the provider, location, credentials and method for communication.
► No standardized capability to accurately identify, for authorized users, the access points where provider information is electronically available for expediting end-to-end communications with providers.
Data Dissemination Issue: ► The existence of multiple provider sources, each one holding
different, key pieces of information.
► The existence of provider sources with duplicate information being collected independently of each other
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 4November 10, 2009
Health IT Provider Registry (HITPR) definition We envision HITPR as a unified directory of providers
containing identifiers, demographics, credentials, locations (physical, electronic), classifications, and relationship data
“Provider” is defined as medical services entities such as physicians, dentists, pharmacists, nurses, diagnostic imaging professionals as well as organizations such medical laboratories, hospitals, facilities etc.
HITPR provides directory services to systems over a network or an information exchange using standards based messages
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 5November 10, 2009
Use Cases: Strategic Drivers for health IT “meaningful use”
Use Case Use of HITPR Stakeholders
Social Security Administration Disability Determination
Identify claimant’s providers by demographics & affiliations
Locate providers’ electronic end points in the network to support directed electronic requests
Claimants, Providers, SSA, Health Information Exchanges, Social Services programs
Emergency Response Contact providers and identify “Medical Reservists”
Verify provider credentials
Citizens, Providers, Public health Officials, State & Local Epidemiologists, Response Workers
Consumer Access to Provider List Select provider of care list from registry to grant or deny access permissions
Alerts on provider demographic updates
Consumers, Families, PHR vendors, providers
E-Prescription Prescriber credentials (DEA) validation
Identify & communicate with prescribers on drug recall
Providers, Patients, Pharmaceuticals, Drug Safety Officials
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 6November 10, 2009
Trusted SourcePublic
Trusted SourcesCommercial
Federated Data Sourcing
HITPR
SecureStandards-
based
SecureStandards-
based
Physicians
EMR
ProviderInformation
Lookup
Hospitals
HITPR Context Model
Federal & State Agencies& Health Institutes
Consumers
Publish ProviderInformation
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 7November 10, 2009
HITPR Technical Approach Define Registry that provides:
► Content Model: An extensible metadata that defines the content of registry• properties, relationships, classifications (i.e., demographics,
physical, telecom and electronic addresses) to support ► Interoperable Transactions to perform basic data management
operations on the content• Query Lookup, Publish, Update, Subscribe and Notify, Audit
► Actors that interact together in support of the use case scenarios • Registry data Consumers and Source(s) that interact with
Registry
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 8November 10, 2009
Technical Approach: HITPR Content Model The HITPR Content Model supports the query for provider
based on properties, relationships, and classifications
Relationships
Properties
Classifications
Provider
Provider intends to include licensed individuals that
provide medical services, as well as medically related
facilities
This metadata defines
Properties or attributes for a
Provider This metadata defines relationships between Properties metadata.
This metadata classifies Properties metadata based on standard taxonomies to enable query based on
a particular classifier
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 9November 10, 2009
Technical Approach: Extensible Metadata based registry
Provider HITPR Metadata
Properties- Identifiers- Name, Alias- Location- Electronic end URLs- Specialty- Certificates- Status- User- defined
Relationships- Provider Credentials- Provider Affiliations- Geographic- Status - user-defined
Classifications- Provider Type- Location Type- Credential Type
Organization- Hospital- Lab- Practice- Radiology- Business Entity- Etc
Individual- Physician - Nurse- Lab Technician- Pharmacist- Physical Therapist - Etc
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 10November 10, 2009
Secure IT Infrastructure
HIT Provider Registry
Technical Approach: HITPR Actors and Transactions
Provider Registry Source
Provider Registry Consumer
Add/Update Provider
Notify of Change
Subscribe
LookupProvider
Authentication AuditingTransaction
Actor
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 11November 10, 2009
Proposed Standards & Systems HL7 v3 which covers message standards, interactions and the XML
data model for provider registry.
Lightweight Directory Access Protocol (LDAP) – defines the messaging protocol, operations and data schema for directory services.
UDDI standard- OASIS approved standard that specifies protocols for creating a registry for Web services, methods for controlling access to the registry, and a mechanism for distributing or delegating records to other registries. Current NHIN registry specification uses UDDI standard.
ANSI ASC X12 –standard transaction set for interoperable EDI with registry.
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 12November 10, 2009
Challenges and Risks Challenge in developing recommendations for the registry’s content,
messaging, and transmission components based on available, and sometimes competing, standards
Challenge in keeping initial scope and effort aligned with minimum needs for a functional registry while deferring additional needs to future phases.
Challenge in providing mechanisms for validating content with multiple authorized sources, such as:► State and local licensing bureaus► National Plan & Provider Enumeration System (using National Provider
Identifier)► Trusted Enterprise Master Person Indexes (EMPIs) ► Commercial Registry data ► Health Information Exchanges & Organizations
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 13November 10, 2009
Issues Scoping a data model structure to be deployed globally, while
anticipating the need for future expansion of metadata to support additional needs, including mechanisms for:► Designating provisional status until new updates are vetted
► Marking a record inactive
► Maintaining a history of changes
► Supporting ability to merge and unmerge records
► Securing control over update access
► Enforcing use of standardized vocabulary
Anticipating vital add-on capabilities such as HITPR support for directed queries to specific providers or groups of providers.
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 14November 10, 2009
Effort Estimate Pages: 40-50 Complexity of Issues: Medium Effort Estimate: Medium
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 15November 10, 2009
Next Steps Breakdown of tasks that need to be accomplished
► Define the Content Model of HITPR
► Evaluate standards for Content Model and Transactions
► Write detailed profile
SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 16November 10, 2009
Discussion Items Proposal Scope:
► Define a registry data model to facilitate unambiguous lookup and communications with a provider, comprised of a minimum required: • Content - properties, relationships, classifications (i.e., demographics,
physical, telecom and electronic addresses) to support • Actors – healthcare organizations (initially hospitals) and individuals
(initially physicians)• Transaction Services – Query Lookup, Publish, Update, Subscribe and
Notify, Audit Future Scope Possibilities:
► Expand property, relationship and classification metadata, (e.g. multiple current and past locations, naming aliases, affiliations, relationships, medical credential information)
► Validation of data with multiple trusted sources► Develop ID Validation to support provider self-input and update requests (to
a provisional input queue) ► Develop robust master-slave replication techniques