Security Briefing - Extended Outline

Intended to improve "the efficiency and effectiveness of health information systems through establishment of standards and requirements for the electronic transmission of health information"
Establishes Federal Regulation of

Electronic Health care Transactions
Health care Identifiers
Confidentiality of computerized health information
Security of electronically maintained or communicated Health Information

Health Care Transaction Standards

Federal Regulation of Health Plans' electronic communication with providers and purchasers
Requires that all health plans must support standard EDI, for 9 common "transactions":

claims and encounters, health claim attachments, claim status, referral and authorization, eligibility verification, health plan enrollment, health premium payment, first report of injury

Provider use of EDI optional, but can transmit non-standard EDI only through clearinghouse
HCFA to determine standard format and code sets

e.g. ANSI X12.837 (4010 version) for healthier claims
e.g. ICD-9 for diagnosis, CPT-4 for procedure coding

For the listed common transactions, restrict electronic transactions to these standards
Provisions must be adopted within two years of publication of final standards, by early 2001

Unique Health Identifiers

Mandates creation of federal set of health care identifiers to support electronic transactions

Health Plan (Payer ID)
Purchasers (Employer Identification Number or EIN- from IRS))
Providers (National Provider ID or NPI)

requires that providers obtain NPI from "enumerator"
requires national registry to coordinate enumerators
registry not funded by legislation, so implementation uncertain
may replace MediCare Provider ID

Patients

HCFA has not yet issued a proposed rule, rather Notice of Intent to solicit input for alternatives
very controversial - legislation to rescind mandate pending

HR4281 Paul
S2352 Leahy

Further Protection for Confidentiality of Electronic Health Records

Law requires creation of a Federal standard with respect to privacy of the individually identifiable health information transmitted in connection with the HIPAA mandated transactions, to include:

Appropriate use standards
Appropriate disclosures standard
Rights of individual with respect to this information and procedures to exercise these rights

Law requires Congress to create Federal law by August, 1999

Legislative Proposals in Committee.

HR 1815 - "Medical Privacy in the Age of New Technologies Act of 1997" - McDermott
S1921 - "Health Care Personal Information Nondisclosure Act of 1998" - Jeffords / Dodd

If Congress fails to pass the required legislation, then HHS is required to create the federal standard by Regulation with Final Rules published by February 2000.

Confidentiality of Electronic Health Records - HHS Recommendations

Presented to Congress September, 1997. This will be basis of Final Regulation if Congress does not create the required law. The recommendations represent the Clinton administration view and should be viewed as containing the likely standards.
Presented as Statements of Principles and Policy
Limited Disclosure Provisions

Use of individually identifiable health information limited to purposes for which the information was collected or received.

example: "legislation should forbid the use of information received in payment process for anything but payment related purposes"
example, hospital solicitation of former patients for donation to foundation would be precluded.

NO disclosure of individually identifiable health information to third parties without patient authorization

Disclosure requires a specific purpose
Disclosure limited to the minimum information required to support that purpose

Exemption for purposes of health Oversight for:

licensing and accreditation of providers
audit by government payers (HCFA, state Medicaid)
public agencies pursuant to federal or state law
public health

Patient Control Provisions

written explanation of information practices
patient inspection and copying of records

process to amend incorrect records

patient inspection of history of disclosures

name, date, purpose of all disclosure

Patient Authorization

guidelines for authorization content

must be written, signed, dated, and limited
specifies information disclosed
specifies person(s) to receive this information
specifies purpose of disclosure

separate from consent to health care
guidelines for revocation, retention, patient copies, etc.
would not require explicit patient authorization for data processing by service organizations, e.g. billers, clearinghouses, pharmacy benefit managers.

Regulation should not differentiate between types of health information
Regulation should not dictate technology or otherwise restrict ability to implement sound professional practice
Uses of health information mentioned as inappropriate include:

marketing, employment decisions,

Problematical: Common practice of third parties pulling the chart to support HEDIS reporting

Security Provisions contained within the Act - Agenda

Legislative Intent
Applicability and Scope
Time Frame
Regulation Specifics

HIPAA Security Provisions - Legislative Intent

require that HHS (HCFA) create reasonable and appropriate administrative, technical and physical safeguards:

ensure the integrity of health information
protect against unauthorized use or disclosure

Issue: Rules for Appropriate Use and Disclosure may not be codified until after security regulation becomes effective

standard must explicitly take into account:

current technology, implementation costs, capabilities of persons accessing health information, small providers and rural health systems

logic of the security provision: As a cost savings measure, the Federal government mandates standardization of coding and format that will presumably increase use of health care EDI. The mandate will increase the computerization and electronic communication of health information. This increases the exposure of health information to threats against its integrity and confidentiality of health information; there is a need to balance increased exposure with increased security. Furthermore, standardization of security mechanisms increases the confidence with which trading partners (and in particular providers) may engage in health care EDI.

HIPAA Security Provisions - Applicability and Scope

Applies to:

All health plans
All clearinghouses
Health care providers who electronically transmit any health information in connection with the listed health care transactions

Applies to: All individually identifiable information relating to:

present, past or future health condition, treatment, or payment for treatment

explicitly includes demographic data collected by plan or provider

Regulation does not distinguish on basis on presumed sensitivity

does not preclude stricter state standards for different data types, e.g. psychiatric reports, AIDs test results

Applies to maintenance of electronic data as well as communication of electronic data
Security provisions are explicitly not restricted to:

HIPAA Transactions
"External" Communication

HIPAA Security Provisions - Time Table

HCFA Published Proposed Rules in August 12 NPRM (Notice of Proposed Rules)

basis of today's talk

Comment Period expired October 13
HCFA considers comments

must publish a response to comments, but is not obligated to adopt recommendations contained within
In excess of 17,000 responses to Transaction and Identifier NPRMs

Publication of Final Rules Pending

date uncertain -

draft Final Rules will probably not be completed until April 1999

best rumor status...WEDI estimate with some confirmation by HCFA personnel

Final Rules not likely to be published until end of 1999

Regulation becomes effective 2 months after publication of Final Rules
Plans and providers must comply with 24 months of effective date

end of 2001 / beginning of 2002

HIPAA Security Provisions - Enforcement

Specific financial penalties for failure to comply with HIPAA standards

$100 per occurrence, $25K max a year

NOTE: Bill Braithwaite (HCFA lead for HIPAA regs) maintains that these financial penalities are an order of magnitude too small
HCFA is concerned that some organizations will merely pay the penalty rather than absorb cost of compliance. HCFA will seek other mechanisms to obtain compliance.

Criminal penalties for knowlingly wrongful disclosure or willful misuse of individually identifiable health information

up to $250,000 and 10 years imprisonment (with intent to sell)

Enforcement procedures for security regulations still a "work in progress"

HCFA anticipates enforcement thorough a partnership with private accreditation bodies

HIPAA security compliance would then impact accreditation

independent physician practices would be allowed to self-certify compliance using "industry checklists"

can always opt out of current security mandate by not engaging in EDI

HHS keeps final responsibility for determining violations and imposing penalties

Regulation under HIPAA - HCFA Proposal

Security Regulations - HCFA's General Approach

Comprehensive security standard

single standard that integrates all required security components
define "health information security" and what must be done to attain it

"Unifies" existing guidelines and standards, in particular:

ASTM E31 Health care Informatics Security Framework
National Research Council 1997 Report on Health Information Security
NIST General Security Principles
maps a number of technical standards from

ANSI, ASTM, IEEE, IETF, FDA
NPRM maps specific security regulations to these other standards

input from NCVHS, WEDI, HISB, NUCC,NUBC,ADA

Scalable - single standard for all health care organizations

small provider, large health plan, multi-state IDS

Technology "neutral"

standard is not stated in terms of specific technology
really just a point of view, requirements sometimes imply use de facto standard technology such as RSA

Overall Security Management

Requirement for a formal security management process that includes:

Risk analysis \ management

assessment of exposure and the steps to reduce risk to acceptable levels

implies construction of threat model, i.e.: what information / systems are to be protected from whom and what and for how long. What attacks are more likely? more serious?

part of normal business process
HIPAA does provide any metric or cost assumptions.
Left to be determined by each organization is the acceptable risk level

left unstated is the role of insurance

Analysis may conflict with other HIPAA condition that all information has equal sensitivity.

Sanction Policy

Disciplinary action for misuse or misappropriation of health information. Applicability to employees, agents, or contractors

Security Policy

Statement of needed levels of protection and assignment of protection responsibilities.

Identity systems with the mechanisms that will protect them

Requirement that security be an assigned responsibility

Specific Individual or Organization
management of security measures and conduct of personnel
designed to fix organization focus and responsibility

Requirement for Security Certification

organizations must certify that organization provides "appropriate" security for health information, This certification can follow:

internal evaluation
external accreditation agencies, e.g. EHNAC
security consulting firms such as MitreTech may provide this role for large organizations

Final rule will include requirement for other "mechanisms" to support independent audit

Presumed to include a "reports" requirement
HCFA was soliciting input as to what this should be

HCFA expects industry development of appropriate "checklists" for smaller organizations (e.g. independent physician practice)
HCFA yet to determine if or how "off the shelf" vendor products should be certified

probably of little value as security that vendor product provides depends upon user configuration

Requirement for "chain of trust" agreements

contract with intermediaries (in particular, for administrative transactions) whereby assurance is given that appropriate levels of protection are given to transmitted data

makes trading partners mutually responsible to each other for information security
however, must implement vague requirement in contractual language.

as clearinghouses are already covered by regulation, unclear why this is needed
certainly applies to non-healthcare organizations that process or maintain health info as the organization's agent

Requirement for Formal Mechanism of Processing Records

Document procedures for routine and exceptional: receipt, processing, storage, transmission and disposal of health information

for all health information, document how information is obtained and what is done with it, i.e.. "workflow" for patient data

preliminary to risk analysis

Requirement for Security Incident Procedures

Formal documented procedures for reporting and responding to security incidents.

Requirements for Specific Protections

HIPAA Security Matrix

Requirement to implement numerous security mechanisms. Regulation does not speak to how mechanism should be implemented or calibrate solution parameters
HIPAA creates matrix by typing elements of security solution

Administrative - personnel and process management
Physical - physical access and media controls
Technical "Services" - application level security to 1) "protect information" and 2) "control and monitor individual access"

information security in internal environment

Technical "Mechanisms" - guard against unauthorized access to data that is transmitted over a network

security for EDI, remote access to systems, extranets

In each class, HIPAA identifies requirements in a general way and then specifies optional and mandatory components of any solution that will satisfy the requirement.

for example, HIPAA mandates a contingency plan to respond to "system emergency". This plan must include a data and applications "criticality analysis" and then address: data backup, disaster recovery, emergency mode operation, with periodic testing and revision of the plan.

Requirements are often imprecise:

for example, there is a requirement for "data authentication" to corroborate that "data has not been altered or destroyed in an unauthorized manner". Data is only defined as "sequence of symbols", so at what level of specify is the data to be authenticated? character? data element? record? something else? How strong does this "corroboration" have to be? Does the metadata which authenticates data itself have to be authenticated?

Requirements sometimes overstated

for example, "not placing a terminal used to access patient information in any area of a doctors office where screen contents can be viewed from any reception area". Is this realistic?

HIPAA does not provide any metrics to evaluate the adequacy of the security solution

evaluation must be done relative to risk analysis
testing is only to uncover "weakness" in overall plan.

Requirements sometimes conflict with other HCFA rules and principles such as those contained in "DHS Recommendations for measures to protect the Confidentiality of Patient Information"

The DHS recommendation clearly states that organizations should not differentiate data on basis of "presumed sensitivity", but NPRM expects organizations to implement security regulations relative to presumed data sensitivity. For example, the NPRM includes the following sort of language: "procedures commensurate with the sensitivity of the data to be accessed".

Mandated implementation features often redundant, for example:

for data communicated over a network, there is a mandate to implement both "message authentication" and "integrity checks".

the integrity "check" has no added security value if messages are authenticated.

Mandates include requirements that, as stated, imply use of particular technology when, as a matter of principal, the regulations are to be technology neutral.

requirement for "automatic logoff" is only meaningful when using session based technologies.

"logoff" not meaningful, per se, with stateless protocols such as HTTP
"logon / logoff" can be simulated, but the health care application may not otherwise require maintenance of state?

Standard is "uneven"

for example, include mandate to change "combination locks" at employee termination but says nothing about encryption "strength" or "key management".

Specific requirements address threats and solutions that cross boundaries and so it is not always clear when, where or why specific procedures are implemented or required.

for example, there is requirement for access control on a physical, technical services and technical mechanism basis. The NPRM does not address how or if implementations at these levels can be coordinated. If physical access to a single user workstation is controlled, does there have to be some login \ pswd process?

Schema for specific implementation requirements:

Classify Threats by Locus of Data

Data maintained by Enterprise
Data Communicated over network

Classify by Type of Threat

Environmental

destruction, tampering, removal, or otherwise unavailability of the physical devices used to store or access health information

Personnel

inappropriate use or disclosure by known parties, in particular organization employees

Technological

use of technology by unknown parties to inappropriately acquire or tamper with health information

Tunitas Axiom:

Technical mechanisms protect against technological threats; physical mechanisms against environmental threats; personnel policies against personnel threats.
Corollary: Don't expect a technology solution to your people problem.

Security Regulations - Environmental Threats

Primary relevance to data maintained by enterprise.

Enterprise cannot physically control / manage components of communication solution as, at a minimum, shared with business partner and also may involves infrastructure components of VAN, clearinghouse, PSTN, Internet.

Requirement for a Contingency Plan

emergency mode operations subsequent to fire, vandalism or natural disaster
disaster recovery to recover data lost as a result of fire, vandalism, natural disaster or system failure.
implies, at a minimum, data backup and some system redundancy for critical operations

Requirement to limit physical access

govern receipt and removal of hardware and media storing health information from enterprise
principally to protect against theft of systems and vandalism
facility security plan should include

controlled physical access to systems containing health information

physical access policies on a "need to know" basis. This requirement may overreach. "Need to know" access would be better controlled with technical access controls.

control of equipment into and out of facility
visitor \ maintenance policy (sign-in and escort)

Security Regulations - Personnel Threats

Personnel Security. This requirement intended to assure that access to health information is limited to appropriate personnel. The requirement includes:

Supervision of personnel maintaining the technical access control mechanisms
Appropriate screening (clearance) of personnel prior to authorization of data access.

depends upon sensitivity of data and risk to organization

Access authorization, establishment and modification

Record of access authorization

Security training intended to promote security responsibilities as part of routine activities

"awareness" training (including management)
periodic reminders
specific education for auditing, exception reporting, virus protection, password management)

Termination Procedures to end a user's access

removal of user accounts
removal from access lists
recovery of keys, tokens, or cards that allow access

Security Regulations - Technological Threats to Enterprise Systems and Data

User Authentication to corroborate the identity of person or entity accessing the health information

Requirement for unique user identification

This requirement may require a change in common practice, especially as pertains to remote access by affiliated physician practices.
Not sufficient to authenticate "departmentalStaff" or "staff@xyz"; individual staff members must be recognized

precludes the use of "office pins" or "shared" login ID and password
precludes reliance upon "workstationID" as sole authentication mechanism, unless access to workstation is controlled, so that unique user can be determined.

NPRM inappropriately requires either biometrics, password or pin as possible authentication mechanisms

need to support digital certificate and public key based authentication mechanisms

basis of all next generation networking security solutions, i.e. Netware 5, NT5, Kerberos

Additional requirement for "automatic logoff"

meaningful only for session based protocols
analogous to "time to live" feature when using stateless protocols

Requires authorization control mechanisms to explicitly support assignment of access privileges to users. Authorization control instantiates a (possibly virtual ) access control list for a protected resource. The list identifies users who are allowed access. The NPRM explicitly recognizes two kinds of authorization control:

User-based access model

privileges explicitly assigned to uniquely named individuals

e.g. grant access to Jill Smith with loginID:=jsmith1.medrecords

simple setup
not scalable or simply distributed except on resource basis

Role based access model

privileges assigned to roles and roles assigned to individuals

e.g. grant resource access to "medical records staff" and assign Jill Smith to a "medical records staff" role

scalable and supports distribution

Requires access control mechanism to ensure that authenticated user has authorization to access requested data.

This is the process, prior to allowing access to resource, that confirms the authenticated user's presence on the resource's (possibly virtual) access control list.
Granularity of authorization control determines granularity of this service and where the access control has to be implemented

on a system basis, control access to applications, services or processes
on an application basis, control access to records or data elements

Data Integrity Control to ensure that information is not modified or deleted in an unauthorized manner

NPRM provides example mechanisms: checksum, "double-keying", message authentication code (MAC) or digital signature.

different mechanism provide different protections and different degrees of accountability
examples confuse a) the fact of a change, b) authorization/non-authorization for the change

NPRM does not address the significant granularity issues involved with this requirement.

Minimize impact of exception if authenticate at a data element level, but
fine granularity requires significant amounts of metadata to record state information including (possibly) data dna time of change, person making change, authorization for change, etc.

Requirement is incomplete as the metadata must also be authenticated.

Audit Controls for purposes of identification of suspect activity and assessment of security program.

Security Regulations - Network Communications

Understood in the context of two communication models:

client server. Initial responsibility placed upon server resource.
store and forward, in particular eMail. Initial responsibilities placed on sender of message.

General Requirements respond to two general issues:

protect confidentiality and integrity of messages.

concern about inappropriate "interception" of message when communicated over open network
concern for corruption of message (intentional or otherwise) when communicated over network

protect systems from non authorized remote access.

intruder masquerading as legitimate user

Regulation explicitly calls for a number of mechanisms to be implemented

User / entity authentication.

Requirement to irrefutably identify users, programs and processes
two basic models

identify a user. This means a "unique individual"

unique individual identification required in local environment; certainly same standard applies in wide area environment. Local environment provides many additional controls (e.g. audits, physical access control, etc.) identification standard cannot be more stringent.
may require upgrade from current practice of "office PIN"

need for a distributive process in order to rely upon management by business partner.

identify a program or process

HIPAA does not provide guidance as to how this must be accomplished
this may mean a "unique user" but as a (distributed) two step process:

server identifies client application or process
client application identifies end user in the remote environment appropriately for local use
rely upon business partner for configuration appropriate to business partner's situation.

business partner is either a health care organization bound by HIPAA requirements; or other bound by "chain of trust partner agreement"

Access control. HIPAA requires either

User based access control

problematic in a multi-enterprise environment

Role based access control

Guidance in ASTM guidelines - common definition of roles
need for directories and mechanism to secure them

Encryption

Required for both Internet and dial-up up
Controversy over the requirement as pertains to dial-up

would require addition of encryption to "comm" component of PMS systems, for example
significant cost to clearinghouse and system vendors as typically will involve an application integration requirement. Typical vendor EDI client -server applications are "stove-pipe" and cannot simply take advantage of independent communications components.

newer development using the Win32API (i.e. Windows) or Java can take advantage of "pluggable crypto"
encryption could be supported by generic "print to file" for subsequent transfer by stand alone encryption application, e.g. Premenos Templar

WEDI recommendation that "dail-in" encryption unnecessary as can rely upon security provided by Federal "wire-tap" laws

prediction that health care EDI use would "collapse" until encryption technology integration accomplished
argument essential that cost of requiring encryption for dial in systems to great relative to benefit.

Encryption readily implemented for Internet based applications.

Secure Sockets (SSL)

encryption services on all commercial web server platforms
encryption services provided by modern browser
SSL includes

protocol to negotiate bulk encryption algorithms and session key's
challenge- response to mutually authenticate clients and servers

Secure eMail standards appropriate for "store and forward" messages

s/MIME the de factor standard to provide secure "enveloping" of Internet eMail

support present in Netscape Communicator, MS OUtlook, Eudora, Groupwise 5.5

uses public key to identify senders
uses recipient's private key to encrypt randomly generated "message key"
use message key to bulk encrypt message contents

assumes public key infrastructure and takes advantage of hierarchical trust model

PGP similar in function and purpose

standalone application from Network Associates
also a public domain specification for mail and file encryption with some support by 3rd party applications (e.g. Eudora)
generates public keys as needed and utilizes a "web of trust" model

HIPAA encryption standard inadequate

does not specific strength of encryption

must be calibrated relative to current technology
typically a function of key length and thus size of key space.

differs with respect to algorithm used

silent about key management

in principle, health care communication involves large number of business partners.

Significant problem in sharing \communicating secret keys for the bulk encryption of large messages

public key based solutions require public key infrastructure

Message authentication / integrity controls
Alarms / Event reporting / Audit

Communication of Health Data - Politics and the HCFA View

The HCFA ban on Internet / dial-up network (PSTN) use for communication of patient identifiable data

publicized in "Region II Notice" dated October 10, 1997
HCFA policy allowed only use of "dedicated communication lines, e.g. T-1
logic based on "non-avialablity of acceptable" encryption mechanisms

significant criticism of this position as it is /was wrong on the facts

Recognition of need to support dial-up and Internet access to health resources

Explicit legislative requirement in HIPAA to mitigate impact upon small and rural providers
advocacy of NVCHS workgroups
WEDI (clearinghouse) position that dial-up ban excessive

HCFA policies need be consistent with HIPAA regulations
Lifting of HCFA Internet /dial up ban imminent

new policy under internal review
HCFA policy will be more specific than HIPAA regulation

Security Regulations - Electronic Signature

Regulation creates an electronic signature standard with respect to standard transactions

current applicability unclear as adopted transaction standards do not current require a signature of any sort.

However, HIPAA mandates that electronic signatures will be "digital signatures"

digital signatures are self authenticating, applicable to any electronic document. They are non-reputiable due to the cryptographic complexity involved in reproducing a signature.
A general cryptographic method that encrypts a digest (or hash) of the signed message with a signer's private key. The signature is verified by decrypting the signature with the presumed signer's public key and comparing with a freshly computed hash of the message.
Digital signatures assume a public key infrastructure (PKI) which binds a public key (and associated private key) to a particular entity. A digital certificate associates a subject with a public key. This association is confirmed by a trusted third party (or certificate authority or CA).
A digital signature will be non-repudiable only if the private portion of the key pair is kept under the exclusive control of the certificate subject. Validity of digital signature depends upon diligence of certificate subjects' to control and protect use of private portion of key pair.

RSA provides de factor standard algorithm for digital signature.

Implemented in s/MIME compatible Internet mail clients.

Netscape Messenger, Microsoft Outlook, Eudora

Broad use awaits development of an appropriate public key infrastructure.

Significant efforts by Federal government to coordinate independent private sector PKI efforts for Federal (HCFA) digital signature use.

not likely that the federal government will be a CA for anything other than Federal employees.

Coordinated state and Federal efforts to create empowering legal infrastructure.

Legislation will create conditions for a presumptive subject responsibility for the control of the private portion of key pair.
Rules for Certificate Authorities.
Preemptive (of state law) Federal legislation for digital signature.

CMA interest and commitment to create a PKI for California physicians.
Organizations can issue certificates to trading partners

Use and liability would be governed by trading partner contract
Approach places significant responsibility on certificate subject. Typical health care physician \ worker may not accept management responsibility associated with one business partner (domain) - one certificate model.
Nontrivial education \ support requirement.

Applicability

the Act: the adopted electronic signature "will be deemed to satisfy Federal and State statutory requirements for written signatures with respect to (...HIPAA administrative transactions)"
the Rules: Any HCFA electronic signature requirement will be a digital signature.
Can be jointed adopted by trading partners once they mutual accept a CA process.
Regulation makes non cryptographically based electronic signatures, for example, digitized signatures or biometrically based signatures of only local value.

Issues for the Small Provider

Why this is an industry issue:

Physicians are source of much of patient identifiable data

patient data is obtained, ultimately, from physicians examining room and not the IPA.
industry should recognize this fact: If electronic data cannot be securely maintained at the source then the backlash will against electronic maintenance and transmission of health information, in general

Note, however, though that any patient identifiable data regardless of source will most likely be considered confidential

as a practical matter, physician non-compliance is a barrier to electronic data exchange

All entities subject to regulation are required to certify compliance

Physicians will be allowed to self-certify compliance.

Regulation does not explicitly prohibit electronic exchange with non-compliant physicians

however, by definition, such exchanges would be non-compliant

Physician can escape regulation by avoiding electronic data exchange altogether

HCFA view regarding small provider compliance

Requirements are scalable
Anticipate support from:

Knowledgeable staff, PMS vendor or consultants to conduct required security analysis, develop and document procedures, certify and audit
PMS vendors for required software upgrade, for example: audit trails for all access
Industry association and vendors for "model" documentation forms

Deficiency in HCFA view

Anticipated support may not materialize

Many PMS "legacy" systems may not be upgraded

Many legacy "stovepipe" systems that are not "upgradeable"
Vendors will await upon demonstrated market demand before they will construct the business case that supports modification of software systems. The market demand, though, will come only as a result of provider's risk analysis and security planning. There may be a substantial delay before the required modification of PMS software. The HCFA mandate is only indirectly a mandate on PMS vendors.

HCFA provides no basis for accrediting "security consultants". Vague requirements (relative to physician practice) provide basis for excessive consultant expense

Assumes much simpler business partner relationships than is typical in California

in particular, implicitly assume a single source communication solution using a single clearinghouse

Doesn't explicitly recognize that EDI adoption is already a hard sell to physicians. If security requirement is seen as overly intrusive, physicians simply opt out by not engaging in EDI.

Trading partners need to anticipate and support small provider business process if they are to allow remote access or achieve any significant benefit from EDI.

Often it is not the physician but office staff who require access

for example, EDI applications
for example, patient scheduling, A/R
STILL, THIS DATA IS ALL CONSIDERED "PATIENT CONFIDENTIAL"

Therefore, Security solutions should anticipate need for physician staff access

for administrative and clinical data
note though that the management of staff access requires active participation of physician and/or office administrator

for staff identification and role assignment
notification of change in status

significant staff churn and multiple staff assignments

Cannot reasonably expect physicians to assume administrative role specific to hospital/plan/IPA security "solution".

This model requires physician or office administrator to act as an administrator for a domain on the healthplan / hospital / ipa network.
to simplify management problem, the provider "breaks" affiliate's security model

for example, office sharing of single password

or avoids using the electronic solution to maximum benefit

for example, fail to support staff access because security solution "too hard" or expensive

Need for collaborative solutions for authentication and access control.

Small provider interaction with many business partners: multiple health plans, IPAs, medical groups, state and local health agencies.
All require for the same group of staff persons:

authentication services
authorization to act on behalf of provider for some limited purpose
audit of access

without collaboration, administrative burden on small provider office is insurmountable

collaboration though construction of "networks" (CHIN, clearinghouse, PMS vendor) have proved insufficient

fail to acquire sufficient breath (from provider view) and reach (from server point of view)
provide only partial solutions, provider requires multiple "networks"

some technologies that may support the required collaboration

Public Key Cryptography, in particular pkcs for certificate requests and issuance

create common authentication mechanism
allow for effective distribution of responsibility, i.e. provider creates certificates for staff persons in the provider's domain

secure X.500 / LDAP Directories

means for provider to "publish" staff role assignments
support role based access control

Initiatives to support required collaboration

nascent efforts to create a "Health care PKI"
efforts to standardize "Health Care Directory Attributes", e.g. ASTM
these efforts consistent with HIPAA mandate for a "National Provider Identifier"

Planning for Compliance - Next Steps

Responses to NPRM now under HCFA review
Publication date for Final Rule uncertain

most likely not before April 1999, possibly as late as December 1999
final rule will clarify and differ somewhat from NPRM in technical detail

Compliance mandated within 2 years plus 2 months of publication date
Questions to answer now?

Assignment of security responsibility?
Risk assessment?

inventory patient identifiable data
determine access requirements

anticipate increased exposure as a result of HIPAA EDI mandates

assess exposure

Vendor product qualifications?

Assess potential impact on budget and outsource contracts.
Assess any new product acquisition relative to ability to support regulation

what is the vendor's HIPAA compliance strategy?

does the vendor product provide a security layer for authentication, access control, auditing?
does the vendor rely upon existing security services, for example, Operating System security services? Will this be sufficient for the kind of data the vendor product manipulates?

how does use of this vendor's product affect your organization exposure

how does the product support authentication, access control and audit requirements
how does it integrate with existing security solution

guarantees?

Anticipate some gotchas in requirements that may exceed current practice:

unique user authentication especially as it pertains to remote access by affiliated provider organizations
data authentication
audit trace

Focus on themes.

that risk analysis and security management should conducted as a formal process with the enterprise
that access should restricted to minimium required by function
accountability through authentication and audit
multiple security layers through physical, personnel and technology controls

Information Resources

Regulation

HCFA Administrative Simplification site

HIPAA Security NPRM
DHS HIPAA Security FAQ

HHS Recommendation for further Federal Patient Confidentiality Legislation

DHS Recommendations for measures to protect the Confidentiality of Patient Information This will be the basis of HCFA Rules if congress does not pass required legislation by August 1999
Protecting Privacy of Health Information Donna Shalala speech articulating the current administration's view on the topic.

Remarks on Security NPRM

Health care Security Guidelines and Standards

Examples of the development of specific standards to support HIPAA regulation. These standards provide guidelines for some specific components of the HIPAA security matrix and are explicitly developed to support HIPAA compliance.
ASTM - draft standards for health care information access authorization, audits and data authentication.
ENHAC - proceedures to support a HIPAA Security Accreditation for clearinghouses and VANs
JCAHO - standards and scoring for the Management of Information by a major accrediation body. We have not been able to identify an explicit commitmment of the Joint Comission to include the HIPAA matrix in its evaluation, although clearly HCFA desires this.
AHIMA - a likely source of some of the industry supplied checklists that HCFA expects to support the small provider

Digital Signature Guidelines

American Bar Association This is an excellent introduction to the meaning and use of digital certificates and digital signatures.