Info System / Health Care
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
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
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.
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.
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.
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.
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.
4
Individually identifiable health information, or IIHI [eye-eye-H-eye] is any data that can be correlated with an individual, for
example information in a medical record or a database that can be linked up to an individual. A related term is personal health
information. This is individually identifiable health information as defined explicitly by the HIPAA [hip-uh] privacy rule in the US.
Finally, consent is actually a broader term but it will be defined here in the context of privacy. When consent is given to the
healthcare system, it entails written or verbal permission to allow use of individually identifiable health information for the activity
of providing healthcare or for participation in a research project or related activity.
5
The remainder of this lecture focuses on concerns about privacy and security beginning with concerns about privacy followed
by the notion of personal privacy versus the common good. The discussion continues with disclosures of personal health
information, examining some of the concerns that the public has about the privacy of health information. Finally, the lecture will
close with a few comments about de-identified data.
6
Consider the notion of personal privacy versus the common good. Some of the concerns are well demonstrated in a video that
was produced in 2004 by the American Civil Liberties Union, to which a link is provided. In this video, a pizza restaurant has
access to customer’s medical information and they penalize them for things like ordering extra cheese when their cholesterol
levels are shown to be high. It is a video worth watching, even though it takes a very specific point of view.
There is a broad spectrum of views here, often times reflecting underlying political beliefs.
At one end of the spectrum is the view that while personal privacy is important, there are some instances when the common
good of society outweighs personal privacy. An example that is often given is biosurveillance [buy-oh-sur-vay-lehns], whether it
is monitoring emerging natural diseases or things like bioterrorism. Early intervention and response is possible with more
information. Another example is clinical research. When more clinical research is conducted, the ability to provide quality
healthcare is increased.
The other end of the spectrum holds that personal privacy trumps everything, that there should really be no reason to violate
one's privacy without explicit consent. Some of the organizations that are prominent in promoting this point of view include the
Privacy Rights Clearinghouse that has written specifically about medical information even though they typically deal with
broader privacy rights topics. Another group is called patientprivacyrights.org, and is headed by Dr. Deborah Peel, a Texas
7
psychiatrist who is very well known and outspoken on personal privacy.
Others have called for a more balanced approach between personal privacy and the common good. For more information on this topic,
some good articulations of this can be found in documents from the California Healthcare Foundation, an editorial by Dr. Don Detmer,
and a policy paper from the American College of Physicians.As with many ethical issues, there are no explicitly right or wrong answers,
and each individual has to decide where their views fall on the spectrum; however the US political process, not the individual, will more
than likely determine how personal privacy and common good in terms of healthcare are balanced.
7
It is important to know about patient information disclosure and how to prevent it from happening in the future. One particularly
egregious [ih-gree-juhs] story happened in Portland, Oregon on New Year's Eve, 2005. On that date, an individual left in his car
a number of disks, backup tapes, and other media that contained the records of about 365,000 patients who were seen by a
visiting nurse association. This naturally received a lot of press and demonstrated the need to be careful and not, for example,
leave items in your car, especially if they contain personal health information.
The Veterans Administration system has had a number of episodes, probably the largest of which was when a laptop with the
data of over a million veterans was stolen. The laptop was recovered and it appeared that the data was not accessed, but of
course, no one knows exactly what went on with the machine when it was in the hands of those who stole it.
More recent data shows that disclosures continue to be a problem. Two Web sites are devoted to ongoing documentation of the
problem. The Privacy Rights Clearinghouse provides a searchable Chronology of Data Breaches. The data includes medical
breaches but is not limited to them. The site can be linked to from http://www.privacyrights.org/data-breach.
The Department of Health and Human Services (HHS, aych-aych-ess) is now required under the HITECH Act to post a list of
breaches of unsecured protected health information affecting 500 or more individuals. It is called by some their “wall of shame.”
It can be accessed at http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachtool.html.
8
By end of 2011, this site had documented 380 incidents affecting 18,059,831 individuals.
8
The Ponemon [pone-eh-mon] Institute publishes an annual report on the impact of security breaches on healthcare
organizations. The 2011 report found that the number of breaches increased by 32% over 2010. It also found that the average
cost per breach to an organization was $2.2 million and took one to sixth months to resolve. A significant part of cost was “lost
business” by the organization.
About 41% of the breaches were discovered as a result of a patient complaint. The top causes of data breaches were
unintentional employee action, lost or stolen computing devices, or third-party problems. Of note, most organizations believe
their EHR makes data more secure.
9
There are newer challenges from the proliferation of health IT technologies and applications. For example, there is an ever-
growing use of electronic data in clinical workflows. Likewise, health information exchange (HIE) moves data across networks
and cloud computing alters the perimeter of data protection. There are also new models of healthcare, such as accountable
care organizations (ACOs, ay-see-ohs) that require more members of a team to access information. Finally, clinicians want to
increasingly use their own devices, such as personal laptops, tablet devices, smartphones, and so forth.
10
And, of course, technology itself can worsen the problem. A widely cited study by Wright looked at the USB drives commonly
plugged into computers (sometimes called thumb drives). These drives run a program that enables their use when they are
plugged in, and that program can be modified to extract data from the computer. So if that computer has personal health
information on it, the thumb drive can basically copy it off the computer.
There are many people who have developed personal health record systems based on tools like Microsoft Access, which has
some encryption functionality, but is very easily compromised.
Another interesting analysis found that ten percent of hard drives sold by second-hand retailers in Canada had remnants of
personal health information (PHI) on them. Often when computers are disposed of, the hard drives are not completely wiped
clean, potentially providing access to personal information to the next user, if they know how to extract it.
Also of note is that PHI can be discovered by files available from peer-to-peer (P2P, pee-two-pee) file-sharing networks. One
analysis found that half of one percent of all IP addresses on the Internet in the US have discoverable PHI.
Finally, another technology that can store PHI is the digital photocopier, which stores all copies on an internal hard disk. If this
information is compromised, PHI can potentially be leaked.
11
Two analyses have shown that healthcare organizations are not well-prepared for security challenges. A report by Deloitte
[deh-loyt], the consulting firm, looked at security issues in healthcare organizations and came to the following conclusions:
The primary threat to information is data leakage, or data that gets out in the routine care of patients. The report also concluded
that identity and access management is a top priority. The trend towards outsourcing of IT in healthcare organizations raises
many third-party security concerns.
The role of the chief information security officer or chief security officer in most healthcare organizations, particularly large ones,
then takes on greater significance. Every decision about information systems needs to be assessed from the standpoint of
security.
This report also found that despite the increasing complexity of the security environment and the growing number of
regulations, the budgets of financially strapped healthcare organizations were not keeping pace with security needs.
The annual security readiness survey by HIMSS [himz] Analytics reached roughly the same conclusions: healthcare
organizations, in general, are not keeping pace with security threats and readiness. This analysis found, for example, that 85%
of organizations share electronic data but only 61% perform a risk analysis annually or more frequently.
12
One question to ask is, “What is the role of government in protecting privacy and confidentiality?” This discussion will begin by
looking at the US and then move to other countries.
In the US, the National Center for Vital & Health Statistics, or NCVHS [N-C-V-H-S], has weighed in over the years on a number
of privacy and security issues. In 2006, it released a set of twenty-six recommendations for policies concerning health privacy
for the Nationwide Health Information Network. Further recommendations have been released for personal control of health
information, and again called for a consistent and coherent policy.
Another activity has been the HISPC [hisp-see] effort, the health information security and privacy collaboration, a project funded
by the government that looked at forty-two states and territories and assessed the various approaches and laws to privacy. A
wide range of privacy policies were found and it was concluded that a nationwide approach would be difficult due to the
sometimes conflicting laws. There probably needs to be more harmonization of privacy laws as more health information
exchanges that move personal health information across state lines are developed.
More recently, the Office of the National Coordinator for Health Information Technology (ONC) has established a Privacy &
Security Tiger Team charged withdeveloping policies and vetting them with other ONC policy and standards committees.
13
The US is not the only government that has been addressing privacy. In fact, the European Commission has devoted even
more efforts to the protection of individual privacy. The directive, 95/46/EC, is a set of fairly stringent rules that essentially
allows data processing only with consent or in some highly specific circumstances, such as a legal obligation, or what is defined
as a public necessity, usually revolving around public health. The countries that implement this directive provide examples of
how “consent” around information could be used for efforts in the US in the Nationwide Health Information Network.
14
There are a number of related issues for medical privacy. One of these issues, and again, there is no right or wrong answer,, is
who owns medical information. As the articles by Hall and Rodwin point out, historically the owner of the information medium
was considered to be the owner of the information.
For example, if an office practice or hospital had paper charts, and had bought and owned the paper the charts were printed on,
it was presumed that the practice or hospital owned the information on that paper. However, in the electronic era, information
moves freely across networks from one system to another, and ownership of that information becomes less clear - in fact, a
growing view is that the patient owns their own information.
As the amount of information increases, there is an increased economic value to health systems, pharmaceutical companies,
and others who may want to use that data for various purposes. The article by Rodwin, in particular, argues that when there is
an economic advantage gained by the use of that information, then at least some of that gain should be shared back to the
patient.
Another concern is compelled disclosures of information, that is, even though laws and regulations may highly protect
information, individuals may sometimes be compelled to disclose information for nonclinical care reasons in the healthcare
setting. Healthcare providers need to be aware of requiring individuals to disclose information that is not really being used for
15
health-related activities.
Another growing issue concerns the human genome, which may be a person’s ultimate personal identifier. A person’s genome is what
makes them an individual. Individual genes and the variation that they have from others’ genes, are unequivocally unique to each
person. Health information can be de-identified, but with genomic information, individuals may be easily identifiable.
Access to the genomic information manifests itself in a number of ways. For example, a person's genome [jee-nohm] can be identified
by the genomic [ ji-noh-mik] information in their siblings. There are a growing number of genome wide association studies where an
attempt is made to associate variation in an individual’s genome [jee-nohm] with different diseases. There is actually a requirement for
researchers to put this data in public databanks, although usually the individual personal information is protected, with the exception of
the researchers who can legitimately get to that information. It is not too difficult to identify who the individual is from that data, so as
research moves forward with genomics [ ji-noh-miks] and personalized medicine, more privacy issues will come to the fore.
15
Another number of organizations have tried to define health information rights. One example is the Declaration of Health Data
Rights, which comes from a group of mostly personal health record (PHR, pee-aych-are) vendors, accessible at
HealthDataRights.org. This group advocates that individuals should all have the right to their own health data. Theyshould also
have the right to know the source of each health data element. In addition, individuals should have the right to take possession
of a complete copy of their individual health data, without delay, at minimal or no cost. If data exists in computable form, it must
be made available in that form. Finally, individuals should have the right to share their health data with others as they see fit.
The American Health Information Management Association (AHIMA, a-hee-mah) also has a Health Information Bill of Rights
that is slightly more detailed but has similar provisions.
16
When data is referred to as being de-identified, this refers to the removal of personally identifying characteristics of the data,
such as name or address, or other fields that make up personal health information. Is de-identified secure? It may not always
be as secure as intended.
One researcher, Dr. LaTonya Sweeney, brought this to light and has received notice in the popular press is. When she was
completing her PhD at MIT, she did a widely cited study that essentially identified William Weld, the Governor of Massachusetts
at the time, from information found by linking up to publicly available data sources. Her research also showed that eighty-seven
percent of the US population could be uniquely identified by their five-digit ZIP code, gender, and date of birth.
So when relatively common data elements are combined, individual identities may be easily identified. In the case of William
Weld, Dr. Sweeney was able to access a health insurance database for state employees, and Governor Weld was obviously a
state employee, and she was also able to purchase the voter registration list for the city of Cambridge, Massachusetts, where
he lived. She then combined these two databases, linking up the ZIP code, gender, and date of birth, and was able to identify
the Governor, as will be demonstrated further in the next slide.
While it has been found that genomic data that can be generated in clinical research studies, some recent research has shown
how Social Security numbers of individuals can be predicted from public data because so many data sets have Social Security
17
numbers.
17
This slide demonstrates how Governor Weld was identified. On the left is the so-called de-identified state employee health
database, which included state employees’ ethnicity, visits to healthcare providers, diagnosis, procedures, medications, and
charges. It also contained ZIP codes, dates of birth, and gender. The Cambridge voter registration database included name,
address, registered party affiliation, and the same ZIP codes, date of births, and gender. Governor Weld was one of those
eighty-seven percent who had a unique combination of ZIP code, date of birth, and gender. So Dr. Sweeney was able to take
Weld’s voter registration information and then access his entire medical information; this was picked up by the national media
and at the time caused quite a stir.
18
This concludes Lecture (a) of Privacy, Confidentiality, and Security. In summary, it is important to distinguish between
privacy, which is the right to keep information to one’s self, from confidentiality, which is the right to keep information about
one’s self from being disclosed to others. For many reasons, breaches and disclosures of patient information are increasing. In
addition, the concept of “de-identified” information is not necessarily as secure as originally thought.
19
References slide. No audio.
20
References slide. No audio.
21
References slide. No audio.
22
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.
Welcome to The Culture of Healthcare: Privacy, Confidentiality, and Security. This is Lecture (b).
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 of 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 lecture discusses concerns that people have about the security of health information. One of the ways to protect privacy is
to make information more secure. A comprehensive overview is the recent book, Information Security in Healthcare - Managing
Risk, by Herzig.
So what concerns do people have about security? The following slides will look at the many points of leakage in the system,
some of the consequences of poor security and the related topic of medical identity theft.. It is important to remember that
security is not unique to electronic systems – it is also an issuefor paper systems. .
3
As anyone who works in a healthcare setting knows, there are many points where information can leak out of the system. This
figure, adapted from Rindfleisch [rihnd-flahysh], shows how information flows through the healthcare system. Information is first
generated in the provision of patient care by healthcare providers and clinics and hospitals. It then then flows to healthcare
support activity, such as payers of healthcare, the insurance companies that reimburse, quality reviews thatmeasure the quality
of care delivered, and other types of administration. There are also what Rindfleisch [rihnd-flahysh] describes as social uses of
information, everything from insurance eligibility to reporting to public health authorities and using data in medical research -
although it is regulated now by the Health Insurance Portability and Accountability Act (HIPAA) more so than when this figure
was published. There are also commercial uses of information, things like marketing, participating in managed care
organizations that may use data for various purposes to try to improve the quality or efficiency of the care they deliver, and the
monitoring of drug usage. There are many points along the way where information can leak out of the system.
4
It is important to note that even though the concerns about privacy and security are heightened with electronic systems, paper
records have their own set of privacy and security problems. In fact, some have argued that they may be more prone to
breaches of security and disclosure. Unlike electronic systems, it is very difficult to audit the trail of a paper chart. It is not clear
exactly where the chart goes and who has looked at it - unlike most electronic systems that record which login has looked at a
particular piece of information.
There are also issues with fax machines. Even in this electronic era, many still rely on fax machines to move information. When
the paper comes out of fax machines and is put into a basket, anyone can view this document and where this information goes
is not always known.
Records also continue to be photocopied. We photocopy for many reasons: the patient goes to a new provider, the insurance
company needs to have documentation that a specific procedure was done or referral was made, and records get abstracted by
individual people. Whether they are paper or electronic, records are also copied for research or quality assurance purposes.
Most healthcare insurers belong to something called the Health Information Bureau, which monitors for insurance fraud. It has
developed a huge database of individuals’ healthcare claims, looking very properly for health insurance fraud, but also
collecting quite a bit of information on individuals’ personal health.
5
Aware of the consequences of poor security, Rindflesich [rihnd-flahysh] pointed out in the late 1990s that patients do various
things to protect their security. They avoid seeking healthcare. They lie so things will not end up in their charts. Healthcare
providers also have concerns about security, so they may avoid entering sensitive data that could be important in the care of a
patient by others and they may also devise workarounds to entering that information.
A California Healthcare Foundation survey of healthcare consumers found that thirteen percent engaged in activity that the
foundation termed privacy-protective - activities that might put their health at risk, such as asking a doctor to leave out a
diagnosis, perhaps to prevent someone from knowing that they have a certain diagnosis. Some also pay for tests out-of-pocket
because they do not want to submit an insurance claim, knowing that when a claim is submitted, the insurance company then
knows that the test was done. Others avoid seeing their regular doctor for some problems because they are trying to protect
their privacy over some piece of information.
6
A final security concern is medical identity theft. This is a growing concern, especially as more information is available
electronically. With medical identity theft, the thief is using individually identifiable health information for obtaining access to
property or services. When this happens, the victims are not only individuals whose medical records have been compromised,
but also health providers, health plans, and society at large that pays for healthcare, resulting in many victims. The American
Health Information Management Association (AHIMA [uh-hee-muh]) has determined that the value of medical identity
information is much higher than the information accessed through identity theft, like a Social Security number. The Department
of Health and Human Services has also addressed this problem and has developed a report that outlines various approaches to
prevention, detection, and remediation of medical identity theft.
7
The next slides will discuss tools for protecting health information. A good source to begin with is the Institute of Medicine (IOM)
report that addresses issues of protecting electronic health information, entitled For the Record. It was commissioned by the
National Library of Medicine and informed theHIPAA [hip-uh] legislation. It also made recommendations on immediate and
future best practices. While some of the content in the book is dated, the framework provides a good way of thinking about the
problem.
8
There are many different threats to security. There are insider threats which may be accidental disclosure or the curiosity of
individuals working in an institution, or insubordination, where a disgruntled or dissatisfied employee accesses information
inappropriately. The latter is probably the major cause of security breaches. There are certainly secondary settings. There are
also threats that come from outside the institution, such as a hacker that accesses information over the Internet. This type of
threat to security has received a lot of press but there are actually relatively few examples. It is really insider threats that have
proven to be more problematic.
9
There are a variety of technologies that can be used to secure information. There are deterrents, which do not exclude people
from breaching security, but give them pause for doing so, such as putting up alerts when, for example, an employee’s medical
record is about to be accessed. Another deterrent is the audit trail. There are also system management precautions that can be
taken. It turns out that a number of software systems do not protect information as well as they should, and there should be
some kind of analysis of vulnerability.
Here are some obstacles that can prevent individuals from getting to private information:
• Authentication – such as having to use a password or other authentication
• Authorization – where individuals have to be authorized to look at certain information
• Integrity management – where the integrity of the overall system is assessed and maintained
• Digital signatures – requiring a password or other type of digital process to ensure that an individual who is entering data is
truly that individual
• Encryption – which will be covered in the next two slides
• Firewalls – that keep systems inaccessible from, say, the Internet
• Rights management – such as restricting who can look at what aspects of different records
10
The next slides will discuss encryption. While encryption is necessary, it is not sufficient to ensure security. Any medical
communication, whether it is an e-mail or transmission of the medical record, should be encrypted over a public network,
because anyone with the right know-how, could intercept that information.
What actually is encryption? In essence, it is when information is scrambled using a key and then that key has to be used to
unscramble it. There are different types of encryption. So-called symmetric encryption is when information is scrambled and
unscrambled with the same key. Asymmetric encryption,sometimes called public-key encryption, is where there is a different
key for scrambling than for unscrambling the information.
11
There are a number of important standards related to encryption and other functions that are listed on this slide. Not everyone
in the informatics field needs to become an expert, but it is important to know what these standards are in different roles, for
example, how they will be mandated in the Health Insurance Portability and Accountability Act, HITECH [high-tech], criteria for
the meaningful use of electronic health records.
First, there is the encryption standard itself, the advanced encryption standard or AES [ay-ee-ess] that has been designated by
the National Institute for Standards and Technology or NIST [nihst] as the standard for robust enough encryption and decryption
to be used in computer systems for securing information such as health information. Of course information is not just encrypted
and decrypted on individual machines; it moves across networks, so the movement of data from point to point also requires a
process that not only encrypts the data, but make sure that it stays secure as it moves across those connections.
The emerging standard is transport layer security, or TLS, which succeeds a standard that was a very prominent route in the
early days of the World Wide Web, the secure sockets layer, or SSL. Of course information moves according to a protocol,
such as IP [ei-pee], so there is an Internet Protocol Security, or IPsec [ei-pee-sec]. This is part of the IP Internet protocol
communications process that was developed for the new version of IP, version 6, but it has actually been pulled from that
version and added to version 4, which is what most people use when they connect to the Internet.
12
In addition to making sure information is secure from one point to another across the network, the system needs to ensurethe integrity
of the information - that it has not been altered, either due to transmission errors, or for malicious reasons where someone alters the
information in transit. The secure hash algorithms, or SHA [ess-aych-ay], ensure the integrity of transmitted information documents.
The original protocol was SHA [ess-aych-ay], but it was found to have some security flaws, so SHA-2 [ess-aych-ay-two] has emerged
now and is the more robust way of ensuring the integrity of transmitting information across networks. Wikipedia has a nice overview
explanation of these standards, as does the NIST [nihst] website, listed on this slide.
12
For the Record lists a number of best practices, divided into organizational and technical practices.
Organizational practices include confidentiality, security policies and committees; education and training programs; and the all-
important sanctions - so that when an individual is caught breaching security, he or she faces appropriate penalties. Patients
also need to be given access to the audit trail, so they can see who has accessed their record, and then determine whether it
has been done appropriately.
Some of the technical best practices are authenticating users, having audit trails, using various forms of physical security and
disaster recovery, protecting remote access points, having discipline in terms of the software development, and ongoing system
vulnerability assessment. The latter two are quite important in terms of maintaining vigilance about security.
13
The next slides will elaborate on authentication and passwords. Authentication is the process of gaining access to a secure
computer, for example, logging onto a computer. The usual approach for authentication is the password, which is a piece of
information that the computer user “knows”.
With more secure systems, organizations may require information about a physical characteristic, or what you “have”, such as a
biometric device that registers thumbprints, or the use of a smart card or some other physical key that enables the user to
access the machine.
In terms of passwords, the ideal password is one that can be remembered but that no one else can guess. This is easier said
than done, especially in today, when the typical Internet user may interact with many different sites, each of which requires the
use of a password. In busy healthcare settings, there is what is called single sign-on, where the user only has to authenticate
once and then has access into the other systems that they need. Of course, the downside to that is if someone else is able to
gain access through a user’s sign-on, then that user’s access points are now open to that other person.
14
There are a number of challenges with passwords. One approach that is commonly used is password aging so the password
expires after a certain time, usually something like six months, in which case the individual has to create a new password. A
number of security experts have written about password aging and the major conclusion has been that this is not a good
approach to security and it may induce counterproductive behaviors, such as writing passwords down or somehow making
them easier to guess. One report argues that other measures are more effective, things like session locking that only allows
one or a small number of simultaneous logons, so a user cannot log onto many different places at the same time. There are
also login failure lockouts -- after a certain number of unsuccessful attempts, the individual is locked out. But clearly passwords
are going to be a continued issue in terms of keeping information secure, including health information.
15
In the big picture of health information, security represents a trade-off. There is one end of the spectrum with no security where
a website will show the user any page requested, which is appropriate most of the time. On the other end of the spectrum,
there is the level of security that is employed by some of the secretive government agencies like the CIA or the National
Security Administration (NSA, enn-ess-ay).
Healthcare security cannot be at either of these extremes. It cannot be freely available to look at, but it also cannot achieve the
kind of total security that the CIA or NSA can. For this level of security there is a price – a person cannot, for example, bring an
ordinary laptop into a CIA building.
In healthcare settings, there can be many different people looking at information or needing to access it quickly, in order to
maintain the workflow and get the work done. For health information security, there has to be some kind of happy medium,
where information is protected, but it is still easily accessible by those people for whom it is appropriate to look at. There needs
to be a culture of protecting information where accessing that information by appropriate people is not too onerous.
16
We also know there is a need for ongoing research to improve security. The HITECH Program funds four Strategic Healthcare
IT Advanced Research Projects (SHARP). One of these projects is focused on security, called SHARPS (sharp-ess), detailed
on the web site: www.sharps.org.
SHARPS is focused on security issues in three environments. These are:
1. The Electronic Health Record (EHR) – for example, self-protecting and privacy-aware systems
2. Health Information Exchanges (HIEs) (aych-eie-ees) and Personal Health Records (PHRs) (pee-aych-ars) – such as
improved service models and access controls
3. Telemedicine – for example, its devices, telecommunications, and so forth.
17
This slide closes the general conversation on privacy, security, and confidentiality, with a few general issues to ponder.
• Who owns information? When a healthcare provider creates information, puts it on a computer system that they own, or for
that matter, a piece of paper, who actually owns that information?
• Most would argue that the patient owns the information, although the medium is perhaps owned by others. When information
is moved across systems, ownership of the information starts to blur.
• How informed consent best implemented to ensure that people really understand the issues and give truly informed consent?
• When does the public good exceed personal privacy? Should it be for public health measures, for medical research, for law
enforcement?
• What conflicts are there with business interests when it comes to privacy and confidentiality?
• And finally, how will individuals be allowed to opt out of different systems? Should they be allowed to opt out of any specific
piece of information or should it be an all or nothing choice?
If people are allowed to choose different options, what are the costs of each, and is it appropriate for healthcare providers to
override those choices when access to vital patient information is necessary to provide the best medical care and/or to
advocate for the common good?
18
This concludes Lecture (b) of Privacy, Confidentiality, and Security. In summary, there are many points where private patient
information can “leak” out of the healthcare system. There are also many technologies for protecting security that must be used.
One of these, encryption, is necessary but not sufficient by itself. Finally, issues of privacy and security apply to both electronic
and paper-based information.
19
References slide. No audio.
20
References slide. 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.
Welcome to The Culture of Healthcare: Privacy, Confidentiality, and Security. This is Lecture (c).
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 lecture discusses the Health Insurance Portability and Accountability Act (HIPAA) [hip-uh] Privacy Rule. This rule went
into effect in 2003; however, there were substantial enhancements to HIPAA [hip-uh] with the Health Information Technology for
Economic and Clinical Health Act or HITECH [high-tech] legislation. The details of HIPAA are in a posting in the US Federal
Register, and the Department of Health and Human Services Office for Civil Rights maintains a website devoted to privacy and
all of the HIPAA rules and their implications. There are many summaries available on the HIPAA rules, several of which are
listed on this slide. The paper by ID Experts presents a relatively concise overview. Bridgefront focuses on some of the legal
implications and the Leyva [lay-vah] summary is focused more on the clinical side. All of these documents give a very detailed
overview of what is in HIPAA and of course, there are more summaries out there from other sources.
3
Those who work in a healthcare setting in the US, are probably familiar with the HIPAA [hip uh] Privacy Rule. Patients getting
care in the US will likely have been exposed to the HIPAA Privacy Rule as well. The HIPAA Privacy Rule applies to so-called
covered entities, which are essentially any entities that bill electronically. One category of covered entities is healthcare
providers, such as clinicians, hospitals, and clinics. Another category is health plans such as Health Management Organizations
(HMOs), insurance companies, and others. This rule also applies to healthcare clearinghouses that deal with sensitive health
information by billing services. A key point about HIPAA hip-uh] that leads to a lot of misconceptions is that the HIPAA Privacy
Rule does not require patient authorization to disclose information for treatment, payments, or operations, sometimes called
TPO [tee-pee-oh]. Probably the biggest misconception is when a patient is transferred from one institution to another and a
referring institution will not want to send the patient’s information because they believe it violates HIPAA [hip-uh]. But when a
patient is transferred, it is within the legal rights of everyone involved in their healthcare to disclose information to each other for
the care of the patient.
4
The Notice of Privacy Practices is essentially an oath of privacy – an interesting Web page devoted to oaths of privacy in
healthcare notes that physicians have been taking privacy seriously for quite some time. The Hippocratic Oath, or the Oath of
Hippocrates, developed in the fifth century BC, requires the physician to state “all that may come to my knowledge in the
exercise of my profession or outside of my profession or in daily commerce with men, which ought not to be spread abroad I will
keep secret and never reveal.” Likewise, the more modern Declaration of Geneva, usually considered to be the modern day
replacement of the Hippocratic Oath, states that, “I will respect the secrets which are confided in me even after the patient has
died.”
5
What is covered by the HIPAA privacy regulations? The privacy regulations cover protected health information, or PHI [P-H-I].
This is information that is collected from the patient and created by a covered entity, such as a healthcare provider,
clearinghouse or health plan. It is individually identifiable and electronically transmitted, although since almost all information is,
in some way put into electronic form these days, the HIPAA regulations extend to covered entities or business associates of the
covered entities.
For example, if a business works with a healthcare institution for whom the HIPAA regulations apply, then those regulations
apply to that business as well. De-identified information is not covered; issues with so-called de-identified information was
discussed in a previous lecture.
There are various levels of pre-emption; HIPAA trumps state law if state law is less protective of privacy and security, but state
laws that go beyond the HIPAA protections are not nullified by HIPAA and must be followed.
6
What types of identifiers fall under protected health information, or PHI [P-H-I, pee-aych-eye]? The HIPAA definition of PHI is
quite broad and comprehensive; the regulations define nineteen different types of patient data that can be PHI. Obviously, this
includes information like name and address but it also includes ZIP code, employer's e-mail address and telephone numbers,
photographic images, Social Security number, medical record number, and any web URLs associated with the patient. Finally,
any other unique identifying number, characteristic, or code is also considered PHI [P-H-I].
7
What are the key compliance areas for the HIPAA Privacy Rule?
• Healthcare organizations must post and inform patients of their Notice of Privacy Practices.
• There are issues related to authorization of the use of protected health information.
• There are rules that apply to business associates; these have been strengthened in the HITECH modifications to HIPAA.
• There are allowable disclosures, there are rules around marketing, and there are rules around physician and staff training.
• Finally, there are penalties for noncompliance with the privacy rules.
These areas will be discussed in the slides that follow.
8
One of the cornerstones of the HIPAA Privacy Rule is the Notice of Privacy Practices or NPP [N-P-P]. People who have
obtained healthcare in the US in the last decade or so will have come across an NPP and probably had to sign it. The NPP
states what the patient rights are. Under the HIPAA Privacy Rule, the patient has the right to know the privacy practices of a
covered entity, such as a physician practice or hospital. The notice should contain the uses and disclosures of personal health
information, including those that extend beyond TPO. The NPP should also have a description of individual rights, as well as
the legal duties of the covered entities. Part of the problem with these documents is that the readability of them is comparable to
what is seen in medical journal articles. In other words, they are highly technical and are probably beyond the readability of
eighty percent of the US adult population.
What are the physician requirements for obtaining the NPP consents? First, physicians must make a good-faith effort to obtain
at least acknowledgment of the Notice of Privacy Practices during the first provision of in-person service. If this is not obtained,
there is not a penalty, but a good-faith effort should be made to obtain the NPP.
9
Some other aspects of privacy practices are that they must be written in plain language, although later slides will show that this
is somewhat of an issue. Practices and organizations have to state that they reserve the right to change the Notice of Privacy
Practices. There must be some sort of complaint process by which a patient can challenge whether the privacy practices have
been inappropriate. Every practice organization must designate a privacy official in the office, essentially a chief privacy officer.
In smaller practices, this may be the office manager, or perhaps one of the physicians in the practice. Listed on this slide is the
link to the Oregon Health & Science University’s Notice of Privacy Practices, which has been translated into numerous different
languages.
10
The HIPAA Privacy Rule requires that an authorization be obtained for the use of PHI [P-H-I] for purposes other than TPO. The
covered entity is not allowed to condition treatments of the patient on whether or not an individual gives authorization for use of
PHI beyond TPO. When covered entities release PHI, reasonable safeguards must be in place to limit the use to the minimum
necessary standard, as defined by the statute from the Health and Human Services Office for Civil Rights.
11
Authorizations must include the following:
• The names of authorized persons making use of, or disclosing the information.
• The description of the information.
• An expiration date so the authorization does not last into perpetuity.
• Instructions on the patient’s right to revoke the authorization and how to do so.
• A statement of the specific purpose of use or disclosure.
• A signature and date by the patient.
12
HIPAA defines business associates and sets rules for their interactions with covered entities. These have been strengthened or
upgraded in the enhancements to HIPAA under the HITECH legislation. Business associates are agents, contractors, or others
hired to do work for covered entities that requires the use or disclosure of protected health information. These include billing
companies and vendors, software vendors, etcetera.
In the original HIPAA legislation, covered entities were only required to obtain what was called satisfactory assurances of
privacy protections from business associates. In the HITECH enhancements, these business associates are now required to
essentially meet the same rules as covered entities. For example, each business associate must sign an agreement with the
covered entity, stating that it will adhere to all of the HIPAA privacy rules. When business associates undergo a breach of
information, they are subject to the same breach notification rules under HIPAA. In addition, the definition of business
associates has been expanded and includes health information exchanges, personal health record vendors who work with
covered entities, and literally anyone who comes into contact with the covered entity’s protected health information.
13
What are some of the allowable disclosures outside of treatment, payment, and operations, or non-TPO? One area is research.
The Department of Health and Human Services has a publication that describes what is allowed and not allowed under the
HIPAA Privacy Rule. In general, authorization by the patient is required and there is usually a clause that allows information to
be used for research purposes in the Notice of Privacy Practices. However, there are some waivers that can be granted without
the patient's explicit approval, by either an institutional review board, also known as an IRB [I-R-B], or privacy board. The
Privacy Rule states that when this authorization waiver is used, there must be no more than a minimal risk of disclosure of
information and that the research could not be practically conducted without the waiver and without access to personal health
information.
There are some public health disclosures that are allowed so that information gathered by public health agencies can be
released. Information in specific areas such as child abuse, exposure to communicable diseases, and workforce surveillance
can also be disclosed. Some other areas where disclosure is permitted include information related to law enforcement, issues
related to decedents [dih-seed-nts] (those who are deceased), and cadaveric [ka-duh-vehr-ihk] tissue donation.
14
Marketing is an issue, although there are unforeseen issues when the rules are codified [kod-uh-fahyd]. Marketing is defined in
HIPAA as a communication about a product or service that encourages recipients of the communication to purchase or use the
product or service. Using PHI for marketing requires authorization of the individual.
Activities such as a healthcare provider recommending a treatment to a patient, encouraging a patient to keep an appointment
or to refill a prescription have been defined as outside the scope of marketing for providers. So when a provider recommends a
treatment, that is not considered to be marketing; likewise, notifying about appointments and prescription refills is not marketing
either.
15
Another aspect of the HIPAA privacy regulations is physician and staff training, which has been a substantial expense to
healthcare organizations. The regulation states that practices and organizations must designate a privacy officer, develop
policies and procedures, provide privacy training to the workforce, and develop a system of sanctions for employees who
violate the privacy law. There is sometimes frustration when individuals have to complete HIPAA training at each and every
organization they are associated with. For example, a researcher would have to complete similar HIPAA training at all of the
institutions that they collaborate with, resulting in a lot of repetition.
16
Obviously the HIPAA Privacy Rule must have teeth. In fact, the original HIPAA Privacy Rule was criticized for the relatively
modest penalties and minimal prosecutions that took place initially when the rule was launched. As such, the HITECH
enhancements increased the severity of penalties. Another aspect of the penalties is that the legal concept of “willful neglect”
can be applied when organizations are prosecuted for HIPAA violations. While the original penalties were in the range of ten-to-
twenty-five-thousand dollars, there is now a tiered penalty structure, depending on the severity of violation, with penalties
ranging from twenty-five-thousand dollars up to one-point-five million dollars.
17
One question that often gets asked is whether the HIPAA Privacy Rule truly protects privacy. There has been a lot of work on
different aspects of the HIPAA Privacy Rule, how well it works, how it can be strengthened, and so forth. Reviews in 2004, after
the privacy rule was launched, by the National Committee on Vital and Health Statistics (NCVHS) and the Government
Accountability Office, found that adherence was actually less problematic than many had anticipated.
The HIPAA Privacy Rule has now become part of healthcare delivery. One area where there have been many concerns is in
the performing of clinical research. Some studies have documented, for example, that finding and accessing patients for
research has become more difficult. Researchers themselves report more difficulty in doing their work and at the same time, not
believing that privacy is being substantially enhanced. This has led some organizations, in particular the Association of
Academic Health Centers and the Institute of Medicine, to argue for revisions to the HIPAA Privacy Rule to make research
easier.
There also have been some assessments of the HIPAA Privacy Rule with regards to public health. In general, public health
authorities are relatively satisfied with HIPAA and do not find it too onerous [on-er-uhs]. One approach that has been advocated
is for less emphasis on patient consent and more emphasis on a framework that makes it easier to share appropriate TPO, with
some modifications of how operations is defined, coupled with more rigorous restrictions on other uses, in particular marketing.
18
There are other modifications to the HIPAA Privacy Rule under the HITECH legislation. One area concerns breach notification.
Obviously patients must be informed, but when the breach exceeds 500 patients, the local media or local press, must be
notified as well as the Office for Civil Rights (OCR) of the Department of Health and Human Services. In fact, the OCR
maintains a web page that lists all breaches of more than 500 patients, which can be accessed through the link on this slide.
There are also some modifications that allow patients to put more restrictions on disclosures. For example, when patients pay
for medical care out-of-pocket instead of through their insurance, they can stipulate that information not be sent to payers.
There are also stricter rules for appropriate disclosures of treatment, payment, and operations. These must be tracked and
records maintained for three years. In addition, covered entities that have electronic health records have to either provide, or if
the patient requests, transmit protected health information in electronic format as the patient directs. Finally, one other clause
allows patients to opt out of fundraising appeals.
19
This concludes Lecture (c) of Privacy, Confidentiality, and Security. In summary, the HIPAA Privacy Rule restricts disclosure
of information not authorized by a patient. It has been enhanced by the HITECH Act. It is important to remember that patient
authorization for disclosure is not required for treatment, payment, or operations, or TPO. Finally, the HIPAA Privacy Rule
defines covered entities and business associates of those entities that also must adhere to the privacy regulations.
20
References slide. No audio.
21
References slide. No audio.
22
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.
Welcome to The Culture of Healthcare: Privacy, Confidentiality, and Security. This is Lecture (d).
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 lecture will discuss the Health Insurance Portability and Accountability Act (HIPAA) [hip-uh] Security Rule. There is a very
readable overview of the HIPAA Security Rule on the Centers for Medicare and Medicaid Services, or CMS, website called
Security 101 for Covered Entities, and there are a number of other documents that go into more detail on the specifics. Another
document provides guidance on security related to remote devices, such as handhelds and laptops. The terminology of the
HIPAA [hip-uh] Security Rule is aligned with the Privacy Rule, so that presumably one could identify areas of the security rule
that map back to the privacy rule.
The HIPAA [hip-uh] Security Rule aims to minimize specificity and to be what is called technology-neutral, to allow scalability,
flexibility, and the ability to adapt to changes in technology. As such, there are only thirteen required implementation specifics –
the remainder of what is listed in the security rule is addressable; that is, there are approaches that may or may not be
reasonable for a particular covered entity. As with the HIPAA [hip-uh] Privacy Rule, there are some modifications under Health
Information Technology for Economic and Clinical Health Act (HITECH [high-tech]) legislation for the Security Rule as well.
3
The general provisions of the security rule are that covered entities must ensure confidentiality, integrity, and availability of
electronic protected health information that is created, received, transmitted, and maintained by the entity. Entities must protect
against reasonably anticipated threats and hazards to such information by having a secure data center and using encryption
where appropriate. There must be protections against reasonably anticipated uses or disclosures that are not permitted or that
are required by the Privacy Rule. Entities must also ensure compliance by their workforce in implementing the security and
privacy rules.
The Department of Health and Human Services provides guidance on conducting risk assessments. One important feature of
this reference is that it helps determine whether something that is addressable should be addressed by the provider. If the
provider chooses not to address it, it should be documented in the risk analysis.
4
What are the required safeguards? They are grouped into three categories: administrative, physical, and technical.
• Administrative safeguards are related policies and procedures that are designed to prevent, detect, and contain security
violations.
• Physical safeguards include protecting facilities, equipment, and media where medical information is stored.
• Technical safeguards are implementing various technical policies and procedures.
The following slides show some features from each category, though these are not exhaustive. The overview article referenced
earlier further enumerates all of these safeguards, as do many other sources of information.
5
This slide shows the first part of the list of administrative safeguards from the Security 101 document. Perhaps the most
important of the required standards is a security management process that includes an analysis of risk, how risk is managed,
and any sanction policy. There also need to be procedures for addressing security violations as well as an overall information
system activity review. Additionally, there must be assigned security responsibility in the form of a chief security officer. The
security for the rest of the workforce is addressable as are aspects of information access management, with the exception of
the requirement that healthcare clearinghouse functions must be isolated for analysis with regards to security issues.
6
Continuing with the administrative safeguards, a set of addressable issues are security awareness and training for the
workforce. These are things like security reminders, protection from malicious software such as viruses and spyware, login
monitoring, and password management. All of these must be addressed. There needs to be a process in place for security
incident procedures. There also needs to be required elements of a contingency plan including what organizations do to back
up data, recover from disaster, and respond to emergencies. There also needs to be evaluation of the security process as it
pertains to the explicit agreements with an organization’s business associates.
7
The second category of safeguards is physical safeguards. Access to the facility is addressable, so the facility must have a
security plan with contingency operations, maintenance records, and other controls. There are requirements for workstation
use, physical security of the workstation and dealing with devices and media. There are explicit regulations for how media
containing protected health information is disposed of or reused. There are also addressable issues on accountability for media
and its backup and storage.
8
The third and final category is technical safeguards. This includes issues like access control. The specifications require that
every user of a system with protected health information is required to have a unique, personal, user identification and there
needs to be emergency access to information when appropriate.
One addressable specification is automatic logoff. Institutions must decide how quickly they want automatic logoff; in
operational settings different groups have different ideas on the length of time before automatic logoff should occur.
Encryption and decryption are listed as addressable specifications, probably because the developers of the HIPAA [hip-uh]
security regulations realized that the technology would be changing and that people within organizations would be able to make
the best decisions on specific encryption and decryption needs.
Audit controls are required under the technical safeguards while integrity mechanisms that authenticate protected health
information are addressable. Authentication of the individual and/or their institution is a required specification; transmission
security is addressable.
9
There are other regulations in the HIPAA Security Rule, some of which have been strengthened in the revision of HIPAA [hip-
uh] under the HITECH [high-tehk] legislation.
Business associates, even in the original rule, are required to implement safeguards to protect a covered entity’s protected
health information. Likewise, business associates must ensure that organization’s agents and subcontractors meet the same
standards and report back to the covered entity any security incident. Business associates are also subject to the breach
notification rules when the number of patients exceeds 500, in terms of reporting to the local media and to the Health and
Human Services Office for Civil Rights.
There are also regulations regarding the documentation of entity security practices and procedures that must be maintained for
six years. The documentation must be made available to those responsible for implementing security and it must be reviewed
and updated periodically.
The meaningful use criteria of the HITECH [high-tehk] Act also specifies various government encryption standards, discussed
in a previous lecture, such as advanced encryption standard (AES), the standard for encryption and decryption; transport layer
security (TLS) and Internet Protocol Security (IPsec) [eye-pee-sehk] which cover how information moves across networks; and
the latest secure hash algorithms (SHA-2) [S-H-A-two], which verifies that information is transmitted intact from one point to
another.
10
In bringing this discussion of privacy and confidentiality and security together, what can be concluded? Clearly the ongoing
breaches of data are getting worse, so serious attention needs to be paid to privacy and security issues – they are not to be
taken lightly.
However, it is also probable that complete security of all health information is impossible. Too many people access information,
too many of the applications are not as robust as they could be, and, as discussed in a previous lecture, security is a trade-off
with ease-of-use.
As such, there needs to be a happy medium where the desired level of security can be attained with the benefits of health
information technology, such as error prevention and improved quality.
Another question that comes up is, will the theoretical (and some real) concerns about privacy and security be tempered
somewhat when society sees more of the benefits of health information technology?
A final question might be, would other societal changes lessen the impact of the problem--changes, for example, in the legal
system in terms of discrimination being more rigorously prosecuted, in the healthcare finance system, and in the insurance
system to prevent loss of health insurance, particularly when switching jobs?
11
This concludes Lecture (d) of Privacy and Security. In summary, the HIPAA Security Rule aims to be actionable but flexible.
Its rules are either required or addressable and fall into three categories - administrative, physical, and technical.
12
This also concludes Privacy, Confidentiality, and Security. In summary, the major aspects of privacy, confidentiality, and
security of health information were reviewed and the HIPAA Privacy and Security Rules were explored. Privacy is the right to
keep information to one’s self, whereas confidentiality is the right to keep information about one’s self from being disclosed to
others. Security in this context is the protection of sensitive health information. There are many technologies to maintain
security, but human vigilance is also required. Finally, the HIPAA Privacy and Security Rules spell out the requirements for
healthcare organizations and those with whom they do business in the US.
13
References slide. No audio.
14
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.
© Johns Hopkins University.
Welcome to the Introduction to Information and Computer Science: Security. This is Lecture (a).
The component, Introduction to Information and Computer Science, provides a basic overview of computer architecture; data organization, representation and structure; structure of programming languages; networking and data communication. It also includes basic terminology of computing.
1
The Objectives for this unit, Security, are to:
• List and describe common security concerns • Describe safeguards against common security concerns • Describe security concerns for wireless networks and how to address them • List security concerns/regulations for healthcare applications • Describe security safeguards used for healthcare applications
2
This lecture will discuss first why all users should be concerned about the security of computers, data, and networks.
The potential for lost, stolen, or compromised data is a real concern. When data has been compromised, somebody has seen information they should not have seen, or somebody has accessed information and then made unauthorized changes to it. Identity theft and impersonation are also significant concerns. For example, somebody could steal a user’s identity and then impersonate the user by using his or her credit card. Network security and data security breaches can also lead to business downtime. If a company’s Website (for example, Google, Amazon, or eBay) were not secure, think of the ramifications of a shutdown of their Websites for part or all of a business day. Consider the financial repercussions for that business and its customers.
Finally, consider blackmail. Confidential personal data that is not secure may end up in the wrong hands, leading to threats of disclosure unless certain actions are taken, such as paying large sums of money to the person who wrongly accessed the data.
3
Common threats to security include malware [mal-wair], defined on this slide. According to Wikipedia, “Malware, which is short for malicious software, is software designed to infiltrate a computer system without the owner’s informed consent.”
Computer users most likely know how this occurs through experience or indirect experience. Individuals may have inadvertently clicked on a file which in turn forces an installation program to launch and install something on a computer. Although the user didn’t approve the installation, it just installed anyway. Or maybe the user has visited a Web page and clicked on a link or button on the page that automatically installed software on the computer. All users find this very frustrating and must be aware and mindful when opening attachments to emails, open files, and clicking on items on various Websites.
Types of malware include Trojans, viruses, hoaxes, worms, phishing attacks, macro viruses, and hackers. The next few slides will examine each of these in the following slides.
4
A Trojan Horse is a malware program that usually impersonates a known good file installed on a computer, where the Trojan Horse replaces the known good file with itself. This is more difficult to do with critical updates and the built-in security measures implemented in Windows operating systems, but it still happens. The Trojan Horse gets its name from the Greek Trojan Horse myth. The Trojan does its dirty work on a certain date, through a user action or even on command.
Most computer users have probably heard stories of hackers creating programs, installing them on computers, and then waiting for a date―or a certain event―to occur. When that date or event comes to pass, the program launches itself and then destroys certain files on the computer, or even all of the files on the computer. Trojans can destroy or copy data, install adware and other programs, or even install a browser toolbar. They can also record keyboard key strokes and send this information to an attacker, who can later use the information to further scam and attack a computer or person.
Lastly, Trojans can scan computer ports. Computer ports can be likened to telephone extensions on a phone system. A computer provides thousands of ports for communication purposes. Ports are used by browsers, installed applications, and the operating system for communication purposes. A Trojan can scan a communication port, look for information to pass through the port, and then send that information to an attacker.
5
A virus is a computer program that can harm a computer and make it inoperable. Indeed, some viruses disable important operating system functionality such as the ability to back up a hard disk. Some viruses will even work to reformat a hard disk.
Some viruses are only an annoyance and usually don’t make copies of themselves on other computers; they just act. Removing a virus usually cleans the computer, assuming it is the only virus on the computer. However, some viruses do make copies of themselves and if one copy of the virus is removed, the remaining copy replaces the removed virus, making it difficult to clean the system. Often, the best response is to format the hard disk and reinstall the operating system or restore from a virus-free backup. Sending a virus by an email usually does replicate the virus because all it takes is for someone to click on an email to give it focus, which can launch the virus’s program code.
In 2008, the Fun.exe [fuhn-dot-E-X-E] virus spread itself via email throughout the world and was very difficult to remove as it made millions of copies of itself on infected computers.
6
Macro viruses usually infect Microsoft Office files and install themselves when users click or give focus to Microsoft Office files. A macro is a small program which is usually written in Visual Basic for Applications; known as “VBA.” In fact, all Microsoft Office files have the ability to have VBA code written inside of them, for functionality. VBA code in itself isn’t harmful; it is the people who write programs for bad purposes who can cause harm.
Macro viruses, as mentioned previously, spread when users click files in which the macro virus resides. Note that most people would be totally unaware that a virus is inside a file because its actions are silent. Clicking on an infected file typically provides no immediate indication that something bad has launched.
Macro viruses may also delete files and disable Windows functionality on an infected system.
Again, it is important to be aware of the risks when receiving files and/or emails. If the sender is not known or trusted, it is best not to even click on the email and attachment because that simple act will give it the focus needed to do harm.
Some email programs quarantine suspicious email, preventing it from doing harm to the system, regardless of whether the user clicks the email or not.
7
Personal information attacks are accomplished through an activity called “phishing.” Although it is pronounced like the word “fishing,” it is spelled with a P-H rather than F.
Phishing is an attempt to trick a user into revealing personal information to an attacker so that they can impersonate the user. The attacker “phishes” for information about the user. For example, the attacker will an email that appears to be from the user’s bank, from eBay, or even from Amazon, asking the user to log in to verify a transaction or to verify a username and password. Never respond to such an email request. Banks or financial institutions―indeed, any reputable Internet merchant―would never send an email asking for such actions. Contact the institution being impersonated by an attacker and report the incident immediately so that they may investigate.
8
In fact, when clicking a link that appears in a phishing email, the Website that opens looks as it would be expected to look. For example, if it came from the user’s bank, the Website that appears looks mostly like that bank’s Website. But, a careful examination of the email and Website often reveals spelling errors or slight variations in colors, alerting the user to the fact that this might be an attack and not an authentic communication.
Most email software such as Microsoft Outlook includes the ability to monitor for phishing activity and then move the suspected email to a non-functional folder called “Junk Email.” The email is quarantined and isolated from the rest of the computer system and is not actionable as long as it remains in the Junk email folder. Be wary of moving email from the Junk email folder to the Inbox because doing so takes it out of quarantine.
9
A worm is a program that works to create a lot of network traffic. Note that some worms are not malware but are put in place by network administrators to crawl the network searching for information and to report activity.
Worms that are malware, though, usually work to replicate themselves, and they make the network unusable by continuously putting excess traffic on the network. This would be similar to every person in a large city leaving work at 5:00 p.m. and immediately jumping in their cars and getting on the same highway. That is essentially what a worm does.
An example of a notorious malware worm is the “I love you” worm. In May of 2000, the “I love you” worm successfully attacked millions of computers. When users clicked an email attachment called “I love you,” the worm made copies of itself and sent the copies to every contact that was in each email recipient’s contact list.
10
Hoaxes are usually harmless attempts to convince a user of something that is not true. They usually come in the form of an email. Some hoaxes, which are harmful, invite users to send money to someone in another part of the world. Others ask users to contribute to find missing children.
In some cases, emails requesting funds for missing children are valid, but in most cases they are not. Unfortunately, there are always stories of people who respond to email requests for money from another part of the world and are scammed out of their money. For example, an email may read “Send us $10,000 and we’ll send you $50,000.” It may be hard to believe, but people actually fall prey to these types of scams. If these types of attacks were not successful, they would cease to exist.
If an email appears to be a hoax, the careful user should use a search engine to determine whether the email’s message is true. For example, if the subject line of the email contains, “Missing Child” in some city, for instance, enter the text of the subject line in a search engine, adding the word “hoax” to the end. The result set will usually indicate whether the email is a hoax. If users receive this type of email at their place of work, they should report it to their network administrator immediately.
11
It is important to use trusted Internet sites to detect hoaxes. Therefore, when running a search, look for results that are from “Snopes” or “Urban Legends Online,” as indicated on this slide―to name two reputable sites that will display a picture or an image of the email on their site and share whether their investigation reveals it to be a hoax.
Never forward email chains, which are typically hoaxes, without verifying their source and identifying them as true.
12
Hackers and how they operate is our next topic of discussion. Hackers are typically people who work to break a computer’s security. Sometimes they do it to destroy data or to steal data on a computer. Other hackers just want to break into a computer because they can. One thing that hackers do is employ the use of something called a “packet sniffer,” which can read Internet traffic. Wireshark is a free packet sniffer. It is also known as a protocol analyzer software tool that can display unencrypted network traffic on a screen so that anyone can read it. For example, if a hacker ran a packet sniffer and “sniffed” the network from which a user had sent an email, the hacker would be able to see the email in clear text on their screen.
Therefore, emailing usernames and passwords or storing them in an email may make them available to a hacker. Hackers like to use this information to install malware in the form of adware, which places ads on a user’s screen (an annoyance that makes a computer almost useless) and spyware, which reports on sites that users visit and then perhaps even reports on information that the user has stored on his or her computer.
Some hackers try to infiltrate a computer system by guessing usernames and passwords. It is incumbent on computer users to never use “easy-to-guess” passwords such as name, birth date, pet’s name, and so on. Also, users should change default usernames and passwords on wireless routers and on computers so that hackers are unable to easily guess them and gain access to the device.
13
This discussion leads to the topic of network security. According to Wikipedia, “In the field of networking, the specialist area of network security consists of the provisions and policies adopted by the network administrator to prevent and monitor unauthorized access, misuse, modification, or denial of the computer network and network accessible resources.” In simpler terms, network security is about the rules that both corporate and home network administrators set up for the use of equipment, software, and data―and our adherence to those rules. The use of computing devices revolves around authentication, authorization, and providing permissions for the use of network assets. In other words, if a user cannot validate identity, then he or she cannot gain access to the network, its equipment, or its data. This will be discussed in more detail in the following slides.
14
Authentication is essentially the beginning of network security. In an authentication process, a user provides a valid username and password, or “credentials.” When the user enters credentials, the computer authenticates the credentials against its user account and password database. In other words, if a user logs in successfully, their credentials matched the information in the database and the user is authenticated.
Servers typically authenticate users through an “active directory database” which stores information about all users, user groups, computers, printers, and other objects that are managed by the server. Therefore, an authenticated object (note the term “object”) is a user with a proven identity, a computer program that a server is able to positively identify, or a server that other devices (for example, servers, computers and printers) are able to positively identify.
15
The next step after authentication is authorization. These terms might seem difficult to grasp at first, but they will become familiar upon repetition. Authorization means that the computer indicates precisely what the user―or more technically, what the object can do (for example, allowing a user to print files using specified printers).
Authorization might also include gaining access to specified network drives. For example, to allow users to store files on a server, the network would first authenticate and then authorize the users, granting read and write access to a specific network drive. Authorization means that a user may be able to change and/or view documents and folders on a specific drive or use company email. Further, these actions are usually recorded for audit at a later date. This setup indicates that the user can prove that it is authenticating and then authorizing users to perform these actions in our network.
Corporations, small businesses, and medical facilities may be audited to prove that data is being safeguarded. Failing such an audit might cause a business to lose its license, incur a fine, result in criminal prosecution, or even shut down.
Again, note the use of the term “objects,” which is used often in this discussion and used interchangeably with the term “users.” Users, computers, printers, scanners, and other things are referred to as “objects” in the IT world. In reality, “objects” are authenticated and authorized on a computer network.
Other examples of objects, in addition to what we’ve mentioned on previous slides, include tables in a database, a text field on a Web
16
form, a file, a folder, a hard disk, and more.
The future health informatician will use this term quite a bit in future classes and in everyday work.
16
To summarize what has been discussed in the last few slides:
One of the first things that can ensure network security is authentication, which is where a user’s credentials (made up of a username and password) are authenticated.
Once a user has been authenticated against the Windows-based computer or server’s database, then the user can be authorized. Authorization includes associating the user account or other type of object, with permissions.
Part of the process of authorizing a user is determining the permissions applicable to that user account―also known as permissioning. Permissions indicate actions an object can or cannot perform on a computer and/or within a network. Two types of permissions are typically used. The first is a “sharing permission,” which allows one object to connect to or use another object over the network.
For example, assume that a user and his sister each own a computer. The user stores a number of family pictures that he has taken digitally. He decides to create a folder to share the pictures with his sister. From her computer, the sister connects to his computer and then gains access to that shared folder. This is accomplished through “sharing permissions.” In addition to sharing permissions, for his sister to successfully access the shared folder, the “NTFS [N-T-F-S] permissions” must be configured.
17
NTFS is the New Technology File System and applies to all current Windows operating systems. In reality, NTFS is no longer “new,” as it has been around since approximately 1993.
NTFS permissions determine what one object can or cannot do to another object. For example, will a user allow somebody to have access to pictures and then delete them, or will the user only allow that person to view it? Will the user allow them to change the picture’s name or allow them to add new pictures to the folder? NTFS permissions, properly applied to folders and/or files, determine whether any of these actions can be performed.
This discussion of authentication, authorization, and permissions has only scratched the surface. Permissions are a complex topic.
17
Sharing and NTFS permissions on a Windows-based computer work together. This slide examines in a little more detail how this works. For example, the user creates a folder on his computer so that his sister can copy pictures stored in that folder. Next, he shares the folder and sets her “sharing” permissions to “read.” Lastly, he sets NTFS permissions to “read” so that she can view and copy pictures. Without this type of configuration, his sister will not be able to view or copy files from his computer.
Of course, there are other operating systems, or OS, besides Microsoft Windows; these offer similar mechanisms to protect devices and files. For example, Linux-based operating systems also provide for usernames and passwords for authentication and authorization and file-based permissions. One current Linux file system is ext3 [E-X-T-three], or the third extended file system. There are a large number of file systems in use today.
18
Examine the partial screenshot of a desktop on this slide, where a folder called “Pictures” appears in the top-left side of the screen. From the context menu that appears, the user will right-click the folder and select “Properties” to view the window “Picture Properties” that appears on the right side of the figure.
Note that in this slide, a user previously clicked the “Share” button, which is slightly gray in color, indicating that the folder is shared. This is confirmed by the text, “Pictures Shared,” to the right of the yellow folder icon in the Pictures Properties dialog box. Clicking the “Advanced sharing” button allows the configuration of sharing permissions for this folder.
Examine some of the detail shown here on the screenshot. The name of the computer is “John-PC.” The name of the shared folder is “Pictures.” With proper configuration, his sister can open this folder by opening any window or browser and typing the following text in the address line: \\john-pc\pictures.
19
The “Pictures Properties” dialog box is still open. Click the Security tab to configure NTFS permissions. “Group or usernames” are listed in what is called an “access control list” or “ACL.” In the ACL shown is a group or username of “administrators,” meaning that user accounts that are members of the Administrators group on this computer have full control over this folder and its contents.
This means that a user who is a member of the Windows Administrator’s group can do anything to this folder and to its contents. “Anything” means that they can view, add new files, delete existing files, change file names, and create subfolders.
To make changes to the group or usernames listed, click “Edit” and then add a new username or group to the access control list for this folder.
20
This concludes Lecture (a) of Security. In summary, this unit listed and described common security concerns.
21
References slide. No audio.
22
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.
© Johns Hopkins University.
Welcome to the Introduction to Information and Computer Science, Security. This is Lecture (b).
The component, Introduction to Information and Computer Science, provides a basic overview of computer architecture; data organization, representation and structure; structure of programming languages; networking and data communication. It also includes basic terminology of computing.
1
The objectives for this unit, Security, are to:
• List and describe common security concerns • Describe safeguards against common security concerns • Describe security concerns for wireless networks and how to address them • List security concerns/regulations for healthcare applications • Describe security safeguards used for healthcare applications
2
This lecture will discuss that when considering threats to data and protecting data, it is important to identify threats to network security and devise a mitigation plan for those threats before allowing data onto a network. Mitigating threats will decrease the effect of bad things that may occur. In other words, users can identify some bad things that may eventually happen and want to ensure that those things will have minimal impact on data and other company assets.
Mitigating threats can include creating a security policy; authenticating users; using firewalls; installing antivirus software on all devices; using an “intrusion protection system” or an IPS [I-P-S] device in the network; encrypting communications; and finally, auditing adherence to security policies.
3
Most security policies contain provisions related to security definition. In other words, a security policy defines the term “security” for the organization and how to address identified concerns.
Enforcement defines how people are expected to obey the rules listed in a policy. Policies also address user access to the network, devices, software, and data; password management; email and Internet use; antivirus software use; backup and recovery procedures; intrusion detection; auditing; and other topics.
4
Users typically input their credentials in the form of a username and password. In this case, authentication involves something the user knows. Authentication can also involve something that most people have, for example, a smartcard or a badge, or something that is a part of the human body such as a fingerprint, a retinal scan, or a palm print.
5
Combining authentication types is known as factor authentication. Three levels of authentication factors are used to enforce security policy rules today: one-factor, two-factor, and three-factor.
One-factor authentication has already been discussed, where a user enters credentials or username and password. This is the simplest authentication process.
In addition to a username and password, two-factor authentication requires another authentication type such as a smartcard or a fingerprint reader. With three-factor authentication, all three authentication types are required―a username and password combination, a smartcard or badge, and some kind of a biometric reader, like a fingerprint reader.
6
Another way to mitigate security threats is to implement the use of a firewall in the network.
A firewall is software or hardware that blocks unauthorized communication to and from a computer or from one network to another network. The Windows operating systems (OS) provides what is known as the “Windows firewall,” which should almost always be enabled to protect a home or small office desktop computer system.
Routers have basic firewall protection built into their OS functionality. Most ISP routers act as firewalls. Therefore, if a home uses DSL or some other type of Internet access that is always on, an Internet attacker will be unable to infiltrate a home network and attack a computer because the ISP device will act as a firewall that blocks that communication from entering the network.
A firewall inspects each piece of communication and then permits or denies that traffic based on its configured rules. For example, a user will not be able to connect to her brother’s PC to copy shared photos unless her brother’s firewall is configured to allow that communication.
The Windows firewall and an ISP router will adequately protect a home office. However, larger networks require more extensive protection through the use of a firewall device. For example, Cisco’s ASA [A-S-A] 5500 [fifty-five-hundred] Series Adaptive Security Appliance provides a firewall and many other protections. The price (as of December 2011) was approximately $2,500. More robust firewalls cost even more.
7
This slide contains a screenshot of the Windows 7 firewall. Starting at the middle, top, notice the text that reads, “Help protect your computer with Windows firewall.”
The Windows firewall can prevent hackers or malicious software from gaining access to a computer through the Internet or a network. The green shield indicates that the firewall is functioning. The firewall is set to block all connections to programs that are not on the list of allowed programs. The firewall can also be configured to allow a program or a feature through the Windows firewall. This is known as “punching a hole in the firewall.” Looking at the center of the slide, note that the Windows firewall is currently configured to Notify me when Windows firewall blocks a new program. When this computer is connected to a “public network” such as networks in public places such as airports or coffee shops, the Windows firewall state is “on.” In such locations, incoming, unsolicited connections are blocked.
8
Requiring all devices to have antivirus software installed is yet another way to mitigate security threats. AV [A-V] software detects and removes malware [mal-ware]. It can also protect against adware and spyware being installed on systems.
AV software requires current virus pattern definitions, which means that as new viruses and new attacks become known, the AV software vendor updates the ability of AV software to catch and then quarantine malicious actions. Updates are obtained by subscription and cost approximately $50 per year.
AV software searches computer files for “virus signatures.” AV software is able to read a computer’s files and determine if a file is virus-infected or not. If the AV software finds what it sees as a virus, then the AV software quarantines the file.
AV software also monitors for malicious computer activity. For example, if a running program attempts to perform an unfamiliar action, the AV software will stop and quarantine that program and its action or actions. For example, would a user expect Microsoft Excel to start a search in a folder for files or would that user expect it to communicate over the network to a Web site without the user being part of that process? Typically, the answer would be, “No.” AV software should stop that from happening.
9
Common antivirus software vendors include Avast! [uh-vast]; AVG Free [A-V-G-Free]; HouseCall; Kaspersky [kas-per-skee]; McAfee [mack-uh-fee]; and Symantec [sih-man-tihk]. It is important to perform a Web search for antivirus software vendor rankings before investing in one of the options. Many computer magazines annually rank AV vendors, which helps with the decision process.
It is wise to pay for reputable antivirus protection software that includes automatic updates to virus protection pattern files rather than rely on free antivirus software that may be on your computer. The cost of $50 or $60 a year is nothing compared to the pain of suffering the loss of personal data on a computer or even worse attacks.
10
In corporate or healthcare environments where security of data is paramount and it cannot be compromised, employing a hardware device known as an “intrusion protection system” or an IPS is advised.
An IPS is similar to a firewall but provides much more protection. The IPS monitors all network traffic in real time for malicious activity. Think of what that means. It examines every packet passing through the network and then determines if that packet has bad intent. The purpose of the IPS is to stop intrusions and then alert network administrators to the threat.
On this slide is an image of a Cisco Secure Intrusion Detection System, an enterprise scale, real-time, device. “Real time” means that the device examines traffic as the traffic occurs, not by capturing the traffic and examining it later. This device is designed to detect, report, and terminate unauthorized activity throughout a network. Its cost is approximately $700. Would a home user need or want something like this? Probably not, but it is used in larger environments.
11
Another mechanism at our disposal to improve network security is encryption. Anybody who has any knowledge of the “Three Stooges” knows that they used to communicate verbally using something referred to as “Pig Latin,” where they would change around the letters of a word–believing that only they would be able to understand what they were saying.
Well, from an electronic standpoint encryption means that communication is unreadable to unauthorized viewers.
Encryption uses electronic private and public key sets. In other words, each piece of encrypted communication has its own private and a public key set. This means that if a user encrypts a file on his or her computer, the user possesses what is known as the “private key.” To allow someone to be able to decrypt that communication requires providing them with the set’s public key since only those two keys are able to decrypt this specific piece of communication.
Another example is email encryption. For example, a user might encrypt an email sent to a doctor by using a private key through the installation of a program in the email client. For example, a Microsoft Outlook private key encrypts outgoing email. The email sent to the doctor includes its public key so that the doctor can read the email.
All communication encrypted using a private key through the email client is protected, and only those in possession of the public key can read it. Further, a medical office might encrypt data stored on a server’s hard disk using its private key and allow the patient to decrypt the
12
data using the medical office’s public key.
12
Encryption may seem difficult to understand, but all encryption processes are basically the same for all types of transactions.
On the slide is a screen shot of a Microsoft Excel 2010 document where a user has clicked the File menu, clicked Info, and then clicked “Protect workbook.” Notice that one of the entries in the list is to “Encrypt with password.” Encrypting a document is essentially scrambling the contents. When a file is encrypted, the only way its contents can be read is to enter the required password, which decrypts the file.
Any Microsoft Office file can be encrypted, or password-protected, in this way.
13
Consider an example where a user creates, encrypts, and closes a Microsoft Word document to record daily diary entries. Then the user logs out; next, her brother subsequently logs into the computer. Looking for new pictures, he accidently locates the document, which is entitled “My Diary.” Curious, he double-clicks the file to open it.
When he double-clicks the encrypted document, a password dialog box displayed at the top of the slide opens, indicating that the document is protected, or encrypted, and that a password is required to open it. Next, he types the word “password” and clicks OK. Well, if that is not the password that the owner of the document used to encrypt the document, the dialog box shown at the bottom of the slide appears, reporting that “The password you supplied is not correct...” Therefore, if the user’s brother―or any other potential viewer―is unable to supply the correct password, the document cannot be opened. In fact, if the owner of the document loses the password, he or she also will be unable to open the document.
14
Any file or folder on a Windows-based PC can be encrypted.
To encrypt an existing folder, right-click it and select “Properties” from the context menu. This opens the properties dialog box as displayed on the left side of the slide. Next, click “Advanced.” Click, “Encrypt contents to secure data,” to encrypt all of the documents in the folder. Next, click OK to apply the setting to the folder and all of its contents.
Subsequently, all files placed in this folder will be encrypted. This means that files in this folder can only be viewed when the user is logged into the computer with the username and password used to encrypt the folder. All other user accounts will receive an “access is denied” message when they try to open any file in the encrypted folder.
15
Even if all of these mechanisms were established to protect a company’s network and data, it is still necessary to regularly ensure that people and departments are following the rules outlined in the documented security policy. Therefore, it is important to audit security policy practices. An audit reveals whether an organization is doing what they said they would do.
For example, if nurses are instructed to log off a nursing station when they leave that station, how is that process enforced? An auditor would observe the nurses and then record their actions. Another example is ensuring that a database server is kept up-to-date with critical updates. An audit of the database servers update records would determine when critical updates to the OS or other software installed on the server were issued and then when they were actually applied to the server.
Other questions to consider are: Is all access of medical records being logged? Are back-ups being done regularly and stored according to the security policy? For example, many organizations will back up hourly and then order that the backup tapes be stored in another building. Is this being done? Do employees adhere to email policies?
16
Additional steps that companies can take to improve the security of their assets and data include educating employees.
Employees should be taught to never open unsolicited email attachments. In other words, if an employee receives an email with an attachment, the employee should not click the attachment, even once.
Users should be taught to lock their display screens when they are not sitting at their desks. For example, if an employee gets up to get a drink of water, then that employee should press “Control-Alt-Delete” and then press “Enter,” which locks the computer from unauthorized use. In addition, users should be taught to never click pop-up ads while surfing. For example, an ad may pop on the computer’s screen that reads “click here to scan your computer.” If the user clicks anywhere in the pop-up window, including the red X at the top right corner, it installs adware, spyware, or even a virus on the computer.
Another step towards good security is to educate employees so that they report strange activity to network administrators— encouraging them to be aware of unusual behavior on their computer, for instance, or if they receive a call from somebody asking for their password, indicating that they work for “our IT department.”
Finally, only authenticated and authorized use of software should be permitted, and the software applications should contain rules that record who used the software. For example, a company may have a customized database program that allows users to enter patient
17
information in a database. They later learn that information recorded in a patient’s record was not entered correctly. The software should prove beyond a doubt who entered that data, possibly revealing a training issue.
When security policies prove that a user or program performed an action beyond a reasonable doubt, this is known as non-repudiation. Therefore, the user cannot deny having entered data in a database, removal of an item from inventory, or any other action.
17
Password policies usually revolve around the subject of password complexity.
A complex password is usually at least six characters in length, and includes at least one uppercase character, one lowercase character, one number, and one special character.
In addition, a password policy may state that passwords must be changed every 90 days, and that the current password cannot be used for 365 days. In addition, a policy might require that passwords are never to be written on paper.
Hackers know that if they want to find a user’s password, they should look for sticky notes on the monitor or under the keyboard. They will not hesitate to lift the keyboard and turn it over. Hackers are quite aware of the myriad ways people attempt to remember their usernames and passwords, especially writing them down and hiding them. Never do this in any environment in which security is essential.
Implementing a domain-based network environment is another good security measure. In a domain-based world, a server, which is a computer installed with special OS software, manages users, devices, software, and domain policies. The server manages all objects that are part of its domain, and the server enforces rules where network assets can be used only by objects that are part of the domain that the server manages. Think of a domain as a gated community where the gate around the community represents a guarded geographical location.
18
Therefore, a server guards its domain and doesn’t allow any other object to enter without permission.
In a domain-based network environment, it is good practice to restrict the number of network, or domain, administrators. Only people with the need to perform network administration should possess such privileges.
18
When security professionals examine an environment and look for things that they can do to enhance security, they usually look for what’s known as “low-hanging fruit.” In other words, they identify simple things that they can implement to improve the security of data and assets. Physical security of data and network assets refers to measures such as bolting servers to some type of a structure, like a floor, in a locked room. Only authorized access is allowed to the locked room.
In some environments, for example a hospital setting, there may be a number of servers that are all running 24 hours a day. Assume that there are 100 running servers. All of those servers are password-protected and their screens locked. If the network administrator wants to gain access to that server to perform some administrator task, the administrator uses a Windows program named “remote desktop” to access the server. Using this program, administrators can connect to the server from their desk, maintaining the server’s physical security.
In addition, servers and other devices should be UPS [U-P-S] and power-surge protected at all times to protect the integrity of the data. Yet another security measure is to validate all data that is entered into any database. For example, if a database name field contains a patient’s first name, what would happen if a data entry clerk accidentally entered an ampersand, a number, a space, or a period in the field? Would that action cause the database to corrupt the record, or stop functioning all together?
19
In this case, a hacker may be able to gain control of the database and steal its data. With data validation, data is tested for expected and unexpected field entries. This means that if a data entry clerk is expected to enter a character-based name in a database field, the data should be tested for non-character-based names, to ensure the integrity of the data in the database.
Then, if the data that was entered in a database form field is invalid, for example, if a name contains a number, the entry is probably invalid and a message would appear on the screen, asking the clerk to enter the information again or verify that the name actually does contains a number.
19
This concludes Lecture (b) of Security. In summary, this lecture:
• Described safeguards against common security concerns • Described security concerns for wireless networks and how to address them
20
References slide. No audio.
21
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.
© Johns Hopkins University.
Welcome to the Introduction to Information and Computer Science: Security. This is Lecture (c).
The component, Introduction to Information and Computer Science, provides a basic overview of computer architecture; data organization, representation and structure; structure of programming languages; networking and data communication. It also includes basic terminology of computing.
1
The objectives for this unit, Security, are to:
• List and describe common security concerns • Describe safeguards against common security concerns • Describe security concerns for wireless networks and how to address them • List security concerns/regulations for healthcare applications • Describe security safeguards used for healthcare applications
2
This lecture discusses wireless networks. It is impossible to have a discussion about security without mentioning wireless networking. Wireless networks are unsecure by their very nature, because typically they are open, allowing anybody to connect.
Wireless networks include home networks and including airports, coffee shops, hotels, city-wide wireless access points or WAPs [W- A-Ps]; college campus environments and hospitals.
Indeed, wireless networks are everywhere in the medical environment because doctors and nurses tend to move from room to room constantly using wireless communication using handheld devices that are not connected to a wire.
3
Therefore, wireless security starts with the configuration of a WAP. An example of a WAP is the wireless router that many computer users have in their home. WAPs in a corporate environment are much more robust than those used at home.
To configure a WAP for security requires changing the default password and configuring the router’s SSID [S-S-I-D]. Wireless routers are shipped with default passwords, meaning that anyone can look up the default password for a router on the Internet.
SSID is an acronym for the term “Service Set Identifier.” Routers need to be configured so that they do not broadcast the SSID; this security configuration will make it harder for others to find and connect to the wireless network.
Good security requires WPA2 [W-P-A two] authentication. Users may be familiar with WEP [wep], the “Wireless Equivalency Protocol,” an older technology that should no longer be used. WPA Version 2 protection is a much better choice through which to restrict access to known devices.
Administrators should program MAC [mack], or media access control, addresses into the access point’s configuration. All network interface cards, or NICs [nicks], have their own address (the MAC). Modern WAPs allow administrators to allow only recorded MAC addresses to authenticate themselves on the Web and then communicate wirelessly.
4
Another thing that administrators can do to improve security on a network is to install a “digital certificate” on sensitive devices. After this installation, only devices with known and valid certificates can communicate on the network. This type of a setup requires the use of special certificate servers, something not usually found in small offices because of the server complexity. Look at the screen and locate the green image on the bottom showing a partial browser address bar with a valid bank certificate as shown in Internet Explorer Version 8. Starting from the left, the address indicates the Umpqua Bank, an Oregon bank; moving from the left to the right, there is a gold lock. Clicking the gold lock will allow a user to view the bank’s certificate, who issued it, and how long it is valid.
Any user can try this by opening a browser and looking at the screen that appears when connected to a bank, especially the bank’s logon screen. Depending on the browser used, a green address bar and the gold lock will appear. The gold lock proves that the browser validated the bank’s certificate with the certificate’s issuer, which allows access to the account.
Security with certificates is a very complex topic. That’s why most colleges have full security courses.
Certificates can be used in wired and wireless environments. In many cases, all WAPs have certificates installed so that the organization determines which access points are allowed to authenticate users.
Every time that a user opens a browser and performs online banking, the browser checks the bank’s certificate to ensure that it is
5
valid. And again, in Internet Explorer 7 and 8, the browser address bar turns green when the certificate is valid. If the address bar turns red, the certificate is invalid; the user should close the browser window and not connect to that site.
5
Wireless device security includes smartphones and other portable devices. In hospitals, nurses and doctors communicate wirelessly, using small handheld devices. All portable devices that connect to the network need antivirus protection software installed, each with current antivirus patterns. In fact, no one should use a portable device for sensitive transactions, such as banking and viewing medical records, unless that device is protected by antivirus software.
Further, if a user views medical information or performs financial transactions on a portable device and uses that device to send or receive e-mail, he or she should not open e-mail or attachments from unsolicited or unknown sources. As a side note, even known sources might be virus-infected, meaning that they did not send the e-mail or its attachments; this was done by a virus. Always exercise caution when using these devices and keep security in mind. Security rules apply to all devices!
6
In this lecture, there have been a number of references to healthcare. This is because the US government’s stated goal for a number of years now has been that most Americans should have access to electronic health records (EHRs) [E-H-Rs] by the year 2014. This means that a lot of private and confidential information will be accessible through Web browsers and through wireless devices. If these devices are not secure, then personal medical information is at risk. In other words, information could be falsely entered or even changed by somebody with malicious intent, and so it is very important that organizations understand the application of security in conjunction with healthcare.
The impetus for EHRs is coming from the American government. The motivation is to improve quality of care, decrease cost, and then insure privacy and security of the data.
One security concern is the current trend of outsourcing medical and bank data entry management to countries outside the United States. If hospitals employ medical transcriptionists in countries other than the United States, might these countries have different cultural values and even EHR regulations? How can data be protected when it is on the other side of the world being used by people who live by different rules, regulations, and cultural norms? These questions must be resolved before implementing EHR use on a wide scale.
7
Other issues include concerns about encountering another person’s information in one’s health record, making the information in both records incorrect and compromising security. Individuals might be discriminated against in employment, denied employment, or even denied health coverage based on pre-existing conditions if private medical information is made public. Personal privacy might be violated, such as when friends, family, and others find out about an embarrassing, but non-infectious medical condition. A final concern about the security of health data involves the sharing of data between providers, adding risk. Any time that data travels over the Internet, there is always a risk to data and privacy.
8
An EHR system is a collection of health data about the medical practice, the patients, doctors, nurses, and all of the entities that are involved in that process. Health data is stored as a record in a database system. For example, on each visit to a doctor, an entry is recorded in the EHR that is stored in a database. The patient’s name and contact information are one record in a database. A blood test or an X-ray , for example, each represents one record in a database.
9
EHR systems are used and maintained by healthcare providers and others to store healthcare data.
Healthcare providers, healthcare clearinghouses, and health plan providers are subject to federal rules governing security and other rules related to EHRs. The primary federal rule governing EHRs is known as HIPAA [hip-uh], which is the “Health Insurance Portability and Accountability Act” of 1996, including its subsequent amendments. Organizations that must adhere to HIPAA rules are called “covered entities.”
Data in EHRs are also subject to HIPAA rules when they are maintained by covered entities. Google Health, a free, online, electronic, personal health record offered by Google, is not a covered entity: Data entered in Google’s health record system are not protected by HIPAA rules.
EHRs use centralized database systems to integrate functions such as patient intake, medical care, pharmacy billing into one large database system. Departments and other entities might not be in the same physical location, so this means that patient data must travel over the Internet, and any time the Internet and data are combined, an element of risk is introduced.
Why does data have to travel over the Internet at all? One reason―and there are many―might be that when a doctor’s office bills an insurance company, some of the patient’s medical information must travel over the Internet. Through the use of EHRs, people can view their own health record, taking ownership of its contents, insuring accuracy, and even
10
providing content by adding comments for their doctors to read.
10
Consider some EHR security question and answers.
How is―or how should―data be sent over the Internet? In most cases, data will be sent in an encrypted secure manner over the Internet. If not, patients should question the security practices being used.
Is personal data safe? The answer to this question depends on each organization’s physical record and network security practices, as governed by their security policy. However, no data is 100 percent secure against theft or misuse, regardless of the applicable security policy. Having a good security policy in place and then auditing compliance can significantly improve success in obtaining data security.
And then, finally, who can view private medical records? According to HIPAA, only those who need to know or view the contents of a health record should be able to do so. Patients must authorize all other access to their record.
11
HIPAA requires that healthcare providers, insurance companies, and employers abide by privacy and security standards.
12
The HIPAA privacy rule requires covered entities to provide patients with what is known as a “Notice of Privacy Practices,” when care is first provided. A patient might receive this notice when visiting a walk-in clinic, for example. The privacy rule covers paper and electronic private health information.
HIPAA also incorporates a security rule that goes farther than the privacy rule in that it covers administrative, physical, and technical data safeguards that must be enacted to secure EHR data. All of these should be outlined in the entity’s security policy as mentioned throughout this lesson.
13
This slide discusses privacy. Most privacy law revolves around privacy between a person and the government.
According to Wikipedia, the law of privacy regulates the type of information that can be collected and how this information may be used and stored. Privacy relates to people: A patient visit to a doctor is private information.
14
Confidentiality differs from privacy. According to Wikipedia, confidentiality is commonly applied to conversations between doctors and patients. Legal protections prevent physicians from revealing certain discussions with patients, even under oath in court. The rule applies only to secrets shared between physician and patient during the course of providing medical care.
Therefore, from this definition, it can be inferred that confidentiality relates to data, because the communication typically involves data shared between the health provider and the patient. Confidentiality, then, in this context, means that the things discussed with a doctor should remain between the patient and the doctor; they are confidential.
To put privacy and confidentiality in context, the fact that someone visited a doctor is private; what the patient and doctor discussed is confidential. Privacy and confidentiality are not usually exclusive and each slightly overlaps the other in scope.
15
What steps can be taken to secure an EHR and its records? It is possible to authenticate and authorize all access to EHR records. Authorization includes permissions including sharing and NTFS permissions when appropriate.
Only those with a need to know should view medical records; only pertinent people can actually make a change to a record; it is possible to limit who can print electronic documents; and finally, all views and changes should be recorded for audit. For example, a clerk can view the dates and charges related to an office visit but cannot view anything that details the treatment received or the information discussed between patient and doctor. Nurses and doctors can view medical records for patients under their care but cannot view medical records for patients not under their care.
An important point is that security outlines the structure through which privacy and confidentiality can be enforced. Putting in place security mechanisms such as requiring usernames and passwords; badges to open doors; and keys to open file cabinets increases the probability of data privacy and confidentiality.
16
Device security is important in securing EHR and records.
Operating system critical updates should be applied immediately; antivirus definitions should always be current; physical access to servers that house medical data should be restricted; and finally, access to devices must be authenticated.
Encryption can also secure electronic communications. All communication between an EHR system and a destination device should be encrypted.
A client server environment will allow maintenance of a domain environment with a server that manages all devices and all objects.
User accounts should be configured in groups, and permissions must be provided to the groups.
Finally, organizations should implement network access protection mechanisms. For example, if a device attempts to connect to a network, the system first examines the device to verify that it has critical updates applied to its operating system, require the device to have antivirus protection software installed, or check that its firewall is enabled.
17
EHR transmission over the Internet requires that HTTPS, or secure Web browsing, be implemented for all Web transactions. In other words, all communication over the Internet is encrypted. Further, all data entered into Web forms must be validated before that data is stored in a database.
Further steps to secure EHR and records include regular audits of data access and changes in medical records and implementing redundant devices within the data environment to ensure that devices are available as expected. In addition, system administrators can load-balance heavily used hardware devices. For example, rather than using only one server to store database records, an administrator can create a five-server cluster. Then, whichever server is the least busy can respond to requests for database records.
For example, in an EHR system where doctors and nurses see 500 patients per day, it would be wise to have more than one database system in place because of the heavy load that will be placed on these systems. Administrators should prosecute security violations vigorously. If a hacker attacks a network, administrators should use records to find out who the attackers are and then report the activity to the authorities. Even internal violations should be prosecuted. This would discourage others from taking the same actions.
Finally, it is mandatory to perform regular back-ups of EHR data and secure the storage of that data so that it cannot be located and used by unauthorized persons or entities.
18
This concludes Lecture (c ) of Security. In summary, the lecture covered wireless networks and how to address them and discussed security concerns and regulations for healthcare applications.
19
This also concludes the unit, Security.
In summary, this unit addressed common security concerns and safeguards, including firewalls, encryption, virus protection software and patterns, and programming for security. Additional topics included security of wireless networks and concerns, mitigations, and regulations related to healthcare applications.
20
References slide. No audio.
21
Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-
ShareAlike 3.0 Unported license. © Johns Hopkins University
Welcome to Installation and Maintenance of Health IT Systems, System Security Procedures and Standards. This is Lecture a.
This component covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR) systems.
This unit, System Security Procedures and Standards, will discuss the security rules required by regulation and best practices for implementation and monitoring of security in EHR systems.
1
The objectives for this unit System Security Procedures and Standards are to:
• Identify regulatory requirements for EHRs • Provide training for system users regarding the methods and importance of security compliance • Identify administrative, physical, and technical safeguards for system security and regulatory compliance • Identify best practices for system security • Identify best practices for risk / contingency management
In any software system, security should be the number one priority of administrators and developers. Enacting good security measures – in other words, handling information well and protecting it from attack – not only safeguards the business from financial and legal liability, but also is a measure of professionalism.
Before implementing new EHR software, whether a commercial off-the-shelf, or COTS, product or one you’ve developed in-house, it’s important both to look for software defects that may compromise security and to establish reasonable safeguards and policies to prevent abuse and security breaches.
In today’s lecture we will cover what is security and privacy of health information and some ways it can be compromised. Next we will
2
discuss the agencies responsible for regulating the protection of data and what your requirements are, along with some baseline practices you can use to protect your infrastructure. Finally, we’ll address the largest security threat of all (users) and ways to mitigate issues with training and compliance.
2
Security and privacy with regards to health records are tightly governed by federal, state, and local laws. These laws govern: • Who can legally have access to any type of health information; • What measures must be taken to protect those records; • How long those records must be stored; • And whom to notify and what you need to do if records have been compromised.
3
HIPAA, or the Health Insurance Portability and Accountability Act of 1996, is primarily responsible for governing the protection of individual health data. Many states have also passed legislation to further enhance these federal guidelines. Protected health information (PHI) under HIPAA includes any individually identifiable health information. Identifiable refers not only to data that is explicitly linked to a particular individual, it also includes health information with data items which reasonably could be expected to allow individual identification.
Note that the definition of PHI excludes individually identifiable health information in education records covered by the Family Educational Rights and Privacy Act (FERPA).
Employment records held by a covered entity are also exempt from this federal regulation.
4
Under HIPAA, 18 different identifiers are recognized as providing identifiable links to individuals: 1. Names 2. All geographical subdivisions smaller than a state, including street address, city, county, precinct, zip code, and their equivalent
geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (2) The initial three digits of a zip code for all geographic units containing 20,000 or fewer people is changed to 000.
3. All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older
4. Phone numbers 5. Fax numbers 6. Electronic mail addresses 7. Social Security numbers 8. Medical record numbers 9. Health plan beneficiary numbers 10. Account numbers 11. Certificate/license numbers
5
12. Vehicle identifiers and serial numbers, including license plate numbers 13. Device identifiers and serial numbers 14. Web Universal Resource Locators (URLs) 15. Internet Protocol (IP) address numbers 16. Biometric identifiers, including fingerprints and voice prints 17. Full face photographic images and any comparable images 18. Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by an investigator to the
code data)
5
Federal law tends to supersede state and local law. When in doubt or where overlap occurs, always plan on implementing the tightest control policy.
It is important to familiarize yourself with all of these regulations, and the state and local health departments can be excellent resources. Remember that the requirements will come from the legislative body with jurisdiction over your practice area, so legal counsel should be consulted to identify applicable requirements and resolve conflicts.
Since local and state laws vary from state to state, we will focus today on the federally mandated rules governing health data and storage.
6
As we alluded to earlier, the HIPAA Privacy Rule is a set of federal standards written to protect the privacy of patients' medical records and other health information maintained by covered entities. These entities consist of health plans, which include many governmental health programs such as the Veterans Health Administration, Medicare, and Medicaid; most doctors, hospitals and many other health care providers; and healthcare clearinghouses.
These standards provide patients with access to their medical records and with significant control over how their personal health information is used and disclosed. Compliance with the standards was required beginning in 2003 for most entities covered by HIPAA.
7
The Office for Civil Rights is responsible for investigating all complaints associated with HIPAA security and privacy; however, only in 2009 did OCR assume responsibility for administering and responding to HIPAA security complaints. Since 2003, HHS (Health and Human Services) has received over 66,000 HIPAA Privacy complaints, of which over 15,000, after investigation, required changes in privacy practices and other corrective actions by the covered entities. At roughly $10,000 in fines per validated complaint, there’s no doubt that failure to ensure adequate safeguards can be costly to an organization. However, in the end, these losses pale in comparison when considering the organization’s potential loss of reputation and patient confidence, which can take years to rebuild.
The most common types of covered entities that have been required to take corrective action to achieve voluntary compliance are, in order of frequency: • Private practices; • General hospitals; • Outpatient facilities; • Health plans (group health plans and health insurance providers); and • Pharmacies.
8
From the compliance date to the present, the compliance issues investigated most are, compiled cumulatively, in order of frequency: • Impermissible uses and disclosures of protected health information; • Lack of safeguards of protected health information; • Lack of patient access to their protected health information; • Uses or disclosures of more than the minimum necessary protected health information; and • Complaints to the covered entity.
9
The HIPAA Security Rule establishes national standards for the security of electronic protected health information (ePHI). The final rule adopting HIPAA standards for security was published in the Federal Register on February 20, 2003, and specifies a series of administrative, technical, and physical security procedures that covered entities must use to assure the confidentiality of electronic protected health information. The standards are delineated into either required or addressable implementation specifications. Compliance with the standards was required as of 2005, for most entities covered by HIPAA.
The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting ePHI.
Specifically, covered entities must: •Ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain or transmit; •Identify and protect against reasonably anticipated threats to the security or integrity of the information; •Protect against reasonably anticipated, impermissible uses or disclosures; and •Ensure compliance by their workforce.
The Security Rule defines “confidentiality” to mean that ePHI is not available or disclosed to unauthorized persons. The Security Rule's confidentiality requirements support the Privacy Rule's prohibitions against improper uses and disclosures of ePHI. The Security rule also promotes the two additional goals of maintaining the integrity and availability of ePHI. Under the Security Rule,
10
“integrity” means that ePHI is not altered or destroyed in an unauthorized manner. “Availability” means that ePHI is accessible and usable on demand by an authorized person.
It’s important to note that the Security Rule was designed to offer flexible and scalable options to allow covered entities to analyze their own needs and implement solutions appropriate for their specific environments. What is appropriate for a particular covered entity will depend on the nature of the covered entity’s business, as well as the covered entity’s size and resources.
Both the Privacy Rule and the Security Rule work in tandem to help ensure that healthcare data is properly protected.
10
The HIPAA Security rule requires covered entities to guarantee certain safeguards to protect ePHI data. These safeguards can be broken down into categories:
• Administrative Safeguards • Physical Safeguards and • Technical Safeguards
Let’s take a closer look at each of these categories, their requirements, and some specific options available so you can adequately address them.
11
Administrative safeguards address the process you have put into place in your organization to administer security of the ePHI system.
Each organization is required to identify and analyze potential risks to its ePHI, and it must implement security measures that reduce those risks and vulnerabilities to a reasonable and appropriate level.
This is done using a risk analysis. A risk analysis process includes, but is not limited to, the following activities:
• Evaluate the likelihood and impact of potential risks to ePHI;
• Implement appropriate security measures to address the risks identified in the risk analysis;
• Document the chosen security measures and, where required, the rationale for adopting those measures; and
• Maintain continuous, reasonable, and appropriate security protections.
This should be an ongoing process. Regular reviews should be performed to evaluate the effectiveness of the security measures put in place, and newly identified potential risks to ePHI should be addressed in an ongoing fashion.
12
A covered entity must also designate a security official who is responsible for developing and implementing its security policies and procedures.
Your network security officer or person handling network security should have knowledge of both HIPAA guidelines and IT security standards. He or she should be willing to take proactive measures to ensure the safety of the ePHI system and be able to communicate effectively with and solicit support from upper management as well as with staff at all levels of the organization.
13
The Security Rule requires a covered entity to implement policies and procedures for authorizing access to ePHI only when such access is appropriate based on the user’s or recipient's role within the organization.
Written policies should be created, then endorsed by management, to explain the process for granting access to ePHI. This includes establishing, documenting, reviewing, and modifying a user's right of access, including termination of said access.
This policy or group of policies should adequately address these questions: Who gets access to ePHI data? What level of access is needed? Who is the agent authorizing the access? Is this authorization adequately documented? Is the access periodically reviewed? Is there a process for rescinding access once it’s no longer needed?
14
The administrative safeguards also provide for appropriate authorization and supervision of workforce members who work with ePHI.
A covered entity must routinely train all workforce members regarding its security policies and procedures, and it must have and apply appropriate sanctions against workforce members who violate its policies and procedures. Training can include newsletters, one-on- one consultation, media presentations, staff meetings, and the like. This training should be adequately documented for auditing purposes, including the time and date of the training, topics covered, and who attended. Training should encompass all users who may interface with ePHI in some manner, including upper management.
Note that although HHS-collected information about breaches does not include those caused directly by personnel (through social engineering or exploitation of poor security practice or simple error), people remain the largest security risk. Training is an important additional safeguard to ensure good security practices.
Any policies and procedures that are developed must also undergo a periodic review and evaluation process. Since the regulatory environment may change with new legislation or newly identified best practices, older policies may be out-of-date or no longer appropriate. Additionally, onerous or poorly-implemented policies may cause development of security bypassing “workarounds” from personnel that bypass critical security features. If these bypasses are used to “get the job done” then the procedures bypassed need to be restructured so that the requirements of the Security Rule remain fulfilled.
15
Physical safeguards are written to address issues regarding facility access control, workstation use, workstation security, and device and media controls. This includes limiting physical access to work facilities without impeding access to those requiring access. This is particularly true in areas where ePHI may be present including work areas, server rooms, back-up media storage units, and the like. These areas require an extra level of protection to limit access to authorized users only and, whenever possible, create a structure for logging access, particularly any irregularities such as for maintenance staff, etc, who may require entry into these locations but are not considered routine in nature.
Additionally, keeping a reliable hardware inventory – along with its value and locations – is also an important safeguard to preventing theft of a system which may inadvertently contain ePHI data.
16
Policies should also exist surrounding the acceptable use of any workstation or device or media with the potential of collecting or storing ePHI. This includes: • Physically locking any workstations which are in public areas which may store ePHI • Requiring the devices and EHR software to use strong passwords. A strong password has the core aspect of being difficult to
guess. For this reason, there are many recommendations to increase password strength. The most important aspect of a strong password is length. Though counterintuitive, a password of “A%2j6A” is _much_ easier to break than “kitty1231231234”. Other restrictions to increase password strength include: NOT re-using passwords from a previous login or system, using numbers, punctuation, symbols, and upper and lowercase letters, and NOT using common dictionary words or parts of a login.
• Encrypting all storage media containing ePHI – The use of password protection instead of encryption is not an acceptable alternative to protecting ePHI. This is particularly true regarding wireless access of ePHI, say from laptops or PDAs; offsite access of any sort, or backup media, particularly media being transported off-site, whether physically or digitally through the network.
• Whenever possible, the strongest methods for encryption should be utilized, preferably with 256-bit or higher encryption. Backup media should be kept locked away in a secured environment with tight access controls.
• Additionally, policies should be implemented prohibiting the storage of ePHI on workstations, laptops, or any other unapproved device. Measures should be taken to routinely examine these devices for compliance. Likewise, when disposing hard drives or other connected media from these devices, they should be rendered completely useless after being thoroughly wiped a minimum of 7 times in a manner consistent with DOD specifications. There are plenty of free tools available for this purpose – DBAN (Derik’s Boot and Nuke) is popular.
17
This concludes lecture a of System Security Procedures and Standards.
So, let’s take a moment to recap what we have covered so far:
We’ve talked about the many facets of ePHI regulation, along with various administrative, physical, and technical safeguards available to assist you in protecting your infrastructure. We have discussed that HIPAA, along with additional state and local guidelines, requires healthcare data to be protected from unwanted and unauthorized disclosure. We have identified at least 18 different types of data in health records that are considered identifiable with regard to the federal guidelines.
Healthcare data should be protected using a layered approach including enacting numerous administrative, physical, and technical safeguards.
User training for personnel working with ePHI is critically important because they are the greatest threat to data security. Make sure personnel are aware of policies and procedures, document any training, and review the effectiveness of that training with periodic evaluation.
Much of what you will do will hinge on the type, topology, and operating systems utilized in your infrastructure. In the next part of our lecture we will continue our discussion with technical safeguards often utilized in healthcare settings.
18
No audio.
19
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.
Welcome to Installation and Maintenance of Health IT Systems, System Security Procedures and Standards. This is
Lecture b
This component Installation and Maintenance of Health IT Systems covers fundamentals of selection, installation, and
maintenance of typical Electronic Health Records (EHR) systems.
1
The objectives for this unit System Security Procedures and Standards are to:
• Identify regulatory requirements for EHRs
• Provide training for system users regarding the methods and importance of security compliance
• Identify administrative, physical, and technical safeguards for system security and regulatory compliance
• Identify best practices for system security
• Identify best practices for risk / contingency management
This lecture finalizes the discussion of regulatory requirements by introducing technical safeguards and some best practices for
system security and risk management that you can use to protect your infrastructure.
2
HIPAA demands that sufficient measures be put into place at the technical level to guard healthcare data from all reasonable
means of attack and unwanted disclosure. Technical safeguards address access controls, audit controls, integrity controls, and
transmission security.
The access control technical requirement mandates that “a covered entity must implement technical policies and procedures
that allow only authorized persons to access electronic protected health information.” From a technical perspective, there are
several tools that assist administrators with administering this process.
Effective security practices embrace a layered approach to providing security to a network. That is, several different
technologies are employed concurrently to protect the network instead of relying solely on one approach. That way, if an
attacker finds his way through one layer, he still has to overcome additional obstacles before he is successful. This would be
the equivalent to adding a security alarm and dogs at your home instead of simply relying on the deadbolt lock to dissuade
intruders.
One such tool is Active Directory, or AD. AD allows administrators to assign policies, deploy software, and apply access roles,
based on users or user groups, to an organization’s network. It does this by storing information and settings about users and
resources in a central database. Active Directory networks are very scalable and are seen from small installations, with a few
3
computers, users, and printers, to large organizations with tens of thousands of users.
Active Directory uses a protocol called LDAP (Lightweight Directory Access Protocol) to allow connectivity and control access to a wide
variety of management and query applications. It may be possible for your vendor to adapt your EHR system to use Active Directory to
help you manage access if the software is not already configured to do so.
For instance, when a new physician begins at the organization, her access would be partially governed by what Active Directory group
her account was added to.
Regardless, your vendor’s product should come with a set of access controls already built into the software. Be sure to have a candid
conversation about how these controls work and be certain they will work in a manner consistent with the roles your organization uses
for administering ePHI data.
3
Other technical safeguards include utilizing hardware, software, and/or procedural mechanisms to record and examine access
and other activity in information systems that contain or use e-PHI. We call this audit control, and it is implemented through
activity logging.
What actually needs to be logged depends on the level of access controls to the ePHI data. However, there are some pretty
consistent items. In general, your servers should use OS system logging tools to log:
• Who accessed, or tried to access the server; and
• What data or databases were successfully accessed and any changes made.
4
Your EHR software should support logging user access, logging data accessed, logging sign-on failures, and any changes to
the data
Proactive audits should be performed periodically, with the intent of sampling the data set to look for possible inappropriate use
or activity. Log sampling does not have to be random. Proactive audits can sample from the entire log population or from areas
known to be of higher risk.
For example, when reviewing access logs to patient records, it may be appropriate to intentionally sample from the population
of employee patients, as well as from the patient population as a whole.
Proactive auditing can serve as a deterrent to would-be voyeurs. Therefore, it is important that system users be aware that
proactive auditing takes place.
Reactive audits are performed whenever a defined event triggers the need for an audit.
An "event" might be a patient or employee complaint or a security system alarm.
It is also advisable to audit appropriate logs when unusual or extreme situations occur, such as a highly publicized accident
5
involving victims treated at your facility, an illness of an employee known to coworkers with access to systems containing the
employee's PHI, or the involuntary termination of an employee.
5
Your EHR software must have policies, procedures, and electronic controls to ensure that e-PHI is not improperly altered or
destroyed. This should be automatic and verifiable, as the previous slides indicated.
The electronic measures may be implemented at the network level through transmission security, at the operating system level
through authentication and authorization controls, or at the patient record level through database authentication and data
integrity controls – preferably a combination of all three.
6
Since ePHI is transmitted over networks, security measures and restrictions must be in place to guard against unauthorized
access to those networks.
Offsite access of ePHI poses a particularly hazardous risk. In some instances, the use of offsite access can be disallowed
completely; for many healthcare institutions, however, it is unacceptable to restrict access by other healthcare institutions or
physicians who may be practicing offsite but have a valid need to access these records.
In any case, offsite access should be strictly controlled, and any data being transmitted from your site to another offsite location
should be adequately protected by the use of encryption and VPN (Virtual Private Networks).
A VPN uses encryption, authentication, and authorization to protect data as it is routed through the Internet. VPN connections
may use protocols such as L2TP/IPSec, OpenVPN, or Cisco’s client implementations . However, Microsoft’s PPTP VPN
implementation has vulnerabilities that make it ill-suited for ePHI transmission.
7
Here’s a graphical illustration of VPN, used for transmitting data over the internet between the VPN router and the VPN client
on a user’s machine.
By using the internet as a connection medium, VPN can adequately protect your data while saving the cost of long-distance
phone service and hardware costs associated with using dial-up or leased line connections.
8
Another way to help prevent unwanted access is through the use of firewalls. A firewall is a dedicated appliance or software
running on a computer which inspects network traffic passing through it and denies or permits passage based on a set of rules
or criteria. It does this by controlling access to ports. Ports are essentially communications channels that applications need to
communicate with one another. Some ports are pretty common, such as port 80 which regulates web traffic. Firewalls represent
an important front line element to thwart unwanted access and help ensure HIPAA compliance.
It is normally placed between the protected network, where ePHI is housed, and the unprotected network, and it acts like a gate
to protect assets. A firewall’s basic task is to protect computer networks where they meet at different trust levels. For example,
you very often see a firewall between the internet traffic and internal network traffic. Many servers and workstations also have
firewalls to provide yet another level of protection.
It’s important to note that your EHR system will require certain ports to remain open on your firewall to work properly. Work with
your vendor to ensure proper ports are left open.
9
As this picture illustrates, firewalls can be placed anywhere the network transitions from a less trusted segment to a more
trusted segment. In this instance, the first firewall – the network firewall – allows some communications through as determined
by the overall network needs.
The second firewall – the computer firewall – is then tailored further, reducing traffic to and from the computer system to only
those applications installed and running on the system itself.
10
Another tool is the VLAN or Virtual Local Area Network. This is an administrative division on network equipment to separate
devices and data, such that the data cannot be intercepted by a device on a separate VLAN. Modern telephones that operate
over IP networks (IP phones or VOIP phones) often are configured and managed on a separate VLAN. Additionally, non-
sensitive data for appointments, Internet access, and general office use can be on a VLAN with less onerous controls than a
VLAN with ePHI data. Lab devices that require network communication can be separated from employee workstations to
reduce the risk of computer virus transmission.
11
Another tool to prevent unwanted access is the Intrusion Detection System, or IDS. An IDS is a device or application that
monitors the network (or the system it’s installed on) for malicious activities, based on pre-defined patterns or policies, and
reports such activities to the network administrator. Some systems actually take it a step further through preemptive actions to
stop detected activities until the administrator intervenes or for a certain duration of time. These systems are known as Intrusion
Prevention Systems (IPS).
12
There are many different ways in which your system could be breached, allowing for the compromise of your sensitive data.
Let’s list a few of the more common approaches, as outlined by the Microsoft TCP/IP core networking guide:
The inside job: An overwhelming majority of network security issues center around the organization's own workforce. Lack of
policy understanding, laziness, or disgruntlement among workers are always threats. Training employees on the hazards of
mishandling sensitive data and the importance of following both legal regulations and your organization's policies will help
mitigate this risk.
Social engineering is the process where someone is tricked into divulging information that allows an attacker to infiltrate a
network. The most common attempt centers around pretending to be a network administrator needing the user’s password to
repair something in the system.
Brute force attacks are just what they seem. An evildoer identifies a server on the network, perhaps by scanning for the remote
desktop port, then attempts to break into the system using the administrator account and runs specialized utilities that will try an
endless number of passwords until it cracks the password.
Eavesdropping: The majority of network communications occur in an unsecured or "clear text" format. An attacker who has
13
gained access to your network can "listen in" on the traffic. When an attacker is eavesdropping on your communications, it is referred to
as sniffing or snooping. Eavesdropping is generally the biggest security problem that administrators face in an enterprise environment.
Enabling strong encryption services on your sensitive data as it traverses the network can mitigate this risk.
Note that gaining access to a network will depend on the type of network medium – a wireless network could be accessed without
requiring physical contact, thus requiring additional security measures. Access to wired networks can depend somewhat more on
physical security controls.
Data modification: An attacker can modify the data in the packet without the knowledge of the sender or receiver. This can lead to
erasure or corrupted data.
Identity spoofing: Most networks and operating systems use the IP address of a computer to identify a valid entity. In certain cases, it is
possible for an IP address to be falsely assumed. Try not to use IP addresses as a method of ensuring connectivity to a particular
device. Ensure that the device MAC addresses are utilized for connecting to a domain.
Password-based attacks: Failure to use strong passwords or, whenever possible, multi-factor identification (requiring more than one
method of identification to authenticate to a network) can lead to account compromises, potentially compromising data.
Denial of service attacks: Though these attacks don’t usually intercept data, they can render a network virtually useless by overloading
the infrastructure with unwanted traffic.
Man in the middle attack: Someone figures out a way to intercept the network traffic and captures it before sending it along to the
reader. This is often the result of a compromised encryption key. Utilizing 256-bit or stronger encryption on VPN, wireless, and other
communication can help offset this risk.
Application layer attacks: This attack targets application servers by causing a fault in a server's operating system or applications. Once
compromised, the attacker gains the ability to bypass normal access controls. The attacker takes advantage of this situation, gaining
control of the application, system, or network, leaving data vulnerable.
13
Servers and computers containing sensitive data, such as ePHI, are particularly attractive targets to attack. In addition to
installing a firewall, intrusion detection system (IDS), and advanced logging tools, there are additional safeguards you should
take:
Administrative:
-Enact and enforce policy that ensures that all users needing access to ePHI understand that all ePHI data must be stored on
approved and protected network systems only. Taking patient data home on a physician’s personal laptop should raise alarms!
-Ensure that all local users to the systems are approved for accessing ePHI, and remove or disable any local accounts, such as
the guest account, that are not needed. Be sure to rename the default administrator and guest accounts as well. Default
configurations and passwords are an all too frequently overlooked problem, especially on equipment such as a networked lab
device.
-Strong passwords can be difficult to create and track. Provide a recommended process for effective strong password
generation, and enable automatic password strength checking.
-Monitor usage for user accounts, and disable unused accounts to prevent them from being compromised without awareness.
Technical:
14
-Install an effective antivirus / anti-malware system and ensure it stays updated.
-Attack surface is the set of services running on a server that are potential vectors of attack. A given server may not be obviously
vulnerable today, but new exploits may be developed tomorrow. An unneeded service that is not running or available cannot be used by
an attacker.
-Configure the server with coordination with your software vendor to ensure proper application performance. For Windows, this tool is
called the Security Configuration Wizard.
-Create a security baseline for your servers. For windows deployments, Microsoft has a tool designed for the creation of security
baselines specific to the server software you are using. For more details search for “Microsoft Security Baseline Analyzer”.
Remember to test and install the latest service packs and security releases for your server. 48 hours after release is a good standard to
adhere to.
Database applications need additional safeguards in place. Be sure to research your particular database applications and remember to
lock down and install all patches for these applications.
14
Updates and service packs often provide security fixes for operating systems, applications, databases, and embedded systems.
Any device connected to open networks should be patched as soon as the fix is available – automated update services are one
way to ensure this. For critical systems containing ePHI or core business data (that would halt business if unavailable) testing
and verification should be performed in test environments before moving to production systems.
Note that specialized medical equipment may have its own operating system, applications, and configuration. If the underlying
operating system is vulnerable to an attack, do not immediately assume that a patch should be deployed. Some of these
systems have only been certified or are only supported in specific configurations. Check with the system vendor before applying
any patches or fixes in this environment, but during the vulnerable period, try to implement specific monitoring for attacks
directed towards the newly discovered vulnerability.
Create a security baseline for your servers. For windows deployments, Microsoft has a tool called “Microsoft Security Baseline
Analyzer” that is designed for the creation of security baselines specific to the server software you are using. In general, a
security baseline is a periodic record of system parameters (like software versions and configuration details) that can be
compared to determine if any vulnerabilities have been newly discovered. These lists should be updated periodically and
compared against publicly known exploits and vulnerabilities.
15
Database applications need additional safeguards in place. Be sure to research your particular database applications and remember to
lock down and install all patches for these applications as recommended by your vendor.
15
Ensuring your data is protected from natural and technical threats is just as important as ensuring data is not compromised
through malicious intent. In the event something catastrophic does occur, plans must be in place to ensure the network, along
with its valuable data, can be returned to operating status with a minimal amount of downtime.
This means ensuring data is reliably and securely backed up, along with a disaster recovery plan containing an emergency
contact list of critical players and stakeholders in the organization who will be needed to make decisions and assist with the
technical components of restoring the network.
These plans should include contingencies for:
-The offsite storage of data and the prompt return and restoration of the data from backup.
-Plans for relocation of infrastructure resources, or the operation as a whole, until repairs can be affected.
16
These plans should be put in writing BEFORE an incident develops:
Written Plans
Risk analysis or assessment
Database backup
Database secure storage
Data restore plan
Disaster recovery plan
17
Critical incident response plan
Software Inventory
Hardware Inventory
Logs - transmission points
Let’s take a few moments to look at each of these plans in a little more detail. We’ve already discussed the risk analysis, or risk
assessment, in the first half of this Unit, so we’ll start with database backup.
17
Ensuring integrity of data is just as important as ensuring its confidentiality. Loss or corruption of data means a costly loss of
productivity because of the effort required to, at a minimum, recreate the data.
Backing up data files, including patient or EHR databases, helps ensure data can be recovered in the event of data corruption,
a catastrophic failure, or security breach.
The purpose of a data backup policy is to set into motion a method for implementing a backup strategy and procedures that
adequately addresses the needs of the institution and maintains compliance with regulations. This strategy includes what data
will be backed up and how often, as well as how to ensure these archives will be secured but easily accessible if needed. The
policy also outlines the hardware and software required to ensure reliable and efficient backup of these production databases.
18
Data spend over 90% of their time at rest where they are more susceptible to corruption or loss than in any other state.
The Secure Data Storage and Restore policies outline specific protocols which must be adhered to in order to mitigate risks
associated with short- or long-term data storage.
In particular, databases require extra attention when it comes to security. Each production database housing data, particularly
healthcare data, should be evaluated to determine the best method for securing the resident data and ensuring access to the
database is properly administered and in compliance with regulations.
Likewise, if special protocols are needed for restoring the database, or datasets within those databases, a plan of action should
be spelled out for how this process works.
19
Disaster Recovery and Critical Incident Response plans are designed to address emergencies requiring immediate intervention
to protect the network or restore the network to operational status after a catastrophic event.
Based upon your risk analysis, these plans provide a step by step guide to identify and recover from each of the potential
threats identified in the original analysis.
They identify the key players or teams needed to perform the recovery process, outline the types of hardware needed and the
vendors who supply them, pinpoint alternate facilities in the event your facility cannot be accessed, and provide detailed
procedures to bring the network back to operational status and restore the integrity of the data.
20
Maintaining inventories for both hardware and software used on the network is just as important as securing the data.
Maintaining an up-to-date hardware inventory not only helps you as you plan out hardware and software upgrades and other
administrative tasks, it also ensures your inventory is properly “locked down” and accounted for. This is essential from a
security perspective. Why would you worry about a hacker creeping through the network if someone could just walk in and
steal the data directly from the hardware where the data is stored?
Likewise, keep a current inventory of the applications being used on your network. This will provide additional insight needed to
properly manage and mitigate security risks related to software vulnerabilities. It will also facilitate proper patching and issue
mitigation.
21
As we pointed out earlier, monitoring is an important part of security. Often, log monitoring is taken for granted.
Your IT systems are capable of monitoring and logging nearly every activity that occurs. An effective logging and monitoring
strategy means understanding what to log and what to look for, and devising a method for effectively managing and monitoring
vast amounts of data. This is critical for network security. Logs can quickly grow to hundreds of thousands of cryptic entries
that, without some sort of strategy or management system in place, would surely overwhelm even the mightiest of IT gurus.
Start with identifying what data requires more stringent monitoring. At the very least, you will want to know who is trying to
access the data or critical hardware components and were they successful. You can also track the movement of this critical
data, though expect extremely large logs from this type of audit process.
It’s important to devise a written plan summarizing what is logged and why, along with the appropriate procedures to audit the
logs effectively. Create a written record of accountability for the reviewer(s) to ensure compliance with the policy.
22
This concludes System Security Procedures and Standards.
We have only scratched the surface of all the security measures that can be implemented with an EHR system. We’ve talked
about several aspects of ePHI regulation, along with various administrative, physical, and technical safeguards available to
assist you in protecting your infrastructure.
Types of system vulnerabilities have been introduced, along with best practices for securing systems against those
vulnerabilities.
Finally, risk assessment and contingency plan development will help ensure secure operation and regulatory compliance.
Much of what you will do will hinge on the type, topology, and operating systems utilized on your infrastructure, along with
ensuring compliance with regulatory and organizational policies. Security is a continuing process of adaptation to emerging
threat. If you’re not comfortable with always learning something new, this field is not for you.
23
No audio.
24
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.
Welcome to The Culture of Healthcare, Ethics and Professionalism. 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 Ethics and Professionalism are to:
• Provide an orientation to ideas about medical ethics and professionalism
• Explore the relationships among ethical ideals, professionalism, and legal duties
• Apply the general principles of ethics and professionalism to specific topics
• Examine ethical issues in health informatics
2
This lecture discusses ethics and professionalism. These topics are very broad and can
include many ideas that are not clear-cut. This unit approaches the subject of ethics and
professionalism by starting with some basic ideas, then showing how these ideas apply to the
complicated situations that can occur in healthcare settings.
Generally speaking, ethics is the study of beliefs about what is right and wrong and how people
go about making those kinds of decisions. Professionalism is a term that describes generally
accepted ideas of appropriate conduct within a specific profession.
3
Many people who study medical ethics say that the basics of healthcare ethics can be
captured by four principles: respect for autonomy, beneficence [buh-niff-fuh-sense], non-
maleficence [non-muh-liff-fuh-sense], and justice. Some experts are critical of this approach
as each of the broad principles is open to a variety of interpretations. However, the concept of
these four basic principles is widely used and serves as the starting point for many discussions
of healthcare ethics.
The following slides define each of these principles and show how they are applied in
healthcare settings.
4
Generally, autonomy means people have the right to make their own decisions. This concept
is often called “self-governance.”
In the healthcare setting, respect for autonomy means that healthcare professionals must
recognize that patients have the right to make their own treatment decisions based on their
individual preferences and beliefs. Respect for autonomy also includes the idea that
healthcare decisions are entirely voluntary. Healthcare providers must not put excessive
pressure on patients to make a particular choice or submit to treatments.
The principle of respect for autonomy is the ethical basis for the concept of informed consent.
Informed consent means that the patient knows, understands, and accepts the risks and
benefits of treatment. This concept is discussed in more detail in a later lecture.
5
The principle of beneficence simply means that healthcare providers should do things that
benefit the patient. This includes both actions meant to prevent problems and actions to
address problems the patient is already experiencing.
The idea of beneficence is commonly recognized as one of the main purposes of healthcare.
The idea is applied at the level of individuals and the level of populations. For example, giving
antibiotics to a patient with pneumonia applies the principle of beneficence at the individual
level. Giving elderly patients the opportunity to be vaccinated against pneumonia applies the
principle at a population level.
6
Non-maleficence is the expectation that healthcare professionals will not intentionally injure a
patient. Medical students learn the famous saying that doctors should, “First, do no harm.”
There are two types of non-maleficence acts: acts of commission and acts of omission. An
example of an act of commission is giving a patient a drug for the sole purpose of harming
them. Acts of omission might not be as obvious. An example is intentionally withholding a
drug from a patient who is expected to benefit from the drug.
7
In discussions of medical ethics, the term justice is often used as a synonym for fairness. The
concept of justice includes the idea that all people have the right to be treated equally.
Distributive justice is the idea that if resources are scarce, they will be allocated in a fair
manner. How distributive justice should be implemented is controversial in our society, and it
is discussed in more in a later lecture.
8
Healthcare professionals have an obligation to consider difficult questions about how far and
wide their ethical duties extend. Obviously, it is not reasonable to think that every individual
healthcare professional is responsible to care for every individual in the world. But is each
healthcare professional responsible to everyone in their community? How about everyone in
the country? Furthermore, does the healthcare profession as a whole have a duty to society
as a whole? Do healthcare professionals have to respect the rights of laboratory animals, or
the whole natural environment?
These are difficult questions, and well-meaning people can have fundamentally different beliefs
about the answers. The phrase “concern for the scope of their action” means that when
healthcare professionals are confronted with these kinds of difficult questions, they are
obligated to think about them.
9
The general principles of respect for autonomy, beneficence, non-maleficence, and justice
have many specific applications in the healthcare setting.
As previously mentioned, informed consent is a major duty that flows from respect for
autonomy. Another duty based in respect for autonomy is confidentiality. In general, a person
has no obligation to keep the secrets of another. However, in the healthcare setting,
confidentiality is both a legal and ethical duty.
The principles of beneficence and non-maleficence are closely related. One implication of
these duties is that healthcare treatments must be designed to maximize benefits and
minimize risks.
The principle of justice obliges the healthcare profession to ensure that the risks of medical
research do not fall disproportionally on one group of people. As previously mentioned,
another implication is that healthcare will be distributed fairly among patients.
10
Experts in medical ethics say that each of the four principles is a prima facie [pree-muh fay-
shee] duty. Translated from the Latin, prima facie means “at first view.” In the context of
ethics, this term means it is self-evident that an ethical principle is binding unless it conflicts
with another principle.
As an example of a conflict in principles, imagine a situation where there is only enough
medicine for one patient, but two patients need to be treated, and half the medicine would do
no good for either patient. This situation represents an ethical conflict between the duties of
beneficence, non-maleficence, and justice. Unfortunately, the concept of the four principles
does not give guidance about how to choose between the principles when they conflict.
11
A conflict between ethical principles is called an ethical dilemma. People working in the
healthcare field are often faced with ethical dilemmas, and although the four principles are a
guide, they do not always provide an answer.
For example, a doctor may be unsure whether to recommend withdrawing life-sustaining
treatment from a very premature infant who is not expected to survive. Another example of an
ethical dilemma is how to decide which patient should receive a kidney that has become
available for transplant.
12
Sometimes, ethical issues are divided into those that are professional obligations and those
that are aspirational.
An obligation is a standard that must be met, the minimum of care that must be provided.
Some examples of ethical obligations are to provide competent healthcare to individual
patients, and to make sure patients understand the risks and benefits of treatment.
In contrast, an aspirational goal is a standard that would be met in an ideal world but is not
currently achievable in the real world. Some examples of aspirational goals are providing
equal worldwide access to care, and finding cures for diseases that are currently incurable.
13
A common way for healthcare professionals to resolve ethical dilemmas is to consult with
others. This can be accomplished by having an ethics committee that is consulted to make
ethical decisions. In the United States, all accredited hospitals must have a process for
resolving ethical questions, and this usually takes the form of an ethics committee. Many long-
term-care facilities and home healthcare organizations also have ethics committees.
The members of the ethics committee usually represent the many kinds of people who have a
stake in resolving ethical questions. This can include doctors, nurses, social workers, lawyers,
members of the clergy, and people from the community who are not healthcare professionals.
14
Another way in which healthcare professionals may get guidance about a difficult ethical
situation is to consult a code of ethics created by an organization related to their specific
profession. For example, the American Health Information Management Association has a
code of ethics that is discussed in a later lecture.
When doctors in private practice have ethical questions, they might consult the American
Medical Association Code of Ethics. In addition, they might talk the situation over with their co-
workers. In some cases, they might even consult a medical ethicist [eh-thih-cyst], a person
who is specially trained to deal with ethical questions.
Codes of ethics can be statements of current professional standards, or they can be
aspirational, seeking to raise the standards of the profession. Some codes of ethics contain
both obligatory and aspirational statements. A code that contains both kinds of provisions
should identify the statements that are intended to be aspirational.
A code of ethics may also be called an ethical statement, statement of professional conduct, or
something similar.
15
The Hippocratic [hip-po-crat-ick] oath is one of the historical foundations of medical ethics.
Generally interpreted, it states that doctors have a moral obligation to maximize the benefits
and minimize the harms of treatment. Those core values are still held today, as discussed in
this lecture.
However, other provisions in the oath reflect the beliefs of ancient Greek culture and are no
longer relevant. Some, but not all, medical schools have new doctors take a modernized
version of the oath.
16
There are many definitions of the word “profession.” In this unit, it means an occupation that
requires special knowledge and training. In addition, a profession has standards that must be
met.
A healthcare professional is a person who, by training and experience, has the knowledge to
provide some aspect of healthcare delivery.
Professionalism means acting in a way that meets the standards of the profession. In addition,
professionals are aware of their ethical obligations and strive to fulfill them.
17
A charter created jointly by several medical societies states ten core principles of medical
professional responsibilities. The first five are as follows:
(1) Commitment to professional competence. Individual doctors must do what it takes to keep
up with new discoveries in their field and keep their skills at the level needed to deliver
appropriate care. The medical profession must monitor its members and provide ways for
doctors to meet this goal.
(2) Commitment to honesty with patients. This principle includes the duty of informed consent.
In addition, this principle requires doctors to be honest when medical errors occur.
(3) Commitment to patient confidentiality. Doctors must take steps to protect patients’ private
information.
(4) Commitment to maintaining appropriate relations with patients. Because patients are often
vulnerable and dependent on their healthcare providers, “physicians should never exploit
patients for any sexual advantage, personal financial gain, or other private purpose.”
(5) Commitment to improving quality of care.
.
18
The remaining five principles are as follows:
(6) Commitment to improving access to care. Doctors should work to reduce barriers and
achieve a fair healthcare system.
(7) Commitment to fair distribution of limited resources. This principle requires that doctors
provide cost-effective healthcare and avoid unnecessary tests and procedures.
(8) Commitment to scientific knowledge. Doctors have a duty to “uphold scientific standards,
to promote research, and to create new knowledge and ensure its appropriate use.”
(9) Commitment to maintaining trust by managing conflicts of interest. Doctors should not
“compromise their professional responsibilities by pursuing private gain or personal
advantage.” An example is that doctors should report any relationships they have with
pharmaceutical companies when they are conducting research or reporting the results of their
research in journal articles.
(10) Commitment to professional responsibilities. Medical professionals should work together
to get the most out of patient care, treat each other respectfully, and take part in the regulation
of the profession.
19
This concludes Lecture (a) of Ethics and Professionalism. In summary, people in the
healthcare profession have duties that are based in the core principles of medical ethics:
respect for autonomy, beneficence, non-maleficence, and justice, plus concern for the scope of
their action. Professionalism requires that people in the healthcare industry act in accordance
with the standards of their profession.
The proper applications of ethical principles and standards of professionalism are not always
clear. Individuals can find guidance in codes of ethics, statements of professional standards,
and consultations with colleagues, ethics committees, and ethics experts.
20
References slide. No audio.
21
References slide. No audio.
22
References slide. No audio.
23
Activities
Discussion for Week 4 Discussion Topic
IFSM 305 7980 Information Systems in Health Care …
0 % 0 of 2 topics complete
Topic: Explain the data interchange standards required to enable the flow of the
information.
As part of the Stage 2 assignment, you will identify Data Interchange Standards the
Midtown Family Clinic EHR system will use to exchange information with external
organizations. For this discussion, we will explore several different Data Interchange
Standards, or "Interoperability Standards" as the ONC defines them. First to understand
the top challenges in sharing data, read
http://www.pewtrusts.org/en/research-and-analysis/fact-sheets/2016/11/electronic-
health-records-patient-matching-and-data-standardization-remain-top-challenges This
article highlights the need for data standardization. Next, you will become familiar with
the Interoperability Standards Advisory published and maintained by the Office of the
National Coordinator for Health Information Technology
(ONC) https://www.healthit.gov/isa/ The purpose of the Advisory, as stated on the
website is shown below.
The Interoperability Standards Advisory (ISA) is meant to serve at least the following
purposes:
1. To provide the industry with a single, public list of the standards and
implementation specifications that can best be used to address specific clinical
health information interoperability needs. Currently, the ISA is focused on
Case Study Stage 2 Assignment Assignment
Due November 17 at 11:59 PM
interoperability for sharing information between entities and not on intra-
organizational uses.
2. To reflect the results of ongoing dialogue, debate, and consensus among industry
stakeholders when more than one standard or implementation specification could
be used to address a specific interoperability need, discussion will take place
through the ISA public comments process. The web-version of the ISA will improve
upon existing processes, making comments more transparent, and allowing for
threaded discussions to promote further dialogue.
3. To document known limitations, preconditions, and dependencies as well as
provide suggestions for security best practices in the form of security patterns for
referenced standards and implementation specifications when they are used to
address a specific clinical health IT interoperability need."
GROUP 4: From the many different standards listed in the Advisory, choose one that has
not yet been posted and:
1. Put the Title of the standard in the Subject line for your posting.
2. Conduct some additional research and explain:
a. What the standard is
b. What the standard is used for
c. Why it is important
GROUPS 1, 2 and 3: For at least two postings,
1. Conduct your own research on the standard
2. Critically evaluate and respond to the explanation provided for:
a. What the standard is
b. What the standard is used for
c. Why it is important
3. Provide at least one additional comment on one of the aspects above (what the
standard is, what it is used for, or why it is important)
Your responses should be complete and thorough, and not simply "I agree."
EVERYONE: Review the criteria in the Discussion Grading Rubric, and reply to those who
critique your work or post other points of view. Be sure to demonstrate your
understanding of the topic and analytical thinking.
Attached is the Stage 2 assignment. It uses the Case Study located under Content >
Course Resources > Case Study, and is due as shown in the class schedule/calendar.
When you submit your work, please include your last name in the filename.
Case Study Stage 2 Assignment
Instructions
Stage 2 - Sharing Data.docx (65.51 KB)
Submissions
No submissions yet. Drag and drop to upload your assignment below.
Drop files here, or click below!
Upload Record Audio Choose Existing
You can upload files up to a maximum of 1 GB.
Task: Submit to complete this assignment Assessment
IFSM 305 7980 Information Systems in Health Care …
Attached is the Stage 2 assignment. It uses the Case Study located under Content > Course
Resources > Case Study, and is due as shown in the class schedule/calendar. When you
submit your work, please include your last name in the filename.
Activity Details
Due November 17 at 11:59 PM
Stage 2 Grading
Rubric
Last Visited Nov 4, 2019 11:27 AM
IFSM 305 Stage 2: Sharing Data 11/17/2017 1
Stage 2: Sharing Data Overview
Before you begin work on this assignment, be sure you have read the Case Study and reviewed the feedback received on your Stage 1 assignment. Refer to the System Recommendation Report Table of Contents below to see where you are in the process of developing this report.
As a professional medical consultant, your next step in developing your recommendation for an EHR system is to determine what data will need to be shared with other organizations and how that data will be shared.
System Recommendation Report
Table of Contents
Introduction (Stage 1)
I. Organizational Analysis and Requirements (Stage 1) A. Introduction B. Organizational Strategy C. Strategic Use of Technology D. Components of an Information System E. Requirements F. Summary
II. Sharing Data (Stage 2) A. Introduction B. Need to Share Data C. Types of Data to be Shared D. Data Interchange Standards E. Summary
III. Ethical, Legal and Regulatory Policy Issues (Stage 3) A. Introduction B. Table of Ethical, Legal and Regulatory Policy Issues C. Addressing the Most Difficult Issue D. Summary
IV. System Recommendation (Stage 4) A. Introduction B. Proposed IT solution C. How the Proposed IT Solution Meets the Requirements D. Improvements from Proposed IT Solution E. Implementation Considerations F. Summary
Conclusion (Stage 4) References
IFSM 305 Stage 2: Sharing Data 11/17/2017 2
System Recommendation Report (SRR), Section II – Sharing Data Section II of the SRR document addresses the need for the Midtown Family Clinic to share data with other organizations. As part of analyzing the requirements for the new system, one step is to consider how that system will enable the Midtown Family Clinic to exchange electronic data with other health organizations – such as other providers, pharmacies, insurance companies, and even patients themselves. The case study mentions several of these. For this assignment you will select two types of external organizations and describe what kind of data would flow between the Midtown Family Clinic and those organizations and how that can be done effectively. Stage 2 Assignment Instructions The first step is to incorporate the feedback you received on your Stage 1 assignment, making any needed corrections or adjustments. For this assignment, you will add Section II of the System Recommendation Report (SRR). Using the case study, the overview above, Course Content readings, and external resources, develop your Section II on Sharing Data. Approximate lengths for each section are provided as a guideline; be sure to provide all pertinent information. Apply specific information from the case study to address each area listed below. II. Sharing Data A. Introduction - Introduction to this section describing what is included. (3-4 sentences)
B. Need to Share Data - Review the Midtown Family Clinic Case Study and identify two types of
external organizations (e.g., hospitals, nursing homes, rehabilitation centers, laboratories, pharmacies, health insurance providers, etc.) with which the Midtown Family Clinic needs to communicate and the purpose of the communication. (Introductory sentence and list of two external organizations and the purpose of their communication with the Midtown Family Clinic, providing specifics from the Case Study.)
1. External Organization #1 and purpose of communication. 2. External Organization #2 and purpose of communication.
C. Types of Data to be Shared – In Stage 1, Section C.3., Data, you took an initial look at the types of
data the new EHR system will process. But now we’re going to take that a step further and add a layer of complexity by considering the needs and requirements of different external organizations. Using the two external organizations you listed in Section A above, list five data items, or data elements, that would be shared with each external organization, and explain whether that information is going out from the Midtown Family Clinic or coming in from each of the two external organizations. Feel free to consult the list you developed for Section C.3 of your Stage 1 assignment. Some of these data elements may come from that list if they are appropriate for this purpose; however, other, different, data elements may be listed here. Note: For full credit, a different list of data elements should be provided for each organization (no duplicates in the table below, although data elements may be repeated from Section C.3). (Provide an introductory sentence and copy the table and insert information within.)
IFSM 305 Stage 2: Sharing Data 11/17/2017 3
Organization #1 (replace with your organization from above) Data Element or Item Data Goes TO/FROM Midtown Family Clinic 1. 2. 3. 4. 5. Organization #2 (replace with your organization from above) Data Element or Item Data Goes TO/FROM Midtown Family Clinic 1. 2. 3. 4. 5.
D. Data Interchange Standards - Conduct some external research and identify a data interchange
standard that would apply to the data that is exchanged with each external organization. The standard you select should apply to one or more of the data elements you listed above for each organization. Provide a brief description of what the standard is, what it requires, why it is important and how it applies to the data elements listed and the Midtown Family Clinic EHR system. Note: For full credit, two different data interchange standards are required. (There are some specific data interchange standards that apply to health data exchange; if the same standard applies to the data exchanged with both organizations, explain how it relates to each.) (Introductory sentence and list of two external organizations and the information shown about the Data Interchange Standard selected for each, providing specifics from the Case Study.)
1. External Organization #1 a. Data Interchange Standard and description b. What the Data Interchange Standard requires c. Why the Data Interchange Standard is important d. How the Data Interchange Standard applies to the data elements listed and the
Midtown Family Clinic EHR system 2. External Organization #1
a. Data Interchange Standard and description b. What the Data Interchange Standard requires c. Why the Data Interchange Standard is important d. How the Data Interchange Standard applies to the data elements listed and the
Midtown Family Clinic EHR system E. Summary - briefly summarize the content of this section and tie the information together for the
reader. (3-4 sentences)
Formatting Your Assignment
For academic writing, the writer is expected to write in the third person. In third person, the writer avoids the pronouns I, we, my, you, your, and ours. The third person is used to make the writing more objective by taking the individual, the “self,” out of the writing. This method is very helpful for academic writing, a form in which facts, not opinion, drive the tone of the text. Writing in the third person allows the writer to come across as unbiased and thus more informed. The Report is to be written for the
IFSM 305 Stage 2: Sharing Data 11/17/2017 4
Midtown Family Clinic, and reference should not be made by name to individuals who own or work in the Clinic. • Include the Introduction and Section I, revised according to any feedback received, and add to it
Section II. • Write a short concise paper: Use the recommendations provided in each area for length of
response. Content areas should be double spaced; table entries should be single-spaced. It’s important to value quality over quantity. Section II should not exceed 4 pages.
• Ensure that the table is preceded by an introductory sentence that explains what is contained in the table, so the reader understands why the table has been included.
• Use at least two resources with APA formatted citation and reference. Use at least one external reference and one from the course content.
• Compare your work to the Assignment Instructions above and the Evaluation Criteria/Grading Rubric below to be sure you have met content and quality criteria. Do not overlook this step. Read your work out loud or have your computer read it to you. Fix the grammar and other areas identified.
• Submit your paper as a Word document, or a document that can be read in Word. • Your submission filename should be as follows: Lastname_firstname_Stage_2 EVALUATION CRITERIA/GRADING RUBRIC:
Criteria
90-100%
Far Above Standards
80-89%
Above Standards
70-79%
Meets Standards
60-69%
Below Standards
< 60%
Well Below Standards
Possible Points
Section Introduction and Summary
9-10 Points
Provides effective introduction and summary to Section II; is clear, logical, derived from the Case Study; demonstrates a sophisticated level of writing.
8.5 Points
Provides an introduction and summary to Section II; is clear, logical, and derived from the Case Study.
7.5 Points
Provides an introduction and summary to Section II; is adequate, and derived from the Case Study.
6.5 Points
Not clear, logical and/or derived from the Case Study. Or, either the introduction or summary is not included.
0-5 Points
Not included, or demonstrates little effort.
10
Need to Share Data
Two external organizations and the purpose of their communication
9-10 Points
Organizations and communication are clearly appropriate and explained in detail using course vocabulary; demonstrates understanding of course concepts, analysis, and/or critical thinking.
8.5 Points
Organizations and communication are appropriate and well explained using course vocabulary; demonstrates understanding of course concepts and critical thinking.
7.5 Points
Organizations and communication are provided.
6.5 Points
Fewer than two organizations are identified, or are incorrect; and/or explanation of the communication between them and the Midtown Family Clinic may lack demonstration of understanding of course concepts, analysis, and/or critical thinking.
0-5 Points
Identification of external organizations and/or explanation of communication is incomplete or inadequate.
10
IFSM 305 Stage 2: Sharing Data 11/17/2017 5
Types of Data to be Shared
5 data elements for each organization and direction of flow
27-30 Points
Data elements are correctly identified and are different for each organization; the direction of the data flow is appropriate to the case study; strongly demonstrates understanding of course concepts, analysis, and critical thinking.
24-26 Points
Data elements are correctly identified; the direction of the data flow is appropriate to the case study; demonstrates understanding of course concepts, analysis, and critical thinking.
21-23 Points
Data elements are identified; direction of the flow of data is appropriate to the case study.
18-20 Points
Fewer than 5 data elements may be presented for each of the two external organizations; flow of data may be less than correct, or not appropriate to the case study.
0-17 Points
Data elements and flows are not presented or are not appropriate to the case study, or are otherwise inadequate.
30
Data Interchange Standards
Two standards with description, requirement, importance and applicability
27-30 Points
Two different data interchange standards are listed and explained, and are applicable to the case study, with complete explanations of the standards, what they require and why they are important.
24-26 Points
At least one data interchange standard is explained, along with how it applies to the data interchange with both external organizations, is applicable to the case study, with a complete explanation of the standard, what it requires and why it is important.
21-23 Points
At least one data interchange standard is explained, along with how it applies to the data interchange with both external organizations, is applicable to the case study, with an explanation of the standard, what it requires and why it is important.
18-20 Points
At least one data interchange standard is explained, but how it applies to the data interchange with both external organizations or to the case study is incomplete; and/or explanation of the standard, what it requires and why it is important may be incomplete.
0-17 Points
Data interchange standard is not identified; only one organization/data standard are identified; or explanation is severely lacking.
30
Research
Two or more sources--one source from within the IFSM 305 course content and one external (other than the course materials)
9-10 Points
Required resources are incorporated and used effectively. Sources used are relevant and timely and contribute strongly to the analysis. References are appropriately incorporated and cited using APA style.
8.5 Points
At least two sources are incorporated and are relevant and somewhat support the analysis. References are appropriately incorporated and cited using APA style.
7.5 Points
Only one resource is used and properly incorporated and/or reference(s) lack correct APA style.
6.5 Points
A source may be used, but is not properly incorporated or used, and/or is not effective or appropriate; and/or does not follow APA style for references and citations.
0-5 Points
No course content or external research incorporated; or reference listed is not cited within the text.
10
Format 9-10 Points
Well organized and easy to read. Very few or no errors in sentence structure, grammar, and spelling; double- spaced, written in third person and
8.5 Points
Effective organization; has few errors in sentence structure, grammar, and spelling; double- spaced, written in third person and
7.5 Points
Some organization; may have some errors in sentence structure, grammar and spelling. Report is double spaced and
6.5 Points
Not well organized, and/or contains several grammar and/or spelling errors; and/or is not double-spaced and
0-5 Points
Extremely poorly written, has many grammar and/or spelling errors, or does not convey the information.
10
IFSM 305 Stage 2: Sharing Data 11/17/2017 6
presented in a professional format.
presented in a professional format.
written in third person.
written in third person.
TOTAL Points Possible
100
Assignments Case Study Stage 2 Assignment
Case Study Stage 2 Assignment
Hide Assignment Information
Instructions
Due Date
Nov 17, 2019 11:59 PM
Attachments
Stage 2 - Sharing Data.docx (65.51 KB)
Download All Files
Hide Rubrics
Rubric Name: Stage 2 Grading Rubric
Criteria
Section Introduction and Summary
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 10
IFSM 305 7980 Information Systems in Health Care …
Attached is the Stage 2 assignment. It uses the Case Study located under Content > Course Resources > Case Study, and is due as shown in the class schedule/calendar. When you submit your work, please include your last name in the filename.
Submit Cancel
Well Above Standard 10 points
9-10 Points Provides effective introduction and summary to Section II; is clear, logical, derived from the Case Study; demonstrates a sophisticated level of writing.
Need to Share Data - Two external organizations and the purpose of their communication
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 10
Well Above Standard 10 points
9-10 Points Organizations and communication are clearly appropriate and explained in detail using course vocabulary; demonstrates understanding of course concepts, analysis, and/or critical thinking.
Types of Data to be Shared - 5 data elements for each organization and direction of flow
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 30
Well Above Standard 30 points
27-30 Points Data elements are correctly identified and are different for each organization; the direction of the data flow is appropriate to the case study; strongly demonstrates understanding of course concepts, analysis, and critical thinking.
Data Interchange Standards - Two standards with description, requirement, importance and
applicability
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 30
Well Above Standard 30 points
27-30 Points Two different data interchange standards are listed and explained, and are applicable to the case study, with complete explanations of the standards, what they require and why they are important.
Research - Two or more sources--one source from within the IFSM 305 course content and one
external (other than the course materials)
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 10
Well Above Standard 10 points
9-10 Points Required resources are incorporated and used effectively. Sources used are relevant and timely and contribute strongly to the analysis. References are appropriately incorporated and cited using APA style.
Format
Well Above Stand Above Standard Meets Standard Below Standard Far Below Standar / 10
Well Above Standard 10 points
9-10 Points Well organized and easy to read. Very few or no errors in sentence structure, grammar, and spelling; double-spaced, written in third person and presented in a professional format.
Total / 100
Overall Score
Far Above Standard
90 points minimum
Above Standard
80 points minimum
Meets Standard
70 points minimum
Below Standard
60 points minimum
Far Below Standard
0 points minimum
Add a File Record Audio
Submit Assignment
Files to submit
(0) file(s) to submit
After uploading, you must click Submit to complete the submission.
Comments
Paragr
Font Fa Font
- IFSM 305 7980 Information Systems in Health Care Organizations (2198) - IFSM 305 7980 Information Systems in Health Care Organizations (2198)
- comp6_unit5a_lecture_slides
- comp6_unit5b_lecture_slides
- comp12_unit5a_lecture_slides
- comp2_unit9a_lecture_slides
- comp2_unit9b_lecture_slides
- comp2_unit9c_lecture_slides
- comp2_unit9d_lecture_slides
- comp4_unit8a_lecture_slides
- comp4_unit8b_lecture_slides
- comp4_unit8c_lecture_slides
- comp8_unit6a_lecture_slides
- comp8_unit6b_lecture_slides
- comp2_unit8a_lecture_slides
- IFSM 305 7980 Information Systems in Health Care Organizations (2198) - IFSM 305 7980 Information Systems in Health Care Organizations (2198)2
- Case Study Stage 2 Assignment - IFSM 305 7980 Information Systems in Health Care Organizations (2198)
- Stage 2 - Sharing Data
- I. Organizational Analysis and Requirements (Stage 1)
- A. Introduction
- B. Organizational Strategy
- C. Strategic Use of Technology
- D. Components of an Information System
- II. Sharing Data (Stage 2) /
- A. Introduction
- B. Need to Share Data
- C. Types of Data to be Shared
- D. Data Interchange Standards
- E. Summary
- III. Ethical, Legal and Regulatory Policy Issues (Stage 3)
- A. Introduction
- B. Table of Ethical, Legal and Regulatory Policy Issues
- C. Addressing the Most Difficult Issue
- IV. System Recommendation (Stage 4)
- A. Introduction
- B. Proposed IT solution
- C. How the Proposed IT Solution Meets the Requirements
- E. Implementation Considerations
- Criteria
- TOTAL Points
- Case Study Stage 2 Assignment - IFSM 305 7980 Information Systems in Health Care Organizations (2198) - UMGC Learning Management System