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