Authentication in Healthcare
ann geyer - bill pankey
module 1 of the PKI tutorial
presentation of motivating cases

slides
1.  Requirements
2. Value of PKI
3. Collaborative Models
4. Target Application: Internet Mail
5. Target Application: File Transfer
6. Target Application: Form Signing
7. Target Applications: EDI over the Internet
8. Target Application: Member Communication

• Authentication is designed to positively corroborate identity of remote user / electronic correspondent
• necessary component of any network security solution, as follows
• authentication - authorization - access control - audit
• necessary condition for disclosure of patient identifiable data, due to
• HIPAA, HCFA Internet Policy, good practice
• Healthcare specific requirements 
• need to support unique individual identification, per HIPAA
• need to recognize persistent personal roles (e.g. physician)
• roles assigned to individuals independent of resource or organization
• different organization respond to this role in a similar way, e.g. all plans contract with physicians as providers and so have similar authentication requirements
• support presumptive access privileges and disclosure 
• must respond to industry reliance on “proxy” roles
• assigned independently of resource by principal, e.g. provider staff
• Healthcare Context
• Multiple affiliations for many provider persons 
• Mesh Industry
• Heterogeneous business relationships
• Heterogeneous computing platforms
• Cost Avoidance
• Regulatory Scrutiny
• Risk Avoidance
• New technology deployments require perception of significant  value / cost ratio
top

• Tentative acceptance of digital certificates and PKI as alternative with greatest potential:
• can be very secure
• if authenticated persons do accept personal responsibility for the integrity of keys
• can be highly scalable
• if plans and provider institutions take advantage of common CA resources
• can acquire high degree of provider acceptance
• if solution simplifies provider authentication requirements
• for providers and staff
• for a large number of resources
• requires that plan & institutions will use common CA resources 
• can reduce regulatory risk 
• with explicit industry recognition of common solutions
• explicit HCFA support for the creation and adoption of de facto standards and solutions 
• HCFA policy 
• WEDI / AFEHCT Internet “trial”
• can be low cost security solution
• unbundles authentication from resource or application
• allows for sharing cots of a common industry solution
top

• Collaborative Models 
• Healthcare specific rootCA controlling certificates for large segments of the industry
• requires significant industry commitment
• lacks suitable business or technology model
• difficult to identify appropriate authority
• Domain specific policy management
• instantiated in the userType Management Model
• Tunitas Group proposal for a CMA managed physician PKI
• enthusiastic support within physician community
• involves collaboration specific to classes of persons and organizations
• design to leverage existing professional and trade associations 
• vision generally lacking within association management
• basic concepts appear sound; model may be revisited with greater maturity 
• Promulgate de facto standard CA vendor for at least some user classes, i.e. “buying coalition”
• demonstrated failure.  The approach is flawed, in principal, as the excluded vendors will always act in ways to fracture the coalition rather than abandon market
• many examples of this sort of failure in California healthcare
• Develop and standardize the presentation of common healthcare  certificate requirements. in particular …. This is the Model Policy Workshop focus.
• Build a framework for consistent and potentially inter operable healthcare PKI implementations by independent CA
• create common healthcare certificate policies and framework
• provide platform for further PKI collaboration
• advances the general understanding of PKI issues and healthcare’s Internet use
top
 

• Security requirements for Internet mail
• encrypt messages to protect confidentiality of message content
• provide assurance of the authenticity of correspondent
• issue for both for recipients and senders
• authentication by addresses inadequate
• authentication by context inadequate without significant policy development
• two potential models for secure Internet mail
• support proprietary “mail” - host mailboxes for practice partners on a secure server
• Example: "mailboxing" on clearinghouse server
• requires partners to support correspondents’ mail processes
• implies “secure file transfer” ability
• SMTP mail
• messages must be “crptographically enveloped” and self-authenticating
• s/MIME is the de facto secure Internet mail standard
• HCFA explicitly acknowledges suitability of this protocol in its Internet policy
• software support found in all browsers, 3.x and later
• s/MIME protocol requires authentication using digital certificates

top

• Requirements
• mutual assurance of the authenticity of client & server
• protect integrity and confidentiality of files as they are being transferred
• cost and acceptance factors
• leverage existing client software (e.g. browsers)
• support connectivity solutions of trading partners
• SSL (secure socket layer) is the de facto internet standard for secure client server exchange
• provides authentication and “negotiates” encryption parameters
• HCFA explicitly acknowledges suitability of this protocol
• software support found in all browsers, 3.x and later
• “session layer” protocol supports (among others) HTTP, FTP
• also object communication with IIOP over SSL 
• SSL requires digital certificates for authentication
•  optionally supports weaker client authentication with "login /pswds"
top

• Requirements
• provide non refutable assurance of the identity of submitter of electronic form
• anticipate a HCFA requirement as this will protect against fraud in MediCare billing; 
• bind the electronic signature to the electronic document
• SSL binds identity to a session and only indirectly to the information submitted.  Non refutation requires binding document to session and submitter to session.  This is not feasible 
• leverage existing client software and language level APIs
• Digital Signatures are the de facto standard for electronic signature
• HIPAA mandates that healthcare electronic signature will be a digital signature
• support in existing language level API (javascript; java) as implemented by current browser editions
• Digital signatures require digital certificates of signers

top

• Requirements from HCFA & HIPAA
• mutual authentication of trading partner EDI processes
• encryption
• EDIINT is the established protocol for exchanging structured messages (EDI) over the Internet
• place structured messages in an s/MIME envelope 
• use transport protocol of choice FTP, HTTP, SMTP to communicate enveloped EDI
• EDIINT recommendations include message disposition notification (MDN) to support receipts and delivery guarantees
• EDIINT requires that digital certificates be issued to trading partner EDI resources

top

• Benefits
• Member \ patient satisfaction
• Improve member involvement in management of care
• JAMA reports on increased eMAil communication between physicians and patients
• Need for guidelines for appropriate use.  Without guidelines and without true authentication, providers significantly exposed
• support future Privacy Act required authorizations for disclosure of patient information
• Requirements
• Positively identify unique patient.  Requires corroboration of patient identifiers beyond just name.
• Positively identify appropriate parents \ caretakers relative to dependents
• Must support mobility of patients  
• Assurance that patient has available appropriate encryption software. 
• Support very large scale authentication solutions
• Digital certificates can support required member authentication
• certificates can bind person identifiers to patient \ member ID
• Portability across  computing platforms
• Very difficult to create healthcare specific PKI for patients, however:
• Digital certificates will become ubiquitous in the general population
• large scale deployments anticipated
• Financial services initiatives - SET (electronic bank card)
• Certificate based security used for corporate intranets and next generation network OS (NT5, Netware 5)
• Other potential certificate sources
• authentication solutions used for the purchaser's intranet.  May be used support member communication with healthplans and providers,
•  e.g. , Netscape employee communications with Prudential Health Plan 
• Other drivers, examples:
• smart cards in university environments, UCLA certificate project
• genernmental agencies, e.g. Province of Ontario to issue certificates to entire population !!!
• Cost effective solution can be built using multiple certificate sources and a Patient \Member Directory
• digital certificates for members
• online application to bind a patient provided credential to unique patient identifiers
• secure publication to providers and staff
top