20091005 consumer preferences draft requirements document

8/14/2019 20091005 Consumer Preferences Draft Requirements Document

1/42

U.S.DepartmentofHealthandHumanServicesOfficeoftheNationalCoordinatorforHealthInformationTechnology

ConsumerPreferencesDraftRequirementsDocument

October5,2009


2/42

Consumer Preferences Draft Requirements Document

October 5, 2009Off ice of the Nat ional Coordinator for Health

Informat ion Technology2

Table of Contents1.0 Preface........................................................................................ 3

1.1 Approach ..................................................................................................................... 31.2 Document Overview ......................................................................................................... 31.3 Requirements Document Review Guidance ................................................................................ 5

2.0 Introduction .................................................................................. 62.1 Progress to Date.............................................................................................................. 72.2 Scope ......................................................................................................................... 9

3.0 Consumer Preferences Stakeholders ...................................................... 114.0 Issues and Policy Implications ............................................................ 12

4.1 Consumer Participation .....................................................................................................12 4.2 Consumer Education........................................................................................................12 4.3 Access, Control and Disclosure ............................................................................................12 4.4 Segmentation of Health Information .......................................................................................13 4.5 Liability and Accountability ................................................................................................14

5.0 Perspectives & Scenarios .................................................................. 155.1 Perspectives/Roles: .........................................................................................................15 5.2 Scenarios ....................................................................................................................15

6.0 Process Diagrams ..................................................................... 166.1

Scenario 1: Creation of a Preference .......................................................................................16

6.2 Events and Actions for Scenario 1: Creation of a Preference .............................................................17 6.3 Scenario 2: Preference Management .......................................................................................22 6.4 Events and Actions: Scenario 2 Management and Exchange of Preferences .............................................23

7.0 Information Exchanges .................................................................... 317.1 Legend.......................................................................................................................32

8.0 Functional Needs........................................................................... 338.1 Universal Functional Needs ................................................................................................33 8.2 Consumer Functional Needs................................................................................................33 8.3 Primary/Secondary Receiving Organization Functional Needs ...........................................................34

9.0 Data Set Considerations ................................................................... 369.1 Identity and Preference Verification .......................................................................................36 9.2 Data Classification ..........................................................................................................36

10.0 Appendix A: Glossary ..................................................................... 39


3/42




1.0 Preface1.1 Approach

Recognizing that the creation and exchange of consumer preferences is a highly sensitive

and complex topic, the Office of Interoperability and Standards (OIS) has amended itsapproach to developing the Requirements Document (formerly known as a Use Case) to

ensure a more coordinated and collaborative process between requirements development

and standards harmonization. This updated approach includes gaining input from a greater

number of stakeholders and greater collaboration across Office of the National Coordinator

for Health Information Technology (ONC), the Healthcare Information Technology Standards

Panel (HITSP) and the Nationwide Health Information Network (NHIN) for developing the

requirements that may inform future development of certification criteria, including those

for electronic health records (EHRs) and health information exchange (HIE).

Policies surrounding consumer preferences are expected to evolve over time. This

document will enable standards development organizations to harmonize standards in a

manner that will accommodate potential future policy decision outcomes. This

Requirements Document is designed to be forward thinking and highlights both a

progressive current and future state scenario that is supported by electronic systems.

1.2 DocumentOverviewOIS has refined the development process and format of the Requirements Document, to

improve the facilitation of the standards development and harmonization process. This

Requirements Document is focused on information needed to facilitate the electronic

exchange of consumer preferences regarding the use and management of their associated

health information. The 2009 Consumer Preferences Requirements Document is divided

into the following sections:

Section 1.0, Preface, includes a Requirements Document Review Guidance, that

indicates who the end users of this document are intended to be and what sections

may be most relevant to these various end users. Additionally, this section outlines

the amended approach utilized to develop the Requirements Document, describes

the sections of the document and denotes any significant changes from previous Use

Cases.

Section 2.0, Introduction and Scope, describes the background, progress to date, therequest being made to HITSP and the scope of that request.

Section 3.0, Stakeholders, lists the individual stakeholders and organizations that

participate in the activities described in this Requirements Document.


4/42




Section 4.0, Issues and Policy Implications, describes issues, obstacles and policy

considerations and/or implications related to accommodating and supporting

consumer preferences.

Section 5.0, Perspectives & Scenarios, describes the perspectives/roles of the

stakeholders participating in the events and actions of the underlying scenarios that

are supported by the process diagrams and information exchanges described in later

sections.

Section 6.0, Process Diagrams, depicts the business processes surrounding consumer

preferences that may or may not involve health information exchange; the process

diagrams are described in the Events and Actions component of this section.

Section 7.0 Information Exchanges; depicts the focused information exchanges that

standards development organizations should address.

Section 8.0, Functional Needs, describes the combination of end-user needs and

system behaviors that support interoperability and information exchange.

Section 9.0, Data Set Considerations, provides a comprehensive (though not

exhaustive) framework that can be used to support standards development and to

accommodate the major types of consumer preferences.

Appendix A, Glossary, provides contextual descriptions of key concepts and terms

introduced in this Requirements Document.


5/42




1.3 RequirementsDocumentReviewGuidanceThe Consumer Preferences Requirements Document describes a framework for the

electronic exchange among multiple stakeholders of the preferences consumers may have

regarding the management of and controlling access to their information and potentially

sensitive health information (SHI) utilizing standard message formats, terminologies and

data sets (further defined in Sections 2.0 and 9.0). Further, it is intended to support

current and future health information exchange activities as these concepts and associated

terminologies evolve.

In order to best support multiple stakeholders, guidance on how to review this document is

included below. The guidance highlights the sections that may be most pertinent to a given

stakeholder. These sections can be utilized separately or in combination.

Figure 1.3 Requirements Document Review Guidance

Requirements Document Review Guidance

Stakeholder Section Focus

Consumer Advocacy Groups& Policy Setting Organizations

Issues & Policy ImplicationsSection

Guiding principles

Standards DevelopmentOrganizations (SDO)

Perspectives and Scenarios,Process Flows, Events andActions, Information Exchange

Standards harmonization

Providers Process Flows, InformationExchange, Issues & PolicyImplications

May be incorporated intocertification criteria

Consumers & General Public Issues & Policy ImplicationsSection, Process Flows,Events and Actions

Informative


6/42




2.0 IntroductionAs the healthcare system moves toward the adoption of electronic health records, the need

to protect the privacy of health information and promote security is paramount. Inaccordance with the American Recovery and Reinvestment Act of 2009 (ARRA), which

includes the Health Information Technology for Economic and Clinical Health (HITECH) Act,

privacy and security protections are essential to building public trust and encouraging the

use of Health Information Technology (HIT). Without appropriate protections, consumers

may be less willing to participate in information exchange and the benefits of an

electronically enabled healthcare delivery system may not be fully realized.

The electronic exchange of consumer preferences is an integral step on the path towards

enhanced privacy, security and public trust in the exchange of health information.

For the purposes of this document, the term consumer preferences is used to collectively

represent several interrelated capabilities including, but not limited to:

the ability for a consumer to define permissions for who is permitted to access

information in their electronic health record (EHR) and under what circumstances

this access is appropriate,

the ability for consumers to express preferences regarding how and under what

circumstances their health information should or should not be made available to

others by their healthcare providers;

the ability for consumers to authorize the release of their health information to

another provider or third party; and

the ability to establish various types of consumer preferences including but not

limited to consents, advance directives and other potential types outlined in Section

9.0, Data Set Considerations.

In order to realize the benefits of the electronic exchange of consumer preferences,

technologies, harmonized data standards and policies which facilitate the expression,

execution and exchange of consumer preferences and their associated health information,

must be defined in order to support interoperability. These standards must address the

privacy concerns of consumers and organizations and be founded on business processes

which comply with certification rules prescribed by the Department Health & Human

Services (HHS) as well as state and federal law.

The identification and harmonization of standards for exchanging consumer preferences will

create a foundation which may facilitate and encourage consumers to participate in health

information exchange activities, to authorize the release of their data and to determine what

information should be released to a specialist, hospital, personal health record (PHR), a

surrogate such as a Medical Home or a health record bank. While different consumer

preferences may be applicable in different jurisdictions and settings, a standardized


7/42




approach to the exchange and use of those preferences will support common HIT

implementations as well as interactions between disparate organizations.

2.1 ProgresstoDateIn April and June of 2008, the American Health Information Community (AHIC) approved arecommendation to develop documents that address Extensions/Gaps from the Use Cases

published between 2006 and 2009. One of the Extensions/Gaps prioritized for subsequent

processing in the national health information technology (HIT) agenda activities in early

2009 was consumer preferences. AHIC requested that the 2009 Consumer Preferences

Extension/Gap address the electronic exchange of information describing consumer

preferences between consumers, healthcare providers, healthcare entities, entities involved

in health information exchange activities and with other entities as authorized by the

consumer.

In the development of this Requirements Document the AHIC priorities, 2009 Consumer

Preferences Extension/Gap and other previous publications were referenced. This ConsumerPreferences Requirements Document will provide further context for the national health

information technology agenda activities, beginning with the selection of harmonized

standards by HITSP. Therefore, this Requirements Document is intended to expand upon

the Consumer Preferences Extension/Gap Document that was published in early 2009.

In subsequent activities, the harmonized standards will be tested, refined and implemented.

Components that need to be considered during the standards identification and

harmonization activities include a standardized vocabulary, data elements, data sets and

technical standards that support the information needs and processes of consumers and

those involved in implementing consumer preferences. During the development of the

document there will be an opportunity for review and feedback by interested stakeholders

within both the public and private sectors.

To date, neither the ONC Coordinated Federal Health IT Strategic Plan, nor the national

health information technology agenda, including the activities of AHIC and HITSP, has

formally addressed all of the interoperability considerations for the communication of

consumer preferences to support the goal of patient/consumer focused healthcare and

population health.

Therefore, the purpose of this document is to support the ONC Strategic Plan and the

national HIT agenda related to standards development and harmonization process by

describing business processes, information exchanges, stakeholders, functionalrequirements, issues and policy implications involving consumer preferences.

Previously published AHIC Use Cases and HITSP work products should also be leveraged

during standards harmonization for this Requirements Document.


8/42




The 2006 Consumer Empowerment Registration and Medication History Use Case

describes the needs for a consumer to be able to establish permissions and access

rights for viewing their data;

The 2007 Consumer Access to Clinical Information Use Case describes the needs for

a consumer to identify those providers who are permitted to access information in

the consumers PHR and what data they are permitted to access. Also describes the

capabilities needed to communicate a consumer's decisions to other entities which

also hold data about the consumer.

HITSP Access Control Transaction Package (HITSP/TP20)

HITSP Manage Consent Directives Transaction Package (HITSP/TP30)

HITSP Patient ID Cross-Referencing Transaction Package (HITSP/TP22)


9/42




2.2 ScopeThe Consumer Preferences Requirements Document describes a framework for the

electronic exchange among multiple stakeholders of the preferences consumers may haveregarding the management of and controlling access to their information and potentially

sensitive health information (SHI) utilizing standard message formats, terminologies and

data sets. The scope of this Requirements Document includes a high-level description

detailing:

Key actors involved in the expression and creation of consumer preferences, namely

the consumers, providers and organizations handling this information

Descriptions of the expression, transmission and application of consumer preferences

How consumer preferences are exchanged between electronic systems

The exchange of health information authorized by a consumer preference

The potential types of consumer preferences

The location of a consumer preferences origin and storage

In addition, examples of implications and ramifications regarding the execution of consumer

preferences are discussed.

Certain aspects of the handling of consumer preference data are outside of the scope of this

document including:

The details surrounding consumer education processes and requirements

The process for reconciling situations where multiple, conflicting preferences exist forone consumer/patient

Policies regarding whether or not a consumer preference is expected to be honored

or accepted when sent from one entity to another

The consequences of not following appropriate consumer preference procedures asprescribed by state, local or entity policy

The process and requirements for classifying and segmenting an individualsdemographic and clinical information in a way that supports that individuals

expressed preferences regarding what information or data types should be

designated as sensitive health information

The mechanics of consumer auditing and tracking of this information, which has been

addressed in the 2007 Consumer Access to Clinical Information Use Case

These out-of-scope issues may best be handled by laws in particular jurisdictions, policies

the entities sending or receiving this information and, in some cases, by the Department of

Health and Human Services (HHS).

The policies for supporting consumer preferences are expected to evolve in the coming

years, which will necessitate the leverage and expansion of current standard to support

evolving needs.


10/42




At the highest level, consumers, require the capability to opt in or opt out of the

exchange of their health information. Consumers may also request that only certain

information, episodes of care or classes of information be shared. These classes of

information could be classified at varying levels of granularity. Defining the needed levels of

granularity is not the main focus of this Requirements Document.

For the purposes of organizing consumer preference information for increased levels of

granularity, the information may be broadly classified. Section 9.0 of this document (Data

Set Considerations) discusses classification in greater detail.

This Requirements Document focuses on processes, functional needs and data set

considerations relating to consumer preferences in order to help in the development of

standardized data exchanges. The Office of Interoperability and Standards (OIS)

acknowledges that there are still key policy issues which need to be defined and developed

in the area of consumer preferences. While these policy decisions are beyond the scope of

this document, the implications of these policy decisions will be addressed in Section 4.0 of

this document (Issues and Policy Implications).


11/42




3.0 ConsumerPreferencesStakeholdersExamples of stakeholders that may be directly or indirectly involved in the exchange of

consumer preference information are listed below. Contextual descriptions of each type ofstakeholder can be found in the Glossary (Appendix A).

Stakeholders that may be directly involved in the exchange of consumer preference

information may include:

Figure 3.0.1 Consumer P reference Stakeholders

Consumer Preference Stakeholders

Clinicians Healthcare Payors

Consumers HIT Vendors and Providers

Government Agencies Laboratories

Health Information

Exchanges

Patients

Health Record Banks Public Health

Agencies/Organizations

Healthcare Entities Standards Development

Organizations

Additional stakeholders that may assist in consumer preference information communication

may include:

Figure 3.0.2 Additional Stakeholders for Consumer Preferences

Additional Stakeholders

Family Members/Surrogate Decision

Makers/Caregivers

Public Health Agencies

Research Entities


12/42




4.0 IssuesandPolicyImplicationsA number of issues in todays health information technology environment may present

obstacles to achieving healthcare data standardization and interoperability. Many issuesand policy implications common to all exchanges of health information were presented and

discussed within the 2006 2009 AHIC Use Cases. Examples of specific issues and

obstacles more specifically related to exchanging consumer preferences are outlined below.

4.1 ConsumerParticipation1. Additional guidance from ONC may be needed in the area of consumer participation in

electronic health information exchange. A national policy may be needed to address

the variations in policies regarding opt-in/opt-out, classifications and granularity

requirements across health information exchanges and healthcare organizations. The

variations could make integration and the implementation of electronic exchange ofconsumer preferences more difficult.

4.2 ConsumerEducation1. For the optimal execution of consumer preferences, consumers must understand the

content of their electronic health record, their rights regarding the protection and use

of their information and the implications of disclosingor not disclosing their medicalinformation.

2. In addition, organizations that receive consumer preferences may be responsible for

informing the individual of any limitations that may exist within the organization, their

systems or state and federal law that could prevent them from acting in accordancewith the preferences expressed by the consumer. Both of these issues may require

some level of consumer-oriented educational intervention to be effectively addressed.

4.3 Access,ControlandDisclosure1. While consumers may express preferences for who can view and exchange their

personal health information, privacy controls as well as the means for restricting data

access are not standardized nor are they entirely supported by existing policies or

regulations. In addition, the policies and regulations that do exist vary widely from

state to state and among providers and healthcare entities.

2. A clear standard or policy may be needed to establish a universal method formanaging the process for notifying appropriate stakeholders of the existence of a

consumer preference. In some instances, the mere existence of a consumer

preference for a specific category (e.g., HIV status) may provide clues to an

individuals health status.


13/42




3. A clear standard or policy may be needed to identify that a category or type of data

has been withheld due to the expression of a consumer preference. There may be a

need to communicate this event without specifying the category or type of data that

has been withheld.

4. Information sharing and access policies are not standardized among providers or HIEs

and may present challenges to interoperability regarding conflicts that arise.

5. Additional policy guidance may be needed to address the use of health information

data after it has been received or generated by a covered entity. Protections to

individually identifiable health information (policy and technical) may be required to

ensure that consumers are informed of and approves any secondary uses of their

health information.

6. The existence of consumer-provided data (e.g., data entered into a PHR) in a

repository should not imply that the consumer has consented to the sharing of that

information. By default this information remains private and requires authorizationfor disclosure.

7. During the collection of consumer preferences, policies may need to be established to

prevent situations where consent is obtained through coercion. For example, coerced

consent situations may occur when a consumer is given a financial penalty or reward

for providing consent or may occur when a consumer is unaware of their rights to

withhold or limit the disclosure of personal information.

8. Currently states have differing break the glass access regulations and restrictions.

Standardized guidance may be required to establish break the glass protocols that

can be consistently interpreted across state lines.

4.4 SegmentationofHealthInformation1. Clarification may be needed for consumers to explain the protections relating to and

the differences between Sensitive Health Information (SHI), Protected Health

Information (PHI) and Individually Identifying Health Information (IIHI). A national

discussion that explores the definition of sensitive health information and how that

information might be classified would help to advance the meaningful creation and

use of standards and policies for identifying and managing these different classes of

information.

2. A universal process or policy may be needed for classifying sensitive healthinformation for the purposes of upholding consumer preferences. This may include a

common taxonomy for defining elements that collectively articulate consumer

preferences within electronic health records and other data stores.


14/42




3. A national policy or standard may be needed to address a consistent method of

expressing consumer preferences within the varying state laws and healthcare entity

policies. These policies accommodate varying levels of granularity and protections

among states and prescribe conflicting levels of responsibility. A harmonized method

to accommodate the variances in consumer preferences policies may be required forinteroperability.

4.5 LiabilityandAccountability1. Additional guidance may be needed to reconcile and resolve situations where

consumer preferences are in conflict. Situations may arise from consumers providing

multiple preferences or state laws may override or conflict with a consumers

preference.

2. Guidance regarding the enforcement of consumer preferences may be needed. An

understanding of responsibilities and liabilities may need to be defined or clarified for

organizations that create, exchange or store consumer preferences.

3. Laws, policies and procedures regarding liability, oversight and accountability may

need to be established or standardized for handling breaches of consumer

preferences.

4. State laws regarding consumers ability to limit access to their health information to a

specific person, practitioner or department within a healthcare organization vary

widely. Additional policies may be needed to clarify this issue.

5. Providers have expressed concerns regarding potential liabilities they may assume in

instances where their patients withhold some portion of their health information.

Further discussion around potential policy approaches to addressing this issue is

warranted.

6. Entities may enforce policies which dictate the acceptance or honoring of consumer

preferences provided by other organizations or entities. These internal policies may

be subject to federal, state and local law, which may hinder the electronic exchange

of consumer preferences.


15/42


5.0 Perspectives&ScenariosThis section describes the actors participating in the events, their roles or perspectives and

their actions in the context of the underlying scenarios. These scenarios are supported by

the Process Diagrams (Section 6.0) and Information Exchanges (Section 7.0).

The Process Diagrams (Section 6.0) outline the business processes surroundingconsumer preferences, which include descriptions of events and actions.

The Information Exchanges (Section 7.0) compliment the process diagrams andare meant to express the focused information exchange events that HITSP should

address.

5.1 Perspectives/Roles: Consumer: Any recipient or legal proxy of a recipient of healthcare who wishes to

create preferences regarding aspects of their care and how their health-relatedinformation (HRI) is accessed or shared.

Primary Receiving Organization: Any organization (provider, information

exchange or other information recipient) who receives and may act on or manage aconsumer preference and its related health information.

Secondary Receiving Organization: Any organization (provider, informationexchange or other information recipient) who receives from another organization and

may act on or manage a consumer preference and its related health information.

5.2 ScenariosFigure 5.2 Consumer Preferences Scenarios

Scenario 1: Creation of a P reference The process by which the consumer

articulates a consumer preference by expressing their preference (decisionsregarding access control, consent, content preferences, etc.) to the primary receiving

organization.

Scenario 2: Preference Management: Application, Exchange and

Replacement Process The process by which the primary receiving organization

identifies, retrieves, applies, updates and exchanges a consumers preference to a

secondary receiving organization

Off ice of the Nat ional Coordinator for HealthOctober 5, 2009 15

Informat ion Technology


16/42


6.0 ProcessDiagramsThis section depicts the business processes surrounding consumer preferences and not necessarily

process diagrams are described in the Events and Actions component of this section.

6.1 Scenario1:CreationofaPreferenceFigure 6.1 Scenario 1: Creation of a P reference P rocess Diagram

Secondary

Re

ceiving

Organization

Primary

Receiving

Organization

Consumer

Off ice of the Nat ional Coordinator for HealthOctober 5, 2009



17/42




6.2 EventsandActionsforScenario1:CreationofaPreferenceCode Event

Action

Perspective

Description

6.1

Event: Provide Education

MaterialsPrimary Receiving Organization

6.1.1Action: Primary receiving

organization provides educational

materials to the consumer

Note: This action is out of scope

In order for consumers to make informed choices regarding their

preferences for the classification and handling of their health-

related information, they may need to be educated regarding their

choices and the content of their EHR. The primary receiving

organization may need to provide educational materials to

consumers prior to the expression of their preferences explaining

the choices they could make regarding the sharing or sequestering

of information they might consider sensitive as well as information

that may be pertinent in the delivery of their healthcare. This

information may be in the form of printed documents, videos, on-

line or live interactive sessions. The details of the delivery and

content of this information will likely vary from state to state and

from organization to organization.

6.2Event: Receive/ Review

Education Materials

Consumer

6.2.1Action: The consumer receives

and reviews the education

materials before creating a

preference with the primary

receiving organization


In order to make informed choices regarding their preferences for

handling their health-related information, the consumer may need

to acquire some level of education, likely provided by their

healthcare provider, PHR or HIE. This step may need to precede

any specific decisions or actions taken by the consumer in

expressing their preferences for handling their HRI. The details of

the delivery and content of this information will likely vary from

state to state and from provider to provider.


18/42




Code Event

Action

Perspective

Description

6.3Event: Discussion Regarding

Consumer Preference Choices

Consumer + Primary Receiving Organization

6.3.1Action: Provider has a discussion

with the consumer to provide

assistance with consumer

preference choices


The consumer may have a discussion regarding the choices and

mechanisms available for expressing their preferences for handling

their health-related information. The primary receiving

organization may provide a medical professional or counselor to

discuss these choices which may help the consumer make

appropriate informed decisions.

6.4Event: Identity Verification Consumer + Primary Receiving Organization

6.4.1Action: Consumers identity is

verified by the primary receiving

organization

Prior to interacting with the primary receiving organizations

electronic system, the consumer must be positively identified within

that system. The authentication process takes place within the

providing entity and must be completed before the consumer can

express their preferences.

Existing capabilities exist for this functionality, HITSP TP22: Patient

ID Cross-Referencing as well as the NHIN Patient Discovery

Specification both address establishing the consumer identity.


19/42




Code Event

Action

Perspective

Description

6.5Event: Express Preference Consumer

6.5.1 Action: Consumer decides to

express preferences

The consumer decides, after sufficient education and discussion, to

express their preferences. The consumer expresses their

preferences from the available choices regarding the sharing of

pertinent medical information. The options the consumer has

regarding what information can be restricted and with whom the

information should or should not be shared may be different

depending on the state and the provider organization. There are

multiple technical mechanisms by which the preferences may be

exchanged. These mechanisms are described in the following

alternative actions and correspond to information flows 1a through

1e as depicted in Section 7.0, Information Exchanges. Each of the

following alternatives is dependent on positive identification and

authentication of the consumer or the recipient or legal proxy of a

recipient of healthcare.

6.5.1.1Alternative Action: Consumer

preferences expressed via a PHR

If the consumer has a PHR or other patient-controlled repository,

they may express the preferences directly into the PHR. These

preferences can then be shared from the PHR in various ways which

are described in section 6.5.1.3 and 6.5.1.4. The consumer may

have set these preferences prior to, during or subsequent to an

encounter with a primary receiving organization.


preferences expressed via a

providers EHR

The consumer may express their preferences via a providers EHR

system. This process may be accomplished either by the provider

entering information directly into the system or by the consumer

filling out a paper form. The information on the form is then

transferred to the providers system by a representative from the

providers organization.


preferences exchanged through

direct connection between PHR

and providers EHR

This alternative aligns with activities described in section 6.5.1.1.

Once the preferences have been expressed and stored on the

consumers PHR, the PHR may be connected directly to the

providers EHR system and the preferences previously set may be

exchanged directly between those two systems.


20/42


21/42




Code Event

Action

Perspective

Description

6.7Event: Create Preference Primary Receiving Organization

6.7.1 Action: Primary receiving

organization creates the

preference(s) based on the

instructions from the consumer.

Once the primary receiving organization has received the

preferences as expressed by the consumer, the preferences are

created within their system.

6.8Event: Store Preference Primary Receiving Organization

6.8.1Action: Primary receiving

organization stores the

preferences

The primary receiving organization may retain the preference

profile for later use by storing it in accordance with federal, state

and local internal policies and procedures.

6.9Event: Audit and Reporting of

the Preference and/ or

Associated Information

Primary Receiving Organization

6.9.1Action: Audit reports of the

preference and/or associated

information are generated

Audit reports are generated in the primary receiving organizations

system. These audit reports may be used in the future by the

entity itself, they may be requested by a consumer or may be

utilized by an outside auditing, certifying or accreditation

organization.


22/42


6.3 Scenario2:PreferenceManagementFigure 6.3: Scenario 2: Preference Management: Application, Exchange and Replacem

Consumer Preferences

Sec

ondary

Receiving

Organization

Primary

ReceivingOrganization

Consumer

Share Preference

Stop Flow ofInformation

6.18

6.22

Receipt of thPreference

Request of Audit

6.236.19

Consumer EmpowermentConsumer Access to Clinica

Information Use Case

Scenario 2: Preference Management: Application, Exchange and Replacement

Opt In

Classification

IdentityVerification

6.24

6.21

Apply Preference

6.20

6.11

6.29

6.14

Opt In WithClassification

6.13

Transfer/Transmission ofPreference and/or AssociatedInformation

Audit andReporting of thePreference and/or AssociatedInformation

IdentifyPreference

Replace ExistingPreference

Identify RelevantSecondaryReceiving

Organization(s)

RequestPreference

Action

IdentityVerification

Relay

ReplacementStatus to

AppropriateOrganization(s)

6.15

6.10

6.166.17

OptOut

Revoke

Request toAmend Existing

Preference

6.12

Out of Scope Event

In Scope Event

Legend

Off ice of the Nat ional Coordinator for HealthOctober 5, 2009



23/42




6.4 EventsandActions:Scenario2ManagementandExchangeofPreferencesCode Event

Action

Perspective

Description

6.10Event: Request P reference Action Consumer

6.10.1Action: Consumer requests an update to their

profile

Once a consumer has expressed their preferences

and a profile has been established, the consumer

may wish to amend these preferences or share them

with another organization. The consumer must

submit a request to the primary receiving

organization to begin this process. The process

begins by retrieving the profile from the primaryreceiving organizations electronic system.

6.11Event: Iden tify Primary Receiving Organization

6.11.1Action: Primary receiving organization identifies

the consumer preference

Prior to the application of the consumer preference,

the primary receiving organization identifies the

preferences in their own system and/or retrieves

them from a PHR or other system.

6.12Event: Request to Amend Existing Preference Consumer

6.12.1Action: Consumer makes request to amend their

profile

Once the consumers preference profile has been

identified, they must direct the system to begin the

process of amending the preference profile. If a

replacement is desired, then the process continues

down the alternative path to Event 6.15.

6.12.2Alternative Action: Consumer makes request to

amend their profile

If the consumers request is to amend their

preference profile, the process starts with the

revocation of the preference profile. Once the profile

has been revoked, the process continues down this

alternative path through Event 6.15 through 6.17

then returns back to Event 6.5 in which the

consumer expresses their amended preferences.


24/42




Code Event

Action

Perspective

Description

6.13Event: Apply Preference Primary Receiving Organization

6.13.1 Action: Consumer preferences are applied The consumer preferences must be applied to the

appropriate SHI. The primary receiving organization

must take the preferences and implement them.

This step represents a decision point. Depending on

the wishes of the consumer, the instructions for

medical information may be to opt in, opt out or to

opt in with certain restrictions on the information

based on the classifications and choices offered to

the consumer. HITSP TP20 and TP30 address the

general opt in and opt out situations, but there are

gaps in the standards where specific classifications

of the data are utilized for consumer preferences.

6.13.1.1Alternative Action: Opt in This alternative represents the choice to opt in to

sharing the consumers medical information in its

entirety. In this case the data may be shared with

providers as necessary, including secondary

receiving organizations. No restrictions are put on

the information beyond the standard restrictions

afforded all SHI based on national, state, local or

entity policy depending on the context of care.

HIPAA rules must always apply to this information.

6.13.1.2Alternative Action: Opt out This alternative represents the most restrictive

choice on the part of the consumer, where no data

sharing may take place outside of the primary

receiving organization. However, there may be

provisions at the entity site whereby providers can

utilize a break the glass protocol (i.e. access the

EHR in opposition to the patients preference) if an

emergency warrants the sharing of this information.

However, if a provider breaks the glass it may be

necessary to let the consumer know about this

situation as soon as possible. This issue is

addressed in the 2007 Consumer Empowerment:

Clinical Access to Clinical Information Use Case in

Event/Action: 7.1.4.


25/42




Code Event

Action

Perspective

Description

6.13.1.3Alternative Action: Opt in with classification This alternative represents additional considerations

regarding consumer preferences. If a consumer

chooses this option, they may wish to restrict or

sequester certain parts or data within their EHR. The

specific classification of SHI is discussed in the Data

Set Considerations Section 9.0 of this Document.

6.14Event: Stop Flow of Info rmation Primary Receiving Organization

6.14.1Action: Primary receiving organization stops the

flow of information based on the consumer opting

out

If the consumer decides to Opt Out of

sharing/exchanging their EHR, the primary receiving

organization must not allow for or stop the flow of

this information to exchanges and/or to other

healthcare providers. The EHR will remain with the

primary receiving organization and the record may

be used according to federal, state and local internal

policies and procedures.

6.15Event: Replace Existing Preference Primary Receiving Organization

6.15.1Action: Primary receiving organizations system

replaces the consumers preference profile

Once the consumer has expressed their wishes to

replace or amend the preference profile, the

instructions are given to the primary receiving

organization and the status of the consumers

preference profile is replaced.

6.16Event: Identify Relevant Secondary Receiving

Organization(s)


6.16.1Action: Primary receiving organization identifies

secondary receiving organizations

The primary receiving organization must identify any

and all secondary receiving organizations to which

the consumers preference profile was transmitted.

The audit report may be used to determine all

relevant entities.


26/42




Code Event

Action

Perspective

Description

6.17Event: Relay Replacement Status to

Appropriate Organization(s)


6.17.1Action: Relay the replacement order to all the

appropriate secondary receiving organizations.

The primary receiving organization notifies the

secondary receiving organizations of the inactivation

of the consumer preference profile and of its

replacement.

6.18Event: Classificati on Primary Receiving Organization

6.18.1Action: Consumers health information is classified

prior to data exchange

The Primary receiving organization must be able to

exchange information based upon the classification

specified by the consumers preferences and

recognized standards.

Certain granular pieces of information may be

sequestered or not included in the EHR or in the

information which is exchanged.

6.19Event: Share Prefer ence Primary Receiving Organization

6.19.1Action: Preferences are prepared for sharing with

information exchange or secondary receiving

organization

The primary receiving organizations EHR system

gathers the preferences and relevant associated

medical information and processes this information

into a transmittable packet of data to be exchanged

via an information exchange or other provider.

Secondary receiving organizations may not be

obligated to accept or uphold preferences

established by primary receiving organizations. The

honoring of preferences when sent from one entity

to another is out of scope for this requirements

document.


27/42




Code Event

Action

Perspective

Description

6.20Event: Audit and Reporting of the Preferences

and/ or Associated Information


6.20.1Action: Audit reports of the preference and/or

associated information are generated

Audit reports are generated in the primary receiving

organizations system. They may also be generated

in subsequent systems. These audit reports may be

used in the future by the entity itself, they may be

requested by a consumer or may be utilized by an

outside auditing or accreditation organization.

6.21Event: Identity Verification Primary Receiving Organization

6.21.1

Action: Identity is verified in the primary receiving

organizations system

Prior to transmission of the consumer preferences,

the identity of the consumer, whose data is being

exchanged and the secondary receiving

organization, must be positively verified. This

verification is required to take place prior to

exchange.

Existing capabilities exist for this functionality, HITSP

TP22: Patient ID Cross-Referencing as well as the

NHIN Patient Discovery Specification both address

establishing the consumer identity.

6.22Event: Identity Verification Secondary Receiving Organization

6.22.1Action: Identity is verified in the secondary

receiving organizations system

Prior to completion of the transmission of the

consumer preferences, the identity of the consumer

whose data is being exchanged, and the secondary

receiving organization must be positively verified a

second time; this time the verification takes place

upon receipt by the secondary receiving

organization.

Existing capabilities exist for this functionality, HITSP

TP22: Patient ID Cross-Referencing as well as the

NHIN Patient Discovery Specification both address

establishing the consumer identity.


28/42




Code Event

Action

Perspective

Description

6.23Event: Transfer/ Transmission of P reference



6.23.1Action: The consumer preferences are transmitted

along with associated information

Once events 6.21 and 6.22 have been completed,

the consumer preferences and all pertinent

associated medical information are transmitted from

the primary receiving organization to the secondary

receiving organization. The secondary receiving

organization may be a health information exchange,

a national or regional information network or simply

another provider who requires the electronic health

record of the consumer.

6.24Event: Receipt of the Preference Secondary Receiving Organization

6.24.1Action: The consumer preferences are received by

the secondary receiving organization

The consumer preferences and associated

information is received by the secondary receiving

organizations electronic system. At this time the

information may be integrated into a new or existing

EHR and may then be used by care coordinators or

clinicians working at the secondary receiving

organization.

6.25Event: Acknow ledgment of Receipt and

Reconciliation

Secondary Receiving Organization

6.25.1Action: Acknowledgment of receipt of consumer

preferences

Once the consumer preferences are received at the

secondary receiving organization, an electronic

acknowledgement is transmitted back to the primary

receiving organization and the consumer. This is a

simple acknowledgement of the receipt of the

electronic information by the secondary receiving

organizations system. It is not necessarily an

agreement to abide by the preferences. These

policies are addressed in the Issues and Policy

Implications Section 4.0.


29/42




Code Event

Action

Perspective

Description

6.25.2Action: Reconciliation of consumer preferences

between entities

Note: This action is out of scope.

If the consumer already has expressed their

preferences and some information is already in the

secondary receiving organizations system, there

may be a need to reconcile the multiple sets of

consumer preferences. The receiving system should

have the ability to identify which set of consumer

preferences is the most recent, the source of the

consumer preferences, etc.

The process for the reconciliation of preferences is

out of scope for this requirements document. This

step is mentioned to address the need for this

functionality.

6.26 and

6.20Event: Receipt of Reconciliation Notice Consumer and Primary Receiving Organization

6.26.1Action: The consumer and primary receiving

organization receives a notice of consumer

preference reconciliation.

If reconciliation is necessary (action 6.25.2) and a

notice is sent out by the secondary receiving

organizations system, the consumer and the

primary receiving organization may receive this

notice.

6.27 Event: Store Prefe rence Secondary Receiving Organization

6.27.1Action: Secondary receiving organization stores

the preferences in their data repository

The secondary receiving organization may retain the

consumer preference profile for later use by storing

it in accordance with federal, state and local internal

policies and procedures.

6.28Event: Audit and Reporting of the P reference


Secondary Receiving Organization

6.28.1Action: Audit reports of the preference and/or

associated information are generated

Audit reports are generated in the secondary

receiving organizations system. These audit reports

may be used in the future by the entity itself, they

may be requested by a consumer or may be utilized

by an outside auditing, certifying or accreditation

organization.


30/42




Code Event

Action

Perspective

Description

6.29Event: Reques t of Audit Consumer

6.29.1 Action: Consumer requests an audit of their

expressed consumer preferences


The consumer may request an audit of their

consumer preferences. This request may be for the

primary, secondary or other receiving organizations

or providers that are storing the consumers

preferences. This issue has been addressed in the

2007 Consumer Empowerment: Consumer Access to

Clinic Information Use Case in Event/Action 7.1.4.

The process involved with a consumer requesting an

audit has been deemed out of scope for this

Consumer Preferences Requirements Document.


31/42


7.0 InformationExchangesInformation exchanges depict the focused information exchanges that standards

development organizations should address.

Figure 7.0 Information Exchange for Consumer P references

6.5, 6.12

Express orRevokePreference

6.6, 6.7, 6.24

Receipt ofPreference

6.23Transfer/

Transmission ofPreference and/or

AssociatedInformation

6.25Acknowledgement

of Receipt andReconciliation

HIEIntermediary

orPoint to Point

EHR

PHR

Healthcare Entities

Social Agencies

Other Providers

Consumer ProviderInformation Sources and

RecipientsInformation Exchange

4

3

1b

1e

1c

1d

3

4

1d

6.25Acknowledgement

of Receipt andReconciliation

2a

1a

6.20, 6.28Audit and

Reporting of thePreference and/or

AssociatedInformation

556.29

Request of Audit6

6.26Receipt of

ReconciliationNotice

2b

Off ice of the Nat ional Coordinator for HealthOctober 5, 2009 31



32/42




7.1 LegendThe Information Exchange Diagram extracts the events from the Process Diagram where

consumer preference information is actually exchanged between entities in order to

illustrate the flow of a consumers preference more clearly. The exchanges of information

are explained below.

Figure 7.1 Information Exchange Legend

Information Exchange

1a The request to initially express, replace or amend a consumer preference is

completed via a PHR.

1b The request to initially express, replace or amend a consumer preference is

completed via a providers EHR.

1cThe initial, replaced or amended consumer preference is shared with theclinician through a direct connection between the providers EHR and the

consumers PHR.

1d The initial, replaced or amended consumer preference is exchange with the

provider via an information exchange.

1e The initial, replaced or amended consumer preference may be shared via a

health information exchange using publish/subscribe, push or query/retrieve

methods of exchange.

2a Provider exchanges with and reconciles the consumer preferences in theirsystem against the consumer preferences in the information exchange. Potential

conflicts of existing consumer preferences are resolved.

2b The consumer is notified if their preference was reconciled.

3 Provider communicates information as appropriate via the information exchange.

4 Provider receives acknowledgement of receipt or publication of consumer

preference via an information exchange, regardless of sending method

(publish/subscribe, push or query/retrieve).

5 Provider creates/updates and exchanges or transmits an audit log regarding

consumers preference.

6 The consumer requests and receives a copy of the audit log for their preference.


33/42




8.0 FunctionalNeedsThe Functional Needs Section describes the combination of end-user needs and system

behaviors that support interoperability and information exchange.

8.1 UniversalFunctionalNeeds1. Identity Verification (Events 6.4, 6.21, 6.22)

a. The ability to positively identify the consumer is required by:

i. The primary receiving organization: to verify that they are creating,

retrieving or transmitting the preference and/or the associated

information for the correct consumer

ii. The secondary receiving organization: to verify that they have

received the consumer preferences and/or the associated information

for the correct consumer

b. The ability to positively identify the primary receiving organization is required

by:

i. The secondary receiving organization: to ensure they are receiving a

preference from the correct organization

ii. The consumer: to verify that they are expressing or transmitting a

preference to the correct organization

c. The ability to positively identify the secondary receiving organization is

required by:

i. The primary receiving organization: to ensure the preference is

transmitted to the correct organization

ii. The consumer: to verify that their preference was transmitted to the

correct organization

8.2 ConsumerFunctionalNeeds1. Express Preference (Event 6.5)

a. The ability for the consumer to express preference choices to a primary

receiving organization and have that preference applied and exchanged

appropriately.

2. Amend Preference (Event 6.10)

a. The ability for the consumer to amend a preference already in existence at a

primary receiving organization. There needs to be the technical ability tonotify all secondary receiving organizations of the amended consumer

preferences.

3. Replace Preference (Event 6.10, 6.12)

a. The ability for the consumer to inactivate and replace a preference at a

primary receiving organization. There needs to be the technical ability to


34/42




notify all secondary receiving organizations of the inactivation and

replacement of consumer preferences.

4. Request Exchange (Event 6.10)

a. The ability for the consumer to request the exchange of preference from oneorganization to another.

5. Request Audit (Event 6.29)

a. The ability for the consumer to request an electronic copy of their

preferences audit log at a primary receiving organization.

8.3 Primary/SecondaryReceivingOrganizationFunctionalNeeds1. Create Preference (Event 6.7)

a. The ability for any organization to receive a consumers expression of their

preferences and create an electronic consumer preference profile.

2. Transmit Preference (Event 6.23)a. The ability for all organizations to electronically send and receive a consumer

preference and/or associated information or an update to a preference withanother organization in a secure manner upon request.

3. View Preference (Event 6.24)

a. The ability for any organization to view the consumer preference and/or

associated information of a positively identified consumer.

4. Store Preference (Event 6.8, 6.27)a. The ability for any organization to electronically store the consumer

preference and/or associated information in a secure manner.

5. Apply Preference (Event 6.13)

The ability to technically enforce any policy related restrictions that are

imposed at the federal, state or local level.

6. Amend Preference (Event 6.13)

a. The ability for the primary receiving organization to identify and amend a

consumer preference (at the consumers request) and electronically exchangethat update to any secondary receiving organization that received the original

consumer preference.

7. Replace Preference (Event 6.15)a. The ability for a primary receiving organization to inactivate and replace a

consumer preference or consumer preference profile (at the consumersrequest) and electronically communicate the replacement to any secondary

receiving organization that received the original preference.


35/42




8. Transmit an Update of a Preference (Event 6.23)a. The ability for any organization that receives a consumer preference update

notice to enact those changes and relay that notice to any other organizationsthat they transmitted the consumer preference to.

9. Reconciliation of Conflicting Preferences (Event 6.25)a. The ability for all organizations to reconcile a consumer preference with any

other consumer preferences that the consumer may have expressed and theability to electronically communicate the reconciliation to the consumer.

10.Acknow ledge Receipt of Preference or Update (Event 6.25)The ability for any organization to electronically acknowledge the receipt of an

original, replaced or amended consumer preference.

11.Maintain an Audit Log of the Preference (Event 6.9, 6.28)

a. The ability for any organization to create and update an audit history

(including modifications, transmissions, views, etc.) of the consumer

preference profile and produce the audit log upon request.

12.Classify Data (Event 6.18)a. The ability of the primary receiving organization to segment information in

alignment with the classifications of information contained in consumerpreferences.


36/42




9.0 DataSetConsiderationsIt is important to note that consumers, at the highest level, require the capability to opt in

or opt out of the exchange of their health information. Consumers may also request thatonly certain classes of information be shared. These classes of information and preferences

could be classified at varying levels of granularity. Defining the needed levels of granularity

is not focus of this Consumer Preferences Requirements Document.

This Data Set Considerations Section provides a comprehensive (not exhaustive) list of

classes of consumer preferences that should be considered in identifying, harmonizing and

developing standards. This section is only intended to be a guide for the development of

standards, however, it does not preclude, the use of existing standards approved by

standards development bodies such as HITSP.

They include:

9.1 IdentityandPreferenceVerification1. Consumer Information - addressed in 2006-2009 AHIC Use Cases

2. Primary/Secondary Receiving Organization Information

a. Provider Information

b. EHR information

c. HIE information

d. PHR information

3. Consumer Preference Information

a. Consumer preference identification information

b. Consumer preference audit information

i. Date and locations where the consumer preference was created,received, applied, stored, shared, transmitted, amended or replaced

9.2 DataClassificationPossible types of consumer preferences classifications

1. Access Restriction & Management

a. Consent & Disclosure of Information Sequestering or disclosing protected

health and/or sensitive health information, categories may include:

i. HIV/AIDS

1. Status or diagnosis

2. Medications

3. Treatment

4. Test results, etc

ii. Mental Health

1. Medications

2. Psychotherapy notes

3. Counseling or treatment

4. General information, etc.


37/42




iii. Substance Abuse

1. Status

2. Treatment

3. Referrals, etc.

iv. Sickle Cell Anemia

1. Status

2. Test results

3. Genetic testing, etc.

v. Genetic Information

1. Newborn screening

2. Genetic testing

3. Personal genetic/genomic data

4. Family genetic/genomic information, etc

vi. Sexually Transmitted Diseases (STDs)

vii. Communicable or venereal disease

viii. Developmental diabetes

b. Role & Criteria Based Access

i. Organization

1. Primary/Secondary Receiving Organization Information (Section

9.1.2, a-d)

ii. Role

1. Provider personal identification information

2. Provider role or specialty

iii. Encounter Based Access & Authorization

1. Provider practice location (facility)

2. Hospital admission and discharge

3. Long term care admission and discharge4. Ambulatory care encounter

5. Outpatient visit encounter

6. Appointment Slots:

a. Date

b. Time

c. Duration

d. Appointment Type

e. Provider

f. Location

g. Resources, etc

iv. Embargoed Records1. VIP

2. Legal protections, etc

v. Time Limited Access

1. Start Date

2. End Date

3. Duration


38/42




2. Content preference Preference surrounding delivering care or associated services

a. Status and/or designation

i. Advanced directives

ii. Do not resuscitate (DNR) order

iii. Healthcare proxies

iv. Living wills

v. Medical surrogates

vi. Access to family members, etc.

b. Care or associated service needs Communication needs

i. Appointment reminders

ii. Lab results, etc.

c. Comfort Needs

i. Non medical dietary restrictions

ii. Language needs

iii. Cultural needs

iv. Clergy preference, etc.

3. Components of Access Restrictions/Management and Content Preferences

i. Level/Status of Participation

1. Opt In or Opt Out

2. With or without additional classifications

3. With or without additional granularity

ii. Consent Information

1. Requestor & disclosure types

2. Requestor & disclosure locations

3. Type/purpose of use

4. Elements of consent5. Sensitive health flags or information

a. Clinical Scenarios

b. Clinical data types/classifications

i. Labs

ii. Meds

iii. Diagnosis, etc.


39/42


40/42




Health Information Exchange: A multi-stakeholder entity which may be a free-standing

organization (e.g., hospital, healthcare system, partnership organization) that supports

health information exchange and enables the movement of health-related data within state,

local, territorial, tribal or jurisdictional participant groups. Activities supporting health

information exchanges may also include integrated delivery networks, health record banksand others.

Health-Related Information (HRI): For the purposes of this document, health-related

information refers to a superset of all of a consumers data that is associated with

healthcare delivery. This may include health information as well as demographic, insurance

and financial information.

Healthcare Information Technology Standards Panel (HI TSP): A cooperative

partnership between the public and private sectors. The Panel was formed for the purpose

of harmonizing and integrating standards that will meet clinical and business needs for

sharing information among organizations and systems.

Health Record Banks: Entities/mechanisms for holding an individuals lifetime health

records. This information may be personally controlled and may reside in various settings

such as hospitals, doctors offices, clinics, etc.

Healthcare Entities: Organizations that are engaged in or support the delivery of

healthcare. These organizations could include hospitals, ambulatory clinics, long-term care

facilities, community-based healthcare organizations, employers/occupational health

programs, school health programs, dental clinics, psychology clinics, care delivery

organizations, pharmacies, home health agencies, hospice care providers, pharmacies and

other healthcare facilities.

Healthcare Payors: Insurers, including health plans, self-insured employer plans and third

party administrators, providing healthcare benefits to enrolled members and reimbursing

provider organizations.

HIT Vendors and Providers: Organizations that develop and provide health information

technology solutions. These solutions may include personal health records, applications,

data repositories, and web services.

Individually identifiable health information (I IHI ): According to the Health Insurance

Portability and Accountability Act (HIPAA), IIHI is information that is a subset of health

information, including demographic information collected from an individual, and: (1) Is

created or received by a healthcare provider, health plan, employer or healthcare

clearinghouse; and (2) Relates to the past, present or future physical or mental health or

condition of an individual; the provision of healthcare to an individual; or the past, present

or future payment for the provision of healthcare to an individual; and (i) That identifies the

individual; or (ii) With respect to which there is a reasonable basis to believe the

information can be used to identify the individual.
http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Acthttp://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Acthttp://en.wikipedia.org/wiki/HIPAAhttp://en.wikipedia.org/wiki/HIPAAhttp://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Acthttp://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act


41/42




Laboratories: A laboratory (often abbreviated lab) is a setting where specimens are sent

for testing and analysis are resulted and then results are communicated back to the

requestor. The types of laboratories may include clinical/medical, environmental,

veterinarian and may be both private and/or public.

Medical Home: A model for providing care that is accessible, comprehensive and

coordinated and delivered in the context of family and community. A patients medical

home includes a clinician, referred to as the medical home provider, who is the central point

of planning, coordination and management of the patients health promotion, acute illness

care and chronic condition management.

Patients: Members of the public who receive healthcare services.

Personal Health Record System Suppliers: Organizations which provide specific PHR

solutions to clinicians and patients such as software applications and software services.

These suppliers may include developers, providers, resellers, operators and others who may

provide these or similar capabilities.

Protected Health I nformation (PHI ): According to HIPAA, PHI is any information about

health status, provision of healthcare or payment for healthcare that can be linked to an

individual.

Providers: The healthcare clinicians within healthcare delivery organizations with direct

patient interaction in the delivery of care, including physicians, nurses and other clinicians.

This can also refer to healthcare delivery organizations.

Public Health Agencies/ Organizations: Federal, state, local, territorial and tribal

government organizations and clinical care personnel that exist to help protect and improve

the health of their respective constituents.

Research Entities: Organizations that are engaged in or support healthcare research

including entities performing research, clinical trials or other research activities (e.g.,

National Institutes of Health, academic centers).

Sensitive Health Information (SHI): For the purposes of this document, SHI is

personally identifiable health information that is deemed by the individual (or their

designee) as requiring protections and particular care in its handling or dissemination that is

greater than the protections afforded other personally identifiable health information. What

information an individual considers to be sensitive is not necessarily the same set of

information that another individual considers sensitive, nor is it necessarily the same as the

information designated under HIPAA to be Protected Health Information (PHI).

Specialty Networks: Networks that are accessed directly by the PHR to feed information

into the PHR. These information providers may interface directly with participating entities:

i.e. healthcare entities, ancillary entities, laboratory, etc.
http://en.wikipedia.org/wiki/HIPAAhttp://en.wikipedia.org/wiki/HIPAA


42/42


Standards Development Organizations (SDO): Any entity whose primary activities are

developing, coordinating, promulgating, revising, amending, reissuing, interpreting or

otherwise maintaining standards that address the interests of a wide base of users outside

the standards development organization. HITSP is an example of an SDO.

Transmission: For the purposes of this document, transmission refers to uni-directional

communication.
http://en.wikipedia.org/wiki/Standardhttp://en.wikipedia.org/wiki/Standard

20091005 consumer preferences draft requirements document

Documents