Hipaa compliance privacy officer snopes

IFSM - Healthcare Systems

I need three ethical, legal, regulatory topics on information systems, especially on the health care industry. The assignment must one page for each topic. I have attached the class materials, which must be incorporated into the paper. APA citations. Please see the assignment questions below and the referenced list.

Review the list of 20 ethical, legal and regulatory topics in the Stage 3 assignment. Select one (preferably different from others previously chosen, but this is not required) and:

Put the topic in the Subject line of your posting
Discuss an event in your life that relates to that topic
What it meant to you
What suggestions you have for improving the outcome or ensuring that others benefit if it was a positive outcome.
1 Safe Design Week 2: "Principles of Quality and Safety for HIT," lecture b

2 Meaningful Use Week 2: "Introduction to Quality Improvement and HIT," lecture a

3 Quality Improvement Week 2: "Introduction to Quality Improvement and HIT," lecture b

4 Data Accuracy Week 3: "Data Quality Improvement" lecture a

5 Data Accessibility Week 3: "Data Quality Improvement" lecture a

6 Data Comprehensiveness Week 3: "Data Quality Improvement" lecture a

7 Data Consistency Week 3: "Data Quality Improvement" lecture b

8 Privacy Week 4: "Privacy, Confidentiality & Security," lecture a

Week 4: "Security," lecture c

9 Confidentiality Week 4: "Privacy, Confidentiality & Security," lecture a

Week 4: "Security," lecture c

10 Security Week 4: "Privacy, Confidentiality & Security," lecture a

11 Individually Identifiable Health Information Week 4: "Privacy, Confidentiality & Security," lecture a

12 Protected Health Information Week 4: "Privacy, Confidentiality & Security," lecture c

13 HIPAA Privacy Rule Week 4: "Privacy, Confidentiality & Security," lecture c

Week 4: " System Security Procedures and Standards," lecture a

14 HIPAA Security Rule Week 4: "Privacy, Confidentiality & Security," lectures c and d

Week 4: " System Security Procedures and Standards," lecture a

15 Business Associate Contracts Week 4: "Privacy, Confidentiality & Security," lectures c and d

16 Authentication Week 4: "Security," lecture a

17 Authorization Week 4: "Security," lecture a

18 Encryption Week 4: "Security," lecture b

19 Technical Safeguards Week 4: " System Security Procedures and Standards," lecture b

20 Healthcare Ethical Principles Week 4: "Ethics and Professionalism," lecture a

Content

Week 4, Monday, November 11, 2019 - Sunday, November 17, 2019

IFSM 305 7980 Information Systems in Health Care …

The following should be completed in Week 4:

Read:

Read/View all Week 4 Content

Do:

Participate in Discussion(s), as assigned

Submit the Case Study Stage 2 Assignment

0 % 0 of 3 topics complete

The second of two weeks on data, this week you will learn more about how data

is used to support decision making in health care organizations and how data is

protected. Health care data is by definition personal and private, so we will also

address issues of ethics and professionalism surrounding data and how health

information can be protected.

The following table lists the Week 4 outcomes, mapped to the corresponding

course outcome. The course outcome gives you "the big picture," and the weekly

outcomes provide more detailed information that will help you achieve the

course outcome.

Course Outcome Met in Week 4 Week 4 Outcomes

Analyze the flow of data and explain how clinical decision support

javascript:void(0);
https://learn.umuc.edu/d2l/home/418648
Activities

Week 4 Learning Resources Link

Discussion for Week 4 Discussion Topic

Case Study Stage 2 Assignment Assignment

Due November 17 at 11:59 PM

information among disparate

health information systems

to support internal and

external business processes

systems support health care quality

improvement

describe the privacy, confidentiality, an

security issues with health care data

describe methods for protecting health

care data

explain the ethical issues in health

informatics

javascript:void(0);
https://learn.umuc.edu/d2l/le/content/418648/viewContent/16194554/View
https://learn.umuc.edu/d2l/le/content/418648/viewContent/16194543/View
https://learn.umuc.edu/d2l/le/content/418648/viewContent/16194549/View
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. © Johns Hopkins University. UMUC has modified this work and it is available under the original license.

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
Welcome to Health Management Information Systems, Clinical Decision Support Systems. This is Lecture a.

The component, Health Management Information Systems, is a “theory” component that provides an introduction to health care

applications and the systems that use them, health information technology standards, health-related data structures, and enterprise

architecture in health care organizations.

Lecture a will offer a definition of clinical decision support, provide some historical context surrounding clinical decision support,

describe the requirements of a clinical decision support system, and discuss the relationship of clinical practice guidelines and

evidence-based practice to clinical decision support systems.

1

The objectives for this unit, Clinical Decision Support Systems are to:

• Describe the history and evolution of clinical decision support;

• Describe the fundamental requirements of effective clinical decision support systems;

• Discuss how clinical practice guidelines and evidence-based practice affect clinical decision support systems;

2

Additional objectives for this unit, Clinical Decision Support Systems are to:

• Identify the challenges and barriers to building and using clinical decision support systems;

• Discuss legal and regulatory considerations related to the distribution of clinical decision support systems;

• and Describe current initiatives that will impact the future and effectiveness of clinical decision support systems.

3

Osheroff, Pifer, & Teich (as cited in Das & Eichner, 2010) stated “CDS provides clinicians, patients, or caregivers with clinical

knowledge and patient-specific information to help them make decisions that enhance patient care” (Das & Eichner, 2010, p. 4).

Das & Eichner (2010) go on to explain “The patient’s information is matched to a clinical knowledge base, and patient-specific

assessments or recommendations are then communicated effectively at appropriate times during patient care” (p. 4).

Musen, Shahar, and Shortliffe (2006) define a clinical decision support system as “any computer program designed to help

healthcare professionals to make clinical decisions” (p. 700).

Bottom line, when one hears CDS or CDSS, think of computer-assisted clinical decision-making.

4

Computer-assisted clinical decision-making has been considered viable since the late 1950s when initial publications appeared.

Then in the late 1960s, the Leeds Abdominal Pain System was created at the University of Leeds. The Leeds Abdominal Pain

System was built based on “computer-based decision aids using Bayesian probability theory” (Musen, Shahar, & Shortliffe, 2006,

p. 702).

While it is not possible to explain the theory in depth in this short course, it is important to know the theorem is based on rules of

predictive probability. A clinical decision support system may use Bayesian logic in its inference engine.

5

Other systems considered to be key in the evolution of clinical decision support systems are MYCIN and HELP, both of which used

rule-based approaches.

According to HIMSS, a rule is “A formal way of specifying a recommendation, directive, or strategy, expressed as ‘IF premise

THEN conclusion’ or ‘IF condition THEN action’” (HIMSS Dictionary, 2010, p. 105).

MYCIN, which uses a rules-based methodology, is described by Musen, Shahar, & Shortliffe as “…an early exploration of methods

for capturing and applying ill-structured expert knowledge to solve important medical problems” (p. 705).

HELP, an integrated clinical information system, has decision rules called “HELP sectors” encoded into it (Musen, Shahar, &

Shortliffe, 2006, p. 705). Kuperman, Gardner, & Pryor, (as cited in Musen, Shahar, & Shortliffe, 2006) stated, “HELP has the ability

to generate alerts when abnormalities in the patient record are noted, and its impact on the development of the field has been

immense, with applications and methodologies that span nearly the full range of activities in biomedical informatics” (p. 705).

In addition to Bayesian logic and rule-based approaches, the current clinical decision support systems may use other reasoning

methodologies such as neural networks or combinations of several methods.

6

Two Healthcare Information Technology Standards Panel (HITSP) groups convened a meeting with experts in the area of clinical

decision support systems and one outcome was the image shown on this slide. As explained by Boone (2006) in his blog,

clinical decision support was “…viewed as a black box, through which we have three different kinds of inputs, and several different

types of outputs… The three different inputs include:

1. Algorithms, or knowledge about how to make inferences or assertions based on existing instance or world knowledge.

2. Instance data describing the specific case that is being addressed by the clinical decision support application.

3. Ontological or "world knowledge", representing facts about the world, such as what drugs interact badly, or how body parts are

related, or the relationships between genes and diseases” (para. 13).

The output of information, actions, and alerts is characterized by symbols shown coming from the black box representing clinical

decision support.

This image of a model is representative of the components of clinical decision support.

7

As the previous slide showed, a model of a clinical decision support involves certain inputs in order to arrive at an output. Berner

(2009) explains the system requirements in the following way: “Common features of CDS systems that are designed to provide

patient-specific guidance include the knowledge base (e.g., compiled clinical information on diagnoses, drug interactions, and

guidelines), a program for combining that knowledge with patient-specific information, and a communication mechanism—in other

words, a way of entering patient data (or importing it from the EMR) into the CDS application and providing relevant information

(e.g., lists of possible diagnoses, drug interaction alerts, or preventive care reminders) back to the clinician” (p. 5).

Each component provides a piece that is important for clinical decision support interventions to occur. For example, clinical

decision support could provide suggestions for possible diagnoses (knowledge base) that match a patient’s signs and symptoms

(inference engine) and communicate this to the provider through a ranked list of diagnoses that might explain the patient’s signs

and symptoms (communication mechanism).

8

The first system requirement is the knowledge base. A knowledge base is just what you would expect it to be, that is an automated

representation of clinical knowledge.

Osheroff et al. (2006) defined clinical knowledge as “A generally applicable fact (or set of facts), best practice, guideline, logical

rule, piece of reference information (such as a text article), or other element of information that is important to know for optimal data

interpretation and decision-making regarding individual and population health and health care delivery” (p. 59).

The knowledge base is a collection of clinical information on such things as diagnoses, drug interactions, and evidence-based

guidelines. Content for the knowledge base comes from internal as well as external sources such as specialty societies,

commercial knowledge vendors, and health care organizations. Because of amount of time and expertise it takes to create content,

healthcare providers usually depend on developers of clinical information systems for the knowledge base who often will obtain

and incorporate commercial knowledge bases into their CDS products. For example, a number of drug knowledge bases are

available in the marketplace.

9

The second system requirement is the inference engine. In a clinical decision support system, the inference engine combines the

knowledge base with the patient’s data. According to Spooner (2007), “The inference engine is the portion of the CDSS that

combines the input and other data according to some logical scheme for output…One such scheme for an inference engine is the

Bayesian network… A Bayesian network is a way to put Bayes’ rule to work by laying out graphically which events influence the

likelihood of occurrence of other events” (p. 37).

As mentioned previously, in addition to Bayesian logic, clinical decision support systems may use other reasoning methodologies

such as rule-based approaches.

10

The final system requirement is the communication mechanism. Berner (2009) describes this component as a mechanism for

entering patient data into the CDS application and providing relevant information back to the clinician.

One method for input would be importing it from the electronic medical record. Some examples of information that might be output

are lists of possible diagnoses, drug-allergy alerts, duplicate testing reminder, drug interaction alerts, drug formulary guidelines, or

preventive care reminders.

One of the five rights in the CDS Five Rights model is communication occurs to the right person, that is consideration of all

members of the care team, such as the clinician, patient, parent or caregiver, nurse (Sirajuddin et al., 2009, p. 40).

11

Given the components of a CDSS, what are some expectations of its use? Berner (2009) provided examples shown in Table 5.1 of

CDS interventions by target area of care.

The first row in Table 5.1 states the target area of care as preventive care with intervention examples of immunization, screening,

and disease management guidelines for secondary prevention.

The second row lists diagnosis as the target area of care, where clinical decision support could provide suggestions for possible

diagnoses that match a patient’s signs and symptoms.

The third row on the list is the target area planning or implementing treatment. CDS intervention could entail the display treatment

guidelines for specific diagnoses, drug dosage recommendations, or alerts for drug-to-drug interactions.

The fourth row, follow-up management, is the target area of care for clinical decision support an intervention might involve

information about corollary orders or reminders for drug adverse event monitoring.

The fifth row states the target area of care as hospital or provider efficiency with care plans to minimize length of stay or the

presentation of order sets as examples of CDS intervention.

12

The sixth and final row is the target area cost reductions and improved patient convenience. Examples of CDS interventions include

duplicate testing alerts and drug formulary guidelines.

Thus, CDS interventions can assist health care providers at different stages in the care process, that is, from preventive care through

diagnosis and treatment, all the way to monitoring and follow-up.

12

Osheroff et al. (2006) describes CDS interventions as “…alerts, reminders, and order sets, as well as other techniques for

knowledge delivery including reference information and education (delivered with or without context sensitivity), health/clinical

protocol and workflow orchestration support, display of context-relevant data, topic-oriented documentation forms, and others” (p.

59).

Intervention types and examples as summarized by Osheroff (2009) are shown in table 5.2.

While typically several elements from these types are combined in the clinical decision support intervention, each of these

intervention types will be examined independently in the next several slides. Drawing from Osheroff, Pifer, Teich, Sittig, & Jenders,

(2005) AHRA provides an example of a combination of elements as “an order set might highlight—through a non-interruptive

alert—an essential intervention that should routinely be ordered and provide an infobutton link to more detailed reference

information that supports the clinical recommendation” (AHRQ, n.d., para 2).

13

Each major CDS intervention type results in certain benefits and can be further broken down into subtypes. The benefits of the

documentation forms/templates intervention include the ability to “provide complete documentation for care quality/continuity,

reimbursement, legal requirements; reduce omission errors by displaying items for selection; reduce commission errors by

ensuring critical data—such as allergies—are captured; provide coded data for other data-driven CDS; provide prompts to acquire

specific information in the format desired” (Osheroff et al., 2005).

Subtypes along with examples as summarized by Osheroff et al. (2005) are shown in table 5.3.

Row one lists the subtype of patient self-assessment forms with the example of a pre-visit questionnaire that outlines health

problems and current medications.

The second row identifies the subtype of clinician patient assessment forms and an inpatient assessment as its example.

Clinician encounter documentation forms is the third subtype and a structured history and physician examination template is an

example.

The fourth row refers to departmental/multidisciplinary clinical documentation forms as a subtype and emergency department

14

document as an example.

The fifth and final row lists data flowsheets as a subtype and the example of a health maintenance/disease management form.

14

The relevant data presentation intervention has several benefits. They include the ability to “optimize decision making by ensuring

all pertinent data are considered and to organize complex data collections to promote understanding of overall clinical picture and

to highlight needed actions” (Osheroff et al., 2005).

Subtypes and examples for this intervention as summarized by Osheroff et al. (2005) are shown in table 5.4.

Row one lists the subtype of relevant data for ordering, administration, or documentation with the example of a longitudinal display

of key patient information to highlight trends and issues requiring attention.

The second row identifies the subtype of retrospective/aggregate reporting or filtering and adverse drug event tracking as its

example.

Environmental parameter reporting is the third subtype and recent hospital antibiotic sensitivities is an example.

The fourth row refers to choice lists as a subtype and suggested dose choice lists, possibly modified as needed for patient’s kidney

or liver function and age as an example.

15

The fifth and final row lists practice status display as a subtype and the example of ED tracking display.

15

The benefit to order/prescription creation facilitators include “promote adherence to standards of care by making the right thing the

easiest to do” (Osheroff et al., 2005).

The subtypes and examples for the order/prescription creation intervention as summarized by Osheroff et al. (2005) are shown in

table 5.5.

Row one lists the subtype of single-order completers including consequent orders with the example of suggested drug and/or dose

choice lists integrated into ordering function—possibly modified by patient’s kidney or liver function and age.

Order sets is the third subtype and general order sets such as an order set for hospital admission or problem-oriented ambulatory

visit is an example.

The third and final row identifies tools for complex ordering as a subtype and the example of guided dose algorithms based on

weight, body surface area (BSA), kidney function, etc.

16

The next intervention is protocol/pathway support. The benefit of this intervention is that it “Provides support for multistep care

plans, pathways, and protocols that extend over time” (Osheroff et al., 2005).

As summarized by Osheroff et al. (2005), table 5.6 identifies two subtypes and examples for the protocol/pathway support

intervention.

Row one lists the subtype of stepwise processing of multi-step protocol or guideline with the example of tools for monitoring and

supporting inpatient clinical pathways (for example, for pneumonia admissions) and multiday/multi-cycle chemotherapy protocols in

the inpatient or outpatient setting.

Support for managing clinical problems over long periods and many encounters is the second subtype and computer-assisted

management algorithm for treating hyperlipidemia over many outpatient visits is an example.

17

"Address recognized information needs of patients and clinicians" (Osheroff et al., 2005) is a benefit of the CDS intervention type,

reference information and guidance.

The subtypes and examples as summarized by Osheroff et al. (2005) are shown in table 5.7.

Row one lists the subtype of context-insensitive with the example of a general link from EMR or clinical portal to a reference

program (at table of contents or general-search level).

The second row identifies the subtype of context-sensitive and link within patient-messaging application to relevant patient drug

information leaflets as its example.

18

The final intervention is alerts and reminders. The benefits to this intervention include “provide immediate notification of errors and

hazards related to new data or orders entered by clinical information system (CIS) user or the CIS itself (such as when abnormal

lab result is posted) or passage of a time interval during which a critical event should occur; help enforce standards of care.

Effectiveness requires careful attention to workflow, high value of information to end user, and other factors” (Osheroff et al., 2005).

The subtypes and examples for the alerts and reminders intervention as summarized by Osheroff et al. (2005) are shown in table

5.8.

The first row refers to alerts to prevent potential omission/commission errors or hazards as a subtype and drug interaction alert, for

example, with drugs, pregnancy, laboratory, food as an example.

Row two lists the subtype alerts to foster best care and the example disease management such as an alert for needed therapeutic

intervention based on guidelines/evidence and patient-specific factors.

19

This image is an example of the subtype alerts to prevent potential omission/commission errors or hazards. The screen shot

depicts an example of a CDS drug warning alert. The warning indicates the patient is currently on another drug and to avoid use

due to a patient’s possible allergy to cephalosporins. The user has different options to consider, including canceling or continuing

with the order thereby overriding the alert.

20

As mentioned previously, requirements for clinical decision support include the knowledge base, inference engine, and the

communication mechanism. Each component provides a piece that is essential for clinical decision support interventions to occur.

Since clinical decisions are made based on the intervention, then the accuracy and reliability of the knowledge base is vitally

important.

Clinical best practices and evidence-based medicine are important to the trustworthiness of the knowledge base or its rules and

associations of compiled data. Osheroff et al. (2006) explain CDS has the capability of having the scientific evidence and clinical

best practices be more available and helpful and “in so doing adds substantially to the value of health information technology such

as EHRs and CPOE …It is only through CDS that EHRs and CPOE can achieve their full potential for improving the safety, quality

and cost-effectiveness of care” (p.22).

21

Clinical practice guidelines are a foundational part of the knowledge base. The Quality Assurance Project (QAP), funded by the

U.S. Agency for International Development, includes a glossary of useful terms. According to Marquez (2001) “Practice guidelines

consist of systematically developed statements, usually based on scientific evidence and expert consensus, to assist practitioner

decision making about appropriate care for a specific clinical situation” (p. 5).

A similar definition from the National Library of Medicine (NLM) defines a clinical practice guideline as “Work consisting of a set of

directions or principles to assist the health care practitioner with patient care decisions about appropriate diagnostic, therapeutic, or

other clinical procedures for specific clinical circumstances. Practice guidelines may be developed by government agencies at any

level, institutions, organizations such as professional societies or governing boards, or by the convening of expert panels. They can

provide a foundation for assessing and evaluating the quality and effectiveness of health care in terms of measuring improved

health, reduction of variation in services or procedures performed, and reduction of variation in outcomes of health care delivered”

(NLM, 2012).

Clinical practice guidelines are central to determining the care plan for a patient and are considered to be the preferred process for

care.

22

As the previous slide noted, there a number of places where clinical practice guidelines can be located. For example, government

agencies, institutions, professional societies, or expert panels may generate them.

Clinical practice guidelines “…can provide a foundation for assessing and evaluating the quality and effectiveness of health care in

terms of measuring improved health, reduction of variation in services or procedures performed, and reduction of variation in

outcomes of health care delivered. Clinical or practice guidelines usually cite references from a research study whose findings

were used to support the recommendations as noted in the guideline” (Becker Medical Library, 2010, para. 2, 3)

23

The National Guideline Clearinghouse (NGC), a program of the Agency for Healthcare Research and Quality (AHRQ), was formed

as a partnership with the American Medical Association and the American Association of Health Plans (now America's Health

Insurance Plans [AHIP]). The NGH is a public resource for evidence-based clinical practice guidelines.

The image shown is a screen shot taken from AHRQ’s National Guideline Clearinghouse. It shows a portion of the clinical practice

guideline for using nontraditional risk factors in coronary heart disease risk assessment. The source of this guideline is the U.S.

Preventive Services Task Force, a federally-appointed panel of independent experts. It is an example of a source for clinical

practice guidelines from a government agency.

24

Clinical practice guidelines which are based on evidence present the strongest case for accuracy and reliability. The National

Library of Medicine (NLM) defines evidence-based practice as “A way of providing health care that is guided by a thoughtful

integration of the best available scientific knowledge with clinical expertise. This approach allows the practitioner to critically assess

research data, clinical guidelines, and other information resources in order to correctly identify the clinical problem, apply the most

high-quality intervention, and re-evaluate the outcome for future improvement” (NLM, 2012).

The practice of evidence-based medicine is supported through the provision of clinical decision support systems. As Berner (2009)

emphasized, “…the quality of the information and the evidence underlying it are the major determinants of the impact of clinical

decision support on patient safety and quality improvement” (p. 7).

The accuracy and reliability of the knowledge base is vitally important since clinical decisions are being made based on the

intervention. Clinical best practices and evidence-based medicine are essential to the trustworthiness of the knowledge base.

Through the provision of clinical decision support systems the practice of evidence-based medicine is supported.

While guidelines exist, the reality is the availability and utility of useful guideline representations and user interface issues continue

as challenges in CDS deployment.

25

This concludes Lecture a of Clinical Decision Support Systems. This lecture defined clinical decision support, described system

requirements, and explained the effects of clinical practice guidelines and evidence-based practice on CDSS.

26

No audio.

27

No audio.

28

No audio.

29

No audio.

30

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. © Johns Hopkins University. UMUC has modified this work and it is available under the original license.

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
Welcome to Health Management Information Systems, Clinical Decision Support Systems.

This is Lecture b.

The component, Health Management Information Systems, is a “theory” component that

provides an introduction to health care applications and the systems that use them, health

information technology standards, health-related data structures, and enterprise architecture in

health care organizations.

Lecture b will identify the challenges and barriers in building and using clinical decision support

systems, explain how legal and regulatory technologies may affect their use, and introduce the

future directions for clinical decision support systems.

1

The objectives for this unit, Clinical Decision Support Systems are to:

• Describe the history and evolution of clinical decision support;

• Describe the fundamental requirements of effective clinical decision support systems;

• Discuss how clinical practice guidelines and evidence-based practice affect clinical decision

support systems;

2

Additional Objectives for this unit, Clinical Decision Support Systems are to:

• Identify the challenges and barriers to building and using clinical decision support systems;

• Discuss legal and regulatory considerations related to the distribution of clinical decision

support systems;

• and Describe current initiatives that will impact the future and effectiveness of clinical decision

support systems.

3

As a framework for supporting clinical decisions to improve outcomes, the CDS Five Rights

model states CDS-supported improvements in desired healthcare outcomes can be achieved if

communication occurs in the following manner:

“The right information: Evidence-based, suitable to guide action, pertinent to the circumstance

To the right person: Considering all members of the care team, including clinicians, patients, and

their caretakers

In the right CDS intervention format: Such as an alert, order set, or reference information to

answer a clinical question

Through the right channel: For example, a clinical information system (CIS) such as an electronic

medical record (EMR), personal health record (PHR), or a more general channel, such as the

Internet or a mobile device

At the right time in workflow: For example, at time of decision/action/need” (Sirajuddin et al.,

2009, p. 40).

However, achieving the five rights for CDS is challenging. Berner (2009) states “Achieving the

five rights for CDS presents challenges, and the challenges differ depending on how closely the

CDS is tied to what the clinician already intends to do. Clinicians may initially want certain

reminders or, after performance assessments, agree that they need other reminders, but in

either situation they are choosing to receive the reminders. The key issue in reminding the user

about things they choose to be reminded about is the timing of the reminder. For instance,

should reminders for preventive care be given to the physician in advance of the patient visit

4

(e.g., the day before), or should the reminders appear during the patient’s visit” (p. 7-8)?

4

Clinical decision support systems offer so much potential to improve patient care and outcomes.

Similar challenges in designing and selecting clinical decision support systems to the five rights

model can be posed as questions. Berner (2009) asked them in the following manner: “whose

decisions are being supported, what information is presented, when is it presented, and how is it

presented to the user” (p. 6).

Each question should be explored and answered before building or selecting a clinical decision

support system. If any are ignored, the chances that end-users will use it and the expected

system benefits gained are limited. For example, consider the question – when the intervention

will be presented? Depending on the information, the best time to deliver could be at the point of

care—for example, delivering an alert about drug-to-drug interactions at the time of prescribing.

Other information, such as providing the names of patients being seen on a given day who need

immunizations, could occur prior to the patient encounter. Knowing when the information from

the CDS should be presented automatically or “on demand”, i.e., when the user chooses to

access the information, is no small feat. Tying the answers to the other questions, e.g., whose

decisions are being supported, can also be complex.

5

Looking further at the challenge of knowing when the information from the CDS should be

presented, that is, automatically or “on demand,” another factor that must be considered and

presents its own set of challenges is deciding how much control the user has over the decision to

use clinical decision support. In other words control over whether users are required to accept

the CDS suggestion, whether they can easily ignore it, or whether it takes significant effort to

override the advice.

Berner (2009) explains, “These decisions involve not only whether the CDS is set up to be

displayed on demand, so that users have full control over whether they choose to access it, but

also the circumstances under which users can, after viewing the CDS information, choose

whether to accept it. The two aspects of control are related and they connect with how closely

the CDS advice matches a clinician’s intention. CDS may be designed to (1) remind clinicians of

things they intend to do, but should not have to remember; (2) provide information when

clinicians are unsure what to do; (3) correct errors clinicians have made; or (4) recommend that

the clinicians change their plans. Conceived of in this way, it should be obvious that the users’

reactions to CDS may differ with these diverse intents” (p. 7).

6

Building on to the challenges already described, Table 5.1 summarizes three clinical decision

support intents and matches each to a user’s intention along with a key issue.

The first CDS intent is an automatic intervention – a reminder of actions a user intends to do but

should not have to remember. As one would expect, timing is a key issue.

Next under CDS intent is an on demand intervention – one that provides information when a user

is unsure of what to do, or a request for consultation. In this instance, it is speed and ease of

access that the user is looking for. According to (Berner, 2009) “Users may recognize the need

for information, but may be willing to access it only if they can do so efficiently. If access is too

difficult or time-consuming, potential users may choose not to use the CDS” (p. 8).

The third row lists the CDS intent as correct user’s errors and/or recommend a user change

plans, and could be either an automatic or on-demand intervention. For an automatic

intervention, the key issues are timing, autonomy, and user control over the response. For an on

demand intervention, they are speed, ease of access, autonomy, and user control over the

response. For this CDS intent, users balance the change planned with the desire for autonomy

with other demands such as improving patient safety or decreasing practice costs. Another key

issue related to autonomy that was previously discussed is the amount of control users have

over how they respond to the CDS.

Berner (2009) goes on to explain, “While some of these issues have been addressed by

research, there are no universally accepted guidelines regarding them, in part because clinicians

often differ in their preferences. In addition, there are varying clinical approaches that are

justified, which makes designing effective CDS a challenge. How these issues are addressed will

influence the ultimate impact and effectiveness of CDS” (p. 8).

7

The report, Clinical Decision Support Systems: State of the Art, cited several studies and

provided insight into other challenges in the building and using of clinical decision support

systems. Discussions were split between the impact on care process and patient health

outcomes and the impact on structure.

For the first one, impact on care process and patient health outcomes, the three challenges

identified were matching of clinical decision support to user intentions, user control,

disruptiveness, and risk, and integration of CDS into work processes.

Each one of these challenges presents issues which need to be addressed when building clinical

decision support systems. For example, according to the report, “…integrating CDS into the

workflow often requires unique customization to local processes, and sometimes to changes in

processes (when previous clinical processes were found to be inefficient or ineffective). CDS

also needs to be minimally disruptive to the clinician’s “cognitive workflow” and this, too, can be a

challenge. For instance, accessing the data needed for the CDS can be disruptive if the clinical

systems are not well integrated or if the necessary data are not in a form that the CDS can use. If

the lack of data leads to inappropriate alerts, these alerts may be overridden. In addition, to the

extent that using CDS or following its advice is disruptive to the clinician’s work or thought

processes, the CDS is likely to be ignored” (Berner, 2009, p. 11).

Another group of discussion points addressed studies on the structural impact of CDS. The

conclusion was “It is important to recognize that the development, implementation, and

maintenance of CDS will have an impact on the structure or work system in which it will be used.

The changes that the CDS will introduce need to be incorporated in the planning so that the

impact on clinician time is not excessive” (Berner, 2009, p. 13)

8

In addition, often IT resources are limited due to implementation of other EHR modules, support

of systems already in place, and compliance demands, which causes barriers to CDS

deployment.

8

There are six barriers to the effective implementation of CDS. The first three identified are:

1. Acquisition and validation of patient data – The issues here are the need to have 1) effective

techniques for capturing data accurately, completely, and efficiently and 2) a standardized

way to express clinical situations that a computer can interpret Musen et al. (2006).

2. Modeling of medical knowledge – Described by Musen et al. (2006) as “deciding what

clinical distinctions and patient data are relevant, identifying the concepts and relationships

among concepts that bear on the decision-making task, and ascertaining a problem-solving

strategy that can use the relevant clinical knowledge to reach appropriate conclusions” (p.

713).

3. Elicitation of medical knowledge – keeping the knowledge-base up-to-date is portrayed by

Musen et al. (2006) as an important problem for CDSS.

9

The last three barriers to the effective implementation of CDS are:

Representation of and reasoning about medical knowledge - Musen et al. (2006) stated “among

the ongoing research challenges is the need to refine the computational techniques for encoding

the wide range of knowledge used in problem-solving by medical experts” (p. 715). Another part

to this is the need to obtain an understanding of the psychology of human problem-solving for

use in the development of clinical decision support tools so they more closely reproduce the

process by which clinicians move through the diagnostic process (Musen et al. (2006).

Validation of system performance – Here Musen et al. (2006) pointed out issues of having a

responsible party for validating the clinical knowledge bases and the challenges in determining

how best to evaluate the performance of the tools that use the knowledge particularly when a

“gold standard” in which to perform the evaluation doesn’t exist.

Integration of decision-support tools – Musen et al. (2006) state the need for “…more innovative

research on how best to tie knowledge-based computer tools to programs designed to store,

manipulate, and retrieve patient-specific information” (p. 716).

10

One legal barrier to the implementation of clinical decision support systems is the lack of detailed

case laws on issues for dealing with clinical decision support systems and under which category

of law the systems will fall. Musen et al. (2006) provide the following explanation regarding this

barrier: “Under negligence law (which governs medical malpractice), a product or activity must

meet reasonable expectations for safety. The principle of strict liability, on the other hand, states

that a product must not be harmful. Because it is unrealistic to require that decision support

programs make correct assessments under all circumstances—we do not apply such standards

to physicians themselves—the determination of which legal principle to apply will have important

implications for the dissemination and acceptance of such tools” (p. 731).

11

Another legal barrier described by Musen et al. (2006) is the issue of who will bear the liability.

Should it be the physicians or the builders of the systems? Musen et al. (2006) state “A related

question is the potential liability borne by physicians who could have accessed such a program,

and who chose not to do so, and who made an incorrect decision when the system would have

suggested the correct one. As with other medical technologies, precedents suggest that

physicians will be liable in such circumstances if the use of consultant programs has become the

standard of care in the community” (p. 731). With no case law yet to establish the precedent,

recommendations have been for stronger regulation and guidelines.

12

There are also regulatory barriers that could affect distribution of clinical decision support

systems. One identified by Musen et al. (2006) is the validation of decision-support tools before

their release and what role the government should play.

Where should the government fall with regards to prerelease regulations of medical software?

Musen et al. (2006) point out that “Programs that make decisions directly controlling the patient’s

treatment (e.g., closed loop systems that administer insulin or that adjust intravenous infusion

rates or respirator settings) are viewed as medical devices subject to FDA regulation” (p. 732).

However, the IOM report Health IT and Patient Safety: Building Safer Systems for Better Care

did not recommend the FDA, ONC, CMS, or AHRQ as the regulatory body to oversee health IT

safety but did recommend the creation and funding of a new independent federal agency, similar

in structure to the National Transportation Safety Board (IOM, 2012, p. 128).

Other barriers include data privacy and security. Identifiable data used for research purposes are

afforded protections which is one view of what data used for CDS is. Aggregated data can be

used without consent, but de-identification and aggregation of clinical data across systems is

difficult.

While there are challenges and barriers, including legal and regulatory ones, in the building, use,

and distribution of clinical decision support systems, their benefits such as avoidance of errors

and adverse events, are seen as worth the work involved. A description of the various efforts and

initiatives are discussed in the next few slides.

13

Legislative and regulatory efforts needed to support widespread adoption of clinical decision

support systems were identified by the AHIC CDS Workgroups.

As explained in a letter to Secretary HHS Leavitt the recommendations were as follows (AHIC,

2008):

1. Drive measurable progress toward priority performance goals for health care quality

improvement through effective use of CDS

2. Explore options to establish or leverage a public-private entity to facilitate collaboration

across many CDS development and deployment activities.

3. Accelerate CDS development and adoption though federal government programs and

collaborations.

One of these recommendations has been implemented as the next few slides will show.

14

There are a number of projects shaping the future directions for clinical decision support

systems. These include the Office of the National Coordinator’s initiatives, the Institute of

Medicine’s studies, and the meaningful use criteria, objectives and measures. Each will be

explored in the slides that follow.

15

The Office of the National Coordinator for Health IT (ONC), which is charged with coordinating

federal efforts regarding HIT adoption and meaningful use, has stated their commitment and

facilitated a number of projects for the purpose of moving CDS development and deployment

ahead. The major activities include:

The “Advancing CDS” is a project intended to:

“Advance the widespread dissemination of successful CDS implementation practices to promote

broad CDS adoption

Improve the acceptance and usability of medication CDS systems through the development of a

clinically important drug-drug interaction list

Advance the practical sharing of effective CDS interventions across care settings

Identify CDS-related gaps and goals specific to a broad range of clinical specialties” (ONC, 2011,

para. 3)

Another ONC initiative related to CDS includes the report Development of a Roadmap for

National Action on Clinical Decision Support that recommended ways to improve CDS

development, implementation and use. Three pillars for fully realizing the promise of CDS were

identified. They are: 1) Best knowledge available when needed, 2) High adoption and effective

use, and 3) Continuous improvement of knowledge and CDS methods (Osheroff, et al., 2006,

p.5).

Other projects include the development of CDS recommendations by the AHIC workgroups

mentioned previously, an ONC-sponsored Clinical Decision Support (CDS) Workshop, and the

CDS Federal Collaboratory.

16

The final ONC initiative is an Institute of Medicine study carried out under a $989,000 contract

awarded in September 2010. The next slide will provide more information on this work.

16

The Institute of Medicine (IOM) has for many years published key bodies of work. A press

release on September 29, 2010 included a quote from Dr. David Blumenthal who at the time

was national coordinator for health information technology which explained IOM’s role “Since

1999, when the IOM published its ground-breaking study To Err Is Human, the Institute has been

a leader in the movement to improve patient safety” (CMS, 2010).

The To Err is Human report emphasized “…mistakes can best be prevented by designing the

health system at all levels to make it safer--to make it harder for people to do something wrong

and easier for them to do it right” (National Academy of Sciences, 2000).

The IOM study launched in 2010 was aimed at examining a comprehensive range of patient

safety-related issues, including prevention of HIT-related errors and rapid reporting of any HIT-

related patient safety issues. IOM saw its charge as “recommending ways to make patient care

safer using health IT so that the nation will be in a better position to realize its potential benefits”

(National Academy of Sciences, 2011). As mentioned previously, one of the recommendations

was the creation and funding of a new independent federal entity that would have the

responsibility to oversee health IT safety. Another recommendation was funding a new Health IT

Safety Council to set standards for safety.

17

The final endeavor having an impact on future directions for CDSS is the American Recovery

and Reinvestment Act or ARRA and the associated Health Information Technology for Economic

and Clinical Health (HITECH) provision. ARRA, officially Public Law 111-5 signed into law

February 2009, provides many different stimulus opportunities, one of which is $19.2 billion for

health IT. HITECH is a provision of the American Recovery and Reinvestment Act. The HITECH

section of ARRA deals with many of the health information communication and technology

provisions. It established programs under Medicare and Medicaid to provide incentive payments

for the "meaningful use" of certified EHR technology. According to the Centers for Medicare and

Medicaid Services (CMS, 2011), “The Medicare and Medicaid EHR Incentive Programs will

provide incentive payments to eligible professionals, eligible hospitals and critical access

hospitals (CAHs) as they adopt, implement, upgrade or demonstrate meaningful use of certified

EHR technology” (para. 1).

On July 13, 2010, the Secretary of HHS published in the Federal Register a final rule that

adopted standards, implementation specifications, and certification criteria for HIT. The final rule

was released in conjunction with the Medicare and Medicaid EHR Incentive Programs final rule.

The CMS regulations specify the objectives that providers must achieve in payment years 2011

and 2012 to qualify for incentive payments. The ONC regulations specify the technical

capabilities that EHR technology must have to be certified and to support providers in achieving

the “meaningful use” objectives.

Following are meaningful use requirements that must be met to qualify for incentive payments

(CMS, 2010, p. 44350):

• For the eligible professional: Implement one clinical decision support rule relevant to specialty

or high clinical priority along with the ability to track compliance with that rule.

• For the hospital: Implement one clinical decision support rule related to a high priority hospital

18

condition along with the ability to track compliance with that rule

18

This concludes Clinical Decision Support Systems.

Lecture a defined clinical decision support, described system requirements, and explained the

effects of clinical practice guidelines and evidence-based practice on CDSS.

Lecture b described challenges and barriers, including legal and regulatory ones, in the building,

use, and distribution of clinical decision support systems. To move forward requires further effort.

A number of projects shaping the future directions for clinical decision support systems have

come to fruition in the last few years, and more initiatives are underway. These include the ONC

initiatives and the meaningful use requirements tied to clinical decision support.

19

No audio.

20

No audio.

21

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. © Johns Hopkins University. UMUC has modified this work and it is available under the original license.

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
Welcome to Quality Improvement: Decision Support for Quality Improvement. This

is Lecture a.

This unit is designed to provide information on Clinical Decision Support as it is

used to enhance patient care quality and safety.

1

The Objectives for Decision Support for Quality Improvement are to:

•Define decision support, its importance, and why it is difficult to implement.

•Compare decision support tools that help improve quality.

2

According to Healthcare Information and Management Systems Society (HIMSS),

“Clinical Decision Support is a process for enhancing health-related decisions and

actions with pertinent, organized clinical knowledge and patient information to

improve health and healthcare delivery. Information recipients can include patients,

clinicians and others involved in patient care delivery; information delivered can

include general clinical knowledge and guidance, intelligently processed patient

data, or a mixture of both; and information delivery formats can be drawn from a rich

palette of options that includes data and order entry facilitators, filtered data

displays, reference information, alerts, and others.”

Clinical Decision Support Systems (CDSS) are typically designed to integrate a

medical-knowledge base, patient data, and an inference engine to generate care-

specific advice. These systems are designed to help healthcare providers make

decisions at the point of care.

This unit will present examples of Clinical Decision Support (CDS) and more

complex decision support systems. CDS can occur without a complex system to

support it and should be pervasive in HIT systems. It is also important to consider

that CDS systems are support tools and must be surrounded by a strategy and an

overall aim. Whether you choose CDS or CDSS they will be of no use unless you

have an overarching goal for their implementation.

3

Here are some examples of how the CDS can help improve the care of patients.

Hospital example: a physician is writing an order for an antibiotic that has to be

dosed depending on the kidney function. When he adds the antibiotic at its full dose,

the computer will prompt him to reconsider the dose based on the latest creatinin (a

blood test of kidney function) and pulls up a dose calculator.

Primary-care example: a medical assistant is rooming a patient and reviews a

reminder that informs her that the patient is due for a PAP and a mammogram. She

tells the patient and they decide she would like to have it today. By the time the

clinician walks in, the patient is undressed and ready for the PAP, the mammogram

order papers are ready, and the patient has been informed about how to perform

her breast self-exam.

As you can see, CDS systems are important tools for increasing the safety and

efficiency of the health care system.

4

The CDS Five Rights model states that we can achieve CDS-supported

improvements in desired healthcare outcomes if we communicate following these

five premises:

•The information has to be evidence based, pertinent, and actionable. There is no

point to adding information if you cannot do anything about it.

•There is a tendency to have the clinician be the recipient of all information. As

teams organize around the patient-centered care model, one should consider which

member of the team is the appropriate recipient.

•CDS can be administered in many different formats. Consider the use of alerts,

order sets, or reference information as different CDS formats. Each has a role in the

development of an institutional strategy.

•The delivery channel is also an important component of the CDS design. A delivery

model example could include a PHR (personal health record) a mobile device, an

EHR (Electronic Health Record) or a more general channel such as the Internet.

•The final component of a sound CDS strategy is the time when the information is

delivered. When are the decisions made and when are actions taken?

5

There are a number of CDS systems, including relevant data displays, smart

documentation forms, order facilitators such as smart order sets, consequents and

modifiers, extended-time guidelines and protocols, targeted reference, such as

contextually relevant medical references or information buttons, reactive alerts and

so on.

6

Other CDS systems include task assistants for tasks such as drug dosing and

acknowledging laboratory results, diagnostic suggestions, patient summaries for

hand-offs between clinicians, procedure refreshers, training, and reminders;

performance dashboards with prompts for areas needing attention; and tracking and

management systems that facilitate task prioritization and whole-service

management.

7

Let’s review some of the research that supports the effectiveness of CDSS.

Kuperman and his research team report that clinical decision support systems,

when combined with CPOE, have the potential to improve medication safety and

reduce medication-related expenditures. In addition to the obvious benefits of

increasing legibility of orders, these systems introduce automation at the time the

prescriber places an order. Decision support can also assist to ensure the safety of

the order as well as compliance with clinical practice guidelines.

An example is provided by Seidling and colleagues, who developed a

comprehensive algorithm that pulled relevant patient data—such as age and renal

function—and adjusted upper dose limits for these patient characteristics. They

have been able to decrease prescription of excessive medication doses using this

type of decision support.

8

Despite the potential usefulness of decision support systems, there is concern over

the lack of widespread clinical acceptance by clinicians. In the early development of

clinical decision support systems, there were three basic assumptions, which

strongly influenced the development of these systems. These assumptions have

been challenged and are now seen as myths. The first myth is that diagnosis is the

dominant decision-making issue in medicine. In reality, clinicians usually ask “what

can I do for this patient?” rather than “what does this patient have?” The second

myth is that clinicians will use knowledge- based systems if the programs can be

shown to function at the level of experts. We know that there is significant variation

in practice, even among experts. The final myth is that clinicians will use stand-

alone decision support tools. We know now that we need to integrate decision

support into the context of routine clinical workflow.

9

Four key functions of electronic Clinical Decision Support Systems have been

identified. These include: administrative, managing clinical complexity and details,

cost control, and decision support.

10

Decision support has the potential to be helpful to support clinical coding. In addition

to assisting with authorization of procedures and referrals, decision support can

assist in selection of appropriate diagnostic codes for billing purposes. Coding

accuracy, that is, the extent to which the code accurately reflects the underlying

patient’s disease, directly affects the quality of billing decisions. The quote on the

slide from Peters illustrates this point.

Since coding is based on clinical documentation, with the advent of electronic-health

records, administrators are looking for opportunities to capture accurate billing

information from the data documented by clinicians, especially documentation of

coded problem lists and data contained in history and progress notes. Other

researchers are investigating the use of decision-support tools that employ

algorithms based on clinical data in the EHR, to display a proposed list of coded

diagnoses to guide prescribers to make the most appropriate selections.

11

Decision support is used to manage the complexity of the clinical environment,

especially in academic medical centers. Academic medical centers have a

combined clinical and research mission and very complex business operations. With

respect to clinical research, alerts can be established to assist with the recruitment

efforts of clinical researchers by identifying eligible research participants based on

inclusion and exclusion criteria. Clinical Decision Support is also used to manage

follow-up of multiple referrals and tracking of orders. Clinical guidelines and

outcomes related to preventive care and treatment of patients with chronic disease

is another area in which investigators are studying the effectiveness of clinical

decision support.

12

Decision support can be used to help control the costs of care. By monitoring

prescribing practices with respect to high cost medication orders, alerts can be

generated to suggest lower cost alternatives. When institutions place restrictions on

prescribing high cost drugs, decision rules can ensure that indications for use are

present. Duplicate or unnecessary laboratory and radiologic testing can be avoided

by applying decision rules that warn the prescriber that the test has already been

ordered, or that the test is inappropriate for the particular patient.

13

General decision support functions promote use of best practices and facilitate

evidence-based population management. For example, rules-based logic can scan

available patient information and flag patients who are not in compliance with

wellness or disease management regimens and alert the provider or the patient that

interventions are due. Formulas and algorithms can present relevant patient data

and perform complex calculations that the providers used to have to perform by

hand. Important patient information can be tracked in disease registries. For

example, diabetes-disease registries may include pertinent laboratory tests, dates of

last foot and eye exams, and due dates for next services. Summary screens,

usually the first to appear when the electronic record is opened, display patient

problems, medications, recent laboratory test results, and other pertinent clinical

information in a, “patient-at-a-glance,” display. These summary screens serve as

reminders for the patient’s care team about chronic issues to factor into decisions

as well as for covering providers who may have gaps in knowledge about the

patient. Clinical situations can also be addressed as preassembled order sets for

typical clinical scenarios. For example, annual physical examinations for females

over age 45 may aid the provider to order the appropriate preventive tests as

needed.

14

Researchers have looked at unintended consequences related to Clinical Decision

Support. These consequences can be categorized into consequences related to

content and presentation. There are three themes related to content. The first is

elimination or changing of roles of clinicians and staff, especially clerical staff. For

example, one case study noted that clinicians underestimated the gatekeeper

function of the clerical staff, who in the paper world, questioned daily X-ray orders

after a certain amount of time, but once they automated this function, chest X-ray

orders went on ad infinitum. A second unintended consequence related to currency

of Clinical Decision Support content. For example, changes in coding for billing or

compliance and difficulties updating order sets may cause problems. Another

content-related consequence is wrong or misleading clinical decision support

content. An example of this would be a clinical decision support rule that leads

clinicians to order something that is not adequately stocked. Another example is

when contradictory advice is offered by two separate clinical decision support rules.

The second category of unintended consequences is presentation. This category

includes rigidity of systems, alert fatigue, and other sources of potential error. For

example, the way in which workflow is changed by the insertion of the computer into

the clinical workspace represents a presentation consequence. Alert fatigue is so

great a problem that there is an entire unit devoted to that issue. Other sources of

potential error include such things as the auto-complete feature that may insert the

wrong medication or alerts that are seen when it is too late for action.

15

This concludes Lecture a of Decision Support for Quality Improvement. In

summary, Clinical Decision Support Systems are usually designed to integrate a

medical knowledge base, patient data, and an inference engine to generate care-

specific advice. Despite the potential usefulness of Clinical Decision Support, its use

has not led to widespread adoption. In planning to implement Clinical Decision

Support, IT professionals need to know that it will be used by clinicians and that its

use will alter clinical decision-making, change behaviors, and improve patient

outcomes. Four key functions of Clinical Decision Support are: administrative,

managing clinical complexity and details, cost control, and decision support.

16

No audio.

17

No audio.

18

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. © Johns Hopkins University. UMUC has modified this work and it is available under the original license.

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
https://creativecommons.org/licenses/by-nc-sa/3.0/us/
Welcome to The Culture of Healthcare: Privacy, Confidentiality, and Security. This is Lecture (a).

The component, The Culture of Healthcare, addresses job expectations in healthcare settings. It discusses how care is

organized within a practice setting, privacy laws, and professional and ethical issues encountered in the workplace.

1

The objectives for Privacy, Confidentiality, and Security are to:

• Define and discern the differences between privacy, confidentiality, and security

• Discuss the major methods for protecting privacy and confidentiality, including through the use of information technology

• Describe and apply privacy, confidentiality, and security under the tenets of HIPAA Privacy Rule

• Describe and apply privacy, confidentiality, and security under the tenets of the HIPAA Security Rule

2

This unit defines these important terms and discusses reasons for concerns about privacy and security related to health

information. Tools for protecting health information will be examined, followed by a discussion of the Health Insurance

Portability and Accountability Act, or HIPAA [hip-uh] regulations and what additions have been made in the HITECH [high-tehk]

(Health Information Technology for Economic and Clinical Health Act) legislation.

3

This lecture discusses Privacy and Security.

Privacy is one’s right to keep information to one’s self. It is the right to be left alone, the right to keep personal information

secret, and in essence, the right to control personal information.

Confidentiality, on the other hand, is one’s right to keep information about one’s self from being disclosed to other people. When

a patient vests confidentiality in a physician and a healthcare system, it is expected that personal information is kept confidential

and not disclosed to others. Data is only shared or disseminated to those with a “need to know.”

Security is the activity of protecting personal information. It consists of mechanisms to assure the safety of data and the

systems in which the data reside.