Social Security Administration (SSA) Experience with Provider Directory HIT Security and Privacy WG

Transcription

1 Social Security Administration (SSA) Experience with Provider Directory HIT Security and Privacy WG Presenters: Shanks Kande, Nitin Jain Date: 04/06/2011 1

2 Social Security Administration Use of Provider Directory Social Security Administration is a consumer of Provider Directory information to support its disability determination process. Currently, Social Security Administration uses an internally developed provider directory to support its production environment Provider Information useful to Social Security Administration: Individual and Organizational Provider Name, Aliases Multiple Addresses: Service locations, Medical records/administrative, Billing Contact Information: Mailing Address, Phone, Fax numbers. Relationship to HIE/HIO, affiliation to hospitals Electronic Service End Points: EHR end point, NHIN Direct s, NHIN Gateway URL, Home Community Identifiers etc. 2

3 Social Security Administration s efforts to build a standards based Provider Directory Developed a IHE Healthcare Provider Directory (HPD) Profile in 2010 Initiated and led the development of provider directory standards that provides interoperability & uniformity. Executed a Proof-of-Concept on HPD Performed interoperability tests with other vendors at IHE 2011 Connectathon Participants: Social Security Administration, Epic, Medicity, Siemens, Tiani-Cisco Demonstrated two use cases of HPD at HIMSS 2011 Social Security Administration: Authorized Release of Information to a Trusted Entity Urology Referral with Lab Specimen Report: Use of Provider Directory for provider to look up a specialist

4 Lessons Learned from HPD development Standards did not pose any significant technical and implementation issues due to commonly available tools Operational challenges related to provider information maintenance, currency, and data use rights Ambiguous results during provider identification requiring manual interventions and software matching algorithms. Need for consistent policies to manage provider directories in a federated environment Develop governance procedures for data source verification and data reconciliation

5 Why IHE? IHE Integrating the Healthcare Enterprise - an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE Profile describe the solution to a specific integration problem, and document the system roles (Actors), standards, and design details (transactions) for implementers to develop systems that cooperate to address that problem. Systems that implement IHE profiles solve interoperability issues. Profiles may be in one of the following stages: Development Trial Implementation Final Text Stable Retired / Deprecated

6 IHE HPD Profile Overview Provider Information Source ITI-59 -Provider Information Feed Provider Information Consumer ITI-58 - Provider Information Query 3 Actors (Functional Components) Provider Information Source Provider Information Consumer Provider Information Directory 2 IHE standards based Transaction Pairs (interactions) Provider Information Query Provider Information Feed Query (provider) Security and Privacy Organization Member of Individual Provider Provider Information Directory Query (Provider)

7 Information managed by HPD *The profile is extensible to accommodate additional business needs.

8 Organizational (Entity Level) Provider View has (1..N) Name has (0..N) Organizational Provider Owns (0..N) Relationship Group has (0..N) has (0..N) is a member of (0..N) Identifier Credential Specialty is composed of (0..N) is a member of (1..N) is a member of (0..N) Individual Provider Is located at (0..N) Sub-Organizations e.g. Facilities Addresses

9 Individual Provider View Individual Provider has (1..N) Name has (0..N) has (0..N) has (0..N) is a member of (0..N) owns (0..N) Identifier Relationship Group Organizational Provider Credential is located at (0..N) Specialty Addresses

10 Standards Adopted in HPD Profile Standard SDO Description ISO TC 215 : ISO/TS Health Informatics Lightweight Directory Access Protocol (LDAP) v3 Directory Services Markup Language (DSML v2) ISO IETF OASIS Defines the attributes of health professionals and providers to represent health care regulatory information, clinical credentials, multiple affiliations etc An open standard built on X.500 framework defines the messaging, operations and data schema for directory services. Systematic translation of LDAP s ASN.1 grammar (defined by RFC 2251) into XML-Schema. Simple Object Access Protocol (SOAP) v1.2 Personnel White Pages (PWP) W3.org IHE Protocol specification for exchanging structured information in the implementation of Web Services in computer networks. The Personnel White Pages Consumer may make a wide variety of queries and cascaded queries using LDAP. Intended for inside of an provider;

11 Why LDAP? LDAP easily supports high volume of directory lookups. Good tooling support to ease implementation: both commercial products and open source solutions available. LDAP standard is commonly used for the personnel directories within organizations. Federation solutions for LDAP are well defined in the IT industry to support federation of directories.

12 Why DSML v2? Open Standards based specification: OASIS Express LDAP requests and responses in XML format to allows for greater interoperability with other non-ldap directory services. DSML v2 messages can interact with a variety of LDAP based directories making HPD interface vendor agnostic. Easier to transport DSML messages over a variety of protocols including HTTP, JMS

13 Security and Privacy Considerations Implement and enforce policies and procedure to validate the provider information before it is stored and published by Provider Directory Capture and record audit trail events for the provider information submission. Supports Role based Access Control (RBAC) policies to authenticate data sources. Provider information in HPD is deemed public, so it can be open searchable. HPD content structure can be extended to include any non-public sensitive information that can be controlled by RBAC policies. The best practices for Infrastructure, Network Security, Operations management are suggested for directory deployment.

14 Q&A? Thank You! Contact: Shanks Kande: Security Administration.gov Nitin Jain: