Patient ID Service http://design.patientidservice.us/
* Kantara Initiative * Healthcare Identity Assurance Work Group, Chairs: John Fraser, Pete Palmer, Rick Moore * Open ID Foundation of Japan, Nat Sakimura * My Partners at eCitizen * Dazza Greenwood * Daniel Bennett
http://design.patientidservice.us/
* Research * Survey * Iterate Design * Final Presentation (we are here) * November 10, 2011 during HIAWG Conference Call 1:00 to 2:00 EST; http://kantarainitiative.org/confluence/ display/healthidassurance/Home * Lay ground work for future phases
* Engage Participants * Raise Funding * Develop project plan to address Policy, Operating Rules/Agreements, Technology * Publish work under open source license
* Develop implementations * Write code, documentation, etc. * Certification * Promote project, develop community * Develop future roadmap
Kickoff Announcement SAVE THE DATE PATIENT IDENTITY SERVICE PROJECT LAUNCH A Key to Meaningful Use: Patient Identity and Authentication Building on Current Technology to Enable "Meaningful Use" Transactions Open Architecture for Citizen-Centered Solutions
* SAFE BioPharma: http://www.safe-biopharma.org/ * eAuthentication Initiative/eAuthentication Partnership * HSPD-12/OMB 11-11/FIPS 201/NIST SP 800-63/ FICAM, etc. * Liberty Alliance – Kantara Initiative Identity Assurance Framework * HIMSS/GSA National eAuthentication White Paper: http://www.himss.org/content/files/ GSAwhitepaper.pdf
* The Markle Foundation calls it, “A Critical Problem of the Digital Age.” CT2: Authentication of Consumers http://www.markle.org/sites/default/files/ CT2.pdf * Health IT Standards Panel: Identity Credentials Management (ICM) subcommittee of Security, Privacy and Infrastructure Committee, http://www.hitsp.org/ * National Strategy for Trusted Identities in Cyberspace, http://www.nist.gov/nstic/, http://www.nstic.us/
* Leverage the work of the Kantara Initiative to solve national (international?) problem * Healthcare Identity Assurance Work Group & eCitizen Foundation, OpenID of Japan collaboration * Design, Implement, Publish, Share an Open Architecture for Patient Identity addressing Business, Legal, and Technical requirements * Develop at least three implementations of PIDS to demonstrate interoperability and obtain certification
* Architecture to allow flexibility in choice of components that meet functional requirements. * Focus on use of existing business, legal and technology components to address immediate and short-term needs for patient identity functions. * Leverage existing credentials by providing functionality to attain Asusrance Level 3 * Facilitate healthcare providers' meeting of "Meaningful Use" requirements and in the implementation of Health Information Exchanges, Electronic Health Record (EHR) or Personal Health Record (PHR) systems. * Deliver capabilities to patients to participate significantly in their own healthcare, access, and to the extent appropriate, control their personal health information. * Identify gaps are identified and new applications for the architecture and develop further efforts to address these needs.
* A student attending college out of state requires medical treatment. Information and records of prior treatment from her home state doctor will be helpful in the new case. The student chooses to request the prior records, receiving a copy, storing these in a personal health record and forwarding a copy to the new doctor.
* Project Materials * The PIDS Design Phase included research and inquiry as part of the discovery process to develop and define the needs, requirements and constraints to pass forward to the implementation phase. * The PIDS project commenced with an Online Launch Event, at which the principals described the overview and intentions for the project. * Much of the information related to this research and other project materials are available at the eCitizen Foundation's Patient Identity Page. This research included a field survey. In addition, the following eCitizen Research Paper on URL’s for Electronic Health Records provides a description of the technical approach to using the architecture of the web as part of the design assumptions for this identity service: http://ecitizenproject.org/ideafactory/urls-for-electronic- health-records
* Overview of Solution Design: * The design principles for the Patient ID Service are to create an open architecture, leveraging open standards, for a citizen-centered solution. As such, the proposed design puts the user - in this case a patient - in the driver’s seat. The PIDS design 1) empowers the user to configure important aspects of a personal identity account, 2) enables relying parties such as providers of patient portals, to accept the PIDS as a log- in for the patient, and 3) can be used by the patient to both organize their many health related identifiers and permissions as well as to access many different applications and services.
* Outline of PIDS Sign-Up and Usage Process * Patient Creates a voluntary PIDS Account * Patient is issued PIDS OpenID Identifier, or External OpenID is bound to PIDS account * Patient inputs additional healthcare relevant identifiers into PIDS "wallet" * External Authentication Tokens are bound to PIDS account * Patient configures permissions for PIDS account * Patient logs in to Relying Party systems with PIDS credential * Relying Party challenges for a higher level of authentication (optional) * Patient generates reports from PIDS system (activity logs, linked accounts)
* Technical Components * A simple account system with identity information from each account holding patient information, including first, last name, phone, address, etc. * A URI/URL for each Patient Account * SAML Service, such as Shibboleth, capable of sending and receiving assertions according to the NwHIN standards
* PIDS Credential, Identifier and Token Capability * An OpenID service * An Advanced Credentialing and Token issuance or adoption service (enabling a patient to use, bind and/or link different identity tokens to their PIDS account), for example: * X.509v3 digital certificate * Registered Mobile Phone for voice and/or text and/or keypad-based verification * Registered Smart Phone for Mobile Phone functions plus application functions * RSA Data Security Key Fob * PIV, PIV-I or other variations of these Cards * Authentication as a Service account linkage, enabling the account credentials to be linked to KBA, crypto-based and other methods * Authorization as a Service account linkage, enabling the account credential to be linked to UACS/RBAC and XACML types of services * eSignature Service, enabling the use of credential to assent to or otherwise approve a document, signify consent or perform other related transactions * Credential Suspension/De-linking/De-binding and Termination Service * (option) Time Stamp Service and other real-time audit-friendly tools (e.g. GIS, HTTP logs, etc) * OpenID Connect and Oauth Services (as they come available) * Audit and Logging Service
* PIDS work will Identify Gaps * One such is Step Up Authentication * Working with OASIS “Trust Elevation Technical Committee” * Open Identity Attribute Exchange Summit * http://www.eventbrite.com/event/ 2266130056
http://design.patientidservice.us/
MIT Interim Session Coding sprint for development of function components of use in PIDS
* Engage Participants * Raise Funding * Develop project plan to address Policy, Operating Rules/Agreements, Technology * Publish work under open source license
* Develop implementations * Write code, documentation, etc. * Certification * Promote project, develop community * Develop future roadmap
University of Texas
* UT , Austin - Center for Identity, http://identity.utexas.edu/ * ID360, ID360.us * Conference - Late April
* CEO, eCitizen Foundation, * http://www.ecitizenfoundation.org/ * dancombs@ecitizenfoundation.org * dancombs1@gmail.com
Recommend
More recommend
