November 10, 2009 SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT Health IT Provider Registry IHE Proposal Overview Proposed Editor: Shanks Kande, Nitin Jain (US Social Security Administration) November 10, 2009

SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 2 November 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 3 November 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 4 November 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 5 November 10, 2009 Use Cases: Strategic Drivers for health IT “meaningful use” Use CaseUse 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 6 November 10, 2009 Trusted Source Public Trusted Sources Commercial Federated Data Sourcing HITPR Secure Standards- based Secure Standards- based Physicians EMR Provider Information Lookup Hospitals HITPR Context Model Federal & State Agencies & Health Institutes Consumers Publish Provider Information

SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 7 November 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 8 November 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 9 November 10, 2009 Technical Approach: Extensible Metadata based registry

SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 10 November 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 Lookup Provider AuthenticationAuditing Transaction Actor

SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 11 November 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 12 November 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 13 November 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 14 November 10, 2009 Effort Estimate  Pages:  Complexity of Issues: Medium  Effort Estimate: Medium

SOCIAL SECURITY ADMINISTRATION-HIT SUPPORT 15 November 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 16 November 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