Open Architecture for a Patient ID Service

texturegainfulMobile - Wireless

Dec 10, 2013 (3 years and 9 months ago)

110 views


Open Architecture for a
Patient ID Service


Research and Design Report


Version 0.81, September 12, 2011



Prepared by the eCitizen Foundation


A project of:


The Kantara Initiative


The Open ID Foundation of Japan




Executive

Summary

Introduction

Patient

Identity

Patient

Identity

Service

(
PIDS
)

Goals

Open

Architecture

Layered

Approach

and

Modular

Design

Requirements

and

Constraints

Overview

Field

Survey

Requirements

Interviews

Initial

Use

Case

and

Additional

Suggested

Use

Cases

Legal

Prohibition

on

National

Patient

ID

Patient

Advocacy

Perspective

and

Individual

End
-
User

Needs

Architectural

Design

Solution

Functional

Description

from

Patient

Perspective

Functional

Description
:
Relying

Party

Perspective

Three

Uses

of

PIDS

by

Relying

Parties

PIDS

Needed

for

Inter
-
mediating

All

Patient

Access

to

Relying

Party

PIDS

Needed

to

Match

Identity

to

Internal

Patient

User

in

Relying

Party

System

PIDS

Native

for

Relying

Party

System

Functional

Description
:
External

Credential

Provider

Perspective

Actors

and

Elements

of

Design

Solution

Technical

Components

Interfaces
,
Connectors

and

Adapters

Architectural

Superstructure

Modular

Component

Approach

General

Security

Requirements

Enrollment

and

Voluntary

Linking

Existing

Healthcare

Identifiers

to

Account

Process

for

Enrollment

Linkage

to

Identity

Credentials

and

Token

Enrollment

and

Voluntary

Linking

Existing

Healthcare

Identifiers

to

Account

Legal

Architecture

for

the

Patient

ID

Service

Legal

Rights

and

Obligations

Major

topics

Roles

and

Parties

Layers

1.
Statutory

and

Regulatory

Overlay

2.
Enterprise

Contractual

Overlay

3.
Consents
,
Acknowledgement

and

Approval

Management

4.
Privacy
,
Confidentiality

&
Privilege

5.
Individual

Identifiers
,
Authentication

and

Identity

Management

Standard

Forms

and

Checklists

Configuration

Management

Emergency

Response

and

Continuity

Planning

Portability

of

ID
,
Preferences

and

Data

Education
,
Training

and

Support

Multilateral

Contractual

Dimension

1.
When

PIDS

is

used

as

a

simplified

log
-
in

for

consumer

apps

and

personal

health

records

integration
:

2.
When

PIDS

is

used

as

a

simplified

log
-
in

for

employee

access

to

personal

health

records

or

electronic

medical

records

held

by

or

on

behalf

of

an

employer
-
insurer
:

3.
When

PIDS

is

used

as

simplified

log
-
in

to

a

hospital

or

clinic

patient

portal

for

access

to

one

s

own

electronic

medical

records

and

to

conduct

related

transactions
:

Operating

Rules

and

Trust

Framework

Outline

Contact

Information

and

Attribution

Field

Survey

Appendices

Background

Patient

Identity

Background

SAFE

HIMSS
/
GSA

National

eAuthentication

White

Paper

HITSP

ICM

Kantara

and

the

HIAWG

NSTIC





Executive Summary

(to be developed)


A brief "concept overview" video of this project, produced in collaboration with the MIT New
Media Medicine group, is embedded at the top of this explanatory post:

http
://
www
.
civics
.
com
/2011/01/
open
-
architecture
-
for
-
patient
-
centered
-
identity
-
presented
-
at
-
mit
.
html
.






Lots of people doing lots of work.



Developing such a project as PIDS requires leveraging prior good

work. Mentioning only a
few efforts among hundreds or thousands risks omitting important items. With that in mind
there are a few that bear mentioning here and invite further study and exploration, both in
the appendix of this document and in the websites

and documentation associated with
these efforts. The following have been used to inform and guide the development of PIDS
as described in this document:


1. SAFE BioPharma (Signatures and Access for Everyone),

http
://
www
.
safe
-
biopharma
.
org
/
;

2. U.S.
Government: e
-
Authentication Initiative, Federal Bridge Certificate Authority, Federal
Identity, Credential, and Access Management, and IDmanagement.gov,

http
://
www
.
idmanagement
.
gov
/
;

3. e
-
Authentication Partnership;

4. HIMSS/GSA collaboration, "National e
-
Authentication Whitepaper,"

http
://
www
.
himss
.
org
/
content
/
files
/
GSAwhitepaper
.
pdf
;

5. Liberty Alliance/Kantara Initiative, especially the Identity Assurance Framework,

http
://
kantarainitiative
.
org
/
confluence
/
display
/
GI
/
Identity
+
Assurance
+
Framework
+
v
2.0
, and
the Healthcare Identity Assurance Workgroup,

http
://
kantarainitiative
.
org
/
confluence
/
display
/
healthidassurance
/
Home
;

6. Markle Foundation Common Framework, especially component CT2, "Authentication of
Consu
mers;"

http
://
www
.
markle
.
org
/
sites
/
default
/
files
/
CT
2.
pdf
;

7. Health Information Technology Standards Panel,

http
:
//
www
.
hitsp
.
org
/

-

Identity
Credentials Management subcommittee;

8. National Strategy for Trusted Identities in Cyberspace (NSTIC),

http
://
www
.
nist
.
gov
/
nstic
/
.


Thank you! We could not have done it without you!




Introduction

The Markle Foundation in its Health Consumer Authentication publication (available at

http
://
www
.
markle
.
org
/
health
/
markle
-
common
-
framework
/
connecting
-
consumers
/
ct
2)

of
January, 2008 concluded that there is a "Need for a New Approach" to patient identification and
authentication in the evolving networked world of healthcare. The Kantar
a Initiative's Healthcare
Identity Assurance Workgroup and the eCitizen Foundation created a collaboration to develop a
new approach by initiating the Patient Identity Service (PIDS) project. The project benefits from
and leverages significant previous wor
k done to fill the need for patient identification and
authentication.


Healthcare will be conducted in an increasingly networked environment in which digital
information moves by way of wires and waves rather than in physical documents passed hand
to
hand. Progress has been made developing the standards, protocols, processes, technology,
and business arrangements that determine how health information will travel from point to point
but there remains a significant functional gap encompassing identificat
ion and authentication of
participants, especially patients. The PIDS project will fill some of this particular gap. The focus
will be on patients, but PIDS could be used as well by any participants in healthcare or other
sectors with little or no adaptati
on.


Patient Identity


How do you know who a patient is? Why know who a patient is? Is the person who is requesting
a record or treatment or services truly Jane Doe or John Smith as claimed? The need for patient
identification and authentication has long b
een recognized. The Markle Foundation calls it, "A
Critical Problem of the Digital Age." Is the right treatment being provided to the right person? Is
the correct account belonging to the right person being charged for treatment provided? Is the
proper inf
ormation about the right person being used to determine treatment? Is the right record
delivered to the right person? During the 1990's some in the U.S. Government recognized a
need for patient identification and took action. That action was quickly follo
wed by undoing what
it had done and ensuring that little more would be accomplished in this area by U.S.
Government for years to come. The need did not vanish; it has only grown more important,
more urgent, more costly, even more deadly. Public and privat
e sectors have borne the effects
of this unaddressed need. Lack of a means to identify and authenticate individuals results in
improper treatment, death, fraud, waste and abuse. Lack of an interoperable means to deliver
these identity functions results in
individual tragedy and sufffering; collectively much higher
costs; and significant roadblocks to efficient, effective use of information.


During the past two decades there have been numerous groups convened, whitepapers written,
studies undertaken on iden
tification and authentication of individuals both in and beyond
healthcare. Tremendous amounts of work have been done to provide the business, legal and
technical components of identification and authentication. The Clinton, Bush and Obama
administrations,

State, Local, and Tribal Governments in the U.S. have developed programs,
and supported work on these issues. Various international collaborations have been created.
Standards groups have created standards, policy has been written, operating rules drafted
, and
technology developed, bought and implemented. The private sector has devoted billions of
dollars and related resources to addressing these issues.
And still there is not a simple,
straightforward, common way for these components to work together
so that the point or
local solutions can inter
-
operate.


Patient Identity Service (PIDS)

This PIDS Phase 1 effort is to research and design an open architecture for a service
incorporating common functions of user authentication adapted for specific use of

patients in the
healthcare environment. It became evident during research that there are other capabilities
necessary to enhance the utility and adoption of the PIDS architecture. Some examples are
enabling interoperation among individual instances of the

service and interaction with major
healthcare networks such as NwHIN; and "bridging the gap" or translating among the ways of
addressing patients, as users, entities, objects, or bits of information related to health records. It
is intended that individua
l instances of the service based on the PIDS architecture will be
implemented in a variety of specific contexts. A PIDS implementation could serve as a
component of an electronic health record; as part of a patient portal provided by a health service
provi
der such as a hospital, clinic, insurance provider, government health information or
insurance exchange, or various other provider systems; or as a component of a standalone
authentication service.


The architecture will incorporate and advance several key

principles:


1. Enhance User Experience


a. Improve users' participation in their own healthcare;


b. Facilitate privacy and user control of personal information;


c. Improve security of users' interactions;



2. Flexibility of choice


Users will have a v
ariety of choices to meet individual requirements and desires such as which
credential to use or where feasible what information to share with whom;


a. System implementers will have great flexibility in choice of technical components to meet
functional
requirements within the architecture;



3. Interoperability
-

The PIDS Architecture should facilitate interoperability


Implementations of the PIDS architecture will interoperate with each other


a. The architecture will incorporate existing standards and
adapt to future standards to foster
interoperability with various peer systems



4. Green" Design


* Reuse existing concepts, credentials, code, standards, etc.;


a. Recycle best practices;


b. Limit new construction to necessities;


i. Step
-
up Authenticat
ion



The architecture design effort began with extensive research and requirements gathering,
including interviews of various stakeholders, collection and study of related past work and
documents, several rounds of discussion and iteration of design eleme
nts. Early on a use case
was drafted that would inform and guide development of the architecture and force the
resolution of a variety of issues encountered and yet to be encountered in the increasingly
networked healthcare environment. The use case is as
follows:


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, storin
g these in a personal health record and
forwarding a copy to the new doctor.


There are potentially many different ways to conduct this transaction. Several key concepts
(ideas, requirements?) were incorporated into or added onto this simple use case inten
ded to
increase the utility and likelihood of adoption of the PIDS architecture. The use case is based on
Meaningful Use requirements for responding to requests for health records. The PIDS
architecture is based on the Kantara Initiative's Identity Assuran
ce Framework (IAF).
Additionally, it incorporates and overcomes a number of hurdles to be addressed in
implementing the National Strategy for Trusted Identities (NSTIC) in Cyberspace. Through
exploring the permutations and meeting the resulting requirement
s of this use case the PIDS
architecture provides important and necessary functions for major U.S. national and
international trends in healthcare.


The PIDS architecture design is the first of several planned phases. The next phase is
underway to engage g
overnment and private sector participants and stakeholders including
patients and their advocates. The PIDS effort will continue in several tracks, for example,
collaborating to create a standard for step
-
authentication, filling out the legal component of
the
architecture and implementing instances of PIDS to demonstrate the viability of the architecture
and to obtain certification of one or more of the implementations. The architecture and related
documentation, including any code developed will be publish
ed for general use.


Goals


The PIDS project is being planned and implemented to meet the following goals:


∙ Demonstrate the feasibility of the Kantara Initiative's Identity Assurance Framework


∙ Demonstrate the feasibility of major assertions of the
National Strategy for Trusted Identities in
Cyberspace


∙ Demonstrate the ability to create a service that will recognize and accept a variety of
credentials, conduct appropriate processing of credentials and users when needed, and employ
the results of th
ose processes to conduct "Meaningful Use" transactions among other functions.


∙ Create one or more model implementations that will be useful for authentication requirements
in the development of Health Information Exchanges and Health Benefit Exchanges an
d other
systems, will allow for testing and demonstration of interoperability and certification.


∙ Engage a variety of stakeholders and collaborators in the Public and Private sectors to create
a widely useful model implementation PIDS that will incorpora
te input from these and other
participants.


∙ Identify gaps and necessary components not yet available that will serve as the subjects for
future efforts.


Open Architecture


By tracking to the National Strategy for Trusted Identities in Cyberspace and in
dustry standards.
Develop “components” meeting the strategy and related policies that can be implemented by
different vendors using different technologies that meet the requirements and constraints.


Relevant Federal Health Standards, including ONC Meaning
ful Use, The Direct Project, CMS
Authentication and NHIN Gateways:


Relevant Federal Identity Standards Including: 800
-
63
-
1, 201, ICAM and PKI


Relevant Standards of the W3C, OASIS and IETF


Identity Ecosystem Framework, Steering Committee, Trust Framework
, Accreditation Authority
and Trust Scheme


National Real
-
Time Service Oriented Infrastructure at the Business, Legal and Technical Layers


Layered Approach and Modular Design


By carefully separating th
e identifiers used, the authentication methods and the authorization
and access control aspects of the Patient ID Service, this open architecture enables flexible and
tailored applications of identity management tools.


Requirements and Constraints


[Under

development]


Overview


Eset eiusmod tempor incidunt et labore et dolore magna aliquam. Ut enim ad minim veniam,
quis nostrud exerc. Irure dolor in reprehend incididunt ut labore et dolore magna aliqua. Ut enim
ad minim veniam, quis nostrud exercitation u
llamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse molestaie cillum. Tia
non ob ea soluad incommod quae egen ium improb fugiend.


Field Survey


Duis autem vel eum iriure dolor in hendrerit

in vulputate velit esse molestie consequat. Et
harumd dereud facilis est er expedit distinct. Nam liber te conscient to factor tum poen legum
odioque civiuda et tam.


Requirements Interviews


Neque pecun modut est neque nonor et imper ned libidig met, con
sectetur adipiscing elit, sed ut
labore et dolore magna aliquam is nostrud exercitation ullam mmodo consequet.


Initial Use Case and Additional Suggested Use Cases


Eset eiusmod tempor incidunt et labore et dolore magna aliquam. Ut enim ad minim veniam,
qu
is nostrud exerc. Irure dolor in reprehend incididunt ut labore et dolore magna aliqua. Ut enim
ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat.


Legal Prohibition on National Patient ID


Eset eiusmod tem
por incidunt et labore et dolore magna aliquam. Ut enim ad minim veniam,
quis nostrud exerc. Irure dolor in reprehend incididunt ut labore et magna aliqua.


Patient Advocacy Perspective and Individual End
-
User Needs


[NOTE: The eCitizen Foundation has been

in communication with Patient Advocacy community
and has solicited interest in receiving their feedback to assist in drafting this section. Once
feedback is received from version 0.1, we intend to seek their feedback for this section.]

Architectural Desig
n Solution


Functional Description from Patient Perspective


The wallet and keys for health services.{graphic}


A patient will be connected to the Internet through a device for every aspect of PIDS. Prior to
access to data, the patient will have to be enro
lled in a PIDS system which will be either part of
or separate from the initial site that the patient has logged into. The process of enrollment for
the patient should be as short as possible, but must include creating a PIDS account with a
unique identifi
er and primary authentication method.


Initially or over time, the patient will help to find all of the necessary identifiers and attributes
necessary for PIDS to provide services to the patient. And to create controls sufficient to protect
privacy and sec
urity meeting the needs of the patient, relying party and regulating entities, the
patent will help with identifying, authorizing and binding of new and existing credentials for
authentication.


From that point on the PIDS service will assist the patient i
n obtaining, storing, copying,
forwarding and communicating health information with services provided by regulated health
care providers and other services the patient chooses to use. For the patient, PIDS is his or her
wallet and keys for accessing health

services electronically as easily as possible while providing
private and secure online transactions. And since PIDS is centered on the patient, it simplifies
for them identity and authentication, similar to taking out id’s, credit cards, loyalty cards an
d
replacing as they want or need.


Patient Creates PIDS Account


Patient is issued PIDS OpenID Identifier


External OpenID is bound to PIDS account


Patient Logs in to Relying Party System with PIDS credential (if supported)


Relying Party Challenges for h
igher level authentication


Patient configures permissions for PIDS account


Look up permission


Emergency look up override


Patient generates reports from PIDS system (activity logs, linked accounts)


Patient binds external credentials to PIDS account


SAFE


PIV


Shibboleth


Mobile phone


Smart phone


Medical Professional PIDS patient discovery service (for example emergency lookup)


Below is a rendering of how a web
-
based health and wellness service could support use of a
PIDS login, along with other Op
enID based log
-
in services:


Below is a conceptual depiction of how a patient portal (e.g. on a hospital or insurer system)
could support an alternative single sign on login using PIDS:


Functional Description: Relying Party Perspective

PIDS appears as
the patient (meaningful use/HIPAA/DURSA/NSTIC compliant and fully
authenticated patient/customer) to the relying party. {graphic}


A health provider will want to be sure that the online party requesting or receiving services is
actually the intended patien
t. PIDS will provide all of the needed credentials and authentication
that is needed by the relying party. In many cases, relying parties will allow access through
using a SAML/Shibboleth/OpenID/OAuth/Connect/Direct process. In addition, the PIDS service
will allow patient discovery and opportunity to communicate Meaningful Use required
information.


Three Uses of PIDS by Relying Parties


PIDS Needed for Inter
-
mediating All Patient Access to Relying Party

If the Relying Party either does not have a user ty
pe designated as a patient or that is
inaccessible to PIDS, then PIDS will intermediates access, mapping to attributes and allowing
limited access and/or email between patient and providers (Direct).


PIDS Needed to Match Identity to Internal Patient User
in Relying Party System

If the Relying Party does have an internal user type for patients, the PIDS service will first match
identifiers and attributes, and then use or create as is necessary, a patient user. Using the
access control system of the Relying
Party, the patient will then have a predetermined access
and ability to communicate with the provider(s).



PIDS Native for Relying Party System

Either the Relying Party that the PIDS system is primarily connected to or another provider that
uses PIDS from

other parties natively (for example, by use of OpenID PIDS identifiers). Based
on accepted standards for transactions like with HITSP, the Relying Party allows for
transactions with the PIDS enabled patient to interact with their services, including for t
he
Meaningful Use requirements.


For each of these types of Relying Parties, limitations will be specified by the PIDS system and
will match any agreements made between the Relying Party and PIDS connected organizations
through a framework, multi
-
party or
bilateral agreements. In addition the PIDS service will
comply with relevant laws and policies.


Outline of PIDS Process


Patient Creates PIDS Account

∙ Patient is issued PIDS OpenID Identifier

∙ External OpenID is bound to PIDS account

Pat
ient Logs in to Relying Party System with PIDS credential (if supported)

Relying Party Challenges for higher level authentication

Patient configures permissions for PIDS account

∙ Look up permission

∙ Emergency look up override

Patient gene
rates reports from PIDS system (activity logs, linked accounts)

Patient binds external credentials to PIDS account

∙ SAFE

∙ PIV

∙ Shibboleth

∙ Mobile phone

∙ Smart phone

Medical Professional PIDS patient discovery se
rvice (for example emergency lookup)

Below is a rendering of how a web
-
based health and wellness service could support use of a
PIDS login, along with other OpenID based log
-
in services:



Functional Description: External Credential Provider
Perspective


[
NOTE: To Be Decided]


Actors and Elements of Design Solution


The actors and elements of the PIDS component include:


Patient


PHR Service


PIDS services


Registration Authority


Identity Proofing


Enrollment


Issuance (or adoption) of Identifier


Issuance

(or adoption) of Identity Credential


Authentication registration, discovery and implementation service


Authorization and attribute registration, discovery and implementation service (e.g. PDP with
XACML)


Relying Parties outside of NwHIN


Relying Party
Registries


Health care standard APIs or translation services


Health care providers within NHIN


Personal health and wellness devices


Smart Phone health and wellness apps


Other services on the web


Technical Components


A simple account system with iden
tity information from each account holding patient
information, including first, last name, phone, address, etc.


A URI/URL for each Patient Account


A SAML 2.0 service that can send each Relying Party (Shibboleth)


PIDS URI/URL or OID and


either the
Patient URI/URL or another OID to that Relying Party


PIDS Credentials


An OpenID service


An Advanced Credential issuance or adoption service (enabling a patient to use, bind and/or
link different identity credentials to their PIDS account)


Advanced cred
ential 1 is an X.509v3 digital certificate (optional)


Advanced credential 2a is a Registered Mobile Phone for voice and/or text and/or keypad
-
based
verification (optional)


Advanced credential 2b is a Registered Smart Phone for 2a functions plus... (optio
nal)


Advanced credential 3 is an RSA Data Security Key Fob (optional)


Advanced credential 4 is a PIV, PIV
-
I or other variations of these Cards (optional)


(option) An Authentication as a Service account linkage, enabling the account credentials to be
lin
ked to KBA, crypto
-
based and other methods


(option) An Authorization as a Service account linkage, enabling the account credential to be
linked to UACS/RBAC and XACML types of services


(option) An eSignature Service, enabling the use of credential to ass
ent 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, e
tc)


Audit and Logging Service


OpenID Connect and Oauth Services


Interfaces, Connectors and Adapters


NwHIN Gateway


Direct Project


Indivo/Dossia


Microsoft Health Vault


Health & Wellness Apps on Android and iPhone Devices


Personal Medical Devices and

Appliances


Back
-
End EMR, EHR and MPI Systems


Architectural Superstructure


{architectural design diagram goes here.}

Modular Component Approach


PIDS Component Contains Services and Data Stores


Legal and Policy Interoperability and Modularity


Inte
rfaces Points With External Systems/Services


Features of ID Service Component Approach:


Capacity to Upgrade Components and Not Interfaces


Capacity to Replace Component and Not Interfaces


Capacity to Maintain Component and Replace Interfaces


General Se
curity Requirements


In addition to the standard security included by protocols such as SAML, the PIDS system
should take a holistic approach to information security, ensuring points such as those described
by the recent Inspector General’s report on “Audi
t of Information Technology Security Included
in Health Information Technology Standards” are adequately addressed. Some of the key
findings from that report include the following issues:


encrypting data stored on mobile devices, such as compact disks (CD
) and thumb drives;


requiring two
-
factor authentication when remotely accessing an HIT system;


patching the operating systems (OS) of computer systems that process and store EHR.


unprotected wireless networks,


lack of vendor support for OSs,


inadequ
ate system patching,


outdated or missing antivirus software,


lack of encryption of data on portable devices and media,


lack of system event logging or review,


shared user accounts,


excessive user access and administrative rights.


Enrollment and Volu
ntary Linking
Existing Healthcare Identifiers to
Account


It is intended that an instance of PIDS can be implemented in a variety of environments. For
example, PIDS may be hosted and implemented by a PHR Provider (in effect, using PIDS as
the PHR account a
nd log
-
in solution), or a Medical Provider, an HIE, HBE (HIX) or other health
information handler (HIH) or by an Independent Identity Provider.


Process for Enrollment


A patient will need to establish their identity for PIDS by enrolling. Given that the P
IDS identity
will be used primarily as a common source point for logging into other systems that will have an
existing account and relationship with the Patient and will have done their own enrollment
process appropriate to their needs, the required enroll
ment process to create an account on a
PIDS system would be relatively light weight.


The process for patient enrollment will vary depending on the type of PIDS hosting organization:


If the instance of PIDS is hosted by a PHR provider, then the PHR provid
er will pass on the
identifier, attributes and credentials that the PHR provider uses in their local web service to their
internal PIDS system..


If the instance of PIDS is hosted by a Medical Service Provider, then the Medical Service
Provider will pass o
n the identifier, attributes, credentials and, if the data is available, any NHIN
OID, UACS or other data related to the patient.


If the instance of PIDS is hosted by an Independent Identity Provider (e.g. bank, AARP,
workplace HR department, credit uni
on, etc), then the provider will pass on the identifier,
attributes and credentials used by the organization for their employees or members to their
PIDS system.


Linkage to Identity Credentials and Token


By design, the PIDS component will support the use

of externally issued credentials. This
capability enables the Patient to use the same mechanisms of authentication that they already
possess and enables Relying Parties to leverage existing credentials, without the need to issue
it themselves. One of the
benefits of this extensible method of binding existing credentials to a
PIDS account is that Relying Parties for whom it is important, can use highest level of
assurance credential available without the need to issue such credentials themselves.


Enrollmen
t and Voluntary Linking Existing Healthcare
Identifiers to Account


After the enrollment process, the PIDS service provides OpenID SSO service as well as OAuth
2.0 process to exchange information with other systems. The OpenID identifier will be bound to
a
ny data being moved through OAuth from one service to the other.



Legal Architecture for the Patient ID
Service

Legal Rights and Obligations


Major topics



Liability and Indemnification



Ombuds and Administrative Recourse



Tort, Contract and Constitutional C
laims



Roles and Parties



The Patient



The Clinical Provider



The Technology and Service Provider



The Private Insurer



The Employer as Insurer (Dossia example)



The Government as Insurer (VA, SSA, HHS)





Layers


1. Statutory and Regulatory Overlay



HIPAA



Covered entities



Consents and Basic Rules (link to them)




ARRA



Meaningful Use



ACO (patient involvement in governance, a legal dimension)




Tech driven legal issues from NwHIN Onboarding and Direct/Connect


HHS Prohibition



Cite to rule



Patient ID Group



L
argely irrelevant due to legal architecture (out of scope)




Non
-
Medical Field Privacy and Applicable Public Laws



ECPA



ID Theft



Consumer Protection



Forgery and Illegal Impersonation



Right to Name and Identity Sovereignty (Common Law)





2. Enterprise Con
tractual Overlay



Existing Provider Agreements


Coming ACO Agreements and Governance


Patient Portal Terms and Conditions and Privacy Policies


Patient Agreement



3. Consents, Acknowledgement and Approval Management



Consent Assertion Markup Language



New
Media Medicine Group User
-
Centered Consent Management



OASIS eContracts Assent with eSignature Approach and W3C Signatures



4. Privacy, Confidentiality & Privilege



Protected Records and Information



Obligatory Access and Reporting



Judiciary Privilege



5. I
ndividual Identifiers, Authentication and Identity Management


Legal context of the identifiers



Social Security Number



VUHID



Hospital Number



Insurance Number



Master Patient Index Number



Other Healthcare Identifiers (VA, Clinics, Small Officers, etc)




Leg
al context related to sharing and proving identifiers



Validation of Identifiers



Authentication of Person Identified



Legal Issues Related to Aggregation of Identifiers



Legal Issues Related to Sharing of Identifiers



Passive Sharing



Active Sharing



Patient Con
trol



Audit and Reporting



Legal Issues Related to Linking Identifiers with Down Stream Identity Management




Standard Forms and Checklists



Configuration Management



Legal audit and directives related to configuration management



Default settings



User warni
ngs, alerts and other notices



User acknowledgements and binding assents



Configuration of Electronic Agents as Proxy for Later Assents



Emergency Response and Continuity Planning



Records management requirements



Distributed and Off
-
Site Backup



Disaster reco
very and continuity



Manual process and paper records emergency reversion plan




Portability of ID, Preferences and Data



Data Portability



Identity Portability



Identifier Portability



Authentication Portability



Customization, Personalization and Preferences
Portability



Cross
-
Boundary Authorization Standardization with XACM



Education, Training and Support



sd



Multilateral Contractual Dimension


Because the PIDS approach is open and flexible, the number and types of legal contexts within
which PIDS may opera
te are varied. Depending upon the context of the legal environment in
which PIDS is operating, different legal issues and prospects arise. There are some elements,
however, that would be common. Below we discuss the legal dimension based upon context
and h
ighlight the common elements or decision points.


1. When PIDS is used as a simplified log
-
in for consumer apps and
personal health records integration:


a Mobile Apps:


b. [Discuss the apple and android apps marketplace privacy and consumer legal issues]


c. Integrated vs External Personal Health Records


d. [Discuss the API and legal overlays for getting data into external PHR’s]


e. Cloud
-
Based Apps


f. [Discuss the Cloud Security and Legal issues that arise]


g. Consumer Medical Devices


h. [Discuss the

use case in the Media Lab New Media Medicine video]


2. When PIDS is used as a simplified log
-
in for employee access to
personal health records or electronic medical records held by or on
behalf of an employer
-
insurer:


a. Federating with Enterprise Direc
tory and Other Employee Account Systems


b. [Use the InCommon federation as an example, focused on the enterprise directory guidance]


c. Portability and Privacy


d. [Highlight the DOSIA use case and “life
-
long” service vs portability and export]


e. [Work
place privacy overview and cross
-
walk to medical and other protected data]


f. Integration With External Insurers and Providers



Federating identity from an enterprise for use by insurers and providers is still a novel use case,
however, much can be learn
ed from the existing cross
-
boundary enterprise identity federations
for employees. In this case, given that the insurer would be operating under a master contract of
some kind with the employer, most of the legal and regulatory issues would likely be addre
ssed
in that higher level agreement. The insurer, in this case, could either be set up to pass back the
identity assertions from the employer on to providers or the providers could be set up to receive
the identity assertions from the employer directly. If

the identity assertions were transmitted in a
chain to the provider from the employer through the insurer, then a down
-
stream relying party
agreement would be needed by the provider to bound liability and ensure security. If the
provider received the iden
tity assertions directly from the employer, then the provider would
undergo some kind of “on
-
boarding” process to the employers federated identity program and at
that time would conclude the relevant legal contracts. New and emerging business models,
inclu
ding novel combinations of organizations through ACO and other vendor
-
driven
intermediary and transaction processor services may further modify or complicate the above
scenarios.


3. When PIDS is used as simplified log
-
in to a hospital or clinic patient
po
rtal for access to one’s own electronic medical records and to
conduct related transactions:


a. Meaningful Use


b. DURSA


c. HIPAA


Common to all of these scenarios is the need for the Patient to agree to use a PIDS service.
This agreement must clearly an
d simply describe what personal information the Patient will
share, how it will be used and the Patient’s ongoing rights and responsibilities with respect to
use of the system. In addition, in all scenarios there would be a service provider hosting PIDS
fo
r use by the Patient. This service provider would be a counter
-
party to the Patient agreement,
and would be responsible for abiding by the operational, privacy, security and other terms of the
Patient agreement as well as setting up or opting into the fede
rated systems with which PIDS
would interoperate.


Operating Rules and Trust Framework

Outline


Governance


Scope and Application


Dispute Resolution and Recourse


Records Retention and Audit


Participation Agreements:


Patients


Relying Parties


Providers


Apps/Services


Privacy and Fair Information Practices


Legal Ecosystem Context



Contact Information and Attribution



Prepared by


The eCitizen Foundation


www.ecitizenfoundation.org



A Project of


The Kantara Initiative


The Open ID Foundation of Jap
an


Field Survey


Last Name, F. (Date). Dolor Sit Amet. Lorem Ipsum, 1
-

10.


Last Name, F. (Date). Lorem Ipsum Dolor Sit Amet. City: Publisher.


Last Name, F. (Date). Lorem Ipsum Dolor Sit Amet. Duis sed elit ante, pp. 10
-
20.



Appendices



PIDS Phase 1.5
: Future Directions


Patient ID Background and Markle Foundation Context


Legal Architecture for PIDS: Check lists and Standard forms


PIDS Interoperability Test Suite: SAML, NwHIN and Meaningful Use


PIDS Use
-
Centered Identifier Control: Wallet and Prefer
ence Architecture



Background


Patient Identity


How do you know who a patient is? Why know who a patient is? Is the person who is
requesting a record or treatment or services truly Jane Doe or John Smith as claimed?
The need for patient identification an
d authentication has long been recognized. The
Markle Foundation calls it, "A Critical Problem of the Digital Age." Is the right treatment
being provided to the right person? Is the correct account belonging to the right person
being charged for treatment
provided? Is the proper information about the right person
being used to determine treatment? Is the right record delivered to the right person?
During the 1990's the U.S. Government again recognized a need for patient identification
and took action, quick
ly followed by undoing what it had done and ensuring that nothing
more would be done in this area for years to come. The need did not vanish; it has only
grown more important, more urgent, more costly, even more deadly. Lack of a means to
identify and auth
enticate individuals results in improper treatment, death, fraud, waste
and abuse. Lack of an interoperable means to deliver these functions results in
significantly higher costs and roadblocks to efficient use of information.


During the past two decades
there have been numerous groups convened, whitepapers
written, studies undertaken on identification and authentication of individuals both in and
beyond healthcare. Tremendous amounts of work have been done to provide the
business, legal and technical comp
onents of identification and authentication. The
Clinton, Bush and Obama administrations, State and Local Governments in the U.S.
have developed programs, and supported work on these issues. Various international
collaborations have been created. Standards

groups have created standards, policy has
been written, operating rules drafted, and technology developed, bought and
implemented. The private sector has devoted billions of dollars and related resources to
addressing these issues.


Background

How do you
know who a patient is? Why know who a patient is? Is the person who is requesting
a record or treatment or services truly Jane Doe or John Smith as claimed? The need for patient
identification and authentication has long been recognized. The Markle Foundat
ion calls it, “A
Critical Problem of the Digital Age.” Is the right treatment being provided to the right person? Is
the correct account being charged for the medicine provided? Is the proper information being
studied to determine treatment? Is the right

record delivered to the right person? Studies and
anecdotes provide a convincing case that not being able to identify patients contributes to
waste, fraud and abuse, improper payments, faulty and even dangerous treatments and a host
of other negative out
comes. Unnecessary costs, for example repetition or duplication of testing,
are tolerated at least in part in an effort to ensure that, yes, indeed, a particular individual is who
she claims to be and the information available, possibly from another provid
er or lab or from the
patient, does apply to this particular patient.

The U.S. and other nations are currently transforming large portions of healthcare service and
delivery to electronic systems. The U.S. is devoting substantial resources, billions of dol
lars, to
catalyze the adoption and use of electronic health record systems, to develop Health
Information Exchanges (HIE's) and Health Benefit Exchanges (HBE's). One core set of
functional requirements necessary, yet inadequately addressed, to facilitate t
he operation of
HIE's, HBE's, and use of electronic health record (EHR) systems and personal health record
(PHR) systems are those functions related to patient identity. There is a "community" of experts
and practitioners who focus on the policy, business
and technology of determining who is who
and creating the systems to perform the appropriate related functions. The inhabitants of this
"identity world" recognize these functions of patient identity as identification and authentication.
The healthcare worl
d may more readily recognize these functions as patient matching or similar
terms. While these terms are not precise equivalents, they overlap enough to have much in
common and are performed to accomplish the same or closely related outcomes, “Is someone
c
laiming to be Jane Doe really Jane Doe?”

Creating the mechanism of interoperability is vitally important in a connected or networked
healthcare world that has determined it is valuable to collect, share, and distribute information
electronically. Without a

reliable means to determine that a patient is who he or she claims to be
delivery of electronic records, remote treatment or monitoring, and increasing the involvement of
patients in their own health care is difficult or impossible and much more costly th
an necessary.
Meeting these requirements of patient identification and authentication takes significant effort
and resources and is often hard to do. It is expensive and requires significant expertise. Sharing
the burden of meeting these requirements and r
eusing the outputs is a good way to spread the
costs and to improve outcomes. Patients can gain better control of their information, security
and privacy can be enhanced, the identity functions can be improved, and the healthcare
processes that rely on pat
ient identity can be performed with less "friction" thus reducing costs,
speeding delivery and improving healthcare outcomes.

There are several prior efforts that form the background and foundation for the current Patient
Identity Service work. Following
are summaries of some of the key developments on which the
PIDS Design project relies.

SAFE

(description of SAFE effort here)

HIMSS/GSA National eAuthentication White Paper

During the years 2005
-

2007 The Healthcare Information and Management Systems Soci
ety
(HIMSS) and the General Services Administration (GSA) of the federal government collaborated
to demonstrate how the security and identity management infrastructure developed to support
electronic government can be applied by the healthcare industry to
enable secure and
appropriate access to personal health information.

The solution offered by the GSA enabled secure and interoperable electronic healthcare
transactions locally, regionally and nationally. The box to the right contains an excerpt from the
E
xecutive Summary of the whitepaper on this collaboration and the whitepaper is available

here,

http
://
www
.
himss
.
org
/
content
/
files
/
GSAwhitepaper
.
pdf
.

The PIDS p
roject incorporates several of the major concepts of the HIMSS/GSA collaboration.
Primary or foundational concepts of the HIMSS/GSA work are interchangeable components,
interoperability among participating systems and reuse of credentials. This means th
at
credentials, whether they are username and passwords, smartcards, or other tokens can be
issued according to a set of common practices using interchangeable components that meet a
common set of functional requirements and those credentials can be used f
or a wide variety of
purposes often beyond the intent of the original issuance. The PIDS design is an open
architecture that extends the concept beyond technical components to include business and
legal components. Interoperability among a broad range of

participants and reuse of credentials
is essential to the PIDS design.

The Healthcare Information and Management Systems Society (HIMSS) and the General Services
Administration (GSA) of the federal government are collaborating to demonstrate how the
security
and identity management infrastructure developed to support electronic government can be applied
by the healthcare industry to enable secure and appropriate access to personal health information.

The solution offered by the GSA would enable secure

and interoperable electronic healthcare
transactions locally, regionally and nationally. This level of security does not exist today at a national
level because state and federal healthcare agencies are unable to mutually authenticate user
credentials.

He
althcare facilities require every user, be it a physician, nurse, care coordinator or any other staff
member, to authenticate their identity to the information systems used to provide administrative or
clinical services. The most common authentication meth
od in use today is a username and
password. Users have a long list of these username/password pairs for authenticating to multiple
systems, both within their institutions and between institutions. Some care facilities are now using a
single “sign on” metho
d locally by incorporating “roles” into their authentication and authorization
systems, thus allowing access to a variety of systems (upon presentation of credentials) based upon
someone’s role in the care
-
giving process.

The goal of the HIMSS/GSA pilot is

to demonstrate that numerous Health Information Exchanges
(HIE) and Regional Health Information Organizations (RHIO) can use a common authentication
system to facilitate the secure exchange of healthcare information. Value propositions and a
business case

for using the GSA’s e
-
Authentication method will also be developed.

HIMSS and the GSA developed a pilot project to demonstrate the adoption of the GSA’s secure and
interoperable technical architecture for sharing medical information among multiple healthc
are
providers. The pilot utilized the GSA‘s e
-
Authentication Service Component program to provide
digital certificates, technical architecture development support and certificate validation services.*


*From the Executive Summary, page 3, HIMSS/GSA
National e
-
Authentication Whitepaper




The

Markle

Foundation

based in New York, NY, invests substa
ntial resources toward the cause
of “Advancing Health in a Connected World.” During the past several years the Foundation has
assembled a broad range of experts to collaborate in developing the

Markle

Common

Framework
.

“The Markle Connecting for Health public
-
private collaboration develops foundational practices
for sharing personal health information

in a way that preserves privacy and security.

These policy and technology practices are embodied in the Markle Common Framework and
endorsed by a wide range of experts and organizations.

The Framework is divided into three sections

Connecting

Professionals
,

Connecting

Consumers
, and

Connecting

All

Health

Decision

Makers
. Each of the sections consi
sts of
multiple components.

During the years 2006
-
2007 the Markle Foundation assembled a team of experts to address the issue of
health consumer authentication. The team collaborated to explain issues of health consumer identification
and authentication a
nd to provide recommendations for the health sector. The results of the team’s work
were published in January 2008 as a component of the Common Framework sections
Connecting
Consumers
: “
CT
2:
Authentication

of

Consumers
,” and
Connecting Professionals
: “
T
7:
Consumer

Authentication

for

Networked

Personal

Health

Informati
on
.”

A Critical Problem of the Digital Age

At birth, a baby's hospital nametag is the first of several tokens that society will use to assert
"identity" throughout the rest of life. For a child born into this Digital Age, countless electronic
transactions
will be based on assertions of identity. There is no practical or affordable
technology

at least, not yet

to flawlessly identify each person for each transaction. So we use
a variety of imperfect tokens (driver's licenses, passports, PINs, passwords, etc.)

to validate an
individual's claim to a particular identity. And that identity will be created over and over again in
electronic systems throughout a person's life.

All business sectors and all individuals are challenged

and to some extent threatened

by th
is
burden of proving identity, and of issuing and using authentication tokens. The increasing
scattering of personally identifiable information makes identity management critical for business
and consumer activities, yet at the same time problematic, costl
y, and sometimes risky. In the
health care sector today, many important transactions occur daily with little rigor to confirm the
identity of individual consumers.

This paper addresses the problem of authenticating consumers in electronic health informatio
n
exchanges involving PHRs to ensure that each transaction is associated with the right person.
These include concerns such as the growing public anxiety regarding privacy and security of
personal health information, the fear by primary sources of data of
increased risk to the
information they hold, and loss of provenance of data, resulting from extensive sharing and
duplication that could affect the trustworthiness of the system.

Because PHRs store sensitive personal health data, it is critical to develop
reliable and
trustworthy mechanisms to ascertain the identity of anyone accessing the information. Health
information has several characteristics that make it even more sensitive than similar access to
bank accounts and lines of credit, because someone who

loses money through inappropriate
access can be made financially whole. Someone who loses control of sensitive health data, by
contrast, can never arrange to have that information returned to a purely private sphere. As part
of handling this sensitive dat
a, accurately identifying and authenticating consumers is an
important hurdle to be overcome in enabling institutional health data sources to share electronic
personal health information with consumer
-
accessible applications.
[1]

The PIDS project leverages

the work done by the Markle Foundation in its Health Consumer
Authentication documents, incorporating many of the concepts developed in that earlier effort
and updating the specifics where appropriate.

This paper

offers a framework for processes by which participants in electronic health
information networks can be assured that an individual consumer is who she claims to be. The
framework includes these four components:

Identity Proofing:

This is our umbrella term

for the steps by which a person's identity is verified. Specifically, it is
the validation of independent evidence and/or credentials of "identity." It happens several times
throughout life at various institutions. For example, to receive a driver's licen
se, a person must
present required documents in person at a state motor vehicle department.

Identifiers or tokens:

Once identity proofing is performed, organizations issue or require users to use tokens or
identifiers, which could be physical documents (e.
g., driver's license), biological markers (e.g.,
fingerprint), or be based on knowledge (e.g., passwords), or some combination (e.g., ATM card
plus PIN).

Ongoing monitoring:

After tokens have been issued or identifiers linked to an identity, systems are pu
t in place to
establish behavior patterns of individuals and alert authorized parties if behavior changes
suspiciously.

Ongoing auditing and enforcement:

If an organization relies upon third parties for identity proofing or the issuing of identifiers or
to
kens, then it must have mechanisms to audit those third parties and redress bad actions.

The Markle Workgroup adopted three major principles to guide the effort to develop
recommendations for Health Consumer Authentication. These principles have helped to

guide
the development of the PIDS project and will be incorporated into the model implementations.

Principle 1

Authentication systems should, as a whole, cover as much of the population currently
using the U.S. health care sector as possible.

Authenticati
on processes that are ineffective
or unavailable for particular groups of people (due to disability, expense to the user, lack of
available credentials such as driver's licenses, etc.) should be balanced with alternatives
appropriate for those groups, to t
he extent that such alternatives are available.

Principle 2

Consumers should have a choice in Consumer Access Services.

Consumers should be
entitled to a reasonable expectation of a choice of entities conforming to a published set of
authentication standar
ds. It's optimal, when feasible, to let informed consumers play a role in
determining their Consumer Access Service provider and authentication stringency level of
choice. However, given a widespread lack of consumer awareness about authentication
techniqu
es and identity threats, minimum consumer authentication standards for health
information should provide relatively high security.

Principle 3

To be both effective and trustworthy, a distributed system of authentication needs
oversight, accountability, and

mechanisms of redress.

The policies of the authentication
system should be transparent. Systems should allow the consumer to understand who has
potential access to her data as well as when it has been accessed and by whom, ideally on
demand and in real
-
ti
me.

We prefaced our deliberations by stating that:


Our recommendations must be reasonably affordable and workable in today's
environment.


Our recommendations must not be tied to existing practices and technologies that may
preclude futu
re innovations.


Our recommendations should not depend on the promise of future innovations in order for
organizations to act on them now.


Our recommendations must not favor any one technology or vendor, or any business
model or business

relationships.


Our recommendations must be fully cognizant of any non
-
proprietary frameworks that are
broadly accepted by at least large segments of the health sector.


A Need for a New Approach

Frameworks that address the authentication problem

typically do so based on a model of
increasing stringency of identity proofing and authentication, corresponding with increased
sensitivity of the data being accessed and the related risk. Requirements that are too low or
loose create an unacceptable risk

of the wrong person getting someone's information,
compromising a consumer's accounts, defrauding providers or otherwise engaging in criminal
acts. Requirements that are too stringent create unacceptable difficulties for the right person to
get to his inf
ormation, and may erect unacceptable barriers to adoption and implementation.

The development of networked PHRs is in its infancy, so there is no broad ecosystem to
observe. Yet the problems of authentication are primarily ecosystem problems. If every
orga
nization dealing with a consumer managed its own authentication process from start to
finish, there would be no systemic risk, and thus no need for a systemic solution. However,
making every organization responsible for every one of its users pushes signif
icant costs onto
both the individual (who needs to manage multiple passwords) and the organizations that hold
the consumer's data (each of which needs to be able to maintain a proofing and authentication
infrastructure.)

A Consumer Access Service with insu
fficient proofing or authentication standards creates a risk
for the security of the consumer's records. It also creates a risk to any clinical organizations and
other entities that hold the consumer's data, to the degree that those organizations trust a
C
onsumer Access Service to correctly validate a consumer's identity. If there is a race to the
bottom for convenience to the customer, then there may be a high level of abuse (which could in
turn inspire a draconian legislative or regulatory post
-
hoc remedy
).

Therefore, it would be helpful to define an acceptable baseline identity proofing and
authentication standard to which all Consumer Access Services should conform. Ideally, the
standard would have an understood and generally accepted threshold for relia
bility, so that new
methods for authentication can be evaluated against the effectiveness of existing methods. We
aspire to a situation where an affordable and accepted industry standard is based on a
measurable reliability of performance. However, as we d
iscuss below, such a standard is not
quantifiable today.

The Health Consumer Authentication document contains a number of recommendations. These
help inform the conduct of the current patient identity effort. The PIDS project extends the body
of knowledg
e developed for the Markle Health Consumer Authentication workgroup. Starting
from the foundation of the Markle Framework the PIDS effort will address a variety of issues that
arise when transitioning from a conceptual framework to development of specific

implementations to meet functional business, legal, and technical requirements and to adapt to
changes in recent years.


HITSP ICM

https://docs.google.com/a/ecitizenfoundation.org/leaf?id=0BzYsjcwnkhvkNWFiNmUyZTUtNDE4
Yi00YTI4LWE4MWUtNDcyZThiMDc3NGVl&hl=en
_US

http
://
ww
w
.
colorado
.
gov
/
cs
/
Satellite
?
blobcol
=
urldata
&
blobheadername
1=
Content
-
Disposi
tion
&
blobheadername
2=
Content
-
Type
&
blobheadervalue
1=
inline
%3
B
+
filename
%3
D
%22
Med
icaid
+
and
+
SCHIP
+
Presentat
ion
+(3
%2
F
26%2
F
08).
pdf
%22&
blobheadervalue
2=
application
%2
Fpdf
&
blobkey
=
id
&
blobtab
le
=
MungoBl
obs
&
blobwhere
=1251656633775&
ssbinary
=
true

Kantara and the HIAWG

NSTIC