NGA toolkit v.1.2 - Justice Clearinghouse · This Consents Toolkit is intended to support the development and implementation of consent processes consistent with the most stringent

State and Federal Consent Laws Affecting Interstate Health Information Exchange

2011 Consents Toolkit

______________________________________________________________________________

i

Contents

1. Introduction ........................................................................................................................ 3

2. State Law Information Collection Worksheet..................................................................... 4

3. Consents Standards Derivation Flowchart........................................................................ 25

a. Demonstration: Derivation of Patient HIE Authorization Form. .................... 29

b. Demonstration: Derivation of Patient Consent Form. .................................... 30

c. Demonstration: Derivation of Authentication ................................................ 32

4. Consent Policy Reference Matrix ...................................................................................... 35

5. Consents Transaction Decision Tree ................................................................................. 38

6. Consent Process Management ......................................................................................... 45

a. Consent Document Contents and Records Management .............................. 45

b. Electronic Consent Documentation ................................................................ 47

Table 1: Consent Type Coding ........................................................................................................ 6

Table 2: Comment Coding ............................................................................................................... 7

Table 3: HIPAA Consent Reference Table ..................................................................................... 10

Table 4: Privacy‐Specific Laws ....................................................................................................... 13

Table 5: Laws Based on HIPAA, Other Federal Statutes and Regulations .................................... 13

Table 6: Health Information Laws ................................................................................................. 14

Table 7: Health/Medical Records Laws ......................................................................................... 15

Table 8: Consent/Authorization Laws ........................................................................................... 16

Table 9: Minors ............................................................................................................................. 16

Table 10: Proxies ........................................................................................................................... 17

Table 11: Condition/Situation‐Specific Laws ................................................................................ 17

Table 12: Provider‐Specific Laws .................................................................................................. 19

Table 13: Facility‐Specific Laws ..................................................................................................... 20

Table 14: Health Plan/Payer‐Specific Laws ................................................................................... 21

Table 15: Employer‐Specific Laws ................................................................................................. 21



______________________________________________________________________________

ii

Table 16: Public Health Reporting ................................................................................................ 22

Table 17: State Facilities and Records .......................................................................................... 23

Table 18: Research ........................................................................................................................ 23

Table 19: Miscellaneous Legal Definitions .................................................................................... 24

Table 20: Derivation Categories .................................................................................................... 26

Table 21: Derivation Indicators ..................................................................................................... 28

Table 22: Derivation of Authorization .......................................................................................... 29

Table 23: Derivation of Consent ................................................................................................... 31

Table 24: Derivation of Authentication ........................................................................................ 32

Table 25: Consent Policy Matrix ................................................................................................... 35

Table 26: Consents Transaction Decision Tree ............................................................................. 38

Table 27: Electronic Signature Processes ..................................................................................... 52



State Law Information Collection Worksheet ______________________________________________________________________________

3

1. INTRODUCTION

This Consents Toolkit is intended to support the development and implementation of consent processes consistent with the most stringent requirements of Federal and state law, from identification and assessment of applicable laws through their reconciliation into policy requirement, to a decision‐making process for identifying the consent policy which applies to a specific type of disclosure. Consent requirements under the laws of multiple states, 42 CFR Part 2 and FERPA can all be accommodated in these tools.

These tools may be used in any type of HIE arrangement. In an Enterprise HIE, the organization can use them to develop policies and make consistent decisions across its operations. In a Standard HIO the governing entity can use them to develop appropriate policies and provide them to participants, and provide guidance on participants’ decision‐making about consents for specific kinds of disclosure. In a Utility, the HIE services provider may wish to provide guidance to participants based on these tools, or participants may wish to use the tools to develop their own policies and documentation. State agencies and Regional Extension Centers may also use them to develop guidelines or recommendations for HIE in their jurisdictions or for purposes of HIE initiatives.

In particular, the Toolkit includes:

State Law Information Collection Worksheet. This is a set of tables which can be used to assemble and identify the various state laws which may apply to HIE consents, characterize them and determine whether they are more or less stringent than HIPAA.

Derivation of Consents Requirements Flowchart. Once applicable laws have been identified and characterized, they need to be reconciled into actionable policies. The derivation flowcharts therefore demonstrate the reconciliation of overlapping legal requirements to develop policies which are compliant with all applicable laws.

Consents Policy Reference Matrix. The result of reconciliation process will most likely be a set of different policy requirements for consents varying by type of disclosing entity and purpose of disclosure. These results can be summarized in a matrix which serves as a reference for identification of consents policies.

Consents Transaction Decision Tree. Once consent policies have been developed, parties needing to decide whether a given disclosure (or type of disclosure) is permitted under the applicable consent policies can use the Decision Tree to identify applicable consent requirements, and determine whether they have been met (or the conditions which must be met for the type of disclosure to be authorized).

Consent Process Management. Consent processes must be managed to ensure permissions are recorded and records are maintained, and limitations are appropriately




4

communicated. While specific consent management processes cannot be dealt with in detail in this Toolkit, baseline HIPAA authorization and recordkeeping requirements are noted. This section also discusses principles for use of electronic processes, particularly use of electronic signatures which may be used for signature of electronic consent forms, since Electronic consent management processes in particular may be of value in HIE

These tools simplify the development and use of consent processes, but using them will still require a certain amount of time and expertise, and there will need to be a continuing process to update information about legal requirements to ensure policies are kept compliant. These tools should also be reviewed and adapted as necessary to ensure they are consistent with the actual needs of the specific HIE arrangement, and take into account any outlier or uncommon variations in the laws of a given state.

2. STATE LAW INFORMATION COLLECTION WORKSHEET

The following tables (“Worksheet”) are based on the Comparative Assessment Matrix (“CAM”) and Assessment Tool developed by the Harmonizing State Privacy Law Collaborative (“HSPLC”) for the Health Information Security and Privacy Collaboration (“HISPC”), published in the HSPLC Roadmap: Analytical Framework and Collaborative Recommendations .1 It is strongly recommended that the project leader(s) for a consents development project read the Roadmap itself before working with these tables, as there is significant background material and explanation which will make their use clearer.

The Roadmap was expressly developed to support legislative and regulatory assessment and possible action to reduce obstacles to interstate HIE created by interstate legal variations, and the Worksheet can be used for that purpose with a specific focus on consents. However, it is also intended to support development of actual consent processes, policies and forms for public sector, private sector and mixed HIE, within and between states.

In other words, the Worksheet can be used to develop consents which comply with existing laws, including overlapping state and federal laws as well as the laws of different states, without a need for the laws to be changed. The resulting consents standards may not be ideal for some purposes, but are likely to support effective HIE under existing conditions. Legislative or regulatory solutions which may provide a better resolution but are likely to require long

1 Health Information Security and Privacy Collaboration, HSPLC Roadmap: Analytical Framework and Collaborative Recommendations (March 31, 2009), produced by the Harmonizing State Privacy Law Collaborative.




5

periods of development can be pursued,2 but this pursuit of “perfect” solutions need not prevent the current use of solutions which are “good enough.”

The Worksheet is set up to map federal HIE‐related law, principally HIPAA, against the laws of one state, to identify variations between the two. Once variations are identified, the more stringent of the two variations is identified, and the more stringent requirements are applied. The resulting consent is therefore based on the most stringent requirements of the two overlapping laws.3

In the form provided below the Worksheet can be used to develop consent strategies for intrastate HIE which only needs to take the laws of one state into account. Where interstate HIE is under consideration the Worksheet should be used to map the laws of each participating state separately. Each state’s results should then be compared, but only on those variations where state law rather than HIPAA applies because it is more stringent.

For requirements where HIPAA applies in all states, HIPAA sets the minimum consent requirement. Where the law of one state is more stringent than HIPAA and HIPAA is more stringent than the laws of the other states, the law of the former state applies. Where the laws of more than one state are more stringent than HIPAA with respect to the same requirement, the laws of the two states need to be analyzed to determine which provides the greater protections, and the more protective law should set the minimum consent requirement.

Use of the Worksheet is unavoidably a detail‐oriented process, and requires the identification of relevant laws and their logical review and analysis.4 The Worksheet provides a set of subject matter areas for various types of laws which may have HIE implications, such as general privacy laws, hospital medical records regulations, genetic information protection, and so on. Each table can therefore be used as the basis for finding statutes, regulations, caselaw and other policy authorities which may be relevant to HIE consent. Additional or slightly variant

2 See Christiansen, Apgar and Melamed, Policy Strategies for Advancing Interstate Health Information Exchange: A Report to the State Alliance for e‐Health (October 2009)for a discussion of state strategies for dealing with variations in HIE‐related laws.

3 It should be noted that the more protective of two overlapping state laws is not applied because one preempts the other, but in order to manage potential liability issues. Privacy laws in general define individual rights to control access to information about the individual, so a more protective law is one which gives the individual greater rights to control access and/or establishes greater limitations on access. Since greater rights or greater limitations on access should generally include but go beyond the rights or limitations established by an overlapping but less protective law, compliance with the more protective law should also include compliance with the less protective law.

4 Roadmap at 8 – 9.




6

authorities may exist in some states which may require some amendment to the tables. It is highly recommended that this process include input from a number of knowledgeable sources. 5

Once laws have been identified they should be entered into the Worksheet in the appropriate sections, including citations and/or links to ensure accuracy and allow for updating and future review. The requirements of the laws should then be analyzed to see how if they overlap, and if so to determine if they are inconsistent. If they are inconsistent, the more protective requirement should be identified. Once the various legal requirements for consents have been identified they can be used to derive a consent process, including whatever notice, documentation, policies and procedures they require, using the process described in Section 3 below.

It should be noted that this process can be followed on as broad or narrow a basis as is appropriate to the HIE arrangement. If only hospitals and physician practices are participating and they are only sharing information for treatment purposes, the analysis is likely to be much narrower than that required if the arrangement also allows for sharing with public health agencies, health plans and researchers for a wide range of purposes.

a. Suggestions for Typology of Analysis

In order to provide some guidance and detail in analyzing legal variations, for some HIEs the following typologies may be used to characterize applicable law.

The first typology (Table 1) is the consents typology discussed in the main body of the Report, and is intended to allow for a general characterization of legal requirements under that typology. The second typology (Table 2) is intended to be used to supplement the characterization where appropriate, as part of the Comments to each law. Table 2 is loosely based on the HISPC Report on State Law Requirements for Patient Permission to Disclose Health Information,6 but has been significantly adapted for purposes of this Toolkit.

Table 1: Consent Type Coding

Type of Consent Code Examples

No Consent NC Some notice to individual of disclosures

Opt‐Out O‐O Notice to individual and opportunity to prohibit disclosure

Opt‐In O‐I Notice to individual and authorization by

5 The Roadmap recommends legal counsel and an advisory board. Id. at 13. 6 Health Information Security and Privacy Collaboration, Report on State Law Requirements for Patient Permission to Disclose Health Information (August 2009).




7

individual required

Directive D Organization is required to disclose information as directed by individual

No Directive Permitted

ND Individual may not direct organization to disclose information under any conditions

Table 2: Comment Coding7

Permission Code Explanation

Y =Yes Information may be disclosed without written permission. There are no additional qualifications or conditions. This category allows the disclosure of health information in a manner most similar to the HIPAA Privacy Rule.

N = No Written permission is required to disclose information. This category includes laws statutes and regulations that require the patient to affirmatively permit the patient’s information to be disclosed at least once.

S = Sometimes The discloser may sometimes disclose information without patient permission. This category is divided into a number of specific subcategories to provide more detail into the circumstances under which information may be released without treatment.

S‐AP = Sometimes, attempt to obtain permission:

The discloser must make an affirmative attempt to obtain the individual’s permission to disclose information. If these attempts are unsuccessful, the provider may nonetheless disclose the information for the designated purpose. This is included as a separate category because the party holding the information must take specific, affirmative action prior to disclosing health information. In other words, the information would not automatically be disclosed.

S‐CC = Circle of care

Discloser may disclose information without written permission with others involved in ongoing care. Provisions included in this category permit disclosure where there is a direct link between e.g. providers, either when the providers are working together at the same time or when one provider assumes care from another such as:

7 Id. at 2‐4 – 2‐7 (footnotes and some text omitted, format changed).




8


upon the patient’s transfer to a new provider or facility;

for a specified limited time upon admission to a health facility;

to providers to whom patient has been referred;

to providers who are providing consultation;

to providers involved in current episode of care;

to providers for follow‐up care.

S‐E = Sometimes—Emergencies

Discloser may disclose information without patient permission for emergency medical treatment. Included in this category are provisions that permit disclosure without permission:

to provide emergency care or treatment;

in an emergency;

when required for emergency hospitalization; and

when necessary to avoid imminent danger to life or safety of patient.

SS‐PJ = Sometimes—Professional Judgment

Law expressly provides that discloser may disclose information without express permission subject to professional judgment. This category includes provisions with the following clauses:

when, in the provider’s professional judgment;

when the provider determines;

when the provider deems;

as prudent professional discretion dictates.

disclosure is

necessary for treatment;

necessary to provide appropriate care or treatment;

necessary to protect the patient’s health and welfare;

in the patient’s best interest;

needed to accomplish objectives of diagnosis and treatment.

S‐NT = Sometimes—Necessary for Treatment

Discloser may disclose information without express permission when necessary to provide treatment. This category includes provisions that permit the provider to disclose information without permission in the following circumstances:




9


when necessary to provide care or treatment;

if, and to extent necessary, to provide treatment;

to extent necessary for consultation;

where demonstrable need for treatment exists;

when necessary in connection with care;

when receiving provider has legitimate need to know the information for treatment;

when in best interest of the patient; and

as relevant for care.

S‐SP = Sometimes—Specific Providers

Discloser may disclose information only to specified providers without patient permission (e.g., may only release to mental health care providers or to facilities under same control as the provider).

U = Unclear It is unclear whether disclose may disclose information without express permission for designated purpose. This category includes provisions where the scope of the law is unclear (e.g., whether a law applies only to health department records or also to records held by other providers) or the requirements are unclear. This category does not include those provisions that are categorized as “UABL,” unclear due to “as authorized by law” provision.

UABL = Unclear It is unclear whether discloser may disclose information without express permission because the statute or regulation contains an ambiguous provision permitting disclosure “as authorized by law “or similar phrase. This category includes provisions that have the following statutory language:

as provided by law;

to the extent allowed by law;

as otherwise permitted or provided by law;

to any person to whom disclosure is authorized by law without the consent of the patient; and/or

as permitted by HIPAA (or by 42 C.F.R. part 164).

State Law Identification and Characterization Tables




10

State laws can be identified and entered into the following tables, and characterized using the above codes. Each table represents a category of types of law which may have implications for consents. Not all states are likely to have laws in all categories, and some states may have laws which do not fit any of these categories (though that should be uncommon).

Laws should be identified by citation, and if possible a link to a legislative, regulatory or other authoritative website which maintains a copy of the law. Each law can then be characterized using the Permission Codes from Table 1, and compared with the corresponding HIPAA provision in Table 2 (if any) to determine which is more stringent, and therefore is applicable.

Table 3: HIPAA Consent Reference Table

Type of Consent Purpose Comments

NC Treatment Y

No limitations or conditions on provider‐to‐provider disclosures for treatment purposes

NC Payment Y

Minimum necessary rule applies

Health Care Operations

Y


Public Health Activities

Y: As authorized by law, to entities authorized by law


Victim Reporting S‐E, S‐AP: Reasonable belief of victim status, to legal authorities, to extent required by law or harm prevention, with notice to individual presumed


Health Oversight Y: As authorized by law, to entities authorized by law


Judicial, Admin. S‐AP: As required by order or legal process,




11

Proceedings subject to protections in proceedings


Law Enforcement S‐E: As required by law or legal process, limited for identification or immediate action, to report crime in emergency


Decedents Y: To law enforcement re crime; to coroners, funeral directors


Transplants Y: To procurement and related organizations


Research w/ Approval

S: Subject to conditions established by IRB or privacy board


Protection of Health/Safety

S‐E: If necessary to prevent or lessen serious, imminent threat to individual or public health, safety, to person(s) reasonably able to prevent or lessen threat, or law enforcement if necessary


Special Gov’t Functions

Y: Military/veterans agencies,; national security/intelligence as authorized by law; Presidential, etc. protective services; foreign service; correctional institutions; government benefits programs; workers’ compensation; all as provided by law, conditioned


O‐O Marketing N: Any remuneration must be disclosed




12

Fundraising S

Out‐of‐pocket care N

Facility Directory O‐O, S‐E

Care Participants S‐CC, O‐O

O‐I All Disclosures Not Otherwise Specified

N

Research‐Related Care

N: May condition provision of research‐related care on consent

Plan Eligibility, Enrollment

N: May condition enrollment on consent

D All PHI in Designated Record Sets

S‐EP: May be denied if licensed health care provider determines disclosure Is reasonably likely to endanger life, safety, cause harm to any individual

Subject to CLIA S: May be denied if appropriate under CLIA

Exempt from CLIA S: May be denied if appropriate under CLIA

Inmate Request S: May be denied under appropriate conditions

Research in Progress S: May be denied

U.S. Privacy Act‐protected

S: May be denied to protect confidentiality

Confidentially Obtained

S: May be denied to protect confidentiality

Psychotherapy Notes

S: May be denied unconditionally

Compiled for legal action

S: May be denied unconditionally




13

Table 4: Privacy‐Specific Laws

Category of Law (Constitution,

Statute, Regulation, Caselaw)

Citation/Link

Permission Code

More Stringent than

HIPAA? (Y/N)

Comments on Consent Implications

Comprehensive general privacy

act

Comprehensive medical privacy

act

Constitutional right to privacy

Restrictions on use of Social

Security Number or other personally identifiable information

Table 5: Laws Based on HIPAA, Other Federal Statutes and Regulations



Citation/Link Permission Code

More Stringent than

HIPAA? (Y/N)


Provisions adopting HIPAA requirements




14




More Stringent than

HIPAA? (Y/N)


Provisions adopting other federally based

provisions

Table 6: Health Information Laws




More Stringent than

HIPAA? (Y/N)


Health information exchange specific

provisions

Electronic health/ medical record

specific provisions

Telehealth/ telemedicine provisions

Personal health records




15

Table 7: Health/Medical Records Laws

Category of Law (Constitution, Statute, Regulation, Caselaw)


More Stringent than

HIPAA? (Y/N)


Patient access

Specific re‐disclosure prohibitions

Redisclosure statement required




16

Table 8: Consent/Authorization Laws




More Stringent than

HIPAA? (Y/N)


Patient consent requirements

Patient authorization requirements

Disclosure for emergency situations

Table 9: Minors



Citation/Link

Permission Code

More Stringent than

HIPAA? (Y/N)


Age of majority

Emancipated minors

Age consent requirements—Mental health

Age Consent requirements—Other conditions




17

Table 10: Proxies

Category of Law (Constitution, Statute, Regulation, Caselaw)


More Stringent than HIPAA? (Y/N)


Personal Representatives/ Executors

Guardians

Health Care Power of Attorney

Health Care Power of Attorney—mental health

Table 11: Condition/Situation‐Specific Laws




More Stringent than HIPAA?

(Y/N)


Genetic information

HIV/AIDS information

Sexually transmitted disease




18




More Stringent than HIPAA?

(Y/N)


information

Hepatitis C information

Adult mental health

Children's mental health

Communicable disease

information

Alcohol addiction

Drug addiction

Reproductive rights

Minor wards of the state

Adult wards of the state

Reporting of abortions

Victims (domestic violence, sex assault, etc.)

Futile Care Provisions

Other proxies




19

Table 12: Provider‐Specific Laws




More Stringent

than HIPAA?(Y/N)


Pharmacy records

Emergency services

(ambulance/ EMT)

Health profession licensing

Health profession

accreditation

Professional counselors

Utilization, peer & quality review




20

Table 13: Facility‐Specific Laws




More Stringent

than HIPAA?(Y/N)


Hospitals

School‐based clinics

Imaging labs and centers

Testing and clinical labs

Assisted living facilities

Drug & alcohol treatment facilities

Rehabilitation facilities

Home health agencies

Hospice




21

Table 14: Health Plan/Payer‐Specific Laws




More Stringent

than HIPAA?(Y/N)


Health insurance related provisions

HMO provisions

Medicaid/ Medicare related

provisions

Table 15: Employer‐Specific Laws




More Stringent

than HIPAA?(Y/N)


EHR

Provisions related to employers

Pre‐employment screenings

Employee assistance programs




22

Table 16: Public Health Reporting




More Stringent

than HIPAA?(Y/N)


Newborn screening

Vital records (birth/death certificates)

State Department of Health reporting (reporting certain conditions to state)

Reports to other state agencies

Immunization reporting

Registries

Information sharing in public

emergencies




23

Table 17: State Facilities and Records




More Stringent

than HIPAA?(Y/N)


Other state facilities

Public health clinics

Correctional facilities (adult)

Correctional facilities (minors)

State hospitals

State Freedom of Information Act

Table 18: Research




More Stringent than

HIPAA? (Y/N)


Disclosures for research




24

Table 19: Miscellaneous Legal Definitions




More Stringent than

HIPAA? (Y/N)


Electronic Medical Record

Electronic Health Record

Health Information Exchange

Health Information Organization

Personal Health Record

Consent

Authorization

Privacy

Confidentiality



Consents Standards Derivation Flowchart ______________________________________________________________________________

25

3. CONSENTS STANDARDS DERIVATION FLOWCHART8

Once legal authorities and their requirements have been identified and analyzed, they can be reconciled and an appropriate consent process derived using the process described in this Section.

The following flow charts graphically depict a process of logical derivation of specific policies and processes from legal and standards authorities. The charts are read from left to right, reflecting (with some exceptions) a gradation from general to specific. Generally, elements in columns to the left determine or influence elements in columns to the right, though as will be seen this is not always a simple relationship and the depiction can be somewhat complex.

The examples which follow include an authorization derivation, a consent derivation and an information access authentication derivation. The specific values, laws and in some cases standards which should be taken into account may vary, but the general approach to derivation applies. For example, as will be seen below, disclosure processes implicate patient privacy as one of a set of public policy consideration, and HIPAA as a set of statutory and regulatory obligations.

Figure 1 demonstrates the general structure and categories used. In this chart, Public Policy Considerations (farthest left) are more general than and determine Statutes and Common Law, which in turn are more general than and determine Regulations and Mandatory Standards, and so on. (Note that the Public Policy Considerations column is repeated as a row at the bottom of the chart. As will be seen below this is necessary to depict the Public Policy Considerations affecting factors three or more columns to the left without too many confusing line crossings.)

8 Based on Christiansen, The Logical Derivation of Information Technology Policies, Procedures and Solutions (2007).




26

Table 20: Derivation Categories

The categories used in this chart are described as follows:

“Public Policy Considerations” are the high‐level values which guide the development of legislation and judicial decisions, regulations, standards and guidance. For purposes of the present discussion this category has been populated with a basic set of HIT‐related public policy values. The specific values included in this category, and their nomenclature, are not intended to be comprehensive or final. Public Policy Considerations guide implementation, but are not specific enough in themselves to specify actionable requirements.




27

“Statutes and Common Law” includes both federal statutory law, such as HIPAA, and state statutes relevant to HIT issues, as well as federal and state caselaw (published judicial decisions) with HIT implications. The laws included in this category will vary by the issues and jurisdictions under consideration. Statutes and common law may, but probably most often do not provide sufficiently detailed, specific standards to provide actionable requirements.

“Regulations and Mandatory Standards” includes federal and state regulations, as well as standards or guidance published by governmental agencies which have binding legal effect, relevant to the HIE issue under consideration. The HIPAA Privacy and Security Rules would fall into this category, as would state medical records regulations. “Mandatory standards” would include, for example, Centers for Medicare and Medicaid Support (“CMS”) security guidance which Medicare contractors are required to comply with, if such an organization is involved in the HIE issue. In many but not all cases Regulations and Mandatory Standards include actionable requirements.

“Industry Standards and Guidance” include governmental, professional and industry standards which are relevant to the HIE issue but do not have the force of law. This would include standards and guidance published by the National Institute for Standards and Technology (“NIST”)(as long as no federal agencies are involved; since they are supposed to comply with NIST, for them NIST requirements are Mandatory Standards), international standards such as ISO 27799 (Health Information Security), guidance from organizations such as the American Health Information Management Association (“AHIMA”), etc. These standards frequently provide sufficient detail to allow for actual implementation, which is usually not provided in statutes or most regulations.

“HIE Agreements or Conditions of Participation” is an optional category applicable if the organization is subject to documented legal agreements among the participants in a health information exchange (“HIE”) arrangement, as in a regional health information organization (“RHIO”) or subnetwork organization (“SNO”). HIE can and perhaps at present most frequent does take place without such documentation, but that situation may be changing. When such documentation is established, it will often specify policies, procedures and technical standards participants must implement or comply with, sometimes in considerable detail.

“Entity Policies and Business Practices” includes the specific policies, procedures and technical solutions organizations have adopted or should adopt in order to address the HIE issue in question.




28

The relationships between these authorities and the Entity Policies and Business Practices they

inform are depicted by different types of line, as shown in Figure 2.

Table 21: Derivation Indicators

Type of Line Appearance Meaning

Dotted Left element logically supports or influences right element

Solid Left element logically or legally determines right element

Dashed Left element provides guidance for implementation in right element

Dot‐and‐dash Left element imposes contractual requirement on right element

For example,

1. Public Policy Considerations support and influence Statutes and Common Law, most other authorities, and Entity Policies and Business Practices. However, they do not state legal requirements which must be followed. This relationship is shown by a dotted line.

2. Statutory grants of authority as necessary to authorize regulations, and determine their permitted scope and content. They may also directly impose requirements on healthcare organizations which must be taken into account. This kind of relationship is shown by a solid line.

3. Industry standards are sometimes incorporated into regulations but more often do not have binding legal effect, and so may be valuable in developing Entity Policies and Business Practices but are not mandatory. This kind of guidance relationship is shown by a dashed line.

4. In some situations healthcare organizations enter into contracts, for example with federal agencies or other healthcare organizations, which include specific contractual provisions must be taken into account in the Entity Policies and Business Practices. This contractual relationship is shown by a dot‐and‐dash line.

The following flow charts demonstrate these relationships for two related consent and authorizations scenarios.




29

b. Demonstration: Derivation of Patient HIE Authorization Form.

Figure 3 depicts a relatively simple issue based on a fact pattern in which a RHIO seeks access from participating organizations to monitor the incidence and management of diabetic patients. This issue raises questions about whether such disclosures and uses of patient information must be explicitly authorized by the patient, and generally what kinds of policies and business practices participating healthcare organizations should implement to allow them.

Table 22: Derivation of Authorization

Reading from left to right, the first, Public Policy Considerations column is populated as shown in Figure 1. The second, Statutes and Common Law column includes placeholders for HIPAA (the legislation as codified) and state privacy laws, which are present in most states.




30

Dotted lines link the Public Policy Considerations which are the principal relevant bases of each law. State privacy laws are presumably based principally or only on individual privacy considerations, while HIPAA is based on considerations of administrative and financial efficiency and private profitability as well as individual privacy.

The laws in the Statutes and Common Law column are in turn linked (by solid lines) to the Regulations and Mandatory Standards they determine in the third column. HIPAA’s statutory authorization for privacy regulations is the principal determinative factor for the relevant HIPAA authorization standards, while there are no state regulations on point (this may not always be the case).

Industry Standards and Guidance in the fourth column are not generally determined by either statute or regulation, though they are often developed for or are helpful in complying with statutes or regulations; this is why they are included. In this case the relevant standards are the Markle Foundations Connecting for Health guidance for HIE and Joint Commission on Health Care Accreditation (“JCAHO”) accreditation standards (assuming the organization is a hospital, or hospital‐affiliated). Industry Standards and Guidance are also generally influenced by the same Public Policy Considerations values which influence the laws, and this influence is shown by dotted line links to the values in the far‐left column would have crossed other chart elements in a confusing way.

The fifth, HIE Agreements or Conditions of Participation may or may not be determined by laws or industry standards, though they are (or should be) developed consistently with them. In this particular analysis we assume there is an applicable HIE agreement in place for regional information sharing agreement based on the Markle Foundation’s Connecting for Health model agreement. This is linked to the Connecting for Health guidance in the fourth column.

The sixth column then represents the individual Entity Policies and Business Practices which will control the content and management of authorization forms. As indicated, the only direct legal obligations informing the authorization policies and business practices are the HIPAA Privacy Rule and state privacy laws, and the RHIO participation agreement which is based on the Markle Connecting for Health model. It is also possible to clearly identify the competing public policy considerations which must be reconciled: Patient privacy informs most of the authorities involved, while public health surveillance and patient health and safety considerations, which are the motivations for gathering information on diabetic patients, are identifiable but have not been formalized in any legal or industry authority.

c. Demonstration: Derivation of Patient Consent Form.

Figure 4 takes the basic issue in Figure 3 and assumes that instead of information about patients with diabetes, the RHIO seeks access about care provided to patients for substance abuse. This additional “sensitive information” factor implicates the federal substance abuse regulations, which have specific consent requirements, and state substance abuse laws as well.




31

Table 23: Derivation of Consent

This addition of another legal authority in Figure 4 adds another, more specific set of obligations informing to the authorization policies and business practices required by the HIPAA Privacy Rule and state privacy laws, and additional weight to patient privacy considerations. As indicated, then, the Entity Policies and Business Practices implemented to allow substance abuse information to be collected by the RHIO would have to reconcile the RHIO participation agreement with legal obligations under HIPAA, federal substance abuse confidentiality laws and state laws. In this particular setting it is likely the resolution would require adoption of consent requirements compliant with the most stringent legal obligation, the federal substance abuse confidentiality regulations.




32

d. Demonstration: Derivation of Authentication

Figure 5 provides a look at a different issue based on a different set of facts. In this scenario one of the issues presented is authentication for remote access to a patient’s electronic health record (“EHR”) by the treating physician (“Dr. X”), including application of an electronic signature to confirm record content. Figure 5 demonstrates the relationships among the authorities in various categories which inform the policies, procedures and standards implemented for this purpose.

Table 24: Derivation of Authentication




33

This chart is to be read the same way as the previous charts, though note that key Public Policy Considerations values are repeated in the row on the bottom which link to elements in the fourth to sixth columns, providing a less confusing diagram than would have been possible if links had been run from the first column. (Elements not relevant to this analysis have not been included in the bottom row on this version of the chart.)

The second, Statutes and Common Law column includes placeholders for state privacy, medical records and electronic signatures laws. Most states have some set of these, which are implicated in this issue. This column also includes relevant federal statutes, in this case including HIPAA and E‐SIGN (the Electronic Signatures and Global and National Commerce Act, which permits electronic signatures to be used for most purposes as a matter of law).

Dotted lines link the Public Policy Considerations which are the principal relevant bases of each law. State privacy laws are presumably based principally or only on individual privacy considerations, while HIPAA is based on considerations of administrative and financial efficiency and private profitability as well as individual privacy, and E‐SIGN is based principally upon efficiency considerations.

The laws in the Statutes and Common Law column are in turn linked (by solid lines) to the Regulations and Mandatory Standards they determine in the third column. HIPAA’s statutory authorization for security safeguards is the principal determinative factor for the relevant HIPAA authentication standards. State medical records protection regulations, by contrast, are determined by both the medical records and the privacy laws of the state.

Industry Standards and Guidance in the fourth column are not generally determined by either statute or regulation, though they are often developed for or are helpful in complying with statutes or regulations; this is why they are included. In this case the relevant standards are federal governmental information security and risk analysis standards, as well as the Markle Foundations Connecting for Health guidance for HIE. Industry Standards and Guidance are also generally influenced by the same Public Policy Considerations values which influence the laws, and this influence is shown by dotted line links to the values depicted in the bottom row. (Links from these value elements from the far‐left column would have crossed other chart elements in a confusing way.)

The fifth, HIE Agreements or Conditions of Participation may or may not be determined by laws or industry standards, though they are (or should be) developed consistently with them. In this particular analysis we assume again that there is an applicable HIE agreement in place for regional information sharing agreement based on the Markle Foundation’s Connecting for Health model agreement. This is linked to the Connecting for Health guidance in the fourth column.

The sixth column then represents the individual Entity Policies and Business Practices which will allow for the authentication of Dr. X. As indicated, these policies, procedures and standards will




34

have to reconcile the requirements (solid line) of state medical records protection and electronic signatures regulations, as well as those of the HIPAA Security Rule’s authentication standard (solid line), and comply with the regional HIE agreement (dot‐and‐dashed line, indicating contract). These policies, procedures and standards are also legitimately influenced by the values of private profitability, linked from the bottom row.



Consent Policy Reference Matrix ______________________________________________________________________________

35

4. CONSENT POLICY REFERENCE MATRIX

Once legal requirements have been identified and mapped to a set of consent policies which meet or exceed the most stringent legal requirements, these policies can be summarized in a matrix which Types of transaction, categorized by type of entity making the disclosure and the purpose of the disclosure, can then be coded based on the typologies of Tables 1 and 2.

Table 25: Consent Policy Matrix

Purpose of Disclosure

Provider Mental Health Professional

Alcohol, Substance Abuse Program

Health Plan

Treatment (Not SHI)

Treatment: Alcohol/Drug Program

Treatment: Psych Notes

Treatment Other (State SHI by Specific Type)

Emergency Treatment (Not SHI)

Emergency Treatment: Alcohol/Drug Program

Emergency Treatment: Psych Notes

Emergency Treatment (State SHI by Specific Type)

(Specific Other




36




Health Plan

Treatment)

Payment (Not SHI)

Payment: Alcohol/Drug Program

Payment: Psych Notes

Payment (State SHI by Specific Type)

(Specific Payment Purposes)

Health Care Operations (Not SHI)

Health Care Operations: Alcohol/Drug Program

Health Care Operations: Psych Notes

Health Care Operations (State SHI by Specific Type)

(Specific Health Care Operations Purposes)

Individual Request




37




Health Plan

Research (Not SHI)

Research: Alcohol/Drug Program

Research: Psych Notes

Research (State SHI by Specific Type)

Public Health (Not SHI)

Public Health: Alcohol/Drug Program

Public Health: Psych Notes

Public Health (State SHI by Specific Type)

This kind of consents policy matrix can then be used to determine specific processes and documentation for the various kinds of disclosures identified.



Consent Transaction Decision Tree ______________________________________________________________________________

38

5. CONSENTS TRANSACTION DECISION TREE

Once consent processes and documentation have been determined, participants may still need to decide what kind of disclosure they are making, and whether the consent requirements for that disclosure have been met. The following decision tree is intended to support this kind of determination.

This decision tree can be followed for classes of disclosure so that all disclosure transactions in that class are subject to the same rules, and in problematic individual cases where a non‐standard disclosure may be at issue. Additional decision factors may be added if appropriate, and some may be deleted if not necessary for a specific HIE arrangement.

Table 26: Consents Transaction Decision Tree

A. Disclosing Entity Status

1. Are you disclosing as a Health Care Provider? Yes/No If Yes, continue to A(1)(a)

If No, continue to A(2)

a. If you are a Health Care Provider, are you disclosing information from an alcohol or drug treatment program?

Yes/No If Yes, continue to B(1)(a)

If No, continue to A(1)(b)

b. If you are a Health Care Provider, are you a mental health professional?

Yes/No If Yes, continue to B(1)(b)

2. If not a Health Care Provider, are you disclosing as a Health Plan?

Yes/No If Yes, continue to B(1)


3. If not a Covered Entity, are you disclosing as a Business Associate?

Yes/No If Yes, continue to A(3)(a)


a. Is the disclosure authorized under the applicable Business Associate Contract?


If No, do not execute




39

disclosure

4. If not a Covered Entity or Business Associate, are you disclosing as a Subcontractor to a Business Associate?

Yes/No If Yes, continue to B(1).


a. Is the disclosure authorized under the applicable Subcontract?


If No, do not execute disclosure

6. Are you disclosing the information as a type of entity not otherwise listed in this Section?

Do not execute disclosure, not appropriate for electronic HIE

B. Federal Law Information Status

1. Is the information you are disclosing Protected Health Information?

Yes/No If Yes continue to B(1)(a)

If No, continue to C(1).

a. Is the information also protected under 42 CFR Part 2?

Yes/No If Yes, continue to E(3)(c)

If No, continue to B(1)(b)

b. Does the information include Psychotherapy Notes?

Yes/No If Yes continue to E(3)

If No continue to C(1)

c. Does the information concern or arise from health care services paid for by the patient “out of pocket?”

Yes/No If Yes, continue to E(3)

If No, continue to C(1)

d. Is the information also Sensitive Health Information under State law?

Yes/No If Yes continue to D(2).

If No continue to C(1).

C. Purpose of Disclosure (HIPAA)




40

1. Are you disclosing the information for purposes of Treatment of the individual?

Yes/No If Yes, continue to B(1)(a)

If No, continue to B(2)

a. Is the disclosure for purposes of emergency treatment?

Yes/No If Yes, execute disclosure

If No, continue to D(1)

2. Are you disclosing the information for purposes of Payment?

Yes/No If Yes, continue to D(1)


3. Are you disclosing the information for purposes of Health Care Operations?

Yes/No If Yes, continue to C(1)


4. Are you disclosing the information to the Individual or his/her legally designated representative, or as directed by the Individual or his/her legally designated representative?

Yes/No If Yes continue to E(4)


5. Are you disclosing the information for purposes of Research?

Yes/No If Yes, continue to C(5)(a)(i)


a. If the information is for purposes of Research, has the IRB/privacy board required consent by:

(i) Notice to subjects? Yes/No If Yes, continue to E(1)

If No, continue to C(5)(a)(ii)

(ii) Opt‐Out? If Yes, continue to E(2)




41

If No, continue to C(5)(a)(iii)

(iii) Opt‐In? If Yes, continue to E(3)


6. Are you disclosing the information for purposes of public health activities to an authorized agency or authority?



6. Are you disclosing the information for a purpose not otherwise listed in this Section?

Do not execute disclosure, not appropriate for electronic HIE

D. State Law Requirements

1. Does state law require consent for disclosure of Personally Identifiable Health Information?

Yes/No If Yes, continue to D(2)

If No, continue to E(1)

2. If state law requires consent to disclosure of Personally Identifiable Health Information, does state law require:

a. A general Notice? Yes/No If Yes continue to E(1)

If No, continue to D(2)(b)

b. An Opt‐Out procedure? Yes/No If Yes, continue to E(2)

If No, continue to D(2)(c)

c. An Opt‐In? Yes/No If Yes, continue to E(3)

If No, continue to D(2)(d)

d. A reviewable Directive? Yes/No If Yes, continue to




42

E(4)

If No, continue to D(2)(e)

e. An unreviewable Directive? Yes/No If Yes continue to E(4)


3. If the information is Sensitive Health Information, does state law require:

a. A general Notice? Yes/No If Yes, continue to E(1)


b. An Opt‐Out procedure? Yes/No If Yes, continue to E(2)

If No, continue to D(3)(c)

c. An Opt‐In? Yes/No If Yes, continue to E(3)

If No, continue to D(3)(d)

d. A reviewable Directive? Yes/No If Yes, continue to E(4)

If No, continue to D(3)(e)

e. An unreviewable Directive? Yes/No If Yes, continue to E(4)


E. Due Diligence Findings

1. Does an applicable Notice describe the disclosure?






43

disclosure.

2. Has the Individual been provided with the Opt‐Out option?

Yes/No If Yes continue to E(2)(a)

If No, do not execute disclosure.

a. Is there a record that Opt‐Out has been exercised?

Yes/No If Yes, continue to E(2)(b)

If No, execute disclosure

b. If the Opt‐out has been exercised, does it apply to the disclosure?

Yes/No If Yes, do not execute disclosure.


3. Has the Individual been provided with the Opt‐In option?

Yes/No If Yes continue to E(3)(a)


a. Is there a record that Opt‐In has been exercised?

Yes/No If Yes continue to E(3)(b)


b. If the Opt‐out has been exercised, does it apply to the disclosure?

Yes/No If Yes, do not execute disclosure

If No, continue to E(3)(c)

c. Is the information also protected under 42 CFR Part 2?

Yes/No If Yes, continue to E(3)(c)(i)


(i) Is the information accompanied by the required redisclosure statement?

If Yes, execute disclosure





44

disclosure

4. Has the Individual provided a Directive? Yes/No If Yes continue to E(4)

a. Is the Directive Subject to pre‐disclosure review?

Yes/No If Yes, continue to E(4)(b)

If No, continue to E(4)(d)

b. Has the Directive been reviewed and the disclosure approved?

Yes/No If Yes, continue to E(4)(d)

If No, continue to E(4)(c)

c. If the Directive has not been approved, does policy require approval?

Yes/No If Yes, do not execute disclosure

If No, continue to E(4)(d)

d. Does the Directive apply to the disclosure?





Consent Process Management ______________________________________________________________________________

45

6. CONSENT PROCESS MANAGEMENT

The specific documents and procedures which are necessary (or prudent) for consent management will vary depending on the consent process used. Even in a minimal No Consent process, it may be prudent to record the purpose for which the information was shared and a summary of the contents to demonstrate that it qualified for disclosure under that process.9 Processes for Opt‐In and Opt‐Out consents would require not only specific content and for authorization documentation, but may need to include records of identity verification, and would definitely need procedures to record and communicate the decision made by the individual and ensure there are no future disclosures inconsistent with it.

The content of some consent‐related documentation is required by law, as with authorizations under HIPAA and some other laws. Procedures for obtaining and managing documentation, and for documenting consent‐related actions, tend not to be specified by law (except for HIPAA document retention periods), and are determined as a matter of prudent compliance.

a. Consent Document Contents and Records Management

The most detailed requirements for consent document content are probably for the HIPAA authorization. This form of document is required for opt‐in for most PHI disclosures other than those for treatment, payment and healthcare operations (see below).10

A valid HIPAA authorization is required to include the following:11

The name or other specific identification of the person(s) or class of persons authorized to use or disclose the information

The name or other specific identification of the person(s) or class of persons to whom the covered entity may make the use or disclosure

A description of each purpose of the requested use or disclosure.

An expiration date or event that relates to the individual or the purpose of the use or disclosure.

9 For example, a disclosure of PHI from one provider to another for treatment of the individual should be permitted given notice under a properly drafted notice of privacy practices without individual action and without being subject to the “minimum necessary” rule. A transfer of the same information between the same providers for some kinds of research, on the other hand, might require written individual authorization and might be restricted to a smaller data set. 10 See 45 CFR § 164.508. 11 See 45 CFR § 164.508(b) – (c).




46

Signature of the individual and date. If the authorization is signed by a personal representative of the individual, the authorization must include a description of the representative's authority to act for the individual.

A statement of the individual's right to revoke the authorization in writing and either a reference to the revocation right and procedures described in the notice, or a statement about the exceptions to the right to revoke and a description of how the individual may revoke the authorization.

Statements describing possible consequences for failure to sign the authorization, such as inability to enroll in research‐related treatment

A statement that information used or disclosed pursuant to the authorization may be subject to redisclosure by the recipient and may no longer be protected by HIPAA.

Authorizations for multiple purposes are permitted in only a very few marginal circumstances.12

While HIPAA is a sound model and minimum legal requirement for authorizations, 42 CFR Part 2 and FERPA add other, specific requirements for authorizations, as do many state laws. HIPAA therefore sets up a presumptive Opt‐In process for many secondary uses of PHI, which can be used as a framework for other consents where documentation is required.

HIPAA also establishes a minimum recordkeeping requirement of six years from the later of the date of creation or the last effective date of documentation and communications required to be documented under its rules.13 This requirement applies to authorizations, notices of privacy practices and denials of information access, and it might be prudent to document some actions and communications not specifically required to maintain sound compliance records.

Many forms of consent are also subject to termination or expiration, which have to be managed as well.14 HIPAA authorizations must be revocable at any time and must have an expiration date or identified event which will cause it to expire,15 and many state laws have comparable requirements. Under HIPAA a disclosure based upon an expired or revoked authorization should only be a HIPAA violation by the disclosing and not the receiving entity, unless the receiving entity knows it has expired or been revoked.16 Entities responsible for disclosing PHI therefore need to implement procedures (and if feasible technical mechanisms) to ensure consent expirations and revocations are identified and implemented.

12 45 CFR § 164.508(b)(3). 13 See 45 CFR § 164.530(j)(2). 14 A HIPAA “No Consent” for TPO does not appear to expire, but might be revoked if the Covered Entity maintaining the information accepts an individual request for restrictions. 15 See 45 CFR § 164.530(b)(5), (c)(1)(v). 16 See 45 CFR § 164.530(b)(2).




47

Depending on the governance model, HIE functionality might include applications which electronically store and forward copies of consent documents signed by individuals, in scanned hard copy or electronically signed. The documentation would itself be protected information, so would itself have to be maintained subject to appropriate access limitations. As a quality control function such a database might be subject to HIO audit to ensure that the documentation is adequate and that consent limitations are being enforced by HIE consent mechanisms.

b. Electronic Consent Documentation

One alternative for managing consent records for HIE is the implementation of electronic processes for consent documentation as well. A recent HIE survey indicated that 35 out of 199 respondents had implemented electronic means for obtaining and managing patient consent, while 82 planned to do so.17 This electronic documentation approach might be implemented not only for execution of patient consent records, but for electronic contracts and limitations acknowledgments between HIO participants as well.18

The use of electronic records as operational documents and electronic signatures as the equivalent of “wet” signatures is specifically authorized by the federal Electronic Signatures in Global and National Commerce Act (“E‐SIGN”),19 and at the state level by the Uniform Electronic Transactions Act (“UETA”) which has been adopted in all but a handful of states.20 E‐SIGN and UETA are generally consistent, and E‐SIGN does not apply where UETA is applicable.21 The two statutes therefore provide a consistent national legal framework for electronic signatures and documentation. Electronic commerce and electronic contracting law is now fairly well settled and is considered “mature.”22

E‐SIGN imposes some consumer protection obligations which may burden electronic consent processes if entry into the consent is required or an incentive for the individual to obtain healthcare goods or services.23 If the consent is not so conditioned, E‐SIGN and UETA allow the

17 eHealth Initiative, supra note 32, at 25. 18 See e.g. HealthKey Collaborative, supra note 33. 19 Electronic Signatures in Global and National Commerce Act, Pub. L. No. 106‐229 (June 30, 2000). 20 See Christiansen, Apgar and Melamed, supra note 3, at 19 – 20. 21 15 U.S.C. § 7002. 22 Moringiello and Reynolds, Electronic Contracting Cases 2008–2009, supra note 32 at 317. 23 If an individual is a “consumer,” he or she has to opt‐in to the use of electronic contracting and be provided with lengthy notices, and the party providing the notice has to adopt potentially burdensome compliance procedures. See 15 U.S.C. § 7006(1a)(c).

E‐SIGN defines a “consumer” as “an individual who obtains, through a transaction, products or services which are used primarily for personal, family, or household purposes[.]”15 U.S.C. § 7006(1). A “transaction” is defined as “an action or set of actions relating to the conduct of business, consumer, or




48

use of electronic documentation for consent purposes (within the meaning of this Report), and allow any kind of “electronic sound, symbol or process” associated with an electronic record to be an electronic signature, as long as it is intended as such by the signing party.24

An electronic signature can therefore be a typed name in a box in an electronic form, a user name and password, or one of many other electronic processes, as long as it can be shown it was executed by the individual with intent to sign the associated record. The implementation of reliable processes to record and maintain records of electronic signatures associated with them is therefore necessary, and to the extent such information is electronic PHI protection of such records according to the HIPAA Security Rule is required.

A perhaps more difficult issue is presented by the need for processes which reliably demonstrate the identity of the individual executing the electronic signature. The reliability of the processes adopted will depend very much on the potential risks of erroneous identification; in information security terms, this is the problem of “authentication” of identity.

At one end of the consent spectrum there is no risk of misidentification, because there is no documented consent required. As individual control increases, however, the risk of error increases. For directives the risks associated with misidentification should be considered quite high, since an erroneous (or fraudulent) misidentification could lead to disclosure of highly sensitive PHI for purposes of criminal or malicious misuse.25

Electronic signatures for consents should therefore be implemented based on analysis of the risks associated with the consents. An appropriate and authoritative framework for such an analysis has been developed and adopted by the Centers for Medicare and Medicaid Support (“CMS”) and the National Institute of Standards and Technology (“NIST”).

While not binding on nongovernmental organizations as a matter of law unless incorporated in a contract between a federal agency and the nongovernmental organization,26 NIST and CMS standards are likely to be highly influential in regulatory determinations of the adequacy of HIPAA Security Rule and related compliance.27

commercial affairs between two or more persons, including . . . the sale . . . exchange, licensing, or other disposition of . . . personal property, including goods and intangibles, [and] services[.]”15 U.S.C. § 7006(12). “Consumer” status may therefore be avoided, by avoiding using the authorization as part of a sale or exchange of health care goods or services. 24 15 U.S.C. § 7006(5). 25 See e.g. Dixon, Medical Identity Theft: The Information Crime that Can Kill You (Spring 2006). 26 E.g. a CMS business partner such as a Medicare carrier or fiscal intermediary. 27 As a statutory matter NIST standards apply only to federal agencies. However, NIST influenced the drafting of the HIPAA Security Rule, see e.g. U.S. Department of Health and Human Services, Health Insurance Reform: Security Standards; Final Rule, 68 F.R. 8334 (February 20, 2003), preamble at 8346.




49

CMS categorizes information sensitivity in four levels, from “Low” to “High;” PHI is categorized as “High Sensitivity.”28 Sensitivity levels are then matched against appropriate authentication “assurance levels” to determine appropriate technical solutions and procedures, under NIST standards. 29

NIST authentication requirements are ranked in four categories based on the potential consequences of authentication errors. The use of online credentials – identification and authentication processes and information30 ‐ for transactions is then ranked according to their “assurance level,” or suitability for various types of online transactions, from Level 1 (low) through Level 4 (high).31 At the same time online transactions are mapped to their own appropriate assurance levels based on data sensitivity from low to high.32

Demographic information is considered “Moderate Sensitivity” for transaction purposes, while clinical information is considered “High Sensitivity.” Examples of transactions and their assurance levels include the following:33

Level 2 Assurance: “A beneficiary changes her address of record through the Social Security web site. The site needs authentication to ensure that the entitled person’s address is changed. This transaction involves a low risk of inconvenience. Since official notices regarding payment amounts, account status, and records of changes are sent to

28 See U.S. Department of Health and Human Services Center for Medicare and Medicaid Support, Information

Systems Security Policy, Standards and Guidelines Handbook Version 1.2 (July 19, 2004) (“CMS Handbook” at 43 – 44: High Sensitivity information includes information “for which unauthorized disclosure would constitute a ‘clearly unwarranted invasion of personal privacy’ likely to lead to specific detrimental consequences for the individual in terms of financial, employment, medical, psychological, or social standing[.]” 29 U.S. Department of Commerce, National Institute of Standards and Technology, Electronic Authentication Guide (NIST Special Publication 800‐63, September 2004) (“Electronic Authentication Guide”).

30 For authentication purposes, a “credential” is an “object that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a person.” NIST Electronic Authentication Guide at 5. “Object” in this context refers to a data module which links information about a person (i.e., “identity”) to the “token” used to authenticate the person, while the “token” is “[s]omething that the claimant possesses and controls (typically a key or password) used to authenticate the claimant’s identity.” Id. at 6. Online “credentials” therefore exist when a system (1) can identify a user (by connecting a log‐in name to a record of identification information) and (2) can link an authentication token (e.g. password or smart card including a cryptographic key) to that user. 31 The following categories were established by the U.S. Executive Office of the President, Office of Management and Budget, E‐Authentication Guidance for Federal Agencies (OMB 04‐04, December 16, 2003) (“E‐Authentication Guidance”), which is implemented by the NIST Electronic Authentication Guide. 32 Based on E‐Authentication Guidance at 9 – 11. 33 Id.




50

the beneficiary’s address of record, it entails moderate risk of unauthorized release of personally sensitive data.”

Level 3 Assurance: “An agency employee or contractor uses a remote system giving him access to potentially sensitive personal client information. He works in a restricted‐access Federal office building. This limits physical access to his computer, but system transactions occur over the Internet. The sensitive personal information available to him creates a moderate potential impact for unauthorized release.”

Level 4 Assurance: “An agency investigator uses a remote system giving her access to potentially sensitive personal client information. Using her laptop at client worksites, personal residences, and businesses, she accesses information over the Internet via various connections. The sensitive personal information she can access creates only a moderate potential impact for unauthorized release, but her laptop’s vulnerability and her non‐secure Internet access raise the overall risk.”

Based on assurance levels as determined above, NIST standards require a number of processes intended to ensure the validity of online credentials. The validity of a credential depends not only upon its technical characteristics (such as password length and robustness), but also crucially upon how the user is identified in the first place, how the credential is transmitted to the user, and how the user protects it against unauthorized use; even the technically strongest credential can be compromised at any of these stages.

The first step in credentialing is registration of the user. In this step some party – the operator of the information system in which the credential is to be used, some party acting on behalf of the system operator, or a third party otherwise trusted by the system operator – obtains evidence of the user’s identity. This step is particularly vulnerable to fraud by the applicant, who may represent a false identity. The validity of a credential therefore depends fundamentally on the rigor of the required evidence of identity.

At the lowest level potentially applicable to consents, Level 2 credentials require either (1) in‐person presentation of valid, current photo identification, or (2) remote registration including confirmation of a the current validity of the identification, plus financial account information or some other non‐public information which can be confirmed by the registering agent.34 Level 3 credentials are based on a comparable process, with additional rigor in the confirmation of information about the applicant in the course of remote registration.35 Finally, Level 4 credentials may only be issued after in‐person presentation of identification and confirmation of identifying information.36

34 Id. at 23, 25. 35 Id. at 24. 36 Id. at 24 ‐ 25.




51

The second step is issuance of the credential, for example a user name and password. Somehow, the information system operator (or its representative) must reliably transmit the credential to the user. The principal vulnerability in this step is interception of the credential information before it reaches the correct user, so the validity of a credential therefore also depends upon how well protected it is in transmission to the user.

Credential transmission methods turn first on one principal distinction: Whether they are sent “in‐band” or “out‐of‐band.”37 “In‐band” transmission means that the credential is transmitted to the user via the same channel in which the user has asserted his or her identity. For example, in a Level 2 transaction a user might access a web page and enter information asserting his or her identity. A password might then be transmitted back to the user “in band” as part of the same session. An “out‐of‐band” transmission, on the other hand, might send the password to the user via e‐mail or U.S. mail.

Once the correct user has received the credential it is vulnerable to third party access, as when a password is shared or accidentally disclosed by the user. The validity of a credential therefore also depends on how well the user protects it. It also depends on accurate, timely termination of the credential (or its suspension, where allowed and appropriate) if it has been compromised, or the user’s online rights have been terminated for some reason.

A policy or contractual agreement requiring credential protection is therefore an essential element of authentication. One approach to this which may be of significant value for consumer purposes is the use of an “informed consent” interview and/or form, which includes both disclosures of possible risks of online communications and a record of their acceptance.38

Finally, authentication of online users depends upon one or more factors: Something the user knows; something the user has; or something the user is. A password or PIN would be “something the user knows,” while a smart card would be “something the user has” and biometric characteristics (e.g. fingerprints) would be “something the user is.” Authentication may rely upon one, two or more factors, and depending on the number of factors used is referred to (logically enough) as single‐factor, two‐factor, multiple‐factor, etc.

The choice of factors, and number of factors required, is as always risk analysis‐based, with appropriate consideration not only of risks but of costs, burdens and available resources. Some highly secure solutions, such as public key infrastructure, have proven too costly and burdensome to implement in all but the most sensitive environments.

The choice of factors may also have a significant effect on the short‐term adoption of HIE as it may impose new requirements and changes in workflows. The history of electronic data exchange in health care shows that many health care organization are resistant to changing their systems. A good example is the initial adoption of the HIPAA electronic transactions, when

37 See e.g. CMS Handbook at 73 – 74. 38 See American Medical Association Ethics Policy E‐5206, The Use of Electronic Mail.




52

some organizations sought changes and delays because they had just upgraded their systems prior to the regulations or needed more time to ensure a smooth transition.

Table 27: Electronic Signature Processes

Transaction Type

Assurance Level

User Registration Transmission of Credential

Minimum Factors

Basic Level 2 In‐person presentation of photo ID

On‐line representation of photo ID plus third party proofing

In‐band issuance with out‐of‐band notice

Single factor

High Level 3 In‐person presentation of photo ID plus sponsor or third‐party proofing

On‐line representation of photo ID plus sponsor or third‐party proofing

Out‐of‐band issuance

Two factor

Documents

NGA toolkit v.1.2 - Justice Clearinghouse · This Consents Toolkit is intended to support the development and implementation of consent processes consistent with the most stringent