CPHIMS Notebook

Nine chapters of the Review Guide rebuilt as lesson blocks, plus thirteen supplemental lessons closing the Addendum B gaps. Practice questions draw on the full master test bank: canonical, stress, supplemental and scenario pools. Every lesson runs the same way: big picture, walkthrough with a question block after each topic, memory tips, key concepts, practice questions with trap feedback, and a source fidelity line.

9chapters

94lessons

1060practice items

13supplemental

✎ Practice Exam Blueprint-weighted practice exams and drills, pulled from the same master bank, with its own scoring and review.

How to work through it

Read the big picture, then the walkthrough. Answer each question block out loud before moving on; that is the teach-back.
Do the practice questions only after the teach-back. When you miss one, log the trap family rather than the item.
Each question is tagged Canonical, Stress, Supplemental or Scenario. Canonical is blueprint-weighted and closest to exam framing; Stress sweeps every fact; Scenario applies it to a situation.
Scenario items carry a shaded vignette above the question. A few vignettes span more than one lesson, one sub-question per lesson.
Memory tips are for the list-and-number items that resist understanding. Everything else should come from the walkthrough.
Supplemental lessons carry a banner. They cover material the Review Guide does not, and they have their own items.
Use [ and ] to move between lessons. Printing hides the practice questions and leaves ruled space under each question block.

Chapter 1 · Healthcare Environment · Lesson 1 of 9

Health, the Four Pillars and the Environment You Work In

Big picture

This opening section defines the ground the whole credential stands on: what health means, what pressures the healthcare system is under, and where the health IT professional sits inside that pressure. It is the first section of Chapter 1 and feeds the Healthcare Environment domain, which the exam treats as context for every later chapter. The larger problem it addresses is that technology decisions are made inside constant trade-offs between competing goods, so a solution that improves one measure at the expense of another is not automatically a win. The concept most easily confused with the four pillars is any other named four-part or six-part quality list, because the exam populates distractors with real frameworks drawn from elsewhere in the guide.

Walkthrough

How the source defines health

The World Health Organization defines health as a state of complete physical, mental and social well-being.
The definition adds that health is not merely the absence of disease or infirmity.
The WHO has not amended this definition since 1948.
Care sought only at an advanced stage of disease costs more and produces less desirable outcomes.
Healthcare practice is increasingly focused on the activities with the greatest impact on the health of communities and patient populations.
A state of health is no longer limited to office visits and hospital admissions; it extends to wellness encounters with nonphysician providers, virtual encounters through telehealth or mobile health technologies, and safety and preventive care outreach programs.

The definition is doing two jobs at once. It states what health is, and it rejects a narrower definition in the same sentence. That built-in rejection is why the phrase about absence of disease shows up so often as a wrong answer.

Example

A senior living operator that only counts hospital transfers is measuring illness. Adding fall-prevention outreach, a wellness visit with a nurse practitioner and a telehealth check for residents who cannot travel is measuring against the WHO definition.

Question:

State the WHO definition of health in full, including the clause about what health is not.
Why does the source argue that waiting until advanced disease is economically as well as clinically costly?

The four pillars and the stakeholders pressing on them

The four pillars are quality, access, cost and value.
The pillars require dynamic trade-offs; professionals are pressured to deliver the highest quality to the greatest portion of the supported population within tight cost constraints.
Health IT carries the added burden of demonstrating the value of the technology itself.
The source pictures the pillars as a four-legged stool onto which stakeholder demands are placed.
Named stakeholders: governments, consumer groups, professional associations, regulatory organizations, payers and insurers, and suppliers.

The stool image matters because it states the relationship between the pillars. Loading more weight on one leg does not remove weight from the others; it changes what the other three have to carry.

Example

A community adds evening clinic hours to improve access. Staffing those hours raises cost, and if the evening shift is thinly staffed, quality drops. The trade-off is the point, not a failure of planning.

Question:

Name the four pillars in the source's wording and explain what the four-legged stool metaphor asserts about them.
List the six stakeholder groups the source names as placing demands on the system.
How does the value pillar create a distinct obligation for health IT compared with clinical departments?

Comparing national systems with OECD indicators

The Organisation for Economic Cooperation and Development provides key indicators on health system performance across countries.
Those indicators give a basis for comparing international approaches to organizing and resourcing national healthcare.
The comparison shows substantial variance in spending by country.
It also shows variance in the proportion of public to private contribution to national health expenditures.
Investment has produced large reductions in cardiovascular and infant mortality rates.
Lifestyle and risk factors remain: more than 18 percent of adults smoke daily, and almost one-third of children aged 5 to 9 are overweight.
The overweight rate in that age group rose from 20.5 percent to 31.4 percent between 1990 and 2016.

Spending level and funding mix are two different axes. A country can spend heavily and still be mostly publicly funded, or spend less with a large private share, which is why the source reports both.

Question:

What two things does the OECD comparison make visible about national health systems?
Contrast the mortality trend with the lifestyle and risk factor trend the source reports.

Memory tips

Four pillars: Quality, Access, Cost, Value. Anchor phrase for the stem: dynamic trade-offs. If the stem says trade-offs, the answer is the pillar list, not a quality framework.
1948 is the only date attached to the WHO definition, and the definition has never been amended. One date, one fact.
Stakeholder six, grouped as two threes: who governs (governments, regulatory organizations, professional associations) and who transacts (consumer groups, payers and insurers, suppliers).
Overweight children 5 to 9: 20.5 climbing to 31.4, 1990 to 2016. Two decimals, two dates, one direction.

Key concepts

Health: a state of complete physical, mental and social well-being, and not merely the absence of disease or infirmity, per the WHO definition unchanged since 1948
Holistic focus of care: the shift of healthcare attention toward activities with the greatest impact on community and population health, including wellness, virtual and preventive encounters
Four pillars: quality, access, cost and value, the competing goods that require dynamic trade-offs in the healthcare environment
Four-legged stool: the source's image for the pillars, with stakeholder demands placed on top of them
Stakeholders: governments, consumer groups, professional associations, regulatory organizations, payers and insurers, and suppliers
OECD indicators: cross-country measures of health system performance showing variance in spending and in the public to private funding mix

Practice questions

3 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: WHO definition of health and its 1948 currency · the cost and outcome argument for earlier engagement · extension of health encounters beyond office and hospital · the four pillars and their trade-offs · the four-legged stool and its stakeholder load · named stakeholder groups · OECD as the basis for international comparison · spending and public-private variance · mortality gains and lifestyle risk factors.

Read the original source

Introduction

In order to best understand the context of healthcare information and management systems, it is necessary to first understand the concept of health. The World Health Organization (WHO) asserts that “health is a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity.”1 The WHO has not amended this definition since 1948.

Why is it important that we more fully understand this more holistic concept of health? If we do not present for care until we are in an advanced stage of disease or arrive with injuries from unsafe working or living practices, the cost of providing that care is likely to be high and the health outcomes often less than desired. The practice of healthcare, and thus the systems and management processes supporting it, is increasingly focused on those activities that have the greatest impact on the overall health of the community and patient populations. A state of health is not best achieved by limiting our engagement to patients’ visits to the doctor's office and admissions to hospitals, but is increasingly extended to wellness encounters with nonphysician healthcare providers, virtual encounters through telehealth or mobile health technologies and safety and preventive care outreach programs. The increasing strain of healthcare costs on national economies is forcing us to continually reevaluate our healthcare delivery paradigm to optimize health outcomes at an affordable cost. This is the macroeconomic context in which health information professionals and technologists will be performing their art.

The healthcare environment is an exceptionally complex one in which multiple players compete for placement on center stage. The four pillars of quality, access, cost and value require dynamic trade-offs in which healthcare professionals are under constant pressure to deliver the highest quality of care to the greatest portion of their supported population within tight cost constraints, while having to demonstrate the value of health information technology (IT). Placed upon this already complex four-legged stool are demands from multiple stakeholders, including governments, consumer groups, professional associations, regulatory organizations, payers/insurers and suppliers.

The Organisation for Economic Cooperation and Development (OECD) provides a solid basis for comparing international approaches with organizing and resourcing national healthcare with several key indicators on health system performance across countries. Figure 1.1 illustrates the substantial variance in spending by country and the proportion of public to private contribution to overall national health expenditures.

These investments have seen great reductions in cardiovascular and infant mortality rates, but lifestyle and risk factors show that more than 18% of adults continue to smoke daily,2 while almost one-third of children 5–9 years are overweight, with the rate of overweight children increasing from 20.5% to 31.4% from 1990 to 2016.2

Therefore, it is not hard to develop a sense of the complexities of the healthcare environment in which we toil. The breadth of stakeholders, the balance of public versus private funding and the active engagement to improve the health of populations, one individual at a time, produce a daunting task. This is the arena the health information professional and technologist enter to ensure that the best possible information management and systems support are available to improve the quality of life for the greatest number of our world's citizens.

Chapter 1 · Healthcare Environment · Lesson 2 of 9

Hospitals and How They Are Classified

Big picture

This section opens the survey of healthcare organizations by teaching how hospitals are sorted. The source organizes the entire care landscape through the patient's eyes, splitting it into hospital-based inpatient care and office-based outpatient care, then adding ancillary services, payers and regulators. Classification matters because payment, regulation and reporting obligations follow the category a facility falls into, which is the practical reason an informatics professional cares. The distinction most often blurred is ownership versus funding source: who owns a hospital and who pays for its care are separate questions, and the source uses Canada specifically to prove it.

Walkthrough

How the source organizes healthcare organizations

The number and types of organizations providing, supporting and paying for care is large, complex and constantly evolving.
The simplest way to categorize them is through the eyes of the patient.
Hospital-based care is referred to as inpatient care.
Care from doctors' offices is referred to as outpatient or ambulatory care.
Providers of ancillary services are included because of the diagnostic services and pharmaceuticals the care process requires.
Regulators and payers of care complete the picture.
Structures vary by country and often by geographic location within a country.

This patient's-eye ordering is also the order the chapter follows, so a question about what comes next in the source is usually answered by walking this list.

Question:

Reconstruct the source's categories of healthcare organizations in order, and state the organizing principle behind that order.

Classification by ownership

A single hospital may be classified in more than one way at the same time; for example private, not-for-profit and specialty.
Ownership splits into public, meaning government-managed, versus private.
In public hospitals, governments at national, provincial, state or other level own the facility and are responsible for operations.
Providers in public hospitals are generally private practitioners, although in some countries they may also be government employees.
The National Health Service of the United Kingdom and the U.S. Veterans Health Administration are the source's examples of government-employed providers.
Private hospitals span a broad spectrum of private practitioners or groups of providers, and in some countries are further classified as for profit versus nonprofit.
For-profit private hospitals are also called investor-owned and often sit within a multihospital system, with varying degrees of interrelationship among the system's hospitals.
Nonprofit private hospitals are not investor owned; they organize under national and state laws as nonprofit corporations, generally avoiding federal and property taxes.
Canada's hospitals are almost exclusively private nonprofit organizations, although publicly financed through provincial and territorial governments.
Just more than half of hospitals in the United States operate as private, nonprofit organizations.

The Canadian example is the load-bearing one. Public financing does not make a hospital public, because ownership and funding are independent axes.

Example

A nonprofit community hospital in the United States pays no federal or property taxes, receives most of its revenue from Medicare and private insurers, and is still a private hospital. Its revenue source says nothing about its ownership category.

Question:

How does the source describe who provides care inside public hospitals, and what exception does it name?
Explain why Canada's hospitals are classified as private nonprofit despite public financing.
What is the synonym the source gives for a for-profit private hospital?

Classification by service, teaching status and geography

Types of service provided: most hospitals are general hospitals supporting common medical and surgical needs.
Psychiatric hospitals focus on mental healthcare.
Rehabilitation hospitals generally focus on restoring neurological and musculoskeletal function following treatment in an acute care facility.
Children's hospitals focus on the care and treatment of children.
Teaching status: teaching hospitals train future physicians and other providers in addition to delivering inpatient clinical services.
Teaching hospitals are often associated with academic institutions and may be further classified as academic medical centers or university hospitals.
Many teaching institutions also contribute substantially to medical research and publish knowledge that advances medical science.
Geographic location: urban hospitals sit in large cities, rural hospitals substantially distant from major urban areas with greater resources.
Operating challenges differ enough between urban and rural settings to require programs of specialization.
Meeting government standards for urban or rural classification may give hospitals access to special government funding programs.

Specialty hospitals are defined by the function they restore or the population they serve, not by acuity. Rehabilitation follows acute treatment rather than replacing it.

Question:

Name the four classification systems for hospitals the source gives, with their subcategories.
Why does the source say urban and rural designations matter beyond description?
Compare a rehabilitation hospital with a psychiatric hospital using the source's own wording.

Memory tips

Four classification axes: Ownership, Service, Teaching, Geography. First letters spell OSTG; read it as Own, Serve, Teach, Go. One hospital can sit in all four at once.
Ownership tree: public equals government-managed. Private splits into for profit, also called investor-owned, and nonprofit.
Canada is the ownership-versus-funding test case: privately owned, publicly financed. If a stem pairs a country with a funding word, check which axis it is asking about.
Two numbers: just more than half of U.S. hospitals are private nonprofit; Canada is almost exclusively private nonprofit.
Rehabilitation equals neurological plus musculoskeletal, and it comes after acute care. Sequence cue: acute first, rehab second.

Key concepts

Patient's-eye categorization: the source's organizing method, splitting the landscape into inpatient, outpatient or ambulatory, ancillary services, payers and regulators
Inpatient care: hospital-based care
Outpatient or ambulatory care: care delivered from doctors' offices and similar non-hospital settings
Public hospital: a hospital owned and operated by government at national, provincial, state or other level, generally staffed by private practitioners and in some countries by government employees
Private hospital: a hospital owned outside government, further classified in some countries as for profit or nonprofit
For-profit or investor-owned hospital: a private hospital owned by investors, often part of a multihospital system
Nonprofit private hospital: a private hospital organized as a nonprofit corporation, generally exempt from federal and property taxes
General hospital: a hospital supporting the most common medical and surgical care requirements
Specialty hospital: a hospital focused on a defined area of care, such as psychiatric, rehabilitation or children's
Teaching hospital: a hospital that trains future physicians and other providers, often classified as an academic medical center or university hospital
Urban and rural classification: geographic designations that reflect different operating challenges and can unlock special government funding programs

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: patient's-eye categorization of organizations · inpatient and outpatient constructs · multiple simultaneous classification · ownership: public versus private, provider staffing in each · NHS and VHA as government-employer examples · for-profit and investor-owned synonymy · nonprofit tax treatment · Canada's private nonprofit hospitals · U.S. nonprofit share · service classification and the three named specialty types · teaching status and its subclassifications · research and publication role · urban and rural classification and funding access.

Read the original source

Healthcare Organizations

The number and types of organizations involved in the provision of care, supporting the provision of care and paying for the care provided is large, complex and constantly evolving. The simplest way to categorize these is through the eyes of the patient. When speaking of accessing care, often a patient will say, “I went to see my doctor at her office” or “I was in the hospital last week to have my appendix out.” So, in a broad sense, we have the constructs of hospital-based care—often referred to as inpatient care—and care from doctors’ offices—referred to as outpatient or ambulatory care. Additionally, given the diverse types of diagnostic services and pharmaceuticals needed to support the healthcare process, providers of ancillary services are included as well. Lastly, regulators and payers of care are discussed. The interrelationships among these diverse players will be expanded upon in the next section. The following is an overview of many of these structures, which vary not only by country but also often by geographic location within countries.

Hospitals

While hospitals may be categorized in any number of ways, a single hospital may also be classified in more than one way. For example, a hospital may be a private, not-for-profit and specialty hospital, thus falling into three categories. Notable systems for classifying hospitals include classification by the following:

Ownership. Public (government-managed) versus private hospitals.

In public hospitals, governments (at the national, provincial, state or other level) own and are responsible for the operations. The healthcare providers in such hospitals are generally private practitioners, although in some countries the providers may be government employees as well (e.g., in the National Health Service [NHS] of the United Kingdom or the U.S. Veterans Health Administration hospitals).

In private hospitals, staffing arrangements span a broad spectrum of private practitioners or groups of healthcare providers. Private hospitals in some countries are further classified as for profit versus nonprofit.

For-profit private hospitals, also referred to as investor-owned hospitals, often exist as part of a multihospital system with varying degrees of interrelationship among the system's hospitals. Examples of large, investor-owned hospital systems include the Hospital Corporation of America (http://hcahealthcare.com/) and BMI Healthcare in the United Kingdom (http://www.bmihealthcare.co.uk/).

Nonprofit private hospitals are not investor owned, but rather exist under laws at national and state levels allowing them to organize as nonprofit corporations, generally providing them the advantage of avoiding federal and property taxes. Canada's hospitals, although publicly financed, are almost exclusively private, nonprofit organizations,3 albeit funded through the provincial/territorial governments. Just more than half of the hospitals in the United States operate as private, nonprofit organizations.4

Types of service provided. Hospitals are often classified by the types of service they provide. While the majority of hospitals will be general hospitals supporting the most common types of medical and surgical care requirements, hospitals specializing in more focused areas of care are becoming more prevalent. Such hospitals include psychiatric hospitals, which focus on mental healthcare; rehabilitation hospitals, which generally focus on restoring neurological and musculoskeletal functions following treatment in an acute care facility; and children's hospitals, which focus on the care and treatment of children.

Teaching status. In addition to providing inpatient clinical services, teaching hospitals train future physicians and other healthcare providers. Often associated with academic institutions, teaching hospitals may be further classified as academic medical centers or university hospitals. Many such institutions also contribute substantially to medical research and publish much of the knowledge that advances the science of medicine.

Geographic location. Hospitals may be further classified as urban hospitals when located in large cities or as rural hospitals when substantially distant from major urban areas with greater resources. While such classifications appear mundane, the challenges of operating in urban and rural environments are different enough to require programs of specialization. Meeting government standards for classification as urban or rural may provide such hospitals access to special government funding programs.

Chapter 1 · Healthcare Environment · Lesson 3 of 9

Ambulatory Care, Community Health Organizations and Ancillary Services

Big picture

This section covers everything that is not a hospital bed: the ambulatory settings where most care now happens, the community organizations serving defined local populations, and the diagnostic and pharmacy services that both depend on. It sits in the middle of the Healthcare Organizations survey and supplies the settings that later chapters use as examples for workflow, interfaces and integration. The larger problem it addresses is the migration of care away from expensive acute settings toward cheaper and more convenient ones, which is what creates the demand for data that follows the patient. Community health center and critical access hospital are the two designations most often swapped in answer options, since both attach to underserved or rural populations but carry different definitions.

Walkthrough

The shift to outpatient and ambulatory care

Care that does not require the intensive management of a hospital setting is generally received in an outpatient or ambulatory setting, most frequently a doctor's office.
Most primary care, delivered by primary care providers or general practitioners, is provided in the ambulatory setting.
Most referrals from those providers to clinical specialists for evaluation are also completed in the ambulatory setting.
The past decade has seen a dramatic shift from acute care to less expensive, more patient-friendly settings.
Less complicated surgical procedures that once required an overnight stay have moved to the outpatient setting.
Even major surgeries such as total joint replacement are now routinely performed in an ambulatory surgery center with same-day discharge.
Urgent care and injury clinics are opening at a tremendous rate in response to demand for flexible hours.
Nontraditional settings are emerging, including drugstore minute clinics and other walk-in options.
Patients accustomed to an always-on, always-available experience now demand the same from healthcare.
Direct appointment booking and virtual visits using video calling apps are proliferating.
Patients are no longer content to call an office and wait for a callback or wait weeks for a specialist.
Practices responsive to this model are the ones that will thrive.

The source names three models of outpatient care: single independent provider offices, larger multi-provider group practices with a broader range of specialists, and hospital emergency departments, which it flags as not a preferred approach from an expense perspective.

Example

A patient needing a knee replacement is scheduled at an ambulatory surgery center, books the pre-op visit through a portal, and has the post-op check by video. Ten years earlier the same episode was an inpatient admission with an in-person follow-up.

Question:

Name the three models of outpatient care the source lists and the reservation it attaches to one of them.
What patient expectation does the source credit for the growth in virtual visits and direct booking?
Give an example of the acute-to-ambulatory shift using a procedure the source names.

Community health organizations

A community generally refers to the specific geographic location in which healthcare is delivered.
Organizations serving local populations are broadly referred to as community health organizations.
Community-centered hospitals and clinics provide most of the care available to local populations in most nations.
Some nations give formal designations that impose both legally constrained definitions and operational characteristics.
In Canada, a community health center is a key provider of local health services, aspiring to support access and comprehensive care, including health promotion and illness prevention, through a publicly administered process.
In the United States, community health centers are generally associated with medically underserved areas as defined by the Health Resources and Services Administration.
U.S. centers strive to provide comprehensive, culturally competent, quality primary healthcare to medically underserved communities and vulnerable populations.
Small community hospitals in rural areas of the United States may apply for designation as critical access hospitals, which allows higher reimbursement rates.

Two designations, two different tests. The community health center designation turns on serving a medically underserved area; critical access status turns on being a small rural hospital and pays off in reimbursement.

Question:

How does the source define a community in the healthcare context?
Compare the Canadian and U.S. descriptions of a community health center.
What does critical access hospital designation give a facility, and which facilities may apply?

Diagnostic and pharmaceutical services

Diagnostic services and pharmaceutical treatments are commonly referred to as ancillary services.
Larger hospitals generally have these capabilities in house.
Smaller hospitals and outpatient care centers usually rely on external providers of these services.
Key services in this area are laboratory and anatomic pathology services, diagnostic imaging or radiology services, and pharmacies.
Close associations with these providers are formed with provider offices and hospitals to ensure effective and comprehensive care delivery.

The reliance on external ancillary providers is what makes results delivery and prescription routing the highest-volume interfaces in an ambulatory practice.

Question:

Name the services grouped under ancillary services and explain why smaller organizations depend on external providers for them.

Memory tips

Ancillary trio: Lab and pathology, Imaging and radiology, Pharmacy. Read it as LIP: what the patient's care plan needs but the office may not own.
Three outpatient models: solo office, group practice, emergency department. The ED is the one carrying the expense caveat.
Designation pairs: CHC goes with medically underserved, defined by HRSA. CAH goes with small and rural, and pays in higher reimbursement.
Canada's CHC keywords: access, comprehensive care, health promotion, illness prevention, publicly administered.

Key concepts

Ambulatory care: care delivered outside the intensive management of a hospital setting, most frequently in a doctor's office
Primary care: care practiced by primary care providers or general practitioners, mostly in the ambulatory setting
Ambulatory surgery center: an outpatient facility where procedures including major surgeries such as total joint replacement are performed with same-day discharge
Models of outpatient care: single independent provider offices, multi-provider group practices, and hospital emergency departments, the last not preferred on expense grounds
Community: the specific geographic location in which healthcare is delivered
Community health center: a formally designated local provider; in Canada supporting access, comprehensive care, health promotion and illness prevention under public administration, and in the United States serving medically underserved areas defined by HRSA
Critical access hospital: a small rural U.S. community hospital designation that allows higher reimbursement rates
Ancillary services: diagnostic and pharmaceutical services, namely laboratory and anatomic pathology, diagnostic imaging or radiology, and pharmacy

Practice questions

12 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: definition of the ambulatory setting · primary care and referral location · the decade-long shift from acute to ambulatory · ASC and same-day joint replacement · urgent care growth and nontraditional settings · always-on patient expectations, virtual visits and direct booking · three models of outpatient care including the ED expense caveat · definition of community · Canadian CHC characteristics · U.S. CHC and HRSA underserved-area association · critical access hospital designation and reimbursement · ancillary services and the three named service lines · external reliance by smaller organizations.

Read the original source

Outpatient or Ambulatory Care—A Shift in the Care Setting

When a patient's care does not require the intensive management of a hospital setting that care is generally received in an outpatient or ambulatory care setting—most frequently in a doctor's office. Most primary care—the care practiced by primary care providers (PCPs) or general practitioners (GPs)—is provided in the ambulatory setting. Similarly, most PCP/GP referrals to clinical specialists for evaluation are completed in the ambulatory setting as well. The past decade has seen a dramatic shift from the acute care setting to less-expensive, more patient-friendly care settings. In the last few years, many less complicated surgical procedures that previously required an overnight hospital stay have been moved to the outpatient setting as well. Even major surgeries such as total joint replacement are now routinely performed in an ambulatory surgery center (ASC) with the patient going home the same day. Patients are demanding more flexible hours, and urgent care or injury clinics are opening up at a tremendous rate. Nontraditional care settings are springing up, with drugstores offering “minute clinics” and other walk-in options. Today's patient is accustomed to an always-on, always available experience and demands that from healthcare. There is a proliferation of direct appointment booking and “virtual” visits using video calling apps. These patients are no longer content to call a physician office and wait to be called back, or to wait weeks to see a specialist. Practices that are responsive to this new model will be the ones who thrive. There are multiple models of outpatient care, including single independent provider offices, larger multi-provider group practices in which a broader range of specialists may be available, and—while not a preferred approach from an expense perspective—hospital emergency departments.

Community Health Organizations

In the healthcare environment, a “community” generally refers to the specific geographic location in which healthcare is delivered. Thus, healthcare organizations serving the population of local areas tend to be broadly referred to as community health organizations. Community-centered hospitals and clinics in most nations provide most of the care available to their local populations. Some nations provide more formal designations of community healthcare organizations that impose both legally constrained definitions and operational characteristics. In Canada, a community health center (CHC) is a key provider of local health services and aspires to support access and comprehensive care, including health promotion and illness prevention, through a publicly administered process.5 In the United States, CHCs are generally associated with medically underserved areas as defined by the Health Resources and Services Administration (HRSA). These health centers strive to provide comprehensive, culturally competent, quality primary healthcare services to medically underserved communities and vulnerable populations.6 Small community hospitals located in rural areas of the United States may apply for designation as critical access hospitals (CAHs), allowing them to receive higher reimbursement rates.

Diagnostic and Pharmaceutical Services

The most effective healthcare treatment quite frequently requires the aid of diagnostic services and pharmaceutical treatments, commonly referred to as ancillary services. While larger hospitals will generally have these capabilities, smaller hospitals and outpatient care centers will usually rely on external providers of such services to support comprehensive care to their patients. Key services provided in this area include laboratory and anatomic/anatomical pathology services, diagnostic imaging/radiology services and pharmacies. Close associations with these service providers are formed with provider offices and hospitals to ensure effective and comprehensive healthcare delivery.

Chapter 1 · Healthcare Environment · Lesson 4 of 9

Healthcare Payers

Big picture

This section closes the survey of organizations by asking where the money comes from, viewed from the delivery organization's side of the transaction. It sits at the end of the Healthcare Organizations section and supports later chapters on reimbursement, analytics and the business case for systems. The larger problem it addresses is that payment structure determines what data an organization must capture and to whom it must send it, so the payer mix shapes the interface and reporting workload. The pairing most often confused is Medicaid and CHIP, since both are shared federal and state programs for populations defined by income and age.

Walkthrough

The three sources of payment

From the delivery organization's perspective, payments come from three types of entities.
Government-financed and managed programs.
Insurance programs administered by private entities.
Personal funds.

The framing is deliberate. These are not three kinds of insurance; they are three kinds of payer, and personal funds is a payer type in its own right.

Question:

Name the three payer types the source gives and state the perspective from which they are defined.

Government-financed and managed programs

These programs are generally funded through countries' general taxes.
Some pay for the healthcare system directly, as in the single-payer NHS of the United Kingdom, which finances hospitals and the salaries of most NHS providers.
Others fund a national health insurance program, as in Canada, administered through provincial health plans.
Canadian plans fund hospitals through community trusts and pay providers through the government's insurance program.
Multipayer systems such as that of the United States are more complex to administer.
Medicare is federally managed and provides for most healthcare needs of citizens 65 years of age and older.
Medicaid is a shared-cost federal and state program supporting care for low-income families.
The Children's Health Insurance Program is another federal and state program covering children of uninsured families that do not qualify for Medicaid.
Several other programs serve smaller special populations.
Medicare, Medicaid and CHIP together cover roughly one-third of the U.S. population.

Direct financing and insurance financing are different mechanisms. The NHS pays the providers; Canada insures the patients and pays through plans, which is why the administrative structures differ so much.

Example

A skilled nursing resident may be covered by Medicare for a post-acute stay, then transition to Medicaid once benefit days are exhausted and assets are spent down. The clinical record does not change, but the payer, the eligibility rules and the reporting obligations do.

Question:

Compare the UK and Canadian models of government financing using the source's descriptions.
Sort Medicare, Medicaid and CHIP by who funds them and which population they cover.
What share of the U.S. population do those three programs cover together?

Privately administered insurance

Private insurance programs are generally funded by employers, by citizens themselves, or by a combination of both.
Germany mandates shared contributions from employers and employees.
Those German funds are administered by about 1,100 private, nonprofit sickness funds.
The sickness funds cover more than 90 percent of the German population by paying hospitals and providers.
In the United States, roughly 55 percent of citizens have employer-based insurance and an additional 11 percent purchase insurance directly.
Even in many countries with universal programs, people who can afford private insurance are usually allowed to purchase it.
Private purchase generally allows services not covered under a national benefit structure and may improve access to care.
When organizations treat privately insured patients, they bill the private entity rather than a government organization.

Germany is the source's example of a mandate that is publicly required but privately administered, which is why it does not belong in the government-program category.

Question:

Explain why Germany's system is classified as privately administered despite the mandate.
What two advantages does the source say private purchase can bring in a universal-coverage country?

Personal funds and the financial risk of care

Services are often personally funded by individuals who have government or employer-supported plans, as well as by the uninsured.
Patient co-payments were not required by many universal coverage programs in the past, but an increasing number of countries are adding them to offset growing costs.
In the United States, co-payments are required under most programs, whether government or privately managed.
Persons with higher incomes may choose to avoid insurance constraints and, being able to tolerate the financial risk, pay cash.
Those who fail to qualify for programs such as Medicaid but cannot afford insurance face premium, nonnegotiated rates.
A 2019 study found that 66.5 percent of all U.S. bankruptcies from 2013 to 2016 were tied to medical issues.
58.5 percent were caused specifically by medical bills; the remainder met medical bankruptcy criteria through income loss related to illness.
The Patient Protection and Affordable Care Act was signed into law on March 23, 2010, intended to reduce financial risk and make care more affordable and accessible.
Despite gains in coverage and access, findings suggest the ACA did not change the proportion of bankruptcies with medical causes.

The cash payer and the uninsured patient look alike in a billing system and are opposites in the source's framing. One chooses to carry the risk; the other cannot escape it.

Question:

Distinguish the high-income cash payer from the uninsured patient in the source's account.
State the two bankruptcy percentages and what each one measures.
What does the source conclude about the ACA's effect on medical bankruptcy?

Memory tips

Three payer types: Government, Private insurance, Personal funds. Read as GPP, and remember personal funds counts even when the patient also has coverage.
Country anchors: UK equals single payer paying providers directly. Canada equals national insurance through provincial plans. Germany equals mandated contributions run by about 1,100 nonprofit sickness funds covering more than 90 percent. United States equals multipayer.
U.S. program triangle: Medicare is federal and age 65 plus. Medicaid is federal plus state and low income. CHIP is federal plus state and children above Medicaid eligibility. Together about one-third of the population.
U.S. private coverage split: 55 percent employer-based, 11 percent direct purchase.
Bankruptcy numbers: 66.5 percent tied to medical issues, 58.5 percent caused by bills specifically. The larger number is the wider category.
ACA date: March 23, 2010. Outcome line: coverage and access gains, no change in the medical bankruptcy proportion.

Key concepts

Payer types: government-financed and managed programs, insurance programs administered by private entities, and personal funds
Single-payer system: government financing that pays for the system directly, as the NHS finances hospitals and most provider salaries
National health insurance: government funding of an insurance program administered by subnational plans, as in Canada's provincial health plans
Medicare: the federally managed U.S. program covering most healthcare needs of citizens aged 65 and older
Medicaid: the shared-cost U.S. federal and state program supporting care for low-income families
Children's Health Insurance Program: the U.S. federal and state program covering children of uninsured families that do not qualify for Medicaid
Sickness funds: the roughly 1,100 private, nonprofit German entities that administer mandated employer and employee contributions and cover more than 90 percent of the population
Co-payment: a patient contribution required under most U.S. programs and increasingly added by universal coverage programs to offset cost growth
Cash payer: a higher-income person who avoids insurance constraints and tolerates the financial risk of paying directly
Patient Protection and Affordable Care Act: U.S. law signed March 23, 2010 to reduce patient financial risk and improve affordability and access, which did not change the proportion of bankruptcies with medical causes

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the three payer types from the delivery organization's perspective · general tax funding · NHS direct financing · Canadian provincial administration and community trusts · U.S. multipayer complexity · Medicare, Medicaid and CHIP definitions and the one-third coverage figure · private funding sources · German mandate, sickness funds and coverage share · U.S. employer and direct-purchase percentages · supplemental private purchase in universal systems · billing the private entity · personal funding and co-payments · cash payers · nonnegotiated rates for the unqualified uninsured · 2019 bankruptcy findings · ACA date, intent and measured effect.

Read the original source

Healthcare Payers

From the perspective of the healthcare delivery organization, payments generally come from three types of entities: government-financed and managed programs, insurance programs administered by private entities and personal funds.

Government-financed and managed programs are generally funded through countries’ general taxes. These programs may pay for the healthcare system directly, as does the single-payer system of the NHS of the United Kingdom, which finances hospitals and salaries of most NHS providers. Alternatively, government programs may provide funding for a national health insurance program, such as that in Canada, where the program is administered through provincial health plans. These plans fund hospitals through community trusts and pay providers through the government's insurance program. Multipayer systems, such as that of the United States, are more complex to administer. The U.S. system includes the federally managed program for Medicare, through which citizens 65 years of age and older have most of their healthcare needs provided for; the shared-cost federal/state program Medicaid, which supports care for low-income families; another federal/state program called the Children's Health Insurance Program (CHIP), which provides care to children of uninsured families that do not qualify for Medicaid; and several others for smaller groups of special populations. These three programs provide coverage for roughly one-third7 of the U.S. population.

Insurance programs administered by private entities are generally funded by employers, citizens themselves or by a combination of both. Germany mandates shared health insurance contributions from employers and employees, but these funds are administered by about 1100 private, nonprofit sickness funds that cover more than 90% of the population by making payments to hospitals and providers. In the United States, roughly 55% of citizens have employer-based insurance and an additional 11% purchase insurance directly.8 Even in many countries that have universal healthcare programs, people who can afford to purchase private health insurance are usually allowed to do so. The purchase of private health insurance generally allows the purchaser to receive services that may not be covered under a national benefit structure and may also improve access to care. When healthcare organizations treat patients insured through a private entity, they bill the private health insurance entity rather than a government organization.

Healthcare services are often personally funded by individuals who have government or employer-supported health plans, as well as by the uninsured. While patient co-payments were not required by many universal coverage programs in years past, an increasing number of countries are adding this requirement to offset growing healthcare costs. In the United States, co-payments are required under most healthcare programs, whether government or privately managed. Persons with higher incomes may choose to avoid the constraints of insurance programs and, as they can tolerate the financial risk, are cash payers. Lastly, and perhaps most perversely, those who fail to qualify for government-supported programs such as Medicaid in the United States but still cannot afford to purchase health insurance find themselves at the mercy of a healthcare system that charges premium, nonnegotiated rates to those least able to afford such costs. A 2019 study on bankruptcies in the United States found that 66.5% of all bankruptcies from 2013 to 2016 were tied to medical issues, with 58.5% caused specifically by medical bills. The rest met criteria for medical bankruptcy due to income loss related to illness.9 Although politically divided, the Patient Protection and Affordable Care Act signed into law on March 23, 2010, was intended to help reduce some of these financial risks for patients in the United States and make healthcare more affordable and accessible. Despite gains in coverage and access to care from the ACA, findings suggest that it did not change the proportion of bankruptcies with medical causes.9

In summary, from the perspective of the healthcare delivery organization, three basic types of payers are at play: government-financed and managed programs, insurance programs administered by private entities and patients who pay with personal funds. Add to that the number of potential insurance companies in the market and the differences in payers’ health benefits coverage, and the management of accounts receivable can become an incredibly complex task requiring sophisticated administration and automation support.

Chapter 1 · Healthcare Environment · Lesson 5 of 9

Interrelations Within and Across Healthcare Organizations

Big picture

This section explains why healthcare organizations must exchange information with each other and what breaks when they do not. It follows the survey of organizations and is the bridge into every later chapter on interoperability, standards and exchange. The larger problem it addresses is that care for one patient is delivered by many organizations, so information that stays inside one of them has to be recreated somewhere else, at a cost in time, money and safety. Transfer of care and portability of care are the adjacent pair to keep separate: transfer is a deliberate handoff to another provider, while portability is about information following a patient who turns up somewhere unplanned.

Walkthrough

Why interrelationships exist

Enabling comprehensive care.
Assuring effective transfers of care.
Ensuring the general portability of information in support of care.
Reporting public and population health information.
Obtaining appropriate reimbursement for care.
Supporting particular organizational models of care.

This is a named list of six purposes, and the chapter expands only the first three. The last three are still examinable as members of the set.

Question:

Name all six purposes of interrelationships among healthcare organizations without looking.
Which three does the chapter go on to expand, and which three does it only name?

Enabling access to comprehensive care services

Organizations rely on partners inside or outside the organization to deliver comprehensive care.
Outpatient providers often rely on external laboratory and radiology services for accurate diagnoses.
They also rely on pharmacy availability to complete the care plan with prescribed medications.
Without effective communication, increasingly electronic, the care process breaks down and outcomes can suffer.
This is the area where technology is having the greatest impact.
Public and private initiatives are in place to facilitate seamless, transparent interchange of patient clinical data.
Interoperability is the keyword: transferred data must be consumable by the receiving system.
Consumable data eliminates duplicate data entry and makes information instantly available to the treating provider.

The source sets a specific bar for interoperability. Delivery is not enough; the receiving system has to be able to use what arrives without rekeying it.

Example

A lab result that arrives as a scanned PDF attached to a message has been transferred but is not consumable. The same result delivered as discrete values that file into the flowsheet and trigger the abnormal-value alert meets the source's bar.

Question:

Define interoperability in the source's terms and state the two outcomes it produces.
Which external services does the source name as essential to comprehensive outpatient care?

Assuring effective transfers of care

A transfer of care happens when a provider determines the scope of care required is outside his or her capability.
Communicating health information during the transfer is exceptionally important to patient welfare.
A complete information set covers the history of the present illness, subjective and objective findings including diagnostic test results, and medications prescribed and administered.
With that set, the receiving organization advances treatment substantially more efficiently and effectively.
Without it, time is lost while information is recreated through repetitive evaluation and repeat diagnostic testing, sometimes invasive.
A U.S. initiative encourages use of Health Level Seven International's Consolidated-Clinical Document Architecture, a standard for electronically transmitting continuity of care information.
Lost time in an acute patient and repeated invasive tests both carry adverse consequences.
Not knowing which pharmaceuticals a patient is taking or has been given can be life threatening.
That risk has led some countries to require that medication reconciliation take place.

Medication reconciliation

In the United States it is defined as the process of identifying the most accurate list of all medications the patient is taking.
The list includes name, dosage, frequency and route.
The process compares the medical record to an external list obtained from the patient, hospital or other provider.

The definition is built on a comparison, so a description that only collects a list without comparing it against the record does not meet the source's definition.

Question:

List the elements of a complete transfer-of-care information set.
Define medication reconciliation, including its four list attributes and the two things being compared.
Which standard does the source name for electronically transmitting continuity of care information, and who publishes it?

Ensuring the general portability of care

Patients enrolled with a specific organization still need care elsewhere, including when they travel away from their routine places of care.
A patient who falls ill or is injured hundreds of miles from home is the scenario the source uses.
Having correct health information available can powerfully influence outcomes from the clinical intervention.
The most common example of failure is a new provider who does not know a patient's medication allergies.
Some nations are implementing national health information exchanges to provide virtual, real-time access to patients' health information.
Canada Health Infoway is a nonprofit organization made up of the 14 federal, provincial and territorial deputy ministers of health.
Infoway's vision is healthier Canadians through innovative digital health solutions.
In the United States, work continues on standards for sharing through state-level HIEs and nationally via the Nationwide Health Information Network and the Nationwide Interoperability Roadmap.
The United Kingdom has invested heavily in NHS Digital, formerly the Health and Social Care Information Centre, which connects England's healthcare organizations.
NHS Digital facilitates availability of clinical information shared to support continuity of care and patient safety.

Portability differs from transfer of care in who initiates it. Transfer is a decision by a provider; portability is a patient turning up somewhere no one planned for.

Question:

Distinguish portability of care from transfer of care, and give the source's example of each.
Name the national exchange initiatives the source attributes to Canada, the United States and the United Kingdom.

Memory tips

Six purposes, in source order: Comprehensive care, Transfers, Portability, Public and population reporting, Reimbursement, Models of care. First letters read C-T-P-P-R-M; say it as Care Transfers Port, Public Reports, Models.
Medication reconciliation four attributes: Name, Dosage, Frequency, Route. Read as NDFR: No Drug Fits Randomly.
Interoperability test phrase: consumable by the receiving system. If an option says only transmitted or only received, it is short of the bar.
C-CDA belongs to HL7 and carries continuity of care information. Standard plus owner, memorized as a pair.
Infoway number anchor: 14 deputy ministers, federal plus provincial plus territorial.
Initiative by country: Canada equals Infoway. United States equals NHIN plus the Nationwide Interoperability Roadmap. United Kingdom equals NHS Digital, formerly HSCIC.

Key concepts

Purposes of interrelationships: enabling comprehensive care, assuring effective transfers of care, ensuring portability of information, reporting public and population health information, obtaining appropriate reimbursement, and supporting particular organizational models of care
Interoperability: the transferred data being consumable by the receiving system, eliminating duplicate data entry and making data instantly available to the treating provider
Transfer of care: the handoff that follows a provider's determination that required care exceeds his or her capability
Complete transfer information set: history of the present illness, subjective and objective findings including diagnostic results, and medications prescribed and administered
Consolidated-Clinical Document Architecture: the HL7 standard encouraged in the United States for electronically transmitting continuity of care information
Medication reconciliation: identifying the most accurate list of all medications a patient is taking, by name, dosage, frequency and route, by comparing the medical record to an external list from the patient, hospital or other provider
Portability of care: the availability of correct health information when a patient needs care away from routine places of care
Health information exchange: a national or state initiative providing virtual, real-time access to patients' health information
Canada Health Infoway: a nonprofit made up of the 14 federal, provincial and territorial deputy ministers of health, with a vision of healthier Canadians through innovative digital health solutions
NHS Digital: the United Kingdom body, formerly the Health and Social Care Information Centre, that connects England's healthcare organizations to share clinical information for continuity and safety

Practice questions

25 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the six named purposes of interrelationships · reliance on internal and external partners · lab, radiology and pharmacy dependence · interoperability definition and its two outcomes · trigger and definition of transfer of care · complete transfer information set · consequences of missing information · HL7 C-CDA · medication safety risk · medication reconciliation definition and its four attributes · portability scenario and the allergy example · national HIE purpose · Canada Health Infoway composition and vision · NHIN and Nationwide Interoperability Roadmap · NHS Digital and its former name.

Read the original source

Interrelations Within and Across Healthcare Organizations

The purposes of interrelationships among healthcare organizations are numerous. Some of the key requirements include enabling comprehensive care, assuring effective transfers of care, ensuring the general portability of information in support of care, reporting public and population health information, obtaining appropriate reimbursement for care and supporting particular organizational models of care.

Enabling Access to Comprehensive Care Services

As noted in the section above, healthcare organizations are reliant upon a number of partners within or outside of their organization to enable the delivery of comprehensive care. Providers in the outpatient setting often rely on external laboratory and radiology services to ensure accurate diagnoses and on the availability of pharmacies to provide prescribed medications to complete the provider's care plan for the patient. Absent effective communications—increasingly electronic today—the care process will break down and patient outcomes could suffer as a result. This is the area in which technology is having the greatest impact. Various public and private initiatives are in place to facilitate the seamless, transparent interchange of patient clinical data. “Interoperability” is the keyword here, as the transferred data must be consumable by the receiving system in order to eliminate duplicate data entry and make the data instantly available to the treating provider.

Assuring Effective Transfers of Care

When a provider determines that the scope of care required for a patient's treatment is outside of his or her capability, care is generally transferred to another provider or healthcare organization. Effectively communicating health information during the transfer of care is exceptionally important to the patient's welfare. When a complete set of information is transferred with the patient regarding the history of the present illness, along with subjective and objective findings that include the results of diagnostic tests performed and medications prescribed and administered, the receiving organization can advance the patient's treatment in a substantially more efficient and effective manner. When such information does not accompany a patient during transfer, precious time is often lost, as that information is re-created through repetitive evaluations and repeat administration of diagnostic tests that are sometimes of an invasive nature. To facilitate the provision of essential health information during transfer of care between providers or facilities, an initiative in the United States encourages the use of Health Level Seven International's (HL7) Consolidated-Clinical Document Architecture (C-CDA), which is a standard for electronically transmitting continuity of care information.10

Both the loss of time in treating an acute patient and the need to repeat invasive tests can have adverse consequences for a patient. Not having a clear awareness of the pharmaceutical products a patient may be taking or has been administered in the present course of care can be life threatening and has led to attempts in some countries to ensure that medication reconciliation has taken place. In the United States, medication reconciliation is defined as the process of identifying the most accurate list of all medications that the patient is taking, including name, dosage, frequency and route, by comparing the medical record to an external list of medications obtained from a patient, hospital or other provider.11

Ensuring the General Portability of Care

Even when patients are enrolled to a specific clinical organization or provider for care, there are times when they will need care from other providers. This occurs not only under the two scenarios covered above, but also when patients travel away from their routine places of care. If a patient who is several hundred miles away from home becomes ill or is injured in an automobile accident, having the correct health information available can have a powerful influence on the patient's health outcomes from the clinical intervention. The most common example is that of the new provider who does not know a patient's medication allergies. To overcome these challenges, some nations are implementing national health information exchanges (HIEs) that endeavor to provide virtual, real-time access to patients’ health information. One such initiative is Canada's Health Infoway, a nonprofit organization made up of the 14 federal, provincial and territorial deputy ministers of health. Infoway's vision is “healthier Canadians through innovative digital health solutions.”12 In the United States, much work is under way to define standards to facilitate ease of sharing health information both through HIEs at the state level and nationally via the Nationwide Health Information Network (NHIN) and, more recently, through the Nationwide Interoperability Roadmap. The United Kingdom has also invested heavily in its NHS Digital (formerly Health and Social Care Information Centre (HSCIC)) through its national health system, which connects England's healthcare organizations to facilitate the availability of clinical information that can be shared to support the continuity of care and safety of patients in the healthcare process.

Chapter 1 · Healthcare Environment · Lesson 6 of 9

Roles and Responsibilities of Health Information and Management Systems Professionals

Big picture

This section maps the job titles in health information management and health IT, from the single-provider office to the large academic medical center. It is the part of Chapter 1 that names the people who appear as answer options for the rest of the exam, and it feeds directly into the governance and leadership material in Chapter 9. The larger problem it addresses is that responsibility for information has been split across several executives and specialist roles, so knowing which one owns a given decision is a prerequisite for every escalation question. The pair most easily confused is the chief security officer and the privacy officer, since both protect information but one secures assets and the other controls authorized access to identifiable data.

Walkthrough

How department size shapes the role

The number of position titles in the HIM and health IT space is quite large.
In a single-provider office, one person may perform the broad range of HIM and IT tasks, work less than full-time, or double as the office manager.
In a large academic medical center or integrated delivery system, the IT department could include more than 100 personnel.
The top IT position in healthcare organizations is usually the chief information officer.
The CIO is generally accountable for a broad range of IT activities, including many not directly related to healthcare.
Those activities include organizational computing rooms, individual desktop computers, telephone communications including mobile, bring your own device and Internet of Things equipment, secure Internet access, local and wide area networks, and the organization's website.

Size is the variable that drives specialization. The same set of tasks exists in both settings; only the number of people it is divided among changes.

Question:

Explain how the same HIM and IT workload appears in a single-provider office versus a large academic medical center.
List the areas the source says the CIO is accountable for, including those not specific to healthcare.

Specialized executive roles

The chief security officer secures computing and communications assets against intentional or unintentional breaches from inside or outside the organization.
Lead IT security personnel may hold the Certified Information Systems Security Professional credential from ISC2.
The privacy officer ensures that personally identifiable data, including protected health information, is accessed exclusively by those authorized under law.
In the United States those laws include the Privacy Act and the Health Insurance Portability and Accountability Act, among others.
A credential supporting the privacy role is Certified in Healthcare Privacy and Security.
The chief technology officer is generally responsible for the technical architecture of the IT systems supporting the organization.
The CTO also watches the developing HIM and IT market to keep the organization competitive technologically, across mobile platforms, cloud-based computing and state-of-the-art clinical applications.

Security protects the asset; privacy governs who may see the data. A stem that names breaches and assets points to the CSO, while a stem that names authorized access and identifiable data points to the privacy officer.

Example

A nurse looks up the record of a neighbor who is not her patient. Nothing was breached from outside and no system failed, so this is a privacy officer matter about authorized access, not a security incident in the source's sense.

Question:

Compare the chief security officer and the privacy officer, naming the credential associated with each.
What is the CTO responsible for, and what market-facing duty does the source attach to the role?

Health information management and clinical informatics roles

Health information managers have held roles in medical records departments for decades.
Before electronic health records were commonly available there was not a strong relationship between HIM and IT departments.
As medical records functions became automated, culminating in advanced EHRs, HIM departments find themselves at the center of IT activities.
U.S. HIM credentials named are Registered Health Information Administrator and Registered Health Information Technologist.
The Canadian credential named is Certification in Health Information Management.
Organizations may rely on the Certified Professional in Healthcare Information and Management Systems credential to confirm a broad base of knowledge and experience.
The role of clinical informatics professionals is expanding as medicine is increasingly supported by EHRs and other health information systems; Chapter 3 covers it in depth.
The American Medical Informatics Association advocates advanced training for clinicians to develop a clinical informatics subspecialty in the practice of medicine.
A frequently used title for such staff is chief medical information officer.
Popular variants are chief medical informatics officer and chief health information officer.
In nursing, the equivalent title is chief nursing informatics officer.
Effective integration of clinical insight into systems solutions grows in importance as IT use in care processes increases.

The automation of medical records is what pulled HIM toward IT. The two departments are described as converging because of the EHR, not because of a reporting-line change.

Question:

Explain why HIM and IT departments became closely related, in three sentences, as you would to a nurse manager.
Name the HIM and informatics credentials the source lists and the country or body attached to each.
Give the CMIO title and its named variants, including the nursing equivalent.

How an IT organization is structured

Structure varies with organization size, geographical distribution and line of business. The source gives one sample structure a CIO may oversee and one list of common positions, and both are complete named sets.

Functions in a sample CIO organization

Application development and support.
Data center operations.
Database administration.
Desktop support.
Information security.
Network operations.

Common position types

Desktop support technician.
Database administrator.
Programmer or application developer.
Web developer.
Network engineer or analyst.
Systems analyst or administrator.
Project manager.
Security analyst.

Roles may be filled by staff, consultants or contractors.
The specific roles an organization fills vary with the functions it supports.
Great variation in the size and structure of IT departments drives the number and specialization of jobs within it.

Question:

Name all six functions in the sample CIO organization without looking.
Name the eight common position types the source lists.
What three factors does the source say drive variation in IT department structure?

Memory tips

Six CIO functions, alphabetical in the source: Application development and support, Data center operations, Database administration, Desktop support, Information security, Network operations. Notice the source order is alphabetical, which makes reconstruction easier.
Eight positions, paired: Desktop support technician with Database administrator, Programmer or application developer with Web developer, Network engineer or analyst with Systems analyst or administrator, Project manager with Security analyst.
Credential to role: CISSP from ISC2 goes with security. CHPS goes with privacy. RHIA and RHIT go with U.S. HIM, CHIM with Canada. CPHIMS is the broad health information and management systems credential.
Officer split: CSO protects assets from breaches. Privacy officer restricts identifiable data to the authorized. CTO owns technical architecture.
Informatics titles: CMIO is the main one; variants are chief medical informatics officer and CHIO; nursing is CNIO. AMIA is the association pushing the clinical informatics subspecialty.
Scale anchors: one person, possibly part-time and doubling as office manager, at one end; more than 100 personnel at the other.

Key concepts

Chief information officer: the top IT position, accountable for a broad range of IT activities including computing rooms, desktops, telephony and mobile, BYOD and IoT equipment, secure Internet access, networks and the website
Chief security officer: the executive who secures computing and communications assets against intentional or unintentional breaches from inside or outside
CISSP: the Certified Information Systems Security Professional credential from ISC2, held by lead IT security personnel
Privacy officer: the role ensuring personally identifiable data, including protected health information, is accessed exclusively by those authorized under law
CHPS: the Certified in Healthcare Privacy and Security credential supporting the privacy role
Chief technology officer: the executive responsible for technical architecture and for tracking the developing market to keep the organization technologically competitive
HIM credentials: Registered Health Information Administrator and Registered Health Information Technologist in the United States, and Certification in Health Information Management in Canada
CPHIMS: the Certified Professional in Healthcare Information and Management Systems credential, evidence of broad knowledge and experience in the field
Chief medical information officer: the frequently used title for clinically trained informatics leadership, with variants chief medical informatics officer and chief health information officer, and chief nursing informatics officer in nursing
Sample CIO organization: application development and support, data center operations, database administration, desktop support, information security, and network operations
Common IT positions: desktop support technician, database administrator, programmer or application developer, web developer, network engineer or analyst, systems analyst or administrator, project manager, and security analyst

Practice questions

20 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: breadth of HIM and IT titles · single-office versus large-organization staffing · CIO scope including non-healthcare activities · CSO role and CISSP · privacy officer role, governing laws and CHPS · CTO architecture and market role · HIM history and convergence with IT · RHIA, RHIT, CHIM and CPHIMS · clinical informatics expansion and the Chapter 3 pointer · AMIA subspecialty advocacy · CMIO and its variants including CNIO · the six sample CIO functions · the eight common position types · staff, consultant or contractor sourcing · drivers of structural variation.

Read the original source

Roles and Responsibilities of Healthcare Information and Management Systems Professions

The number of position titles in the health information management (HIM) and health information technology (HIT or IT) space is quite large. In a single-provider office, the person who performs the broad range of HIM/IT tasks may work less than full-time or double as the office manager. In a large academic medical center or IDS, the IT department could include more than 100 personnel. The top IT position in healthcare organizations is usually referred to as the chief information officer (CIO). The CIO is generally accountable for a broad range of IT activities, including many that are not directly related to healthcare. Among these would be such things as maintaining organizational computing rooms, individual desktop computers, telephone communications (including an increasing variety of mobile and BYOD (Bring Your Own Device) and IOT (Internet of Things) equipment, secure Internet access, local and wide area networks and the organization's website.

In larger organizations, the complexity of HIM and IT functions leads to specialization. The chief security officer (CSO) endeavors to secure the healthcare organization's computing and communications assets from either intentional or unintentional security breaches from inside or outside the organization. Lead IT security personnel may carry the Certified Information Systems Security Professional (CISSP®) credential from the Information Systems Security Certification Consortium, Inc. (ISC2®).15 Similarly, the privacy officer is responsible for ensuring that personally identifiable data, including protected health information, is accessed exclusively by those authorized to do so under a broad range of laws—in the United States, the Privacy Act and the Health Insurance Portability and Accountability Act (HIPAA), among others. A credential leveraged in supporting this role is that of Certified in Healthcare Privacy and Security (CHPS®).16

The chief technology officer (CTO) is generally responsible for the technical architecture of the IT systems supporting the organization and often looks toward the developing market in HIM and IT to try and keep the organization competitive from a technology perspective. This could range across the full spectrum of such things as mobile computing platforms, cloud-based computing and state-of-the-art clinical applications.

Health information managers have held roles in medical records departments for decades, but prior to the common availability of electronic health records (EHRs), there was not a strong relationship between HIM and IT departments. As medical records functions have become increasingly automated over the past few years, culminating in EHRs of advanced capabilities, HIM departments are finding themselves at the center of the IT activities in healthcare organizations. In the HIM area, you will find professionals with the Registered Health Information Administrator (RHIA) or Registered Health Information Technologist (RHIT®)17 credential in the United States or with the Certification in Health Information Management (CHIM) credential in Canada.18 Healthcare organizations may also rely on the Certified Professional in Healthcare Information and Management Systems (CPHIMSTM)19 credential to ensure that staff members in the IT department have a broad base of knowledge and experience in healthcare information and management systems.

The role of clinical informatics professionals is also expanding as the practice of medicine is increasingly supported by EHRs and other health information systems. The role of clinical informatics is discussed in depth in Chapter 3.

The American Medical Informatics Association (AMIA) advocates advanced training for clinicians to develop a clinical informatics subspecialty in the practice of medicine.20 A frequently used title for staff with such backgrounds in the health information space is that of chief medical information officer (CMIO). Popular variants are chief medical informatics officer and chief health information officer (CHIO), and in the area of nursing, chief nursing informatics officer (CNIO). With the increasing use of IT in healthcare processes, effective integration of clinical insights into systems solutions is of great importance.

While the great variety of organizational structures in IT departments is driven by such factors as organization size, geographical distribution and line of business, a sample organization structure a CIO may oversee could include:

Application development and support

Data center operations

Database administration

Desktop support

Information security

Network operations

Similarly, the specific roles an IT organization may expect to fill would vary based on the functions the organization supports. These roles could be filled by staff, consultants or contractors. Examples of the more common types of positions one might expect to see include

Desktop support technician

Database administrator

Programmer/application developer

Web developer

Network engineer/analyst

Systems analyst/administrator

Project manager

Security analyst

In summary, there is great variation in the size and structure of IT departments within healthcare organizations, which drives the number and specialization of jobs within the IT organization.

Chapter 1 · Healthcare Environment · Lesson 7 of 9

Government and Healthcare Regulators

Big picture

This section opens the final block of Chapter 1, which covers the four kinds of bodies that sit above healthcare organizations: government, regulators, professional associations and accreditors. Government appears first because its spending problem is what drives most of the oversight that follows. The larger problem it addresses is cost growth as a share of national economies, which governments treat as an economic threat rather than only a health policy question. Government and regulator are the pair to keep separate here: government sets law and funds programs, while a regulator implements the provisions of health law through a more explicit system of regulations, and a regulator is not always a government entity.

Walkthrough

Why government is so heavily involved

Healthcare affects quality of life, longevity and survival after life-threatening disease or accident.
Delivering high-quality care to very large populations is enormously expensive.
Those two facts make extensive government oversight and a large number of regulatory bodies unsurprising.
Most countries continue to see healthcare consume a growing proportion of gross domestic product.
Governments fear these trends will weaken national economies if not slowed, stopped or reversed.
Stopping the growth requires exceptionally difficult decisions, because citizens have grown accustomed to existing health benefit programs.

The political difficulty is part of the source's argument, not an aside. Cost control is framed as a problem of withdrawing benefits people already expect.

Question:

State the two reasons the source gives for heavy government involvement in healthcare.
Why does the source call cost containment an exceptionally difficult decision for governments?

The spending trend the source cites

The Peterson Kaiser Health System tracker is the source of the spending comparison.
Over the past four decades the gap between U.S. health spending as a share of the economy and that of comparable OECD countries has widened.
In 1970 the United States spent about 6 percent of GDP on health, similar to several comparable countries, whose average was 5 percent.
The United States was relatively on pace with other countries until the 1980s.
From the 1980s its health spending grew significantly faster relative to GDP.
In 2017 the United States spent 17 percent of GDP on health consumption.
The next highest comparable country, Switzerland, devoted 12 percent.
The source concludes that healthcare is consuming national economies at an unsustainable rate, making government engagement essential.

Four numbers and one turning point carry this topic. The decade of divergence matters as much as the percentages, because it dates the problem the later reforms respond to.

Question:

Give the U.S. GDP health spending figures for 1970 and 2017 and the comparison figure for each year.
In which decade did U.S. spending begin to diverge from comparable countries?

Government responses to cost growth

Australia: enhancements to the primary care delivery system to manage chronic diseases more effectively.
Canada: experimentation with privatization.
Germany: global budgeting and competition among sickness funds.
Japan: requiring long-term care residents to pay for room and board.
United Kingdom: consideration of pro-market reforms.
United States: encouragement of accountable care organizations with a goal of better health outcomes at lower cost.
Such trends will continue as nations balance quality, access, cost and safety for the greatest proportion of their populations.

Example

The room and board change in Japan shifts a cost from the public program to the resident. No clinical service changed, but the eligibility, billing and resident communication workflows all did.

Question:

Match each named country to the cost response the source attributes to it.
What goal does the source attach to accountable care organizations in the United States?

Healthcare regulators

Regulatory agencies generally implement the provisions of a nation's health laws through a more explicit system of regulations.
In the United Kingdom, the Health and Care Professions Council is the statutory regulator for 15 professions covering nearly 290,000 health and care professionals.
The HCPC maintains standards of proficiency and conduct for the professions it regulates.
In the United States, the dominating regulatory entity is CMS.
CMS drafts rules and finalizes regulations for multiple federally subsidized healthcare programs through a complex rulemaking process involving public engagement.
The Food and Drug Administration evaluates and approves medical devices and new drugs used in treatment.
In Canada, medical devices are regulated by Health Canada's Therapeutic Products Directorate.
It is a common belief that regulatory organizations are always government entities, but private-sector organizations, commissions and associations may also act in a regulatory capacity.

The last bullet is the one the exam leans on. Any option asserting that regulators are exclusively governmental contradicts the source directly.

Example

A skilled nursing facility answers to CMS rules on participation, to a state agency conducting the survey, and to an accreditor acting on CMS's behalf. Only the first is the federal rulemaker, but all three constrain practice.

Question:

Define what a regulatory agency does in the source's wording.
Match HCPC, CMS, FDA and the Therapeutic Products Directorate to their jurisdictions and functions.
What common belief about regulators does the source explicitly correct?

Memory tips

Spending timeline: 6 percent in 1970 against a 5 percent comparable average, divergence starting in the 1980s, 17 percent in 2017 against Switzerland at 12 percent. Two pairs, two dates.
HCPC numbers: 15 professions, nearly 290,000 professionals. Fifteen is small, 290,000 is large; do not let the options swap their scale.
Country responses, one word each: Australia chronic care, Canada privatization, Germany budgets and competition, Japan room and board, United Kingdom pro-market, United States ACOs.
Regulator scope line: implements law through explicit regulations. Government is the usual case, not the only case.
Device and drug approval: FDA in the United States, Therapeutic Products Directorate under Health Canada. Same job, two countries.

Key concepts

Government engagement rationale: the importance of healthcare to life and longevity plus the expense of delivering it to large populations
GDP pressure: the growing share of gross domestic product consumed by healthcare, which governments fear will weaken national economies
Peterson Kaiser spending comparison: the cited tracker showing the United States at about 6 percent of GDP in 1970 and 17 percent in 2017, with divergence beginning in the 1980s and Switzerland next highest at 12 percent
National cost responses: Australian chronic disease primary care enhancement, Canadian privatization experiments, German global budgeting and sickness fund competition, Japanese room and board charges, UK pro-market reform consideration, and U.S. accountable care organizations
Regulatory agency: a body that implements the provisions of a nation's health laws through a more explicit system of regulations
Health and Care Professions Council: the UK statutory regulator for 15 professions and nearly 290,000 professionals, maintaining standards of proficiency and conduct
CMS: the dominating U.S. regulatory entity, drafting rules and finalizing regulations for federally subsidized programs through rulemaking with public engagement
Food and Drug Administration: the U.S. body evaluating and approving medical devices and new drugs, with Health Canada's Therapeutic Products Directorate the Canadian counterpart for devices
Nongovernment regulators: private-sector organizations, commissions and associations that may perform in a regulatory capacity

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: rationale for government oversight · GDP growth concern and its political difficulty · Peterson Kaiser figures for 1970, the 1980s divergence and 2017, with the Switzerland comparison · unsustainability conclusion · six national cost responses by country · ACO goal · definition of regulatory agency function · HCPC scope and numbers · CMS rulemaking · FDA and Therapeutic Products Directorate · correction of the belief that regulators are always government entities.

Read the original source

Roles of Government, Regulatory, Professional and Accreditation Agencies in Healthcare

Given the importance of healthcare in our lives—including our quality of life, our longevity and even our ability to continue living following life-threatening encounters with disease or accidents—and the incredible expense of delivering high-quality healthcare to very large populations, it is not surprising that a tremendous amount of government oversight and a great number of regulatory bodies are involved in healthcare processes. An overview of these organizations and their associated activities is provided below.

Government

The role of governments in healthcare is quite pronounced, as discussed in the previous section on healthcare organizations. Because most countries continue to experience increases in the proportion of their gross domestic product (GDP) consumed by healthcare activities, they are concerned that these trends will weaken their national economies if not slowed—or even stopped and reversed. Stopping the growth in healthcare costs as a percentage of GDP requires exceptionally difficult decisions for governments in industrialized countries, as citizens have grown accustomed to the existing health benefits programs.

According to the Peterson Kaiser Health System tracker:

Over the past four decades, the difference between health spending as a share of the economy in the U.S. and comparable OECD countries has widened. In 1970 the U.S. spent about 6% of its GDP on health, similar to spending by several comparable countries (the average of comparably wealthy countries was 5% of GDP in 1970). The U.S. was relatively on pace with other countries until the 1980s, when its health spending grew at a significantly faster rate relative to its GDP. In 2017, the U.S. spent 17% of its GDP on health consumption, whereas the next highest comparable country (Switzerland) devoted 12% of its GDP

It is easy to see that healthcare is consuming our national economies at an unsustainable rate, making governmental engagement in these factors essential.

To address the growth in healthcare costs, many nations’ governments are considering changes to their health programs. Among these are enhancements to the primary care delivery system to manage chronic diseases more effectively in Australia, experimentation with privatization in Canada, global budgeting and competition among sickness funds in Germany, requiring long-term care residents to pay for room and board in Japan and consideration of pro-market reforms in the United Kingdom.22 Similarly, the development of ACOs in the United States is being encouraged with a goal of producing better health outcomes at lower cost. Such trends will continue as we collectively grapple with the best ways to balance quality, access, cost and safety for the greatest proportion of our populations.

Healthcare Regulators

Healthcare regulatory agencies serve a broad range of functions in the healthcare environment, generally by implementing the provisions of a nation's health laws through a more explicit system of regulations. In the United Kingdom, the Health and Care Professions Council (HCPC) is the statutory regulator for 15 professions with nearly 290,000 health and care professionals in the country.23 The HCPC maintains standards of proficiency and conduct for the professions it regulates. In the United States, the dominating regulatory entity is the CMS. The CMS drafts the rules and finalizes the regulations for the management of multiple federally subsidized healthcare programs for the nation through a complex process of rulemaking involving public engagement. The Food and Drug Administration (FDA) in the United States evaluates and approves medical devices and new drugs used in the treatment of patients. Similarly, medical devices in Canada are regulated by Health Canada's Therapeutic Products Directorate.

While it may be a common belief that regulatory organizations are always government entities, it is not uncommon to find that private-sector organizations, commissions and associations may perform in a regulatory capacity as well. These are addressed in the following sections.

Chapter 1 · Healthcare Environment · Lesson 8 of 9

Professional Associations and Accreditation Organizations

Big picture

This section finishes the oversight picture with the two nongovernment bodies that shape professional practice: associations, which serve their members, and accreditation organizations, which survey healthcare organizations on behalf of federal programs. It closes Chapter 1 and supplies the vocabulary that recurs in the privacy, quality and leadership chapters. The larger problem it addresses is that much of the control over healthcare practice sits outside government, exercised through membership standards and voluntary survey. The distinction the exam presses hardest is association versus regulatory body, because both may set standards of practice and only one exists to protect the public.

Walkthrough

What a profession and an association are

Merriam-Webster defines a profession as a calling requiring specialized knowledge and often long and intensive academic preparation.
Professional associations in healthcare have proliferated greatly, many serving in a semi-regulatory role.
The College of Kinesiologists of Ontario provides the description the source uses.
The primary role of an association is to advocate on behalf of its members and promote the profession.

What associations may do

Advocate with policy makers in the interest of members.
Market and promote the profession.
Provide continuing professional development opportunities.
Represent members' interests by monitoring developments that may affect scope of practice and employment opportunities, and by enhancing relationships with related professionals.

What regulatory bodies may do

Set requirements for entry to the profession.
Maintain a list of individuals eligible to practice.
Develop standards of practice.
Receive and investigate complaints about professional practice and administer appropriate disciplinary action when necessary.
Require professionals to participate in continuing professional development.

The two lists share activities that sound alike, so the deciding question is who is served. An association serves its members; a regulatory body exists to protect the public by regulating the profession.

Example

Both a nursing association and a nursing board may run continuing education. The association offers it as a member benefit; the board requires it as a condition of continued eligibility to practice.

Question:

Give the source's definition of a profession.
Name all four association activities and all five regulatory body activities.
What single question separates an association activity from a regulatory one?

Table 1.1: associations related to healthcare and healthcare IT

The source splits the table into clinical associations and administrative or IT associations. Six appear in each column, and the exam tests the acronym-to-name pairing more than the column itself.

Clinical	Administrative and IT
American Academy of Pediatrics	American College of Healthcare Executives
International Confederation of Midwives	American Health Information Management Association
International Council of Midwives	American Medical Informatics Association
Royal College of General Practitioners	Healthcare Information and Management Systems Society
World Dental Federation	Information Systems Security Association International
World Medical Association	International Medical Informatics Association

Question:

Expand AHIMA, AMIA, HIMSS and ACHE and state which column each belongs to.
Which two associations in the table are international informatics or security bodies?

Accreditation organizations and deemed compliance

Accreditation organizations have substantial interactions with healthcare organizations.
They generally play a semi-regulatory role, often serving on behalf of federal organizations to ensure specific standards or conditions of participation are met.
The Joint Commission and Joint Commission International are perhaps the most recognized accreditors for certification of hospitals in the United States and internationally.
Joint Commission International currently operates in more than 100 countries.
In the United States, the accreditation organizations under CMS are very visible examples.
CMS accreditors determine compliance with Medicare conditions of participation.
When an organization is certified by a CMS accreditor for compliance, it is deemed to have met the requirements.
A deemed organization may then bill CMS for covered services.
A number of other organizations are authorized to act as accreditors for participation in Medicare programs.

The phrase serving on behalf of federal organizations is what makes the role semi-regulatory, and it is also the mechanism behind deemed status. A private body's survey substitutes for a federal one.

Example

A hospital surveyed by an approved accreditor and found compliant is treated by CMS as meeting the conditions of participation, without a separate federal survey, and can bill for covered services on that basis.

Question:

Explain deemed status in three sentences, including who surveys, what is verified and what the organization may then do.
Why does the source call the accreditor role semi-regulatory rather than regulatory?
How does Joint Commission International differ in scope from the Joint Commission?

Table 1.2: CMS-approved accreditation organizations

Organization	Program types
Accreditation Association for Ambulatory Health Care (AAAHC)	Ambulatory surgical centers
Accreditation Commission for Health Care, Inc. (ACHC)	Home health agencies; hospices
American Association for Accreditation of Ambulatory Surgery Facilities (AAAASF)	ASCs; outpatient physical therapy providers; rural health clinics
American Osteopathic Association / Healthcare Facilities Accreditation Program (AOA/HFAP)	ASCs; critical access hospitals; hospitals
Center for Improvement in Healthcare Quality (CIHQ)	Hospitals
Community Health Accreditation Program (CHAP)	Home health agencies; hospice
DNV GL-Healthcare (DNVGL)	Hospitals; critical access hospitals
Institute for Medical Quality (IMQ)	ASCs
National Dialysis Accreditation Commission (NDAC)	End-stage renal disease facilities
The Compliance Team (TCT)	Rural health clinics
Joint Commission	ASCs; critical access hospitals; home health agencies; hospices; hospitals; psychiatric hospitals

The Joint Commission covers the broadest range of program types in the table.
Several accreditors are single-program, including CIHQ, IMQ, NDAC and TCT.
The interrelationships among government agencies, regulators, professional associations and accreditors can be surprisingly complex.
The source illustrates that complexity with the organizations involved in a physician assistant's path from training into practice.

Question:

Which accreditor in Table 1.2 covers the widest set of program types, and name those types.
Name the single-program accreditors and the one program each covers.
Which accreditors cover hospitals, and which cover critical access hospitals?

Memory tips

Who is served: association serves members, regulator protects the public. Both may set standards and both may touch continuing development, so the served party is the deciding clue.
Association verbs: Advocate, Market, Provide development, Represent. Regulator verbs: Set entry, Maintain the list, Develop standards, Investigate and discipline, Require development. Only the regulator investigates.
Deemed status chain: approved accreditor surveys, organization found compliant with conditions of participation, CMS deems requirements met, organization bills for covered services.
Joint Commission is the breadth answer: six program types including psychiatric hospitals, which no other listed accreditor covers.
Single-program accreditors, one each: CIHQ hospitals, IMQ ASCs, NDAC end-stage renal disease facilities, TCT rural health clinics.
Hospital accreditors to remember together: Joint Commission, AOA/HFAP, CIHQ, DNV GL. Of those, AOA/HFAP, DNV GL and Joint Commission also cover critical access hospitals.
JCI number anchor: more than 100 countries, outside the United States.

Key concepts

Profession: a calling requiring specialized knowledge and often long and intensive academic preparation
Professional association: a body whose primary role is to advocate on behalf of members and promote the profession, often in a semi-regulatory capacity
Association activities: advocating with policy makers, marketing and promoting the profession, providing continuing professional development, and representing member interests on scope of practice, employment and professional relationships
Regulatory body activities: setting entry requirements, maintaining the list of individuals eligible to practice, developing standards of practice, investigating complaints and administering discipline, and requiring continuing professional development
Accreditation organization: a body that interacts substantially with healthcare organizations and often serves on behalf of federal organizations to ensure standards or conditions of participation are met
Conditions of participation: the CMS requirements that an accreditor verifies for Medicare program participation
Deemed compliance: the status in which an organization certified by a CMS accreditor is treated as having met CMS requirements and may bill CMS for covered services
Joint Commission and Joint Commission International: the most recognized accreditors for hospital certification domestically and internationally, with JCI operating in more than 100 countries
CMS-approved accreditors: the organizations authorized to accredit for Medicare participation, spanning ambulatory surgical centers, home health agencies, hospices, outpatient physical therapy, rural health clinics, hospitals, critical access hospitals, end-stage renal disease facilities and psychiatric hospitals

Practice questions

14 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: definition of a profession · proliferation and semi-regulatory role of associations · the four association activities · the five regulatory body activities and the public protection purpose · Table 1.1 clinical and administrative or IT associations · accreditor interactions and semi-regulatory basis · Joint Commission and JCI recognition and JCI's country reach · CMS accreditors and conditions of participation · deemed compliance and billing consequence · Table 1.2 organizations and program types · complexity of interrelationships illustrated by the physician assistant pathway.

Read the original source

Professional Associations

According to the Merriam-Webster Dictionary, a profession is “a calling requiring specialized knowledge and often long and intensive academic preparation.”24 Professional associations in the healthcare environment have proliferated greatly, many serving in a semi-regulatory role. The College of Kinesiologists of Ontario25 provides a good description of the roles and functions of professional associations, stating that their primary role is to advocate on behalf of its members and promote the profession and may

Advocate with policy makers in the interest of members

Table 1.1 Professional Associations Related to Healthcare and Healthcare IT

Clinical

Administrative and IT

American Academy of Pediatrics

American College of Healthcare Executives

International Confederation of Midwives

American Health Information Management Association

International Council of Midwives

American Medical Informatics Association

Royal College of General Practitioners

Healthcare Information and Management Systems Society

World Dental Federation

Information Systems Security Association International

World Medical Association

International Medical Informatics Association

Accreditation Organizations

Accreditation organizations (AOs) have substantial interactions with healthcare organizations and generally play a semi-regulatory role in that they often serve on behalf of federal organizations to ensure specific standards or conditions of participation (CoP) are met. The Joint Commission and Joint Commission International (JCI)26 are perhaps the most recognized AOs utilized for the certification of hospitals in the United States and internationally. The JCI currently operates in more than 100 countries around the globe. In the United States, the AOs under CMS are very visible examples of accreditation agencies. CMS AOs determine compliance with Medicare CoP. When a healthcare organization is certified by a CMS AO for compliance with CMS requirements, the organization is deemed to have met the requirements and may then bill CMS for covered services. For participation in Medicare programs, a number of other organizations are authorized to act as AOs, as shown in the Table 1.2.

Table 1.2 CMS-Approved Accreditation Organizations

Organization

Program Type

Accreditation Association for Ambulatory Health Care (AAAHC)

Ambulatory surgical centers (ASCs)

Accreditation Commission for Health

Home health agencies (HHAs)

Care, Inc. (ACHC)

Hospices

American Association for Accreditation of

ASCs

Ambulatory Surgery Facilities (AAAASF)

Outpatient physical therapy (OPT) providers

Rural health clinics (RHCs)

American Osteopathic Association/

ASCs

Healthcare Facilities Accreditation Program (AOA/HFAP)

Critical access hospitals (CAHs)

Hospitals

Center for Improvement in Healthcare Quality (CIHQ)

Hospitals

Community Health Accreditation Program

HHAs

(CHAP)

Hospice

DNV GL-Healthcare (DNVGL)

Hospitals

CAHs

Institute for Medical Quality (IMQ)

ASCs

National Dialysis Accreditation Commission (NDAC)

ESRD Facilities

The Compliance Team (TCT)

RHC

Joint Commission

ASCs

CAHs

HHAs

Hospices

Hospitals

Psychiatric hospitals

Source: Centers for Medicare & Medicaid Services, https://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/SurveyCertificationGenInfo/Downloads/Accrediting-Organization-Contacts-for-Prospective-Clients-.pdf.27

The interrelationships among government agencies, regulators, professional associations and AOs can be surprisingly complex. For example, in the United States. Figure 1.3 shows the many organizations that play a role in the life of a physician assistant moving through training and into medical practice.

Figure 1.3Steps and organizations involved in becoming a practicing physician assistant. (Adapted from AAPA, becoming a PA, Alexandria, VA: AAPA, http://www.Aapa.org/your_pa_career/becoming_a_pa.Aspx.28).

We have covered the breadth of organizational structures in the public and private domains, defined the nature of their interactions, identified roles of healthcare information and management systems professionals and described the great number of governmental, regulatory, professional and AOs affecting our healthcare delivery systems today. The complexity of the processes can be overwhelming. Fortunately, advances in automation, including inexpensive data storage, increasing network capacities and simplified software programming tools, will allow professionals in healthcare information and management systems to make life simpler for those who deliver care by transferring much of the information processing requirements to automated tools.

Market and promote the profession

Provide continuing professional development opportunities

Represent members interests by monitoring development which may impact scope of practice, employment opportunities and enhancing relationships with related professionals

Regulatory bodies on the other hand have a purpose of protecting the public by regulating the profession. They may

Set requirements for entry to the profession

Maintain a list of individual eligible to practice

Develop standards of practice

Receive and investigate complaints about professional practice and administer appropriate disciplinary action when necessary

Require professionals to participate in continuing professional development

Chapter 1 · Healthcare Environment · Lesson 9 of 9

Technology Trends and Patient Outcomes

Big picture

This lesson collects what Chapter 1 says about where technology is taking care delivery and how the value of that technology is judged. It draws on the chapter's introduction, the ambulatory shift and the summary, and it corresponds to the chapter's fifth learning objective on evaluating trends and improving patient outcomes. The larger problem it addresses is that technology spending has to be justified against the same four pillars everything else is judged by, so a trend matters only if it moves quality, access, cost or value. The confusion to avoid is treating any modern system as a population health capability; the source ties population-level work to prevention, community impact and reporting rather than to infrastructure or billing performance.

Walkthrough

The move from encounters to population impact

Healthcare practice is increasingly focused on activities with the greatest impact on the overall health of communities and patient populations.
A state of health is not best achieved by limiting engagement to office visits and hospital admissions.
Engagement extends to wellness encounters with nonphysician healthcare providers.
It extends to virtual encounters through telehealth or mobile health technologies.
It extends to safety and preventive care outreach programs.
Reporting public and population health information is one of the named purposes of interrelationships among organizations.
The strain of healthcare costs on national economies forces continual reevaluation of the delivery paradigm to optimize outcomes at an affordable cost.

Population-level work is defined by who is being managed rather than by the technology used. The unit of attention moves from the visit to the group, and prevention and outreach become the work.

Example

A regional health system wanting to cut heart failure readmissions needs to know which patients are at risk and reach them before they decompensate. Risk stratification and outreach across the population address that directly; more storage or faster claims editing do not.

Question:

Explain how the source widens the definition of a health encounter beyond the office and hospital.
Why does the source say population and community impact has become the focus of practice?

Consumer expectations and virtual access

Patients are accustomed to an always-on, always-available experience and demand it from healthcare.
That expectation is credited with the proliferation of direct appointment booking and virtual visits using video calling apps.
Patients are no longer content to call an office and wait for a callback, or to wait weeks to see a specialist.
Urgent care and injury clinics are opening rapidly in response to demand for flexible hours.
Nontraditional settings such as drugstore minute clinics and walk-in options are emerging.
Practices responsive to this new model are the ones that will thrive.

The driver named here is patient expectation, not payer mandate or regulation. Options that attribute virtual care growth to reimbursement rules or accreditation standards are substituting a plausible cause for the stated one.

Question:

What does the source name as the cause of growth in virtual visits and direct booking?
Give two nontraditional or flexible-access settings the source names.

Demonstrating the value of health IT

Health IT carries the burden of demonstrating the value of the technology, alongside the quality, access and cost pressures everyone faces.
Value is shown through measured effect on outcomes, access and cost rather than through acquisition of new technology.
Improving one pillar requires trade-offs against the others, so a gain has to be assessed across all four.
Advances in automation, including inexpensive data storage, increasing network capacities and simplified software programming tools, will let professionals simplify work for those who deliver care.
The mechanism is transferring much of the information processing requirement to automated tools.

The summary's claim is specific about how technology helps. It reduces the information handling burden carried by clinicians rather than adding capability for its own sake.

Question:

How does the source say an organization demonstrates the value of health IT?
Name the three advances in automation the summary credits and the benefit they are expected to produce.

Memory tips

Trend test question: does it move quality, access, cost or value? If an option names only infrastructure or billing speed, it has not answered the outcome question asked.
Three widened encounter types: Wellness with nonphysician providers, Virtual through telehealth or mHealth, Outreach for safety and prevention. Read as W-V-O.
Attribution rule: virtual visits and direct booking come from patient expectation of always-on access. Keep payer mandates and accreditation out of that answer.
Summary trio of automation advances: cheap storage, bigger networks, simpler programming tools. The payoff is moving information processing off the people delivering care.

Key concepts

Population and community focus: the orientation of practice toward activities with the greatest impact on the health of communities and patient populations, including prevention and outreach
Widened health encounter: wellness encounters with nonphysician providers, virtual encounters through telehealth or mobile health, and safety and preventive care outreach
Always-on expectation: the patient expectation of continuous availability that the source credits for direct appointment booking and virtual visits
Nontraditional care settings: urgent care and injury clinics, drugstore minute clinics and other walk-in options
Demonstrated value of health IT: measured improvement in outcomes, access and cost, judged against the four pillars and their trade-offs
Automation advances: inexpensive data storage, increasing network capacity and simplified programming tools, which shift information processing to automated tools

Practice questions

12 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: focus on community and population impact · extension of encounters to wellness, virtual and outreach settings · public and population health reporting as an interrelationship purpose · cost pressure driving reevaluation of the delivery paradigm · always-on patient expectations and their effect on booking and virtual visits · growth of urgent care and nontraditional settings · the value pillar obligation on health IT · trade-offs among pillars · summary claims on automation advances and transfer of information processing.

Read the original source

Introduction

In order to best understand the context of healthcare information and management systems, it is necessary to first understand the concept of health. The World Health Organization (WHO) asserts that “health is a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity.”1 The WHO has not amended this definition since 1948.

Why is it important that we more fully understand this more holistic concept of health? If we do not present for care until we are in an advanced stage of disease or arrive with injuries from unsafe working or living practices, the cost of providing that care is likely to be high and the health outcomes often less than desired. The practice of healthcare, and thus the systems and management processes supporting it, is increasingly focused on those activities that have the greatest impact on the overall health of the community and patient populations. A state of health is not best achieved by limiting our engagement to patients’ visits to the doctor's office and admissions to hospitals, but is increasingly extended to wellness encounters with nonphysician healthcare providers, virtual encounters through telehealth or mobile health technologies and safety and preventive care outreach programs. The increasing strain of healthcare costs on national economies is forcing us to continually reevaluate our healthcare delivery paradigm to optimize health outcomes at an affordable cost. This is the macroeconomic context in which health information professionals and technologists will be performing their art.

The healthcare environment is an exceptionally complex one in which multiple players compete for placement on center stage. The four pillars of quality, access, cost and value require dynamic trade-offs in which healthcare professionals are under constant pressure to deliver the highest quality of care to the greatest portion of their supported population within tight cost constraints, while having to demonstrate the value of health information technology (IT). Placed upon this already complex four-legged stool are demands from multiple stakeholders, including governments, consumer groups, professional associations, regulatory organizations, payers/insurers and suppliers.

The Organisation for Economic Cooperation and Development (OECD) provides a solid basis for comparing international approaches with organizing and resourcing national healthcare with several key indicators on health system performance across countries. Figure 1.1 illustrates the substantial variance in spending by country and the proportion of public to private contribution to overall national health expenditures.

These investments have seen great reductions in cardiovascular and infant mortality rates, but lifestyle and risk factors show that more than 18% of adults continue to smoke daily,2 while almost one-third of children 5–9 years are overweight, with the rate of overweight children increasing from 20.5% to 31.4% from 1990 to 2016.2

Therefore, it is not hard to develop a sense of the complexities of the healthcare environment in which we toil. The breadth of stakeholders, the balance of public versus private funding and the active engagement to improve the health of populations, one individual at a time, produce a daunting task. This is the arena the health information professional and technologist enter to ensure that the best possible information management and systems support are available to improve the quality of life for the greatest number of our world's citizens.

Outpatient or Ambulatory Care—A Shift in the Care Setting

When a patient's care does not require the intensive management of a hospital setting that care is generally received in an outpatient or ambulatory care setting—most frequently in a doctor's office. Most primary care—the care practiced by primary care providers (PCPs) or general practitioners (GPs)—is provided in the ambulatory setting. Similarly, most PCP/GP referrals to clinical specialists for evaluation are completed in the ambulatory setting as well. The past decade has seen a dramatic shift from the acute care setting to less-expensive, more patient-friendly care settings. In the last few years, many less complicated surgical procedures that previously required an overnight hospital stay have been moved to the outpatient setting as well. Even major surgeries such as total joint replacement are now routinely performed in an ambulatory surgery center (ASC) with the patient going home the same day. Patients are demanding more flexible hours, and urgent care or injury clinics are opening up at a tremendous rate. Nontraditional care settings are springing up, with drugstores offering “minute clinics” and other walk-in options. Today's patient is accustomed to an always-on, always available experience and demands that from healthcare. There is a proliferation of direct appointment booking and “virtual” visits using video calling apps. These patients are no longer content to call a physician office and wait to be called back, or to wait weeks to see a specialist. Practices that are responsive to this new model will be the ones who thrive. There are multiple models of outpatient care, including single independent provider offices, larger multi-provider group practices in which a broader range of specialists may be available, and—while not a preferred approach from an expense perspective—hospital emergency departments.

Summary

Chapter 1 · Healthcare Environment · Supplemental lesson

Regulators, Accreditors and Deemed Status

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This lesson fills a gap the Review Guide leaves open: which body holds which kind of power over a healthcare organization. Chapter 1 names CMS, the Joint Commission and HIPAA without separating regulation from accreditation from certification, and that separation is what determines who must be satisfied and what happens when they are not. Three authorities operate on a hospital at once, and the exam builds adjacent-role traps from the overlap.

Walkthrough

Three kinds of authority

Regulation is government power. CMS sets the Conditions of Participation, the requirements a hospital must meet to bill Medicare and Medicaid, and failing them means losing federal reimbursement.
State health departments license facilities, and without a licence an organization cannot operate at all.
Accreditation is a voluntary review by a private body against its own standards.
The Joint Commission is the best known accreditor, alongside DNV, NCQA, URAC and AAAHC, which accredit different settings and functions.
Certification is narrower still: a specific product, program or individual is certified against a defined criterion, as ONC certifies health IT modules rather than hospitals.
HIPAA is enforced by the HHS Office for Civil Rights, not by CMS and not by the Joint Commission, so an accreditation survey is not a HIPAA audit.

Question:

Distinguish regulation, accreditation and certification by what each acts on.
Which body enforces HIPAA, and why does that matter for how privacy failures surface?

Deemed status and how surveys work

Deemed status is the mechanism connecting regulation and accreditation.
CMS designates certain accrediting organizations as having standards at least as rigorous as the Conditions of Participation.
A hospital accredited by one of those bodies is deemed to meet the conditions and is not separately surveyed by the state on the agency's behalf.
This is why accreditation is voluntary and yet almost universal, since the practical alternative is a direct state survey.
Accreditation surveys are unannounced and use tracer methodology, following one patient's actual experience through the system and pulling on whatever threads appear.
That makes accreditation readiness continuous rather than episodic, and the surveyor will look at the record, the alert, the downtime procedure and the audit log while tracing.
A sentinel event is a patient safety event resulting in death, permanent harm or severe temporary harm.
It obligates the organization to conduct a root cause analysis and produce a corrective action plan.
The Joint Commission also publishes Sentinel Event Alerts on recurring risks, several of which concern health IT directly.

Example

An ONC-certified EHR says something about the software. It says nothing about whether the hospital using it meets the Conditions of Participation. Two objects, two authorities.

Question:

Explain deemed status in three sentences.
Define a sentinel event and state the chain it triggers.
What is tracer methodology, and what does it imply for readiness?

Memory tips

Three authorities: regulation acts on organizations by law, accreditation acts on organizations by voluntary review, certification acts on products, programs or people.
Deemed status chain: CMS designates the accreditor, the accreditor surveys, compliance is deemed, no separate state survey.
Accreditor scope: Joint Commission hospitals and many settings, DNV hospitals, NCQA health plans and medical homes and HEDIS, URAC utilization review and telehealth, AAAHC ambulatory.
Sentinel event chain in order: event, root cause analysis, corrective action plan.
RCA is retrospective and event-triggered. Compare FMEA in S7.1, which is prospective.
Currency note, read once: effective 1 January 2026 the Joint Commission replaced National Patient Safety Goals with 14 National Performance Goals under Accreditation 360. The Review Guide predates this; answer in the guide's frame when a stem says NPSG.

Key concepts

Regulation: government power, exercised through CMS Conditions of Participation and state licensure
Accreditation: voluntary review by a private body against its own standards, by accreditors including the Joint Commission, DNV, NCQA, URAC and AAAHC
Certification: the narrower confirmation of a product, program or individual against a defined criterion, as ONC certifies health IT modules
Deemed status: CMS designation allowing an accredited organization to be treated as meeting the Conditions of Participation without separate state survey
Tracer methodology: the unannounced survey technique of following one patient's experience through the system
Sentinel event: a patient safety event resulting in death, permanent harm or severe temporary harm, obligating root cause analysis and a corrective action plan
Office for Civil Rights: the HHS body enforcing HIPAA, on a track separate from accreditation

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the three kinds of authority and what each acts on · CMS Conditions of Participation and state licensure · named accreditors and their settings · ONC certification scope · OCR enforcement of HIPAA · deemed status mechanism and its effect on voluntariness · unannounced surveys and tracer methodology · continuous readiness and health IT artifacts · sentinel event definition and the RCA and corrective action chain · Sentinel Event Alerts.

Read the supplemental lesson source

S1.1 — Regulators, Accreditors and Deemed Status

Chapter 1 · Task I.A.4 · About 12 minutes

1. Learn the topic

Where this fits

Chapter 1 asks you to recognize how laws, regulations and accreditation shape health IT decisions. Most people arrive knowing the names — CMS, the Joint Commission, HIPAA — without knowing which body has which kind of power over an organization. That distinction is what the exam actually tests, because it determines who you must satisfy and what happens if you don't.

There are three separate kinds of authority operating on a hospital at once, and they are frequently confused.

What it means

Regulation is government power. CMS sets the Conditions of Participation (CoPs) — the requirements a hospital must meet to bill Medicare and Medicaid. Failing them means losing federal reimbursement, which for most hospitals is existential. State health departments license facilities; without a licence you cannot operate at all.

Accreditation is a voluntary review by a private body against its own standards. The Joint Commission is the best known, but it is not the only one — DNV, NCQA, URAC and AAAHC accredit different settings and functions.

Certification is narrower still: a specific product, program or individual is certified against a defined criterion. ONC certifies health IT modules. It does not certify hospitals.

How it works

The mechanism that connects regulation and accreditation is deemed status. CMS designates certain accrediting organizations as having standards at least as rigorous as the CoPs. A hospital accredited by one of those bodies is deemed to meet the CoPs and is not separately surveyed by the state on CMS's behalf.

This is why accreditation is described as voluntary and yet almost universal. Nothing forces a hospital to seek Joint Commission accreditation. But the practical alternative is a direct state survey against the CoPs, which most organizations prefer to avoid.

Accreditation surveys are unannounced and use tracer methodology — the surveyor picks a patient and follows that patient's actual experience through the system, pulling on whatever threads appear. This is why accreditation readiness is continuous rather than episodic, and why health IT matters to it: the surveyor will look at the record, the alert, the downtime procedure and the audit log as they trace.

When something goes badly wrong, the accreditation vocabulary shifts. A sentinel event is a patient safety event resulting in death, permanent harm, or severe temporary harm. It obligates the organization to conduct a root cause analysis and produce a corrective action plan. The Joint Commission also publishes Sentinel Event Alerts on recurring risks — several of which concern health IT directly.

Examples and non-examples

Straightforward. A hospital fails to maintain an accurate medication list and is cited during a survey. The citation is against an accreditation standard; the underlying obligation traces to a CoP.

Connecting to another concept. A health system's EHR vendor is ONC-certified. That certification says something about the software. It says nothing about whether the hospital using it meets the CoPs. Two different objects, two different authorities.

Non-example. HIPAA is enforced by the HHS Office for Civil Rights, not by CMS and not by the Joint Commission. An accreditation survey is not a HIPAA audit. Privacy failures surface through OCR complaints and breach reports, on an entirely separate track.

Common misconceptions

"Accreditation is required by law." It isn't. It is voluntary and functionally near-mandatory — an important difference when a stem uses the word "required."

"The Joint Commission is a government agency." It is a private, non-profit organization. CMS grants it deeming authority; it does not derive its standards from CMS.

"A sentinel event means someone died." Death is one qualifying outcome. Permanent harm and severe temporary harm also qualify.

2. Exam focus

What you must know

CMS sets the Conditions of Participation; failure jeopardizes Medicare/Medicaid reimbursement.

Accreditation is voluntary; deemed status is the bridge that makes it function as though it weren't.

Accreditors: Joint Commission (hospitals and many settings), DNV (hospitals), NCQA (health plans, medical homes, and the owner of HEDIS measures), URAC (utilization review, specialty pharmacy, telehealth), AAAHC (ambulatory).

Sentinel event → root cause analysis → corrective action plan. That chain is testable in order.

OCR enforces HIPAA. Separate track from accreditation.

Distinctions likely to be tested

Regulation vs. accreditation vs. certification (three different objects: organizations, organizations, and products/people).

Licensure (state, permits operation) vs. accreditation (private, signals quality) vs. certification (specific criterion).

Root cause analysis is retrospective, triggered by an event. Compare with FMEA in lesson S7.1, which is prospective.

How this appears in a question

Typically as an adjacent-role trap: four legitimate bodies, and the stem names a function only one of them performs. Anchor on the function in the stem, not on which name is most familiar.

Currency note — read once, don't drill. Effective 1 January 2026 the Joint Commission replaced National Patient Safety Goals (NPSGs) with 14 National Performance Goals (NPGs) under its Accreditation 360 model, removing more than 700 elements of performance from the hospital program. The Review Guide predates this. If a stem says NPSG, answer in that frame. If a distractor says NPG, it is current terminology, not a trick.

3. Teach it back

Close this file. Explain to a colleague who works in finance:

1. Why a hospital would pay for a voluntary accreditation survey it is not legally required to have.

2. The difference between what CMS can do to a hospital and what the Joint Commission can do to a hospital.

3. Give an original example of something that would be a sentinel event and something that would not.

Reveal only after you've answered.

<summary>Key-point checklist</summary>

[ ] Named deemed status as the reason accreditation substitutes for a CMS/state survey

[ ] CMS power = reimbursement eligibility via the CoPs; Joint Commission power = accreditation status, which is what confers deemed status

[ ] Accreditation is voluntary; licensure is not

[ ] Sentinel event = death, permanent harm, or severe temporary harm — not death alone

[ ] Connected sentinel event to the RCA obligation

[ ] Did not attribute HIPAA enforcement to CMS or the Joint Commission

</details>

4. Practice

Items SQ-01 to SQ-04 in 03_supplemental-items.md.

5. Key takeaway

Three authorities, three objects: government regulates organizations, accreditors accredit organizations voluntarily, certifiers certify products and people. Deemed status is the hinge that makes voluntary accreditation function as a regulatory substitute — and it is the single fact that explains why the whole arrangement exists.

Chapter 1 · Healthcare Environment · Supplemental lesson

Value-Based Payment Architecture

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This lesson supplies the payment logic underneath Chapter 1's description of organization types and trends. Without it, questions about population health, analytics investment and care coordination read as preferences rather than economic necessities. Value-based payment is not one thing but a continuum of increasing financial risk, and each rung upward demands capabilities the rung below did not.

Walkthrough

The risk ladder

Fee-for-service pays per unit of service delivered, so the incentive is volume.
Value-based payment ties some portion of payment to measured quality and cost outcomes, shifting the incentive toward keeping a defined population healthy at a defined cost.

Pay-for-performance: still fee-for-service underneath, with a bonus or penalty layered on quality metrics. MIPS works this way for clinicians across quality, cost, improvement activities and promoting interoperability, and MIPS Value Pathways are specialty-aligned subsets.
Shared savings, upside only: the provider is measured against a spending benchmark for an attributed population and shares savings if it comes in under while meeting quality thresholds. This is the entry rung of the Medicare Shared Savings Program, which requires a minimum of 5,000 attributed beneficiaries.
Shared risk, two-sided: the same structure, but exceeding the benchmark now costs money, requiring capital reserves and real analytics.
Bundled or episode payment: a single payment covers all services in a defined clinical episode, with the provider absorbing variance inside it. TEAM is CMS's current mandatory episode model.
Capitation or global budget: a fixed per-member-per-month amount covers all care for the population, at maximum risk and maximum flexibility.

An accountable care organization is the organizational vehicle that takes on the upper rungs for a population, not itself a payment model.

Question:

Name the rungs of the ladder in order and the risk each transfers.
Distinguish an ACO from a payment model.
Give the MSSP beneficiary minimum and what the program is.

Why the ladder drives IT

Shared savings requires attribution logic and cost benchmarking.
Two-sided risk requires predictive stratification to intervene before cost is incurred.
Capitation requires the whole apparatus: registries, risk adjustment, care management workflow and data from outside the organization's own walls.
That is the point at which interoperability and population health analytics stop being optional.
Risk adjustment matters more as the organization climbs, because a benchmark ignoring how sick the population is punishes taking complex patients.
Coding completeness, including SDOH Z codes, therefore carries financial as well as clinical weight.
HEDIS is NCQA's quality measure set used heavily by health plans, and Star Ratings rate Medicare Advantage plan performance.

Example

A readmission is revenue under fee-for-service and a loss under shared risk. The same risk model pays for itself in one contract and not the other.

Question:

Match each capability to the rung that first requires it.
Explain why risk adjustment matters more at higher rungs.
Distinguish quality measurement from quality payment using the named examples.

Memory tips

Ladder order: FFS, pay-for-performance, upside shared savings, two-sided risk, bundled episode, capitation.
Upside-only cue: no downside exposure. Two-sided cue: exceeding the benchmark costs money.
Bundle versus capitation: a defined episode versus a defined population over time.
MSSP is the permanent Medicare ACO program with a 5,000-beneficiary minimum; Innovation Center models are time-limited tests.
Measurement versus payment: HEDIS and eCQMs measure, MIPS and Star Ratings pay.

Key concepts

Fee-for-service: payment per unit of service delivered, incentivizing volume
Pay-for-performance: a bonus or penalty layered on fee-for-service based on quality metrics, as in MIPS
Shared savings: measurement against a spending benchmark for an attributed population, upside only at the entry rung of MSSP
Two-sided risk: shared savings with downside exposure when the benchmark is exceeded
Bundled or episode payment: a single payment covering all services in a defined clinical episode
Capitation: a fixed per-member-per-month payment covering all care for a population
Accountable care organization: the organizational vehicle that enters payment models rather than a payment model itself
HEDIS and Star Ratings: NCQA's plan quality measure set and the Medicare Advantage plan performance rating

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: fee-for-service and value-based incentives · the five rungs in order with their mechanics · MIPS and MVPs · MSSP and the 5,000-beneficiary minimum · TEAM as the current mandatory episode model · the ACO as vehicle · the capability demanded at each rung · risk adjustment and coding completeness · HEDIS and Star Ratings.

Read the supplemental lesson source

S1.2 — Value-Based Payment Architecture

Chapter 1 · Tasks I.A.1, I.A.5 · About 14 minutes

1. Learn the topic

Where this fits

Every strategic decision in a health system — including every IT investment — is shaped by how the organization gets paid. Chapter 1 describes organization types and trends; this lesson supplies the payment logic underneath them. Without it, questions about population health, analytics investment and care coordination read as abstract preferences rather than economic necessities.

What it means

Fee-for-service (FFS) pays per unit of service delivered. More visits, more tests, more revenue. The incentive is volume.

Value-based payment ties some portion of payment to measured quality and cost outcomes rather than volume alone. The incentive shifts toward keeping a defined population healthy at a defined cost.

That's the whole idea. What makes it complicated is that "value-based" is not one thing — it is a continuum of increasing financial risk.

How it works

Read this as a ladder. Each rung transfers more risk from payer to provider.

1. Pay-for-performance. Still FFS underneath. A bonus or penalty is layered on top based on quality metrics. Low risk. Medicare's MIPS works this way for clinicians, adjusting payment based on performance across quality, cost, improvement activities and promoting interoperability. MVPs (MIPS Value Pathways) are specialty-aligned subsets of MIPS.

2. Shared savings (upside only). The provider is measured against a spending benchmark for an attributed population. Come in under it while meeting quality thresholds, share the savings. Exceed it, and you simply don't earn a bonus. This is the entry rung of the Medicare Shared Savings Program (MSSP), the permanent ACO program, which requires a minimum of 5,000 attributed beneficiaries.

3. Shared risk (two-sided). Same structure, but exceeding the benchmark now costs you. Requires real capital reserves and real analytics.

4. Bundled / episode payment. A single payment covers all services in a defined clinical episode — a joint replacement, say, from surgery through recovery. The provider absorbs the variance within the episode. TEAM (Transforming Episode Accountability Model) is CMS's current mandatory episode model.

5. Capitation / global budget. A fixed per-member-per-month amount covers all care for the population. Maximum risk, maximum flexibility.

An ACO — accountable care organization — is the organizational vehicle that takes on rungs 2 through 5 for a population. It is not itself a payment model. That distinction matters.

Why this drives IT

Each rung upward demands capabilities the rung below didn't. Shared savings requires attribution logic and cost benchmarking. Two-sided risk requires predictive stratification to intervene before cost is incurred. Capitation requires the whole apparatus: registries, risk adjustment, care management workflow, and data from outside your own walls — which is why interoperability and population health analytics stop being nice-to-haves at that point.

Examples and non-examples

Straightforward. A system invests in a readmission-risk model. Under FFS, a readmission is revenue. Under a shared-risk contract, it is a loss. The model only pays for itself under the second arrangement.

Connecting to another concept. Risk adjustment matters more as you climb the ladder, because a benchmark that ignores how sick your population is will punish you for taking complex patients. This is why coding completeness — including the SDOH Z codes in lesson S1.3 — has financial as well as clinical weight.

Non-example. A discount off billed charges is not value-based payment. Price changed; the volume incentive did not.

Common misconceptions

"Value-based care means the provider always takes risk." Pay-for-performance transfers almost none.

"An ACO is a payment model." It's an organization that enters payment models.

"Capitation is the same as an HMO." Capitation is a payment mechanism; an HMO is a plan design that commonly uses it.

2. Exam focus

What you must know

The ladder in order: FFS → pay-for-performance → upside shared savings → two-sided risk → bundled/episode → capitation.

MSSP is the permanent Medicare ACO program (5,000-beneficiary minimum). Innovation Center models are time-limited tests.

MIPS adjusts clinician payment on performance; MVPs are its specialty-aligned pathways.

HEDIS is NCQA's quality measure set, used heavily by health plans; Star Ratings rate Medicare Advantage plan performance.

An ACO is a vehicle, not a model.

Distinctions likely to be tested

Upside-only vs. two-sided risk. A stem describing "no downside exposure" is the first, not the second.

Bundled payment (defined episode) vs. capitation (defined population over time).

Quality measurement (HEDIS, eCQMs) vs. quality payment (MIPS, Star Ratings).

How this appears in a question

Usually as a scenario naming a contract feature and asking which model it describes, or asking which capability the organization now needs. Match the risk description to the rung.

Currency note — read once. ACO REACH concludes at the end of 2026; the 10-year LEAD Model succeeds it beginning 2027. Model names churn constantly. The ladder does not. Learn the ladder.

3. Teach it back

Explain to a clinician who has only ever worked under fee-for-service:

1. Why their organization suddenly cares about patients who don't come in.

2. The difference between upside-only shared savings and two-sided risk, in terms of what happens in a bad year.

3. Predict: what analytics capability becomes necessary at rung 3 that wasn't at rung 1?

<summary>Key-point checklist</summary>

[ ] Framed the shift as volume incentive → outcome incentive

[ ] Placed the rungs in ascending risk order

[ ] Upside-only = forgo bonus; two-sided = owe money

[ ] Named ACO as the organizational vehicle, not the model

[ ] Connected rung to required capability (attribution → stratification → full population management)

[ ] Mentioned risk adjustment as the fairness mechanism on benchmarks

</details>

4. Practice

Items SQ-05 to SQ-08.

5. Key takeaway

Value-based payment is one continuum of increasing financial risk, not a category. Every rung upward demands new data capability, which is why payment reform is the engine behind health IT investment. Learn the ladder; the model names will change under you.

Chapter 1 · Healthcare Environment · Supplemental lesson

Social Determinants as Structured Data

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Population health only works if social risk is captured as data rather than noted in a narrative. This lesson covers how that capture happens: the screening instrument, the code and the exchange standard. The distinction to hold is between the population-level condition and the individual-level need that can be acted on.

Walkthrough

SDOH, HRSN and the four steps

Social determinants of health are the non-clinical conditions shaping health outcomes: housing, food security, transportation, employment, education and social connection.
Health-related social needs are the individual-level, actionable version of those conditions, meaning what this patient lacks right now.
SDOH describes the population-level condition; HRSN is the individual-level need.
Screen: a validated instrument asks the patient, most commonly PRAPARE or the CMS Accountable Health Communities HRSN screening tool, with questions and answers coded in LOINC.
Document: identified needs are recorded as ICD-10-CM Z codes, with the SDOH range Z55 to Z65 covering education and literacy, employment, occupational exposure, physical environment, housing and economic circumstances, social environment and psychosocial factors.
Those sit inside the broader Z00 to Z99 family covering factors influencing health status and contact with health services.
Intervene: referrals to community-based organizations, with tracking of whether the referral closed.
Exchange: the Gravity Project, an HL7 FHIR Accelerator, defines how this moves between systems through the SDOH Clinical Care implementation guide.

Example

A social worker's note describing housing instability is real information and not structured data. It cannot be counted, stratified, exchanged or risk-adjusted, which is what the coding layer exists to enable.

Question:

Distinguish SDOH from HRSN.
Name the four steps and the standard attached to each.
Give the Z code range for SDOH and the family it sits within.

Memory tips

Chain in order: screen, document, intervene, exchange.
Z55 to Z65 is the SDOH subset of Z00 to Z99. Not all Z codes are SDOH codes.
Instruments: PRAPARE and AHC-HRSN, coded in LOINC.
Gravity Project is the FHIR Accelerator standardizing SDOH exchange.
Z codes are diagnosis codes, not billing drivers; their value is analytic through stratification and risk adjustment.

Key concepts

Social determinants of health: the non-clinical population-level conditions shaping health outcomes
Health-related social needs: the individual-level, actionable version of those conditions
Screening instruments: PRAPARE and the CMS Accountable Health Communities HRSN tool, with questions coded in LOINC
SDOH Z codes: ICD-10-CM codes Z55 to Z65 within the Z00 to Z99 family, used for stratification and risk adjustment rather than payment
Gravity Project: the HL7 FHIR Accelerator defining SDOH data exchange through the SDOH Clinical Care implementation guide

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: SDOH and HRSN definitions and the level distinction · the four-step chain · named screening instruments and LOINC coding · the Z55 to Z65 range and its contents · placement within Z00 to Z99 · referral and closure tracking · the Gravity Project and its implementation guide · the analytic rather than payment value of Z codes.

Read the supplemental lesson source

S1.3 — Social Determinants as Structured Data

Chapters 1 and 4 · Task I.A.5 · About 10 minutes

1. Learn the topic

Where this fits

Population health is a named example in blueprint task I.A.5. But population health only works if social risk is captured as data rather than noted in a narrative. This lesson covers how that capture actually happens — the screening instrument, the code, the exchange standard.

What it means

Social determinants of health (SDOH) are the non-clinical conditions that shape health outcomes: housing, food security, transportation, employment, education, social connection. The related term health-related social needs (HRSN) refers to the individual-level, actionable version of those conditions — what this patient lacks right now.

The distinction matters: SDOH describes the population-level condition; HRSN is the individual-level need you can act on.

How it works

Four steps, and each has its own standard.

Screen. A validated instrument asks the patient. The two most commonly referenced are PRAPARE and the CMS Accountable Health Communities HRSN screening tool. The questions and answers are coded with LOINC.

Diagnose / document. Identified needs are recorded as ICD-10-CM Z codes. The SDOH range is Z55–Z65 — education and literacy, employment, occupational exposure, physical environment, housing and economic circumstances, social environment, psychosocial. These sit inside the broader Z00–Z99 family, which covers "factors influencing health status and contact with health services" generally.

Set goals and intervene. Referrals to community-based organizations, and tracking of whether the referral closed.

Exchange. The Gravity Project — an HL7 FHIR Accelerator — defines how all of the above moves between systems, via the SDOH Clinical Care implementation guide.

Examples and non-examples

Straightforward. A patient screens positive for transportation insecurity. A Z code is applied. The care manager arranges transport. Missed appointments fall.

Connecting to another concept. SDOH data feeds risk adjustment (lesson S1.2). A population with high social risk will look expensive against an unadjusted benchmark. Capturing the risk is how the organization gets credit for it.

Non-example. A social worker's free-text note describing housing instability is real information but not structured data. It cannot be counted, stratified, exchanged or risk-adjusted. The whole point of the coding layer is to make the need computable.

Common misconceptions

"Z codes are billing codes for reimbursement." They are ICD-10-CM diagnosis codes and they rarely drive payment directly. Their value is analytic — stratification, risk adjustment, and demonstrating population need.

"All Z codes are SDOH codes." Z00–Z99 is a large family covering routine exams, screening, status codes and more. Z55–Z65 is the SDOH subset.

"Screening is enough." Screening without referral capacity generates need you cannot meet. The four-step chain matters as a chain.

2. Exam focus

What you must know

SDOH = population-level conditions; HRSN = individual, actionable needs.

The chain: screen → document → intervene → exchange.

Z55–Z65 within ICD-10-CM; a subset of Z00–Z99.

Gravity Project = the HL7 FHIR Accelerator standardizing SDOH data exchange.

Screening instruments: PRAPARE, AHC-HRSN; questions coded in LOINC.

Distinctions likely to be tested

Structured/coded capture vs. narrative documentation — only the first is usable for population analytics.

SDOH (condition) vs. HRSN (need) vs. health equity (goal).

How this appears in a question

As a "what does the organization need in order to…" stem, where the answer is the structured-capture step and the distractors are downstream activities that depend on it. Classic umbrella-versus-component: coded capture is the foundation, reporting is what it enables.

3. Teach it back

Explain to a hospital executive:

1. Why a note in the chart saying "patient is homeless" is worth less than a Z code saying the same thing.

2. Where LOINC and ICD-10-CM each enter the process, and why it's two standards rather than one.

3. Give an original example of a social need and trace it through all four steps.

<summary>Key-point checklist</summary>

[ ] Named computability as the reason structured beats narrative

[ ] LOINC codes the screening question/answer; ICD-10-CM Z codes the resulting documented condition

[ ] Z55–Z65 as the SDOH range, subset of Z00–Z99

[ ] Walked all four steps in order, ending at exchange

[ ] Connected to risk adjustment or stratification

</details>

4. Practice

Items SQ-09 to SQ-11.

5. Key takeaway

Social risk becomes actionable only when it becomes coded. Screen with a validated instrument, document with Z55–Z65, intervene, and exchange through Gravity-conformant FHIR. Narrative alone cannot be stratified, and what cannot be stratified cannot be managed.

Chapter 2 · Technology Environment · Lesson 1 of 9

The Three Components of the Technology Environment

Big picture

This opening section sets the frame for the whole chapter by naming the three parts every healthcare facility needs to run IT. It is the first section of the Technology Environment domain and everything later in the chapter hangs off one of the three names. The larger problem it solves is scope: without the split into applications, hardware and networks, a discussion of health IT turns into a list of products. The part most often blurred is hardware versus networks, because servers and network connections sit physically side by side, but the source assigns connection and accessibility to networks.

Walkthrough

Where healthcare IT stands today

Healthcare adopted information technology more slowly than other industries.
The electronic health record is now an essential part of every facility that provides patient care, from population health to the intensive care unit.
Most hospitals and outpatient sites run one wireless network for staff and a separate network for family and visitors.
Patients update social media, review care plans from the hospital bed and check in for outpatient visits from smartphones.
Institutions that once banned staff social network use now employ staff to monitor and update social media sites.
Many patients keep personal health records online and also have portal access through the facility's EHR.

Understanding the attributes of healthcare IT, and the applications and hardware needed to use them, is presented as essential to improving care and its safety.

Question:

Why does the source describe two separate wireless networks as common practice?
State the source's claim about why understanding healthcare IT attributes matters.

The three components

Applications: the software used by administrative, clinical and support staff to process and store data, manage patients' records, and provide information and knowledge.
Hardware: the actual servers, whether virtual, cloud or physical, plus network connections and the devices used to access and generate information.
Networks: the wired or wireless connections that link the infrastructure together and enable accessibility of the applications and patient data.
A healthcare facility requires all three components to function.
The sections of these components change frequently with rapid technology change and software improvement.
Decreased access time and increased processor and hard drive speed return processed data to the requesting clinician more quickly.
Technology changes both support and change the applications and their functions.

The source flags its own lists as overviews rather than complete inventories, which matters when a question asks what the guide names rather than what exists in the market.

Example

A bedside nurse scanning a wristband is using an application, on a handheld device, over a wireless network. Remove any one of the three and the medication scan does not happen.

Question:

Name the three components of the technology environment with the source's definition of each.
Which component carries accessibility, and why is that not assigned to hardware?

Memory tips

Three components: Applications, Hardware, Networks. Applications are what you see, hardware is what runs it, networks are what connect it.
Definition cue words: applications process and store, hardware accesses and generates, networks link and enable accessibility.
Servers count as hardware in all three forms named: virtual, cloud, physical.

Key concepts

Applications: the software used by administrative, clinical and support staff to process and store data, manage records and provide information and knowledge
Hardware: the virtual, cloud and physical servers, network connections and devices used to access and generate information
Networks: the wired or wireless connections that link infrastructure together and enable accessibility of applications and patient data

Practice questions

1 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

1 The three components of the healthcare technology environment areCanonical

Aapplications, hardware and networksBapplications, databases and networksChardware, networks and interfacesDapplications, hardware and terminologies

Source fidelity

Covered from the source: slower healthcare IT adoption · the EHR as essential across settings · separate staff and visitor networks · patient use of devices and portals · the three components and their definitions · all three required to function · effect of speed improvements on clinician response · the guide's lists as overviews rather than complete listings.

Read the original source

Introduction

The world now is steered by technology and computers—from social networks to IoT (Internet of Things) devices, everything we interact with has a computer in the process. Healthcare may have been a little bit slower than other industries to adopt information technology (IT), but now the electronic health record (EHR) is an essential part of every facility that provides care to patients—from population health to the intensive care unit. Patients are no longer surprised when the provider pulls out a tablet computer instead of a paper chart and pen.

Most hospitals and outpatient sites provide wireless networks for staff to use in caring for patients and a different network for family and visitors to access. It is common to see patients updating their status on Facebook, reviewing their care plan from their hospital beds or checking in for their outpatient visit using their smartphone. Where hospitals used to have policies forbidding employees from accessing social networks during working hours, many institutions now employ staff to monitor and update social media sites. Many patients have personal health records (PHRs) they manage online, as well as access to a patient portal through the facility's EHR system. Healthcare IT is changing the way that healthcare does business, as well as the way that clinicians care for patients. An understanding of the attributes of healthcare IT, as well as knowledge of the applications and hardware required for their use, is essential in helping to improve the care and the safety of the care provided to patients.

There are three components of the technology environment:

Applications—the software used by administrative, clinical and support staff to process and store data, manage patients’ records, provide information and knowledge

Hardware—the actual servers (virtual, cloud and physical), network connections and devices used to access and generate information

Networks—the wired or wireless connections that link the infrastructure together and enable accessibility of the applications and patient data

A healthcare facility requires these three components to function. While this may seem a very simplistic listing, these are essential to providing IT to a healthcare institution. And, while essential, with the rapid changes in technology and improvements in software, the sections of these components change frequently. Decreased access time and increased processor and hard drive speed enables the application to return processed data to the requesting clinician much more quickly. Technology changes are supporting—and changing the applications and the functions of the applications. The illustrations here are not intended to be a complete listing but to provide an overview.

Chapter 2 · Technology Environment · Lesson 2 of 9

Clinical Applications

Big picture

This section covers the software clinicians touch, starting with the terminology problem that EMR, EHR and PHR create. It is the first and largest of the application groups in the chapter and supplies the vocabulary later chapters assume. The larger problem it solves is that clinical work is spread across departments with their own systems, so the chapter has to explain both the central record and the specialty systems around it. EMR and EHR are the pair the exam leans on: one setting versus multiple settings over time.

Walkthrough

EMR, EHR and PHR

The EMR is the continuous, longitudinal electronic record in one specific setting, such as a provider's office, a hospital or a home healthcare service.
The EHR is a longitudinal record covering multiple settings over time.
The PHR is a medical record often created, edited, maintained and controlled by the patient.
A PHR may include importation of clinical data from other sources.
PHRs are often created online and are accessible to providers when the patient invites them to review information using secure access.

The three terms are described as seeming interchangeable while carrying different meanings, which is exactly why they appear as competing options.

Question:

Distinguish EMR, EHR and PHR in one sentence each, using the source's defining feature for each.
Who controls the PHR, and how does a provider gain access to it?

What the EHR does and what it connects to

Clinical applications support patient care wherever it is delivered, and the most apparent one is the EHR.
In some institutions the EHR is a one-vendor application; in others it is best of breed, with many different vendor applications performing different functions.
Clinicians use the EHR to document care from medication administration to order entry, and to retrieve lab and radiology data.
Provider offices can send electronic prescriptions to the pharmacy and import or export data from inpatient stays or outpatient testing through a health information exchange.
EHR systems can execute algorithms that stratify clinical and operational activities.
Data points driving those prediction models range from vital signs and lab results to the number of no shows for outpatient visits.
Enterprise EHRs may include population health capabilities, clinical specialty modules and integration with outside regulatory and public health systems.

Best of breed is a configuration choice, not a defect. It buys departmental fit and pays for it in the number of interfaces the organization has to maintain.

Question:

Contrast a single-vendor EHR with a best of breed approach.
Give three kinds of data the source says can drive EHR stratification algorithms.

Specialty systems, PACS and the case for interoperability

The EHR interfaces with specialized systems in different departments.
In the United States, radiology and pathology formatting and data display are governed by accrediting agencies including Clinical Laboratory Improvement Amendments, the College of American Pathologists and the American College of Radiology.
In Europe, the European Cooperation for Accreditation covers laboratory certifications.
Dietitians, case managers and social workers have specific software functionality needs, often dictated by professional or regulatory standards.
Areas with specialized documentation and information needs include the perinatal areas of labor and delivery, nursery, neonatal intensive care and postpartum.
They also include the perioperative areas of preoperative unit, operating rooms and post anesthesia care unit, plus critical care units, outpatient primary care centers and special functions such as renal dialysis.
The picture archiving and communication system stores and displays images from ultrasound to computed tomography and magnetic resonance imaging.
PACS requires fine-resolution monitors, large storage drives, good bandwidth and large amounts of random access memory for image display.
Some major EHR vendors support all specialty areas; others require purchase and interface of a niche system for each specialty.
The goal of all these systems is to communicate and exchange patient health information, known as interoperability.
Data should not be entered into systems more than one time.
Images available in the EHR save clinician time and institutional money, since no films are created, stored or retrieved.
Perinatal systems archive fetal monitor strips electronically, saving thousands of dollars in paper strip storage charges.

Example

A clinician reviewing a CT in the EHR rather than walking to radiology is the source's own example of the savings: the time is the clinician's, the money is the film handling the institution no longer pays for.

Question:

Name the perinatal and perioperative areas the source lists as having specialized needs.
What does PACS store, and what four hardware demands does it place on the environment?
Explain the two savings the source attributes to images being viewable in the EHR.

Memory tips

Record trio: EMR is one setting, EHR is many settings over time, PHR is patient controlled. Count the settings and you have the answer.
Accrediting agencies for lab and imaging display: CLIA, CAP, American College of Radiology in the United States; European Cooperation for Accreditation in Europe.
Perinatal four: labor and delivery, nursery, neonatal intensive care, postpartum. Perioperative three: preoperative unit, operating rooms, post anesthesia care unit.
PACS hardware four: fine-resolution monitors, large storage drives, good bandwidth, large RAM.
Interoperability principle to recite: data should not be entered more than one time.

Key concepts

EMR: the continuous, longitudinal electronic record in one specific care setting
EHR: a longitudinal record covering multiple settings over time
PHR: a record often created, edited, maintained and controlled by the patient, which may import clinical data and is shared with providers by patient invitation
Best of breed: an EHR environment assembled from many vendors' applications performing different functions
Specialty systems: niche applications for areas such as perinatal, perioperative, critical care, primary care and dialysis, interfaced when the EHR vendor does not cover them
PACS: the picture archiving and communication system that stores and displays images and requires high-resolution monitors, large storage, bandwidth and RAM
Interoperability: the goal of communicating and exchanging patient health information so data is never entered more than once

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: EMR, EHR and PHR definitions and their confusability · single-vendor versus best of breed · EHR documentation and retrieval uses · e-prescribing and HIE import and export · stratification algorithms and their data points · enterprise EHR capabilities · accrediting agencies governing lab and imaging display · other disciplines' functionality needs · named perinatal, perioperative and other specialized areas · PACS function and hardware demands · niche system interfacing · interoperability goal and the single-entry rule · savings from images in the EHR and electronic fetal strip archiving.

Read the original source

Software in Healthcare IT

Software provides the face of healthcare IT. Hardware is not typically visible to the end users, but the applications that run on that hardware are. Use of the various software applications, along with changes in workflow and processes, can benefit the organization. The software is what the end user interacts with, using interfaces ranging from mobile devices to voice enabled assistants. There are a large number of applications, so we will discuss the major groups of applications and examine some of the newer ideas that are in the pipeline.

Clinical Applications

As with most specialties, healthcare IT has developed its own terminology and acronyms. Some of the terms seem interchangeable when, in fact, they do have different meanings. The EHR, the electronic medical record (EMR) and the PHR are examples of this. The EMR is the continuous, longitudinal electronic record in one specific setting—a provider's office, a hospital or a home healthcare service. The EHR is a longitudinal record covering multiple settings over time.1–3 The PHR is a medical record often created, edited, maintained and controlled by the patient, and possibly includes importation of clinical data from other sources. Often created online, it is accessible by providers when the patient invites providers to review information in the PHR using secure access.

Clinical applications support patient care wherever it is being delivered. The most apparent clinical application is the EHR. In some institutions, this is a one-vendor application; in others, it is a best of breed, with many different vendor applications performing different functions. The EHR is used by clinicians to document patient care, from medication administration to order entry, as well as to retrieve patient data from the lab or from radiology. The provider's office can send electronic prescriptions to the patient's pharmacy, as well as import and export data from an inpatient stay or outpatient testing from a health information exchange (HIE) system.

EHR systems can also execute algorithms for stratifying various clinical and operational activities. The data points that drive these prediction models can range from vital signs, lab results, to the number of no shows for outpatient visits. Enterprise EHR's can also include population health capabilities, clinical specialty modules and integration with outside regulatory and public health systems. The list of capabilities keeps growing as these systems mature.

The EHR interfaces with specialized systems in different departments. As an example, in the United States, radiology and pathology labs have specific requirements, with formatting and data display governed by different accrediting agencies, such as Clinical Laboratory Improvement Amendments (CLIA), the College of American Pathologists (CAP) and the American College of Radiology.4,5 In Europe, the European Cooperation for Accreditation6 covers laboratory certifications. Professional dietitians, case managers and social workers all have specific needs in software functionality, often dictated by professional or regulatory standards.

Some clinical areas, such as the perinatal areas (labor and delivery, nursery, neonatal intensive care and postpartum), the perioperative areas (preoperative unit, operating rooms and post anesthesia care unit), the critical care units, the outpatient centers for primary care and special functions like renal dialysis, have specialized documentation and information needs. The picture archiving and communication system (PACS) stores and displays images from ultrasounds to computed tomography (CT) scans and magnetic resonance imaging (MRIs). These systems require fine-resolution monitors, large storage drives, good bandwidth and large amounts of random access memory (RAM) for image display. Some of the major EHR vendors are able to support all the specialty areas; others do not and require the purchase and interface of a niche system specific to each specialty. The goal of all these systems is to communicate and exchange this patient health information, also known as interoperability. Interoperability is one of the most important attributes of clinical systems, since data should not be entered into systems more than one time. It is essential that these systems exchange data with each other.

The availability of clinical data at the point of care has transformed how clinicians care for patients. They no longer need to go to the radiology department to look at MRIs or CT scans; those images can now be made available in the EHR application, saving time for clinicians, as well as money for the institution, since there are no films to create, store, or retrieve. Perinatal systems archive the fetal monitor strips electronically, saving thousands of dollars in charges for storage of paper fetal strips.

Chapter 2 · Technology Environment · Lesson 3 of 9

Administrative and Financial Applications

Big picture

This section covers the software that keeps the institution running and gets it paid. It follows clinical applications in the chapter and pairs with the payer material from Chapter 1, because the billing rules described there are what these systems have to execute. The larger problem it solves is that healthcare finance carries more variables than most industries, so a general ledger package is not sufficient on its own. Administrative and financial are the adjacent pair here: scheduling staff is administrative, charge posting is financial, and both touch the same time and attendance data.

Walkthrough

Administrative applications

Administrative applications support clinicians as well as administrative staff.
They run from electronic time cards, intranet, payroll, staff competency record keeping and educational applications to scheduling.
Scheduling covers both staff for work shifts and patients for procedures and office visits.
Bed management systems include housekeeping and patient transportation staff as well as clinicians, and help get patients into a room as soon as possible.
Equipment-tracking applications using radio frequency identification save staff time otherwise spent hunting for equipment.
Web-based applications that let staff bid for understaffed shifts reduce overtime labor costs and increase staff satisfaction, as do self-scheduling systems.

Question:

Name the administrative applications the source lists and say which of them involve non-clinical departments.
What two results does the source attribute to shift bidding and self-scheduling?

Financial applications and practice management

Financial applications cover all the features of any organization's financial needs, with more variables than most businesses.
Multiple regulations govern how billing is done, how bills are submitted and what details must accompany a bill, such as diagnosis codes and providers' licenses and billing numbers.
Systems must handle charge posting through both orders and manual charge entry, payment posting and billing based on the providers.
Insurance, coinsurance and deductibles enter the calculations, as do revenue codes, supplies, tests and medications.
Items requiring a provider's order that cannot be billed without one must be distinguished from items that do not require an order.
Statements go to patients and claims go to insurance companies.
These billing systems are commonly referred to as practice management systems.

The order requirement distinction is a billing rule enforced in software. If the system cannot tell the two item types apart, the organization bills for something it may not bill for.

Question:

Why does the source call healthcare financial systems more complex than those of most industries?
What is the common name for these billing systems, and what must they distinguish about billable items?

General ledger, payroll and supply chain

A general ledger must accurately track charges, bills and payments.
Payroll must accept data from the electronic time card system and convert it to salary costs.
It must correctly match regular and overtime hours worked and calculate overtime pay, holiday bonuses, shift differentials and additional wages earned from professional certifications.
Payroll also tracks earnings for paid time off, usually based on hours worked.
Accounts payable must stay in sync with all other systems, and financial systems have to communicate in real time.
The supply chain function must include all methods of supply purchasing and invoice payment, correctly linked.

Example

A nurse works a night shift on a holiday and holds a certification premium. Payroll has to read the time card feed and apply three different rules to the same shift, which is why the interface between time and attendance and payroll is treated as a financial system requirement.

Question:

List what payroll must calculate from the time card feed.
What does the source require of accounts payable in relation to the other financial systems?

Memory tips

Split rule: staff and patient logistics are administrative, money movement is financial. Scheduling is administrative even though it drives revenue.
Payroll five: regular and overtime hours, overtime pay, holiday bonuses, shift differentials, certification wages, plus paid time off accrual from hours worked.
Billing systems are practice management systems. One name to attach to the whole billing stack.

Key concepts

Administrative applications: software supporting clinicians and administrative staff, including time cards, intranet, payroll, competency records, education, staff and patient scheduling, bed management and RFID equipment tracking
Bed management system: an application spanning housekeeping, transportation and clinical staff to place patients in rooms quickly
Financial applications: systems handling charge and payment posting, provider-based billing, insurance, coinsurance and deductibles, revenue codes, supplies, tests and medications
Practice management system: the common name for healthcare billing systems
General ledger: the system that accurately tracks charges, bills and payments
Payroll system: the system converting time card data into salary cost, including overtime, differentials, bonuses, certification pay and paid time off

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: scope of administrative applications · scheduling of staff and patients · bed management participants · RFID equipment tracking · shift bidding and self-scheduling effects · regulatory complexity of billing · charge and payment posting mechanics · order-required versus non-order billing distinction · statements and claims · practice management naming · general ledger duties · payroll calculation elements · accounts payable synchronization and real-time communication · supply chain purchasing and invoice linkage.

Read the original source

Administrative Applications

Administrative applications provide support for clinicians, as well as the administrative staff in an institution. These applications run the gamut from electronic time cards, intranet, payroll, staff competency record keeping and educational applications, to scheduling both staff for work shifts and patients for procedures and office visits. Bed management systems, which include staff from housekeeping and patient transportation, as well as clinicians, are very helpful in getting patients into a room as soon as possible. Popular applications in the last few years include equipment-tracking applications that use radio frequency identification (RFID) technology, thus saving staff time spent in hunting for needed equipment. Web-based applications that permit staff to bid for understaffed shifts are being implemented, reducing overtime labor costs and increasing staff satisfaction, as do systems that permit self-scheduling.

Financial Applications

Financial applications in healthcare IT cover all the features of any organization's financial needs, but possibly with more variables than most businesses have to entertain. From the solo provider's office to the multihospital, multi-provider health system, there is a need for financial systems. Multiple regulations govern how billing can be done, how bills are submitted and the details that have to be included with a bill, such as diagnosis codes and providers’ licenses and billing numbers—the list is incredibly long. Systems have to handle charge posting via both orders and manual charge entry, payment posting and billing based on the providers. Insurance, coinsurance and deductibles have to be part of the calculations, as do revenue codes, supplies, tests and medications. Items that require a provider's order and cannot be billed to patients without an order must be distinguished from items that do not require an order and can be billed to patients. Statements need to be provided to patients and claims to insurance companies. These billing systems are commonly referred to as practice management systems.

A general ledger must accurately track charges, bills and payments. Payroll systems need to accept data from the electronic time card system and convert it to salary costs, correctly matching hours worked, both regular and overtime, and calculate any overtime pay, holiday bonuses, shift differentials, or additional wages earned from professional certifications. It also has to track earnings for paid time off, usually based on the number of hours worked by the employee. The accounts payable portion of the software must also be in sync with all the other systems; financial systems have to communicate in real time. The supply chain mission and support has to include all methods of supply purchasing, as well as invoice payment, and ensure that they are linked correctly.

Chapter 2 · Technology Environment · Lesson 4 of 9

Consumer Applications

Big picture

This section covers what patients themselves use: portals, personal health records and secure messaging. It follows the administrative and financial groups and connects back to the always-on patient expectations described in Chapter 1. The larger problem it solves is that the record is now understood to belong to the patient, which turns access and portability into design requirements rather than courtesies. The pair to keep apart is the portal and the standalone PHR: one is a view into the organization's EHR, the other is patient owned and may not be connected to any institution.

Walkthrough

Portals and patient ownership of the record

Consumers are increasingly involved in electronic records and their own health information.
Patients not infrequently request electronic versions of their charts from providers.
The question of who owns the medical record appears to have been decided in the patient's favor.
Most EHRs have a patient portal that lets patients view test results and clinical notes, request prescription refills, send secure e-mail to the provider or office staff and schedule appointments.
Some portals permit patients to add comments or request amendments to their EHR.

Question:

List the portal functions the source names.
What position does the source take on ownership of the medical record?

Personal health records

Some PHRs are standalone and not connected with an institution's EHR.
They may be web based, installed on the user's computer, or a mobile app.
CMS encourages PHR use and links to Blue Button, a PHR initiative that originated through the Veteran's Administration and is now offered through other organizations' patient portals.
The National Committee on Vital and Health Statistics provides detailed information on PHR advantages.
Web-based PHRs give the patient full control of the record's contents and often allow import of prescription medication history from national drug store chains or results from laboratories.
Some healthcare organizations have partnered with web-based PHR vendors and uploaded records into patients' PHR applications.
Some healthcare insurers allow PHR creation from their websites.
A California Health Care Foundation national survey provides evidence that PHRs support patients in improving their own health.
Caregivers in that survey noted PHRs were almost a necessity for maintaining knowledge and continuity of care for family members with multiple chronic conditions.
Most patients want to use PHRs that their physician or insurer provides.
The survey identified security as the major stumbling block to PHR adoption, with patients looking for evidence that entered information is completely secure.
Most sites explain how privacy and security are maintained and let patients decide who may view information, often through a secure URL or a separate login and password for the provider.
Patients who established a PHR through an insurer or third party have found information could not be easily transferred to a different PHR, forcing reentry of data.
PHR use has increased with medical home and accountable care platforms, which incentivize keeping patients healthy.
In-home health monitoring systems and wearable devices have intensified the need for PHRs.

The NHS Summary Care Record

The SCR is an electronic summary of key clinical information including medicines, allergies and adverse reactions, sourced from the general practitioner record.
Authorized healthcare professionals use it with the patient's consent to support care and treatment.
Registration with a GP practice in England creates an SCR automatically unless the patient has opted out, and 98 percent of practices now use the system.
The SCR is uploaded to the Spine, a set of national services used by the NHS Care Record Service.
The Personal Demographics Service stores demographic information and the NHS number, and patients cannot opt out of it.
The Secondary Uses Service uses record data to provide anonymized and pseudonymised business reports and statistics for research, planning and public health delivery.

Question:

What did the CHCF survey identify as the main barrier to PHR adoption, and what do patients want in response?
Describe the Summary Care Record, its consent model and the two other Spine services named.
Why does the source mention difficulty transferring PHR data between vendors?

Secure messaging and record access

Patients are very interested in communicating electronically with their providers.
Doctors are described as far behind the rest of the world in using electronic communication.
Patient portals or secure messaging applications can provide the needed security.
Most patient issues can be addressed by office staff in e-mail, leaving only a few for the physician or nurse practitioner.
Both sides of the communication have to be secure, and web-based and application-driven tools can supply security and convenience where providers lack the skill to build it.
Providing human-readable medical records in electronic format is new to healthcare.
In the past, patients went to health information management, completed paperwork and often paid a per-page fee for a paper copy.
Stage 1 of CMS Meaningful Use requires a copy of the medical record be available to the patient within 24 hours of request.
Delivery may be by flash drive or pushed through an existing patient portal.
Regardless of regulation, informed patients want copies of their records.

Question:

Who handles most secure message traffic, according to the source?
State the Meaningful Use Stage 1 record access requirement and contrast it with the former paper process.

Memory tips

Portal versus standalone PHR: the portal is a window into the organization's EHR; the standalone PHR is patient owned and may connect to nothing.
Blue Button origin: Veteran's Administration, encouraged by CMS, now offered through other portals.
CHCF survey headline: security is the barrier, and patients prefer a PHR from their physician or insurer.
SCR numbers: 98 percent of English GP practices, automatic unless opted out; the PDS is the one patients cannot opt out of.
Meaningful Use Stage 1 access clock: 24 hours from request.

Key concepts

Patient portal: an EHR feature letting patients view results and notes, request refills, message the practice, schedule visits and in some cases comment or request amendments
Standalone PHR: a patient-controlled record not connected to an institution's EHR, delivered by web, installed software or mobile app
Blue Button: the PHR initiative originating with the Veteran's Administration and encouraged by CMS, now offered through other patient portals
CHCF survey findings: evidence that PHRs help patients improve their health, that patients prefer physician or insurer supplied PHRs, and that security is the major adoption barrier
Summary Care Record: the NHS electronic summary of medicines, allergies and adverse reactions from the GP record, used with patient consent and uploaded to the Spine
Spine services: the national NHS services including the Personal Demographics Service, with no patient opt out, and the Secondary Uses Service for anonymized reporting
Secure messaging: portal or application-based electronic communication between patients and practices, most of which is handled by office staff
Human-readable record access: the requirement, including CMS Meaningful Use Stage 1, that a copy of the record be available to the patient within 24 hours of request

Practice questions

5 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: consumer involvement and chart requests · record ownership decided in the patient's favor · portal functions including amendment requests · standalone PHR forms · CMS encouragement and Blue Button origin · NCVHS information · web PHR control and data import · organization and insurer PHR partnerships · CHCF survey evidence, caregiver finding, preference and the security barrier · viewing controls · PHR portability difficulty · medical home and ACO effect · monitoring and wearable drivers · SCR content, consent, opt out and 98 percent figure · Spine, PDS and SUS · secure messaging volume and security requirement · human-readable access and the Meaningful Use 24-hour rule.

Read the original source

Consumer Applications

Consumers are becoming more and more involved in electronic records and their patient health information. Not infrequently, patients request electronic versions of their charts from providers. The importance of the consumer's relationship to the record and the information in that record is more apparent. While there used to be discussions about who owned the medical record, this seems to have been decided in the patient's favor. Most EHRs have a patient portal that permits the patient to view test results and clinical notes, ask for prescription refills and send the provider or the office staff a secure e-mail, as well as schedule an appointment. Some portals permit patients to add comments or request amendments to their EHR.7,8

Some PHRs are stand-alone and are not connected with an institution's EHR. These applications may be web based, or an application installed on the user's computer or mobile app. In the United States, the Centers for Medicare & Medicaid Services (CMS) encourages the use of PHRs9,10 and provides a link to Blue Button®, a PHR initiative which originated through the Veteran's Administration and is now being offered through other healthcare organization patient portals. The National Committee on Vital and Health Statistics also provides detailed information on the advantages of a PHR.10 Convenient guides are helpful to patients around the world.11 Web-based PHRs give the patient full control of the record's contents, and often offer the opportunity to import prescription medication history from national drug store chains or results from laboratories. According to Gherardi et al., PHRs are becoming very popular in Europe, the United Kingdom and Scandinavia.12 Vendors are increasing their promotion about the PHR across Europe, the United Kingdom and China.13

Some healthcare organizations have partnered with web-based PHR vendors and uploaded records into patients’ PHR applications from those healthcare institutions. Some healthcare insurers also provide the ability to create a PHR from their websites.14 In the United States, a national survey conducted by the California Health Care Foundation (CHCF) provides evidence that PHRs actually support patients in improving their own health.15 According to the survey, caregivers did note that PHRs were almost a necessity in maintaining knowledge and continuity of care for family members with multiple chronic conditions.

The numbers of patients using PHRs is growing rapidly, with the CHCF survey reporting that most patients want to use PHRs that their physician or insurer provides. The survey also identified security as the major stumbling block to PHR adoption, with patients looking for evidence that any information they enter into the PHR is completely secure. Most websites clearly provide information on how security and privacy of the patients’ records is maintained. Most allow the patients to decide who can view their information, often by providing a secure URL or separate login and password for the healthcare provider. Patients have found that after establishing a PHR through their insurance company or other third-party vendor, information could not be easily transferred to a different PHR, resulting in the patients having to reenter the data in their new systems. PHR use has increased with the medical home and accountable care platforms, as they provide incentives for keeping patients healthy.16 In addition, the use of in-home health monitoring systems and wearable devices has also intensified the need for PHRs. In the United Kingdom, the NHS Summary Care Record (SCR) is an electronic summary of key clinical information (including medicines, allergies and adverse reactions) about a patient, sourced from the general practitioner (GP) record. It is used by authorized healthcare professionals, with the patient's consent, to support their care and treatment. If you are registered with a GP practice in England, your SCR is created automatically, unless you have opted out. 98% of practices are now using the system. The SCR is created automatically through clinical systems in GP practices and uploaded to the Spine. The Spine is a set of national services used by the NHS Care Record Service. In addition to the SCR, these include: The Personal Demographics Service (PDS), which stores demographic information about each patient and their NHS number. Patients cannot opt-out from this component of the spine and the secondary uses service (SUS), which uses data from patient records to provide anonymized and pseudonymised business reports and statistics for research, planning and public health delivery.17

Patients are also very interested in communicating electronically with their providers. According to the Wall Street Journal,18 doctors are far behind the rest of the world in using electronic communications, and either patient portals or secure messaging applications can provide security for this increasingly popular communication. Most patient issues can actually be addressed in e-mail by office staff, leaving only a few e-mails that the physician or nurse practitioner needs to address. Patients want the convenience of electronic communication with their providers, but at the same time, both sides of the communication have to be secure. While providers may not have the skill to set up secure communications, there are web-based and application-driven tools that will provide both security and convenience.

The requirement to be able to provide “human-readable” medical records in electronic format is something very new to healthcare. In the past, patients had to go to the health information management department, complete paperwork to request their own records and often pay a per-page fee for a copy of the paper record. As an example, in the United States, Stage 1 of the CMS Meaningful Use requires that a copy of the medical record be available to the patient within 24 hours of the request.19 While it is not always easy to retrieve data from EHR systems, this requirement has to be fulfilled. Ensuring the EHR can provide this information, whether on a flash drive, or pushed out through an existing patient portal, is essential. In addition, regardless of the regulations, informed patients want copies of their records. Patients want to see their records, as determined by a group of researchers in the United States and Canada.20

Chapter 2 · Technology Environment · Lesson 5 of 9

Clinical Business Intelligence and Analytics

Big picture

This short section defines clinical and business intelligence and states what organizations use it for. It closes the software half of the chapter and sets up the data warehouse material later in the chapter and the analytics chapter that follows. The larger problem it solves is proving quality and cost performance, which cannot be asserted without data and analysis. The definition is the examinable object here, so it is worth holding its four verbs rather than paraphrasing it.

Walkthrough

The HIMSS CBI definition and its uses

The HIMSS Clinical and Business Intelligence Committee defines CBI as technologies, applications and practices for the collection, integration, analysis and presentation of clinical information.
The stated purpose of CBI is better clinical decision-making.
Quality in healthcare is described as being shaped by evidence-based medicine and proper utilization of data.
CBI tools support clinicians in improving patient safety and patient care.
They also analyze operating room use and staff overtime patterns.
Collecting and reporting data meaningfully supports direct patient care and all aspects of healthcare, including predictive analytics.
Hospitals and providers both want to show they deliver high-quality, low-cost care, and data analysis is the only key to showing it.
Organizations implement CBI through specific applications or by constructing data warehouses.
They use it to document care delivered, show trends in patient conditions and document improvements in patient status and population health outcomes.

Example

An operating room running late every Tuesday is an operational question and a CBI question at once. The same collection, integration, analysis and presentation chain that flags a rising infection rate flags the block schedule.

Question:

Give the HIMSS CBI definition, including its four activities and its stated purpose.
Name the two implementation routes the source gives for CBI and the uses it lists.

Memory tips

CBI four activities: collection, integration, analysis, presentation. Read as C-I-A-P, in that order, ending with presentation because an unseen analysis changes nothing.
Definition owner: the HIMSS Clinical and Business Intelligence Committee. Attribute the definition, since the exam pairs definitions with the wrong bodies.
Two routes to CBI: buy specific applications or build a data warehouse.

Key concepts

Clinical and business intelligence: technologies, applications and practices for the collection, integration, analysis and presentation of clinical information for better clinical decision-making, as defined by the HIMSS CBI Committee
CBI uses: patient safety and care improvement, operating room utilization and overtime analysis, predictive analytics, quality and cost demonstration, and population health outcome documentation

Practice questions

2 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

1 Technologies and practices for collecting, integrating, analyzing and presenting clinical information for better decision-making are calledCanonical

Aclinical and business intelligenceBclinical decision supportCcomputerized provider order entryDclinical documentation improvement

2 The HIMSS CBI Committee defines clinical and business intelligence as technologies and practices forStress

Ascheduling staff shifts and patient appointments across sitesBcollecting, integrating, analyzing and presenting clinical informationCencrypting protected health information at rest and in transitDtransmitting claims and remittances between providers and payers

Source fidelity

Covered from the source: the HIMSS CBI definition and its purpose clause · evidence-based medicine and data utilization shaping quality · clinical and operational uses of CBI tools · predictive analytics · the demonstration of high-quality, low-cost care · implementation through applications or data warehouses · documentation of trends, patient status and population health outcomes.

Read the original source

Clinical Business Intelligence (CBI) and Analytics

According to the HIMSS Clinical and Business Intelligence (CBI) Committee, CBI consists of “technologies, applications and practices for the collection, integration, analysis and presentation of clinical information, for the purpose of better clinical decision-making. In recent times, quality in healthcare is being shaped by evidence-based medicine and the proper utilization of data.”21 Tools of clinical and business intelligence can provide support to clinicians to improve patient safety and patient care, as well as analyzing operating room use and staff overtime patterns. Collecting—and reporting in a meaningful way—supports not only direct patient care, but also all aspects of healthcare, including predictive analytics. Hospitals want to show that they are providing high-quality, low-cost care for their patients; providers want to show that they are doing the same. Data and data analysis are the only keys to providing that information. More and more organizations around the world are implementing clinical and business intelligence, whether by using specific applications or by constructing data warehouses, to document the care they provide, as well as to show trends in patients’ conditions and document improvements in patients’ status and population health outcomes based on the care that they were given.

Chapter 2 · Technology Environment · Lesson 6 of 9

Hardware: Infrastructure, Servers, Storage and Devices

Big picture

This section covers what runs and captures the data: infrastructure, servers, storage, mobile devices and medical devices. It opens the hardware half of the chapter and connects to the privacy and security material at the end, since most of the risks named here are access risks. The larger problem it solves is that clinical work is mobile while data obligations are long-lived, so hardware has to serve the bedside and the retention schedule at once. Mobile devices and medical devices are the pair to keep distinct: one is a way to reach the record, the other is a source of data flowing into it.

Walkthrough

Technology infrastructure and servers

Hardware systems store data, run applications and connect applications and tools together.
Physical routers, switches and virtual and physical servers connect clinicians, administrators, providers and patients to clinical systems, information and support.
Firewalls, both physical and software based, along with virus scanning systems, protect the network from unauthorized access and maintain information security.
Most healthcare IT departments run virtual, physical and cloud servers.
Which type of server an application is installed on is determined by the vendor's recommendations and by the organization's capability to support the technology.
Servers are among the most expensive equipment in a healthcare IT shop and must be managed well.
Cloud computing offers cost-effective options for organizations lacking the space, resources or desire to house and maintain data in-house.

Question:

What two factors decide which server type an application goes on?
Why does the source present cloud computing as an alternative rather than an upgrade?

Data storage and retention

Regulations set how long patient data must be maintained, depending on the type of patient.
Many healthcare organizations are resigned to keeping charts forever.
With paper records, permanent retention means large sums spent storing paper that will probably never be read again.
Organizations historically stored paper charts off-site and ordered them when needed, adding transportation costs.
Some health systems scan paper charts and then appropriately dispose of the paper.
EHRs have reduced or eliminated the need for paper chart storage.
Current practice for storing, backing up and archiving data is changing, often to the cloud.
The cloud can provide room for storage even when needs double every few years.

Question:

Explain why retention regulation becomes a storage strategy question.
What sequence of storage practices does the source describe, from off-site paper to current practice?

Mobile devices and BYOD

Hardware must be designed to support clinical workflow, which increasingly means portable devices and wireless connectivity.
Institutions use workstations on wheels with wireless access as well as smaller handheld devices.
Workstations can be configured with drawers for storage, holders for barcode medication scanners and locked drawers for medication security.
Other workstations are designed for outpatient clinics with no need for drawers or scanners, and some carry mounted medical devices.
Standardization may be a goal, but one documentation device will likely not meet every area or end user need.
Smartphone popularity and functionality prompt end users to ask for similar devices in healthcare units.
Most EHR vendors have updated their applications for handheld devices.
Touchscreen devices are being configured for healthcare with attention to infection control when equipment is touched by gloved hands.
Devices such as MRI scanners use touchscreens to program examinations and review images.
Security is a major concern with any handheld device connecting to the institution's network, especially when users bring their own.
Before permitting personal device use in clinical areas, establish a policy ensuring protected health information is safe, that the institution can wipe a compromised device and that passwords are required.
Permitting data storage on a personal device must depend on maintaining the data's security.

Example

Two units, two carts: a medication-administration cart needs locked drawers and a scanner holder, while a clinic exam room cart needs neither. The source treats that mismatch as expected, not as a failure of standardization.

Question:

List the three policy elements the source requires before permitting personal devices in clinical areas.
Why does the source caution against a single standard documentation device?

Medical devices and their regulation

Physiologic devices such as cardiac monitors, ventilators, some IV fluid pumps, medication pumps and vital sign monitors can send out the data they obtain, often in HL7 format.
Integration with the EHR decreases data entry and transcription errors and saves time.
Data may go directly to preconfigured fields, or a third-party device may translate it into EHR-acceptable format.
Clinician validation of the information is required before data is permanently stored in the EHR.
Laboratory devices conduct tests and export information to the EHR.
Radiologic images are typically stored in a PACS and viewed through a link from the EHR to the image in PACS or the enterprise imaging system.
In the United States the Food and Drug Administration regulates medical devices, so IT must know the FDA laws and regulations applying to IT-supported hardware and software.
FDA coverage includes displays of physiologic data such as heart rhythms, fetal monitor tracings, ventilator or heart waveforms, and implantable devices such as automatic cardiac defibrillators.
The FDA also regulates mobile medical apps, such as those displaying fetal heart tracings or cardiac waveforms on physicians' cell phones.
The biomedical engineering department must work closely with IT to maintain these systems.
In Europe, the Parliament and the Council of the European Union have developed directives for medical devices and in vitro diagnostics.
Canada and Japan have medical device regulations, and in Russia the Ministry of Public Health and Social Development controls medical devices.
The WHO reports that 65 percent of 145 countries have an authority responsible for implementing and enforcing medical device specific product information.

Validation before permanent storage is the clinical safeguard on device integration. Automated capture removes transcription error, not the need for a human to confirm the value belongs to this patient at this time.

Question:

Trace device data from a cardiac monitor into the EHR, naming the format and the required safeguard.
What categories of display and device does the FDA cover, and who partners with IT to maintain them?
Give the WHO figure on national medical device authorities.

Memory tips

Server types three: virtual, physical, cloud. Placement decided by vendor recommendation plus organizational capability.
BYOD policy three: protect PHI, ability to wipe the device, required passwords. Data storage on the device is conditional on security.
Device data format is HL7; the safeguard is clinician validation before permanent storage.
Regulator by region: FDA in the United States including mobile medical apps, EU directives for devices and in vitro diagnostics, national regulations in Canada and Japan, the health ministry in Russia.
WHO number anchor: 65 percent of 145 countries have a medical device information authority.

Key concepts

Technology infrastructure: the routers, switches, virtual and physical servers, firewalls and virus scanning that connect users to systems and protect the network
Server types: virtual, physical and cloud servers, assigned by vendor recommendation and organizational support capability
Cloud storage: an option for storage, backup and archiving where organizations lack space, resources or desire to maintain data in-house
Workstation on wheels: a configurable mobile documentation station, optionally carrying storage drawers, scanner holders, locked medication drawers or mounted devices
BYOD policy: the requirement to protect PHI, retain the ability to wipe a compromised device and require passwords before personal devices are used clinically
Medical device integration: transmission of physiologic device data, often in HL7 format, into the EHR, with clinician validation required before permanent storage
FDA device regulation: U.S. regulation covering medical devices, physiologic data displays, implantable devices and mobile medical apps

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: hardware's role and the named infrastructure components · firewalls and virus scanning · three server types and placement criteria · server cost and cloud alternatives · retention regulation and permanent chart keeping · off-site paper storage, scanning and EHR effect · cloud-based storage growth · workflow-driven mobile hardware · WOW configurations and area differences · handheld and touchscreen adoption and infection control · BYOD risk and the three policy elements · physiologic device data in HL7 and the validation requirement · lab device export and PACS viewing · FDA scope including mobile medical apps · biomedical engineering partnership · EU, Canadian, Japanese and Russian regulation · the WHO 65 percent figure.

Read the original source

Hardware in Healthcare IT

Technology Infrastructure

The basis of any technology has to be the hardware systems that store data, run applications and connect those applications and tools together. The physical routers, switches and virtual and physical servers are some of the integral parts needed to connect clinicians, administrators, providers and patients to essential clinical systems, information and support. Firewalls, both physical and software based, along with virus scanning systems, protect the network from unauthorized access as well as maintain security of the information in the system.

Servers

While the vision that many people have of IT is a data center full of servers, this is no longer completely accurate. Most healthcare IT departments have virtual, physical and cloud servers. What application is installed on which type of server is determined by the vendors’ recommendations, as well as the capabilities of the organization to support this technology. Servers are part of the most expensive equipment in a healthcare IT shop and must be managed well and appropriately. Cloud computing provides alternative cost-effective options for those organizations that may not have the appropriate space, resources, or desire to house and maintain their data in-house.

Data Storage

There are, depending on the type of patient, regulations on how long patient data must be maintained. Many healthcare organizations are simply resigned to keeping charts forever.

With paper records, that translates to a large amount of money to store stacks of paper that will probably never be looked at again. Health information management departments have looked for a less expensive and more reliable storage method. Historically, most organizations were forced to store paper charts off-site and have to order them when or if they are needed, thus adding transportation costs to and from the storage area to the record-keeping costs. Some health systems have a practice of scanning paper charts, and then appropriately disposing the paper chart. EHRs have reduced or eliminated the need for paper chart storage. Current practice, where data is stored, backed up and archived, is changing—often to the cloud. The cloud can provide room for storage, even when those storage needs may double every few years.

Mobile Devices

Hardware needs to be designed to support clinical workflow, and increasingly that means portable devices and wireless connectivity. Healthcare institutions are using workstations on wheels (WOWs) with wireless access, as well as smaller handheld devices. These workstations can be configured to meet end users’ needs, from drawers for storage to holders for barcode medication scanners and locked drawers for security of medications. Workstations can also be designed for outpatient clinics and other clinical areas that have no need for drawers or scanners, while other workstations can have medical devices mounted on them. It is important to remember that while standardization may be a goal, one documentation device will likely not meet every area or end user needs.

The popularity of smartphones, and their increased functionality, is prompting end users to ask for similar devices for use in healthcare units. Smartphones are one of the most popular handheld devices. Most EHR vendors have updated their applications for use on handheld devices. Devices with touchscreens are being configured for healthcare, with attention to the concern about maintaining good infection control practices while using equipment that is touched by gloved hands. Several devices, such as MRI scanners, employ touchscreens to program the examinations and review the images.

A major concern with any handheld device that connects to the institution's network is security, especially when end users actually bring their own devices (BYOD) to work. Prior to permitting staff's use of their personal devices in the clinical areas, it is important to establish a policy to ensure that protected health information (PHI) is safe, that the institution can wipe a device clean if it is compromised and that passwords are required to access the device. The decision to permit data storage on a personal device must be dependent on maintenance of the data's security.22,23

Medical Devices

Many physiologic devices, such cardiac monitors, ventilators, some IV fluid pumps, medication pumps and vital sign monitors, have the ability to send out the data they obtain, often in Health Level Seven (HL7®) format. This integration with the EHR helps staff by decreasing data entry and transcription errors, as well as saving time. Depending on the EHR, this data could be sent directly to preconfigured fields, or a third-party device can be used to translate the data into EHR-acceptable format. It is important to require validation of the information by the clinician prior to permanently storing data in the EHR.

Laboratory devices can conduct tests and export the information to the EHR. Typically, radiologic images are stored in a PACS and viewed via a link from the EHR to the image in PACS or enterprise imaging system. Both areas have specific regulatory agencies that supervise the use of those devices and regulate them. As an example, in the United States, the Food and Drug Administration (FDA) regulates medical devices. Since so many of those devices have incorporated advanced technology, IT must be aware of the laws and regulations from the FDA that apply to hardware and software that is IT supported. In addition to radiologic images, any display of physiologic data, such as heart rhythms, fetal monitor tracings, ventilator or heart waveforms and any implantable device, such as an automatic cardiac defibrillator, are covered by the FDA. In addition, the FDA regulates mobile medical apps. Examples of these are applications that display fetal heart tracings or cardiac waveforms on physicians’ cell phones.24 The institution's biomedical engineering department must work closely with IT to maintain these important systems.

In Europe, the Parliament and the Council of the European Union have developed directives for medical devices and in vitro diagnostics. Canada has medical device regulations, as does Japan.25 In Russia, the Ministry of Public Health and Social Development of the Russian Federation control medical devices.26 The World Health Organization (WHO) has published a large amount of information about medical device requirements on its web page.27 According to the WHO, “65% of 145 countries have an authority responsible for implementing and enforcing medical device specific product information.”28 There is discussion that the European Commission's regulations for devices are not strong enough to really protect patients.

Chapter 2 · Technology Environment · Lesson 7 of 9

Networks and Communications

Big picture

This section covers the connections themselves, wired and wireless, and the communication devices that ride on them. It is the third component of the technology environment and the one clinicians notice only when it fails. The larger problem it solves is placing information at the point of care, which is a network question before it is an application question. Wired and wireless are the pair here: wireless supports the bedside workflow, while cabled access is described as more reliable and faster.

Walkthrough

Network infrastructure

The network remains dependent on cables while increasingly connected using wireless access points.
Putting information at the point of care requires wireless access points rather than physical wires.
Clinicians do not accept walking from the patient's room back to the nurse's station to log in and retrieve results.
Providers can take the electronic chart into the room and review lab results, x-ray reports and other tests with the patient.
Virtual private networks and voice over Internet protocol use fiber-optic and coaxial cables and supporting protocols governing router and switch connections.
Local area networks use Ethernet and token ring; wide area networks use multiprotocol label switching or asynchronous transfer mode.
VPN technology is a safer, more secure method of providing remote access to an organization's network and servers.
VPNs use tunneling protocols and encryption and require authentication to block unauthorized users.
Regulatory bodies, professional organizations and standards require documentation about patients, the care given and procedures performed.
A major EHR requirement is supporting the documentation, order entry and lab results reporting that regulations, professional standards and patient need demand.
Care documented when and where it is provided reduces errors.
Cabled access to the intranet and Internet is more reliable and faster.
Many institutions already have cable installed from before wireless met their price and speed requirements.
Clinical, administrative and support departments usually have hardwired desktop computers, and some outpatient settings install a fixed device in each exam room.
Radiology examination rooms need larger, high-resolution monitors and high-speed graphic cards supporting detailed images.
Hardware in patient care areas has to be cleaned with appropriate cleansing agents.

Question:

Contrast cabled and wireless access using the source's own attributes for each.
Explain what a VPN provides and the three mechanisms it uses.
Name the LAN and WAN technologies the source lists.

Communications

Healthcare IT uses many data communication protocols and media, from standard telephone landlines with conferencing and video capability to devices using VoIP and broadband access.
Data communication protocols allow information to transmit from one point or medium to another, the telephone being the most common example.
Some devices look like ordinary cell phones, while others are clip-on, hands-free phones worn by staff.
Infection control is a major concern, so device materials need to be antibacterial and cleanable.
Some devices send and receive text messages, but there are concerns about the security of text messages for patient orders, and not all providers want to use them for orders.
Bifurcated workflows of that kind can result in missed patient care.
Other communication protocol examples include broadband access, Ethernet and Wi-Fi for transmitting data across networks or accessing the Internet.

The warning about bifurcated workflow is the point worth carrying. A second, informal channel for orders means the record no longer holds the whole story.

Question:

Why does the source caution against text messaging for patient orders?
Give the source's examples of communication protocols and media in use.

Memory tips

Access trade-off: wireless buys the bedside, cable buys reliability and speed. Both remain in use.
VPN triad: tunneling protocols, encryption, authentication. Purpose is secure remote access.
Network scope: LAN uses Ethernet and token ring; WAN uses MPLS or ATM.
Order channel rule: text messaging for orders raises security concerns and splits the workflow, and split workflows cause missed care.

Key concepts

Wireless access points: the network elements that place information at the point of care and support chart review in the patient's room
Cabled access: intranet and Internet connection described as more reliable and faster, widely installed before wireless became affordable
Virtual private network: a safer method of remote access to the organization's network and servers using tunneling protocols, encryption and authentication
LAN and WAN technologies: Ethernet and token ring for local area networks, multiprotocol label switching and asynchronous transfer mode for wide area networks
Data communication protocols: the means allowing information to transmit between points or media, including landline telephony, VoIP, broadband, Ethernet and Wi-Fi
Bifurcated workflow: the split that results when some communication, such as texted orders, happens outside the intended channel, risking missed patient care

Practice questions

2 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

1 Cabled network access is characterized asStress

Aspecifically required for compliance under HIPAA regulationsBobsolete in clinical settingsCslower but cheaper than wirelessDmore reliable and faster than wireless

2 Voice over IP (VoIP) is an example ofStress

Aa data communication protocol/mediumBa storage architectureCa financial transaction setDa clinical terminology

Source fidelity

Covered from the source: cable and wireless coexistence · point-of-care requirement for wireless · clinician workflow expectation · VPN and VoIP media and protocols · LAN and WAN technologies · VPN security mechanisms · documentation requirements imposed on the EHR · documentation at point of care reducing errors · cabled access reliability and legacy installation · department and exam room hardwiring · radiology display requirements · cleaning of patient area hardware · communication protocols and device types · infection control on communication devices · texting concerns and bifurcated workflow risk.

Read the original source

Networks in Healthcare IT

Network Infrastructure

The network, while still dependent on network cables, is increasingly connected using wireless points. Putting the information for clinicians at the point of care requires wireless access points, not hard or physical wires. Clinicians want data at their fingertips and do not accept the model of going to the patient's room and then back to the nurse's station to log in to the clinical system and retrieve results. Providers can now take the electronic chart with them to the patient's room, where they can review lab results, x-ray reports and other tests with the patient. Wireless access points can support this workflow, permitting clinicians to work with the information they need when and where they need it. This wireless and cabled access supports more than just documentation stations. Virtual private networks (VPNs), voice over Internet protocol (VoIP) using fiber-optic cables and coaxial cables and supporting protocols, govern the connection of routers and switches. Local area networks (LANs) using Ethernet and a token ring, and wide area networks (WANs) using multiprotocol label switching (MPLS) or asynchronous transfer mode (ATM) are all in use, supporting the hardwired and wireless networks. VPN technology is a safer, more secure method of providing remote access to an organization's network and servers. VPNs, using tunneling protocols and encryption, require authentication to block out unauthorized users.

There are guidelines and rules from regulatory bodies and professional organizations, and standards that require documentation about patients and the care given to those patients, as well as documentation of procedures. One of the major requirements of an EHR is that it must be able to support the documentation, order entry and lab results reporting required by regulations, professional standards and patient need. Ideally, that care is documented when and where it is provided, thereby reducing errors.30

There are many areas in an organization that have cabled access to the organization's intranet (internal) and Internet (external). Cabled access is more reliable and faster. Many institutions already have cable that was installed before wireless was within the price range and speed requirements of most IT departments. Clinical departments, as well as administrative and support services, usually have hardwired desktop computers. Some healthcare providers, especially in outpatient settings, have installed a desktop or fixed device in each patient exam room. Specific clinical areas, such as radiology examination rooms, need special hardware, such as larger, high-resolution monitors and high-speed graphic cards that will support detailed images. In addition, hardware devices in patient care areas have to be cleaned with appropriate cleansing agents.

Communications

There are many different types of data communication protocols and media available in healthcare IT today, from the standard telephone landline with conferencing and video capabilities to various devices that use VoIP and broadband access. Data communication protocols allow information to transmit from one point or media to another. One of the most common examples would be the telephone. Some of the devices look like the same cell phones that are used outside the hospital, while some are clip-on, hands-free phones worn by staff members. As with other devices in use in clinical areas, such as tablets and medical devices, infection control is a major concern. Materials for these devices need to be antibacterial and cleanable. While some of these devices can send and receive text messages, there are concerns about the security of using text messages for patient orders and not all providers want to use text messages for orders. Bifurcated workflows such as these can result in missed patient care. Other examples of communication protocols would include broadband access, Ethernet and Wi-Fi for transmitting data across computer networks or accessing the Internet.

Chapter 2 · Technology Environment · Lesson 8 of 9

Interoperability, Standards, Data Integration and Data Warehouses

Big picture

This section names the standards healthcare IT runs on, defines interoperability and explains the two mechanisms that make shared data usable: interface engines and data warehouses. It is the technical center of the chapter and the material later chapters on design and analysis assume. The larger problem it solves is that data has to move between systems that were never designed together. Integration and warehousing are the pair to separate: an interface engine moves data correctly between systems in near real time, while a warehouse collects data from many systems so it can be queried together.

Walkthrough

Standards in healthcare IT

Health Level Seven is an international standard interface language used in healthcare.
HL7 Fast Healthcare Interoperability Resources is a next-generation standards framework leveraging the latest web standards.
Digital Imaging and Communications in Medicine is the standard used for images.
SNOMED CT is the most comprehensive multilingual clinical healthcare terminology in the world.
The International Statistical Classification of Diseases and Related Health Problems provides diagnosis codes for most disease conditions.
In the United States, ICD codes together with current procedural terminology codes classify diagnoses and procedures and link each procedure to the diagnosis that required it.
In France, the International Society for Pharmacoeconomics and Outcomes Research has developed charge codes for providers including the prices chargeable for a specific procedure.
Codes may be entered by clerical staff as well as providers and largely determine whether the institution or provider receives maximum or minimum reimbursement.
United States governing standards are included in the Final Rule published by CMS in August 2012, and Europe has the Advisory Board for Health Standards.

Question:

Pair each standard the source names with what it governs.
Explain how coding links to reimbursement in the source's account.

Interoperability and terminology standardization

Interoperability is the extent to which systems and devices can exchange data and interpret that shared data.
It is also described as the uniform movement of healthcare data from one system to another such that the clinical or operational purpose and meaning of the data is preserved and unaltered.
Data formats have become increasingly important with the movement to exchange patient data regardless of the patient's physical location.
Without standards, interoperability is impossible.
Without standards, healthcare IT would most resemble the Tower of Babel, with no system or device speaking the same language.
The consequences named are duplicative effort and work for clinical and administrative staff and patient safety concerns.
Nursing and other disciplines' terminologies are part of the standards discussion and can be used by nurses and other providers, including physicians, to document care.
The need to standardize terms affects all of healthcare and especially impacts quality reporting.
Standard words improve data, research and natural language processing because the meaning of the terms is clear.
There are interoperability challenges worldwide, and European integration effort is improving adoption chances.
Integration needs to move quickly because the number of specialty systems is increasing, often intended for one discipline and moving away from an integrated EHR.

Exchange plus interpretation is the full definition. A system that receives a message it cannot interpret has met half the definition and none of the purpose.

Question:

State both halves of the interoperability definition the source gives.
Why does the source treat the growth of single-discipline specialty systems as a problem?
What does terminology standardization do for quality reporting and natural language processing?

Data integration and data warehouses

Interface engines permit systems to be connected correctly.
It is not enough to send data from one application to another, because many rules must be followed.
Data reaching the wrong patient's chart can produce errors in care, in the bill and in the final report.
Interface engines drive the systems, matching data and patients correctly in near real time.
Without data integration and interface engines, a national health information network, connections to best of breed EHRs and EHR app integration using FHIR would not be possible.
Data warehouses are highly prevalent, and the value of storing and mining data from multiple sources such as the EHR and ancillary systems is clearly recognized.
Storing data from multiple sources in one place allows it to be queried at the same time.
Institutions must submit data to many organizations, from the Bureau of Vital Statistics to the American Heart Association in the United States or the European Society of Cardiology.
These organizations often require the same quality improvement data elements in a different format.
The warehouse supports quality reporting, clinical research and analytics.
Data mining can identify populations at risk, search for patterns of illness and identify potential study candidates or patient populations doing well.
Defining a data model, deciding whether a data mart would be more helpful than a warehouse and determining how to search the warehouse are decisions for an experienced database manager.

Example

Three registries want the same heart failure measures in three formats. Pulling each report from its own source system means three reconciliations; pulling all three from the warehouse means one set of numbers formatted three ways.

Question:

What does an interface engine do beyond passing data along, and what goes wrong without it?
Give the chief value of a data warehouse and three uses the source names for it.

Memory tips

Standard to purpose: HL7 is the interface language, FHIR the web-based next generation, DICOM images, SNOMED CT clinical terminology, ICD diagnoses, CPT procedures in the United States.
Interoperability definition has two verbs: exchange and interpret. Preserved and unaltered meaning is the second half.
Tower of Babel is the source's image for life without standards; the named costs are duplicative work and patient safety concerns.
Engine versus warehouse: the engine moves data correctly in near real time, the warehouse collects data so it can be queried together.
Warehouse uses three: quality reporting, clinical research, analytics, with data mining for risk, patterns and study candidates.

Key concepts

HL7: the international standard interface language used in healthcare
FHIR: the HL7 next-generation standards framework built on the latest web standards
DICOM: the standard used for images
SNOMED CT: the most comprehensive multilingual clinical healthcare terminology in the world
ICD: the classification providing diagnosis codes for most disease conditions
CPT: the U.S. procedure code set that links each procedure to the diagnosis requiring it
Interoperability: the extent to which systems and devices can exchange data and interpret it, moving data so that its clinical or operational purpose and meaning is preserved and unaltered
Standardized terminologies: nursing and other discipline terminologies that improve data, research, natural language processing and quality reporting
Interface engine: the component that connects systems correctly, enforcing the rules that match data and patients in near real time
Data warehouse: a single store of data from multiple sources allowing simultaneous querying for quality reporting, research, analytics and data mining

Practice questions

12 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: named standards and what each governs · ICD and CPT linkage and reimbursement effect · ISPOR charge codes in France · CMS Final Rule of August 2012 and the European advisory board · both halves of the interoperability definition · standards as a precondition and the Tower of Babel consequence · disciplinary terminologies and quality reporting · NLP benefit · global interoperability challenges and specialty system growth · interface engine function and failure consequences · dependence of national networks and FHIR app integration on integration · warehouse value and multi-source querying · reporting recipients and format variation · warehouse uses and data mining · data model, data mart and search decisions.

Read the original source

Interoperability and Standards

An important facet of all healthcare IT applications is the use of standards. Interoperability is essential to smooth functioning of healthcare IT, and systems that support standards ensure that functionality. Health Level Seven (HL7) is an international standard interface language used in healthcare,31 HL7 Fast Healthcare Interoperability Resources (FHIR®) is a next-generation standards framework that leverages the latest web standards, Digital Imaging and Communications in Medicine (DICOM®) is used as a standard for images32 and the Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT®) is the most comprehensive multilingual clinical healthcare terminology in the world,33 while the International Statistical Classification of Diseases and Related Health Problems (ICD) provides diagnosis codes for most disease conditions.34 In the United States, these codes, along with current procedural terminology (CPT®) codes, classify patients’ diagnoses and the procedures they had and provide a link between each procedure and the diagnosis that required it.35 In France, the International Society for Pharmacoeconomics and Outcomes Research (ISPOR) has developed charge codes for providers, including the correct prices that can be charged for a specific procedure.36 These codes can be entered into the system by clerical staff as well as providers, and in most cases, these codes have a large part in determining if an institution or provider will receive the maximum amount of reimbursement for performing a procedure or the minimum amount.

Interoperability is “the extent to which systems and devices can exchange data and interpret that shared data” and the “uniform movement of healthcare data from one system to another such that the clinical or operational purpose and meaning of the data is preserved and unaltered.”1 With the current movement to exchanging patient data, regardless of the physical location of the patient and the patient's home data, those standards, especially data formats, have become increasingly important and necessary.

Without standards, interoperability is impossible; without standards, healthcare IT would most resemble the Tower of Babel, with no system or device speaking the same language and resulting in duplicative effort and work from clinical and administrative staff as well as patient safety concerns. In the United States, governing standards are included in the Final Rule, published by CMS in August 2012, as well as the Advisory Board for Health Standards in Europe.37

Included in the discussion of standards are nursing and other disciplines’ terminologies. These terms can be used by nurses, as well as other providers, including physicians, to document patient care. The need to standardize terms affects all parts of healthcare and especially impacts quality reporting. The use of standard words for documentation improves data, research and natural language processing (NLP), since it is clear what the standardized terms mean.

There are challenges to EHR interoperability throughout the world. The integration effort currently in place in Europe is improving the chances of adoption. This integration needs to move quickly, as the number of specialty systems is increasing. The specialty systems are often intended for use by only one discipline, moving away from an integrated EHR.

Data Integration

Data integration and the use of interface engines are essential in healthcare IT. Interface engines permit systems to be connected correctly. It is not enough to simply send data from one application to another—there are many rules that must be followed. If data does not go to the right patient's chart, errors in the patient's care, bill and final report could result. Interface engines in a healthcare IT environment really drive the systems, matching data and patients correctly in near real time. Without data integration and interface engines, a national health information network, connections to EHR's with best of breed systems and EHR app integration using FHIR would not be possible.

Data Warehouses

Data warehouses are highly prevalent in today's healthcare IT landscape. The value of being able to store and mine data from multiple sources, such as the EHR and ancillary systems, is clearly recognized. Storing data in one place—the warehouse—from multiple sources allows it to be queried at the same time. Healthcare institutions have multiple requirements for submission of their data to different organizations, from the Bureau of Vital Statistics to the American Heart Association in the United States or the European Society of Cardiology. Often, these organizations require submission of the same quality improvement data elements, but just want it in a different format. The warehouse can support this type of quality reporting, as well as clinical research and analytics. Data mining can be used to identify populations at risk, search for patterns of illness and identify potential study candidates or those patient populations that are doing well.39 Defining a data model, deciding if a data mart would be more helpful than a warehouse and determining how to search the warehouse are all decisions that should be made by an experienced database manager.

Chapter 2 · Technology Environment · Lesson 9 of 9

Privacy and Security in the Technology Environment

Big picture

This closing section states the obligations that constrain every design decision in the chapter. It comes last but governs everything before it, and it previews the privacy and security chapter later in the guide. The larger problem it solves is that the same exchange that makes care safer also multiplies the places data can leak. Access control and disclosure are the pair here: one limits what a role can see inside the organization, the other limits how much leaves it.

Walkthrough

The first charge of EHR administration

Maintaining patients' information and ensuring it is kept private and secure is the first charge for EHR administration.
Data shared through health information exchanges and Regional Health Information Organizations must remain confidential.
Data regulations increasingly include strong language about privacy and security, emphasizing that the EHR can and must be developed without compromising patient privacy.
Systems must be designed to provide the patient an accounting of disclosures.
The system must maintain levels of confidentiality.
A nurse or physician must be able to see laboratory results while a nurse's aide using the same EHR must not.

Role-based visibility is stated as a design requirement, not an administrative preference. The system has to be able to express the difference before the policy can be enforced.

Question:

State the first charge of EHR administration in the source's wording.
Give the source's example of maintaining levels of confidentiality and explain what it requires of the system.

Disclosure limits and professional ethics

Disclosures may be made to appropriate agencies such as the patient's insurance provider.
Those agencies cannot be given complete access to the patient's record.
They must be given the minimum amount of information necessary.
Healthcare providers have an ethical obligation to keep patient information private and confidential.
The healthcare professions have codes of ethics detailing the nurse's and physician's obligation to protect patient information.

Example

An insurer reviewing a claim needs the encounter that generated the charge, not the patient's entire history. Sending the whole record because it is easier to export fails the minimum necessary standard.

Question:

What limit applies to a permitted disclosure to an insurer?
On what basis, beyond regulation, does the source ground the duty to protect patient information?

Memory tips

Order of priority: privacy and security is the first charge of EHR administration, stated before any functional goal.
Disclosure rule: permitted recipient, limited content. Minimum amount of information necessary, never complete access.
Two grounds for the duty: regulation and professional codes of ethics.
Design duties three: accounting of disclosures, levels of confidentiality, role-based visibility such as results hidden from a nurse's aide.

Key concepts

First charge of EHR administration: maintaining patient information and keeping it private and secure
Confidentiality in exchange: the requirement that data shared through HIEs and RHIOs remain confidential
Accounting of disclosures: the system capability to show the patient what was disclosed
Levels of confidentiality: role-based visibility, such as clinicians seeing laboratory results while a nurse's aide does not
Minimum necessary disclosure: the limit on information given to permitted recipients such as insurers, who may not receive complete record access
Professional codes of ethics: the ethical grounding of the nurse's and physician's duty to protect patient information

Practice questions

3 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: privacy and security as the first charge · confidentiality within HIE and RHIO sharing · regulatory language on developing the EHR without compromising privacy · accounting of disclosures as a design requirement · levels of confidentiality and the nurse's aide example · permitted disclosures and the minimum necessary limit · ethical obligation and professional codes of ethics.

Read the original source

Privacy and Security

Maintaining patients’ information, ensuring that it is kept private and secure, is the first charge for EHR administration. As an example, while patients’ data has to be shared through HIEs and Regional Health Information Organizations (RHIOs), it must remain confidential. Increasingly, data regulations are including strong language about privacy and security, emphasizing that the EHR can and must be developed without compromising a patient's privacy. Systems, as part of their design, have to be able to provide the patient an accounting of disclosures. The system must be able to maintain levels of confidentiality. For example, a nurse or physician must be able to see the patient's laboratory results, but a nurse's aide using that same EHR should not be able to see that information.

While disclosures of information can be made to appropriate agencies, such as the patient's insurance provider, those agencies cannot be given complete access to the patient's record, but must be given the minimum amount of information necessary.

Ethically, healthcare providers have an obligation to keep any patient's information private and confidential. The healthcare professions have codes of ethics that clearly detail the nurse's and physician's obligation to protect the patient's information.40

Summary

Understanding the basic foundations of healthcare technologies, applications and other tools used in connecting them together provides healthcare professionals and others allied to the field the ability to create, support and maintain healthcare information. Knowledge of these fundamental areas, as well as key issues and especially trends, is the basis of building and designing healthcare IT and supporting healthcare providers in their work of caring for patients in a safe, accurate and timely manner.

Chapter 2 · Technology Environment · Supplemental lesson

The Four Levels of Interoperability

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Interoperability appears throughout the chapters as a single undifferentiated word. It is actually a four-level hierarchy, and the exam builds umbrella-versus-component traps on hierarchies. Each level assumes the one below it, and the federal instruments sitting above the hierarchy solve different levels of it.

Walkthrough

The four levels

Foundational: system A can transmit and system B can receive, with no interpretation required. A PDF arriving in an inbox satisfies it.
Structural: the format and syntax are defined and preserved, so the receiving system can parse the transmission into the correct fields. HL7 v2 message structure and C-CDA document structure operate here, and the meaning of the values is not guaranteed.
Semantic: shared meaning achieved through common terminologies and value sets, so both systems agree what a specific code means. Only at this level can the receiving system compute on the data, trend it, alert on it or feed it to a measure.
Organizational: governance, policy, trust agreements, legal permission and workflow alignment. Two systems can be technically perfect and still not exchange because no agreement permits it.

Example

A faxed discharge summary is foundational. The same summary parsed as a C-CDA is structural. The same summary with problems in SNOMED CT and labs in LOINC, auto-populating the problem list, is semantic.

Question:

Name the four levels in order and what each adds.
Distinguish structural from semantic interoperability.
Give an example of a failure at the organizational level.

The federal layer above the levels

The 21st Century Cures Act of 2016 is the statute. It prohibited information blocking, meaning practices likely to interfere with access, exchange or use of electronic health information subject to defined exceptions, required certified APIs without special effort and directed creation of a trusted exchange framework.
TEFCA, the Trusted Exchange Framework and Common Agreement, fulfils that directive, with networks designated as Qualified Health Information Networks exchanging under a single common agreement rather than thousands of bilateral ones.
The Recognized Coordinating Entity administering TEFCA is The Sequoia Project, on behalf of ASTP and ONC.
USCDI is the minimum set of data classes and elements every certified system must be able to exchange, the content floor beneath everything else.
TEFCA solves the organizational level and USCDI pushes toward the semantic level; neither replaces the other.

Question:

State what the Cures Act did in three parts.
Explain what TEFCA is and which level it addresses.
What is USCDI, and what level does it support?

Memory tips

Four levels in order: foundational transmit and receive, structural format and syntax, semantic shared meaning, organizational governance and trust.
Most testable dependency: semantic interoperability requires standardized terminologies.
Stem cues: depends on, is based on or is a prerequisite for point down the hierarchy; computable, actionable or automatically populate point up to semantic.
TEFCA is governance, not a data standard. QHINs exchange under the Common Agreement, administered by the Recognized Coordinating Entity.
FHIR alone gives structure, not meaning.

Key concepts

Foundational interoperability: the ability to transmit and receive, with no interpretation required
Structural interoperability: defined and preserved format and syntax, allowing the receiving system to parse data into the correct fields
Semantic interoperability: shared meaning through common terminologies and value sets, making received data computable
Organizational interoperability: governance, policy, trust agreements, legal permission and workflow alignment
21st Century Cures Act: the 2016 statute prohibiting information blocking, requiring certified APIs and directing creation of a trusted exchange framework
TEFCA: the Trusted Exchange Framework and Common Agreement, under which QHINs exchange through a single agreement, administered by The Sequoia Project as Recognized Coordinating Entity
USCDI: the minimum set of data classes and elements every certified system must exchange

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the four levels, their order and what each adds · examples at each level · the dependency of semantic interoperability on terminology · the Cures Act's three provisions · TEFCA, QHINs, the Common Agreement and the Recognized Coordinating Entity · USCDI as content floor · which level each instrument addresses.

Read the supplemental lesson source

S2.1 — The Four Levels of Interoperability

Chapters 2 and 3 · Tasks I.B.2, II.A · About 12 minutes

1. Learn the topic

Where this fits

This is the highest-leverage lesson in the supplement. "Interoperability" appears throughout your chapters as a single undifferentiated word. It is actually a four-level hierarchy, and CPHIMS builds umbrella-versus-component traps on hierarchies. Learn this and a whole class of items becomes readable.

What it means

Interoperability is the ability of systems to exchange data and use what they receive. That second clause is where the levels come from — "use" turns out to mean very different things depending on how much shared understanding exists.

How it works

Build upward. Each level assumes the one below it.

Foundational. System A can transmit; system B can receive. That's all. The receiving system need not interpret anything. A PDF arriving in an inbox satisfies foundational interoperability.

Structural. The format and syntax are defined and preserved, so the receiving system can parse the transmission into the correct fields. It knows that this segment is the patient name and that one is the ordering provider. HL7 v2 message structure and C-CDA document structure operate here. The data lands in the right places — but the meaning of the values is not guaranteed.

Semantic. Shared meaning, achieved through common terminologies and value sets. Both systems agree not only that this field holds a lab result, but that this specific code means serum potassium measured this specific way. Only at this level can the receiving system compute on the data — trend it, alert on it, feed it to a measure.

Organizational. Governance, policy, trust agreements, legal permission and workflow alignment. Two systems can be technically perfect and still not exchange because no agreement permits it. This is the layer TEFCA operates on: the Common Agreement is a legal and governance instrument, not a data format.

The federal layer above the levels

Three things sit on top of this hierarchy and are worth knowing by name and function:

21st Century Cures Act (2016) — the statute. It prohibited information blocking (practices likely to interfere with access, exchange or use of electronic health information, subject to defined exceptions), required certified APIs "without special effort," and directed the creation of a trusted exchange framework.

TEFCA — the Trusted Exchange Framework and Common Agreement, which fulfils that directive. Networks designated as QHINs (Qualified Health Information Networks) exchange under a single common agreement rather than thousands of bilateral ones. The Recognized Coordinating Entity administering it is The Sequoia Project, on behalf of ASTP/ONC.

USCDI — the minimum set of data classes and elements every certified system must be able to exchange. It is the content floor beneath everything else.

Note what each solves. TEFCA solves the organizational level. USCDI pushes toward the semantic level. Neither replaces the other.

Examples and non-examples

Straightforward. A fax of a discharge summary: foundational. The same summary as a parsed C-CDA: structural. The same summary with problems in SNOMED CT and labs in LOINC, so the receiving system auto-populates the problem list: semantic.

Connecting to another concept. Your organization and a neighbouring system both run FHIR R4 with US Core profiles — technically capable of semantic exchange. Nothing moves, because no data use agreement exists. That failure is organizational, not technical. This is the exact shape of a CPHIMS scenario item.

Non-example. Two systems sending each other free-text notes reliably and at scale are not semantically interoperable no matter how much data moves. Volume is not meaning.

Common misconceptions

"Interoperability is a technical problem." The organizational level is usually the binding constraint in practice, and the exam reflects that.

"If we implement FHIR, we're interoperable." FHIR is a transport and structure standard. Semantic interoperability additionally requires agreed terminologies and value sets.

"TEFCA is a data standard." It is a governance framework — a common agreement, participation rules and required exchange purposes.

2. Exam focus

What you must know

The four levels in order and what each adds: foundational (transmit/receive) → structural (format and syntax) → semantic (shared meaning via terminology) → organizational (governance, policy, trust).

Semantic interoperability requires standardized terminologies. That dependency is the single most testable relationship here.

Cures Act → information blocking prohibition + certified APIs + directive to build TEFCA.

TEFCA / QHIN / Common Agreement / RCE = the organizational layer.

USCDI = minimum data content floor.

Distinctions likely to be tested

Structural vs. semantic. Structural gets the data into the right field; semantic makes the value mean the same thing. This is the most common confusion.

Standard (a specification) vs. implementation guide (a constrained profile of it) vs. framework (governance).

How this appears in a question

Stems using "depends on," "is based on," or "is a prerequisite for" point down the hierarchy to the foundational layer. Stems using "computable," "actionable," or "automatically populate" point up to semantic.

3. Teach it back

Explain to an IT director who thinks the interface engine solved interoperability years ago:

1. The four levels, with one concrete example each.

2. Why two organizations running identical software might still be unable to exchange.

3. What has to be true for a received lab result to auto-populate a flowsheet and trigger an alert — and which level that is.

<summary>Key-point checklist</summary>

[ ] All four levels, correct order, correct additive logic

[ ] Structural = format/syntax; semantic = shared meaning

[ ] Named terminology standards as the semantic enabler

[ ] Gave an organizational-level failure with no technical cause

[ ] Recognized that "auto-populate and alert" requires semantic

[ ] Did not describe TEFCA as a data format

</details>

4. Practice

Items SQ-12 to SQ-15.

5. Key takeaway

Four levels, each assuming the last: transmit → parse → mean the same thing → be permitted to. The technical levels get the attention; the organizational level is usually what actually blocks exchange, and CPHIMS consistently rewards the answer that says so.

Chapter 2 · Technology Environment · Supplemental lesson

The HL7 Family and Where the Cloud Sits

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This lesson populates the interoperability levels with the actual standards and the actual infrastructure, the two halves of the technology environment domain. The HL7 generations coexist rather than replacing one another, and the cloud service models are distinguished by who controls which layer. Accountability for protected health information does not move with the workload.

Walkthrough

The HL7 generations and neighbouring standards

HL7 International is a standards development organization whose generations coexist.
HL7 v2 uses pipe-delimited, event-driven messages and remains the workhorse of real-time clinical messaging for admissions, discharges and transfers, lab orders and results and pharmacy. Its flexibility means every interface is negotiated.
HL7 v3 and CDA are XML-based. V3 as a messaging standard saw limited uptake, while CDA succeeded as a document standard, with its U.S. constraint C-CDA carrying the continuity of care document at transitions of care.
FHIR uses modular resources such as Patient, Observation, Encounter and MedicationRequest, accessed over standard web REST APIs in JSON or XML, and is the direction of federal policy and the market.
SMART on FHIR App Launch defines how a third-party app launches inside the EHR and is authorized to read data, using OAuth 2.0.
Bulk Data export provides asynchronous extraction of large populations for analytics.
CDS Hooks lets the EHR call out to a decision support service at defined workflow moments.
Beyond HL7: DICOM for medical imaging as both format and transfer protocol, X12 for administrative and claims transactions, NCPDP for pharmacy transactions.
IHE profiles are not new standards but constrained combinations of existing standards for specific use cases.

Question:

Distinguish message, document and resource as units of exchange with their generations.
Match SMART on FHIR, Bulk Data and CDS Hooks to the question each answers.
What is an IHE profile, and what is it not?

Cloud service models and accountability

Infrastructure as a service supplies compute, storage and network, with the customer managing the operating system upward, at maximum control and maximum responsibility.
Platform as a service adds provider management of the operating system and runtime, with the customer managing application and data.
Software as a service leaves the provider managing everything, with the customer configuring and using, at minimum control and minimum operational burden.
Deployment models cut across these: public, private, hybrid and community.
Under the shared responsibility model the covered entity remains accountable for protected health information whatever the service model.
A cloud provider handling PHI is a business associate and requires a business associate agreement.
An integration engine sits between systems translating and routing, historically HL7 v2 over MLLP and increasingly FHIR over HTTPS, with the enterprise service bus as the architectural pattern.
What changes with FHIR is not that translation disappears but that the interface becomes a queryable API rather than a stream of pushed messages.

Example

Moving to software as a service moves operational work. It does not move HIPAA accountability, which is why the agreement rather than the architecture is the compliance artifact.

Question:

Order the three service models by who controls which layer.
State what moves and what does not move when PHI goes to the cloud.

Memory tips

Generation cues: v2 is messaging and pipe-delimited, CDA and C-CDA are documents in XML for transitions, FHIR is resources over REST.
FHIR patterns three: SMART on FHIR for app launch with OAuth 2.0, Bulk Data for population export, CDS Hooks for workflow-triggered decision support.
Neighbours: DICOM imaging, X12 claims, NCPDP pharmacy, IHE profiles.
Cloud ladder: IaaS you manage the OS upward, PaaS you manage app and data, SaaS you configure and use.
Accountability rule: covered entity stays accountable, provider becomes a business associate, BAA required.

Key concepts

HL7 v2: pipe-delimited, event-driven messaging, dominant for real-time clinical exchange
CDA and C-CDA: XML document standards, with C-CDA carrying continuity of care information at transitions
FHIR: modular resources over REST APIs in JSON or XML, favoured by federal policy and the market
SMART on FHIR, Bulk Data and CDS Hooks: app launch with OAuth 2.0, asynchronous population export, and workflow-triggered calls to external decision support
Adjacent standards: DICOM for imaging, X12 for claims and administration, NCPDP for pharmacy, and IHE profiles constraining existing standards
Cloud service models: IaaS, PaaS and SaaS, distinguished by which layers the provider manages, across public, private, hybrid and community deployments
Shared responsibility: the model under which the covered entity remains accountable for PHI and the cloud provider is a business associate requiring a BAA

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: HL7 as an organization and the coexistence of generations · v2 characteristics and dominance · v3, CDA and C-CDA · FHIR resources and REST access · the three FHIR patterns and their purposes · DICOM, X12, NCPDP and IHE profiles · the three cloud service models and deployment models · shared responsibility, business associate status and BAAs · integration engines, MLLP, FHIR over HTTPS and the ESB pattern.

Read the supplemental lesson source

S2.2 — The HL7 Family, and Where the Cloud Sits

Chapter 2 · Tasks I.B.1, I.B.2 · About 14 minutes

1. Learn the topic

Where this fits

Lesson S2.1 gave you the levels. This lesson populates them with the actual standards and the actual infrastructure — the two halves of blueprint domain I.B.

What it means: the standards

HL7 International is a standards development organization. It has produced several generations, and they coexist rather than replacing one another.

HL7 v2 — pipe-delimited messages, event-driven. Still the workhorse of real-time clinical messaging: admissions/discharges/transfers, lab orders and results, pharmacy. Enormously deployed, highly flexible, and that flexibility is its weakness — v2 implementations vary so much that every interface is negotiated.

HL7 v3 and CDA — XML-based. v3 as a messaging standard saw limited uptake. CDA (Clinical Document Architecture) succeeded as a document standard, and its US constraint, C-CDA, carries the continuity of care document that moves at transitions of care.

FHIR — Fast Healthcare Interoperability Resources. Modular resources (Patient, Observation, Encounter, MedicationRequest) accessed over standard web REST APIs, in JSON or XML. This is the direction of federal policy and of the market.

Three FHIR patterns worth naming, because they answer three different questions:

SMART on FHIR App Launch — how a third-party app launches inside the EHR and gets authorized to read data, using OAuth 2.0. Answers: how does an app get in?

Bulk Data $export — asynchronous extraction of large populations. Answers: how do I get everyone's data for analytics?

CDS Hooks — the EHR calls out to a decision support service at defined workflow moments. Answers: how does external logic reach the clinician in the moment?

Beyond HL7: DICOM for medical imaging (both format and transfer protocol), X12 for administrative and claims transactions, NCPDP for pharmacy transactions, and IHE profiles, which are not new standards but constrained combinations of existing standards for specific use cases.

What it means: the infrastructure

The other half of domain I.B is the technology stack: networks, communications, integration and security. The piece your chapters name without defining is cloud service models, and the exam-relevant question is always who controls which layer.

IaaS — the provider supplies compute, storage and network. You manage the operating system upward. Maximum control, maximum responsibility.

PaaS — the provider also manages the OS and runtime. You manage your application and data.

SaaS — the provider manages everything; you configure and use. Minimum control, minimum operational burden.

Deployment models cut across these: public, private, hybrid, community.

The compliance consequence is the shared responsibility model. Whatever the service model, the covered entity remains accountable for the PHI. The cloud provider handling PHI is a business associate and requires a BAA. Moving to SaaS moves operational work; it does not move accountability.

How it works together

An integration engine (interface engine) sits between systems, translating and routing — historically HL7 v2 over MLLP, increasingly FHIR over HTTPS. The ESB or integration platform is the architectural pattern. What changes with FHIR is not that translation disappears, but that the interface becomes a queryable API rather than a stream of pushed messages.

Examples and non-examples

Straightforward. A lab result arrives as an HL7 v2 ORU message and lands in the flowsheet. A patient's app pulls the same result through a SMART on FHIR call. Same datum, two standards, two access patterns.

Connecting to another concept. FHIR gives you structural interoperability out of the box. It gives you semantic interoperability only if the coded elements use agreed terminologies — which is what US Core profiles and USCDI are for. The standard alone is not the meaning.

Non-example. A nightly CSV drop to an SFTP server is an integration, and it works. It is not a standard-based interface: no defined semantics, no versioning, no conformance. It will break silently.

Common misconceptions

"FHIR replaced HL7 v2." It hasn't and won't soon. v2 remains dominant for high-volume real-time clinical messaging.

"IHE is a standard." IHE publishes profiles that constrain and combine existing standards for defined use cases.

"Moving to the cloud transfers HIPAA responsibility." It does not. The covered entity remains accountable; the provider becomes a business associate.

2. Exam focus

What you must know

v2 = messaging, pipe-delimited, event-driven, ubiquitous. CDA/C-CDA = documents, XML, transitions of care. FHIR = resources, REST APIs, modern and policy-favoured.

DICOM = imaging. X12 = claims/administrative. NCPDP = pharmacy. IHE = profiles, not standards.

SMART on FHIR (app launch, OAuth 2.0) / Bulk Data (population export) / CDS Hooks (workflow-triggered decision support).

IaaS / PaaS / SaaS by who controls which layer. BAA required. Accountability does not transfer.

Distinctions likely to be tested

Message vs. document vs. resource — three different units of exchange, three generations.

Standard vs. profile vs. implementation guide.

Service model vs. deployment model (SaaS is what layer; public/private is where).

How this appears in a question

Adjacent-role traps built from four real standards, where only one has the function the stem names. Anchor on the object being exchanged: a message, a document, a resource, an image, a claim.

Currency note — read once. FHIR R4 is the production and regulatory baseline. R5 published 2023; R6 is in ballot, expected 2026–27. US Core — the US constraint on FHIR — remains R4-based. Don't drill version numbers.

3. Teach it back

Explain to a new analyst:

1. Why the organization still runs HL7 v2 interfaces if FHIR is better.

2. The difference between what SMART on FHIR does and what CDS Hooks does.

3. Your organization moves its EHR to a vendor-hosted SaaS. Explain what changed and what didn't, from a HIPAA standpoint.

<summary>Key-point checklist</summary>

[ ] Distinguished message / document / resource as units of exchange

[ ] Gave a real reason v2 persists (volume, real-time, installed base)

[ ] SMART = app authorization and launch; CDS Hooks = EHR calls out for decision logic at a workflow trigger

[ ] Named the BAA and stated that covered-entity accountability does not transfer

[ ] Did not call IHE a standard

</details>

4. Practice

Items SQ-16 to SQ-19.

5. Key takeaway

Match the standard to the object: v2 moves messages, CDA moves documents, FHIR exposes resources, DICOM moves images, X12 moves claims. And in the cloud, the service model determines what you operate — never what you're accountable for.

Chapter 3 · Clinical Informatics · Lesson 1 of 7

What Clinical Informatics Is, Where It Sits and Who Practices It

Big picture

This section defines clinical informatics, lists the field's components, describes its global reach and names the four things clinical informaticians do. It opens the Clinical Informatics domain, which the exam weights on its own, and it frames the vocabulary, metrics, decision support and analytics lessons that follow. The larger problem it solves is role definition: the informaticist is described as the translator on an interprofessional team, which is why the field is defined by activities rather than by a job title. Do not confuse the HIMSS definition of the field with the AMIA statement of what clinical informaticians do; the first says what the discipline is, the second says what its practitioners perform.

Walkthrough

Definition and scope of the field

HIMSS defines clinical informatics as the promotion of understanding, integration and application of information technology in healthcare settings to ensure adequate and qualified support of clinician objectives and industry best practices.
The field includes methods to collect, store and analyze healthcare data.
It includes the study of information needs and cognitive processes and the optimal ways to meet those needs.
It includes methods to support clinical decisions, including summarization, visualization, provision of evidence and active decision support.
It includes optimizing the flow of information and coordinating it with care providers' and patients' workflows to maximize patient safety and care quality.
It includes methods and policies for information infrastructure, including privacy and security.
Clinical informaticists may come from medicine, nursing, pharmacy, laboratory, radiology and other clinical professions.
Physicians and nurses are the largest group that has actively contributed to and advanced the theory and practice of clinical informatics.
Nurses established an early role with certifications starting in 1992; physicians followed through AMIA in 2013.
CAHIMS and CPHIMS are listed among the highest recommended informatics certifications for clinicians, alongside board certifications.
Certification is recognized as a highly visible quality indicator and a tool to improve recognition among peers.
The informaticist's role is described as translator on the interprofessional team, a professional who speaks both informatics and healthcare.

The five components of the field are a complete named set. Each one anticipates a later section of the chapter, from data collection through decision support to infrastructure policy.

Question:

Name all five components of the clinical informatics field as the source lists them.
Give the certification dates for nursing and physician informatics and the bodies involved.
Explain the translator description of the informaticist to a nurse manager in three sentences.

Global aspects

Health information data can be stored across borders, which brings international law to bear on data usage and patients' rights.
That requires regulatory knowledge of the country of origin and of any foreign locations.
AMIA leads a global health informatics working group designed to work with resource-constrained countries, with a connection forum for exchanging experience and expertise.
Digital health is the term for clinical informatics more commonly used outside the United States.
HIMSS supports digital health in Canada, including the CPHIMS-CA certification, and concentrates on strengthening the Ontario Chapter, supporting existing Canadian associations and initiatives, and filling the gap in Canadian stakeholder expertise.
The EU-US eHealth Work Project, a Horizon 2020 project, ran 21 months from September 2016 to May 2018.
Its goal was to map skills and competencies, provide access to knowledge tools and platforms, and strengthen, disseminate and exploit outcomes for a skilled transatlantic eHealth workforce.
Its survey drew more than 1,000 respondents globally, 72 percent from the United States and 19 percent from Europe.
The most significant result was the need for increased clinical informatics education, with nurses, physicians and educators the top three, released as GAP1 of ten identified gaps.
Other gaps covered teacher and trainer knowledge, acceptance and usage of systems, availability of courses or programmes, and the quality of training materials.
The project updated the Health Information Technology Competencies tool to version 2.0, containing over 1,000 competencies and over 250 healthcare roles in five major European languages.
The HIMSS TIGER Initiative supports the work through the Foundational Curriculum, the TRIE web platform and the skills and knowledge assessment and development framework.

Question:

What is digital health, and where is the term used?
State the EU-US eHealth Work Project's goal, its survey composition and its GAP1 finding.
Describe the HITCOMP tool by its scale and coverage.

Domains of clinical informatics

Clinical informaticians transform healthcare by analyzing, designing, implementing and evaluating information and communication systems.
Those systems enhance individual and population health outcomes, improve patient care and strengthen the clinician-patient relationship.
Per AMIA, clinical informaticians assess information and knowledge needs of healthcare professionals and patients.
They characterize, evaluate and refine clinical processes.
They develop, implement and refine clinical decision-support systems.
They lead or participate in the procurement, customization, development, implementation, management, evaluation and continuous improvement of clinical information systems.
Patient safety is described as always paramount.

Example

An informaticist asked to add a sepsis alert does all four in sequence: asks what the team needs to know, maps the current screening process, builds and tunes the alert, then owns its evaluation after go-live.

Question:

Name the four AMIA domains of clinical informatics in order.
Which domain covers work after a system is live, and what does it include?

Memory tips

Five components of the field, in source order: collect and analyze data; information needs and cognition; decision support; information flow and workflow; infrastructure policy including privacy and security.
Certification dates: nursing 1992, physicians through AMIA 2013. Nurses first by twenty-one years.
AMIA domains four verbs: Assess needs, Characterize processes, Develop decision support, Lead the system lifecycle.
eHealth Work numbers: 21 months, September 2016 to May 2018, over 1,000 respondents, 72 percent United States and 19 percent Europe, ten gaps with education as GAP1.
HITCOMP 2.0 scale: over 1,000 competencies, over 250 roles, five major European languages.

Key concepts

Clinical informatics: the promotion of understanding, integration and application of information technology in healthcare settings to support clinician objectives and industry best practices, per HIMSS
Components of the field: data collection and analysis, information needs and cognitive processes, decision support methods, information flow and workflow coordination, and infrastructure methods and policies including privacy and security
Informatics certifications: nursing certification from 1992, physician clinical informatics certification through AMIA from 2013, and CAHIMS and CPHIMS among the highest recommended for clinicians
Digital health: the term for clinical informatics more commonly used outside the United States
EU-US eHealth Work Project: the 21-month Horizon 2020 project mapping eHealth skills and competencies, whose survey identified education of nurses, physicians and educators as its first gap
HITCOMP 2.0: the health IT competencies tool with over 1,000 competencies and over 250 roles in five major European languages
Domains of clinical informatics: assessing information and knowledge needs, characterizing and refining clinical processes, developing and refining clinical decision support, and leading the clinical information system lifecycle

Practice questions

The bank holds no items mapped to this lesson, so nothing is drilled here. The material still supports items in the lessons that follow.

Source fidelity

Covered from the source: the HIMSS definition of clinical informatics · the five components of the field · professions contributing to the discipline · nursing and physician certification dates and bodies · CAHIMS and CPHIMS recommendation and the value of certification · the translator role · cross-border data and international law · AMIA global health informatics working group · digital health terminology · HIMSS Canada focus areas and CPHIMS-CA · EU-US eHealth Work Project scope, dates, survey composition and gaps · HITCOMP 2.0 scale · TIGER supporting platforms · the AMIA statement of what clinical informaticians do and the four domains · patient safety as paramount.

Read the original source

Introduction

Clinical informatics is a vast and diverse study of information technology (IT) and how it can be applied to the healthcare field. HIMSS defines clinical informatics as the promotion of “understanding, integration and application of information technology in healthcare settings to ensure adequate and qualified support of clinician objectives and industry best practices.”1 The field includes2:

Methods to collect, store and analyze healthcare data

The study of information needs and cognitive processes and optimal ways to meet those needs

Methods to support clinical decisions, including summarization, visualization, provision of evidence and active decision support

Optimizing the flow of information and coordinating it with care providers’ and patients’ workflows to maximize patient safety and care quality

Methods and policies for information infrastructure, including privacy and security

Globally, clinical informatics has been increasingly impactful to the healthcare world. Diana Nole, the Chief Executive Officer (CEO) of Wolters Kluwer Health, states that in 2018 there was more than US$ 8 billion in digital health deals made.3 Clinical decision support (CDS) continues to be a powerful tool in providing guidance to today's clinicians. Drug usage and cost is being looked at with new eyes through data, and artificial intelligence (AI) and machine learning adoption are on the rise. With the increased focus on social determinants of health and patient-driven care, AI will development and usage will continue well into the future.3 And clinical informaticists will be needed to maintain their role as translators in the interprofessional team, as a professional that speaks both informatics and healthcare.

As discussed in Chapter 1, “Healthcare Environment,” often considered a hybrid of many different informatics models and theories, clinical informaticists can consist of physicians, nurses, pharmacy, laboratory, radiology and other clinical professions. Physicians and nurses make up the largest group of healthcare professionals, “who have actively contributed to and advanced the theory and practice of clinical informatics.”4 Nurses established an early role as clinical informaticists, with certifications starting in 1992.4 Physicians later followed with their own certifications through the American Medical Informatics Association (AMIA) in 2013.5 HIMSS, Certified Associate in Healthcare Information and Management Systems (CAHIMSSM) and Certified Professional in Healthcare Information and Management Systems (CPHIMSSM) are listed among the highest recommended informatics certifications for clinicians, as well as board certifications. Acquiring a certification is recognized as a “highly-visible quality indicator and a tool to improve recognition among peers.”4 Table 3.1 takes a look at the differences between nursing and physician certification processes.

Table 3.1 Comparison of Informatics Certification Processes for Nurses and Physicians4

Nursing Informatics Certification Informatics Skills/Competencies References

Clinical Informatics Board Certification for Physician* Informatics Skills/Content Outline References

Skills and Competencies

Scope of nursing informatics practice: foundational knowledge of metastructures, concepts and tools, functional areas of nursing informatics; evolution of informatics competencies, ethics, the future of nursing informatics including trends in practice roles, technology, regulatory changes and quality standards, care delivery models and innovation. Standards of nursing informatics practice: assessment, diagnosis, problems and issues, outcomes identification, planning, implementation, evaluation standards of professional performance for nursing informatics: ethics, education, evidence-based practice and research, quality of practice, communication, leadership, collaboration, professional practice evaluation, resource utilization, environmental health

Informatics competencies as listed on the outline for board certification: leading and managing change, health information systems, fundamentals of informatics, clinical decision-making and care process improvement, legal, ethical and regulatory issues

Global Aspects of Clinical Informatics

Although many items referenced in this chapter are centered around the United States, clinical informatics is very global. Global clinical informatics is a fast-growing, interdisciplinary field. From privacy and security issues to global population health, clinical informatics professionals have a great impact on the management of patient health data.

Health information data can be stored across borders, which allows for the impact of international law with both the data usage as well as patient's rights.6 This requires not only a strong healthcare system and regulatory knowledge for the country of origin but any foreign locations as well.

Several global initiatives share the mission of increasing clinical informatics education and best-practices. The AMIA leads a global health informatics working group (GHIWG) designed to work with resource-constrained countries. They work to increase overall informatics usage and facilitate collaborative efforts between clinical informatics workers. Their connection forum helps to facilitate the exchange of both informatics experiences, as well as expertise, across the global spectrum.7

HIMSS has always had its North American roots. Within that scope, it includes the digital health support of Canada, including its own HIMSS certification (CPHIMS-CASM). Digital health is a term for clinical informatics more commonly used outside the United States. Through HIMSS, “international insights, resources, and audiences” are provided at the ready for the Canadian clinical informatics professionals.8 The Canadian/HIMSS collaboration currently concentrates in three areas8:

Strengthening the HIMSS Ontario Chapter (ON Chapter) through increasing the Canadian health association presence in HIMSS activities, volunteer opportunities and project that will aid both Ontario's, as well as HIMSS, global digital health influence.

Support existing associations and Canadian digital health initiative by including (and sponsoring) local informatics groups such as the British Columbia Health Information Management Professionals Society (BCHIMPS) and the Canadian Trade commission.

And by filling the void. HIMSS has the unique ability to bridge the clinical informatics gap and aid in increasing the knowledge and expertise of Canadian stakeholders. This is evidenced by its recent expansion efforts, including the formation of the Canadian Prairies Chapter of HIMSS to support other areas of Canada in a more local fashion.

Furthermore, since the publication of this chapter, HIMSS has also worked with local constituents to form the Canadian Prairies Chapter and with the BCHIMPS to form the HIMSS British Columbia Chapter.

Finally, there is the EU–US eHealth Work Project, which culminated its project work in May 2018. As a Horizon 2020 project, its goal was to “map skills and competencies, provide access to knowledge tools and platforms and strengthen, disseminate and exploit success outcomes for a skilled transatlantic eHealth workforce.”9 The 21-month project began in September 2016 with funding from the European Commission's Horizon 2020 research and innovation grant program and came to a close in May 2018. Their challenge was to develop something that would expand the foundations already in place for digital skills and push the global boundaries of innovation and resource development. This included making sure that clinical informaticists were engaged and brought into the extensive stakeholder community. They achieved this through the development of the Consortium, which consisted of a network of partners in academia, healthcare associations, as well as healthcare providers, and industry workers. The Consortium included: Omni Miro Systems/Med Solutions (Germany) who served as the project coordinator, European Health Telematics Association (EHTEL) (Belgium), University of Applied Sciences Osnabrück (Germany), Tampere University of Technology (Finland), Steinbeis 2i GmbH (Germany),9 and the HIMSS Foundation with project fulfillment by the HIMSS Technology Informatics Guiding Education Reform (TIGERTM) Initiative. To meet their goals, they conducted a survey (Survey of Current State and Needs of the eHealth Workforce) to identify the “real world” challenges and gaps in informatics. The study, which served as the flagship of the project, considered demographics with over 1,000 respondents globally, primarily from the United States (72%) and Europe (19%). One of the most significant results of the survey was the need for increased clinical informatics education, specifically with nurses, physicians and educators rounding out the top three. They released this as GAP1: eHealth knowledge and skills of healthcare professionals, with there being ten significant gaps identified in total. Other deficiencies consisted of gaps in teacher/trainer knowledge, acceptance and usage of systems, availability of course or programmes for education and the quality of current training materials for any clinical informaticist.9

The project also included an update of the Health Information Technology Competencies (HITCOMP) Tool to a 2.0 version. Seen as an innovative solution, this tool is available to the global clinical informatics community and concentrates on eHealth, digital skills research, education development, skills assessment, and career progression. It contains over 1000 competencies, over 250 healthcare roles, in five major European languages.

The HIMSS TIGER Initiative continues its partnership with the project through support in several platforms such as the Foundational Curriculum and the Interactive Web Platform TRIE (tools, resource, information, education) (includes HIMSS TIGER Virtual Learning Environment (VLE)). Also, the skills and knowledge assessment and development (SKAD) framework promotes certification programs such as the HIMSS CAHIMS/CPHIMS.9

Domains of Clinical Informatics

With patient safety always paramount, “clinical informaticians transform healthcare by analyzing, designing, implementing and evaluating information and communication systems that enhance individual and population health outcomes, improve patient care, and strengthen the clinician-patient relationship.”10

According to AMIA (Figure 3.1), “clinical informaticians use their knowledge of patient care combined with their understanding of informatics concepts, methods, and tools to:

Figure 3.1Domains of clinical informatics.10

Assess information and knowledge needs of healthcare professionals and patients;

Characterize, evaluate and refine clinical processes;

Develop, implement and refine clinical decision-support systems; and

Lead or participate in the procurement, customization, development, implementation, management, evaluation and continuous improvement of clinical information systems.”10

In this chapter, we will take a deeper dive into the world for clinical informatics. Starting with the basics, we will review the language and definitions commonly used in healthcare. We will also examine clinical metrics frequently represented in informatics such as average daily census, turnaround time, adherence and barcode medication administration. To evaluate these metrics, often informaticists will need to use various analytical tools. It is essential to have a good understanding of clinical and operational outcomes through the use of tools such as reports, tables, graphs, charts and predictive models. Finally, in this chapter, we will review one of the most often used tools, and often debated, clinical content and decision-support tools.

Chapter 3 · Clinical Informatics · Lesson 2 of 7

Basic Clinical Vocabulary: Prefixes, Routes, Abbreviations and Specialties

Big picture

This section supplies the clinical language an informaticist has to read fluently: word roots, medication routes, chart abbreviations and the medical specialties. It follows the definition of the field because everything later in the chapter, from order sets to metrics, is written in this vocabulary. The larger problem it solves is that informatics work is mostly reading other people's documentation, and a misread abbreviation in a build is a safety event. The routes and the frequency abbreviations are the two families that trap readers, since both are short, similar in shape and carry dosing consequences.

Walkthrough

Clinical terminology prefixes

Brachi/o refers to the arm.
Lapar/o refers to the abdomen, loin or flank.
Cardi/o refers to the heart, and my/o to muscle.
Cyt/o refers to the cell, and neur/o to nerve.
Derm/a, derm/o and dermat/o refer to the skin.
Ocul/o and ophthalm/o refer to the eye and eyes.
Encephal/o refers to the brain.
Gastr/o refers to the stomach, or/o to the mouth, and intestin/o to the intestine.
Hemat/o refers to blood, ot/o to the ear, and pulmon/o to the lungs.

Two pairs are worth separating deliberately: eye has two roots, ocul/o and ophthalm/o, while ot/o is ear, not eye, despite the similar shape in print.

Question:

Reconstruct the prefix list, giving the body part for each root.
Which two roots both refer to the eye, and which similar-looking root does not?

Drug routes and classifications

Enteral routes include oral, sublingual and per rectum.
Parenteral covers injections, abbreviated SQ, IM, IV, IA, IT, IO and ID.
Inhalation delivers to the lungs through aerosols and steam.
Topical applies to the skin, by methods including instillation, irrigation and swabbing.
PO directs administration by mouth.

Question:

Name the four route classifications and the site or method each uses.
Which classification covers the injection abbreviations, and list them.

Frequently used clinical abbreviations

Frequency: QID is four times a day, TID three times a day, BID twice a day, Q2h every two hours, Q6h every six hours, QOD every other day.
Timing: AC before meals, HS at bedtime, AM morning, PM evening, PRN as needed, STAT immediately.
Status and history: CC chief complaint, PMH past medical history, Hx history, NKDA no known drug allergies, WNL within normal limits, NPO nothing by mouth.
Orders: DC discontinue, Disp dispense, Rx prescription, Supp suppository.
Anatomy pairs: AD right ear, AS left ear, AU both ears; OD right eye, OS left eye, OU both eyes.
Units: L liter, mL milliliter, mm millimeter, cm centimeter, mEq/L milliequivalent per liter, microgram, gram, grain, ounce.
Routes and vitals: SL sublingual, SQ subcutaneous, ID intradermal, IM intramuscular, IV intravenous, IN intranasal, BP blood pressure, HR heart rate, T temperature, BMI body mass index, BS blood sugar.

Example

A build that maps HS to hour of sleep on one screen and to a shift start elsewhere produces two different administration times from one order. The abbreviation is the specification, so the mapping has to be exact.

Question:

Give the ear and eye abbreviation sets and what each member means.
Distinguish QID, QOD and Q6h.
Define CC, PMH, NKDA, WNL and NPO.

Medical specialties

Allergy and immunology treats allergies; anesthesiology covers sedation and anesthesia.
Cardiology treats the cardiovascular system; dermatology the integumentary system.
Endocrinology treats the endocrine system, including diseases such as diabetes and thyroid issues.
Family physicians and internal medicine physicians are both primary care providers.
Internal medicine treats adults and encompasses subspecialties such as cardiology, while family medicine spans all ages.
Gastroenterology treats the digestive system; infectious disease treats infections.
Neurology treats the neurologic system; oncology manages cancer.
Pediatrics covers pediatric care from infancy through age 18; obstetrics and gynecology covers women's health.
Otolaryngology covers ears, nose and throat; psychiatry covers mental and behavioral healthcare.
Radiology covers imaging; surgery covers surgical care, with general or specialized providers responsible for preoperative planning, the surgery, postoperative needs and complications.

Question:

Distinguish internal medicine from family medicine.
Match otolaryngology, dermatology and endocrinology to their body systems.
What age range does pediatrics typically cover?

Memory tips

Root confusions worth drilling: ot/o is ear; ocul/o and ophthalm/o are eye; or/o is mouth; encephal/o is brain and neur/o is nerve.
Route classification four: Enteral, Parenteral, Inhalation, Topical. Enteral goes through the gut, parenteral goes around it.
Laterality letters: A is auris, the ear, so AD, AS, AU are ears; O is oculus, the eye, so OD, OS, OU are eyes. D is right, S is left, U is both.
Frequency ladder: QD once, BID twice, TID three, QID four. Q with a number is by the clock; QOD is every other day.
Primary care pair: internal medicine treats adults and carries subspecialties, family medicine treats all ages.

Key concepts

Clinical prefixes: the word roots listed in the guide, including brachi/o arm, lapar/o abdomen, cardi/o heart, my/o muscle, cyt/o cell, neur/o nerve, derm skin, ocul/o and ophthalm/o eye, encephal/o brain, gastr/o stomach, or/o mouth, hemat/o blood, ot/o ear, intestin/o intestine and pulmon/o lungs
Drug route classifications: enteral by oral, sublingual or rectal route; parenteral by injection; inhalation to the lungs; and topical to the skin
Frequency abbreviations: BID, TID, QID, Q2h, Q6h, QOD and PRN as the guide defines them
Laterality abbreviations: AD, AS and AU for right, left and both ears; OD, OS and OU for right, left and both eyes
Chart abbreviations: CC chief complaint, PMH past medical history, NKDA no known drug allergies, WNL within normal limits, NPO nothing by mouth, DC discontinue and STAT immediately
Primary care specialties: family medicine covering all ages and internal medicine covering adults with subspecialties such as cardiology
Specialty to system: cardiology cardiovascular, dermatology integumentary, endocrinology endocrine, gastroenterology digestive, neurology neurologic, otolaryngology ears nose and throat, radiology imaging, oncology cancer management

Practice questions

34 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the clinical prefix table and each root's meaning · the four drug route classifications with their sites, methods and abbreviations · the clinical abbreviation table covering frequency, timing, history, orders, laterality, units, routes and vitals · the medical specialty table including the internal medicine and family medicine distinction and the pediatric age range.

Read the original source

In this chapter, we will take a deeper dive into the world for clinical informatics. Starting with the basics, we will review the language and definitions commonly used in healthcare. We will also examine clinical metrics frequently represented in informatics such as average daily census, turnaround time, adherence and barcode medication administration. To evaluate these metrics, often informaticists will need to use various analytical tools. It is essential to have a good understanding of clinical and operational outcomes through the use of tools such as reports, tables, graphs, charts and predictive models. Finally, in this chapter, we will review one of the most often used tools, and often debated, clinical content and decision-support tools.

Table 3.2 Frequently Used Clinical Terminology Prefixes11, 12

Brachi/o

Arm

Lapar/o

Abdomen, loin or flank

Cardi/o

Heart

My/o

Muscle

Cyt/o

Cell

Neur/o

Nerve

Derm/a, derm/o, dermat/o

Skin

Ocul/o

Eye

Encephal/o

Brain

Ophthalm/o

Eyes

Gastr/o

Stomach

Or/o

Mouth

Hemat/o

Blood

Ot/o

Ear

Intestin/o

Intestine

Pulmon/o

Lungs

Table 3.3 Common Drug Routes and Abbreviations13

Classification

Drug Routes

Common Abbreviations

Enteral

Oral

PO

Sublingual

SL

Per rectum

PR

Parenteral

Injections

SQ, IM, IV, IA, IT, IO, ID

Inhalation

Lungs

Aerosols, steam

Topical

Skin

Enepidermic, epidermic, insufflation, instillation, irrigation, swabbing

Table 3.4 Medical Specialties14

Allergy and Immunology

Allergies

A provider that specialized in diagnosis and treatment of allergies, including allergy testing, medications

Anesthesiology

Sedation/anesthesia

Specializes in anesthesia, sedation and airway management. Typically seen in the operating room working with the patient during their surgery

Cardiology

Cardiovascular system

The provider treats heart and blood vessel issues and disease processes

Dermatology

Integumentary system

The provider delivers care from aesthetics (e.g., laser treatments) to rashes, skin cancers and other skin issues

Endocrinology

Endocrine system

Diseases such as diabetes and thyroid issues

Family Physician

Primary care provider

Providers deliver basic care (typically nonspecialized) for patients across all spectrums (genders and ages)

Gastroenterology

Digestive system

Providers works around the esophagus, stomach, intestinal issues including reflux, gallbladder, colitis, etc.

Infectious Disease

Infections

Difficult to diagnose or treat, such as tuberculosis, Zika, or Dengue

Internal Medicine

Primary care provider

Specialized providers that encompass sub-specialties such as cardiology or endocrinology

Neurology

Neurologic system

Works with spinal issues, brain, nerves. Some examples include Parkinson's and neuropathies

Pediatrics

Pediatric care

The care is given to younger patients, typically infancy through age 18. This includes well-checks, immunizations, physicals, etc.

Oncology

Cancer management

Providers care for cancer, side-effects of treatment, clinical trials and end-of-life care

Obstetrics/Gynecology

Women's health

Reproductive care, preventive care (annual pap exams, mammograms), pregnancy, menopause, contraception and infertility

Otolaryngology

Ears, nose and throat

Most often, ENTs are also surgeons that cover areas from sinus issues, neck cancers, etc.

Psychiatry

Mental and behavioral healthcare

Providers work with patient counseling, psychotherapy, analysis, hospitalization and medications

Radiology

Imaging

A physician trained at interpreting diagnostic exams/testing

Surgery

Surgical care

General or specialized surgical providers. Responsible for planning pre-operative needs, the surgery, post-operative needs, as well as any complications that may arise (e.g., orthopedics, general, bariatrics, etc.)

able 3.5 Frequently Used Clinical Abbreviations13

Abbreviation

Definition

Abbreviation

Definition

AM

Morning

L

Liter

AC

Before meals

LMP

Last menstrual period

AD

Right ear

MCG

microgram

Ad lib

Freely

mEq/L

Milliequivalent per liter

Amp

Ampule

mL

Milliliter

Ante

Before

Mm

Millimeter

AS

Left ear

N/V

Nausea and vomiting

ASA

Aspirin

NKDA

No known drug allergies

AU

Both ears

NPO

Nothing by mouth

BID

Twice a day

OD

Right eye

BMI

Body mass index

OS

Left eye

BP

Blood pressure

OU

Both eyes

BS

Blood sugar

oz

Ounce

CC

Chief complaint

PRN

As needed

Cap

Capsule

PM

Evening

CM

Centimeter

PMH

Past medical history

CXR

Chest x-ray

Q

Every

DC

Discontinue

Q2h

Every two hours

Disp

Dispense

Q6h

Every six hours

ER/EC/ED

Emergency room

Qam

Every morning

G

Gram

Qpm

Every night

Gr

Grain

QID

Four times a day

HR

Hour

QOD

Every other day

H/O

History of

Rx

Prescription

HR

Heart rate

SL

Sublingual

HS

At bedtime

SQ

Subcutaneous

HX

History

STAT

Immediately

ID

Intradermal

Supp

Suppository

IM

Intramuscular

T

Temperature

IN

Intranasal

TID

Three times a day

INJ

Injection

w/o

Without

IV

Intravenous

WNL

Within normal limits

able 3.6 Frequently Used Healthcare Information Technology Vocabulary15–19

Chapter 3 · Clinical Informatics · Lesson 3 of 7

Basic Healthcare IT Vocabulary and Terms

Big picture

This section is the guide's glossary of the acronyms an informaticist meets in policy, coding and standards conversations. It follows clinical vocabulary because the two languages meet in the record: clinical terms describe the patient, these terms describe the systems and programs that pay for and regulate the care. The larger problem it solves is that most exam distractors in this domain are real terms attached to the wrong definition. The standards cluster is where that happens most, so hold each acronym with its owner and its object.

Walkthrough

Law, payment and organization terms

The Affordable Care Act is the comprehensive U.S. healthcare reform law enacted in March 2010.
An accountable care organization is a group of providers giving coordinated care and chronic disease management, thereby improving quality of care.
A federally qualified health center is a federally funded nonprofit health center or clinic serving medically underserved areas and populations.
HIPAA is the U.S. law providing privacy standards to protect medical records and other health information given to health plans, doctors, hospitals and other providers.
The Merit-Based Incentive Payment System ties payments to quality and cost-efficient care, drives improvement in care processes and health outcomes, increases use of healthcare information and reduces the cost of care.
HITECH, enacted with the American Recovery and Reinvestment Act, provided the incentives that kick-started certified EHR adoption.
CMS introduced Meaningful Use, later succeeded by the Promoting Interoperability Program.
Certified EHR technology is required to meet the requirements of that program.

Question:

Define ACO, FQHC and MIPS in the source's terms.
Trace the U.S. incentive chain from ARRA and HITECH to certified EHR technology and Promoting Interoperability.

Coding and terminology standards

CPT codes are used for the billing of medical procedures.
ICD-10 classifies and codes all diagnoses, symptoms and procedures recorded in conjunction with hospital care in the United States.
LOINC is the coding system for electronic exchange of laboratory test results and other observations.
LOINC development involved a public-private partnership of several federal agencies, academia and the vendor community, a model applicable to other standards-setting domains.
SNOMED CT was created from the combination of SNOMED RT, the reference terminology, and the Read codes.
The Unified Medical Language System was developed by the National Library of Medicine to unify disparate medical vocabularies and facilitate sharing medical knowledge across information systems.

Each of these answers a different question: what was billed, what was diagnosed, what was observed, what the clinical concept is, and how vocabularies map to each other.

Question:

Match CPT, ICD-10, LOINC, SNOMED CT and UMLS to what each codes or does.
What two sources were combined to create SNOMED CT, and who developed UMLS?

Technical standards and methods

HL7 is an ANSI-accredited nonprofit standards-developing organization creating methods for interoperability of healthcare data interchange, focused on clinical and administrative data.
DICOM was developed for the transmission of images and is used internationally for picture archiving and communication systems.
Natural language processing is a branch of artificial intelligence helping computers understand, interpret and manipulate human language.
NLP draws on computer science and computational linguistics to fill the gap between human communication and computer understanding.

Question:

Describe HL7 as an organization rather than as a message format.
Define natural language processing and name the disciplines it draws on.

Memory tips

Coding split: CPT bills procedures, ICD-10 codes diagnoses, LOINC codes lab observations, SNOMED CT names clinical concepts, UMLS maps vocabularies to each other.
Origins to remember: SNOMED CT equals SNOMED RT plus Read codes; UMLS comes from the National Library of Medicine; LOINC came from a public-private partnership.
Program chain: ARRA carried HITECH, HITECH funded Meaningful Use, Meaningful Use became Promoting Interoperability, and both require certified EHR technology.
HL7 is an organization that is ANSI-accredited; DICOM is a standard for images and underpins PACS.

Key concepts

Affordable Care Act: the comprehensive U.S. healthcare reform law enacted in March 2010
Accountable care organization: a group of providers delivering coordinated care and chronic disease management to improve quality
Federally qualified health center: a federally funded nonprofit center or clinic serving medically underserved areas and populations
HIPAA: the U.S. law providing privacy standards protecting medical records and health information held by plans and providers
MIPS: the payment system tying payment to quality and cost-efficient care, care process and outcome improvement, information use and cost reduction
HITECH and Promoting Interoperability: the ARRA-enacted incentives that kick-started certified EHR adoption, and the successor to Meaningful Use requiring certified EHR technology
CPT: codes used for billing medical procedures
ICD-10: the system classifying and coding diagnoses, symptoms and procedures in U.S. hospital care
LOINC: the coding system for electronic exchange of laboratory results and other observations, developed through a public-private partnership
SNOMED CT: the clinical terminology created by combining SNOMED RT with the Read codes
UMLS: the National Library of Medicine system unifying disparate medical vocabularies for knowledge sharing across systems
HL7: the ANSI-accredited nonprofit standards-developing organization creating interoperability methods for clinical and administrative data
DICOM: the standard developed for image transmission and used internationally for PACS
Natural language processing: the branch of artificial intelligence, drawing on computer science and computational linguistics, that helps computers understand, interpret and manipulate human language

Practice questions

23 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the guide's healthcare IT vocabulary table · ACA enactment date · ACO definition · CPT purpose · DICOM origin and PACS use · FQHC definition · HIPAA scope · HL7 accreditation and focus · ICD-10 scope · LOINC purpose and partnership model · MIPS objectives · NLP definition and contributing disciplines · SNOMED CT composition · UMLS developer and purpose · HITECH incentives, CEHRT requirement and the Promoting Interoperability succession.

Read the original source

Affordable Care Act (ACA)

The comprehensive healthcare reform law in the United States enacted in March 2010, also known as “Obamacare”

Accountable Care Organization (ACO)

A group of healthcare providers who give coordinated care, chronic disease management and thereby improve the quality of care patients receive

Current Procedural Terminology (CPT®)

These codes are used for the billing of medical procedures

Digital Imaging and Communication in Medicine (DICOM®)

The Digital Imaging and Communications in Medicine (DICOM) Standard was developed for the transmission of images and is used internationally for Picture Archiving and Communication Systems (PACS)

Federally Qualified Health Center (FQHC)

Federally funded nonprofit health centers or clinics that serve medically underserved areas and populations

Health Information Portability and Accountability Act (HIPAA)

U.S. law designed to provide privacy standards to protect patients’ medical records and other health information provided to health plans, doctors, hospitals and other healthcare providers

Health Level Seven (HL7)

ANSI-accredited, a nonprofit, standard-developing organization that creates methods for interoperability of healthcare data interchange. It focuses on clinical and administrative data

Tenth revision of the International Statistical Classification of Diseases and Related Health Problems (ICD-10)

ICD-10 is a system used by physicians and other healthcare providers to classify and code all diagnoses, symptoms and procedures recorded in conjunction with hospital care in the United States

Logical Observation Identifiers Names and Codes (LOINC®)

Coding system for the electronic exchange of laboratory test results and other observations. LOINC development involved a public-private partnership comprised of several federal agencies, academia and the vendor community. This model can be applied to other standards setting domains

Merit-Based Incentive Payment System (MIPS) (U.S. based)

MIPS was designed to tie payments to quality and cost-efficient care, drive improvement in care processes and health outcomes, increase the use of healthcare information and reduce the cost of care

Natural Language Processing (NLP)

Natural language processing (NLP) is a branch of artificial intelligence that helps computers understand, interpret and manipulate human language. NLP draws from many disciplines, including computer science and computational linguistics, in its pursuit to fill the gap between human communication and computer understanding

Systematized Nomenclature of Medicine-Clinical Terms (SNOMED CT®)

SNOMED-CT (Clinical Terminology) has been created from the combination of SNOMED-RT (Reference Terminology) and Read codes

Unified Medical Language System (UMLS®)

Developed by the National Library of Medicine in an attempt to unify disparate medical vocabularies and facilitate sharing medical knowledge across information systems

Basic Information Technology Vocabulary and Terms

Chapter 3 · Clinical Informatics · Lesson 4 of 7

Common Clinical Metrics in Informatics

Big picture

This section explains where clinical measurement came from, which U.S. laws accelerated it, and which agencies now define the measures. It sits between the vocabulary lessons and the decision support material because measures are what decision support is usually built to move. The larger problem it solves is that reporting drives money, through incentives or penalties, so measure definitions become build requirements. NQF and AHRQ are the pair to separate: one endorses and aligns measures, the other funds research and develops quality indicators and care models.

Walkthrough

Origins and the legislative push

Clinical metrics are credited to the 1999 Institute of Medicine publication To Err is Human.
The report exposed problems responsible for significant financial loss and loss of life.
Since the report there has been a surge in methods to hold down cost, provide accessible healthcare and improve patient safety.
In the United States, ARRA, the accompanying HITECH Act and the Patient Protection and Affordable Care Act reinforced the goal of decreasing government healthcare spending while improving patient safety.
Those laws and the CMS introduction of Meaningful Use created a rapidly changing landscape for clinical informatics.
Adoption was slow at best before these laws; HITECH incentives kick-started a landslide of certified EHR implementation.

Question:

Which publication is credited with launching clinical metrics, and in what year?
Name the laws and program the source credits with accelerating certified EHR adoption.

Electronic clinical quality measures

CMS expectations for electronic clinical quality measures have varied since 2009.
eCQMs measure and track several aspects of healthcare.
Reporting involves eligible providers, eligible hospitals, dual-eligible hospitals and critical access hospitals.
The current approach uses the 2015 version of certified EHR technology to meet the Promoting Interoperability Program requirements.
CMS updates eCQMs each year for evidence-based medicine, code sets and measure logic.
The six measurement goals are patient and family engagement, patient safety, care coordination, population and public health, efficient use of healthcare resources, and clinical process and effectiveness.

The six goals are a complete named set and a favorite EXCEPT stem, so a plausible but unlisted domain such as certification status is the usual wrong answer.

Question:

Name all six eCQM measurement goals.
Who reports eCQMs, and what gets updated each year?

The quality agencies and their tools

The National Quality Forum supports improving national health by setting national standards.
It recommends measures for use in payment and public reporting programs.
It identifies quality improvement priorities, advances electronic measurement and provides information and tools for healthcare decision-makers.
NQF tools include the Graphics Library, the Alignment Tool, the Health IT Knowledge Base, My Dashboard, the Action Registry and the Field Guide to NQF Resources.
AHRQ is a U.S. government agency within the Department of Health and Human Services.
Its primary mission is to support research and produce evidence for the improvement of quality healthcare.
It developed quality indicators to determine healthcare standards and whether providers are meeting them.
Its goals include keeping patients safe, helping providers improve quality and developing data to track changes in the healthcare system.

AHRQ areas of focus

Project ECHO trains and supports primary care clinicians in rural communities to provide specialized care, expanding from hepatitis C into mental health, substance abuse and HIV, and adopted by the Veterans Health Administration.
Re-Engineered Discharge is a structured protocol and suite of implementation tools helping hospitals rework discharge processes by determining patient needs and carefully designing and communicating discharge plans.
Hospitals using RED tools have seen a 30 percent reduction in hospital readmissions and emergency room visits.
Three Centers of Excellence were funded to study how high-performing health systems promote evidence-based practices in delivering care.

Metrics such as average daily census, cervical cancer screening and diabetic eye exams require thorough investigation of requirements plus current and future state workflow assessments to determine how they can be met within certified EHR technology.
Reporting to government agencies for reimbursement incentives or penalty avoidance often becomes the primary goal.
Workflow and ease of usability also need consideration when asking clinicians to help meet metrics, which is where CDS systems are brought in.

Average daily census measures inpatient volume per day.
Turnaround time measures elapsed time for a process such as a lab result.
Adherence measures compliance against a defined protocol or regimen.
Barcode medication administration scan compliance measures how often the safety check was performed.

Example

An 80 percent barcode scan compliance rate says one in five administrations bypassed the check. It does not say errors occurred, which is why the metric is a process measure rather than an outcome measure.

Question:

Contrast the roles of NQF and AHRQ.
Name the three AHRQ areas of focus and the result attributed to Re-Engineered Discharge.
Define average daily census, turnaround time, adherence and barcode scan compliance.

Memory tips

Origin anchor: To Err is Human, IOM, 1999. One report, one year.
Six eCQM goals: Engagement, Safety, Care coordination, Population and public health, Efficient resource use, Clinical process and effectiveness.
Agency split: NQF sets and aligns measures for payment and public reporting; AHRQ funds research, builds quality indicators and runs care models.
AHRQ three programs: Project ECHO for rural specialty support, RED for discharge redesign at a 30 percent readmission and ED reduction, and three Centers of Excellence.
Process versus outcome: scan compliance and adherence are process measures; readmission and infection rates are outcome measures.

Key concepts

To Err is Human: the 1999 Institute of Medicine report credited with launching clinical metrics by exposing financial and human losses in the system
HITECH incentives: the ARRA-enacted funding that kick-started certified EHR implementation after slow adoption
Electronic clinical quality measures: CMS measures reported by eligible providers, eligible and dual-eligible hospitals and critical access hospitals, updated annually for evidence, code sets and measure logic
eCQM measurement goals: patient and family engagement, patient safety, care coordination, population and public health, efficient use of healthcare resources, and clinical process and effectiveness
National Quality Forum: the agency setting national standards, recommending measures for payment and public reporting, identifying QI priorities, advancing electronic measurement and providing decision-maker tools
AHRQ: the DHHS agency supporting research and evidence for quality improvement and developing quality indicators
Project ECHO: the AHRQ-funded model training rural primary care clinicians to deliver specialized care, adopted by the Veterans Health Administration
Re-Engineered Discharge: the structured discharge protocol and toolset associated with about a 30 percent reduction in readmissions and emergency room visits
Common clinical metrics: average daily census, turnaround time, adherence and barcode medication administration scan compliance

Practice questions

19 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: To Err is Human and the birth of clinical metrics · ARRA, HITECH, the ACA and Meaningful Use · slow adoption before incentives · eCQM history, reporting entities, 2015 CEHRT and annual updates · the six measurement goals · NQF functions and tools · AHRQ mission, placement in DHHS, quality indicators and goals · Project ECHO, RED and its 30 percent result, and the Centers of Excellence · workflow assessment required to meet metrics in a CEHRT · reporting for incentives or penalty avoidance · usability considerations and the turn to CDS · the named clinical metrics.

Read the original source

Common Clinical Metrics in Informatics

Most clinical informatics professionals will credit the birth of clinical metrics with the 1999 publication by the Institute of Medicine (IOM), “To Err is Human.” This landmark report brought to light issues within the healthcare system that not only was responsible for significant financial loss but also loss of life.20 With the field of clinical informatics being vast in scope, certain areas set it apart from other types of IT. One is the focus of healthcare informaticists on the need for identification and adoption of clinical metrics. Since the IOM report, there has been a significant surge in the development of methods to help keep down cost, provide accessible healthcare, as well as significantly improve patient safety.

In the United States, the development of the American Reinvestment and Recovery Act (ARRA), the accompanying Health Information Technology for Economic and Clinical Health (HITECH) Act,21 and the Patient Protection and Affordable Care Act22 reinforced the shift in focus even more towards the goal of decreasing government spending on healthcare while also improving patient safety. These public laws, as well as the Centers for Medicare and Medicaid Services (CMS) introduction of Meaningful Use (MU), created a rapidly changing landscape for clinical informatics. Before the introduction of these laws, adoption was slow at best. But with the incentives provided by the HITECH Act, a landslide of implementation of certified electronic health records (CEHRTs) was kick-started.

CMS has had many variations since 2009, of the expectations of meeting their electronic clinical quality measures (eCQMs). These tools were designed to specifically aid in measuring and tracking several aspects of healthcare. The reporting of these measures revolved around working the eligible providers (EPs), eligible hospitals, dual-eligible hospitals and critical access hospitals (CAHs). Per CMS (2019), their current version of meeting the guidelines includes using the 2015 version of CEHRT to meet the requirements of the promoting interoperability program (PIP) (Tables 3.7, 3.8). Each year, CMS provides updates to the eCQMs. These consist of updates regarding evidence-based medicine, code sets and measure logic.23 The current measurement goals of eCQMs for both Medicare and Medicaid for 2019 include23:

Patient and Family Engagement

Patient Safety

Care Coordination

Population/Public Health

Efficient Use of Healthcare Resources

Clinical Process/Effectiveness

With these new standards of cost-saving and healthcare safety, there have been many organizations developed to aid in quality improvement. These groups accomplished this by setting forth guidelines and metrics for facilities and providers to integrate into their care of patients. The tools they provide aid clinical informaticists to develop and implement system functionality to optimize clinical effectiveness and efficiencies. There are many, but two of the more significant ones include the National Quality Forum (NQF) and the Agency for Healthcare Research and Quality (AHRQ).

The NQF is an agency that supports improving overall national health by several methods: setting national standards, recommendation of measure for use in payment and public reporting programs, identification of quality improvement (QI) priorities, advancement of electronic measurement and providing information and tools to help healthcare decision-makers.25 The tools provided by the NQF are especially helpful to healthcare providers when aiming to meet metrics and achieve both facility and personal goals. Table 3.9 provides a brief explanation of the tools provided.

able 3.9 National Quality Forum Tools26

NQF Graphics Library

Collection of downloadable graphics that can be used in your work

Alignment Tool

Helps you align, expand, or start your measurement and reporting efforts in ways that fit with key national programs

Health IT Knowledge Base

Provides answers to some of the most technical questions surrounding NQFs health IT and eMeasures initiatives

My Dashboard

Helps track what is happening at the NQF and lets you personalize your experience on the web

NQFs Action Registry

Online collaboration space designed to help people on the frontlines of making care sage connect with others, find new resources and help distribute proven ideas

Field Guide to NQF Resources

Dynamic, online resource designed to help those involved with measurement and public reporting more easily access basic information and NQF resources related to quality measurement

The AHRQ is a U.S. government agency that functions as part of the Department of Health & Human Services (DHHS). Its primary mission is to support research and produce evidence for the improvement of quality healthcare. To achieve this, they developed quality indicators to determine the standards of healthcare and if certain providers are meeting those standards.27 Examples of their goals are keeping patients safe, helping physicians and other healthcare providers improve quality, and develop data to track changes in the healthcare system (Table 3.10).

Table 3.10 Agency for Healthcare Research and Quality Areas of Focus27

Project ECHO (Extension for Community Healthcare Outcomes)

AHRQ funded an innovative model, Project ECHO, for training and supporting primary care clinicians in rural communities to provide specialized care for their patients. This model has flourished and expanded from its initial focus on hepatitis C into new clinical areas, including mental health and substance abuse and HIV. It has also been adopted by the Veterans Health Administration as a tool for expanding access to high-quality care for veterans across the country.

Re-Engineered Discharge (RED)

RED is a structured protocol and suite of implementation tools that help hospitals rework their discharge processes to reduce readmissions by determining patients’ needs and carefully designing and communicating discharge plans. Hospitals using these tools have seen a 30% reduction in hospital readmissions and emergency rooms visits.

Centers of Excellence

Three Centers of Excellence were funded to study how high-performing healthcare systems promote evidence-based practices in delivering care. The AHRQ project will help close this research gap and produce information that can be used by health systems throughout the United States to improve patient outcomes.

These metrics, such as average daily census, cervical cancer screening and diabetic eye exams, require a thorough investigation of the requirements as well as current and future state workflow assessments to ascertain how the metrics can be met within a CEHRT. The subsequent reporting on to government agencies for either reimbursement incentives or avoidance of penalties often becomes the primary goal. But workflow and ease of usability are factors that also need to be considered when asking providers and other healthcare professionals to aid in meeting these metrics. To accomplish this, often times the use of CDS systems will be brought into play.

Chapter 3 · Clinical Informatics · Lesson 5 of 7

Clinical Content, CPOE and the Case For and Against CDS

Big picture

This section defines clinical decision support, states what keeping its content current demands, and lays out the advantages and disadvantages the guide attributes to CDS and computerized order entry. It follows metrics because CDS is the usual instrument for moving a measure. The larger problem it solves is that evidence changes faster than builds do, so content that is not governed silently goes stale. Advantages and disadvantages here are two named lists, and the exam builds EXCEPT items by moving one item across the line.

Walkthrough

What CDS is and what keeping it current requires

CDS is defined as a category of concepts and methods designed to provide patient-specific clinical information to a healthcare provider at the point of care.
The ultimate goal is patient safety and improved patient experience, though CDS serves other purposes as well.
Establishing a robust and reliable process for developing best-practice maintenance of CDS is essential.
Translational research takes up to 17 years to make its way into clinical practice.
Medical knowledge is said to double approximately every 8 years.
Maintaining current, evidence-based clinical content is a challenge but is required for successful CDS use.
Skilled workflow assessment, governance and maintenance are described as a must.
Clinical informaticists and clinicians have influenced health IT since the late 1950s, from mathematical diagnostic models to present-day AI, APIs, SMART and FHIR.
Deming's line that a bad system will beat a good person every time is cited to argue that a poor design and build will fail regardless of governance or expertise.

The two numbers do the same work from opposite ends: evidence arrives slowly into practice while the volume of evidence grows quickly, which is the argument for governance rather than one-time build.

Question:

Give the definition of CDS and its ultimate goal.
State the 17-year and 8-year figures and explain what each one implies for content maintenance.
What conclusion does the source draw from the Deming quotation?

Advantages named for CPOE and CDS

Averting handwriting issues.
Meeting provider coding requirements.
Formulary recommendations.
Safer or lower cost care.
Economic savings.
Better billing turnaround.
Faster order transmission to lab, pharmacy and radiology.
Increased quality of care and enhanced health outcomes.
Avoidance of error and adverse events.
Improved efficiency, cost-benefit and provider and patient satisfaction.

Question:

Reconstruct the advantage list without looking.
Which advantages are clinical and which are financial or operational?

Disadvantages named for CPOE and CDS

Perceived as more work for clinicians.
Bad use of CDS through poor design and maintenance.
Duplicate alert and drop-down issues.
Never-ending system demands.
Hybridized paper and electronic workflows.
Constantly changing evidence and technology.
Overdependence on CDS.
Alarm and alert fatigue.
Clinician burnout and documentation burden.
Delegation of order entry to other clinicians.
Data integrity problems, including auto-population.
Design and implementation issues and lack of maintenance and governance.

Auto-population is listed as a disadvantage because it threatens data integrity: text that appears without being authored can be signed without being read.

Example

A sepsis alert that depends on vital signs fires late when vitals are charted at the end of a shift. The rule is correct and the timing of the data defeats it, which is a workflow failure rather than a logic failure.

Question:

Reconstruct the disadvantage list without looking.
Why is auto-population named as a disadvantage?
Explain how delayed documentation can defeat a correctly built alert.

Memory tips

CDS definition cue: patient-specific clinical information to a provider at the point of care. Patient-specific is the word that separates CDS from a reference library.
Two numbers: 17 years for translational research to reach practice, knowledge doubling about every 8 years.
Advantage grouping: handwriting, coding, formulary, speed to lab and pharmacy, billing turnaround, quality and outcomes, error avoidance, efficiency and satisfaction.
Disadvantage grouping: workload perception, alert fatigue and duplicates, burnout and documentation burden, hybrid paper workflows, data integrity and auto-population, delegation of order entry, overdependence, and design, maintenance and governance failures.
Deming line to recite: a bad system will beat a good person every time.

Key concepts

Clinical decision support: a category of concepts and methods designed to provide patient-specific clinical information to a healthcare provider at the point of care
Content currency: the requirement for maintained, evidence-based content, against a 17-year translational lag and knowledge doubling about every 8 years
CPOE and CDS advantages: averted handwriting issues, provider coding requirements, formulary recommendations, safer or lower cost care, economic savings, better billing turnaround, faster order transmission, quality and outcome gains, error and adverse event avoidance, and efficiency and satisfaction improvements
CPOE and CDS disadvantages: perceived added work, poor design and maintenance, duplicate alerts and drop-downs, never-ending system demands, hybrid paper and electronic workflows, changing evidence and technology, overdependence, alert fatigue, burnout and documentation burden, delegated order entry, data integrity and auto-population risks, and governance failures
Deming principle: the cited claim that a bad system will beat a good person every time, applied to design and build quality

Practice questions

21 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the CDS definition and its goal · the maintenance process requirement · the 17-year translational figure and knowledge doubling · workflow assessment, governance and maintenance · the history from the late 1950s to AI, APIs, SMART and FHIR · the Deming quotation and its argument · the complete advantage list · the complete disadvantage list including auto-population and data integrity.

Read the original source

Clinical Content and Decision Support Tools

Clinical informaticists and clinicians in general, have been making a significant impact in HIT since the late 1950s. Since then, there has been the development of mathematical models used to aid providers in diagnosing various medical conditions28 to the present-day use of AI, application programming interfaces (APIs), substitutable medical applications reusable technologies (SMART), the fast healthcare interoperability resources (FHIR®), or a combination of several of these such as SMART on FHIR.

CDS is defined as “a category of concepts and methods designed to provide patient-specific clinical information to a healthcare provider at the point of care.”29 The ultimate goal in the use of CDS is, of course, patient safety and improved patient experience. But, it can also serve other purposes. Establishing a robust and reliable process for developing best-practice maintenance of a CDS is paramount. Good build design and implementation can not only provide better patient outcomes but improved overall quality, reduced cost, improved documentation consistency and reliability, as well as an enhanced clinician experience. This is where clinical informaticists are paramount. They have the skills to translate workflow into the CDS design and build. Clinical informaticists have the ability to better communicate and understand all the challenges that clinicians face and that come along with new CDS, new implementation of any kind, within an electronic health record, “acceptance and adoption of CDS is critical for successful implementation.”4 CDS is typically implemented within an EHR, in the form of order sets, condition-specific clinical alerts, access to reference information (also known as info buttons) and passive/active generalized alerts. But, it can also be seen in use with patient portals, health information exchanges (HIEs), mobile applications and other HIT systems.

Considering it takes up to 17 years for translational research to make its way into clinical practice, maintaining current, evidence-based clinical content can be a challenge but is required for any successful use of CDS in the healthcare setting.30 To maintain this rapidly changing use of not only technology, but medicine as well, skilled workflow assessments, governance and maintenance is a must. According to Butterfield, “medical knowledge doubles approximately every eight years, so a physician's knowledge base is outdated very quickly after graduation from medical school. Keeping up with current knowledge by reading journal articles is impractical due to the volume of material and lack of time for reading it.”31

To quote Dr. W. Edwards Deming of The Deming Institute, “a bad system will beat a good person every time.” No matter the amount of governance management, or expert opinion of the project informaticist, if the design and build are “bad,” the implementation will fail. Here, we look as some of the advantages and disadvantages of CDS

able 3.11 Advantages and Disadvantages of Computerized Provider Order Entry33

Advantages

Disadvantages

Averting handwriting issues

Perceived as more work for clinicians

Drug/drug, drug/food, drug/allergy alerts

Provider coding requirements

Formulary recommendations

Bad use of CDS; design, maintenance

Safer or lower cost

Duplicate alert drop-down issue

Economic savings

Never-ending system demands

Better billing turn around

Hybridized paper/electronic workflows

Faster order transmission to lab/pharmacy/radiology

Constantly changing evidence and technology

Overdependence on CDS

Advantages of CDS:

Increased quality of care and enhanced health outcomes

Avoidance of error and adverse events

Improved efficiency, cost–benefit and provider and patient satisfaction

Computerized practitioner order entry

Disadvantages of CDS:

Alarm/alert fatigue

Clinical burnout, documentation burden

Delegation of order entry to other clinicians

Data integrity

Auto-population

Design and implementation issues

Lack of maintenance and governance

According to Bresnick, “CDS tools are designed to help sift through enormous amounts of digital data to suggest next steps for treatments, alert providers to available information they may not have seen, or catch potential problems…. ”34

Osheroff et al. recommends a five-rights framework for CDS that has been adopted and promoted as best practice by the AHRQ35 (Figure 3.2). There is also a need for increased usability. This relates directly to CPOE. The less a physician or advanced practice provider (APP) uses the order systems as designed, the less impactful CDS is. It will be alerting in the face of the incorrect people. So, our providers have to be well trained, well informed and satisfied with the usability of the system.

Chapter 3 · Clinical Informatics · Lesson 6 of 7

The Five Rights of CDS

Big picture

This section presents the framework the guide adopts for designing a decision support intervention. It follows the advantages and disadvantages because the five rights are the answer to most of the disadvantages just listed. The larger problem it solves is that a correct piece of evidence delivered to the wrong person, in the wrong form or at the wrong moment produces noise rather than safety. The rights most often confused are format and channel: format is what the intervention looks like, channel is what carries it.

Walkthrough

The framework and its five rights

The right information: evidence-based, recognized guidelines, actionable and not too much information.
The right person: the right decision-makers involved, the end users and healthcare team included, and a check that the person seeing it is qualified to use it.
The right intervention format: alerts that are passive or actionable, order sets, infobuttons and forms.
The right channel: EHRs, CPOE, HIEs and patient portals.
The right time in the workflow: determined by workflow analysis, closing the loop on when the CDS should be presented.

Osheroff and colleagues recommend the five rights framework, which AHRQ has adopted and promoted as best practice. The rights are a design checklist, so a failed intervention usually violates a specific one rather than being wrong in general.

Question:

Name the five rights in order and give the source's content for each.
Distinguish the right format from the right channel with an example of each.

Usability, CPOE and the future of CDS

There is a need for increased usability, relating directly to CPOE.
The less a physician or advanced practice provider uses the order system as designed, the less impactful CDS becomes.
Poorly targeted CDS alerts in front of the wrong people.
CDS tools are designed to sift through enormous amounts of digital data to suggest next steps for treatment, alert providers to information they may not have seen, and catch potential problems.
CDS increasingly leverages machine learning and artificial intelligence to power analytics.
Machine learning algorithms can ingest large quantities of data, identify patterns and return detailed results to users.

Example

Two clinicians receive the same interaction warning: the prescriber who can change the order, and a nurse who cannot. Sending it to both trains one of them to dismiss alerts, which is the right person failing rather than the rule.

Question:

Explain the link the source draws between order system usability and CDS impact.
What three things does the source say CDS tools are designed to do?

Memory tips

Five rights in order: Information, Person, Format, Channel, Time. Read as I-P-F-C-T and check each one when an intervention misfires.
Format versus channel: format is alert, order set, infobutton or form; channel is EHR, CPOE, HIE or patient portal.
Right person test: is the recipient qualified and able to act on it? If not, the alert is noise.
Right time is set by workflow analysis, not by convenience of the build.
Framework attribution: Osheroff and colleagues, adopted and promoted by AHRQ.

Key concepts

Five rights of CDS: delivering the right information to the right person in the right intervention format through the right channel at the right time in the workflow
Right information: evidence-based, recognized guidelines that are actionable and not excessive
Right person: the qualified decision-maker, with end users and the healthcare team involved
Right format: the intervention shape, including passive or actionable alerts, order sets, infobuttons and forms
Right channel: the delivery path, including the EHR, CPOE, health information exchanges and patient portals
Right time: the point in the workflow determined by workflow analysis, closing the loop
Machine learning in CDS: the capability to ingest large data quantities, identify patterns and return detailed results to users

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the five rights framework, its authors and AHRQ adoption · the content of each right as tabulated · usability and its link to CPOE use · the consequence of providers not using the order system as designed · the described purposes of CDS tools · machine learning and artificial intelligence in CDS.

Read the original source

The five rights include (Table 3.12)37:

Table 3.12 Explanation of the Five Rights of CDS36

Right Information

Right Person

Right Format

Right Channel

Right Time

Have the right decision-makers involved

Include the end-users and the healthcare team

Alerts; passive or actionable?

EHRs

When should the CDS be presented in the workflow?

Evidence-based, recognized guidelines

Determine who needs to actually see the CDS

Order sets, HIEs, patient portals

CPOE

Workflow analysis

Actionable, not too much information

Is the person seeing it qualified to use it?

Infobuttons

Forms, etc.

Close the loop

The right information

To the right person

In the right intervention format

Through the right channel

At the right time in the workflow

Ultimately, CDS is not going anywhere, anytime soon, “CDS tools are increasingly leveraging machine learning and artificial intelligence to sophisticated power analytics. Machine learning algorithms can ingest large quantities of data, identify patterns, and return detailed results to users.”34

Chapter 3 · Clinical Informatics · Lesson 7 of 7

Outcomes and Data Analytics Tools

Big picture

This closing section covers what to do with clinical data: the difference between clinical and operational outcomes, how outcomes should be written, what threatens data integrity and which analytic tools the guide names. It ends the chapter because everything before it produces the data this section interrogates. The larger problem it solves is that analysis presented without inspection can be confidently wrong. Clinical and operational outcomes are the pair to hold apart: one measures change in health, the other measures improvement in a facility's processes or services.

Walkthrough

Clinical and operational outcomes

Clinical outcomes relate to specific changes in health or health quality as a result of the care a patient received.
They are measurable and evaluated through activity metrics such as hospital readmission rates or catheter-associated urinary tract infections.
Operational outcomes are specific and measurable statements about improvements a facility would like to make to its processes or services.
Each operational outcome should flow directly from a more general goal of the unit.
Outcomes should be SMART: specific, measurable, attainable, realistic and timely.

Example

Cutting chart completion from five days to two is operational: it is a process target flowing from a unit goal. A fall in catheter-associated infections is clinical: it is a change in patient health.

Question:

Distinguish clinical from operational outcomes and give the source's example of each.
Expand SMART and explain what each letter demands of an outcome statement.

Knowing your data and protecting its integrity

The process starts with learning about the data, manipulating it, creating information from it and distributing knowledge and wisdom to others.
Determine the data type first: nominal, ordinal, interval or ratio.
Ask what rows and columns the data set reflects and how the data are structured.
Ask whether data are visibly missing in the file and whether they appear sorted in some order.
Data integrity problems are common in healthcare, affecting accuracy or validity over the data lifecycle.
Named causes include wrong patient data.
Height and weight inaccuracies that affect drug calculations.
Allergy and medication documentation inaccuracies or omissions.
Fat finger errors, meaning physically typing or entering the wrong data.
Overall missing data from forgetting, time constraints or fraudulent documentation.
Inspecting data before presenting it is the stated conclusion.

Question:

Name the four data types to identify before analysis.
List the named causes of data integrity problems.
What four questions does the source suggest asking when first exploring a data set?

Common data analytics tools

Tool	Purpose
Fields	a vertical column holding one kind of data, such as first name, last name or date of birth
Records	all of the fields belonging to one row, meaning one entity
Tables	all records together, the combination of fields and records
Reports	an alternate view of data, typically assembled from a query and generally distributed on paper or electronically
Query	the process of selecting desired records, meaning pulling the data
Graphs and charts	tools for examining and presenting data, including scatter plots, pie charts, bar charts and flowcharts
Control charts	tools for looking at a process over time, showing common and special-cause variation with upper and lower control limits
Predictive modeling	using history to project forward, such as pulling five years of financial data to predict next year's budget needs

Recognizing clinical and operational outcomes through these tools is a necessary skill for any clinical or healthcare informatics specialist.
The variables an analysis is designed to explain are the dependent variables, which respond to independent variables.
The future of the field is shaped by big data, project management, evidence-based CDS and mobile technology.

The control chart is the tool that answers whether a change is signal or noise, which is why a point outside a control limit is read as special-cause variation rather than as a bad month.

Question:

Define field, record, table, report and query in the source's terms.
What does a control chart show, and how is a point outside the upper control limit read?
Give the source's example of predictive modeling.

Memory tips

Outcome split: clinical measures health change, operational measures process or service improvement flowing from a unit goal.
SMART: Specific, Measurable, Attainable, Realistic, Timely.
Data types four: nominal, ordinal, interval, ratio. Identify the type before choosing the analysis.
Database ladder: fields are columns, records are rows, tables are all records together, queries select records, reports present the result.
Chart choice: control chart for a process over time, scatter plot for relationships between two variables, predictive model for projection from history.
Integrity causes five: wrong patient, height and weight errors, allergy and medication omissions, typing errors, missing data from forgetting, time pressure or fraud.

Key concepts

Clinical outcomes: measurable changes in health or health quality resulting from care received, evaluated through metrics such as readmission rates or catheter-associated urinary tract infections
Operational outcomes: specific and measurable statements about improvements to a facility's processes or services, each flowing from a general unit goal
SMART outcomes: outcomes that are specific, measurable, attainable, realistic and timely
Data types: nominal, ordinal, interval and ratio, identified before analysis
Data integrity causes: wrong patient data, height and weight inaccuracies affecting drug calculations, allergy and medication omissions, typing errors and missing data from forgetting, time constraints or fraudulent documentation
Fields, records and tables: columns holding one kind of data, rows holding one entity's data, and the combination of all records and fields
Query and report: the selection of desired records and the alternate view of data typically assembled from that selection
Control chart: the tool for examining a process over time using common and special-cause variation with upper and lower control limits
Predictive modeling: projection from historical data, such as using five years of financial data to predict next year's budget
Dependent variables: the variables an analysis is designed to explain, responding to independent variables

Practice questions

26 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: clinical outcome definition and examples · operational outcome definition and its link to unit goals · SMART criteria · the data-to-wisdom progression · the four data types · the exploratory questions about structure, missingness and sorting · named data integrity causes · inspection before presentation · the analytics tool table covering fields, records, tables, reports, queries, graphs and charts, control charts and predictive modeling · dependent and independent variables · the stated future drivers of the field.

Read the original source

Clinical Data Analytics Tools

To put all of this together, clinical informatics is all about the clinical data; how do we enter it, where do we store it, what can we do with it? Whether it is a retrospective look at the data or more towards the future with predictive analytics, clinical informatics plays a vital role in healthcare. Considering what has been discussed related to data, CDS and quality measures, outcomes are a top goal and are necessary in order to meet the goals you have set for providers and facilities, including lowering cost and improving the patient experience. This consists of defining and understanding both clinical outcomes as well as the operational outcomes. Later chapters discuss the systems life cycle and data management in more detail. With all the regulatory and accreditation requirements (e.g., Joint Commission, DNV GL), the ability to develop and maintain a functional system of data management is challenging. According to McBride & Tietze, “data management, measures, and analytics are the foundations of improvement.”6 Data warehouses, retrospective storage of data, can include clinical and operational data.38 See Chapter 2 for more discussion surrounding data warehouses.

Clinical Outcomes

Clinical outcomes are somewhat different from typical outcomes measures. The clinical measurements are related to specific changes in health or health quality, as it relates to the healthcare a patient has received. They are measurable and can be evaluated through activity metrics such as hospital re-admission rates, or catheter-associated urinary tract infections (CAUTIs), as well as many other metrics.39 Often times, facilities will benchmark or compare themselves to other comparable facilities based on a shared standard. This ranking is usually available to the public. It is easy to see why keeping up with data, and clinical outcomes would be considered vitally important.

Operational Outcomes

Operational outcomes are defined as outcomes that are specific and measurable statements about improvements a facility would like to make to its processes or services, “each outcome should flow directly from a more general goal of the unit.” For example, if an academic department has a goal of increasing diversity, then the department might have separate outcomes addressing the recruitment of more diverse students and recruitment of more diverse faculty.40

In the development of outcomes, the use of the acronym SMART is often recommended to assure a measurable outcome is designed.

Outcomes should be SMART:

Specific

Measurable

Attainable

Realistic

Timely

Common Data Analytics Tools

Now that you have all this data, how do you go about making it work for you? The process starts with learning about your data, manipulating it, creating information from it and then distributing that knowledge and wisdom to others. By determining what kind of data you have (nominal, ordinal, interval, ratio), you can examine or explore the data set. There are many tools available for data analysis, including Microsoft Excel, IBM SPSS, Tableau, business intelligence software and many more. When you have identified and opened your data file, you can start with a visual inspection6:

What rows and columns do the data set reflect?

How are the data structured?

Are there visibly missing data apparent in the file?

Do they appear to be sorted in some order?

What variables in the data set represent dependent, independent and grouping variables?

In healthcare, it is not uncommon for there to be data integrity issues or problems with the accuracy or validity of the data over its lifecycle.41 This can often occur for various reason. Some of the more common ones are listed here:

Wrong patient data

Height/Weight inaccuracies impacting drug calculations

Allergies and medications documentation inaccuracies or omissions

“Fat finger” errors, physical typing/entering the wrong data

Overall missing data; forgetting, time constraints, fraudulent documentation

Not documenting real time (e.g., sepsis alert dependent on vital signs data entry)

Based on these examples, it is not hard to understand the value of inspecting your data prior to presenting it. With that, the ability to recognize clinical and operational outcomes through the use of various data analytics tools (e.g., reports, tables, graphs, charts, predictive models) is a necessary skill set for any clinical or healthcare informatics specialist. Here are some examples of the more common data analytics tools and terminology

Table 3.13 Common Data Analytics Tools and Terminology38

Tool

Purpose/Definition

Example

Fields

Vertical column in a database that contains data with common characteristics for the entire record

“First Name”

“Last Name”

“Date of Birth”

Records

Horizontal rows in a database containing different pieces of data belonging to a given entity

All of the fields related to the row of “Billy”

Tables

Consists of all records; combinations of all fields and records together

All horizontal and vertical rows together

Reports

Alternate view of data; typically assembled from a query

Generally generated on paper, can also be electronic for distribution of data

Query

Process of selecting desired records; pulling the data

Pulling data related to all female patients older than 50 with a history of colon polyps

Graphs and Charts

Tool for examining and presenting data

Scatter plot, pie charts, bar charts, flowcharts

Control Charts

Tool for looking at a process over time

Common and special-cause variation, upper and lower control limits

Predictive Modeling

Instead of retrospective data analytics, the data is used to predict future outcomes

Pulling last five years of financial data to predict next years’ budget needs

Summary

Chapter 3 · Clinical Informatics · Supplemental lesson

The Terminology Division of Labour

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This lesson is the highest item-density block in the supplement. Semantic interoperability is impossible without terminologies, and the exam tests which standard does which job. The core distinction is between a terminology, built for capturing clinical detail, and a classification, built for aggregating it.

Walkthrough

Who owns what

Read the table as a set of jobs rather than names.

Standard	Job	Type
SNOMED CT	clinical findings, problems and procedures, the detailed clinical picture	terminology
LOINC	laboratory and clinical observations, naming the question asked	terminology
RxNorm	normalized drug names bridging pharmacy vocabularies	terminology
NDC	manufacturer and package-level drug identity	identifier system
ICD-10-CM	diagnosis reporting for claims and morbidity statistics	classification
ICD-10-PCS	inpatient procedure reporting	classification
CPT and HCPCS	outpatient procedure and service billing	classification
UMLS	metathesaurus mapping across the others	mapping resource
VSAC	authoritative repository of value sets for quality measures	repository
RxNav	browser and API layer over RxNorm and related drug sources	access tool

A terminology assigns unique, unambiguous codes to concepts; a classification groups concepts into categories for reporting and statistics.
A value set is a defined list of codes drawn from one or more code systems representing a clinical concept for a specific purpose, such as the codes that count as diabetes for a measure.
VSAC, hosted at the National Library of Medicine, is where authoritative value sets live for electronic clinical quality measures.

Question:

Reconstruct the job table from memory.
Define a value set and say where authoritative ones are published.

The two relationships most often confused

LOINC names the question and SNOMED often names the answer: a LOINC code identifies serum potassium, mass concentration, while SNOMED CT expresses the finding hyperkalemia.
SNOMED CT and ICD-10-CM both describe conditions, and the discriminator is purpose.
SNOMED CT is for clinical documentation: granular, hierarchical and built to capture what the clinician means.
ICD-10-CM is for reporting and reimbursement, designed to aggregate cases into billable and statistically comparable buckets.
A single SNOMED concept may map to several ICD codes or several SNOMED concepts to one ICD code, which is why UMLS exists.

Example

Using ICD-10-CM as the problem list terminology works, is common and loses clinical detail, because a classification built for aggregation cannot represent what a terminology built for capture can.

Question:

Explain the LOINC and SNOMED relationship with an example.
State the discriminator between SNOMED CT and ICD-10-CM and why UMLS is needed.

Memory tips

Job table is the single highest-value memorization in the supplement.
Observation versus conclusion: LOINC is the question, SNOMED is the answer.
Purpose split: SNOMED captures, ICD aggregates, CPT bills procedures, ICD-10-CM codes diagnoses.
NDC is a package identifier; RxNorm normalizes the clinical drug concept.
UMLS is a metathesaurus, not a terminology. VSAC holds value sets, RxNav is an access layer.

Key concepts

Terminology and classification: code systems built for capturing clinical detail versus systems built for aggregating concepts for reporting
SNOMED CT: the terminology for clinical findings, problems and procedures
LOINC: the terminology naming laboratory and clinical observations, meaning the question asked
RxNorm and NDC: normalized drug names bridging vocabularies, and manufacturer and package-level drug identity
ICD-10-CM, ICD-10-PCS, CPT and HCPCS: classifications for diagnosis reporting, inpatient procedure reporting and outpatient procedure and service billing
UMLS: the metathesaurus mapping across terminologies
Value set and VSAC: a defined list of codes representing a concept for a purpose, and the National Library of Medicine repository where authoritative ones live

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the terminology versus classification distinction · the job table and each standard's role and type · value set definition and VSAC's role · the LOINC and SNOMED question-and-answer relationship · the SNOMED and ICD purpose distinction and mapping mismatch · the reason UMLS exists.

Read the supplemental lesson source

S3.1 — The Terminology Division of Labour

Chapter 3 · Tasks II.A.1, II.A.2 · About 15 minutes

1. Learn the topic

Where this fits

Chapter 3 carries 46 items — 20% of the bank, the single densest chapter. Four of Addendum B's website references (LOINC, RxNav, UMLS, VSAC) exist to teach exactly this content. This is the highest item-density lesson in the supplement.

What it means

A terminology (or vocabulary, or code system) assigns unique, unambiguous codes to concepts. A classification groups concepts into categories for reporting and statistics. The distinction matters: terminologies are built for capturing clinical detail; classifications are built for aggregating it.

Semantic interoperability (lesson S2.1) is impossible without these. That's the connection to hold onto.

How it works: who owns what

Read this as a table of jobs, not names.

Standard · Job · Type

--- · --- · ---

SNOMED CT · Clinical findings, problems, procedures — the detailed clinical picture · Terminology

LOINC · Laboratory and clinical observations — names the question asked · Terminology

RxNorm · Normalized drug names, bridging pharmacy vocabularies · Terminology

NDC · Manufacturer/package-level drug identity · Identifier system

ICD-10-CM · Diagnosis reporting — claims, morbidity statistics · Classification

ICD-10-PCS · Inpatient procedure reporting · Classification

CPT / HCPCS · Outpatient procedure and service billing · Classification

UMLS · Metathesaurus that maps across all of the above · Mapping resource

VSAC · Authoritative repository of value sets for quality measures · Repository

RxNav · Browser and API layer over RxNorm and related drug sources · Access tool

A value set is a defined list of codes drawn from one or more code systems that represents a clinical concept for a specific purpose — "the codes that count as diabetes for this measure." VSAC, hosted at the NLM, is where authoritative value sets live for electronic clinical quality measures.

The LOINC/SNOMED relationship

This one is worth its own paragraph because it is the most commonly confused pair.

LOINC names the question. SNOMED often names the answer. A LOINC code identifies "serum potassium, mass concentration." SNOMED CT can express the finding "hyperkalemia." One is the observation identifier; the other is the clinical conclusion.

The ICD/SNOMED relationship

Both describe conditions. The discriminator is purpose.

SNOMED CT is for clinical documentation: granular, hierarchical, built to capture what the clinician actually means. ICD-10-CM is for reporting and reimbursement: designed to aggregate cases into billable and statistically comparable buckets. A single SNOMED concept may map to several ICD codes, or several SNOMED concepts to one ICD code. That mismatch is why UMLS exists.

Examples and non-examples

Straightforward. A hospital wants to identify every patient with a documented penicillin allergy across three merged systems. SNOMED CT for the allergen concept; UMLS if the legacy systems used different vocabularies.

Connecting to another concept. An eCQM specifies its denominator by value set. The measure developer publishes that value set to VSAC. Every implementer pulls the same list — which is what makes results comparable across organizations. Semantic interoperability, made concrete.

Non-example. Using ICD-10-CM as the problem list terminology. It works, it is common, and it loses clinical detail — because a classification built for aggregation cannot represent what a terminology built for capture can. This is a real design decision with real consequences, not a trick question.

Common misconceptions

"ICD and SNOMED are alternatives." They serve different purposes and coexist. Most systems use both.

"CPT is a diagnosis code set." CPT codes procedures and services. ICD-10-CM codes diagnoses.

"UMLS is a terminology." It is a metathesaurus — a mapping layer across terminologies.

"NDC is the same as RxNorm." NDC identifies a specific manufacturer's package. RxNorm normalizes the clinical drug concept across sources so systems can talk about "the same drug."

2. Exam focus

What you must know

Commit the job table above. If you learn one thing from this supplement, learn that table.

SNOMED CT → clinical documentation, problem lists.

LOINC → lab and clinical observations; names the question.

RxNorm → normalized drug names. NDC → package-level identity.

ICD-10-CM/PCS → diagnosis and inpatient procedure reporting. CPT/HCPCS → outpatient procedures and services.

UMLS → maps across. VSAC → value sets for eCQMs. RxNav → API access to RxNorm.

Terminology (capture) vs. classification (aggregate).

Distinctions likely to be tested

SNOMED vs. ICD — the discriminator is purpose, never granularity alone.

LOINC vs. SNOMED in lab data — question vs. answer.

CPT vs. ICD — procedure vs. diagnosis.

Value set (list of codes for a purpose) vs. code system (the source of codes).

How this appears in a question

Pure adjacent-role trap territory. Four real terminologies, one stem naming a function. Do not pick on familiarity — pick on the job named in the stem. Watch for stems that name the use case ("for billing," "on the problem list," "for the quality measure denominator") rather than the data type; the use case is the discriminator.

3. Teach it back

Explain to a data analyst joining from outside healthcare:

1. Why one industry needs this many code systems instead of one.

2. Given a lab result — potassium 5.9 — which standards are involved and what each one contributes.

3. Compare SNOMED CT and ICD-10-CM without using the word "detailed."

<summary>Key-point checklist</summary>

[ ] Framed the answer around purpose: documentation, billing, observation, medication, mapping

[ ] LOINC identifies the test; the value is a number; a SNOMED finding may express the conclusion

[ ] SNOMED = clinical capture; ICD = reporting/aggregation — described without leaning on granularity

[ ] Named UMLS as the mapping layer and gave a reason it's needed

[ ] Named VSAC and connected it to quality measures

[ ] Did not conflate CPT with ICD, or NDC with RxNorm

</details>

4. Practice

Items SQ-20 to SQ-24.

5. Key takeaway

Every terminology has one job. SNOMED documents, LOINC observes, RxNorm normalizes drugs, ICD reports, CPT bills, UMLS maps, VSAC curates. The exam will hand you four real standards and one function — match on the job, not on the name you know best.

Chapter 4 · Analysis · Lesson 1 of 10

The Systems Development Life Cycle and the Analysis Phase

Big picture

This section introduces the systems development life cycle and locates the analysis phase inside it. It opens the Analysis chapter, which sits in the Systems Management domain and feeds design, selection and testing later in the guide. The larger problem it solves is that projects fail upstream: a weak analysis produces a poor design, and a poor design produces a failed project. Planning and analysis are the adjacent phases to keep apart, because feasibility and scope belong to planning while requirements and the logical model belong to analysis.

Walkthrough

Where healthcare IT spending stands

Healthcare IT use has lagged other industry sectors for most of the past decade.
Deloitte's 2018 Global CIO Survey found about 4.26 percent of revenues spent on technology in healthcare services, up three quarters of a percent from 2017.
In early 2019 Forrester Research and Gartner both predicted healthcare spending would increase to nearly 9 percent.
Gartner's breakdown showed money allocated mainly to supporting and maintaining current infrastructure rather than growing and transforming the business through IT.

Question:

What does the Gartner breakdown say about where increased healthcare IT spending goes?

The SDLC and the planning phase

The SDLC is a process used to develop an information system, including requirements, validation, training and user ownership.
Its phases are investigation or planning, analysis, design, implementation and maintenance.
The planning phase precedes analysis and is where the initial idea for a health information system project is first developed.
Planning examines feasibility, objectives and scope, considers current problems with the existing situation and proposes a recommended solution.
If the project appears worth pursuing, it moves to the analysis phase.

Feasibility, objectives and scope sit in planning. A question that asks where the idea was first assessed is pointing at planning, not analysis.

Question:

Name the SDLC phases in order.
What happens in the planning phase, and what decides whether the project advances?

The purpose and objectives of systems analysis

The purpose of the analysis phase is to understand the business requirements and build a logical model of the new system.
Requirements modeling is completed and business processes are described and defined.
Data, process and object modeling take place.
The phase produces a systems requirements document describing management and user requirements, alternative plans and costs, and an analysis of the recommendation.
Analysis phase objectives: gather, analyze and validate technical, functional and nonfunctional requirements.
Evaluate the alternatives and prioritize the requirements.
Examine the information needs of end users and establish the systems goals.
Create software, hardware and network requirements documentation.
Requirements gathering is key in this phase.
Lack of end user input means a weak analysis, a weak analysis leads to poor design, and poor design can lead to failed projects.

Example

A build team that skips requirements documentation has nothing to test against later. Acceptance testing becomes an argument about what was meant instead of a check against what was agreed.

Question:

Name the four analysis phase objectives.
What document does the analysis phase produce, and what does it contain?
Trace the failure chain the source describes from missing end user input to a failed project.

Memory tips

SDLC five phases in order: Planning, Analysis, Design, Implementation, Maintenance. Planning asks whether to do it; analysis asks what it must do.
Analysis objectives four: gather and validate requirements; evaluate alternatives and prioritize; examine end user information needs and set system goals; create software, hardware and network requirements documentation.
Requirement types three: technical, functional, nonfunctional.
Failure chain to recite: no end user input, weak analysis, poor design, failed project.
Spending anchors: 4.26 percent of revenue in the 2018 survey, predicted near 9 percent, mostly for maintaining current infrastructure.

Key concepts

Systems development life cycle: the process used to develop an information system, covering requirements, validation, training and user ownership through planning, analysis, design, implementation and maintenance
Planning phase: the phase where the project idea is first developed and feasibility, objectives and scope are examined against current problems, producing a recommended solution
Analysis phase: the phase that understands business requirements and builds a logical model of the new system through requirements, data, process and object modeling
Systems requirements document: the analysis phase output describing management and user requirements, alternative plans and costs, and an analysis of the recommendation
Analysis objectives: validating technical, functional and nonfunctional requirements, evaluating alternatives and prioritizing, examining end user information needs and setting system goals, and documenting software, hardware and network requirements

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: healthcare IT spending lag and the survey figures · SDLC definition and phases · planning phase content and the decision to proceed · purpose of systems analysis · modeling activities · systems requirements document contents · the four analysis objectives · the primacy of requirements gathering · the consequence chain from missing end user input to failed projects.

Read the original source

Introduction

Different industries have adopted the use of information technology (IT) in their various operations in order to enhance growth, conform to emerging standards, attract new customers, maximize profitability and acquire business intelligence. Different sectors, however, have adopted IT use in different capacities. The health sector, like all others, is striving to enhance the acceptance of better and easier techniques available through an IT implementation, yet the average use of IT in healthcare has lagged behind other industry sectors for the better part of the last decade. According to Deloitte's 2018 Global CIO Survey, only about 4.26% of revenues were spent on technology in the healthcare services industry. This is up three quarters of a percent since the previous survey in 2017.1 In early 2019, Forrester Research and Gartner both released predictions that spending on healthcare would increase to nearly 9%. Gartner's report though further broke down the spending, which continues to show that, although spending is up, monies are allocated mainly on supporting and maintaining the current infrastructure, not on growing and transforming the business through IT.2 Healthcare has many potential benefits from IT implementation in both managerial operations and patient-related operations. These benefits may be realized through systems implementation. A common methodology that may be followed during this pursuit is the systems development life cycle (SDLC). The SDLC is a process used to develop an information system, including requirements, validation, training and user ownership through investigation/planning, analysis, design, implementation and maintenance.3 During the planning phase of the SDLC, the phase prior to the analysis phase, the initial idea for an health information system project is first developed. The feasibility, objectives and scope are examined, current problems with the existing situation are considered and a recommended solution is proposed. If the project appears to be worth pursuing the project then moves to the analysis phase. The purpose of the systems analysis phase is to understand the business requirements and to build a logical model of the new system. Requirements modeling is going to be completed, business processes are going to be described and defined, data, process and object modeling will take place, and ultimately a systems requirements document describing the management and user requirements, alternative plans and costs and an analysis of the recommendation will be produced. During the systems analysis phase, the following objectives should be met:4

Gather, analyze and validate technical, functional and nonfunctional requirements.

Evaluate the alternatives and prioritize the requirements.

Examine the information needs of end users and establish the systems goals.

Create software, hardware and network requirements documentation.

Requirements gathering in this phase is key. Lack of end user input can mean a weak analysis. A weak analysis leads to poor design, which can lead to failed projects.

Chapter 4 · Analysis · Lesson 2 of 10

Problems with Traditional Systems and Opportunities with Advanced Systems

Big picture

This section states what is wrong with legacy healthcare systems and what integrated systems offer instead. It follows the SDLC introduction because improvement proposals begin with a documented gap. The larger problem it solves is justification: the benefit list is where a project's stated value comes from, and the problem list is where its evidence comes from. The five benefit categories are the named set here, and they are easy to blur because several benefits could plausibly sit in more than one category.

Walkthrough

Problems with traditional healthcare systems

Poor quality of health information, including redundancy and inconsistent standards for collecting and sharing information.
Inability to obtain health information at the time and place where it is needed.
The data collected in health records is limited.
Some health registers exist only in paper form, which limits quick access.
Inadequate procedures for implementing information systems, not related to the relevant organizational changes.
Existing solutions do not ensure interoperability, and lack of cooperation between systems makes information management impossible and adversely affects accuracy, integrity, comparability and completeness of data.
Systems have been developed primarily to support the work of the administrative unit and only to a small extent adjusted to the needs of patients, doctors and other users.
Lack of computerized practitioner order information and histories for drugs and other substances, medical supplies, catalogs and lab test results.
Lack of an integrated, interoperable electronic health record, image and film archiving and associated communication systems, result analysis mechanisms for ordinary processes such as lab tests and prescriptions, prescription error alert systems and electronic monitoring of high care patients.

Note which data qualities the source names as damaged by poor cooperation between systems: accuracy, integrity, comparability and completeness. That four-part list is the usual answer when a stem asks what fragmentation costs.

Question:

Reconstruct the problems list without looking.
Which four data qualities does lack of system cooperation harm?
Why does the source say existing systems serve administration more than clinicians?

Integrated systems and their benefit categories

Hospital information system, healthcare information system and patient data management system all refer to integrated information systems in healthcare.
They are complete solutions for managing medical, administrative, financial and legal data.
The overall aim is to support patient care, achieve optimal financial performance and streamline administration.
They integrate clinical, financial and administrative systems.

Operational benefits

Increases productivity, reduces cost, improves data quality, improves data sharing and flow, provides better access to and easier exchange of data, improves data presentation, reduces medical errors and helps achieve satisfaction.

Managerial benefits

Improves managerial control, provides more understanding and control of processes, supports decision-making, improves allocation of resources, improves quality of care, improves work efficiency, increases performance and increases return on investment.

Strategic benefits

Supports more effective planning, increases synchronous and asynchronous collaboration among actors, improves supplier relationships, improves knowledge sharing, improves population health and increases survival rates and quality of life.

IT infrastructure benefits

Promotes reusability of objects, reduces development risk, supports e-healthcare and telemedicine-based patient support models, achieves non-invasive solutions, and achieves process, object, data and real-time integration across custom and packaged systems.

Organizational benefits

Reduces need for hospitalization or length of stay, reduces waiting times, reduces cancelled operations, achieves effective clinical and administrative management, increases business efficiency, supports clinical decision-making, produces reliable data, increases data analysis and reduces paper work processes.

An actor means all human and non-human users that interact with the healthcare system.
The major avenues of opportunity span clinical, administrative and financial functions as well as infrastructure.

Question:

Name the five benefit categories and give two benefits from each.
Define actor as the source uses it in the strategic category.

Applications by function

Clinical: EHRs standardize how records are entered, stored and retrieved within and across organizations, with industry standardization the biggest challenge.
CPOE may replace conventional order cataloging and fulfillment, improving tracking, logistic synchronization and cost-effectiveness.
A clinical decision-support system gives informative guidelines on medication and procedures, including warnings on high-risk medications and processes.
PACS integrates inputs from multiple radiological and diagnostic tools, and RFID tracks patients within a unit without restricting their location.
Monitoring systems collect vital signs including pulse rate, temperature, blood pressure and other metabolic or respiratory signals.
Automated dispensing machines aid drug dispensing, and electronic materials management systems manage pharmaceutical information processing.
A 2016 report found adverse drug events account for more than 3.5 million physician office visits and 1 million emergency department visits each year.
Preventable medication errors are believed to affect more than 7 million patients and cost almost 21 billion dollars annually across all care settings.
Administrative and financial: general ledger operations, billing, cost accounting, payroll, personnel management, integrated human resources, patient registration and booking, and electronic materials management.
Enterprise relational database management systems support employee management, role definition, reward and recognition and performance development.
Infrastructure: biometric sensors for movement and access control, including fingerprint or palm scanners, voice recognition and eye scanners.
Bar coding systems support medication grouping, ordering, cataloging and stock control, and security infrastructure may include closed-circuit and night infrared cameras.
Security-related applications: patient information access logging supports confidentiality, professionalism and patient trust.
Biometric systems reduce ambiguity in accountability because of high precision and very low chances of identity theft or manipulation.
Research facilities may hold equipment such as DNA synthesis machines that require restriction to high-security facilities.
Baseline network infrastructure includes servers, end user computer stations, switches, network access points, cabling and external access infrastructure.

Question:

Give the ADE and medication error figures the source cites.
Name the biometric methods and the other security infrastructure the source lists.
What does the source say most care units actually use their network infrastructure for?

Memory tips

Five benefit categories: Operational, Managerial, Strategic, IT infrastructure, Organizational. Operational is the work, managerial is the control, strategic is the direction, infrastructure is the plumbing, organizational is the institution's own performance.
Fragmentation damages four data qualities: accuracy, integrity, comparability, completeness.
Three names, one thing: hospital information system, healthcare information system, patient data management system.
Medication error anchors: 3.5 million office visits, 1 million ED visits, 7 million patients, almost 21 billion dollars.
Administrative bias problem: systems were built for the administrative unit, adjusted only slightly for patients, doctors and other users.

Key concepts

Problems with traditional systems: poor information quality and inconsistent standards, unavailability at point of need, limited recorded data, paper-only registers, inadequate implementation procedures, absent interoperability harming accuracy, integrity, comparability and completeness, administrative bias, and missing order, record, imaging, alerting and monitoring capability
Integrated healthcare information system: a complete solution for medical, administrative, financial and legal data that supports patient care, financial performance and streamlined administration
Benefit categories: operational, managerial, strategic, IT infrastructure and organizational
Actor: all human and non-human users that interact with the healthcare system
Clinical applications for change: EHR, CPOE, clinical decision-support systems, PACS, RFID tracking, physiologic monitoring, automated dispensing machines and electronic materials management
Security applications: access logging, biometric identification by fingerprint, palm, voice and eye, bar coding for medication and stock control, and camera-based physical security

Practice questions

5 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the named problems with traditional systems · the four data qualities harmed by lack of cooperation · administrative bias of existing systems · HIS, healthcare information system and PDMS naming and aim · the five benefit categories and their contents · the definition of actor · clinical, administrative, financial, infrastructure and security applications · ADE and medication error figures · biometric and physical security methods · baseline network infrastructure components and their typical underuse.

Read the original source

Healthcare Problems and Opportunities for IT Implementation

Healthcare globally is going through dynamic changes in several ways. Improvements to healthcare information systems emerge from a need for change. Either the existing system does not meet the evolving needs of the program or there is an understanding that emerging technologies allow for radically better systems. In response, a small group, or a project champion, identifies this need and then tries to mobilize a larger group of stakeholders. During this phase, systems analysis, the perceived gaps and opportunities are documented, with a strong focus on describing the desired benefits and why. It may include the development of a high-level business case that compares the benefit with estimated costs. To begin, let's look generally at problems plaguing traditional healthcare systems and then potential opportunities to address these issues.

Problems with Traditional Healthcare Systems

Overall, there are some general problems with the traditional healthcare systems. These may include:

Poor quality of health information including redundancy and inconsistent standards for the collection and sharing information.

Inability to obtain health information at the time and place where it is needed.

The data collected in health records is limited.

Some registers in health exist only in paper form, which limits quick access to them.

Inadequate procedures for the implementation of information systems not related to the relevant organizational changes.

Existing solutions do not ensure interoperability and the lack of co-operation between systems makes management of information impossible and adversely affects the accuracy, integrity, comparability and completeness of data.

To this point, systems have been developed primarily to support the work of the administrative unit, while to a small extent adjusted to the needs of patients, doctors and other users.

Lack of computerized practitioner order information and histories for drugs and other substances, medical supplies, catalogs and lab test results.

Lack an integrated, interoperable electronic health record, image and film archiving and associated communication systems, the result analysis mechanism for ordinary patient processes such as lab tests and drug prescriptions, prescription error alert systems and electronic monitoring of high care patients.

Opportunities with Advanced Healthcare Systems

As we look toward advanced healthcare systems, there are many opportunities. Hospital information system (HIS), healthcare information system and patient data management system (PDMS), all these terms refer to the integrated information systems in the healthcare sector. They are complete solutions for managing medical, administrative, financial and legal data. The overall aim of a HIS is to provide support for patient care, achieve optimal financial performance and streamline administration. These systems include the integration of clinical systems, financial systems and administrative systems. Benefits of integrated healthcare systems include:

Operational

Increases productivity, reduces cost, improves data quality, improves data sharing/flow, provides better access to data, provides easier exchange of data, improves data presentation, reduces medical errors and helps achieve satisfaction.

Managerial

Improves managerial control, provides more understanding and control of processes, supports decision-making, improves allocation of resources, improves quality of care provided, improves work efficiency, increases performance and increases return on investment.

Strategic

Supports more effective planning, increases synchronous-asynchronous collaboration among actors (actor refers to all human and non-human users that interact with the healthcare system), improves relationships with suppliers, improves knowledge sharing, improves population's health and increases survival rates and quality of life.

IT Infrastructure

Promotes reusability of objects, reduces development risk, supports the use of e-healthcare and telemedicine-based patient support models, achieves non-invasive solutions, achieves process integration, provides object/components integration, provides data integration, provides real-time integration, integrates custom systems and integrates packaged systems and integrated e-business solutions.

Organizational

Reduces need for hospitalization or length of stay, reduces waiting times, reduces cancelled operations, achieves effective clinical and administrative management, increases business efficiency, supports clinical decision-making, results in reliable data, increases data analysis and reduces paper work processes.

The major avenues of opportunities for change are spread across clinical, administrative and financial functions as well as infrastructure.

Clinical Functions

A significant percentage of modern healthcare facilities are using IT systems in clinical operations. However, the majority of units are still dependent on traditionally used systems, such as physical patients’ document keeping, lab reports, drug administration history and other functions. While much progress has been made in these areas over the past couple of decades, we still have a long way to go before we achieve a global, interoperable healthcare system in all types of healthcare settings.

Applications for Clinical Functions

Electronic health records (EHRs) involve standardizing the way in which patients’ records are entered, stored and retrieved, not just within an organization, but across different hospitals, caregivers, government-controlled organizations and other interested parties. The biggest challenge regarding EHRs has been the establishment of an industry standard so that an efficient workflow can be realized that would allow for seamless retrieval and use of records for patients, even when patients are moved to units or facilities other than where they were initially treated.

This kind of data pool would imply a dedicated system with necessary checks and balances to prevent unauthorized access to and manipulation of patient records, while, at the same time, enabling data entry by different care providers when patients make additional visits to any facility. This concept is delicate due to the potential of malicious addition or manipulation of patient data by different staff in different facilities. Moreover, a lack of universal standards in proper coding and categorization of prescriptions and procedures has hindered the implementation of interoperable EHR systems in the last two decades. This problem can now be sufficiently handled by high-end software applications that are being developed by individual and corporate research entities.

An example of one type of system being pursued is computerized practitioner order entry (CPOE). CPOE may replace conventional order cataloging and fulfillment in a manner that will enhance tracking, logistic synchronization and cost-effectiveness. Another example of a system is a clinical decision-support system (CDSS), which, in its basic form, will give informative guidelines to practitioners regarding medication and procedures, including warning systems relating to high-risk medications and processes. In addition, the picture archiving and communication system (PACS) integrates inputs from multiple radiological and diagnostic tools to allow easy, consistent and accurate treatment of different conditions, while radio frequency identification (RFID) may help to track patients within a medical unit without the need to restrict them to a particular location or allocate a nurse to them. There are also monitoring systems that may collect vital signs which may include pulse rate, temperature level, blood pressure and other metabolic/respiratory signals. Benefits of such a system, if properly collected, stored and secured, when integrated with other dedicated software applications, may shorten treatment time, allow more freedom and lead to cost efficiency and better resource utilization within a hospital or other healthcare facility. Automated dispensing machines (ADMs) will aid in drug dispensing, while electronic materials management (EMM) systems will operate like the resource planning systems used in other sectors to manage information processing regarding pharmaceuticals, new drug development and coding, among other functions. Such a system could reduce medication errors, which, per a report from 2016 found that adverse drug events (ADEs) account for more than 3.5 million physician office visits and 1 million emergency department visits each year. This same report also stated that it is believed that preventable medication errors impact more than 7 million patients and cost almost $21 billion annually across all care settings..

Administrative and Financial Services

Functions that could be enhanced through investment in IT in the administrative category include general ledger operations, such as revenue and cash flow, expenses, purchases and other day-to-day transactions. Other functions are billing, cost accounting systems, payroll, personnel management and integrated human resource functions, patient registration and booking and electronic management of materials, among others.

Applications for Administration and Finance

IT may find many basic as well as advanced applications in administrative and financial services. Human resource management has experienced radical changes in operational methods as a result of IT implementations. Systems for employee management, role definition, reward and recognition support and performance development have been successfully automated thanks to dedicated software such as enterprise relational database management systems (RDBMSs). Such systems allow easy, timely and accurate workflow management in human resource mobilization and development, saving time and costs that would otherwise be allocated for additional staff. Other functions, such as payroll, budgeting, internal audits and strategic planning, have also been made easier, more precise and tailor-made for specific analytical objectives without incurring additional monthly or yearly charges due to the use of IT systems. Patient registration and tracking can become more enhanced and efficient, and access to the online statistics of every facility within an area may be useful in referrals and in discharge notification, enabling time saving and better emergency handling.

Infrastructure

Infrastructure is a broad category that incorporates various equipment with diverse applications, both general and specific. Current security standards have shifted toward biometric sensors for movement and access control in many major private and public buildings and premises. These security standards enhance accountability in system access and support user logging, which enhances safety and responsibility among authorized personnel. The healthcare sector could, perhaps, benefit the most from such systems, given the delicate nature of confidentiality requirements involved in patient records access and dissemination. Biometric sensors typically used include fingerprint or palm scanners, voice recognition systems and eye scanners, among others. Other more dedicated systems include bar coding systems for medication grouping, ordering, cataloging and stock control. Security infrastructure may also include closed-circuit TV cameras and night infrared cameras.

Security-Related Applications

Since IT relates to healthcare security, it may find many uses, some of which may not be achieved in other ways. Patient information access logging is important in ensuring confidentiality and professionalism in the way patients are treated. It increases patients’ confidence in their practitioners and boosts their trust levels. In addition, the use of biometric systems will eliminate to a large extent, ambiguity in accountability in delicate cases due to their high precision levels and extremely low chances of identity theft or manipulation, unlike conventional security protocols when any person with forced access to pass codes may steal information. In addition, healthcare research facilities may hold expensive machinery that, if it falls into wrong hands, may be used in ways detrimental to society. For instance, ultra-modern DNA synthesis machines, if used by experts, may find applications in the terrorist underworld. Other chemicals and drugs in healthcare facilities may also be abused or sold to unsuspecting people as legitimate prescriptions and lead to catastrophic consequences. Such security measures cannot be overlooked, and government control is restricting the use of certain machinery and equipment to high-security facilities, limiting the range of services that healthcare units with lower security may offer.

Another broad category of infrastructure has to do with network development and all associated controls. Medicare processes large amounts of information internally, not to mention the external linkage requirements associated with referrals and national accountability reports that must be processed and sent to government control and data collection agencies and other industry regulatory bodies. The baseline network infrastructure includes servers, end user computer stations, switches, network access points, all associated cabling and external access infrastructure. While very elaborate high-level applications have been incorporated into network infrastructures in a significant number of healthcare facilities, the majority of care units are using their network support equipment for only slightly more than baseline uses, such as record keeping and document sharing.

Chapter 4 · Analysis · Lesson 3 of 10

Needs Analysis, Its Tools and Needs Prioritization

Big picture

This section defines the needs analysis, lists the operational needs it examines, names the tools used to conduct it and sets the priority order among competing needs. It follows the problem and opportunity survey because a need is a documented gap rather than a wish. The larger problem it solves is that everything on the list is urgent, so a project that cannot rank needs cannot defend its scope. Needs analysis and gap analysis are the same activity under two names in this chapter, which is worth holding so a question naming one is not read as introducing a second method.

Walkthrough

What a needs analysis is

The needs analysis identifies the main challenges in the sector and the needs that sustainable, secure and cost-efficient IT practice can meet.
It categorizes requirements as operational, administrative or industry related.
During the needs analysis the problem is further characterized, a cost-benefit feasibility study is performed, scope and value are defined and the framework for what the system will do is established.
The needs analysis may also be referred to as a gap analysis.
A gap analysis assesses differences in performance between an organization's systems to determine whether business requirements are being met and, if not, what steps will ensure they are met.
These gaps inform the overall needs assessment.

Question:

Define gap analysis in the source's terms and state its relationship to the needs analysis.
What four things happen during the needs analysis?

Operational needs

Staff productivity and satisfaction: IT may reduce time operational staff spend on administrative work and increase patient attendance time.
It reduces unnecessary routines in patient care and non-work-related duties for clinical staff.
It improves employee satisfaction and reduces fatigue from extensive overtime, and better productivity leads to increased patient volumes.
Increased revenue and cost optimization: greater visitor capacity per unit raises revenue through more admissions and discharges per month following shortened lengths of stay, reduced unit costs for bulk purchases and improved capability to meet overhead.
Cost optimization comes through bulk purchases, efficient stock control and reduced cost per patient day.
Patient safety: deaths and malpractice cases arise from errors in treatment, procedures or prescriptions, including adverse drug events, surgical and transfusion errors, and malpractice expenses such as corrective procedures, litigation and compensation.
Quality of care: satisfaction with providers' efforts to resolve problems, including delay time, treatment time, appropriateness of procedures and drugs, professionalism, confidentiality and courtesy.
Quality also involves recognition and accreditation, complication management, physician or nurse time with patients and reduced length of stay.
Patient access to services: delay time for lab reports, billing, online viewing and scheduling, preventive care management and outpatient appointment booking.
Automation should handle routine work not requiring case-specific diagnosis, including remote booking with scheduling alerts, integrated lab linkage that removes physical queues, and electronic bill settlement.
Nonmonetary benefits include good patient-physician relationships and improved community health.

Question:

Name the five operational need areas and one requirement from each.
Which routine work does the source say should be automated, and which should not?

Tools, the needs summary and prioritization

The most common needs analysis tools are observation, interviews, review of documentation, surveys and data analysis.
What is required is planning to implement safe, sustainable and cost-effective IT across administrative, operational, patient-related and industry-related functions.
A seamless backbone IT platform should integrate those four needs, with sustainable controls to keep implementation secure, purposeful and universally adaptable.
All the needs listed are urgent and important, but some must be prioritized for IT acceptance to stand.
From an individual facility's perspective the priority order is patient safety, then profitability, then ease of processes, then industry standardization.
From the healthcare industry's perspective the priorities are patient safety and security, professionalism, standardization, profitability and ease of processes.
Ease of processes is in most cases tied with profitability.
Patient safety outranks bookkeeping and profit because failures in fundamental safety can cost a unit its license, rendering other advances futile.
The project must address both perspectives and strike a balance, and prioritization drives the likelihood of project acceptance.

Example

A proposal that leads with margin improvement and mentions safety last inverts the facility priority order the source states, and it invites the question of what happens to the margin if the license is at risk.

Question:

Name the five needs analysis tools.
Give both priority orders, facility and industry, and explain why patient safety leads.

Memory tips

Needs analysis equals gap analysis in this chapter. Same activity, two names.
Tools five: Observation, Interviews, Documentation review, Surveys, Data analysis.
Four need groupings for the backbone platform: administrative, operational, patient-related, industry-related.
Facility priority order: safety, profitability, ease of processes, standardization. Industry order: safety and security, professionalism, standardization, profitability, ease of processes.
Safety-first argument: a safety failure can cost the license, which makes every other gain futile.

Key concepts

Needs analysis: the identification of sector challenges and the needs IT can meet, categorized as operational, administrative or industry related, during which the problem is characterized, a cost-benefit feasibility study performed, and scope, value and system framework defined
Gap analysis: the assessment of performance differences between an organization's systems to determine whether business requirements are met and what steps would meet them
Operational needs: staff productivity and satisfaction, increased revenue and cost optimization, patient safety, quality of care and patient access to services
Needs analysis tools: observation, interviews, review of documentation, surveys and data analysis
Needs prioritization: the facility order of patient safety, profitability, ease of processes and standardization, against the industry order of safety and security, professionalism, standardization, profitability and ease of processes

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: purpose and categories of the needs analysis · activities performed during it · the gap analysis definition and equivalence · the five operational need areas and their content · nonmonetary benefits · the five needs analysis tools · the four-function backbone platform requirement · both prioritization orders · the licensing argument for safety primacy · prioritization's effect on project acceptance.

Read the original source

Needs Analysis in Healthcare Facilities

In order to develop a proper proposal for sustainable IT supplementation in the core processes of the healthcare sector, it is important to identify the main challenges in the sector and specifically those needs that can be sufficiently met by the implementation of sustainable, secure and cost-efficient IT practices. This section will give a detailed needs analysis to lay the foundation for the chapter. The analysis focuses on requirements that may be categorized as operational, administrative, or industry related. During the needs analysis, the problem will be further characterized, a cost–benefit feasibility study will be performed, the scope and value will be defined and the framework for what the system will do is established. The needs analysis may also be referred to as a gap analysis. A gap analysis is a method of assessing the differences in performance between an organizations systems to determine whether business requirements are being met and, if not, what steps should be taken to ensure they are met successfully.6 These gaps help inform the overall needs assessment. The following text will also describe a number of processes and tools that will aide in establishing the gaps and informing the new system requirements.

Operational Needs

Healthcare facilities need to streamline their core administrative and financial operations with the current global standards in order to foster interoperability in record keeping and analysis with other stakeholders, investors and business partners. Currently, healthcare as an industry is behind average industry standards in IT acceptance. Such processes as payment processing, e-bill systems, human resource systems, stock intake, auditing and other similar functions can be sufficiently integrated with the use of developing software.7 In order for a system to be sustainable and standard, it is necessary to select a universally accepted platform for data storage and analysis in which organizations may pool data relating to logistics and facilities. Financial as well as private human resource information does not need to be pooled in a central storage facility, but adopting software dedicated to easing these functions on a private level is necessary in order to reduce costs, enhance operational efficiency and increase profitability. Operational needs may be broken down into several areas.

Staff Productivity and Satisfaction

The use of IT may reduce time wasted by operational staff performing administrative work and enhance patient attendance time, which is the key need for patients. It will also reduce unnecessary routines in patient care and reduce work of clinical staff due to rigorous, non-work-related duties. Additionally, it will improve employee satisfaction and reduce fatigue due to extensive overtime schedules. Better productivity will invariably lead to increased patient volumes.

Increased Revenue and Cost Optimization

Increased visitor capacity per unit may boost revenues for a care unit due to a larger number of admissions and discharges per month following shortened lengths of stay, reduced unit costs for bulk purchases and improved capability to meet overhead expenses. Cost optimization needs to be realized through bulk purchases, efficient stock control and reduced cost per day for each patient. In this regard, IT practices will save costs for the unit as well as daily treatment and accommodation charges to the customer.

Patient Safety

A significant number of deaths and serious medical malpractice cases are reported each year due to errors in treatment, procedures or prescriptions. The major cases involve ADEs due to wrong prescriptions that affect patients negatively, admissions following adverse drug events, errors in surgical procedures, blood transfusions and malpractice expenses such as corrective procedures, court litigations and compensations. There is an urgent need to reduce such occurrences, many of which can be satisfactorily handled by the application of proper IT processes.

Quality of Care

Patient quality of care deals with the satisfaction that patients get from care providers’ efforts to resolve their problems. It may involve time of delay, time of treatment, appropriateness of procedures used and drugs administered and the levels of professionalism, confidentiality and courtesy of the staff. Moreover, it may involve specific professional services, such as recognition and accreditations, complication management, physician or nurse time with patients and reduced length of stay.7

Patient Access to Services

Apart from the length of stay, patients are concerned with delay time for such processes as lab reports, billing, online services such as viewing and scheduling, preventive care management and outpatient care appointment bookings. There is a need to upgrade systems that can be automated to handle most of the routine work not requiring case-specific diagnosis, such as remote patient appointment bookings and all associated alerts on scheduling, integrated lab linkage with other hospital systems that eliminates the need for extended physical queues at facilities, and electronic procedures for alternative bill settlement by customers. If proper systems are established to meet the outlined objectives, other needs relating to healthcare that cannot be quantified but lie at the core of healthcare provision will also be realized. This will lead to nonmonetary benefits such as good patient–physician relationships and improved community health

Tools for Accomplishing the Needs Analysis

Needs analysis can be conducted through a variety of tools. The most common include observation, interviews, review of documentation, surveys and data analysis.

Needs Summary

The foregoing discussion highlights the need for all-around IT supplementation to help healthcare catch up with other sectors in terms of modernization and integration. In essence, what is required is sufficient planning to implement safe, sustainable and cost-effective IT practices to help healthcare in (1) administrative, (2) operational, (3) patient-related and (4) industry-related functions. There is a need for a seamless backbone IT platform that integrates these four needs, as well as sustainable controls for the IT implementation to ensure it remains secure, serves the maximum purpose possible and is practical for universal adaptability in order to satisfy the core concern within various healthcare institutions, which is the integration of policy implementation.

Needs Prioritization

While all the needs listed above are urgent and important, there are certain ones that must be prioritized in order for IT acceptance in healthcare to stand. These processes are the backbone of healthcare, and all other requirements are built on them. For instance, patient security and safety are core driving factors for any practitioner, and they surpass the need for good bookkeeping or profit optimization. Without proper observance of fundamental safety concerns, healthcare units are likely to face legal implications that could cause them to lose their license, rendering futile any advancement they may have in their other operations. This section will therefore seek to address the need for prioritization of IT acceptance in healthcare facilities based on the hierarchy of the needs model. The needs prioritization process helps drive the likelihood of project acceptance. The primary priority from an individual facility's perspective is patient safety, followed by profitability, then ease of processes and lastly, industry standardization. From the healthcare industry's perspective, the priorities are likely to be patient safety and security, professionalism, standardization, profitability and ease of processes. Obviously, the ease of processes is in most cases tied with profitability.8 The project must therefore address IT implementation issues from both perspectives and attempt to strike a balance. Figure 4.1 illustrates the differing priorities of individual facilities and the healthcare industry.

Chapter 4 · Analysis · Lesson 4 of 10

Workflow and Process Mapping

Big picture

This section explains why processes are drawn before they are automated and what the drawings are used for downstream. It follows the needs analysis because a gap in performance has to be located in a specific step before it can be fixed. The larger problem it solves is that automating a broken process preserves the break at higher speed. Process mapping and requirements analysis are adjacent: mapping shows how work is done now, while requirements describe what the new system must do.

Walkthrough

What mapping is for

Workflow and process mapping are mechanisms for understanding current processes and how work is performed, beginning the change management process.
They support the functional, data and technical strategies.
They identify broken processes and create the opportunity to address them before a system automates them.
They help recognize the need for process improvement through automation.
Process mapping guides functional specifications where a product may not address all the functionality an organization needs or wants.
It helps visualize the need for standard data structures.
The activity can also be called process redesign or process reengineering.
Workflow aids system configuration during implementation, supplies scenarios for test cases and shows new users how the process will change with the new system.
Mapping identifies how work is currently performed and the sequence of steps involved.
Diagram forms include activity diagrams, swim lane charts, data flow diagrams, system flowcharts, entity relationship diagrams, class diagrams and use cases.
Process diagrams and flowcharts show the boundaries of the process, the steps and the sequence in which the steps take place.
They use standard symbols, with different approaches and symbol sets such as ISO 5807 and Unified Modeling Language.
Healthcare operations and processes can be analyzed in four broad categories: administrative and financial, operational, process flow and standardization.

Question:

Name the uses of workflow and process mapping the source lists, including the downstream uses during implementation.
List the diagram forms and the four categories for analyzing healthcare operations.

The two worked processes

The lab report briefing process shows a nurse usually trying to reach a patient more than four times, in stated durations from a few hours to a day.
That process consumes time, delays other functions and reduces the number of patients served per day.
IT implementation could allow convenient briefing and follow-up using trusted e-mail services and other channels, with patients choosing a preferred channel before leaving the facility.
The referral-patient booking process introduces delays from lack of integration between communication and decision-making systems involving providers, referral centers and patients.
A referral patient may wait up to two weeks between the referral date and the appointment booking date solely because of communication and work arrangement delays.
Referrals may not look urgent on the reported data sheet while the patient's situation worsens during the wait.
The waiting period could be greatly reduced by IT policies incorporating remote meetings such as video and audio conferencing.
Time between contacting a patient and receiving a response is service degradation for the patient and revenue loss for the provider.
Most correspondence requiring official letters involves non-vital documents such as booking requests, so a web-based secure communication and client support system could bypass the delay.
Modern patient portals are beginning to address this need, though implementation and use still lag.
Digital signing is a progressively adopted standard that benefits providers sending documents requiring authorization or authentication.
Registered mailing services are offered as an alternative to reduce feedback duration for sensitive medical cases.
Billing and other workflow routines are also inefficient across medical history review, booking, physician time, prescription, pharmacy queuing and bill settlement.

Both examples locate the delay in communication rather than in clinical work. That is the point of mapping: the step that costs the most time is rarely the step that delivers the care.

Question:

Describe the lab callback process and the delay it creates.
Explain the referral booking delay, its length and its two named remedies.

Memory tips

Mapping outputs four: current-state understanding, functional specification input, configuration guidance, and test case scenarios.
Other names for the same work: process redesign, process reengineering.
Symbol standards named: ISO 5807 and Unified Modeling Language.
Four analysis categories: administrative and financial, operational, process flow, standardization.
Two numeric anchors: more than four callback attempts, up to two weeks from referral to booking.

Key concepts

Workflow and process mapping: the mechanism for understanding how work is performed now, identifying broken processes before automation and guiding functional specifications and standard data structures
Process redesign or reengineering: alternative names for the same mapping and improvement activity
Downstream uses of workflow: system configuration during implementation, scenarios for test cases and orientation for new users
Diagram forms: activity diagrams, swim lane charts, data flow diagrams, system flowcharts, entity relationship diagrams, class diagrams and use cases
Process flow diagram: a visual representation showing process boundaries, steps and their sequence using standard symbol sets such as ISO 5807 or UML
Lab callback process: the example process in which a nurse attempts contact more than four times, reducing patients served per day
Referral booking process: the example process in which a patient may wait up to two weeks because of communication and work arrangement delays

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: purposes of workflow and process mapping · identification of broken processes before automation · guidance of functional specifications and data structures · alternate names · implementation, testing and orientation uses · the diagram form list · what flow diagrams show and their symbol standards · the four categories of healthcare operations · the lab briefing example and its costs · the referral booking example, its two-week delay, its causes and the proposed remedies including portals, digital signing and registered mail · billing workflow inefficiency.

Read the original source

Workflow and Process Mapping

Workflow and process mapping serve as mechanisms by which to understand current processes and how work is performed to begin the change management process and serve to support the functional data and technical strategies.9 These two methods can also help identify broken processes and provide an opportunity to address them before a system automates them. This also helps recognize the need for process improvement through automation. Process mapping guides functional specifications where a product may not address all functionality an organization may need or want. It helps visualize the need for standard data structures.9 This can also be termed process redesign or process reengineering. Workflow aids system configuration during implementation, provides scenarios to create test cases from and guides new users of the system regarding how the process with change with the new system. Workflow and process mapping identify how work is currently performed and the sequence of steps involved. There are a variety of forms these diagrams. Some tools include activity diagrams, swim lane charts, data flow diagrams, system flowcharts, entity relationship diagrams, class diagrams and uses cases.

Current Clinical Processes

Operations and processes in the healthcare sector can be analyzed in four broad categories: administrative and financial, operational, process flow and standardization.

Figures 4.2 and 4.3 present typical process flow diagrams that aid in identifying areas of two healthcare processes that are manageable using IT.10 Process diagrams and flowcharts are a visual representation of a process that show the boundaries of the process, the steps and the sequence in which the steps take place. These visual representation will use standard symbols, but different approaches and different symbol sets may be used, e.g. ISO 5807 and Unified Modeling Language (UML).

Figure 4.3Process 2: Referral-patient booking process.

Figure 4.2 shows the process flow for a typical client briefing about lab reports. A nurse will usually try to reach a patient more than four times in stated durations, usually from a few hours to a day. This process takes time, delays other functions and consequently leads to fewer patients served per day. The proper IT implementation, even on the internal level, may allow convenient patient briefing and follow-up using trusted e-mail services, among other channels. Patients can usually be given the option to choose their preferred channel of communication before leaving the hospital or other care facility.

A typical referral process involves even more delay. The referral-patient booking process is diagrammed in Figure 4.3.11 The figure clearly demonstrates delays introduced in current healthcare systems due to lack of integration between the communication and decision-making systems involving care providers, referral centers and patients. In the workflow diagram, it may be noted that a referral patient may wait up to two weeks between the date of referral and the date of appointment booking solely due to communication and work arrangement delays. Referrals may not appear urgent on the reported data sheet, but patients’ situations may become aggravated during the waiting period when they are unable to obtain help. As a result, patient services may be greatly compromised due to the systems’ inefficiency. In addition, the lengthy waiting period can be greatly reduced if proper IT policies that incorporate remote meetings, such as video and audio conferencing, are implemented. The time spent between contacting a patient and receiving a response constitutes service degradation for the patient and revenue loss for the care provider.

A reduced number of patients are seen per day; therefore, customer satisfaction levels may also decline. While authentication issues may be cited as the reason for insistence on the use of official letters by care providers, the bulk of the processes requiring care provider–client correspondence involve non-vital documents, such as requests for bookings. A possible method of bypassing this hindrance through the IT-based communication implementation is to develop a web-based communication and client support system that would allow secure communication between the customer and the care provider. In this platform, customers would be able to receive e-mails and respond to booking notifications. Modern day patient portals are beginning to address this need, but the implementation and use of these systems is still lagging.

In addition, digital signing is a standard that is progressively being adopted by many industry sectors and is a concept that may be beneficial to healthcare providers when they send documents requiring authorization or authentication. As an alternative, the use of registered mailing services may greatly reduce the feedback duration for sensitive medical cases. Apart from the operational perspective, billing systems and other workflow routines in most facilities are also very inefficient. The entire process, which includes a medical history review, booking to be attended by the physician, physician duration, prescription, queuing at the pharmacy and bill settlement, involves avoidable delays. These work stages can be sufficiently improved by computer-aided work management and decision-making.

As workflows begin to be examined naturally other key factors to the analysis process will begin to take form. This really begins the requirements gathering processes as well.

Chapter 4 · Analysis · Lesson 5 of 10

Functional Needs Assessment, Requirements and Inventories

Big picture

This section covers how capability requirements are gathered, documented and cross-checked against what already exists. It follows process mapping because the map shows how work happens while these documents state what the new system must support. The larger problem it solves is scope control: the requirements analysis is what keeps a project aligned to what was agreed and what testing later validates against. Functional needs assessment and requirements analysis are adjacent: the first captures what users say they need, the second documents what the system will actually do.

Walkthrough

Functional needs assessment and use cases

The functional needs assessment describes the key capabilities or application requirements for achieving the benefits the organization has envisioned.
It matters because every organization begins from a different starting point, has different needs, and every vendor offers a different approach.
It is best achieved through surveying users and reviewing use cases.
Users should identify the functionality they need and rank or prioritize it.
Users' understanding of what is possible may be limited early on, which still matters because additional functionality may need planning for later phases.
Identifying users with exposure to different systems provides useful feedback from experience.
Engaging users is a critical component of implementation success.
A use case is a scenario describing system behavior as it responds to a request originating outside the system.
It describes the interaction between the actor who initiated the interaction, such as a clinician, and the system.
The use case approach is often easier for clinicians to understand, and clinicians can form use cases by considering patient care events.
Use cases yield further visualizations such as process diagrams and ultimately a listing of functional requirements.
Current functional capabilities can be inventoried to show users the scope of what exists and what is missing.

Question:

Define a use case and explain why clinicians find the approach accessible.
Why does the source insist the functional needs assessment be organization specific?

Requirements analysis and its categories

The requirements analysis is the documented record of what the system actually does.
It is critical to keeping the project aligned with the identified scope.
It is essential to testing, because the information gathered produces test cases validating that the system meets project requirements.
Use cases begin with a high-level description of the process and include a detailed description of each requirement, often with a graphical depiction.
The document describes the future state and is the primary input for estimating resources, cost and time.
It takes the needs assessment into account and further informs needs prioritization.
Requirement categories: functional and workflow; reporting and analysis capabilities; regulatory requirements; data and database; security; system performance and response time; disaster recovery; platform compatibility; interface and interoperability; physical plant considerations; client devices; and network.

Example

When a hospital cannot say in writing what the system must do, scope grows by conversation. The requirements document is what makes a mid-project addition visible as a change rather than an assumption.

Question:

State the two functions of the requirements analysis: alignment and testing.
Reconstruct the requirement categories without looking.

Document analysis and additional inventories

Workflow and process mapping should be accompanied by collection of all associated documents and a document analysis.
Document analysis helps define the data requirements associated with each process.
Vendors sometimes provide a tool for this, while a spreadsheet is often just as efficient and effective.
An applications inventory identifies all applications that currently exist and how they relate to one another.
It helps identify functional requirements as the new system leverages and interacts with current applications, and may identify applications the new system could replace.
A reports inventory documents all reports currently used or produced by current systems.
The reports inventory informs the functional assessment regarding what the new system must produce.

Question:

What does document analysis contribute that process mapping alone does not?
Distinguish the applications inventory from the reports inventory by what each informs.

Memory tips

Assessment versus analysis: the functional needs assessment captures what users need; the requirements analysis documents what the system will do.
Use case shape: an outside request, an actor, and the system's response.
Requirements analysis has two jobs: hold scope and supply test cases.
Two inventories: applications shows what exists and what could be replaced; reports shows what the new system must still produce.
Twelve requirement categories worth grouping: what it does (functional and workflow, reporting), what it must obey (regulatory, security, disaster recovery), what it runs on (data, platform, interfaces, network, client devices), and how it performs (response time, physical plant).

Key concepts

Functional needs assessment: the description of key capabilities or application requirements needed to achieve the envisioned benefits, gathered by surveying users and reviewing use cases
Use case: a scenario describing system behavior in response to a request originating outside the system, and the interaction between the initiating actor and the system
Requirements analysis: the documented record of what the system does, keeping the project aligned to scope, producing test cases and serving as the primary input for resource, cost and time estimates
Requirement categories: functional and workflow, reporting and analysis, regulatory, data and database, security, performance and response time, disaster recovery, platform compatibility, interface and interoperability, physical plant, client devices and network
Document analysis: the collection and review of process documents to define the data requirements of each process
Applications and reports inventories: records of existing applications and their relationships, and of current reports, both used to inform functional requirements

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: purpose of the functional needs assessment and why it is organization specific · surveying and prioritization by users · limits of early user understanding · user engagement and implementation success · the use case definition, actor interaction and clinician accessibility · progression from use case to functional requirements · inventory of current capabilities · the requirements analysis as record, scope control and test case source · future state and estimation role · the requirement categories · document analysis and data requirements · applications and reports inventories and their uses.

Read the original source

Functional Needs Assessment

The functional needs assessment describes the key capabilities or application requirements for achieving the benefits of the system as the organization has envisioned it.9 This process is important because every organization begins from a different starting point, every organization has different needs and every vendor offers a different approach.

This process is best achieved through surveying users and reviewing use cases. Users should be asked to identify what functionality they need and perhaps rank/prioritize them. Although in the early stages of the project a user's understanding of what may be possible may be limited, it is still important to understand this as you may need to plan for additional functionality in later phases of the project. Knowing this helps ensure that you are selecting a product that will best meet all these needs, including current and potential future needs. You may also be able to identify users who have had exposure to different systems and will be able to provide feedback regarding their experiences. This also allows users to be more engaged in the process which is a critical component of implementation success.

The use case approach is often easier for clinicians to understand. A use case is a scenario that essentially describes a system behavior as it responds to a request that originates outside of that system. It will describe the interaction between the actor who initiated the interaction (such as a clinician) and the system itself. Clinicians can began to form these use cases as they consider patient care events. From these depictions of scenarios, additional visualizations can be created, e.g. process diagrams, but ultimately it will result in a listing of functional requirements to achieve the patient care use case. As part of this, current functional capabilities can be inventoried which will help users see the scope of current capabilities, as well as establish a foundation on which to understand what essential functional capability may be missing and is needed in support of other, more robust capabilities.

Requirements Analysis

The requirements analysis is going to be the documented record of what the system actually does. It is a critical component to keep the project aligned with the identified scope. It is essential to the testing process, as the information gathered in the requirements analysis will produce test cases that can then be used to validate that the system meetings the project requirements. These use cases will begin with a high-level description of the process and will furthermore include a detailed description of each requirement. Often use cases will also include a graphical depiction. This document will describe the future state and is the primary input document for estimating resources, cost and time needed for the project. It will also take into account the needs assessment and further inform the needs prioritization. Requirements are often categorized as follows: functional and workflow, reporting/analysis capabilities, regulatory requirement, data/database, security, system performance and response time, disaster recovery, platform compatibility, interface and interoperability, physical plant consideration, client devices and network.

Document Analysis

In addition to documenting the sequence of steps and decision points in the process, workflow and process mapping should also be accompanied by a collection of all of the associated documents and a documents analysis should be performed. This will also help define the data requirements associated with each process. When working with a vendor they will sometimes provide organizations with a tool to conduct this, while other times a spreadsheet is just as efficient and effective.

Additional Inventories

In addition to the various information-gathering techniques described previously, some additional inventories to be considered include an applications inventory and a reports inventory. In the applications inventory the organization identifies all of the applications that currently exist and how they may or may not be related to one another. This too will help identify the functional requirements of the new system as it leverages and interacts with current applications. It may also help to identify additional applications that could be replaced by the new system. The reports inventory serves as a document of all of the current reports being used/produced by current systems. Again, this too can inform the functional assessment regarding what may need to be produced from the new system.

Chapter 4 · Analysis · Lesson 6 of 10

Process Improvement: DMAIC and PDCA

Big picture

This section defines process improvement and presents the two models the guide names for doing it. It follows requirements work because improvement opportunities surface as processes are examined, and addressing them before design produces a better system. The larger problem it solves is that automation locks in whatever process it encounters, so the improvement has to happen first. DMAIC and PDCA are the pair the exam tests: both are structured improvement cycles, but only one is described as data-driven with a control phase, and only the other is described as cyclical and iterative.

Walkthrough

What process improvement is

Process improvement is the business practice of identifying, analyzing and improving existing business processes.
Its aims are optimizing performance, meeting best practice standards, or improving quality and the user experience for customers and end users.
It goes by several names: business process management, business process improvement, business process re-engineering and continual improvement process.
Everything everyone does in an organization is part of a process, so improving the organization means focusing on the processes.
Improvement opportunities addressed before system design may save time in the long run and produce a better system.

Question:

Define process improvement and name its alternative names.
Why does the source place improvement before system design?

DMAIC

Define the opportunity for improvement.
Measure the performance of the existing process.
Analyze the process to find any deficiencies.
Improve the process by addressing the root causes uncovered.
Control the improved process and future process performance to correct deviations before they result in defects and to prevent reverting to the old way.

DMAIC is described as a data-driven quality strategy used to improve processes. The control phase is what separates it from a one-time fix: it exists to stop the process sliding back.

Example

A team measures lab turnaround, finds the bottleneck in specimen transport, redesigns the courier route and then holds a weekly control chart on turnaround. Without that last step the route quietly reverts.

Question:

Name the DMAIC phases in order and state what happens in each.
What is the control phase for, and what happens without it?

PDCA and PDSA

PDCA stands for plan, do, check or study, and act.
It is a cyclical and iterative four-stage management method used for control and continuous improvement of processes.

Plan: identify and analyze the problem or opportunity, develop hypotheses about the cause, and decide which to test.
Do: test the potential solution on a small scale and measure results.
Check or study: study results, measure effectiveness and decide whether the hypotheses are supported by the data.
Act: if the pilot solution is successful, implement it.

Question:

Name the PDCA stages and the activities in each.
How does PDCA differ from DMAIC in structure and emphasis?

Memory tips

DMAIC: Define, Measure, Analyze, Improve, Control. The last letter is the one distractors drop.
PDCA: Plan, Do, Check or Study, Act. Hypotheses are formed in Plan and tested in Do at small scale.
Model contrast: DMAIC is data-driven with a control phase to hold the gain; PDCA is cyclical and iterative, built around a small-scale test.
Four other names for process improvement: BPM, BPI, business process re-engineering, continual improvement process.
Principle to recite: everything everyone does is part of a process, so improving the organization means improving processes.

Key concepts

Process improvement: the practice of identifying, analyzing and improving existing business processes to optimize performance, meet best practice standards or improve quality and user experience
Alternative names: business process management, business process improvement, business process re-engineering and continual improvement process
DMAIC: the data-driven quality strategy of define, measure, analyze, improve and control, with control preventing deviation and reversion
PDCA or PDSA: the cyclical, iterative four-stage method of plan, do, check or study, and act, built on hypothesis and small-scale testing

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the definition and aims of process improvement · its alternative names · the everything-is-a-process principle · improvement before system design · the five DMAIC phases and their content including the purpose of control · DMAIC as data-driven · PDCA and PDSA naming · its cyclical and iterative character · the four stages and the activities within each.

Read the original source

Process Improvement

These various steps may also lead to process improvement opportunities throughout the analysis phase, and the project as a whole. As workflows and processes are examined and evaluated any improvement opportunities that can be addressed prior to the system design may save time in the long run and produce a better system. Process improvement involves the business practice of identifying, analyzing and improving existing business processes to optimize performance, meet best practice standards, or simply improve quality and the user experience for customers and end users. Process improvement can have several different names such as business process management (BPM), business process improvement (BPI), business process re-engineering and continual improvement process (CIP).12

Everything everyone does in an organization is part of a process. To improve the organization, you must focus on the processes. Process improvement is a fundamental step in business management and here are many different accepted ways to improve process. A couple of examples are the DMAIC and PDCA models.

DMAIC

DMAIC stands for define, measure, analyze, improve and control. The DMAIC model is a data-driven quality strategy used to improve processes.

- Define the opportunity for improvement

- Measure the performance of the existing process

- Analyze the process to find any deficiencies

- Improve the process by addressing the root causes uncovered

Control the improved process and future processes performance to correct deviations before they result in defects and to prevent reverting back to the “old way”

PDCA/PDSA

There is also the PDCA/PDSA model, which stands for plan, do, check/study and act. This is a cyclical model that is also iterative, following a four-stage management method used for the control and continuous improvement of processes.

Plan

Identify and analyze the problem or opportunity

Develop hypotheses about the cause of the problem

Decide which to test

Do

Test the potential solution on a small scale

Measure results

Check/Study

Study results

Measure effectiveness

Decide whether the hypotheses are supported by the data or not

Act

If the pilot solution is successful, implement it

Chapter 4 · Analysis · Lesson 7 of 10

Deficiencies in Current Practice and Alternative Approaches

Big picture

This section names four deficiencies measured against key performance indicators and proposes an IT-based alternative for each. It follows process improvement because the deficiencies are what improvement is aimed at. The larger problem it solves is scoping the achievable: some deficiencies can be fixed locally now, while others wait on industry-wide standardization. That local versus global distinction is the one the exam tests, since prescription errors and standardization sit on opposite sides of it.

Walkthrough

The four deficiencies

Patient support and satisfaction: unnecessarily high numbers of patients leave without treatment because of long waits.
Physicians see fewer patients per day when delays are caused by lack of proper equipment, and slow systems create extra work that degrades service quality.
Patient support and safety correlate with employee retention and satisfaction, and overwhelmed workers perform more poorly and leave more often.
Reduction in revenue generation: delays lower the number of patients attended per day, and patients who leave unattended are business lost.
Facilities also lose potential clients who would have been referred by customers annoyed by long waits.
Heavy workloads bring overtime expense, and inefficient facilities need significantly more workers to cope with physical workflow and lack of integration.
Prescription errors: the current system does not fully use software-supported decision-making for medication orders that would check diagnosis support, drug type and dosage.
The result is numerous prescription errors leading to adverse reactions and deaths, drug-related claims, legal penalties and license withdrawals.
Industry standardization: continued lack of healthcare IT standards has cost opportunities to improve interoperability, data sharing and transitions of care.
That will change when sustainable policy frameworks are agreed by IT experts and enforced by government.

Question:

Name the four deficiency areas and the KPI each is measured against.
Trace how patient wait times reach business loss in the source's account.

The alternatives proposed

Industry standardization: the Healthcare Information Technology Standards Panel and the Office of the National Coordinator have made positive achievements over recent decades.
Future initiatives might include a new integrated architecture meeting a cross section of market needs and linking with major existing software and hardware such as EHRs, data management systems and imaging programs.
Prescription errors: unlike the global integration challenge, these can be handled from a local perspective while awaiting market integration standards.
Avoidance of adverse drug events is a major KPI addressable by IT implementation.
A clinical decision-support system provides updated prescription recommendations to nurses, physicians and other qualified workers.
It is typically integrated with EHR and CPOE systems to perform scenario analysis with appropriate patient backup before a prescription is written.
Revenue generation: financial processes are perhaps the easiest to simulate in IT integration because of their general nature and resemblance to other industries' financial processes.
Revenue generation draws primarily from workflow optimization.
That optimization reduces query time and queue time, reduces waiting through fast patient data retrieval and diagnostic support, and reduces laboratory scheduling and briefing time through fast decision-relay and online client information.
Online support lets patients obtain electronically signed lab results without queuing, and is achievable with modern web applications.
The effects are higher perceived efficiency and productivity, better customer experience and satisfaction, and therefore more referrals, revenue and growth.
Most workflow management software does not require very high initial investment compared with the capital requirements of a modern facility.

Local and global are the deciding axis. A CDSS can be installed in one organization this year, while interoperability standards require agreement and enforcement across the industry.

Question:

Which deficiency can be addressed locally and which must wait on industry agreement, and why?
Describe the CDSS alternative, including what it integrates with and when it acts.
What does revenue generation improvement draw on primarily?

Memory tips

Four deficiencies: patient support and satisfaction, revenue generation, prescription errors, industry standardization.
Scope test: prescription errors are local and solvable now; standardization is global and waits on policy frameworks enforced by government.
Named U.S. standardization bodies: HITSP and ONC.
Revenue lever: workflow optimization, working through query time, queue time, retrieval speed and decision relay.
Why finance is easiest to automate: its processes are general and resemble other industries'.

Key concepts

Patient support and satisfaction deficiency: patients leaving untreated after long waits, fewer patients seen per day, degraded service quality and its correlation with staff retention and satisfaction
Revenue generation deficiency: revenue lost through delays, unattended patients, forgone referrals, overtime expense and the extra staffing inefficiency requires
Prescription error deficiency: underuse of software-supported decision-making for medication orders, producing adverse reactions, claims, penalties and license withdrawals
Industry standardization deficiency: the continued lack of healthcare IT standards costing interoperability, data sharing and transitions of care
Standardization alternative: HITSP and ONC achievements and a possible integrated architecture linking major existing EHR, data management and imaging systems
Prescription error alternative: a clinical decision-support system integrated with EHR and CPOE performing scenario analysis before a prescription is written
Revenue alternative: workflow optimization reducing query, queue, waiting and scheduling time, supported by online results and communication

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the four deficiency areas measured against KPIs · the chain from wait times to lost business and staffing cost · prescription error causes and consequences · standardization losses and the conditions for change · HITSP and ONC · the proposed integrated architecture · local solvability of prescription errors · ADE avoidance as a KPI · CDSS function and integration points · financial process simulability · workflow optimization mechanisms and effects · investment scale of workflow software.

Read the original source

Deficiencies in Current IT Healthcare Practices

From the discussion provided above regarding process flows in the healthcare sector's IT policies and practices, it can be seen that there are still some obstacles to customer satisfaction, healthcare business profitability and industry integration. These obstacles, which are restricting the sector's potential growth, will be analyzed in this section based on the industry's key performance indicators (KPIs). Client satisfaction through good services and support, business growth through revenue generation, efficient service process arrangement and proper implementation integration can be attained through the corporate initiative.

Patient Support and Satisfaction

Unnecessarily high numbers of patients leave healthcare units without treatment due to long waits for service. Physicians see fewer patients per day when lengthy delays are caused by lack of proper equipment. Such slow systems also lead to extra work for the available personnel, which causes degradation in service quality. Proper patient support and safety also have a correlation with employee retention and employee satisfaction. When healthcare workers are overwhelmed, they tend to perform more poorly and have higher exit rates than workers in places where IT supports workflow management.

Reduction in Revenue Generation

Many healthcare systems are not efficient in revenue generation, and there is a possibility for improvement through IT innovation. Delays in customer service lead to low numbers of attended patients per day, which results in revenue losses. In addition, many patients leave unattended, which leads to business loss. On top of this, healthcare facilities lose potential clients who might have been referred by existing customers if they had not been annoyed by long wait times. In addition to losing business, healthcare units incur extra expenses due to overtime work by doctors and nurses when workloads are heavy. These increased operational expenses and reduced business revenue contribute to overall reduction in business profitability. Inefficient facilities also require a significantly higher number of workers to cope with the physical workflow and lack of integration, which results in extra costs.13

Prescription Errors

The current healthcare system does not fully utilize software-supported decision-making for medication orders, even though it would greatly enhance the checking of prescriptions to ensure proper diagnosis support, drug type and dosage. This has resulted in numerous prescription errors, which may lead to adverse patient reactions and deaths. Improper prescriptions have also led to an increase in drug-related claims, legal penalties, license withdrawals and other challenges that could be avoided by proper IT support.

Industry Standardization

Continued lack of healthcare IT standards has led to the loss of tremendous opportunities to improve interoperability, data sharing and transitions of care. This situation will be significantly changed when sustainable policy frameworks can be agreed upon and implemented by IT experts and enforced by government to expand the implementation of IT integration.

Alternative Approaches to Current Healthcare Processes

To increase revenue, provide a seamless link between facilities and regions and improve the patient experience in healthcare workflows, certain IT-based procedures can be implemented. The following sections explore these alternatives according to the deficiency area.

Industry Standardization

The Healthcare Information Technology Standards Panel (HITSP) and the Office of the National Coordinator (ONC) have made many positive achievements in IT integration over the last couple of decades. While there are numerous challenges in such an attempt and many success stories, we continue to work toward this accomplishment through different avenues.14 Future initiatives might include a new integrated architecture that would meet a cross section of market needs. This platform would be such as to link with all major existing software and hardware configurations in the market, such as EHRs, data management systems (DMSs) and imaging programs, among others.

Alternative Ways to Reduce Prescription Errors

Unlike the global integration challenge, prescription errors can be handled from a local perspective while awaiting the market integration standards. Many software applications are dedicated to prescription information and decision-support systems. Avoidance of ADEs is one major KPI that can be addressed by IT implementation in the healthcare sector. One such software category is a CDSS, which provides updated information regarding recommendations for prescriptions to nurses, physicians and other qualified healthcare workers. This system is typically integrated with the EHR and CPOE systems in order to perform a proper scenario analysis with appropriate patient backup before a provider writes a prescription. Many commercially available software options offer this functionality.

Alternative Processes for Revenue Generation

Financial processes are, perhaps, the easiest to simulate in IT process integration due to their general nature and resemblance to other industries’ financial processes. Revenue generation draws primarily from workflow optimization, which mainly seeks to reduce query time and thus queue time, reduce waiting time through the implementation of fast patient data retrieval and diagnostic support and reduce laboratory scheduling and patient briefing time by enhancing fast decision-relay procedures and online client information alternatives. Online support may be an easy way for patients to obtain their lab results electronically signed by their care providers without having to wait in queue. Such a system is not out of reach and may be developed by most modern web applications. In addition to saving time and encouraging more customers, an IT-based process would lead to higher levels of perceived efficiency, productivity, better customer experiences and satisfaction and therefore more referrals.

This chain of flow would, in turn, generate more revenue and lead to higher growth rates. Many software applications have support for workflow management, and most of them do not require very high initial investments in comparison to the average capital requirements of a modern healthcare facility.

Chapter 4 · Analysis · Lesson 8 of 10

Comparative Analysis, the Work Plan and Benefits Realization

Big picture

This section moves from analysis to the plan that will carry the work, covering the comparison of current against expected state, the elements of a work plan and who governs its resources. It follows the alternatives because a chosen alternative has to become a sequenced plan with owners. The larger problem it solves is accountability: resources without a governing committee and a timeframe drift. The pair worth separating is the cost-benefit analysis and the benefits realization plan, because one projects value before the decision and the other confirms it after implementation.

Walkthrough

Comparative analysis of alternatives

The comparative analysis summarizes the current versus expected status of various aspects of a healthcare IT implementation.
Intended achievements attributable to the new system are presented in a table and supported by research into IT-related healthcare practices.
The extent to which key industry players benefit may vary, but the net results are likely to be beneficial.
Capital implications of implementing IT-based support systems are within investment range.
Long-term investment costs should be recoverable from the benefits obtained from healthcare interoperability.

Question:

What does the comparative analysis present, and what claim does the source make about recovering its costs?

Work plan elements

A work plan establishes a step-by-step implementation setup for a project.
It covers materials and equipment layout, intended workflow processes, time management, process analysis and outcome evaluation.
It puts procedures in place to realize the needs for IT acceptance, starting with the primary priorities and proceeding to others.
Executive summary: states the purpose of analyzing current system efficiency and providing an IT-enhanced alternative, and defines the implementation phases and the operations in each.
Introduction and background: describes the challenges that have made IT policy implementation complex and nonstandardized, including individual interests among providers, manufacturers, pharmaceutical companies and regulators.
Goals and objectives: the goal is a structure for IT integration covering cost-effectiveness, patient safety and care, ease of processes and industry standardization.

The stated objectives

Evaluate the current operational situation in each facility, including process mapping and documentation of current trends.
Identify the major problems in those processes with respect to optimizing IT use, comparing current efficiency with what IT implementation typically achieves.
Identify alternative solutions through IT policy, including software and hardware recommendations and a proposed interface with existing resources.
Carry out a comparative analysis of the alternative processes and the original routines using flow charts, tables and process flows.
Evaluate alternative solutions against the specific objectives set out in the plan.
Evaluate the ethical, legal, social and economic implications of the alternatives through a comprehensive cost-benefit analysis.
Develop a proposal for implementing recommendations and follow up after the project to enable quality improvement.

The last objective is the benefits realization step. Following up after the project is what distinguishes a plan that projected value from one that confirmed it.

Question:

Name the work plan sections and what each contains.
Reconstruct the seven objectives in order.
Which objective covers benefits realization, and how does it differ from the cost-benefit analysis?

Resources and accountability

Personnel covers everyone contracted in the rollout, including software support teams, simulation teams, project evaluation teams, engineers, technical teams and other necessary staff.
Partners may be governments, government-sponsored partners, nongovernment organizations and private investment agencies.
Equipment includes facilities and computers, software and related capital purchases.
Legal and regulatory infrastructure intended for the implementation of IT is the fourth resource category.
Resources are regulated and governed by a project management or steering committee.
That committee is responsible for budgetary allocations, expenditure monitoring and accounts reconciliation.
Time management is essential to complete the implementation phases within the specified timeframe.

Example

A steering committee that approves the budget but never reviews expenditure has done one of its three jobs. Allocation, monitoring and reconciliation are named together for that reason.

Question:

Name the four resource categories in a work plan.
What three financial responsibilities belong to the project management or steering committee?

Proposal objectives and alignment

The organizational business plan for most healthcare facilities has four major objectives: patient satisfaction, revenue generation, efficient processes that cut costs and increase profits, and conformity to industry standards.
The proposed solution model should meet all of those requirements.
Patient satisfaction comes from efficient processes that reduce delay, improve experience and follow up on patient issues.
Revenue generation is enhanced by shortened staff time per patient, raising daily attendance.
Process efficiency reduces duplication and improves service quality, increasing revenue through cost cutting.
The proposal expressly seeks to establish a platform for standardization of healthcare IT processes.

Question:

Name the four business plan objectives a proposal must satisfy.
Explain how a proposal should be judged against strategic and operational plans rather than against a competitor's choices.

Memory tips

Work plan sections: executive summary, introduction and background, goals and objectives, resources, accountability.
Resource four: Personnel, Partners, Equipment, Legal and regulatory infrastructure.
Committee duties three: budgetary allocation, expenditure monitoring, accounts reconciliation.
Business plan objectives four: patient satisfaction, revenue generation, efficient cost-cutting processes, conformity to industry standards.
CBA versus benefits realization: the analysis projects value before the decision; the follow-up after the project confirms it and feeds quality improvement.

Key concepts

Comparative analysis: the summary of current versus expected status of a healthcare IT implementation, with costs expected to be recoverable from interoperability benefits
Work plan: the step-by-step implementation setup covering materials and equipment, workflow, time management, process analysis and outcome evaluation, beginning with the primary priorities
Executive summary: the work plan section stating project purpose and defining the implementation phases and their operations
Work plan objectives: evaluating the current situation, identifying problems and alternatives, comparing alternatives with current routines, evaluating alternatives against plan objectives, assessing ethical, legal, social and economic implications through cost-benefit analysis, and proposing implementation with follow-up for quality improvement
Resource categories: personnel, partners, equipment, and legal and regulatory infrastructure
Work plan accountability: the project management or steering committee responsible for budgetary allocation, expenditure monitoring and accounts reconciliation, within a specified timeframe
Business plan objectives: patient satisfaction, revenue generation, efficient processes that cut cost and raise profit, and conformity to industry standards

Practice questions

15 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the purpose and claims of the comparative analysis · work plan definition and coverage · executive summary, introduction and background content · the goal statement and the seven objectives · follow-up for quality improvement · the four resource categories · steering committee responsibilities and time management · the four business plan objectives and how the proposal meets each.

Read the original source

Comparative Analysis of Alternatives

This section summarizes the current versus expected status of various aspects of a healthcare IT implementation.

Intended achievements attributable to the new system implementation are presented in Table 4.1 and supported by various research into IT-related healthcare practices. While the extent to which key industry players may benefit from the implementation of these new IT practices may vary, it is likely that the net results will be beneficial.15 In addition, the capital implications of implementing IT-based healthcare support systems are within investment range. Long-term investment costs should be recoverable from the benefits obtained from healthcare interoperability.

Table 4.1 Comparative Analysis of Core Processes in Healthcare

Work Plan Development

Also part of this phase is the start of the development of the work plan. A work plan is aimed at establishing a step-by-step implementation setup for a project, including materials and equipment layout, intended workflow processes, managing the time, analyzing processes and evaluating outcomes. In the healthcare IT implementation plan, a proper work plan involves putting in place procedures to realize the needs for IT acceptance by healthcare facilities, starting with the primary priorities and proceeding to other priorities.6 Sample elements of a work plan are presented below.

Executive Summary

This project is aimed at analyzing the efficiency of the current systems in healthcare and assessing the situation with the purpose of providing a working alternative that is IT enhanced and will lead to the realization of target objectives of the sector. The plan will provide the project implementation phases as well as define specific operations to be carried out during each phase.

Introduction and Background

The implementation of IT policies in healthcare has been faced with many challenges, rendering the process complex and nonstandardized.15 Establishing a comprehensive industry standardization process has been impossible due to various individual interests among care providers, drug and device manufacturers, pharmaceutical companies and regulating bodies. Thus, there has been a diverse range of new drugs and other medication practices localized in small market segments without proper administration and regulation. In addition, a wide network of healthcare facilities operating in different geographical, economic, technological and cultural settings has made it difficult for the various stakeholders to come together and develop an enhanced global EHR system that will ensure standardization of procedures, leading to a net lag in technology acceptance in the healthcare sector. The IT sector, however, has advanced and infiltrated all major sectors on the global platform, forcing all industries to confirm or become outdated. This is the case in the healthcare sector as well, prompting stakeholders to start seeking urgent and sustainable methods in preparation for standardization and alignment with emerging trends on the global IT platform.

Goals and Objectives

The goal of this work is to find a structure for IT integration in the healthcare sector's main processes, which includes cost-effectiveness, patient safety and care, ease of processes and industry standardization. To this end, specific objectives must be identified initially that include the following:

Evaluation of the current operational situation in each healthcare facility. This step will include analysis of current clinical processes such as process mapping. It will also document the current trends that can be found in healthcare procedures, including administrative and operational trends and integration of workflows.

Identification of the major problems in these processes with respect to the optimization of the IT use. This stage will involve comparing the efficiency of the current processes with the efficiency typically achievable in a similar setting with IT implementation.

Identification of alternative solutions to these problems through the implementation of IT policies. This process will involve providing alternative solutions to the current processes and include software and hardware recommendations, as well as a proposal for a working interface with existing resources.

Carrying out a comparative analysis of the alternative processes and the original routines. Flow charts, tables, process flows and other analytic tools will show relationships and deviations between the systems, thereby guiding the policy implementation decisions.

Evaluation of alternative solutions in alignment with the specific objectives set out in the plan. This stage will involve rethinking the project intentions and comparing them with realized outcomes to assess efficiency.

Evaluation of the ethical, legal, social and economic implications of the alternatives through a comprehensive cost–benefit analysis.

Developing a proposal for implementing recommendations and following up after the project to enable quality improvement.

Resources

The plan will usually involve the purchase of additional materials, as well as the hiring of support staff. The major resources should be assigned as follows:

Personnel - The category will involve all people contracted in the rollout process, including software support teams, simulation teams, project evaluation teams, engineers in various capacities, technical teams and other necessary personnel.

Partners - These may be governments, government-sponsored partners, nongovernment organizations and private investment agencies, among other stakeholders.

Equipment - This includes facilities and computers, software and related capital purchases.

Legal and regulatory infrastructure intended for the implementation of IT.

Work Plan Accountability

The resources available for the implementation of a proposal will be regulated and governed by a project management or steering committee that will be responsible for budgetary allocations, expenditure monitoring and accounts reconciliation. In addition, time management will be essential in order to complete the phases of the project implementation within the specified timeframe.

Chapter 4 · Analysis · Lesson 9 of 10

Proposal Evaluation: Cost-Benefit and Sensitivity Analysis

Big picture

This section covers how a proposal is tested financially: who the stakeholders are, which variables the feasibility study weighs, how a multi-year cost-benefit analysis is built and what sensitivity analysis adds. It follows the work plan because a plan with owners still needs a defensible number. The larger problem it solves is timing: costs and benefits do not arrive together, so leadership needs to see when the investment turns. Payback period and net present value are the pair to keep apart, since one answers when and the other adjusts for the value of money over time.

Walkthrough

The cost-benefit feasibility study

Stakeholders who stand to gain or lose are healthcare facilities, patients, medical practitioners' representative bodies, drug and medical equipment manufacturers, state and federal governments and related authorities, and computer equipment and software manufacturers and vendors.
Expected cost-benefit elements include finance, service quality, control and time.
The important variables are time of implementation, cost of implementation, alternatives to the proposal, impact on stakeholders, impact on external parties, sustainability versus ongoing operating costs per year, and value of time used in implementation.
Anticipated outcomes include continuous reduction in investment costs and a net increase in revenue generation for manufacturers of supporting products, healthcare facilities, and drug and medical equipment manufacturers.
The net long-term outcome for the patient is better service, improved quality of care and greater satisfaction.
Benefit categories in the sample study include reduced prescription errors and resources wasted through adverse drug events, improved services, care and access to records, and access to a global interoperability platform.

Question:

Name the stakeholder groups in the feasibility study.
List the important variables the analysis considers.

The cost-benefit analysis

A cost-benefit analysis uses quantitative techniques to evaluate and measure the benefit of providing products or services against the cost of providing them.
Costs considered include hardware, software, installation and training, and maintenance and support.
Benefits considered include cost savings or avoidance achieved by new functionality, such as charge capture, decision support, diagnostic studies, financial management, medical record operations, nursing department and referral management.
Net impact is determined for each year by subtracting the cost from the benefits.
A detailed analysis factors in present value and determines accumulated net present value.
A typical period such as five years is established and the exercise is repeated for each year.
The analysis shows visually how costs change over time, including front-loaded costs with lower ongoing costs and one-time costs, and when benefits are realized.
Mapping costs and benefits makes it easier to identify the payback period of the investment and when the organization will see a financial benefit.
It provides validation that the benefits of the recommended solution are equal to or greater than the costs.
Information from the RFP or RFQ can be used to inform the cost-benefit analysis.

Example

A five-year analysis with most cost in year one and benefits building from year three tells leadership to expect a deficit before the return. That is not a weak business case; it is the shape of an infrastructure investment stated honestly.

Question:

State how net impact is calculated each year and what net present value adds.
Define the payback period and explain when a CBA validates a recommendation.

Sensitivity analysis

A proposed IT implementation may show varying levels of sensitivity to different stakeholders at different times, and to all stakeholders over time.
The project's sensitivity to challenges or environmental change relies on establishing a support team to ensure conformity of the project's elements and initiatives.

Question:

What does sensitivity analysis examine, and what does the source say it relies on?

Memory tips

Feasibility variables seven: implementation time, implementation cost, alternatives, stakeholder impact, external party impact, sustainability versus annual operating cost, value of time used.
CBA arithmetic: benefits minus costs for each year, repeated across a typical five-year period, then present value and accumulated net present value.
Payback period is the point where accumulated benefit catches accumulated cost. NPV is the adjustment for time value, not a schedule.
Validation test: benefits equal to or greater than costs.
Cost buckets four: hardware, software, installation and training, maintenance and support.

Key concepts

Cost-benefit feasibility study: the evaluation of who gains or loses, across finance, service quality, control and time, weighing implementation time and cost, alternatives, stakeholder and external impact, sustainability against operating cost, and the value of time used
Cost-benefit analysis: a quantitative comparison of the benefit of providing products or services against the cost of providing them, calculated as benefits minus costs per year over a typical five-year period
Net present value: the accumulated present-value adjustment applied to a multi-year cost-benefit analysis
Payback period: the point at which the investment is recovered and the organization begins to see financial benefit
Sensitivity analysis: the examination of how a proposal's sensitivity varies by stakeholder and over time, supported by a team ensuring conformity of project elements

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the stakeholder list · cost-benefit elements · the important analysis variables · anticipated outcomes for manufacturers, facilities and patients · sample benefit categories including ADE waste reduction · the CBA definition · cost and benefit components · annual net impact, present value and accumulated NPV · the five-year convention · cost timing visualization · payback period identification · validation that benefits equal or exceed costs · RFP and RFQ as CBA inputs · sensitivity variability and the support team requirement.

Read the original source

Proposal Evaluation

The organizational business plan for most healthcare facilities has four major objectives: patient satisfaction, revenue generation, efficient processes that cut costs and increase profits and conformity to industry standards. The proposed solution model should meet all those requirements. First, patient satisfaction is achieved through efficient processes that reduce delay time, enhance the customer experience and offer a good follow-up on patient issues. Second, revenue generation is enhanced through shortened staff time spent per patient, which leads to increased daily patient attendance figures. Third, efficiency in the process flows reduces work duplication and improves service quality, both of which increase revenue generation through cost cutting. Fourth, the proposal expressly seeks to establish a platform for standardization of healthcare IT processes. In summary, the proposed solution enhances the general business requirements and objectives for the average healthcare provider and ultimately the patient. Additionally, the following tools may also strengthen the proposal.

Cost–Benefit Feasibility Study

The stakeholders who stand to gain or lose due to this policy implementation are healthcare facilities, patients, medical practitioners’ representative bodies, drug and medical equipment manufacturers, state and federal governments and related authorities and computer equipment and software manufacturers and vendors. The expected cost–benefit elements include finance, service quality, control and time, among others. The important variables to be considered in the analysis are the time of implementation, cost of implementation, alternatives to the proposal, impact on stakeholders, impact on external parties, sustainability versus ongoing operating costs per year and value of time to be used in the implementation.

Table 4.2 provides a sample of a cost–benefit feasibility study for the enhanced IT project.

Table 4.2 Cost–Benefit Feasibility Study of Proposed Healthcare IT Implementation

Variables

Costs

Benefits

Financial implications

Internal equipment and software upgrade

Licensing fees

Loss of investment for users of nonstandard applications

Increased revenues of up to 50% per year

Access to the global interoperability platform

Customers

Possible compromise of privacy and safety due to malicious information access and manipulation

Improved services, care and access to records

Reduction of prescription errors and resources wasted due to ADEs

Drug and medical equipment manufacturers and related bodies

Possible losses in equipment standardization, but generally minimal negative effects

Better policy implementation due to globalization of standards

Less counterfeiting and associated losses

Possibility of forming stronger representative bodies

Governments

standards

Reduced control of medical and healthcare practices for member states

Possible realignment of the structure to include international representation

Increased diplomatic ties

Better availability of globally competitive healthcare standards for citizens

Achievement of core objective of standardization of healthcare

Hardware and software developers and manufacturers

Possible loss of business for companies whose products fail to support the new standards

Numerous opportunities for new developments and increase in sales

The anticipated outcome of the cost–benefit feasibility study predicts a continuous reduction in investment costs and a net increment in revenue generation for manufacturers of products that support or can be adapted to the new standard, healthcare facilities and drug and medical equipment manufacturers. Similarly, the net long-term outcome for the patient is better service, improved quality of care and greater satisfaction.

Proposal Sensitivity Analysis

Any proposed IT implementation may exhibit various levels of sensitivity to different stakeholders at different times and also to all stakeholders over the course of time. The project's sensitivity to these challenges or changes in the environment will rely on the establishment of a support team to ensure conformity of a project's various elements and initiatives.

Cost–Benefit Analysis

The information obtained from these processes, more so the RFP or RFQ, can also be used to inform a cost–benefit analysis (CBA). A CBA is a process that uses quantitative techniques to evaluate and measure the benefit of providing products or services compared to the cost of providing them.9 The CBA is going to evaluate both the costs (considering things such as hardware, software, installation and training, maintenance and support) and the benefits (considering things such as cost savings or avoidance that are achieved by the new functionality [e.g. charge capture, decision support, diagnostics studies, financial management, medical record operations, nursing department, referral management, etc.]). Taking into consideration the costs and achieved benefits, the net impact is determined for each year by subtracting the cost from the benefits (in Figure 4.4 below this in depth CBA factored in the present value (PV) and determined the accumulated net present value (NPV)). A typical period is established, such as five years, and the exercise is repeated for each year identifying both the costs and benefits for each year. The CBA also visually shows how costs change over time, e.g. many being front-loaded with lower ongoing costs or some being one-time costs and how and when benefits are realized. Once the costs and benefits are mapped, it becomes easier to identify how long it will take to achieve the payback period of the investment and furthermore when the organization will actually see a financial benefit from the implementation and provides that validation that the benefits of the recommended solution are equal to or greater than the costs.

Chapter 4 · Analysis · Lesson 10 of 10

Acquisition Documents: RFI, RFP, RFQ and the NDA

Big picture

This section covers the documents that move an organization from a market of vendors to a contract with one. It closes the chapter because acquisition depends on everything before it: strategic objectives, usability requirements, the functional needs assessment and the buy versus build decision. The larger problem it solves is comparability, since vendors answer the same questions only when they are asked the same questions. RFI, RFP and RFQ are the trio the exam tests, separated by formality, commitment and what each is trying to obtain.

Walkthrough

What the acquisition process is trying to answer

Systems planning and analysis feed the acquisition strategy: strategic objectives, usability requirements, the functional needs assessment and the buy versus build decision.
If the decision is to buy, a formal selection process follows, covered later in the guide.
Information gathering on viable products and vendors begins with the RFI and RFP processes.
Does the vendor share the same vision for the product as the organization?
Does the product meet the key functionality needed to achieve the organization's strategic objectives?
Does the product or vendor use the appropriate technology?
Does the vendor qualify under the organization's acquisition policies?
Can the vendor support the organization's implementation strategy?
What is the vendor's track record for operations and maintenance support?
What is the vendor's viability in the market?

Question:

Reconstruct the seven questions the acquisition process should answer about a vendor and product.

Request for information

RFIs are used less today because information traditionally requested through them is largely available on company websites and through demonstrations and trade shows.
An RFI is an informal request for information that does not require commitment from either party.
It is a collection of documents designed to gather information on prospective vendors and their ability to meet the defined need or high-level requirements.
It is generally a two or three page set of questions.
Company background covers size, years in business, number of employees and product lines.
Product information covers product name, product history, technical platform and an overview of capabilities.
Market information covers major competitors and key differentiators.
Installed base and clients covers number of products sold, how many are currently implementing and how many are fully installed.
Special criteria covers anything the vendor identifies as unique or critical.
The RFI plus website research should produce a pool of about 10 to 20 products or vendors, to be narrowed to a handful.
A vendor comparison map plots responses to key criteria and helps narrow the large list.

Question:

Name the five RFI content areas and what each asks for.
What vendor pool size does the RFI process produce, and what tool narrows it?

Request for proposal

The RFP is a formal request sent to vendors that ultimately leads to a contract with the selected vendor.
It obtains more detailed information with more specificity about identified system requirements.
All vendors are asked the same questions, fostering a consistent review and selection process.
It is most appropriate to send the RFP to the four or five vendors that best fit the organization's criteria, though public organizations may be required to send it to every eligible vendor.
Organizational profile: demographics, mission and goals, product vision, current information infrastructure, constraints, response instructions, copy counts and how vendor questions are directed.
Vendor information: size and longevity, years in business, revenues, profitability, employees, research and development history and plans, installation types, corporate composition, references, user group information and contract history.
Functional specifications: functional capability and the processes and workflows the product supports.
Operational requirements: data architecture, analytical processes supported, necessary interfaces, reliability and security features, system capacity, expansion capabilities, response time, downtime and other maintenance issues.
Technical requirements: the proposed technical architecture to meet functional and operational needs, with specific hardware, networking and software requirements.
Application support: the proposed implementation schedule covering data conversion, acceptance testing, training and documentation, and ongoing support and maintenance including service level agreements and upgrades.
Licensing and contractual details: bid for one-time and recurring costs, standard contract, financing arrangements, proposed relationship with hardware vendors, warranty information and clauses protecting the organization if the vendor goes out of business.
Evaluation criteria: tells the vendor up front the most important evaluation elements and how factors are weighted.

Sending every vendor the same questions is the mechanism that makes responses comparable. Publishing the weighting in advance is what keeps the comparison honest.

Question:

Name the RFP sections and one item from each.
Which section carries data conversion, acceptance testing, training and service level agreements?
Why does the RFP go to four or five vendors, and what exception applies to public organizations?

Request for quotation and the non-disclosure agreement

An RFP may include pricing, but it has become common to also complete a request for quotation or request for bid to obtain a price from which to negotiate.
This approach minimizes the influence of cost on the other critical evaluation factors obtained through the RFP.
The RFQ can be more suitable than the RFP when the organization has thoroughly studied products and concluded that a small number are very similar.
Organizations should consider sending a non-disclosure agreement or confidentiality agreement to each vendor.
The purpose of an NDA is to protect both companies from disclosing confidential information.
It states in legal terms that the vendor cannot disclose information about the organization without express permission, and may be written as a two-way NDA.
Any vendor being sent confidential information should sign and execute the NDA before information is released.
Similar confidentiality terms may already sit in a master client agreement, making an additional NDA unnecessary.
Breaching these agreements can be very costly, so the terms and the definition of confidential information must be understood.
Legal counsel should review the terms of any agreement signed.

Example

An organization that has already narrowed to two near-identical products does not need another round of functional questions. It needs a price to negotiate from, which is the RFQ's job.

Question:

When is an RFQ more suitable than an RFP, and what does it protect the evaluation from?
State the purpose of an NDA, when it must be executed and who should review it.

Memory tips

Document ladder: RFI is informal with no commitment and gathers 10 to 20 vendors; RFP is formal, identical questions, four or five vendors, leads to contract; RFQ obtains a price to negotiate from.
RFI five areas: company background, product information, market information, installed base and clients, special criteria.
RFP section cues: application support carries conversion, testing, training and SLAs; evaluation criteria carries the weighting disclosure; licensing and contractual carries the bid and the vendor-failure clause.
RFQ trigger: products already studied and very similar, so price is the remaining question.
NDA rule: signed and executed before confidential information is released, possibly two-way, possibly unnecessary if a master client agreement already covers it.

Key concepts

Acquisition strategy inputs: strategic objectives, usability requirements, the functional needs assessment and the buy versus build decision
Request for information: an informal, non-committing two or three page request covering company background, product information, market information, installed base and special criteria, producing a pool of about 10 to 20 vendors
Vendor comparison map: the tool plotting vendor responses against key criteria to narrow the list
Request for proposal: the formal request sent to about four or five best-fit vendors, asking all the same questions and leading to a contract
RFP sections: organizational profile, vendor information, functional specifications, operational requirements, technical requirements, application support, licensing and contractual details, and evaluation criteria
Request for quotation: a request for price from which to negotiate, suitable when products are already studied and very similar, keeping cost from influencing other evaluation factors
Non-disclosure agreement: the confidentiality agreement protecting both parties, executed before confidential information is released and reviewed by legal counsel

Practice questions

18 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: acquisition strategy inputs and the buy versus build decision · the seven vendor and product questions · declining RFI use and its reasons · the RFI's informal, non-committing character and its five content areas · the 10 to 20 vendor pool and the comparison map · the RFP's formality, uniform questions and contract path · recipient counts and the public organization exception · all eight RFP sections and their contents · RFQ purpose, suitability and effect on evaluation · NDA purpose, two-way form, execution timing, master agreement overlap and legal review · use of RFP and RFQ information for the cost-benefit analysis.

Read the original source

RFI/RFP/RFQ

The various processes of systems planning and systems analysis including determining the strategic objectives, defining the usability requirements, completing the various aspects that contribute to the functional needs assessment and determining the buy vs. build strategy, all contribute to the acquisition strategy. If a decision is made to buy a product, a formal selection process takes place and this is discussed more in Chapter 6. However, in these earlier phases the information gathering regarding viable products and vendor selection begins with the request for information (RFI) and request for proposal (RFP) processes. Through these two processes, the organization should be seeking to understand:9

Does the vendor share the same vision for the product as the organization?

Does the product meet the key functionality needed to achieve the organizations strategic objectives?

Does the product/vendor utilize the appropriate technology?

Does the vendor qualify in regards to the organizations acquisition policies?

Can the vendor support the organizations implementation strategy?

What is the vendor's track record for operations and maintenance support?

What is the vendor's viability in the market?

Request for Information

RFIs are not utilized today as much as they used to be. With the popularity of information sharing through web services and trade shows, much of the information that has traditionally been requested through the RFI process is largely available on a company's website and through demonstrations. However, a RFI is intended to be an informal request for information that does not require commitment from either party. It is a collection of documents designed to collect information regarding prospective vendors and their ability to meet the defined need or high-level requirements. Should an organization still desire to execute the RFI process, it is generally a two or three page set of questions on the following areas:9

Company background (size, years in business, number of employees, product lines)

Product information (product name, product history, technical platform, overview of product capabilities)

Market information (major competitors and identification of key differentiators)

Installed base and clients (number of products the company has sold, how may they are currently implementing, number fully installed)

Special criteria (anything that the vendor has identified as unique or established as critical)

This information in combination with website research should result in a pool of about 10 to 20 products/vendors, with the intent to narrow this list down to only a handful to further evaluate. Tools like a vendor comparison map, which can be used to plot responses to key criteria and help narrow down the large list of vendors to the smaller list to pursue further.

Request for Proposal

Once the list has been narrowed, the organization should then complete the RFP process. The RFP is a formal request sent to vendors that ultimately leads to a contract between the organization and the selected vendor(s). This process is used to obtain more detailed information with more specificity placed on what the organization has identified as their system requirements. All vendors are asked the same questions, which helps foster a more consistent review and selection process. It would be most appropriate to send the RFP to the four of five vendors that seem to best fit the organization's overall criteria. Note here that the number of RFPs sent may also be dependent on the type of organization. Public organizations may be required to send RFPs to every eligible vendor. In general, RFPs have some fairly typical components including:9

Organizational profile (describes the organization seeking the new vendor including; basic demographics, mission and goals, vision for the product(s), current information infrastructure, any specific constraints, instructions for responding to the RFP, how many copies will be sent and how vendor questions will be directed)

Vendor information (description of its demographics (size and longevity, years in business, revenues, profitability, number of employees), product research and development history and plans, types of installations (number, size, status), corporate composition, references, user group information and contract history)

Functional specifications (description of functional capability and processes and workflows the product supports)

Operational requirements (data architecture, analytical processes supports, necessary interfaces, reliability and security features, system capacity, expansion capabilities, response time, downtime and other system maintenance issues)

Technical requirements (vendor should propose the appropriate technical architecture to meet the organization's functional specifications and operational requirements, specific hardware and networking and software requirements)

Application support (the proposed implementation schedule describing data conversion, acceptance testing, training and documentation, ongoing support and maintenance, which may include information regarding any service level agreements (SLAs) and upgrades)

Licensing and contractual details (supply the specific bid for one-time and recurring costs based on the organization's requirements, standard contract, financing arrangements, proposed relationship with hardware vendors, warranty information, any clauses that protect the organization should the vendor go out of business)

Evaluation criteria (provided to let the vendor know up front the most important elements of the evaluation and how certain factors are weighted)

Request for Quotation

Although a RFP may include pricing information (as described above in the licensing and contractual details description), it has also become more commonplace to also complete a request for quotation (RFQ) or a request for bid to obtain a price from which to negotiate.8 This approach can help minimize the influence of cost from the other critical evaluation factors obtained through the RFP process. The RFQ can be more suitable than the RFP if the organization has thoroughly studied products and concluded that a small number are very similar.

Non-Disclosure Agreement

As part of these processes, organizations should also consider sending a non-disclosure agreement (NDA) or confidentiality agreement to each vendor. The purpose of an NDA is to protect both companies from disclosing confidential information. An NDA includes legal terminology that, in effect, states that the vendor cannot disclose information about your company to anyone without your express permission. It may also be written as a two-way NDA, meaning that the organization cannot disclose information either.16 Any vendor who is being sent confidential information about your company should be sent the NDA and this should be signed and executed prior to releasing any information about your organization. In some cases, similar terms regarding confidential information that is exchanged between parties may be included in a master client agreement rendering an additional NDA unnecessary. Breaching these types of agreements can be very costly, so it is very important to understand the terms on agreement and identifying what is considered confidential.16 Your organizations legal counsel should be involved in reviewing the terms of any agreements that are signed.

Cost–Benefit Analysis

The information obtained from these processes, more so the RFP or RFQ, can also be used to inform a cost–benefit analysis (CBA). A CBA is a process that uses quantitative techniques to evaluate and measure the benefit of providing products or services compared to the cost of providing them.9 The CBA is going to evaluate both the costs (considering things such as hardware, software, installation and training, maintenance and support) and the benefits (considering things such as cost savings or avoidance that are achieved by the new functionality [e.g. charge capture, decision support, diagnostics studies, financial management, medical record operations, nursing department, referral management, etc.]). Taking into consideration the costs and achieved benefits, the net impact is determined for each year by subtracting the cost from the benefits (in Figure 4.4 below this in depth CBA factored in the present value (PV) and determined the accumulated net present value (NPV)). A typical period is established, such as five years, and the exercise is repeated for each year identifying both the costs and benefits for each year. The CBA also visually shows how costs change over time, e.g. many being front-loaded with lower ongoing costs or some being one-time costs and how and when benefits are realized. Once the costs and benefits are mapped, it becomes easier to identify how long it will take to achieve the payback period of the investment and furthermore when the organization will actually see a financial benefit from the implementation and provides that validation that the benefits of the recommended solution are equal to or greater than the costs.

Chapter 4 · Analysis · Supplemental lesson

Requirements Vocabulary and Data Quality

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Chapter 4 walks the analysis process well without supplying the formal vocabulary a systems-analysis text would. That vocabulary matters because the exam uses descriptor-to-term items that reward it. This lesson names the requirement families, the elicitation techniques, the specification artifacts and the data quality dimensions.

Walkthrough

Requirements, elicitation and specification

A requirement is a statement of what the system must do or must be.
Functional requirements state what the system does, such as alerting a prescriber when an ordered drug conflicts with a documented allergy.
Non-functional requirements state how well it does it and under what constraints, covering performance, availability, scalability, security, usability and regulatory conformance.
Non-functional requirements are the ones organizations forget to specify and then discover during testing.
Elicitation techniques: interviews for depth one stakeholder at a time.
Observation or job shadowing, which reveals what people actually do rather than what they say they do.
Joint Application Design, a structured facilitated workshop bringing stakeholders and analysts together to converge in compressed time, whose value is resolving conflicts in the room.
Document analysis, surveys and prototyping.
Specification artifacts: the use case, a named actor achieving a goal through a sequence of interactions with alternative and exception flows.
The process map or workflow diagram showing the sequence of work.
The data dictionary listing every data element with name, definition, type, allowed values, source and owner.
The entity-relationship diagram showing how data entities relate.
The requirements traceability matrix linking each requirement forward to design, build and the test that verifies it.

Example

The system shall be fast is untestable. Search results shall return within two seconds for 95 percent of queries under peak load is a verifiable non-functional requirement.

Question:

Distinguish functional from non-functional requirements and say which fails late.
Name the elicitation techniques and the defining feature of JAD.
What does a requirements traceability matrix link, and what does it prove?

Data quality dimensions

Completeness: is the element populated when it should be.
Conformance: does the value match the expected format, type and value set.
Plausibility: is the value believable given everything else, such as a systolic of 400.
Consistency: do the same facts agree across systems and over time.
Timeliness: is it current enough for the decision it supports.
Provenance: do we know where it came from and how it got here.
Definitional mismatch sits under consistency and is the most dangerous, because it produces plausible wrong numbers rather than obvious errors.

Question:

Name the six data quality dimensions and what each checks.
Why is definitional mismatch more dangerous than an obvious error?

Memory tips

Two requirement families: functional is what it does, non-functional is how well and under what constraints.
JAD cue: structured, facilitated, decision-makers present, conflicts resolved in the room.
Artifact set: use case, process map, data dictionary, entity-relationship diagram, traceability matrix.
Six data quality dimensions: completeness, conformance, plausibility, consistency, timeliness, provenance.
Traceability is what makes user acceptance testing meaningful rather than improvised.

Key concepts

Functional requirement: a statement of what the system does
Non-functional requirement: a statement of how well the system performs and under what constraints, covering performance, availability, scalability, security, usability and conformance
Elicitation techniques: interviews, observation or job shadowing, Joint Application Design workshops, document analysis, surveys and prototyping
Specification artifacts: use cases, process maps, data dictionaries, entity-relationship diagrams and the requirements traceability matrix
Data quality dimensions: completeness, conformance, plausibility, consistency, timeliness and provenance
Definitional mismatch: the consistency failure producing plausible wrong numbers when the same fact means different things across systems

Practice questions

12 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the definition of a requirement and the two families with examples · the late-failure pattern of non-functional requirements · each elicitation technique and JAD's defining feature · each specification artifact and its contents · the six data quality dimensions · definitional mismatch and its placement under consistency.

Read the supplemental lesson source

S4.1 — Requirements Vocabulary and Data Quality

Chapter 4 · Tasks III.A.1–A.5 · About 13 minutes

1. Learn the topic

Where this fits

Chapter 4 walks the analysis process well. What it lacks is the formal vocabulary a systems-analysis text supplies — which matters because CPHIMS uses descriptor-to-term items (archetype D) that reward exactly that vocabulary.

What it means: requirements

A requirement is a statement of what the system must do or must be. Two families:

Functional requirements — what the system does. "The system shall alert the prescriber when an ordered drug conflicts with a documented allergy."

Non-functional requirements — how well it does it, and under what constraints. Performance, availability, scalability, security, usability, regulatory conformance. "The alert shall display within two seconds at the 95th percentile."

Non-functional requirements are the ones organizations forget to specify and then discover during testing. That failure mode is testable.

How it works: elicitation and specification

Elicitation techniques — how you find out what's needed:

Interviews — depth, one stakeholder at a time.

Observation / job shadowing — reveals what people actually do, which routinely differs from what they say they do.

JAD (Joint Application Design) — a structured, facilitated workshop bringing stakeholders and analysts together to converge on requirements in compressed time. Its value is resolving conflicts in the room rather than discovering them across weeks of serial interviews.

Document analysis, surveys, prototyping.

Specification artifacts — how you record what you found:

Use case — a named actor achieving a goal through a sequence of interactions, with alternative and exception flows.

Process map / workflow diagram — the sequence of work.

Data dictionary — every data element: name, definition, type, allowed values, source, owner.

Entity-relationship diagram — how data entities relate.

Requirements traceability matrix — links each requirement forward to design, build and the test that verifies it. This is what lets you prove nothing was dropped.

How it works: data quality

Chapter 4 rightly warns that two accurate systems can produce a wrong combined number. Here is the named dimension set that turns that instinct into a checklist:

Completeness — is the element populated when it should be?

Conformance — does the value match the expected format, type and value set?

Plausibility — is the value believable given everything else? (A systolic of 400; a delivery date on a male patient.)

Consistency — do the same facts agree across systems and over time?

Timeliness — is it current enough for the decision it supports?

Provenance — do we know where it came from and how it got here?

Definitional mismatch — the failure your Topic 4.5 already covers — sits under consistency, and it is the most dangerous because it produces plausible wrong numbers rather than obvious errors.

Examples and non-examples

Straightforward. A requirement says "the system shall be fast." Untestable. Rewritten as "search results shall return within two seconds for 95% of queries under peak load," it is a verifiable non-functional requirement.

Connecting to another concept. The requirements traceability matrix is what makes user acceptance testing (lesson S7.1) meaningful. Without traceability, UAT tests whatever the tester thinks of.

Non-example. "The vendor's system is the best available" is not a requirement. It is a conclusion, and it presupposes the analysis rather than performing it — which is precisely the error your Topic 4.6 item flags about presenting one option to an executive.

Common misconceptions

"Non-functional requirements are less important." They are the requirements that cause go-live failures.

"JAD is just a long meeting." Its defining feature is structure and facilitation aimed at convergence, with decision-makers present.

"Data quality means accuracy." Accuracy is one aspect. A perfectly accurate value that arrived three days late, or that means something different in the source system, is still a data quality failure.

2. Exam focus

What you must know

Functional (what it does) vs. non-functional (how well, under what constraints).

Elicitation techniques by their distinguishing feature — especially JAD as facilitated group convergence and observation as the technique that catches the gap between stated and actual workflow.

Use case = actor + goal + interaction sequence. Data dictionary = element definitions. Traceability matrix = requirement-to-test linkage.

Data quality dimensions: completeness, conformance, plausibility, consistency, timeliness, provenance.

Distinctions likely to be tested

Requirement vs. specification vs. design. A requirement says what; design says how. Stems that describe a solution in the requirement slot are testing this.

Current state vs. future state vs. gap analysis (the explicit difference between them).

Interview vs. observation — a stem describing a discrepancy between what staff report and what they do is pointing at observation.

How this appears in a question

Descriptor-to-term (archetype D): the stem describes an artifact or technique and the options name four real ones. Also sequencing traps — requirements before design, design before build, traceability throughout.

3. Teach it back

Explain to a project sponsor:

1. Why you want to shadow nurses for a day when you have already interviewed the nurse manager.

2. What a traceability matrix buys them, in terms of a risk they would otherwise carry.

3. Give an original example of a data quality failure that would not be caught by checking accuracy.

<summary>Key-point checklist</summary>

[ ] Named the stated-vs-actual workflow gap as observation's specific value

[ ] Traceability = proof that every requirement was designed, built and tested; catches silent drops

[ ] Chose a dimension other than accuracy (timeliness, provenance, consistency, plausibility)

[ ] Distinguished functional from non-functional with an example of each

[ ] Kept requirement (what) separate from design (how)

</details>

4. Practice

Items SQ-25 to SQ-27.

5. Key takeaway

Requirements come in two families and are only useful when verifiable. Data quality has six dimensions and accuracy is only one — the dangerous failures are the ones that produce believable wrong answers rather than obvious errors.

Chapter 5 · Design · Lesson 1 of 6

Compatibility and Interoperability of System Components

Big picture

This section defines system design and states the two properties every new component has to satisfy before it enters the environment. It opens the Design chapter, which follows analysis in the Systems Management domain and depends on the requirements gathered there. The larger problem it solves is that healthcare enterprises buy continuously, so without a review process each purchase can create a hidden upgrade cost or a device that connects but cannot exchange anything useful. Compatibility and interoperability are the pair the whole lesson turns on: one is whether the component works in the environment, the other is whether it can exchange and use data across it.

Walkthrough

System design and what it must support

System design is the activity of proceeding from an identified set of requirements for a system to a design that meets those requirements.
A system is a set or assemblage of things connected, associated or interdependent so as to form a complex unity.
Healthcare IT systems must support advanced clinical functionality, patient accounting and financial accounting.
They must also support functionality demanded by new healthcare regulations, medical devices, mergers and acquisitions, and changes and advances in the IT industry.
Compatibility and interoperability are two key aspects of system design.
Compliance with applicable industry, regulatory and organizational standards is a fundamental aspect of design.
A key best practice is development of a comprehensive technical specification.
The design team documents specifications for infrastructure, network, security, application and use cases based on the requirements uncovered during system analysis.

Question:

Give the source's definitions of system design and of a system.
Name the four demands beyond core clinical and financial functionality that design must accommodate.

Reviewing purchases for compatibility

A healthcare enterprise owns and continually purchases hardware, software, network components and medical devices.
Hardware may include laptops, servers, mobile devices and tablets, each running an operating system not necessarily compatible with others.
Application software serves purposes from patient accounting to payroll, laboratory, pharmacy, radiology, dietetics and digital pathology.
Network components include wired and wireless routers, firewalls, cabling and Internet connectivity, and must support enterprise devices as well as patient and visitor Wi-Fi.
Medical devices such as ultrasounds, MRIs, patient monitors, ventilators and blood pressure cuffs provide information digitally and must connect to the network.
Organizations should define a process by which the IT department reviews purchases of any of these components for compatibility and interoperability.
Not all devices or software will work out of the box, and system upgrades may be needed to incorporate a device onto the network.
A new patient monitor may connect physically to the network yet be incompatible with the existing monitoring system that aggregates and distributes waveform data to the EHR.
The process requires close cooperation between IT and the procurement or purchasing department.
That cooperation avoids hidden costs of system or device upgrades and potential delays.

Example

A cardiology group buys monitors at a conference and asks IT to connect them afterward. The monitors join the network, the waveform feed does not, and the upgrade that makes it work is a cost nobody budgeted.

Question:

Why does the source insist IT review purchases before they are made?
Give the patient monitor example and explain what it illustrates about compatibility.

Interoperability in design

HIMSS defines interoperability as the ability of different information systems, devices or applications to connect in a coordinated manner within and across organizational boundaries.
The purpose of that connection is to access, exchange and cooperatively use data among stakeholders.
The goal is optimizing the health of individuals and populations.
In the patient monitor example, interoperability may mean an HL7 interface enabling admission, discharge and transfer notifications from the existing EHR.
Compatibility concerns whether components work together in the environment, while interoperability concerns coordinated connection and cooperative use of data.

Question:

State the HIMSS interoperability definition, including its boundary clause and its stated goal.
Distinguish compatibility from interoperability using the monitor example for both.

Memory tips

Two properties, two questions: compatibility asks does it work here, interoperability asks can it exchange and cooperatively use data here.
HIMSS definition keywords: connect in a coordinated manner, within and across organizational boundaries, access, exchange and cooperatively use, optimizing individual and population health.
Purchase review rule: IT reviews before purchase, in cooperation with procurement, to avoid hidden upgrade costs and delays.
Monitor example carries both properties: joining the network is compatibility, ADT notifications by HL7 interface is interoperability.

Key concepts

System design: the activity of proceeding from an identified set of requirements for a system to a design that meets those requirements
System: a set or assemblage of things connected, associated or interdependent so as to form a complex unity
Compatibility: whether new hardware, software, network components or devices work with the existing environment without unplanned upgrades
Interoperability: the ability of different systems, devices or applications to connect in a coordinated manner within and across organizational boundaries to access, exchange and cooperatively use data, with the goal of optimizing individual and population health
Purchase review process: the defined process by which IT reviews component purchases in cooperation with procurement to avoid hidden upgrade costs and delays
Technical specification: the comprehensive design document covering infrastructure, network, security, application and use cases, based on requirements from system analysis

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: definitions of system design and system · the functionality healthcare IT systems must support · compatibility and interoperability as key design aspects · standards compliance as fundamental · technical specification as key best practice and its coverage · the range of purchased components and their operating systems · network support for enterprise and visitor access · digital medical devices on the network · the IT purchase review process · the patient monitor example · cooperation with procurement and avoided hidden costs · the HIMSS interoperability definition and the HL7 ADT illustration.

Read the original source

Introduction

The Dictionary of Computing defines system design as “the activity of proceeding from an identified set of requirements for a system to a design that meets those requirements.”1 System design depends upon the definition of system, which, according to the Oxford English Dictionary, means “a set or assemblage of things connected, associated, or interdependent, so as to form a complex unity.”2 Healthcare information technology (HIT) systems today take that complexity to a new level in function and interoperability. These systems must support advanced clinical functionality, patient accounting and financial accounting and have been doing this for years. The systems must also support functionality demanded by new healthcare regulations, medical devices, mergers and acquisitions, as well as address changes and advances in the information technology (IT) industry.

Compatibility and interoperability are two key aspects of system design. Considering the complexity and criticality of enterprise IT systems in healthcare, it is essential to ensure any new medical devices, software, hardware, or network components are compatible and interoperable.

Compliance with applicable industry, regulatory and organizational standards is a fundamental aspect of system design. Healthcare organizations could face severe implications for not adhering to these standards. A key best practice in system design is the development of a comprehensive technical specification. The design team documents design specifications regarding the infrastructure, network, security, application and use cases based on the requirements uncovered during system analysis. For more information on defining and prioritizing system requirements, refer to Chapter 4 “Systems Analysis.”

ompatibility and Interoperability of System Components

Any healthcare enterprise today owns and continually purchases a plethora of hardware, software, network components and medical devices. The hardware may include laptop computers, servers, mobile devices and tablets, each running its own operating system (OS) that is not necessarily compatible with other operating systems. The application software that runs on these devices serves a variety of purposes from patient accounting to payroll, laboratory, pharmacy, radiology, dietetics, digital pathology and so on. Network components include routers (wired and wireless), firewalls, cabling and Internet connectivity. Networks today must support connectivity of devices within the enterprise as well as Wi-Fi access for patients and visitors. Medical devices such as ultrasounds, magnetic resonance imaging (MRIs), patient monitors, ventilators and even blood pressure cuffs all provide information digitally and must connect to the network as well. For more information on hardware, software and networks, refer to Chapter 2, “Technology Environment.”

Organizations should define a process by which the IT department reviews purchases of any of these components for compatibility and interoperability. Remember that not all devices or software will work out of the box. There may be system upgrades involved to incorporate the device onto the network. For example, a new patient monitor may connect to the existing network from a physical standpoint, but may not be compatible with the existing patient monitoring system used to aggregate and distribute waveform data to the electronic health record (EHR). This process dictates close cooperation between the IT department and the procurement/purchasing department so IT has a chance to review purchases, thus avoiding such hidden costs of system and/or device upgrades and potential delays.

Compatibility of medical devices and systems is just one dimension of systems design. Interoperability is equally important. HIMSS defines interoperability as “the ability of different information systems, devices, or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders, with the goal of optimizing the health of individuals and populations.”3 In the patient monitor example above, interoperability may translate to a Health Level Seven (HL7®) interface to the patient monitor to enable admissions, discharges and transfers (ADT) notifications from the existing EHR system.

Chapter 5 · Design · Lesson 2 of 6

Standards Compliance

Big picture

This short section states how many standards a healthcare organization answers to and what design is supposed to do about them. It follows compatibility because standards are the external version of the same question: not whether components fit each other, but whether they fit the rules. The larger problem it solves is that standards arrive from many bodies at once, some enterprise-wide and some departmental, so compliance has to be a process rather than a reaction. Standards compliance and the technical specification are linked here: the specification is where design addresses the standards.

Walkthrough

The standards landscape and the design response

Providers face a huge number of external standards from government and industry in addition to their own internal standards.
Some standards affect the entire organization and others affect just one department.
Some countries dictate which vendor IT system the organization must purchase.
ASTM International, HL7, DICOM and other international organizations publish many standards related to healthcare IT.
The Institute of Electrical and Electronics Engineers publishes standards for wired and wireless networking used by most countries in the world.
An enterprise must develop a process to address standards compliance, just as it has a process for component compatibility.
Given the number of standards, this is not a simple effort.
There must be an overlap between business process and compliance management.
System design should attempt to address standards by the clear definition of technical specifications.
Healthcare organizations could face severe implications for not adhering to industry, regulatory and organizational standards.

The named bodies are worth holding as a set, because the exam's distractors in this area are real organizations that publish standards for other industries or other purposes.

Question:

Name the standards bodies the source lists and what IEEE contributes.
How does the source say design should address standards, and what happens when standards are not met?
Give the source's example of how far a country may go in dictating standards.

Memory tips

Bodies named: ASTM International, HL7, DICOM, plus IEEE for wired and wireless networking.
Design's answer to standards is one thing: clear definition of technical specifications.
Scope split: some standards are enterprise-wide, some departmental, and some countries dictate the vendor system itself.
Compliance needs an overlap between business process and compliance management, not a one-time review.

Key concepts

External standards: the government and industry standards facing providers in addition to internal standards, some enterprise-wide and some departmental
Named standards bodies: ASTM International, HL7, DICOM and other international organizations, with IEEE publishing wired and wireless networking standards
Standards compliance process: the process an enterprise must develop, requiring overlap between business process and compliance management
Design response to standards: addressing standards through the clear definition of technical specifications, since non-adherence can carry severe implications

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the volume and sources of external standards · organization-wide versus departmental scope · national dictation of vendor systems · the named publishing bodies and IEEE's networking role · the requirement for a compliance process · the overlap of business process and compliance management · technical specifications as the design response · severe implications of non-adherence.

Read the original source

Standards Compliance

Healthcare providers face a huge number of external standards from government and industry, in addition to their own internal standards. Some of these affect the entire organization, and others affect just one department. Some countries even dictate which vendor IT system the organization must purchase. ASTM International, HL7, Digital Imaging and Communications in Medicine (DICOM®), and other international organizations publish many standards related to healthcare IT. The Institute of Electrical and Electronics Engineers (IEEE) publishes standards for wired and wireless networking used by most countries in the world. Just as an enterprise must have a process to address compatibility of system components, it must also develop a process to address standards compliance. Given the number of standards, this is not a simple effort. There must be an overlap between business process and compliance management. System design should attempt to address standards by the clear definition of technical specifications.

Chapter 5 · Design · Lesson 3 of 6

Industry Trends, Cybersecurity and the Design Team

Big picture

This section covers the process for absorbing change from outside the organization and the people who carry design work inside it. It follows standards compliance because trends are the standards and technologies that have not settled yet. The larger problem it solves is that areas once owned by other departments, telephony and medical devices in particular, now arrive on the IT network with their own risks. Sponsor and project manager are the roles most often confused: the sponsor defines business goals and how they are measured, then steps back from detailed design meetings.

Walkthrough

A process for industry trends

With extensive change in healthcare and technology, a process must exist or be created to evaluate and incorporate industry, technology, infrastructure, legal and regulatory trends.
The process must address areas that in the past were governed by departments other than IT.
Digitization of telephone systems means they generally share the same networks as IT and have become part of the IT organization.
Medical devices such as electrocardiographs, ultrasound and MRI devices generate millions of bytes of medically relevant data that must be integrated into the electronic patient record.
Purchase of such devices must include IT participation to ensure compatibility and interoperability with existing systems.

Question:

What five kinds of trend must the process evaluate?
Give two areas formerly governed outside IT that the process now has to cover.

Cybersecurity and medical devices

Cybersecurity is one of the most critical trending issues facing healthcare IT.
The greatest threat to healthcare networks comes from medical devices.
Many computerized medical devices connect to hospital enterprise networks.
Enterprise security was not included in the product requirements when many of these devices were developed.
Generally accepted IT security practices such as anti-virus software, firewall software and frequent password changes are often incompatible with medical devices or heavily restricted on them.
Some vendors discourage customers from using anti-virus software to scan files associated with medical devices.
Other vendors hard-code passwords or use obsolete commercial operating systems.

Example

An infusion pump running an unsupported operating system cannot be patched on the enterprise schedule and cannot be removed from the floor. The control that answers it is segmentation and monitoring, because the device itself cannot be hardened.

Question:

Why does the source name medical devices as the greatest threat to healthcare networks?
List the vendor practices the source cites as obstacles to securing devices.

Innovation centers and the design team

Many healthcare organizations have invested in innovation centers to develop and deploy healthcare technology innovations.
The Emory Healthcare Innovation Hub is the source's example, connecting the pieces of the healthcare continuum to validate, accelerate and realize ideas.
Its stated mission is improving health outcomes, increasing access to quality care, lowering overall costs and improving provider experiences.
Innovation centers develop solutions addressing problems in the dynamic healthcare environment.
Design team membership varies with the complexity and scope of the project.
The project sponsor should kick off the project with the team and help determine the business goals and how those goals should be measured.
Once the team is established and goals are defined, the sponsor may not need to be involved in more detail-oriented design meetings.
The potential team members are project sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, quality assurance analysts, information security officer, and stakeholders or users.

Question:

Name all nine potential system design team members.
State the sponsor's two responsibilities and when the sponsor steps back.

Memory tips

Trend categories five: industry, technology, infrastructure, legal, regulatory.
Cybersecurity headline: the greatest threat comes from medical devices, because enterprise security was not a product requirement when they were built.
Device obstacles three: anti-virus discouraged, passwords hard-coded, obsolete operating systems.
Design team nine: sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, QA analysts, information security officer, stakeholders and users.
Sponsor scope: kick off, set business goals and their measures, then withdraw from detailed design.

Key concepts

Trends process: the required process for evaluating and incorporating industry, technology, infrastructure, legal and regulatory trends, including areas once governed outside IT
Telephony and medical devices in IT: digitized phone systems sharing IT networks and data-generating devices requiring integration into the electronic patient record, with IT participating in their purchase
Medical device cybersecurity: the greatest threat to healthcare networks, arising because enterprise security was absent from product requirements and standard controls are restricted, discouraged or defeated by hard-coded passwords and obsolete operating systems
Innovation centers: organizational investments such as the Emory Healthcare Innovation Hub that validate, accelerate and realize healthcare technology ideas
System design team: the project sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, quality assurance analysts, information security officer, and stakeholders or users
Project sponsor: the member who kicks off the project and determines business goals and how they are measured, then steps back from detailed design meetings

Practice questions

7 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the required trends process and its five categories · areas formerly governed outside IT · telephony convergence · device data integration and IT participation in purchase · cybersecurity as a critical trend · medical devices as the greatest network threat and the reasons · vendor practices obstructing security · innovation centers and the Emory example and mission · design team variability · the sponsor's kickoff and goal-setting role and later withdrawal · the nine potential team members.

Read the original source

Process to Address Industry Trends

With the extensive changes occurring in healthcare and technology, a process must exist or be created to evaluate and incorporate industry, technology, infrastructure, legal and regulatory trends. This process must address areas that in the past were governed by departments other than IT. The digitization of telephone systems means that these systems generally share the same networks as IT and have become a part of the IT organization. Medical devices such as electrocardiographs, ultrasound and MRI devices now generate millions of bytes of medically relevant data and must be integrated into the electronic patient record. The purchase of such devices must include IT participation to ensure compatibility and interoperability with existing systems.

One of the most critical trending issues facing healthcare IT is cybersecurity. The greatest threat to healthcare networks comes from medical devices. Many computerized medical devices connect to hospital enterprise networks. In the development of these medical devices, enterprise security was not included in the product requirements. In many cases, generally accepted IT security practices like anti-virus software, firewall software and frequent password changes are not compatible with medical devices or the medical devices have significant restrictions on the use of these generally accepted security practices and tools. For example, some medical device vendors discourage customers from using anti-virus software to scan files associated with medical devices. Other medical device vendors hard-code passwords or use obsolete commercial operating systems.

Many healthcare organizations have invested in Innovation Centers within their organization to develop and deploy healthcare technology innovations. An example of this is the Emory Healthcare Innovation Hub (https://www.emoryhub.com). “The Emory Healthcare Innovation Hub is a premier health care advancement and commercialization program that connects all the pieces of the health care continuum to validate, accelerate and realize ideas. Our mission-realize improvements in health outcomes, increase access to quality care, lower overall costs to the system and improve health care provider experiences in Georgia and across the nation.” These innovation centers are developing solutions to address problems in the dynamic healthcare environment.

Structure of the System Design Team

The members of the system design team may vary based on the complexity and scope of the project. A project sponsor, one of the team's key members, should kick off the project with the team and help determine the business goals and how those goals should be measured. Once the team has been established and the goals clearly defined, the sponsor may not need to be involved in more detail-oriented design meetings. Below is a list of potential team members:

Project sponsor

Project manager

Solution architect4

Enterprise business architect4

Biomedical engineers

Application developers

Quality assurance analysts

Information security officer

Stakeholders/users

Chapter 5 · Design · Lesson 4 of 6

Technical Specifications, Continuity and Recovery

Big picture

This section lists what a comprehensive technical specification must cover and then treats the continuity and infrastructure requirements in detail. It follows the design team because the specification is what that team produces. The larger problem it solves is that functional requirements alone do not describe a system that can be operated: backups, recovery targets, availability and patching are what make the design survivable. RTO and RPO are the pair the exam returns to, and they answer different questions: how long until it runs again, and how much data can be lost.

Walkthrough

What the specification must cover

The design team must create comprehensive and detailed technical specifications covering both function and nonfunctional issues such as information infrastructure.
System and wired or wireless network architecture: whether the system must fit existing architectures or may vary.
Security and data encryption: whether the system integrates into the organization's security standards.
Disaster recovery: the recovery time objective and the recovery point objective.
Data conversion: the options if converting from one system to another with different data models.
Response times: what is expected and how it will be measured.
System backups: the options and how long backups will run.
System monitoring: how the system will be monitored and whether it fits existing monitoring infrastructure.
Change management: how the vendor handles changes, on a regular schedule or at customer convenience.
Availability: the availability requirements and the downtime associated with upgrades.
Time zone and daylight saving support: whether multiple time zones are supported and whether outages are required for clock changes.
Standards: whether the system supports integration standards such as HL7, ICD-10 or DICOM.
Government regulations: whether the system meets current regulations and the vendor's commitment for turnaround on new ones.
System integration: how the system will integrate with other health IT systems and medical devices.
Usability: including accessibility for persons with disabilities and use of mobile devices.
Workflow definitions: the definition of desired workflows.
Data management: whether the system fits organizational data management policies for backup, recovery and archiving.
Antivirus and OS patching policy: which anti-virus applications and versions are supported and whether automated patching is allowed.

Time zone and daylight saving support looks minor until an organization spans zones or a clock change forces an outage, which is exactly why the guide names it alongside architecture and security.

Question:

Reconstruct the technical specification areas without looking.
Which specification areas address what happens after go-live rather than at build time?

Recovery objectives

The recovery time objective is the time it will take to recover the system in a disaster.
The recovery point objective is the point in time to which the system must be restored.
RTO is about elapsed time to restoration and RPO is about tolerable data loss.

Example

An RPO of 15 minutes means replication or backup frequent enough that no more than fifteen minutes of data is ever at risk. An RTO of four hours says nothing about that; it says the system must be running again within four hours.

Question:

Define RTO and RPO and state which question each answers.
What does a short RPO demand of the backup or replication design?

Information infrastructure and business continuity

The information infrastructure must support today's business requirements and anticipate emerging or future requirements.
Bring your own device is the source's example of a current requirement, prompted by doctors, nurses and other employees wanting to use their own notebooks, tablets and smartphones on the enterprise network.
Most healthcare organizations have invested in secure mobile communications platforms and network infrastructure to support a BYOD strategy.
ICD-11 is the source's example of a future requirement, since most organizations use ICD-10 and today's applications do not support ICD-11.
As more records become electronic, business continuity emerges as a key part of the IT infrastructure.
Organizations must plan for disasters, whether natural or man-made.
Off-site storage of data is a minimal requirement.
Many sites negotiate contracts with disaster recovery vendors to retain copies of data and the capability to restore entire systems.
Larger organizations may own multiple data centers in which they mirror data, and networks must be in place to access remote sites.
The business continuity plan must ensure remote sites are in place and must be tested at frequent intervals to make certain it can be executed.
Many organizations use cloud-based applications enabling on demand availability of computing resources.
Cloud computing refers to the provision of applications over the Internet where customers do not invest in the hardware and software resources needed to run and maintain them.
Security of application data and customer information is of particular concern, since data is stored on infrastructure not owned by the healthcare organization.
The organization's security requirements must be well understood by the cloud vendor and incorporated into the system design.

Question:

Give the source's current and future examples of infrastructure requirements.
State the minimum continuity requirement and what the plan must do beyond having remote sites.
Define cloud computing and name the concern the source attaches to it.

Memory tips

RTO is a clock, RPO is a calendar page: time to restore versus point restored to.
Continuity ladder: off-site storage is the minimum, vendor contracts add restoration capability, mirrored data centers add immediacy, and testing at frequent intervals is what makes any of it real.
BYOD is the named current requirement; ICD-11 is the named future requirement.
Cloud definition cue: applications provided over the Internet without customer investment in the underlying hardware and software; the concern is data on infrastructure the organization does not own.
Specification areas easily forgotten: time zone and daylight saving, change management schedule, antivirus and patching policy, and vendor turnaround for new regulations.

Key concepts

Technical specifications: the comprehensive design document covering architecture, security and encryption, disaster recovery, data conversion, response times, backups, monitoring, change management, availability, time zone support, standards, government regulations, system integration, usability, workflow definitions, data management, and antivirus and patching policy
Recovery time objective: the time it will take to recover the system in a disaster
Recovery point objective: the point in time to which the system must be restored, expressing tolerable data loss
Business continuity plan: the plan for natural and man-made disasters, requiring off-site storage at minimum, optionally vendor contracts or mirrored data centers, and frequent testing
BYOD: the current infrastructure requirement prompted by clinicians wanting personal devices on the enterprise network, supported by secure mobile platforms
Cloud computing: the provision of applications over the Internet without customer investment in the underlying hardware and software, raising security concerns because data resides on infrastructure the organization does not own

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the requirement for comprehensive technical specifications covering functional and nonfunctional issues · each named specification area · RTO and RPO definitions · infrastructure support for present and future requirements · BYOD and ICD-11 as the named examples · business continuity as a key infrastructure element · natural and man-made disaster planning · off-site storage as a minimum · disaster recovery vendor contracts and mirrored data centers · the testing requirement · cloud computing definition and security concerns · the cloud vendor's obligation to incorporate organizational security requirements.

Read the original source

Detailed Technical Specifications

The design team must create comprehensive and detailed technical specifications that not only cover the function of the system or applications, but also address nonfunctional issues, such as information infrastructure. Some of the key areas of technical specifications that should be addressed are:

System and wired/wireless network architecture—Does the system have to fit into the organization's existing architectures or may it vary?

Security and data encryption—Does the system integrate into the organization's security standards?

Disaster recovery—What is the recovery time objective (RTO) or the time it will take to recover the system in a disaster? What is the recovery point objective (RPO) or to what point in time must the system be restored?

Data conversion—What are the data conversion options if converting from one system to another with different data models?

Response times—What are the expected response times and how will they be measured?

System backups—What are the backup options? How long will backups run?

System monitoring—How will the system be monitored? Will it fit into the organization's existing monitoring infrastructure?

Change management—How does the vendor of a newly purchased system handle changes? Is there a regular schedule? Or, is it done at customer convenience?

Availability—What are the availability requirements? What is the downtime associated with system upgrades?

Time zone and daylight savings time support—Does the system support multiple time zones, especially if the organization has facilities in different time zones? Are system outages required for spring or fall clock changing?

Standards—Does the system support integration standards such as HL7, International Statistical Classification of Diseases and Related Health Problems, 10th Revision (ICD-10) or DICOM?

Government regulations—Does the system meet current government regulations? What is the vendor commitment for turnaround of new regulations?

System integration—How will the system integrate with the other HIT systems and medical devices in the enterprise?

Usability—Much focus is being placed on usability today, and that topic will be discussed in more detail below. Usability should include accessibility for persons with disabilities as well as the use of mobile devices.

Workflow definitions—The definition of desired workflows is another key area of the design that will be discussed in more detail later in the chapter.

Data management—Does the system fit the organization's data management policies and procedures for such functions as backup, recovery and archiving?

Antivirus/OS patching policy—Which anti-virus application and versions are supported by the system? Is automated OS/security patching allowed?

Information Infrastructure

The information infrastructure must be able to support today's business requirements and anticipate emerging or future business requirements. A continuing trend, known as bring your own device (BYOD), is one example of a requirement prompted by doctors, nurses and other employees who want to use their own notebook computers, tablets or smartphones on the enterprise network. Most healthcare organizations have made investments in secure mobile communications platforms and network infrastructure to support a BYOD strategy. A good example of a future business requirement is the 11th Revision of the International Classification of Diseases (ICD-11).6 Most healthcare organizations today utilize ICD-10. While today's applications do not support ICD-11, healthcare organizations should consider how new system/applications will support it the future. Overall, an organization should have a process in place to examine or evaluate emerging trends and technologies. This evaluation should be done on a regular basis as new technologies emerge or existing technologies begin to be adopted. As part of the process, the organization should decide where it wants to be on the technology adoption curve (Figure 5.1).

Figure 5.1Technology adoption curve.

As more and more healthcare records are electronic, business continuity emerges as a key part of the IT infrastructure. Organizations must plan for various types of disasters, whether natural or man-made. Off-site storage of data becomes a minimal requirement. Many sites negotiate contracts with disaster recovery vendors to retain not only copies of data, but also the capability to restore entire systems. Larger organizations may own multiple data centers in which they may mirror their data. Networks must be in place to access these remote sites. The business continuity plan must not only ensure that the remote sites are in place, but also test the plan at frequent intervals to make certain that it can be executed.

Many healthcare organizations now utilize cloud-based applications, which enable on demand availability of computing resources. Cloud computing refers to the provision of applications over the Internet where customers do not have to invest in the hardware and software resource needed to run and maintain the applications. Of particular concern in healthcare, is the security of all application data and customer information. With cloud computing, data is stored on servers/infrastructure not owned by the healthcare organization. The security requirements of the healthcare organization need to be well understood by the cloud vendor and incorporated into the system design.7

Chapter 5 · Design · Lesson 5 of 6

Evaluating Emerging Technologies and Usability

Big picture

This section covers how an organization decides when to adopt a new technology and how it builds usability into design. It follows the technical specification because both are ways the design team turns judgment into documented requirements. The larger problem it solves is that adoption is a positioning decision rather than a yes or no: an organization has to know where it wants to sit on the adoption curve before it evaluates anything. The Usability Maturity Model phases are the named sequence here, and the middle phases are the ones that get swapped in answer options.

Walkthrough

Evaluating emerging technologies

An organization should have a process in place to examine or evaluate emerging trends and technologies.
The evaluation should be done on a regular basis as new technologies emerge or existing technologies begin to be adopted.
As part of the process, the organization should decide where it wants to be on the technology adoption curve.
Information infrastructure must support today's business requirements while anticipating emerging or future requirements.

Example

Deciding whether to pilot a new documentation technology is not only a product question. It is a question of whether the organization intends to be early, mainstream or late, which is the position it should have chosen in advance.

Question:

What does the source say an organization must decide as part of evaluating emerging technology?
How often should the evaluation happen, and on what triggers?

The Usability Maturity Model

Interest in usability has grown significantly over the past decade because of increased EHR adoption.
HIMSS created tools and forums to help clinicians and health IT professionals overcome common usability challenges, including the Usability Maturity Model.
The model examines three nonhealthcare usability models and uses common themes to create a healthcare model with five phases.

Unrecognized: lack of awareness of usability.
Preliminary: sporadic inclusion of usability.
Implemented: recognized value of usability, with small teams using it.
Integrated: benchmarks implemented and a dedicated user experience team in place.
Strategic: business benefit well understood, mandated, budgeted and results used strategically in the organization.

The phases are distinguished by who does usability work and with what authority: nobody, someone occasionally, small teams, a dedicated team with benchmarks, then the organization with a budget and a mandate.

Question:

Name the five UMM phases in order with their defining characteristic.
What separates the integrated phase from the strategic phase?

Tactics for expanding usability

Include usability in contracts.
Create feedback loops from users to vendors.
Talk about tasks and workflows.
Educate about return on investment related to usability.
Engage organizational leaders in usability.
Include usability metrics on one project.
Interview users to determine key usability issues.
Compile evidence from usability assessments.
Look for and document usability wake-up calls.
Find a business or organization driver supporting the need for usability.

Usability in the technical specification should include accessibility for persons with disabilities as well as use of mobile devices.

Question:

Reconstruct the usability expansion tactics without looking.
What must usability specifications include beyond ease of use?

Memory tips

UMM five phases: Unrecognized, Preliminary, Implemented, Integrated, Strategic. Read the ladder by ownership: nobody, sometimes, small teams, dedicated team with benchmarks, mandated and budgeted.
Adoption decision: choose the position on the technology adoption curve before evaluating any specific technology.
Tactic clusters: contractual (contracts, vendor feedback loops), evidentiary (metrics on one project, interviews, assessment evidence, wake-up calls), and political (leader engagement, ROI education, a business driver).
Usability specification must cover accessibility for persons with disabilities and mobile device use.

Key concepts

Emerging technology evaluation: the regular process of examining emerging trends and technologies, including deciding where the organization wants to sit on the technology adoption curve
Usability Maturity Model: the HIMSS five-phase healthcare model derived from three nonhealthcare usability models
UMM phases: unrecognized, preliminary, implemented, integrated and strategic, running from no awareness to mandated, budgeted and strategically used usability work
Usability expansion tactics: including usability in contracts, user-to-vendor feedback loops, talking about tasks and workflows, ROI education, leadership engagement, metrics on one project, user interviews, compiled assessment evidence, documented wake-up calls and a supporting business driver
Usability in specifications: the requirement that usability include accessibility for persons with disabilities and use of mobile devices

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the required process for evaluating emerging trends and technologies · regular cadence and triggers · the adoption curve positioning decision · infrastructure support for present and future requirements · growth of usability interest with EHR adoption · HIMSS tools and the UMM's derivation from three nonhealthcare models · the five phases and their characteristics · the ten tactics for expanding usability · accessibility and mobile inclusion in usability specifications.

Read the original source

Usability

As previously mentioned, interest in usability has grown significantly over the past decade due to increased EHR adoption. HIMSS has created various tools and forums to help clinicians and health IT professionals overcome some of the more common challenges with usability, including the Usability Maturity Model (UMM).5 IT examines three nonhealthcare usability models and uses common themes from those models to create a healthcare model with five phases:

Phase 1: Unrecognized—lack of awareness of usability

Phase 2: Preliminary—sporadic inclusion of usability

Phase 3: Implemented—recognized value of usability and small teams using it

Phase 4: Integrated—benchmarks implemented and have dedicated user experience team

Phase 5: Strategic—business benefit well understood, mandated, budgeted and results used strategically in the organization

The UMM documents how an organization can take itself from one phase to another and recommends the following tactics to expand usability within the organization:

Include usability in contracts

Create feedback loops from users to vendors

Talk about tasks and workflows

Educate about return on investment related to usability

Engage organizational leaders in usability

Include usability metrics on one project

Interview users to determine key usability issues

Compile evidence from usability assessments

Look for and document usability wake-up calls

Find a business/organization driver supporting need for usability

Figure 5.1Technology adoption curve.

As more and more healthcare records are electronic, business continuity emerges as a key part of the IT infrastructure. Organizations must plan for various types of disasters, whether natural or man-made. Off-site storage of data becomes a minimal requirement. Many sites negotiate contracts with disaster recovery vendors to retain not only copies of data, but also the capability to restore entire systems. Larger organizations may own multiple data centers in which they may mirror their data. Networks must be in place to access these remote sites. The business continuity plan must not only ensure that the remote sites are in place, but also test the plan at frequent intervals to make certain that it can be executed.

Many healthcare organizations now utilize cloud-based applications, which enable on demand availability of computing resources. Cloud computing refers to the provision of applications over the Internet where customers do not have to invest in the hardware and software resource needed to run and maintain the applications. Of particular concern in healthcare, is the security of all application data and customer information. With cloud computing, data is stored on servers/infrastructure not owned by the healthcare organization. The security requirements of the healthcare organization need to be well understood by the cloud vendor and incorporated into the system design.7

Chapter 5 · Design · Lesson 6 of 6

Data Management and the DAMA Knowledge Areas

Big picture

This closing section gives the framework the guide uses for data governance and states the design team's obligation toward it. It ends the chapter because data is what all the preceding design decisions carry. The larger problem it solves is that data issues are usually treated one at a time, while the framework names eleven distinct areas that each need an owner and a process. Data governance and data architecture are the adjacent pair here: governance is planning, oversight and control, while architecture is the structure of the data itself within the enterprise architecture.

Walkthrough

The eleven knowledge areas

Data Management International created a framework for data governance defining 11 data management knowledge areas.
Data governance: planning, oversight and control over management of data and the use of data and data-related resources.
Data architecture: the overall structure of data and data-related resources as an integral part of the enterprise architecture.
Data modeling and design: analysis, design, building, testing and maintenance.
Data storage and operations: structured physical data assets, storage, deployment and management.
Data security: ensuring privacy, confidentiality and appropriate access.
Data integration and interoperability: acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support.
Documents and content: storing, protecting, indexing and enabling access to data found in unstructured sources, and making it available for integration with structured data.
Reference and master data: managing shared data to reduce redundancy and ensure better quality through standardized definition and use of data values.
Data warehousing and business intelligence: managing analytical data processing and enabling access to decision support data for reporting and analysis.
Metadata: collecting, categorizing, maintaining, integrating, controlling, managing and delivering metadata.
Data quality: defining, monitoring and maintaining data integrity and improving data quality.

Example

A duplicate patient record is a reference and master data problem before it is a quality problem. Naming the area decides who fixes it and with what process, which is the point of having eleven of them.

Question:

Name all eleven DAMA knowledge areas.
Distinguish data governance from data architecture, and data security from data quality.
Which area covers unstructured sources, and what must it enable?

The design team's obligation

The organization must define a process for addressing those data management functions.
The system design team must ensure that the system fits into that process.
Successful system design centers on a design team that includes the proper members and produces clear, documented technical specifications.
Examining usability and data management are the two ways the design team produces such requirements.
Design must ensure compatibility and interoperability of medical devices, software and hardware components.
The system must also comply with industry, regulatory and organizational standards.
A process should be in place for evaluating emerging technologies to support the organization's strategy and mission.

The obligation runs one way. The organization defines the data management process, and the design team fits the system to it rather than inventing a parallel process for one project.

Question:

State the division of responsibility between the organization and the design team on data management.
Summarize the chapter's conclusion about what successful system design rests on.

Memory tips

DAMA count anchor: 11 knowledge areas, from Data Management International.
Area cues: governance is planning, oversight and control; architecture is structure; security is privacy, confidentiality and access; quality is integrity and improvement; metadata is data about data; reference and master data is shared data and standard values.
Integration and interoperability area verbs: acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization, operational support.
Obligation direction: the organization defines the process, the design team fits the system to it.

Key concepts

DAMA framework: the Data Management International framework for data governance defining 11 data management knowledge areas
Data governance: planning, oversight and control over management of data and the use of data and data-related resources
Data architecture: the overall structure of data and data-related resources as part of the enterprise architecture
Data security: ensuring privacy, confidentiality and appropriate access
Data integration and interoperability: acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support
Documents and content: storing, protecting, indexing and enabling access to unstructured data and making it available for integration with structured data
Reference and master data: managing shared data to reduce redundancy and improve quality through standardized definition and use of values
Metadata: collecting, categorizing, maintaining, integrating, controlling, managing and delivering data about data
Data quality: defining, monitoring and maintaining data integrity and improving data quality
Design team obligation: ensuring the system fits the organization's defined data management process

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the DAMA framework and its 11 knowledge areas with each definition · the organization's duty to define a data management process · the design team's duty to fit the system to that process · the chapter conclusion on team composition, documented specifications, usability and data management as requirement sources, compatibility and interoperability, standards compliance and the emerging technology evaluation process.

Read the original source

Data Management

Healthcare organizations must address a wide variety of issues related to their data. Data Management International (DAMA®) created a framework for data governance that defines 11 data management knowledge areas8:

Data Governance—planning, oversight and control over management of data and the use of data and data-related resources

Data Architecture—the overall structure of data and data-related resources as an integral part of the enterprise architecture

Data Modeling & Design—analysis, design, building, testing and maintenance

Data Storage & Operations—structured physical data assets, storage, deployment and management

Data Security—ensuring privacy, confidentiality and appropriate access

Data Integration & Interoperability –acquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support

Documents & Content—storing, protecting, indexing and enabling access to data found in unstructured sources (electronic files and physical records) and making this data available for integration and interoperability with structured (database) data

Reference & Master Data—Managing shared data to reduce redundancy and ensure better data quality through standardized definition and use of data values

Data Warehousing & Business Intelligence—managing analytical data processing and enabling access to decision support data for reporting and analysis

Metadata—collecting, categorizing, maintaining, integrating, controlling, managing and delivering metadata

Data Quality—defining, monitoring, maintaining data integrity and improving data quality

The organization must define a process for addressing those data management functions. Then, the system design team must ensure that the system fits into that process.

Summary

Successful system design centers on the design team, which must include the proper members. The design team should create clear, documented technical specifications. Two ways in which the design team can produce such requirements are by examining usability and data management. It is fundamental that the system design ensures the compatibility and interoperability of medical devices, software and hardware components. The system must also comply with industry, regulatory and organizational standards. As healthcare practices are constantly changing and evolving, a process should be in place for evaluating emerging technologies to support the healthcare organization's strategy and mission.

Chapter 5 · Design · Supplemental lesson

Usability Evaluation Methods

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Chapter 5 is the shortest chapter and usability is proportionally the biggest gap in the set, serving both design and testing. Usability in healthcare is a patient safety property rather than a matter of preference: a system that induces use errors causes harm regardless of whether people like it. The methods split by whether real users are involved, and by whether the evaluation shapes or judges.

Walkthrough

Definitions and methods

Usability, in the ISO definition, is the extent to which specified users can achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
User-centered design is the process producing usability, involving real users throughout design and iterating on their performance rather than validating at the end.
Heuristic evaluation: several usability experts independently inspect the interface against established principles, such as Nielsen's ten heuristics covering visibility of system status, match to the real world, user control, consistency, error prevention, recognition over recall, flexibility, minimalist design, error recovery and help.
Heuristic evaluation is cheap and fast, works on a mockup before anything is built, finds rule violations reliably and misses what real users actually do.
Cognitive walkthrough: experts step through a specific task as a novice would, asking at each step whether the user will know what to do, see the control and understand the feedback, which targets learnability.
Think-aloud protocol: users verbalize their reasoning while performing tasks, surfacing confusion that observation alone misses.
Usability testing: users perform representative tasks under observation while task success, time on task, error rate and satisfaction are measured.

Question:

Give the ISO definition and its three components.
Sort heuristic evaluation, cognitive walkthrough, think-aloud and usability testing by whether users are involved.
Which method targets learnability specifically?

Formative, summative and the SUS

Formative evaluation happens during design with a small number of participants, is diagnostic and aims to improve the design.
Summative evaluation happens after design with a larger number, measured against defined criteria, and aims to judge whether the design meets the bar.
The heuristic is that formative shapes and summative judges: iterating on findings is formative, pass or fail against criteria is summative.
The System Usability Scale is a ten-item questionnaire producing a score from 0 to 100, normalized across thousands of studies so scores compare across products and industries.
A large national survey found U.S. physicians rated their EHRs at a mean SUS of 45.9, the bottom decile of measured systems, with lower usability scores independently associated with higher odds of burnout.
ONC certification includes Safety-Enhanced Design, requiring developers to follow an industry-standard user-centered design process and conduct summative usability testing with at least ten participants per capability.

Example

Asking clinicians in a governance meeting whether they like a new screen applies no principles, performs no tasks and measures nothing. It is an opinion poll, useful for adoption and worthless for safety.

Question:

Distinguish formative from summative evaluation by purpose and timing.
State the SUS scale, the physician EHR finding and the certification participant threshold.

Memory tips

ISO triad: effectiveness, efficiency, satisfaction, in a specified context.
Experts and principles versus users and tasks: heuristic evaluation and cognitive walkthrough versus think-aloud and usability testing.
Formative shapes, summative judges. Ten participants per capability is a summative threshold.
SUS runs 0 to 100; physician EHR mean was 45.9, bottom decile, linked to burnout odds.
Objective measures three: task success, time on task, error rate. Satisfaction is the subjective one.

Key concepts

Usability: the extent to which specified users achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use
User-centered design: the process of involving real users throughout design and iterating on their performance
Heuristic evaluation: independent expert inspection against established principles, usable before anything is built
Cognitive walkthrough: expert simulation of a novice performing a task, targeting learnability
Think-aloud and usability testing: users verbalizing reasoning during tasks, and users performing representative tasks under measured observation
Formative and summative evaluation: small-n diagnostic evaluation to improve the design, and larger-n evaluation against defined criteria to judge it
System Usability Scale: a ten-item questionnaire producing a normalized 0 to 100 score
Safety-Enhanced Design: the ONC certification requirement for an industry-standard UCD process and summative testing with at least ten participants per capability

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the ISO usability definition and its components · usability as a safety property · user-centered design · heuristic evaluation, Nielsen's heuristics and its strengths and blind spots · cognitive walkthrough and learnability · think-aloud and usability testing measures · formative versus summative purpose, size and timing · the SUS scale and physician EHR findings · Safety-Enhanced Design and the ten-participant summative threshold.

Read the supplemental lesson source

S5.1 — Usability Evaluation Methods

Chapters 5 and 7 · Tasks III.B, III.D · About 13 minutes

1. Learn the topic

Where this fits

Two Addendum B books — Harrington's Usability Evaluation Handbook for Electronic Health Records and Sittig's Challenges in Design and Implementation — are entirely about this, and Chapter 5 is your shortest chapter. Proportionally this is the biggest gap in the whole set. It also serves Chapter 7, so one block of study covers two chapters.

What it means

Usability, in the ISO definition, is the extent to which specified users can achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Three components, and all three are measurable.

Usability is not aesthetics and not user preference. In healthcare it is a patient safety property: a system that induces use errors causes harm regardless of whether people like it.

User-centered design (UCD) is the process that produces usability — involving real users throughout design, iterating on their performance, rather than validating at the end.

How it works: the methods

Split them by whether real users are involved.

Expert inspection methods (no users):

Heuristic evaluation — several usability experts independently inspect the interface against established principles (Nielsen's ten heuristics: visibility of system status, match to the real world, user control, consistency, error prevention, recognition over recall, flexibility, minimalist design, error recovery, help). Cheap, fast, works on a mockup before anything is built. Finds rule violations reliably; misses what real users actually do.

Cognitive walkthrough — experts step through a specific task as a novice would, asking at each step: will the user know what to do, will they see the control, will they understand the feedback? Targets learnability specifically.

Empirical methods (real users):

Think-aloud protocol — users verbalize their reasoning while performing tasks. Surfaces confusion that observation alone misses.

Usability testing — users perform representative tasks under observation while you measure task success, time on task, error rate and satisfaction.

And the axis that cuts across both:

Formative evaluation — during design, small n, diagnostic. The goal is to improve the design. Findings are qualitative and immediate.

Summative evaluation — after design, larger n, measured against defined criteria. The goal is to judge whether it meets the bar.

The exam-relevant heuristic: formative shapes, summative judges. If the stem describes iterating on findings, it's formative. If it describes a pass/fail against criteria, it's summative.

System Usability Scale (SUS) — a 10-item questionnaire producing a 0–100 score, normalized across thousands of studies so scores are comparable across products and industries. Worth knowing as context: a large national survey found US physicians rated their EHRs at a mean SUS of 45.9, the bottom decile of measured systems — a grade of F — and lower usability scores were independently associated with higher odds of burnout.

Examples and non-examples

Straightforward. Before building, two experts run a heuristic evaluation on the order-entry mockup and find that a destructive action lacks confirmation. Cost: a few hours. Cost of finding it after go-live: incalculable.

Connecting to another concept. ONC certification includes Safety-Enhanced Design, requiring developers to follow an industry-standard UCD process and conduct summative usability testing with at least ten participants per capability. Usability moved from good practice to a certification condition — and the number ten is a summative threshold, not a formative one.

Non-example. Asking clinicians in a governance meeting whether they like the new screen is neither heuristic evaluation nor usability testing. No principles applied, no tasks performed, no measurement. It is an opinion poll — useful for adoption, worthless for safety.

Common misconceptions

"Usability testing and heuristic evaluation are the same." One uses experts and principles, the other uses users and tasks. They find different problems, which is why mature programs use both.

"Usability is subjective." Task success, time on task and error rate are objective. Satisfaction is the only subjective component of the three.

"A good SUS score means the system is safe." SUS measures perceived usability. It does not measure use error, which is what summative safety testing targets.

2. Exam focus

What you must know

ISO usability = effectiveness, efficiency, satisfaction in a specified context.

Heuristic evaluation = experts + principles, no users, works pre-build.

Cognitive walkthrough = experts simulating a novice through a task; targets learnability.

Think-aloud and usability testing = real users performing real tasks.

Formative improves; summative judges.

SUS = standardized 0–100 perceived-usability instrument.

Usability is a patient safety property, not a preference.

Distinctions likely to be tested

Expert inspection vs. empirical testing — the discriminator is are users present.

Formative vs. summative — the discriminator is purpose: improve vs. judge.

Usability vs. adoption vs. satisfaction. A well-liked system can still induce errors.

How this appears in a question

Plausible-but-upstream traps: heuristic evaluation and usability testing are both correct answers to "how do we find usability problems," but only one works before a functioning system exists, and only one reflects real user behaviour. Read the stem for when in the lifecycle and who is available.

3. Teach it back

Explain to a project manager who wants to cut usability work to save schedule:

1. Why heuristic evaluation is the cheapest thing on the plan and should be first.

2. What a summative test tells you that a formative test cannot.

3. Give an original example of a system that would score well on satisfaction and badly on effectiveness.

<summary>Key-point checklist</summary>

[ ] Heuristic evaluation needs no users and no working system — that's why it's cheap and early

[ ] Summative measures against criteria for a pass/fail judgment; formative diagnoses to improve

[ ] Effectiveness/efficiency/satisfaction named as separable, with a case where they diverge

[ ] Framed usability as safety, not preference

[ ] Did not treat expert inspection and user testing as interchangeable

</details>

4. Practice

Items SQ-28 to SQ-31.

5. Key takeaway

Two axes organize every usability method: experts or users, and improve or judge. Heuristic evaluation is experts-improving and costs almost nothing; summative testing is users-judging and is what certification requires. In healthcare, all of it is a safety activity.

Chapter 5 · Design · Supplemental lesson

The Sociotechnical Model and the SAFER Guides

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This is the framework explaining why technically correct systems fail clinically, and it is the organizing structure behind the SAFER Guides. Health IT operates inside a complex adaptive system, so safety depends on eight interacting dimensions rather than on the software alone. The dimension most often skipped is measurement and monitoring, which is the one that catches the others failing.

Walkthrough

The eight dimensions

Hardware and software infrastructure: the computing platform, network and devices.
Clinical content: the data, information and knowledge configured in the system, including order sets, rules, alert logic and documentation templates.
Human-computer interface: how users see and interact with the system.
People: clinicians, patients and IT staff, with their training, expectations and capacity.
Workflow and communication: how work actually gets done and how people coordinate.
Internal organizational policies, procedures and culture: governance, rules, incentives and what the organization tolerates.
External rules, regulations and pressures: regulation, accreditation, payment and market.
System measurement and monitoring: whether anyone is watching how the system performs in use.

The dimensions interact, so a change in one propagates into others.
Tightening an alert rule changes interface load, clinician behaviour, workflow and eventually policy about who may override, and failing to anticipate that chain produces alert fatigue.

Example

After a wrong-patient order, the software worked correctly: two patients had similar names, the interface showed the name in small type at the screen edge, the unit habitually kept several charts open and no policy addressed concurrent records. Four dimensions, no software defect.

Question:

Name all eight dimensions in order.
Trace how a change in one dimension propagates through others.
Which dimension tells you whether the other seven are working?

The SAFER Guides

SAFER stands for Safety Assurance Factors for EHR Resilience and turns the model into practice.
They are self-assessment instruments published by ASTP and ONC: sets of recommended practices an organization walks through to rate its own conformance.
The 2025 revision comprises eight guides organized into three groups.
Foundational guides cover high-level organizational responsibilities and readiness.
Infrastructure guides cover the technical substrate: system configuration, interfaces and contingency planning.
Clinical process guides cover specific high-risk processes: computerized order entry with decision support, test result reporting and follow-up, clinician communication and patient identification.
Three properties define them: they are voluntary, they are self-assessments rather than audits or certifications, and they are proactive, used before harm rather than after.

Question:

Name the three SAFER groups and what each covers.
State the three defining properties of the guides.

Memory tips

Eight dimensions, and the four distractors most often omit: workflow and communication, internal policies and culture, external rules and pressures, system measurement and monitoring.
Interaction is the point: a change in one dimension propagates, which is how alert fatigue is produced by a correct rule.
SAFER properties three: voluntary, self-assessment, proactive.
SAFER groups three: foundational, infrastructure, clinical process.
Compare with RCA: the model supplies the dimensions to look across so the analysis does not stop at the user made a mistake.

Key concepts

Sociotechnical model: Sittig and Singh's eight interacting dimensions determining health IT safety and effectiveness
The eight dimensions: hardware and software infrastructure, clinical content, human-computer interface, people, workflow and communication, internal policies and culture, external rules and pressures, and system measurement and monitoring
SAFER Guides: the ASTP and ONC self-assessment instruments turning the model into recommended practices, in foundational, infrastructure and clinical process groups
SAFER properties: voluntary, self-assessment rather than audit or certification, and proactive

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the sociotechnical premise and the eight named dimensions · their interaction and the alert fatigue chain · the role of measurement and monitoring · SAFER's name, publisher and purpose · the eight guides in three groups and their contents · the three defining properties.

Read the supplemental lesson source

S5.2 — The Sociotechnical Model and the SAFER Guides

Chapters 5 and 7 · Tasks III.B, III.D · About 12 minutes

1. Learn the topic

Where this fits

This is the framework that explains why technically correct systems fail clinically — and it is the organizing structure behind the ONC SAFER Guides, one of the Addendum B website references. Like S5.1, it serves both Chapter 5 and Chapter 7.

What it means

Sittig and Singh's 8-dimension sociotechnical model holds that health IT operates inside a complex adaptive system, and that safety and effectiveness depend on eight interacting dimensions — not on the software alone.

1. Hardware and software infrastructure — the computing platform, network, devices.

2. Clinical content — the data, information and knowledge configured in the system: order sets, rules, alert logic, documentation templates.

3. Human–computer interface — how users see and interact with the system.

4. People — clinicians, patients, IT staff; their training, expectations and capacity.

5. Workflow and communication — how work actually gets done and how people coordinate.

6. Internal organizational policies, procedures and culture — governance, rules, incentives, what the organization tolerates.

7. External rules, regulations and pressures — regulation, accreditation, payment, market.

8. System measurement and monitoring — whether anyone is watching how the system performs in use.

How it works

The dimensions interact, and that's the point. A change in one propagates into others. Tighten an alert rule (dimension 2) and you change interface load (3), clinician behaviour (4), workflow (5), and eventually policy about who may override (6). Fix the rule without anticipating that chain and you get alert fatigue — the canonical example of a technically correct change producing a clinically worse outcome.

Dimension 8 is the one organizations most often skip, and it is the one that catches the others failing. Deploy without measurement and you find out from an incident.

How it works: the SAFER Guides

SAFER — Safety Assurance Factors for EHR Resilience — turns the model into practice. They are self-assessment instruments published by ASTP/ONC: sets of recommended practices an organization walks through to rate its own conformance.

The 2025 revision comprises eight guides organized into three groups:

Foundational — high-level organizational responsibilities and readiness. Start here.

Infrastructure — the technical substrate: system configuration, interfaces, contingency planning.

Clinical process — specific high-risk processes: computerized order entry with decision support, test result reporting and follow-up, clinician communication, patient identification.

Three properties to hold onto: they are voluntary, they are self-assessments rather than audits or certifications, and they are proactive — used before harm rather than after.

Examples and non-examples

Straightforward. After a wrong-patient order, the analysis finds the software worked correctly. Two patients had similar names (dimension 2, patient identification content), the interface showed the name in small type at the screen edge (3), the unit's habit was to keep several charts open (5), and no policy addressed concurrent records (6). Four dimensions, no software defect.

Connecting to another concept. Compare with root cause analysis (lesson S7.1). RCA asks "why did this happen." The sociotechnical model gives you the dimensions to look across so the RCA doesn't stop at the first plausible cause — which is usually "the user made a mistake," i.e. dimension 4 alone.

Non-example. A vendor's assertion that the system is certified addresses dimension 1 and part of 2. It says nothing about workflow, people, policy or monitoring. Certification is not safety.

Common misconceptions

"Sociotechnical means people plus technology." It means eight named dimensions with defined interactions — a diagnostic tool, not a slogan.

"SAFER Guides are a certification requirement." They are voluntary self-assessments.

"Monitoring is the last dimension because it's least important." It's the dimension that tells you whether the other seven are working.

2. Exam focus

What you must know

The eight dimensions. If you can't hold all eight, hold the four that distractors most often omit: workflow and communication, internal policies and culture, external rules and pressures, system measurement and monitoring.

Dimensions interact; changing one propagates.

SAFER Guides: ASTP/ONC, self-assessment, voluntary, proactive; 2025 set is eight guides in three groups (foundational, infrastructure, clinical process).

Alert fatigue as the standard illustration of a technically correct change with a clinically worse outcome.

Distinctions likely to be tested

Sociotechnical failure vs. software defect. If the software did what it was configured to do, it isn't a defect — look at content, workflow, people, policy.

SAFER (proactive self-assessment) vs. RCA (retrospective, event-triggered) vs. certification (product conformance).

How this appears in a question

Scenario stems where the technical component functioned and the outcome was still bad. The keyed answer names an organizational, workflow or content dimension; the distractors offer technical fixes. This matches the pattern already visible in your bank — CPHIMS consistently rewards surfacing the organizational dimension.

3. Teach it back

Explain to a CIO who says the EHR is safe because it is certified and has no open defects:

1. What certification does and does not tell them.

2. Name four dimensions their statement doesn't address, and give a concrete failure in one of them.

3. Predict what happens if they tighten a drug-interaction rule without touching any other dimension.

<summary>Key-point checklist</summary>

[ ] Certification addresses product capability, not implementation, configuration, workflow or use

[ ] Named at least four non-technical dimensions correctly

[ ] Traced a rule change through content → interface → people → workflow, landing on alert fatigue and override behaviour

[ ] Described SAFER as voluntary self-assessment, not audit or certification

[ ] Identified measurement and monitoring as the dimension that detects the others failing

</details>

4. Practice

Items SQ-32 to SQ-34.

5. Key takeaway

Health IT safety lives in eight interacting dimensions, and only three of them are technical. The SAFER Guides operationalize that model as voluntary, proactive self-assessment. When a stem describes correct software and a bad outcome, the answer is upstream in content, workflow, people or policy.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 1 of 9

Solution Selection Criteria and Requirements

Big picture

This section covers how a selection starts: an identified need, a business case, governance approval and a requirement set that reaches past end-user functionality. It opens the chapter that follows analysis and design, and it reuses the RFI and RFP vocabulary from Chapter 4. The larger problem it solves is that a selection with vague requirements produces a comparison that cannot be defended later. Business case and requirements are the pair to keep distinct: the business case presents the need and several possible directions, while the requirements state what any acceptable solution must do.

Walkthrough

Where a selection begins

The systems selection process begins with identification of a need and subsequent approval of a project proposal.
Successful implementation and adoption depend on an organized selection process followed by a well-planned and executed implementation strategy.
An effective governance committee evaluates the identified need against the organizational mission, goals, objectives, IT strategic plan, budget and available resources.
Once the decision is made to move forward, objectives, goals and measures of success should be clearly defined.
The team is then assembled to analyze and further define requirements, including all parts of the organization affected.
That analysis surfaces opportunities for process improvement and workflow efficiencies.
The need and justification are often described in a formal business case, project proposal or needs assessment.
Most organizations request a business case before approving the selection process, and if the organization does not require one the IT governance committee should.
Required resources are hard to define this early and are most often defined through scientific guesses; market research can improve the estimates.
Formal market research follows a process similar to the RFI but states clearly that it is for research only with no intent to purchase.
Informal market research is done through vendor exhibitions, Internet searches and contact with similar organizations.
The business case should present the need and requirements rather than a single solution, offering several solutions or recommendations.
The governance committee decides whether to move forward based on fit with the strategic plan or operational goals and the availability of resources.

A business case that names one product has skipped the comparison. Presenting several directions is what leaves the governance decision open.

Question:

Trace the path from an identified need to approval to proceed, naming who evaluates what.
Distinguish formal from informal market research.
Why should a business case avoid identifying a single solution?

RFI and RFP in the selection context

An RFI is an informal request for information that does not require commitment from either party.
It is a collection of documents designed to collect information on prospective vendors and their ability to meet the defined need or high-level requirements.
An RFI may or may not include budget or cost information.
An RFP is a formal request that leads to a contract between the organization and the selected vendors.
It is a collection of documents outlining the detailed requirements and how each responding vendor will be compared for a final decision.
An RFP always includes timelines and budget or cost information.

Question:

State the three differences between an RFI and an RFP as this chapter summarizes them.

What the requirement list covers

Functional requirements, including application functionality specific to the organization.
Security and privacy requirements and regulatory requirements.
Reporting capability, both standard and custom.
Integration with other applications or devices, and interoperability requirements.
Access from mobile devices and redesigned workflow.
Decision support functionality and nonfunctional requirements.
Cloud infrastructure, capacity requirements, load balancing configuration and software or platform as a service requirements.
Facility IT infrastructure including space, cooling and power.
Hardware for disaster recovery or high availability, and hardware for reporting.
Backup and recovery plans and procedures.
Workstation and printer requirements and hardware, and wired and wireless networks.
System installation, configuration and maintenance documentation.
Processes for issue resolution and requests for enhancement.
Maintenance and support processes and procedures.
Expected availability, reliability and scalability.
Training requirements.
Requirements should be ranked as required, preferred or optional, since ranking is what allows responses to be scored and compared.
Independent verification and validation may be included in requirements to obtain an objective assessment of vendor claims.
Build versus buy and cloud versus on-premise are decisions the requirement set has to support.

Example

A requirement that every item is mandatory produces a scoring sheet where every vendor fails something. Ranking is what lets the team say which failures matter.

Question:

Reconstruct the requirement categories beyond end-user functionality.
Why does the source insist requirements be ranked?
Which requirements address what happens after go-live rather than at selection?

Memory tips

Selection order: need, business case, governance approval, team, requirements, market research where time allows.
RFI versus RFP in one line: informal and non-committing, cost optional, versus formal, contract-leading, cost and timeline always.
Requirement ranking three: required, preferred, optional.
Requirement set reaches past function into infrastructure, support, documentation, availability and training.
Governance test: fit with strategic plan or operational goals plus availability of resources.

Key concepts

Business case: the document presenting the need, requirements and several possible solutions, reviewed by governance before a selection proceeds
Market research: formal research run like an RFI but declared research only, or informal research through exhibitions, Internet searches and peer contact
RFI: an informal, non-committing request gathering vendor ability against high-level requirements, which may or may not include cost
RFP: a formal request outlining detailed requirements and comparison method, always including timelines and budget
Requirement ranking: the classification of requirements as required, preferred or optional so responses can be scored
Independent verification and validation: an objective assessment included in requirements to test vendor claims

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the start of the selection process and governance evaluation criteria · definition of objectives, goals and success measures · team assembly and process improvement opportunities · business case, project proposal or needs assessment · resource estimation and market research forms · the instruction to present several solutions · governance decision criteria · RFI and RFP characteristics · the full requirement list including infrastructure, support, documentation, availability and training · requirement ranking · independent verification and validation · build versus buy and cloud versus on-premise considerations.

Read the original source

Introduction

The systems selection process begins with the identification of a need and subsequent approval of a project proposal. The successful implementation and adoption of a new application or a system is dependent on an organized system selection process, followed by a well-planned and executed implementation strategy. Once a need has been identified within an organization, an effective governance committee evaluates it against the organizational mission, goals, objectives, information technology (IT) strategic plan, budget and available resources.

Once the decision is made to move forward, objectives, goals and measures of success should be clearly defined. Once the high-level strategy is defined, the team is assembled to analyze and further define the requirements. It is important to have the appropriate team members to ensure the analysis includes all parts of the organization affected by the new solution. Through this analysis, opportunities for process improvement and workflow efficiencies are identified.

Chapter 4 discussed in detail the items that should be included in a request for information (RFI) or request for proposal (RFP). To summarize,

A RFI

Is an informal request for information that does not require commitment from either party

Is a collection of documents designed to collect information regarding prospective vendors and their ability to meet the defined need or high-level requirements

May or may not include budget or cost information

A RFP

Is a formal request that leads to a contract between the organization and the selected vendor(s)

Is a collection of documents that outline the detailed requirements and how each responding vendor will be compared for a final decision

Always includes timelines and budget or cost information

Evaluating the vendors that respond to the RFP includes on-site visits, reference checks, demonstrations and sometimes a trial version or trial period for the system. After the list of possible vendors is narrowed down to a few, contract negotiations allow the organization to get the best possible deal based on price, payment plan, support levels and ongoing support. It is important to include a step to verify any regulations as part of any standard selection practice.

After the application and vendor have been selected, it is time to begin implementation. Understanding the different implementation strategies will help the organization choose the one that best fits its culture, objectives and available resources. Proper planning and a defined methodology will help decrease project risk and lead to a successful activation. For a smooth transition to support, the implementation project should include planning for post-live activities, such as configuration management, user communication, user support and new employee training, along with operations and maintenance, to ensure continuous performance of the system.

Solution Selection Criteria

As mentioned earlier during the analysis phase, system selection begins with a defined need based on the organization's strategic objectives or a solution to a problem that blocks achievement of an organizational or departmental objective. The selection and implementation processes are built around fulfilling the need and realizing the solution that will meet the organization's expected outcomes. There is quite a bit of overlap with the information identified/defined in the systems analysis phase and the solution selection process as much of the analysis information helps inform this process. The process defined below should be used as a template and modified as needed to fit the specific situation and satisfy the current regulatory requirements.

As was described in Chapter 4, the need and justification for a project are often described in a formal business case, project proposal, or a needs assessment. This document outlines the goal and objectives of the request, along with the high-level resources required to meet them. Most organizations request a business case prior to approving the proposed system selection process. If the organization does not require a business case, it is imperative that the IT governance committee request one. The challenge comes from defining the required resources this early in the process. Most often, they are defined through scientific guesses. If time allows, market research can provide more accurate estimates. Market research starts with high-level requirements, not the detailed ones identified later in the process, and may be conducted formally or informally. Formal market research is completed through a process similar to the RFI process. With market research, however, it is clearly stated that the RFI is for research only, with no intent to purchase at this time. The informal process is completed through vendor exhibitions, Internet searches and contact with other similar organizations.

The business case or project proposal should present the need and requirements, not necessarily the solution, but again, it informs the solution selection process. This document should avoid the identification of a single solution, but rather several solutions or recommendations. The governance committee reviews the business case and decides whether to move forward based on the system's fit within the organization's strategic plan or operational goals and the availability of resources to complete.

Once approval to move forward is received, the selection criteria are built on the defined need and high-level requirements that the business case identified as necessary for the solution. Whether the need is to improve office-scheduling processes through automation or to create a paperless environment in an acute care setting, the requirements go beyond end-user functionality to include nonfunctional necessities also.

A list of requirements could include the following:

Functional requirements

Application with organization-specific functionality

Security and privacy requirements

Regulatory requirements

Reporting capability, including standard and custom reporting

Integration with other applications or devices

Interoperability requirements

Access from multiple locations (acute care, long-term care, clinics, etc.)

Access from mobile devices

Redesigned workflow

Decision support functionality/nonfunctional requirements

Cloud infrastructure

Capacity requirements

Separate cloud environments for production, development, testing and training

Load balancing configuration and requirements

Software as a service or platform as a service requirements

Facility IT infrastructure

Space, cooling and power

Hardware for production, development, testing and training environments

Hardware for disaster recovery or high availability

Hardware for reporting

Backup and recovery plans and procedures

Workstation and printer requirements and hardware

Wired and wireless networks

System installation, configuration and maintenance documentation

Supplemental staffing for implementation, training and post live support

Independent verification and validation to reduce risk by providing impartial reviews of business and technical aspects of the project

Processes for issue resolution and requests for enhancement

Maintenance and support process and procedures

Expected procurement and implementation timeline, along with any constraints that would affect the timeline

Expected availability, reliability and scalability

Training requirements

The gap analysis might be the first step in defining these requirements. What is the status of your current application(s)? Are you planning to replace or enhance those systems? What manual processes can and must be improved through automation? Throughout this process, it is important to focus the analysis on the identified need. Requirement creep can occur very quickly if the team is not focused. The governance committee and executive sponsors are there to help with ensuring the requirements fit within the defined goals and objectives.

Once the requirements are defined, they should be ranked to show which are required, preferred, or optional. It is rare for vendors to be able to meet every requirement, so clarity about which ones are absolutely necessary helps during the evaluation of responses. The rankings should be agreed upon by all committee members and used consistently for all vendors. The requirements and rankings feed into the RFI or RFP documentation as defined earlier in this chapter.

Through this process, a decision to build versus buy should be made. There are many factors that influence this decision. Does the organization have the skill set to build and support the new solution? Is there room in the budget to buy? What is the expected timeline? Which option fits with the organizational IT strategy? Is there a vendor who can meet the need and defined requirements? Based on these factors, the decision to build or buy may occur early in the process, after reviewing the RFI/RFP responses, or anytime in between.

One more analysis to perform is whether a cloud-based technology is preferred over an on premise solution. The analysis should include several criteria such as personnel requirements to install and maintain the software, hardware purchase and maintenance, proper monitoring and auditing and evaluating how well the system aligns with privacy and security requirements in the cloud.

Having the appropriate people involved in the selection process is key to being successful. The governance committee and executive sponsors have already been introduced. A facilitator should be identified early on to ensure that the activity progresses as expected, the defined process is followed and the right people are involved in the review team.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 2 of 9

The Selection Review Team

Big picture

This section names who sits on a selection team and what each role contributes. It follows the requirements because the requirement set is only as complete as the areas represented on the team. The larger problem it solves is representation: no team can include everyone affected, so members carry their area's needs in and carry information back out. Governance committee and selection team are the pair to separate, since one provides oversight and receives reports while the other does the work.

Walkthrough

Choosing the team

The review team should be selected as early as possible, even if some members are not needed at the earliest stages.
Membership decisions balance including the right people against keeping the size manageable.
Members should include representatives from clinical, organizational operations, IT and the business department.

Question:

What balance does the source name in deciding team membership, and which areas must be represented?

The roles

Facilitator: provides overall leadership and coordination of the system selection process.
Executive sponsor: provides support, clarifies the mission, facilitates necessary resources and acts as a champion within the organization.
Technical representative: provides technical expertise such as IT, biomedical and telecommunications.
Business representative: provides business or clinical end-user expertise and represents the end users' current workflows.
Program or project manager: provides implementation and methodology expertise.
Contracting representative: provides contracting, negotiation and process expertise.
Financial representative: provides budgetary expertise.
Organizational change leader: provides expertise in facilitating change within the organization.
Governance committee: provides oversight, is often not directly involved in the team and receives the team's reports.
The governance committee remains intact once implementation begins, to monitor and ensure the project's success, and in some organizations is called a steering committee.

Question:

Match each named role to what it contributes.
Distinguish the facilitator from the executive sponsor.

What membership obliges

The role of team members is to represent their specific area within the organization.
It is very difficult to include everyone affected by the new system on the team.
Members are expected to gather information from their peers and bring it back to the team.
All requirements should be reviewed and approved by the team.

Example

A nurse manager on the team who never asks her unit what they need has represented herself rather than her area, and the requirement list will show the gap at scoring time.

Question:

State the two duties of a team member beyond attending meetings.

Memory tips

Nine seats: facilitator, executive sponsor, technical, business, project manager, contracting, financial, change leader, plus the governance committee above them.
Facilitator leads the process; executive sponsor clarifies mission, secures resources and champions.
Governance committee gives oversight, receives reports, is sometimes called a steering committee, and survives into implementation.
Member obligation: represent the area, gather peer input, review and approve all requirements.

Key concepts

Facilitator: the member providing overall leadership and coordination of the selection process
Executive sponsor: the member providing support, clarifying the mission, facilitating resources and championing the effort
Technical representative: the member supplying IT, biomedical and telecommunications expertise
Business representative: the member supplying business or clinical end-user expertise and knowledge of current workflows
Contracting and financial representatives: the members providing contracting, negotiation and process expertise, and budgetary expertise
Organizational change leader: the member with expertise in facilitating organizational change
Governance committee: the oversight body that receives the selection team's reports, is sometimes called a steering committee and continues through implementation
Member responsibility: representing a specific area, gathering peer information and approving all requirements

Practice questions

5 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: timing and sizing of team selection · required areas of representation · each named role and its contribution · the governance committee's oversight and reporting relationship, its alternative name and its persistence into implementation · member duties to represent an area, gather peer input and approve requirements.

Read the original source

Selecting Review Team Members

The selection of the review team should be completed as early as possible. It is possible that the entire team might not be needed at the very early stages of the process or that some members may not be as actively involved as others. Team members should be identified early so they will be ready to participate when needed. Decisions about team membership should balance the importance of including the right people with the need to keep the size manageable.

The exact members will depend on what is being selected and should include representatives from clinical, organizational operations, IT and the business department to ensure all affected areas are involved. Below is a list of who might be involved in the selection team:

Facilitator—Provides overall leadership and coordination of the system selection process.

Executive sponsor—Provides support, clarifies the mission, facilitates necessary resources and acts as champions within the organization.

Technical representative—Provides technical expertise, such as IT, biomedical and telecommunications.

Business representative—Provides business or clinical end-user expertise. These individuals are highly knowledgeable about the current business and workflows and represent the end users.

Program/project manager—Provides implementation and methodology expertise.

Contracting representative—Provides contracting, negotiation and process expertise.

Financial representative—Provides budgetary expertise.

Organizational change leader—Provides expertise related to facilitating change within the organization.

Governance committee—Provides oversight but is often not directly involved in the team. The selection team reports to this group. Once implementation begins, this group will remain intact to monitor and ensure the project's success. In some organizations, this group is called a steering committee.

The role of team members is to represent their specific area within the organization. It is very difficult to include everyone who will be affected by the new system on the team. Members should be expected to gather information from their peers to bring back to the team. This process helps to ensure that the right information will be reviewed and included where needed throughout the selection process. All requirements should be reviewed and approved by the team.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 3 of 9

Solution Selection Activities

Big picture

This section walks the activities between an approved requirement set and a signed contract. It follows the team because these activities are what the team executes. The larger problem it solves is comparability again, this time under sales pressure: demonstrations, site visits and references only compare if every vendor faces the same scenarios and questions. Demonstrations and site visits are the pair to distinguish, because one shows a generic product and the other shows a configured one in use.

Walkthrough

Gathering and scoring vendor information

Consult the contracting or legal representative before contacting vendors, since rules exist to avoid giving any vendor an advantage.
The RFI gathers information on which vendors can meet high-level requirements, and responses may lead to modifying requirements before the RFP is posted.
The RFP is the official request for vendors to submit how they will meet the more defined requirements, with timelines and budget details.
RFP responses are reviewed and scored against required, preferred and optional requirements.
Scoring is done independently by each team member, followed by team discussion and consensus on a final score.
Comparison to the IT strategic plan asks how the solution fits the IT roadmap, whether toward virtualization, simplification of technologies or fewer vendors.
A solution that does not fit the roadmap may still be acceptable, but the mismatch should be considered during selection.
Interoperability capability spans core data integration, standards-based sharing such as FHIR or HL7 version 2, and application integration using SMART on FHIR or CDS Hooks.
Regulatory requirements should be listed as essential, and all vendors evaluated against government, regulatory and security requirements.
Background checks evaluate financial stability, market share and customer satisfaction, matched to the organization's risk tolerance.

Independent scoring before discussion is the mechanism that keeps one confident voice from setting the whole team's score.

Question:

Describe the scoring process and why it is done independently first.
What does a background check evaluate, and against what organizational trait is it matched?
Name the levels of interoperability capability the source lists.

Seeing the product

Demonstrations let vendors show how they meet the request, but are often given with a generic version of the product that does not reflect configuration to the organization's workflows.
Provide scenarios in advance so vendors show how the product meets your needs rather than only their chosen features.
All vendors should demonstrate the same scenarios, with the same people attending, and demonstrations scheduled closely together so information stays fresh.
The agenda should be tightly controlled, with additional functionality allowed only at the end if desired.
A trial version or trial period allows the organization to run end-user scenarios and identify roles and responsibilities needed for real implementation.
Site visits allow direct conversation, specific questions and observation of the solution inside real workflows.
Site visit questions cover what it is like to work with the vendor, how the vendor responds to support requests during implementation and after go-live, and how easy customization and integration are.
It is optimal for the organization rather than the vendor to choose which sites to visit, though this is not always possible.
Client references by call or remote web meeting substitute when a site visit is not possible, with predefined questions for each reference and attention to lessons learned.

Example

A demonstration shows what the product can look like; a site visit shows what it looks like after someone has lived with it for two years. The second answers questions the first cannot.

Question:

State the main limitation of a demonstration and the controls that make demonstrations comparable.
What does a site visit provide that a demonstration cannot, and what should be asked?

From shortlist to contract

Selection meetings re-score remaining vendors against new information from research, demonstrations, site visits and proposal scores, narrowing the field to two or three.
The team's comments and final evaluations go to the contracting representative for negotiations.
Negotiation covers cost, software, hardware, implementation services, support and maintenance.
The selection committee and a legal representative should review all documents carefully, since signed papers are a binding contract.
Cost tables should include software licenses, integration, data conversions, training, implementation services, hardware and third-party software licenses.
Each step and the justification of the selection should be documented in case a vendor contests the award.
Final agreements often include payment schedule, vendor and client responsibilities, delivery schedule, installation and configuration documentation, specific deliverables, a standard project plan, penalties for missed deadlines, the termination process, assignment of licenses and the process for upgrades or updates.
The budget is developed from negotiated costs and often includes contractors, business change management, hardware not bought from the software vendor, integration services from other vendors, training, travel and fixed or variable costs such as space and staffing.
The budget is typically finalized within 30 days after the final contract is awarded.
Contract size, time constraints or a desire to stay with a single vendor may shorten the process, and each step cut brings some level of risk to be balanced against the benefit.

Question:

What does documenting each selection step protect against?
List the project budget items that fall outside the system vendor's costs.
What can shorten the selection process, and what does shortening cost?

Memory tips

Comparability controls: same scenarios, same attendees, tightly controlled agenda, demonstrations close together, predefined reference questions.
Demonstration limitation: generic product, not configured to your workflows.
Narrowing path: RFI pool, RFP scoring, research and visits, two or three finalists, negotiation, selection.
Budget beyond the vendor: contractors, change management, non-vendor hardware, third-party integration, training, travel, space and staffing. Finalized about 30 days after award.
Documentation motive: a contested award.

Key concepts

Independent scoring: each team member scoring RFP responses alone against required, preferred and optional requirements before team discussion and consensus
Comparison to the IT strategic plan: evaluating how a vendor's solution fits the IT roadmap, with mismatch permitted but considered
Background checks: evaluation of vendor financial stability, market share and customer satisfaction against the organization's risk tolerance
Demonstrations: vendor presentations, usually of a generic product, made comparable by shared scenarios, consistent attendees and a controlled agenda
Site visits and client references: direct observation of a configured system in use, or remote substitutes using predefined questions and lessons learned
Negotiation and selection: contracting-led negotiation over cost, software, hardware, services, support and maintenance, with each step documented against a contested award
Project budget: negotiated vendor costs plus contractors, change management, other hardware, integration services, training, travel and fixed or variable costs, typically finalized within 30 days of award

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: consulting contracting before vendor contact · RFI and RFP roles in the activity sequence · independent scoring and consensus · IT strategic plan comparison · interoperability capability spectrum · regulatory evaluation · background check content and risk tolerance · demonstration limitations and controls · trial versions · site visit value, questions and site choice · client references and lessons learned · selection meetings and narrowing · negotiation scope and contract review · cost table contents · documentation against contest · final agreement elements · budget contents and 30-day finalization · reasons for shortening and its risk.

Read the original source

Solution Selection Activities

Once the requirements have been approved and the decision to buy has been made, it is time to look for vendors that are able to meet them. It is important to consult with your contracting or legal representative to understand the organizational rules and regulations about contacting vendors prior to a signed contract. Some regulations are in place to avoid giving any one vendor an advantage. The contract representative will be able to guide you through the selection activities. The following elements may be involved in solution selection:

RFI: The request for information provides a format for gathering information about which vendors are able to meet the high-level requirements. The responses are compared with the documented requirements, which may be modified prior to posting the RFP if it is clear some required items are not available or require more definition.

RFP: The request for proposal provides the official request for vendors to submit how they will meet the requirements, which are more defined and include timelines and budget details.

Evaluation of RFP responses: Responses should be reviewed and scored based on ability to meet required, preferred and optional requirements. This step is accomplished with the entire team doing independent scoring of each response, followed by team discussion and consensus on a final score. This process helps identify which vendors can meet the organizational need and provides the first opportunity to eliminate any vendor that cannot.

Comparison to IT strategic plan: When evaluating the responses, it is important to understand how a vendor's solution or planned implementation will fit with the organization's IT strategic plan. Is the IT roadmap leading in the direction of virtualization, to simplification of technologies, or to a decreased number of vendors? How does the offered solution fit with this roadmap? It might be OK if the solution does not fit, but that fact should be considered during selection.

An evaluation of a vendor's interoperability capabilities is another important factor to consider: To adopt best of breed solutions, it is absolutely critical to have interoperable systems that doesn’t add burden to the end user workflow. The systems need to integrate seamlessly with the existing solutions to provide greater insights with data integration and efficient workflows with system-level integration. Interoperability capabilities span a wide spectrum from core data integration, standard based data sharing such as using Fast Healthcare Interoperability Resources (FHIR®) or Health Level Seven (HL7®) Version 2, to optimal application integration using Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR or CDS Hooks standards.

Compliance with regulatory requirements: Pertinent regulations should be part of your requirements and listed as essential. All vendors should be evaluated against any government, regulatory or security requirements.

Background checks: Once the list of possible vendors is decreased, some research should be done. This would include evaluation of their financial stability, market share and customer satisfaction. How long a product has been on the market and how many other customers are using it should be matched to your organization's risk tolerance level. Are you an early adopter who can tolerate some issues with the application if you are able to work with the vendor on new features and functionality? Or, would you prefer a solid, reliable application that the vendor has had time to refine? The outcome of this activity should be included in the scoring of each vendor.

Demonstrations: Requesting a demonstration allows vendors to show how they can meet the request. This provides a visual that is very beneficial, but it is often done with a generic version of the product. This does not reflect how it can be customized to fit the organization's workflows or processes. Prior to the demonstration, it is suggested that a list of scenarios be provided to the vendors so they will show how their product can meet your needs, rather than highlight only the features that they choose. All vendors should be guided to demonstrate the same scenarios to ensure they can be compared with one other. Whenever possible, the same people should be invited to all scheduled demonstrations. Having each vendor demonstrate how their product fits within the same scenarios and having the same people attending each meeting make it easier to properly compare and score each option prior to final selection. It is important to control the agenda very tightly, making sure all scenarios are covered and, if you choose, allowing vendors to demonstrate additional functionality at the end. Demonstrations should be scheduled closely together, if possible, so the information is fresh when they are scored.

Trial period or trial version of the software: With many cloud-based solutions, it is becoming easier to offer trial versions of the system or the system for a trial period. If available, facilities should take advantage of it to run through the end user scenarios in the system to see its fit for the requirements. This also provides for an ability to identify various roles and responsibilities needed for real implementation and to assist in additional implementation planning activities.

Site visits: Visiting a site that has already worked with a vendor and implemented their solution provides an opportunity to speak with people directly, ask specific questions and see how the solution works within their workflows and processes. This helps to demonstrate how the system can be customized during the implementation to fit defined workflows and processes. Questions to ask during site visits would range from what it is like to work with the vendor, how they respond to requests for support during the implementation or after go-live and how easy it is to customize the application or to integrate it with other systems. The number of site visits is often dependent on the number of vendors remaining at this point in the process. The decision on who should participate often depends on who will be affected by the implementation and the distance to be traveled for the visit. It is optimal if the organization, and not the vendor, chooses what sites to visit, but this is not always an option.

Client references: If a site visit is not possible, a call with the reference site would still provide the ability to ask questions. While the selection team will not be able to actually view the system live, the same questions can be asked. Through use of remote web meeting technologies, it is possible to have a demonstration of how a client is using the system without the travel. This provides the ability to understand the implementation process, so remember to ask about any lessons learned from their experience. Just like a demo, there should be predefined questions to be asked of each reference site. Simple web searches and informal contacts with peers can also provide some good reference information.

Selection meetings: Throughout this process, the team is meeting regularly to continuously evaluate and score the remaining vendors against the new information obtained through the research, demonstrations, site visits and original proposal scores. Through this process, the number of vendors should be decreased to two or three. The team's comments and final evaluations of each of the remaining options are provided to the contracting representative for negotiations.

Negotiation: The contract representative negotiates with the remaining vendors to obtain the best solution for the organization. This would include cost, software, hardware, implementation services, support and maintenance. The selection committee, as well as a legal representative, should carefully review all documents sent to the organization from the vendors because once the papers are signed, they are a binding contract. During the negotiation, there may be multiple requested modifications to the documents that require back and forth communication. This process can take a while since each modification needs to be properly reviewed by the other party before they come back with their modifications and so on. The cost tables should include costs for items such as software licenses, integration, data conversions, training, implementation services, hardware and third-party software licenses.

Selection: Based on the negotiations and the final offer from each of the remaining vendors, the team makes a selection. Each step of this process, along with the justification of the selection, should be documented in case any vendor chooses to contest the award. The final agreements often include items such as payment schedule, vendor and client responsibilities, delivery schedule, system installation and configuration documentation, specific deliverables, standard project plan, penalties for not meeting deadlines, termination process, assignment of licenses and process for upgrades or updates.

Budget development: During the negotiations, the budget is developed based on the costs defined during negotiation and selection. The budget often needs to include costs beyond the system vendor. Other items that might be included in the project budget are contractors to supplement the organization's staff; business change management requirements; hardware not purchased through the software vendor, such as new workstations or printers; costs from other vendors for integration services; training; travel; and standard fixed or variable costs, such as space and staffing. The budget is typically finalized within 30 days after the final contract is awarded.

The formality, steps included, and length of this process can vary greatly. There are various reasons for this beyond the organizational contracting process. The contract size, a time constraint, or the desire to stay with a single vendor might shorten this process. With each step, a document or process that is cut brings some level of risk. The organization needs to balance the risk versus the benefit of shortening the process.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 4 of 9

The Implementation Process and Project Planning

Big picture

This section covers what happens once a vendor is chosen: the phases an implementation runs through and the plans that have to exist before work starts. It follows selection because the contract does not implement itself. The larger problem it solves is planning failure, which the source names as the most common cause of project failure. Scope approval and the kickoff meeting are the sequence to hold: sponsors approve scope before other plans are finalized, and the kickoff communicates the approved plan.

Walkthrough

Phases and project management strategy

The phases of an implementation are fairly standard, with methodologies differing mainly in terminology or number of phases.
The basic phases are planning, analysis, design, build, test, train, implementation and closeout.
All of them start with gathering information and planning what work is required, when and how.
Most projects fail due to lack of planning, poor planning or not following the plan.
An organization without a defined project management strategy should decide what processes will be followed.
That includes defining project team roles, categorizing facility team versus vendor team tasks, the project manager's authority, expected documentation and deliverables, and the role of the governance or steering committee.

Question:

Name the implementation phases in order.
What does the source name as the most common cause of project failure?

Plans and the kickoff

The initial activity is planning how the project will be accomplished, including what is within and outside scope.
Project sponsors approve the scope before any other plans are finalized.
The risk management plan, change management plan, training plan, testing plan, issue management plan, work breakdown structure and communication plan all need preparation.
Together these documents make up the project management plan and define the tasks to be scheduled.
The activation plan is developed and approved when preparations for go-live begin.
After sponsors approve the project management plan, a kickoff meeting communicates the project to all stakeholders.
The kickoff agenda covers the project scope, the project management methodology, the change management process, identified risks and mitigation strategies, the project team and roles, high-level milestones and schedule, and the communication plan.
The kickoff then launches the remaining work following the SDLC phases and typical project management processes.
The test plan should be started during the planning and analysis phases.
During implementation the project manager controls resources, manages scope, schedule and cost, reports progress and facilitates resolution of issues and risks.

Example

A kickoff that introduces the team and the schedule but never states how a change is requested leaves the first scope conversation to be improvised under pressure.

Question:

Which item do sponsors approve before other plans are finalized?
Name the plans making up the project management plan.
Reconstruct the kickoff agenda.

Memory tips

Eight phases: planning, analysis, design, build, test, train, implementation, closeout.
Scope first: sponsors approve scope before any other plan is finalized.
Seven plans in the project management plan: risk, change, training, testing, issue management, work breakdown structure, communication. The activation plan comes later.
Kickoff agenda seven: scope, methodology, change process, risks and mitigation, team and roles, milestones and schedule, communication plan.
Failure causes three: no planning, poor planning, not following the plan.

Key concepts

Implementation phases: planning, analysis, design, build, test, train, implementation and closeout
Project management strategy: the defined roles, task division between facility and vendor teams, project manager authority, documentation expectations and governance role
Scope approval: the sponsor decision made before any other plans are finalized
Project management plan: the risk, change management, training, testing and issue management plans plus the work breakdown structure and communication plan
Activation plan: the go-live plan developed and approved when activation preparations begin
Kickoff meeting: the stakeholder communication covering scope, methodology, change process, risks and mitigation, team and roles, milestones and schedule, and the communication plan

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: standard phases and methodological variation · the eight named phases · planning as the common failure point · elements of a project management strategy · scope definition and sponsor approval · the seven plans composing the project management plan · the activation plan's timing · kickoff timing and agenda · continuation through the SDLC · test plan start timing · project manager control responsibilities.

Read the original source

Implementation Process

Now that a system has been selected, it is important to define how it will be implemented. While the phases of an implementation are fairly standard, there are a variety of defined methodologies that differ only in the terminology they use or the number of phases. The basic phases which implementation projects go through include: planning, analysis, design, build, test, train, implementation and closeout. It is important to remember that they all start with gathering information and planning what work is required, along with when and how it will be done. Most projects fail due to lack of planning, poor planning, or not following the plan. If the organization does not have a defined project management strategy, it would be important to take the time to decide what processes will be followed throughout the project. This includes defining the project team's roles, categorizing which tasks need the facility project team vs the vendor implementation team, the project manager's authority, the documentation and deliverables expected throughout the project and the role of the governance or steering committee.

The initial activity is to plan how the project will be accomplished. This includes defining what is within and outside the scope of the project. The project sponsors will approve the scope prior to any other plans being finalized. Also, the risk management plan, the change management plan, the training plan, the testing plan, the issue management plan, the work breakdown structure and the communication plan all need to be prepared. All of these documents make up the project management plan and define the tasks to be scheduled to successfully complete the project. When preparations begin for the activation (go-live), the activation plan is developed and approved.

At the end of the planning phase, after the sponsors approve the project management plan, a kickoff meeting is conducted to communicate the project to all stakeholders. The agenda often includes the following:

The project scope

The project management methodology, or how the project will be managed

The change management process, or how changes are requested, analyzed and approved

Identified risks and their mitigation strategies

Introduction of the project team and their roles

High-level milestones and schedule

The communication plan

This meeting and conversation then kicks off the remaining work, following the phases as identified in the systems development life cycle (SDLC) and using typical project management processes.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 5 of 9

Change Management

Big picture

This section covers the human side of implementation: who leads change, what resistance to expect and how adoption is actually decided. It follows project planning because the change plan is one of the plans prepared there. The larger problem it solves is that automation alone does not improve anything, so change work is where the benefit is realized. Project change control and organizational change management share a name and are different things: one governs scope requests, the other governs people's willingness to work differently.

Walkthrough

Leading the change

Any new system will affect the organization, and some change will need to occur.
It is not good enough to just automate a process; the process should be improved through automation.
Changes affect everyone from top management to end users.
Planning for change and evaluating options for managing it should begin during the procurement process.
Top-level support matters, including a member of senior leadership on the change management team, to show commitment and provide strong leadership.
The team should include members from all affected areas so they have ownership and commitment to the project's success.
The team should identify clinical champions and IT champions to serve as decision makers and points of contact for change and risk management activities.
The team defines a strategic plan similar to the project plan, accounting for organizational culture and politics around how staff handle change.
Types of resistance should be identified along with the strategy to break down resistance and move to acceptance.
A clear communication plan ensures information is properly disseminated.

Question:

Why does the source say automating a process is not sufficient?
Who should sit on the change management team and why?
What must the change strategic plan take into account?

What drives adoption

Adoption is often affected by users' perceptions of how the system fits their workflow.
The questions are whether it provides efficiencies or appears to be extra work, and whether functionality causes a perceived negative change in processes or can be made to fit and improve them.
Adoption is often based on perceived benefit by the end users.
Staff have to be ready for the change, which is why stakeholder involvement in workflow redesign is critical.
Involving end users in hardware selection, such as workstations on wheels or mobile devices, gives the project team feedback on usability.

Question:

State what adoption most depends on, in the source's terms.
Give two ways stakeholder involvement improves the outcome.

Change control during execution and after go-live

There will be requests to change project scope or requirements during execution.
A defined process for evaluating each request and determining its impact helps prevent scope creep.
The change management plan identifies who can submit changes, how they are evaluated, what documentation is required and who decides.
A request may be approved, denied or deferred, with sponsors usually deciding and the project manager facilitating the impact analysis.
Users will almost immediately have suggestions for changing the system after go-live, and a clear submission process shows their input is valued.
It is important not to make changes too early, since many suggestions arise only because the system and processes are new and different.
Unless suggestions are critical to patient care they should be documented for now.
Critical issues are handled right away but still follow the defined change management process.
Remaining suggestions should be evaluated one to two months after activation to see whether they are still needed.

Example

A request to move a button gets logged and revisited in six weeks. Half of those requests disappear once the workflow stops being unfamiliar, which is the reason for the wait.

Question:

What does the change management plan have to specify?
How should post-activation suggestions be handled, and what is the exception?

Memory tips

Principle to recite: automating a bad process is not improvement.
Change team composition: senior leader for commitment, members from all affected areas, clinical and IT champions.
Adoption driver: perceived fit with workflow and perceived benefit, not functionality alone.
Change request outcomes three: approved, denied, deferred. Sponsors decide, project manager runs impact analysis.
Post-go-live rule: log suggestions, act only on patient care critical ones, revisit the rest at one to two months.

Key concepts

Change management team: a team including senior leadership, members from all affected areas, and clinical and IT champions serving as decision makers and contacts
Change strategic plan: a plan parallel to the project plan accounting for culture and politics, anticipated resistance and the strategy to move toward acceptance
Adoption: the outcome most affected by users' perception of workflow fit and perceived benefit, supported by stakeholder involvement in workflow redesign and hardware selection
Project change control: the defined process identifying who submits changes, how they are evaluated, what documentation is required and who approves, with outcomes of approved, denied or deferred
Post-activation change handling: documenting non-critical suggestions, acting immediately only on patient care critical issues and reevaluating the rest one to two months after activation

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the requirement that automation improve the process · breadth of change impact · change planning beginning during procurement · senior leadership and affected area membership · clinical and IT champions · the change strategic plan, culture, resistance and communication · adoption drivers and stakeholder involvement in redesign and hardware selection · scope change requests and scope creep prevention · change plan contents and decision rights · post-activation suggestion handling and the one to two month reevaluation.

Read the original source

Change Management

Any new system will have an impact on the organization, and some change will need to occur. It is not good enough to just automate a process; the process should be improved through automation. Changes affect everyone from top management to end users. Planning for these changes and evaluating the different options for managing them should begin during the procurement process. It is important to have top-level support, as well as a member of senior leadership on the change management team, to show commitment and provide strong leadership. The team should also include members from all affected areas, so they have a sense of ownership and commitment to the project's success. The team should also identify clinical champions as well as IT champions who can serve as the decision makers and point of contact for various change management and risk-management activities, along with other implementation activities.

The team should define a strategic plan similar to the project plan used for implementing the software. The strategic plan should take into consideration the organizational culture and politics related to how staff handle change. The types of resistance that might occur should be identified, along with the strategy to break down the resistance and move on to acceptance. A clear communication plan will ensure the information is properly disseminated throughout the organization.

Adoption is often affected by users’ perceptions of how the system fits with their workflow. Does it provide efficiencies or appear to be extra work? Does the system functionality cause a perceived negative change in processes, or can the system be made to fit within the processes and even improve them? Often, the adoption is based on perceived benefit by the end users. The staff has to be ready for the change, which is why stakeholder involvement in the workflow redesign is critical. Having end users involved in hardware selection, such as workstations on wheels or mobile devices, provides feedback to the project team about the usability of the devices being evaluated. Some additional change management principles and strategies will be discussed in Chapter 9.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 6 of 9

Implementation Strategies

Big picture

This section presents the five ways an organization can bring a system live and what each trades away. It follows change management because the strategy chosen shapes how much change users absorb at once. The larger problem it solves is matching rollout to culture, resources and the system being replaced. Phased by location and phased by functionality are the pair most often swapped, and the difference is what is held constant: one place at a time with everything, or one feature at a time everywhere.

Walkthrough

The five strategies

Big bang: going live with all functionality in all locations at the same time.
If a legacy system is being replaced, big bang might be the only option.
Big bang requires considerable coordination so that all areas are ready, with hardware in place, training completed and enough support staff available.
Phased by location: going live with all functionality in one location at a time.
Phasing by location extends the activation duration but lets staff from live areas support those that follow, and lessons learned meetings after each phase feed continuous improvement.
Phased by functionality: going live in all locations with one feature at a time, such as admission, discharge and transfer with demographics first, then CPOE, then clinical documentation.
Phasing by functionality also extends activation and lets users become accustomed to the system gradually.
Pilot: going live initially with one location as a pilot test, then following with everyone else in a phased big-bang process, so the team learns from a small group first.
Like for like: going live with functionality supporting the same processes that were in place before the project, with extra functionality added later through configuration management or a later project.
Like for like is often used when replacing a legacy system or upgrading, decreasing activation complexity and end-user impact.
Some users will perceive like for like as useless because they see no improvement.

Every strategy other than big bang buys learning with time. The cost is a longer activation period and, in phased approaches, a stretch where two ways of working coexist.

Question:

Name the five strategies and the defining move of each.
Distinguish phased by location from phased by functionality using the source's example.
When is like for like used, and what objection does the source anticipate?

Memory tips

Five strategies: Big bang, Phased by location, Phased by functionality, Pilot, Like for like.
Big bang cue: everything everywhere at once, often the only option when replacing a legacy system.
Location versus functionality: one site with everything, versus one feature everywhere.
Pilot cue: one site first to learn, then a phased big bang for the rest.
Like for like cue: same processes as before, extras deferred; expect the no-improvement complaint.

Key concepts

Big bang: going live with all functionality in all locations simultaneously, often the only option when replacing a legacy system and demanding heavy coordination
Phased by location: going live with all functionality one location at a time, extending activation but enabling peer support and lessons learned between phases
Phased by functionality: going live in all locations one feature at a time, such as ADT first, then CPOE, then clinical documentation
Pilot: going live at one location as a test before a phased big bang for the remainder
Like for like: going live supporting the same processes as before, with added functionality deferred to configuration management or a later project

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the five implementation strategies and their definitions · big bang's legacy replacement case and coordination demands · the benefits of phasing by location including peer support and lessons learned · the ADT, CPOE and documentation sequence for phasing by functionality · the pilot's learning purpose · like for like's use in replacement and upgrade, its reduced complexity and the perception problem it creates.

Read the original source

Implementation Strategies

There are multiple strategies for implementing a new system. Early in the project, they should be evaluated to determine which one is the right fit for the organization and right for the current system implementation:

Big bang—Going live with all functionality to be implemented in all locations at the same time. If there is a legacy system being replaced, this might be the only option. This strategy requires a considerable amount of coordination to ensure that all areas are ready, with hardware in place, training completed and enough support staff available.

Phased by location—Going live with all functionality to be implemented in one location at a time. This strategy extends the duration of the activation activity, but provides some benefits. The staff from the areas that are already live can assist with providing support to the ones that follow. Holding a meeting after each phase to discuss lessons learned could provide continuous improvement for later phases.

Phased by functionality—Going live in all locations with one feature at a time. An example would be to bring the admissions process live first for admission, discharge and transfer and patient demographic information, followed by computerized practitioner order entry (CPOE) and then clinical documentation. This strategy also extends the duration of the activation and allows users to gradually get accustomed to the system before utilizing it fully. As above, meeting after each phase to discuss lessons learned could provide continuous improvement for future phases.

Pilot—Going live initially with one location as a pilot test, and then following with everyone else in a phased big-bang process. This allows the team to learn from a small group before going live with the entire user community.

Like for like—Going live with functionality to support the same processes that were in place prior to the project. Extra functionality is often added later through configuration management (discussed later in this chapter) or a later project. This strategy is often used when replacing a legacy system or during an upgrade. It helps to decrease the complexity of the activation and decreases the impact on the end users. There will always be some users who perceive this approach to be useless since they do not see an improvement.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 7 of 9

Building, Integrating, Training and Activating

Big picture

This section covers execution: configuring the vendor's product, integrating it with other systems, training users and running the go-live. It follows strategy selection because the strategy determines the shape of the activation. The larger problem it solves is that everything here happens under a date, so sequencing and rehearsal matter more than individual skill. Real-time and scheduled integration are the pair to keep apart, and device integration adds the validation requirement neither of the others carries.

Walkthrough

Configuring the application

The project team takes the basic vanilla application the vendor provides and customizes it to meet the organization's needs.
The vendor should train the project team on how to make these changes.
Configuration includes clinical documentation entry into notes or flow sheets and output as reports.
Every order that can be placed, such as medications, diagnostic tests, diets and consults, has to be configured.
Other items range from drop-down lists for a patient's religion at admission to how surgery is scheduled.
Data conversion or loading from a legacy system happens during this time, with some migration occurring at activation so all data is present at go-live.
Care should be taken to avoid duplication during migration, and data validation after each migration should pair with an action plan to resolve duplicate records.
Vocabulary mapping should align with industry standards such as RxNorm, SNOMED and LOINC.
Testing activities occur throughout execution, often beginning with verification that hardware and the application were installed correctly in each environment.

Question:

What is the first testing activity in execution, and what does it verify?
What risks does data migration carry, and what controls does the source name?

System integration

It is rare to have a stand-alone system that does not share data with another.
The EHR should include lab and radiology data, and demographics should flow between outpatient and inpatient systems so the patient does not repeat information.
Integration allows data to be in multiple systems without manual data entry.
Real-time data integration shares data nearly simultaneously when it is entered or modified or when a defined trigger occurs, with HL7 as the standard defining interface messages.
Scheduled data integration shares data in a batch on a predetermined timeframe, such as nightly at midnight, through formatted files or HL7 messages.
Integration of data from devices feeds data from hemodynamic monitors, vital sign monitors, anesthesia machines and ventilators into an application, decreasing manual entry but often requiring verification before the data becomes official.
Integration uses an interface engine that receives information from the source system and either passes it directly or modifies it before passing it along.
An example modification is combining a first and last name into the full name a destination system requires.
Systems differ in how data must be structured and where in the message specific data is expected, and a mapping document describes the expected locations and any manipulation.

Question:

Distinguish real-time, scheduled and device integration.
Explain what an interface engine does with an example of transformation.
What does a mapping document describe?

Training and support

A training environment should be set up early so the training team can develop materials and hypothetical patient data.
Training must take place on the system that will actually be used, so the training environment cannot be fully set up until configuration is complete and a copy is made.
Training decisions depend on organizational culture, extent of the change, number of users, users' work hours and staff comfort level with computers.
Training can be delivered through computer-based modules, lectures, demonstrations, hands-on exercises or a combination.
Training should occur right before activation so users retain what they were taught, with timing driven by the number of users and class length.
The best planning will not eliminate the need for just-in-time training, since someone will miss class or forget a step.
End-user manuals, quick reference guides and support staff presence during the first week or two fill that gap.
Workflow documents explain end users' workflows and how the system fits their daily activities.

Question:

Why can the training environment not be built early in full?
What factors decide the training approach, and what gap remains no matter the plan?

Activation and immediate post-activation

Activation planning begins with the implementation strategy decision and continues through the project.
The organization works with the vendor to define which activities can be completed in advance and which must occur on go-live day.
Moving from a manual process to an automated one can be as simple as users starting to use the system, while migration or upgrade involves a period of downtime.
A detailed checklist of tasks before and during activation ensures nothing is missed.
A rehearsal tests the process, surfaces mistakes, refines the checklist and raises the team's confidence.
Planning covers where everyone will sit, whether a command center will be used, food and drink, rest space, communication for those outside the command center and how status updates reach end users.
It also covers how escalation is handled and whether the vendor will be on site or on the phone.
Type and duration of post-activation support depend on the impact of the change and the amount of just-in-time training expected.
Clinic implementations may need support just before and during clinic hours for the first week, while a new acute care EHR may need around-the-clock support for the first few weeks.

Example

A rehearsal that runs two hours over is a cheap failure. The same overrun on go-live day happens while clinicians are waiting for the system.

Question:

What does an activation rehearsal accomplish?
Name the logistics considerations activation planning covers beyond the technical tasks.
What determines post-activation support duration?

Memory tips

Configuration scope: documentation, reports, every orderable item, list values, scheduling, plus migration and vocabulary mapping to RxNorm, SNOMED and LOINC.
Integration three: real-time on a trigger via HL7, scheduled in batches, device feeds requiring clinician verification.
Interface engine job: receive, optionally transform, deliver in the structure the destination expects, guided by a mapping document.
Training timing: right before activation, on a copy of the real configuration, with just-in-time support afterward.
Activation kit: checklist, rehearsal, command center, escalation path, communication, and support sized to the change.

Key concepts

Configuration: customizing the vendor's vanilla application, covering documentation, reports, orderable items, list values and scheduling
Data migration controls: validation after each migration, an action plan for duplicate records and vocabulary mapping to RxNorm, SNOMED and LOINC
Real-time integration: near-simultaneous data sharing on entry, modification or a defined trigger, standardized by HL7
Scheduled integration: batch sharing on a predetermined timeframe through formatted files or HL7 messages
Device integration: data fed from monitors, pumps and similar devices, often requiring verification before becoming official
Interface engine and mapping document: the component that receives and optionally transforms data for the destination system, guided by documentation of expected data locations and manipulations
Training environment: a copy of the completed configuration used for training, built only after configuration is complete
Just-in-time training: the support that remains necessary after formal training, backed by manuals, quick reference guides and on-site support staff
Activation planning: the checklist, rehearsal, command center, escalation, communication and logistics preparations for go-live, with support duration matched to the change

Practice questions

19 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: vanilla application customization and vendor training of the project team · configuration scope · data conversion timing, duplication risk, validation and vocabulary mapping standards · first testing activity · rarity of stand-alone systems and the purpose of integration · real-time, scheduled and device integration definitions · device verification requirement · interface engine function, transformation example and mapping documents · training environment timing and constraints · factors determining training approach and delivery modes · training timing and just-in-time need · manuals and support staff · workflow documents · activation planning, checklists, rehearsal value and logistics · escalation and vendor presence · post-activation support duration examples.

Read the original source

Implementing Solutions

You have taken enough time to properly plan how the system will be implemented. You have selected a project team with the right skills, chosen the right implementation strategy, identified what features will be implemented, and developed an outstanding communication plan. Now all you have to do is follow your plan.

This is when the project team takes the basic vanilla application the vendor provides and customizes it to meet the organization's needs. The vendor should provide training to the project team on how to make these changes. This includes configuring the clinical documentation data entry into notes or flow sheets, as well as the output as reports. Each order that can be placed for a patient, such as medications, diagnostic tests, diets and consults, has to be configured in the system. Other items range from drop-down lists for a patient's religion during admission to how surgery will be scheduled. If there is a legacy system, the data conversion or loading of data also happens during this time. Even if data is migrated early, some data migration will have to occur during activation to ensure that all data is in the new system when it goes live. Care should also be taken to avoid duplication of data during the migration. Data validation after each migration is an important step that should be combined with an action plan to resolve duplicate records if they occur. Vocabulary mapping process should also be implemented to align with industry standards such as RxNorm®, SNOMED® and LOINC®.

Part of the methodology should include how changes are handled during the project. There will be some requests to change the scope of the project or some requirements during the execution phase. Having a defined process for evaluating each request to determine its impact on the project helps prevent scope creep. The change management plan should identify who can submit changes, how changes are evaluated, what documentation is required and who makes the final decision. A request may be approved, denied, or deferred to a later time. The project sponsors usually make the decision with the project manager facilitating the impact analysis.

Testing activities occur throughout the execution. A test plan, which should have been started during the planning and analysis phases, describes all the different testing activities to be completed during the project. Often, the first testing activity is verifying that the hardware and application were installed correctly. Each of the initial environments, such as development, testing, or training, is required to ensure that the installations were successful. Testing will occur throughout the project based on the test plan and the different types of testing to be performed. For additional information on systems testing, refer to Chapter 7.

System Integration to Support Business Requirements

It is rare in healthcare today to have a stand-alone system that does not share data with another in some way. The electronic health record (EHR) should include data from the lab and radiology systems so those who need to make medical decisions can view the results. Patient demographic information should be shared between the outpatient clinic, or office system, and the inpatient EHR so the patient does not need to provide the same information over and over again. Integration allows data to be in multiple systems without manual data entry. Some types of integration to be considered include the following:

Real-time data integration—Sharing of data nearly simultaneously when it is entered or modified or when another defined trigger occurs. The standard for this type of integration is HL7, which defines the specifics surrounding the interface messages so what is sent from the source system is acceptable by the destination system.

Scheduled data integration—Sharing of data in a batch according to a predetermined time frame, such as nightly at midnight or every so many hours. The data feed can be accomplished through formatted files or HL7 messages.

Integration of data from devices—Feeding of data from a specific device into an application. These devices can range from hemodynamic monitors to vital sign monitors and anesthesia machines to ventilators. This type of interface helps decrease manual data entry, but may require the data to be verified before it becomes official within the system.

Integration utilizes an interface engine that receives information from the source system and either passes it directly to the destination system or makes some modification to the data before passing it along. For example, a modification would occur if the source system sent a patient's name as first name and last name, but the destination system could only accept a full name. The interface engine would accept the first and last names, combine them and send the full name on. Different systems have different requirements for how the data is structured and where in the interface message they expect the specific data to be located. The interface message has sections, and a mapping document describes where each piece of data is expected to be and if the interface engine needs to do any manipulation.

User and Operational Manuals and Training

As a project nears activation, it is necessary to educate the end users through documentation and training. If hands-on training is required, a training environment should be set up early in the project to allow the training team to develop materials and hypothetical patient data for any practice exercises that might be included. Training activities are tricky to schedule because they need to take place on the system that will actually be in use. As a result, the training environment cannot be fully set up until the entire configuration is completed and a copy created.

There are many factors that lead to the decision on what type of training should be provided. These include the organizational culture, extent of the change, number of users, users’ work hours and even the staff's comfort level with computers. Training can be done through computer-based training modules, lectures, demonstrations, hands-on exercises, or a combination of these.

Training should occur right before the activation so the users will retain what they were taught. The timing depends on how many users need to be trained and how long the training classes will be. Experience shows that the best planning will not eliminate the need for just-in-time training. Inevitably, someone will not make it to class or will not remember how to do something. End-user manuals and quick reference guides along with the presence of support staff during the initial week or two will help fill this gap.

Activation Planning and Immediate Post-Activation Activities

Planning for the system to go-live begins with the decision on implementation strategy discussed earlier in this chapter and continues through the remainder of the project. The organization should work with the vendor to define which activities can be completed in advance and which have to occur on the go-live day. The actual activities will depend on the specific project. If the organization is moving from a manual process to an automated one or is implementing a new system, the activation could be as simple as having users start using the system. When migrating from a legacy system or upgrading an existing system, the activation activities are more complex and include a period of time when the system is down, or unavailable. A detailed checklist of tasks that occur before and during the activation, whether downtime is scheduled or not, helps to ensure nothing will be missed or forgotten. A rehearsal of the activation provides an opportunity to test the process and fix any mistakes that occur. Evaluating the rehearsal helps to refine the process and the checklist to make the actual activation go more smoothly. It also boosts the project team's level of confidence because they have already done the tasks at least once, depending on how many rehearsals are conducted.

The planning for activation goes beyond the actual tasks that will occur to bring the system up. Other considerations should include where everyone will sit; if a command center will be set up so the entire team will be in one location; if food and drink will be available, especially if the activity will go beyond a few hours; if there will be a place for the staff to rest; what forms of communication will be available for anyone not in the command center; and how status updates will be communicated to the end users. How will issues requiring escalation be handled, and will the vendor be on-site or on the phone to provide assistance?

The type and duration of post activation support will depend on the impact of the change and the amount of just-in-time training expected. When implementing a new system in a clinic, the support staff might be available just before and during clinic hours for the first week. When implementing a new EHR in an acute setting, the support staff might be available around the clock for the first few weeks.

The users will almost immediately have suggestions for changing the system. Having a clear process for submitting requests for change will help users know their input is valuable. With that said, it is important not to make changes too early. Often, the suggestions are just because the system, workflows, or processes are new and different from the ways the users have always done things. Unless suggestions are critical to patient care, they should just be documented for now. Critical issues should be taken care of right away, but should still follow a defined change management process as discussed previously. The rest of the suggested changes should be evaluated one to two months after activation to see if they are still needed.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 8 of 9

Managing the System in Operations and Maintenance

Big picture

This section covers life after go-live: the documentation that makes support possible, the processes that control change and the service desk that receives the calls. It follows activation because that is when the project ends and operations begin. The larger problem it solves is stability under continuous change, since vendor fixes and user requests never stop arriving. Configuration management and release management work together and answer different questions: how a change is approved and made, and when and how it moves between environments.

Walkthrough

Operations and maintenance documentation

Once live, the system moves into operations and maintenance mode, where IT must ensure it continues to support the organization's mission and goals and remains reliable and stable.
Processes put in place during implementation include configuration management, release management, customer support through a service desk and resolution of issues entered as trouble tickets.
Communication plan: defines how end users communicate with IT about the system, including how to request help, modifications and general how-to answers.
Service desk knowledge base: explains how to identify and resolve issues, including questions to ask and decision trees, plus the escalation process and who has authority to contact the vendor.
Data flow documents: identify where and how data flows between systems or locations, the dependencies and the triggers, such as a patient location change updating the lab system.
Workflow documents: explain end users' workflows and how the system fits their daily activities.
Configuration management process: defines how changes are made and what approval and documentation each change requires.
Downtime procedures: identify what end users do when the system is unavailable and what technical staff do to identify and resolve the cause.
Manuals: end-user manuals, training guides and the configuration manual giving step-by-step directions for making changes.

Question:

Name the operations and maintenance documents and what each covers.
Which document carries the escalation process and vendor contact authority?

Controlling change after go-live

Configuration management and release management control changes to the system, including software and hardware.
They cover how changes are requested, reviewed and approved, how changes are made and tested, and how changes are released across environments so environments stay in sync and each migration is verified.
Changes should be made in a development environment, tested in a test environment and verified in production.
Regression testing after changes ensures new modifications did not break something else.
Controlling how and when changes are made in each environment is critical to avoiding unexpected negative results.
Small vendor fixes are sometimes called hot fixes, and range up to major upgrade releases.
Scheduling updates with the vendor keeps the system current while minimizing unexpected downtime.
Each new update should be evaluated before moving through the configuration management process, and an update large enough should be managed as a separate project.

Example

A hot fix applied straight to production skips the two checks that would have caught its side effect. The environments exist so that surprise happens in test rather than on a unit.

Question:

Trace a change through the environments and name the test that protects existing function.
How should vendor updates be handled, and when does one become a project?

Customer support

Customer support is often provided through a help desk or a single phone number reaching someone who can listen and help resolve issues.
Calls may concern a system issue, a usability problem or a training or how-to question.
A good knowledge base lets help desk staff ask the right questions and resolve issues on the first call, keeping customer satisfaction high.
A process for second-tier support is needed when the service desk cannot resolve an issue.
That is often handled through a help desk or ticket management system, though a custom database with workflows and notifications could also work.
Timely feedback to the customer matters until the problem is resolved.

Question:

What kinds of calls does the service desk receive?
What makes first-call resolution possible, and what happens when it is not achieved?

Memory tips

Seven operations documents: communication plan, service desk knowledge base, data flow documents, workflow documents, configuration management process, downtime procedures, manuals.
Environment path: develop, test, verify in production, with regression testing after each change.
Hot fix is the small vendor fix; a large enough update becomes its own project.
Help desk call types three: system issue, usability, training or how-to.
Escalation lives in the knowledge base, including who may contact the vendor.

Key concepts

Operations and maintenance mode: the phase after go-live in which IT keeps the system aligned to organizational mission and goals and keeps it reliable and stable
Service desk knowledge base: the document explaining identification and resolution of issues with questions and decision trees, plus escalation and vendor contact authority
Data flow and workflow documents: records of where and how data moves between systems with its triggers and dependencies, and of user workflows and the system's place in them
Configuration management: the process defining how changes are made and what approval and documentation each requires
Release management: the control of how changes move between environments so they stay in sync and each migration is verified
Regression testing: testing after a change to confirm the modification did not break existing function
Hot fix: a small vendor fix released between major upgrades, evaluated before entering configuration management
Second-tier support: the escalation path used when the service desk cannot resolve an issue, with timely customer feedback until resolution

Practice questions

12 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the move into operations and maintenance and its obligations · processes established during implementation · each operations and maintenance document and its content · configuration and release management scope · the development, test and production sequence · regression testing · environment synchronization · hot fixes and upgrade scheduling · evaluation of updates and escalation to a project · help desk structure and call types · knowledge base and first-call resolution · second-tier support and customer feedback.

Read the original source

Managing Healthcare Information Systems

Once the system is live, it moves into operations and maintenance mode. During this time, the IT department must ensure that it continues to support the mission and goals of the organization and remains reliable and stable. During the implementation project, various processes should be put into place in preparation for this phase. These processes include configuration management, release management, customer support through a service desk and resolution of any issues entered as trouble tickets. Documentation about how the system was configured feeds into good operations and maintenance documentation for resolving issues when they arise. Examples of operations and maintenance documentation include the following:

Communication plan—Defines how end users communicate with the IT department about the new system. How will they request help for an issue? How will they request modifications to the system? How will they request help for general questions about how to use the system?

Service desk knowledge base—Explains how to identify and resolve issues when a user contacts the service desk. This includes questions to ask and decision trees to help identify the resolution or the escalation process if an issue cannot be resolved. The escalation process should include how to approach the vendor if an issue cannot be resolved internally, as well as who has the authority to contact the vendor.

Data flow documents—Identifies where and how data flows from one system to another or from one location in the system to another, along with the dependencies between systems. This includes the triggers that prompt the data to flow, such as a change in the patient's location would trigger the information to be sent to update the lab system.

Workflow documents—Explains end users’ workflows and how the system fits into users’ daily activities.

Configuration management process—Defines how changes are made and what levels of approval and documentation are required for each change.

Downtime procedures—Identifies which procedures end users will follow when the system is unavailable and what procedures the technical staff will follow to identify and resolve an issue causing downtime.

Manuals—A group of documents ranging from end-user manuals to training guides and the configuration manual that provides step-by-step directions on how to make changes in the system.

Configuration management and release management are processes to control changes to the system, including software and hardware. They involve how changes are requested, the process for review and approval of changes, how changes are made and tested and the process for releasing changes to the different environments to ensure that they are kept in sync and that each migration is verified. It is important that changes are made in a development environment, tested in a test environment and finally verified in production. Conducting regression testing after the changes are made ensures the new modifications did not break something else. Controlling how and when changes are made in each environment is critical in avoiding unexpected negative results.

Working with the vendor on scheduling updates for small fixes, sometimes called hot fixes, to major upgrade releases will keep the system current while minimizing unexpected downtimes. Each new update should be evaluated prior to moving it through the configuration management process. If the update is large enough, it should be managed as a separate project.

Customer support is often provided through a help desk or a single phone number that goes to someone who can listen and help to resolve the issues the end users have. The calls may pertain to a an issue with the system; a problem with the usability of the system; or a training or how-to question. Having a good knowledge base that allows the help desk staff to ask the right questions and provides enough information to resolve the issue during the first call can keep customer satisfaction high. For times when the service desk cannot resolve an issue, it is important to have a process for providing second-tier support. Often, this is done through a help desk or ticket management system, but a custom database with workflows and notifications could work also. Timely feedback to the customer is important until the problem is resolved.

Chapter 6 · Selection, Implementation, Support and Maintenance · Lesson 9 of 9

Analyzing Trends, Enhancements and Continuity Planning

Big picture

This section closes the chapter with the long view: whether the system delivered what was promised, how requests for change are prioritized and what happens when the system is unavailable. It follows operations because these are the activities that recur for the life of the application. The larger problem it solves is accountability after the project team disbands, since the investment case has to be checked against results. Business continuity, disaster recovery and the downtime plan are three related documents with different subjects: the business, the technology and the people working without the system.

Walkthrough

Looking for trends

Throughout an application's life cycle it is good practice to look for trends in usage as well as problems.
Within the first year after go-live, analysis should determine whether the application actually met the need identified before purchase.
That analysis evaluates how well the goals leading to the investment were met and whether the expected return on investment was realized.
Results should go back to the governance committee for possible action, especially if the need was not met.
Reasons to collect data include tracking new system adoption over months or years, evaluating user satisfaction and understanding system performance trends.
Data collection methods include surveys, user groups and visits to users.
On the technical side, trends in error reports, help desk logs, monitor logs and unexpected downtimes help staff plan performance improvements.

Example

Help desk logs showing repeated login failures on one unit is a trend rather than a set of incidents, and it points at something specific about that unit's devices, accounts or training.

Question:

What must the first-year analysis determine, and who receives the result?
Name the data collection methods for user-side and technical-side trends.

Repairing, maintaining and enhancing critical functions

Technical staff receive change requests through help desk calls, rounds, user groups and direct change requests.
Some requests raise issues that must be fixed by the vendor or seek enhanced functionality not currently available.
Each change or group of changes should be evaluated and, if approved, prioritized.
Smaller changes move through configuration management and are assigned and migrated on the release management schedule.
Larger requests or groups of requests should be managed as separate projects following the project management process.

Question:

Where do change requests come from, and how are they routed by size?

Business continuity, disaster recovery and downtime

The criticality of the system within the organization defines the disaster recovery and business continuity plans.
The business continuity plan defines how an organization prepares for and maintains business functions related to the system.
It covers operations and maintenance for stability, resolution of issues that could cause unavailability, how the business continues without the system and how to recover from an actual disaster.
The disaster recovery plan focuses on technical aspects such as data backup and recovery after the system goes down.
Backups are often done nightly and stored off-site on redundant servers or with a cloud computing provider, typically for an indefinite period.
Hardware configurations such as automatic failover between clustered servers provide some continuity, and vendors can offer configuration options.
For critical systems, some organizations keep off-site facilities where the system can be recovered from backup.
The disaster recovery plan, or a separate technical downtime plan, should include the steps for when the system goes down from causes other than a disaster, covering identification, resolution, who is involved and the root cause analysis process.
These processes should be tested regularly and updated as needed.
The downtime plan focuses on business aspects such as operating without the electronic system, including communication procedures, hard-copy forms and plans for entering data once the system returns.
Users dependent on the system are reluctant to use manual processes, so regular review of the downtime plan and communication before scheduled downtime help adoption, with support staff available whenever the plan is in use.

Question:

Distinguish the business continuity plan, the disaster recovery plan and the downtime plan by subject.
What does the downtime plan have to cover about the return to service?

Memory tips

First-year question: did the application meet the need and realize the expected return? Report to governance either way.
Trend sources: surveys, user groups and user visits on the human side; error reports, help desk logs, monitor logs and unexpected downtimes on the technical side.
Request routing: small changes through configuration and release management, large ones become projects.
Three plans, three subjects: continuity is the business, disaster recovery is the technology, downtime is working without the system.
Downtime plan must cover data entry after recovery, not only operation during the outage.

Key concepts

First-year analysis: the evaluation of whether the application met the identified need and realized the expected return on investment, reported to the governance committee
Trend data collection: surveys, user groups and user visits, alongside error reports, help desk logs, monitor logs and unexpected downtime records
Change request routing: evaluation and prioritization of requests, with small changes moving through configuration and release management and large ones managed as projects
Business continuity plan: the plan for preparing for and maintaining business functions related to a system, including operating without it and recovering from a disaster
Disaster recovery plan: the technical plan for data backup and recovery, including off-site and cloud backups, failover configurations and recovery facilities
Downtime plan: the business-side plan for operating without the electronic system, covering communication, hard-copy forms and data entry once the system returns

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: trend analysis across the life cycle · the first-year evaluation against the identified need and expected ROI · reporting to governance · reasons for collecting data and the collection methods · technical trend sources · sources of change requests · evaluation, prioritization and routing by size · criticality driving continuity and recovery planning · business continuity plan scope · disaster recovery plan scope, backup practice, failover and recovery facilities · the technical downtime plan and root cause analysis · regular testing · downtime plan contents and post-recovery data entry · user reluctance to revert to manual processes.

Read the original source

Analyzing Data for Problems and Trends

Throughout the life cycle of any application, it is good practice to look for trends in usage as well as problems. Within the first year after an application goes live, analysis should occur to see if it actually met the need that was identified prior to its purchase. This is an evaluation of how well the goals leading to the investment were met and if the expected return on investment was realized. The results should be brought back to the governance committee for possible action, especially if the need was not met.

There are many reasons to collect data and look for trends. A researcher may want to look for levels of new system adoption over the months or years, evaluate user satisfaction with a system, or understand trends in system performance. The ways to collect data can be through surveys, user groups, or visits to the users. On the technical side, looking for trends in error reports, help desk logs, monitor logs, or unexpected downtimes will help the technical staff plan for improvements in system performance.

Ensuring Critical Functions Are Repaired, Maintained or Enhanced

The technical staff receives many different kinds of requests for change. These include feedback from users through help desk calls, rounds, user groups and direct change requests. Some of these requests raise issues that must be fixed by the vendor or seek enhanced functionality not currently available. Vendors often provide updates, as mentioned earlier. Each change, or group of changes, should be evaluated and, if approved, prioritized. The smaller changes move through the configuration management process and are assigned and migrated according to the release management schedule. Larger requests or groups of requests should be managed as separate projects and follow the project management process.

Business Continuity and Disaster Recovery Plans

As was also discussed in Chapter 5, the criticality of the system within the organization will define the disaster recovery and business continuity plans. The business continuity plan defines how an organization prepares for and maintains the business functions related to the defined system. This includes the operations and maintenance of the system to ensure stability, the process of resolving issues that could or do cause the system to be unavailable, how the business will continue without the system and how to recover from an actual disaster.

The disaster recovery plan focuses on the technical aspects, such as data backup and recovery after the system goes down. Backups of the data are often done nightly and stored off-site on redundant servers or through a cloud-computing provider, typically for an indefinite amount of time. There are also hardware configurations that provide some level of continuity, such as automatic failover between clustered servers. Vendors can provide some options for how their systems can be configured. For critical systems, some organizations have off-site facilities where they can recover the system from backup if needed. Part of the disaster recovery plan, or a separate technical downtime plan, should include the steps to follow when the system goes down from causes other than a disaster. How the issue is identified and resolved, who is involved, and the process for a root cause analysis should all be included in this plan. These processes should be tested on a regular basis and updates should be made as needed.

The downtime plan focuses on business aspects, such as how to continue to operate without the electronic system. It includes procedures for communication, hard-copy forms for documentation and plans for how data will be entered into the system once it becomes available again. Once users become dependent on the system for their work processes, they are reluctant to use manual processes. Regular reviews of the downtime plan and communication before any scheduled downtime will help with adoption, but support staff should be available to provide assistance whenever the downtime plan is required.

Chapter 6 · Selection, Implementation, Support and Maintenance · Supplemental lesson

Delivery Methodology and Service Management

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Chapter 6 covers the implementation sequence without the methodology that governs how work is planned and the service management discipline that takes over once the system is live. Both are heavily tested because they carry umbrella-versus-component distinctions. The governing hierarchy is governance above project management above service management.

Walkthrough

Delivery approaches

Predictive, or waterfall, defines requirements up front with sequential phases and formal change control, and suits stable requirements, well-understood domains and regulatory documentation demands. Its weakness is discovering requirement errors late, when they are expensive.
Adaptive, or agile and iterative, delivers work in short increments with requirements refined each cycle. Scrum is the most common framework, with fixed-length sprints, a product backlog, a product owner who prioritizes and defined ceremonies.
Adaptive approaches suit emergent requirements and strain fixed-price contracts, regulated documentation and stakeholders who want a date.
Hybrid places a predictive governance envelope of fixed budget, defined milestones and formal gates around adaptive delivery, and is what most health systems actually run.
DevOps is adjacent but distinct: practices integrating development and operations to shorten the change cycle with automated build, test and deployment, concerned with delivery flow rather than requirements management.

Example

In a predictive approach, changing requirements mid-project is scope creep. In an adaptive approach, refining requirements between iterations is the method working. The same behaviour, two paradigms.

Question:

Match predictive, adaptive and hybrid to the conditions each suits.
Name the Scrum elements and what DevOps is concerned with.

Service management and governance

Once a system is live, project management gives way to service management, and ITIL is the dominant framework.
An incident is an unplanned interruption or degradation, and the objective is to restore service as quickly as possible, with a workaround a legitimate resolution.
A problem is the underlying cause of one or more incidents, and the objective is to eliminate recurrence; a known error with a documented workaround is a problem management artifact.
A change is any addition, modification or removal that could affect services, governed by change control, typically through a change advisory board.
A service request is a routine user request such as access, a password or standard equipment, which is not an interruption.
Incidents are symptoms and problems are causes, so restoring service does not fix the cause.
COBIT sits above both as an IT governance framework concerned with aligning IT with enterprise objectives, risk and value delivery.
Governance decides what should be done and who decides; management does it.
The hierarchy runs governance through COBIT, project management through PMBOK, and service management through ITIL.

Question:

Distinguish incident, problem, change and service request by objective.
Place COBIT, PMBOK and ITIL in the hierarchy and say what each governs.

Memory tips

Three approaches: predictive for stable and regulated, adaptive for emergent, hybrid for both at once.
Scrum set: sprints, backlog, product owner, ceremonies. DevOps is flow, not requirements.
ITIL four: incident restores, problem eliminates the cause, change is controlled modification, request is routine.
Frameworks by layer: COBIT governs, PMBOK delivers projects, ITIL runs services.
Handover point: project management ends at transition to operations, service management begins there.

Key concepts

Predictive delivery: up-front requirements with sequential phases and formal change control, suited to stable and regulated work
Adaptive delivery: short increments with requirements refined each cycle, commonly through Scrum sprints, backlog, product owner and ceremonies
Hybrid delivery: a predictive governance envelope around adaptive delivery, standard in regulated complex environments
DevOps: practices integrating development and operations with automated build, test and deployment to shorten the change cycle
ITIL constructs: incident as an unplanned interruption restored quickly, problem as the underlying cause eliminated, change as a controlled modification and service request as a routine ask
COBIT: the IT governance framework aligning IT with enterprise objectives, risk and value delivery

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: predictive, adaptive and hybrid approaches with their conditions and weaknesses · Scrum elements · DevOps scope · the transition from project to service management · ITIL incident, problem, change and service request definitions and objectives · the symptom and cause relationship · COBIT's governance role and the governance, project management and service management hierarchy.

Read the supplemental lesson source

S6.1 — Delivery Methodology and Service Management

Chapter 6 · Tasks III.C.1–C.6 · About 14 minutes

1. Learn the topic

Where this fits

Chapter 6 covers the implementation sequence well — kickoff artifacts, scope control, go-live, maintenance. What sits above the sequence is the methodology that governs how work is planned and delivered, and the service management discipline that takes over once the system is live. Coplan & Masuda's Project Management for Healthcare Information Technology is the Addendum B source for both.

What it means: delivery approaches

Predictive (waterfall). Requirements defined up front, phases sequential, change managed through formal change control. Works when requirements are stable, the domain is well understood and regulatory documentation demands traceability. Its weakness: you discover requirement errors late, when they are expensive.

Adaptive (agile/iterative). Work delivered in short increments; requirements refined each cycle based on what the last increment revealed. Scrum is the most common framework — fixed-length sprints, a product backlog, a product owner who prioritizes, defined ceremonies. Works when requirements are emergent. Its weakness: it strains fixed-price contracts, regulated documentation and stakeholders who want a date.

Hybrid. A predictive governance envelope — fixed budget, defined milestones, formal gates — with adaptive delivery inside it. This is what most health systems actually run, and it is usually the defensible answer when a scenario has both regulatory constraints and uncertain requirements.

DevOps is adjacent but distinct: a set of practices integrating development and operations to shorten the change cycle, with automated build, test and deployment. It is about delivery flow, not requirements management.

What it means: service management

Once a system is live, project management gives way to service management. ITIL is the dominant framework, and its core distinctions are highly testable because they are exactly the umbrella-versus-component shapes CPHIMS likes:

Incident — an unplanned interruption or degradation. The objective is to restore service as quickly as possible. A workaround is a legitimate resolution.

Problem — the underlying cause of one or more incidents. The objective is to eliminate recurrence. A known error with a documented workaround is a problem-management artifact.

Change — any addition, modification or removal that could affect services. Governed by change control, typically through a change advisory board.

Service request — a routine user request (access, password, standard equipment) that is not an interruption.

The relationship: incidents are symptoms, problems are causes. Restoring service does not fix the cause. Confusing the two is why some organizations resolve the same incident forty times.

COBIT sits above both: an IT governance framework concerned with aligning IT with enterprise objectives, risk and value delivery. Governance decides what should be done and who decides; management does it.

How it works together

A useful mental hierarchy: governance (COBIT — are we doing the right things, who is accountable) → project management (PMBOK — are we delivering this initiative well) → service management (ITIL — are we running the result reliably).

Examples and non-examples

Straightforward. A regulated interface build with fixed scope and an external compliance deadline runs predictive. A clinician-facing dashboard whose requirements nobody can articulate until they see something runs adaptive.

Connecting to another concept. Your existing Topic 6.4 distinguishes scope creep from change control. That distinction is a predictive concept. In an adaptive approach, changing requirements between iterations isn't scope creep — it is the method working. The same behaviour is a failure in one paradigm and the point in another.

Non-example. "We're agile" used to mean the team doesn't document or plan. Agile prescribes a great deal of structure — cadence, roles, backlog, review. Absence of discipline is not a methodology.

Common misconceptions

"Agile has no documentation or planning." It has different documentation and continuous planning.

"Incident and problem management are the same activity." Different objectives: restore vs. eliminate.

"ITIL is a project management framework." It is service management, for the operational life of the service.

"Hybrid is a compromise for teams that can't commit." It is the standard model in regulated, complex environments.

2. Exam focus

What you must know

Predictive vs. adaptive vs. hybrid, and the conditions each suits.

Scrum basics: sprints, backlog, product owner, ceremonies.

ITIL: incident (restore) vs. problem (eliminate cause) vs. change (controlled modification) vs. request (routine).

COBIT = governance; PMBOK = project management; ITIL = service management.

Project management ends at transition to operations; service management begins there.

Distinctions likely to be tested

Incident vs. problem. This is the single most reliable ITIL trap and it is a textbook umbrella-versus-component pair.

Governance vs. management. Governance sets direction and accountability; management executes.

Change control (predictive, gate-based) vs. iterative refinement (adaptive, expected).

How this appears in a question

Scenario stems describing a situation and asking which approach fits, or which process applies. Match on the objective in the stem: "get the clinic working again" is incident; "stop this happening monthly" is problem.

Currency note — read once. The PMBOK Guide 8th Edition (published late 2025) consolidated the 7th Edition's twelve principles into six, the eight performance domains into seven, and reintroduced processes as five focus areas containing forty processes. If a bank item is keyed to PMBOK 6 process groups or PMBOK 7's twelve principles, answer in that frame.

3. Teach it back

Explain to a service desk manager:

1. Why closing the same incident every Monday is a sign of a process failure, and which process.

2. When you would choose predictive over adaptive for a clinical system build, and why.

3. Give an original example of something that is a service request and something that looks similar but is an incident.

<summary>Key-point checklist</summary>

[ ] Repeat incidents indicate absent problem management — restoration without cause elimination

[ ] Chose predictive for stable/regulated/traceable, adaptive for emergent, and named hybrid as the common real answer

[ ] Service request = routine and expected; incident = unplanned interruption or degradation

[ ] Placed COBIT (governance) above PMBOK (project) and ITIL (service)

[ ] Did not describe agile as absence of planning

</details>

4. Practice

Items SQ-35 to SQ-37.

5. Key takeaway

Governance decides, projects deliver, services run. Within delivery, the choice is predictive, adaptive or hybrid, driven by how stable the requirements are. Within operations, the sharpest line is incident (restore now) against problem (never again).

Chapter 7 · Testing and Evaluation · Lesson 1 of 6

The Purpose and Cost of Systems Testing

Big picture

This section states why testing exists and what it is supposed to produce for the people who read its results. It opens the Testing and Evaluation chapter, which sits between implementation and go-live in the Systems Management domain. The larger problem it solves is risk: testing is described as a risk-mitigation activity that converts unknowns about a system into knowledge stakeholders can act on. Hardware and software testing are distinguished here, and the validation list that follows is a complete named set the exam draws EXCEPT items from.

Walkthrough

What testing is for

Healthcare organizations rely on information systems for clinical, administrative, financial and legal operations.
Stakeholders must weigh the risks of implementing or modifying systems and mitigate them as much as possible, and testing is a critical element of that strategy.
The fundamental purpose of system testing is to provide knowledge to assist in managing the risks of developing, producing, operating and sustaining systems and their capabilities.
Testing provides knowledge of capabilities and limitations to stakeholders for improving system performance, and to the user community for optimizing use and sustaining operations.
It identifies technical and operational limitations so they can be resolved before production and deployment.
Information systems often have a direct impact on patient safety, so identifying and testing areas likely to be major patient safety risks is very important.

Question:

State the fundamental purpose of system testing and who uses its knowledge.
Why does patient safety change how testing priorities are set?

What comprehensive testing validates

Testing and evaluation are performed on both hardware and software.
Hardware testing evaluates physical components such as circuits, drives and internal components.
Software testing investigates quality and validates functionality, aiming to find defects or bugs and fix them before release.
It also provides an objective, independent view of the software so the business can appreciate and understand implementation risks.
Comprehensive testing validates and verifies that a system meets the requirements that guided its design and development.
That it responds correctly to all kinds of inputs.
That it performs its functions within an acceptable time.
That it is sufficiently usable.
That it can be implemented and run in its intended environments.
That it achieves the general results the stakeholders desire.

Question:

Reconstruct the six validation statements without looking.
Distinguish hardware testing from software testing in the source's terms.

The cost of defects

A National Institute of Standards and Technology study released in 2002 reported that software bugs, meaning coding issues as well as integration challenges, cost the U.S. economy 59.5 billion dollars annually.
More than a third of those costs could have been avoided with better testing enabling earlier and more effective identification and resolution of defects.
The earlier a defect is found within the product development life cycle, the cheaper it is to fix.
In 2017 the estimated cumulative cost of software bugs and failures worldwide grew to 1.7 trillion dollars, affecting at least 3.7 billion people.
The first step in executing a successful test is creating a test methodology.

Example

A defect caught in unit testing costs a developer an afternoon. The same defect caught after go-live costs a downtime, a support surge and a correction cycle, which is the whole argument for testing early.

Question:

Give the NIST figure, its year and the share the study said better testing could avoid.
State the 2017 global figures.

Memory tips

Purpose in one line: testing produces knowledge for managing risk, for stakeholders and for users.
Six validation points: requirements met, all inputs handled, acceptable time, usable, runs in intended environments, achieves desired results.
Cost anchors: 59.5 billion dollars annually in the 2002 NIST study, more than a third avoidable; 1.7 trillion dollars worldwide in 2017 affecting at least 3.7 billion people.
Economic rule: the earlier the defect is found, the cheaper the fix.
First step of a successful test: create a test methodology.

Key concepts

Purpose of system testing: providing knowledge to manage the risks of developing, producing, operating and sustaining systems, for stakeholders improving performance and users optimizing use
Hardware testing: evaluation of physical components such as circuits, drives and internal components
Software testing: investigation of quality and validation of functionality to find and fix defects before release, giving the business an independent view of implementation risk
Comprehensive testing validation: confirming the system meets its design requirements, responds correctly to all inputs, performs within acceptable time, is sufficiently usable, runs in its intended environments and achieves the results stakeholders desire
Cost of defects: 59.5 billion dollars annually in the 2002 NIST study with more than a third avoidable, and 1.7 trillion dollars worldwide in 2017, with earlier detection cheaper

Practice questions

2 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

1 The 2002 NIST study estimated annual U.S. cost of software bugs atStress

A$5.9 billionB$59.5 billionC$595 billionD$5.95 trillion

2 A test lead is defining what software testing is intended to validate. Which objective does NOT belong?Stress

Amaximizes vendor revenueBperforms within acceptable timeCmeets the requirements that guided its designDresponds correctly to all kinds of inputs

Source fidelity

Covered from the source: reliance on information systems across operational domains · testing as risk mitigation · the fundamental purpose and its two audiences · identification of limitations before deployment · patient safety prioritization · hardware and software testing definitions · the independent view of risk · the six validation statements · the 2002 NIST cost figure and avoidable share · the earlier-is-cheaper principle · the 2017 global cost and population figures · test methodology as the first step.

Read the original source

Introduction

Healthcare organizations rely on information systems to manage clinical, administrative, financial and legal aspects of daily operations. As technology advances and new healthcare systems are developed and marketed, stakeholders must weigh the risks of implementing or modifying systems and mitigate those risks as much as possible. A critical element of that risk-mitigation strategy is testing and evaluating any new or modified component or system.

Purpose of Systems Testing

The fundamental purpose of system testing is to provide knowledge to assist in managing the risks involved in developing, producing, operating and sustaining systems and their capabilities. Specifically, system testing provides knowledge of capabilities and limitations to the stakeholders for use in improving the system performance, and to the user community for optimizing system use and sustaining operations. Furthermore, system testing identifies the technical and operational limitations of the system under development so they can be resolved prior to production and deployment.1 Information systems have become an integral part of healthcare operations and, as such, often have a direct impact on patient safety. With this in mind, identifying and testing for areas that are likely to be major patient safety risks is very important.

System testing and evaluation are performed on both hardware and software. Hardware testing includes evaluation of the physical components of the system (e.g., circuits, drives, internal components, etc.). Software testing is an investigation of the quality and validation of the functionality of a software product or service with the goal of finding any defects or “bugs” and fixing them before the product is released. Software testing can also provide an objective, independent view of the software that enables the business to appreciate and understand the risks of implementation. Test techniques include, but are not limited to, executing a program or application with the intent of finding software errors or other defects. Comprehensive testing is a process of validating and verifying that a system:

Meets the requirements that guided its design and development

Responds correctly to all kinds of inputs

Performs its functions within an acceptable time

Is sufficiently usable

Can be implemented and run in its intended environments

Achieves the general results the stakeholders desire2

Appropriate testing is critical for the success of any new or upgraded system. A study conducted by the National Institute of Standards and Technology (NIST) released in 2002 reported that software bugs (coding issues as well as integration challenges) cost the U.S. economy $59.5 billion annually.3 It also found that more than a third of these costs could have been avoided if better testing was performed to enable earlier and more effective identification and resolution of defects; the earlier a defect is found within the product development life cycle, the cheaper it is to fix. In 2017, the estimated cumulative cost of software bugs and failures worldwide grew to $1.7 trillion, affecting at least 3.7 billion people.4

The first step in executing a successful test is creating a test methodology.

Chapter 7 · Testing and Evaluation · Lesson 2 of 6

Test Methodology, Strategy and Tools

Big picture

This section names the six steps of a testing methodology and covers the first two in detail: the strategy that governs testing and the tools that carry it out. It follows the purpose of testing because a methodology is how purpose becomes practice. The larger problem it solves is that most healthcare organizations buy rather than build, so their IT staff hold only a partial picture of a system's development history and need a defined method to compensate. Test strategy and test plan are the pair to separate: one is the high-level description of how a system will be tested, the other is the derived detail of cases, scripts, schedules and criteria.

Walkthrough

The six steps

Define the test strategy.
Develop testing tools.
Execute testing.
Employ test controls.
Report on testing results.
Perform final evaluation.

Testing methodologies are the strategies and approaches used to test a product to ensure it is fit for purpose.
They involve testing that the product works in accordance with its specification, has no undesirable side effects when used outside its design parameters and, in a worst case, fails safely.
Many healthcare organizations adopt a buy-not-build strategy, outsourcing development or purchasing off-the-shelf solutions.
As a result their IT staff often has only a partial picture of the system's development history, which makes a well-defined methodology critical.
The methodology matters equally whether testing an enterprise system, an individual workflow or application, or a specific piece of code.

Question:

Name the six methodology steps in order.
What three things does a testing methodology check, including the worst case?
Why does the buy-not-build strategy raise the importance of methodology?

Test strategy and test plan

The test strategy is a formal, high-level description of how a system will be tested, also referred to as the test approach.
It is developed to address all facets of the testing process and ensure testing objectives are achieved.
It may include testing scope and objectives, current business issues, testing roles and responsibilities, status reporting methods, test automation and tools, test deliverables, applicable industry standards, testing measurements and metrics, risks and mitigation, defect reporting and tracking, and change or configuration management.
The more specific test plan may live within the strategy or as its own document and is derived from documented business requirements.
The test plan may contain test cases, conditions, scripts, testing schedules, test environments, pass or fail criteria and risk assessments.
The test strategy may be developed by a project manager, with the detailed test plan created by a test lead or team.
Both are shared with the project team, end users and other stakeholders for review and approval before testing begins.

Question:

Distinguish the test strategy from the test plan by author, level and content.
What has to happen to both documents before testing begins?

Manual and automated tools

Testing tools are widely available commercially, and which are needed depends on the testing methods employed.
Testing is performed either manually or through automated tools.
Manual testing is direct human interaction with a system to identify defects or unexpected outcomes, with a team member playing the role of an end user.
The test team often follows a written test plan or script leading them through important test cases.
Manual testing requires a written test plan, scripts or scenarios and a method of recording and reporting results.
Manual testing may find many defects but is laborious and time consuming, and may not be effective at finding defects not immediately apparent to the end user.
Automated testing uses special software, separate from the software being tested, that controls test execution, compares actual outcomes to predicted outcomes, sets up test preconditions and performs other control and reporting functions.
The most significant benefit of automation is the ability to duplicate the testing process, so tests can be run and repeated quickly.
Automation is often the most cost-effective method for systems with a long maintenance life, since even minor patches can break features that worked earlier and repeated testing is required for each patch or upgrade.

Example

An organization that upgrades its EHR quarterly repeats the same core regression suite every time. That repetition is exactly what automation pays for.

Question:

Define automated testing by what the controlling software does.
State the advantage and the limitations of manual testing.
For what kind of system is automation most cost effective, and why?

Memory tips

Six steps: strategy, tools, execution, controls, reporting, final evaluation.
Strategy versus plan: high-level approach, often by the project manager, versus cases, scripts, schedules, environments and pass or fail criteria, by the test lead or team.
Methodology test: works to specification, no undesirable side effects outside design parameters, fails safely in the worst case.
Automation payoff: repeatability, which matters most on systems with a long maintenance life.
Manual testing tools three: written plan, scripts or scenarios, a recording and reporting method.

Key concepts

Test methodology: the six-step approach of defining the test strategy, developing tools, executing testing, employing controls, reporting results and performing final evaluation
Test strategy: the formal, high-level description of how a system will be tested, covering scope, roles, reporting, tools, deliverables, standards, metrics, risks and defect tracking
Test plan: the detailed document derived from business requirements containing test cases, conditions, scripts, schedules, environments, pass or fail criteria and risk assessments
Manual testing: direct human interaction following a written plan or script, effective but laborious and weak at defects not apparent to the end user
Automated testing: use of separate software to control execution, compare actual to predicted outcomes, set preconditions and report, valued for repeatability over a long maintenance life

Practice questions

5 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the six methodology steps · definition of testing methodologies and the three checks including safe failure · the buy-not-build strategy and partial development history · applicability across scales · test strategy definition and contents · test plan derivation and contents · authorship of each and review before testing · manual testing definition, required tools and limitations · automated testing definition, functions and repeatability benefit · cost effectiveness on long maintenance life systems.

Read the original source

Test Methodology

Different types of methodologies are used in the field of systems testing and quality assurance for today's complex healthcare information technology (IT) systems. Whether testing an enterprise-level system, an individual workflow or application, or a specific piece of code, the methodology is equally important. Due to the complexity of healthcare systems, many healthcare organizations adopt a buy-not-build strategy, outsourcing development to or purchasing off-the-shelf solutions from companies that specialize in that area. As a result, their IT staff often has only a partial picture of their system's development history. In such cases, a well-defined testing methodology is critical to ensure that the delivered system meets the needs of the healthcare organization. Testing methodologies are the strategies and approaches used to test a particular product to ensure it is fit for purpose. Testing methodologies usually involve testing that the product works in accordance with its specification, has no undesirable side effects when used in ways outside of its design parameters, and, in a worst case, will fail safely.5 Testing scenarios vary widely among healthcare systems and are tailored for each organization by the test teams and stakeholders, but a sound testing methodology generally includes the following key steps:

Define the test strategy

Develop testing tools

Execute testing

Employ test controls

Report on testing results

Perform final evaluation

Each of these steps will be discussed in further detail in the following sections.

Test Strategy

The test strategy is a formal, high-level description of how a system will be tested. It is developed in order to address all facets of the testing process and ensure testing objectives are achieved. The test strategy, also referred to as the test approach, may include testing scope and objectives, current business issues to consider, testing roles and responsibilities, status reporting methods, test automation and tools, a list of test deliverables, applicable industry standards, testing measurements and metrics, risks and mitigation, defect reporting and tracking and change/configuration management. The more specific test plan, which may live within the test strategy or as its own document, is derived from the documented business requirements and may contain test cases, conditions, scripts, testing schedules, test environments, pass/fail criteria and risk assessments.6 The test strategy may be developed by a project manager, with the more detailed test plan created by a test lead or team, and once completed are shared with the project team, various end users and other stakeholders for review and approval before testing begins.

Test Tools

Testing tools are widely available in the commercial market; the specific tools required will depend on the testing method(s) employed. Generally, system testing is performed either manually or through the use of automated tools. Manual testing is simply direct human interaction with a system, testing to identify defects or unexpected outcomes. A member of the test team plays the role of an end user and tests most features of the application to ensure correct behavior. To ensure completeness of testing, the test team often follows a written test plan or script that leads them through a set of important test cases. Tools required for manual testing include a written test plan, test script or scenarios to follow and a method of recording and reporting the results. Although manual testing may find many defects in a system, it is a laborious and time-consuming process. In addition, it may not be effective in finding certain classes of defects not immediately apparent to the end user.

Automated testing may be performed through the use of special software (separate from the software being tested) that controls the execution of tests, compares actual outcomes to predicted outcomes, sets up test pre-conditions and performs other test control and test reporting functions. The use of automated testing tools in healthcare is expanding, and there are many automated tools available that can be tailored specifically to an individual system's testing needs. One of the most significant benefits of test automation is the ability to duplicate the testing process. Once tests have been automated, they can quickly be run and repeated. This is often the most cost-effective method for systems that have a long maintenance life; even minor patches over the lifetime of a system can cause features to break that were working at an earlier point in time, so repeated testing is required for each patch or upgrade.2

Chapter 7 · Testing and Evaluation · Lesson 3 of 6

Test Execution: Box Methods, Levels and Objectives

Big picture

This section covers how tests are actually run: the three points of view a tester can take and the test types classified by development level or by objective. It is the center of the chapter and the material most heavily tested. The larger problem it solves is matching the test to the question being asked, since a test that passes at one level says nothing about the next. Unit, integration and system testing are the level ladder; stress, acceptance and regression are classified by objective instead, and mixing the two axes is the usual error.

Walkthrough

White box, black box and gray box

Test execution methods mostly fall into white-box or black-box testing, based on the point of view the test engineer takes.
White-box testing, also known as clear-box, glass-box, transparent-box or structural testing, tests the internal structures or workings of a system rather than its functionality.
The white-box tester is concerned with how the system operates internally rather than how it is supposed to behave.
Black-box testing, also known as functional testing, tests the functionality of an application rather than its internal structures.
The black-box tester knows only what the system is supposed to do and has no knowledge of internal operations.
Gray-box testing combines the two, with the tester holding some knowledge of internal structures and understanding expected functionality.
Gray-box testing is most useful on existing systems that have been upgraded, patched or modified.

Question:

Define white-box, black-box and gray-box testing by what the tester knows.
When is gray-box testing most useful?

Tests classified by development level

During system development, tests are performed at unit, integration and system levels.
Unit testing checks individual units of source code and sets of one or more program modules together with associated control data, usage procedures and operating procedures to determine fitness for use.
A unit is the smallest testable part of an application, and unit tests are created by programmers and white-box testers during development.
Unit tests cannot validate overall functionality on their own; they ensure individual pieces function independently.
Integration testing combines individual modules, applications or units and tests them as a group to identify issues in how the integrated components interface and interact.
Integration testing takes unit-tested modules as input, groups them into larger aggregates, applies the tests defined in an integration test plan and delivers the integrated system ready for system testing.
It can be done with any box method but is best suited to gray-box testing.
System testing is conducted on a complete, integrated system to evaluate compliance with specified requirements.
It is one of the most common black-box methods and does not require knowledge of inner design or logic.
System testing combines all integrated components that passed integration testing with software integrated with hardware and tests them as a single system.
It detects inconsistencies between integrated software units, called assemblages, or between assemblages and hardware, and checks exchange of data with external applications and systems.

The ladder runs upward in scope and outward in knowledge: unit is internal and narrow, integration is partly internal and joins pieces, system is external and whole.

Question:

Name the three development levels and what each takes as input.
Who creates unit tests, and what can they not establish?
Which box method fits each level best?

Tests classified by objective

Stress testing determines the stability of a system by testing beyond normal operational capacity, often to a breaking point, to observe the results.
It emphasizes robustness, availability and error handling under heavy load rather than correct operation under normal circumstances.
Its goals may include ensuring the software does not crash under insufficient computational resources such as memory or disk space, unusually high concurrency or denial-of-service attacks.
Acceptance testing determines whether the requirements of a specification or contract are met and validates successful implementation.
It is usually created by business customers, the clients or users, which is why it is commonly called user acceptance testing, and executed before accepting transfer of system ownership from the developer or vendor.
It provides confidence that the delivered system meets the business requirements of sponsors, users and other stakeholders and acts as the final quality gateway.
Provided additional acceptance criteria are met, such as security testing, supportability and maintenance standards, usability standards and standards compliance, sponsors normally sign off and deliver final payment to the vendor.
Acceptance testing is also done internally for major upgrades and patches, and in some organizations the terms acceptance, system and integration testing may be synonymous.
Regression testing seeks to uncover new bugs or errors in an existing functional system changed by patches, enhancements or configuration changes.
Its intent is to ensure a planned software or hardware change did not introduce new faults into production.
A common method is repeating previously successful tests to see whether behavior changed or previously fixed bugs reemerged.

Example

Leadership asking what happens when 500 clinicians log in at 7 a.m. is asking for a stress test. Asking whether the contracted interface was delivered is asking for acceptance testing.

Question:

Distinguish stress, acceptance and regression testing by their objectives.
Who creates acceptance tests, when are they run and what follows a successful result?
What triggers regression testing, and what method does the source describe?

Memory tips

Box methods three: white box is internal structure, black box is functionality, gray box is both and fits upgrades and patches.
Level ladder: unit is the smallest testable part, integration joins unit-tested modules, system tests the whole against requirements.
Best fit: unit is white box, integration is gray box, system is black box.
Objective tests three: stress for stability beyond capacity, acceptance for contract and specification, regression for damage from change.
Acceptance cue words: created by business customers, executed before ownership transfer, final gateway, triggers sign-off and final payment.
After a vendor hot fix, the answer is regression testing.

Key concepts

White-box testing: testing of internal structures or workings, also called clear-box, glass-box, transparent-box or structural testing
Black-box testing: functional testing of what the system does, with no knowledge of internal operations
Gray-box testing: the hybrid approach used when the tester knows some internal structure and the expected functionality, best suited to upgraded, patched or modified systems
Unit testing: testing the smallest testable part of an application, created by programmers and white-box testers, confirming pieces function independently
Integration testing: testing unit-tested modules grouped into aggregates to find interface and interaction issues, delivering the integrated system for system testing
System testing: black-box testing of the complete, integrated system against specified requirements, including assemblage and hardware inconsistencies and external data exchange
Stress testing: testing beyond normal operational capacity, often to breaking point, emphasizing robustness, availability and error handling under heavy load
Acceptance testing: testing created by business customers to confirm specification or contract requirements are met before ownership transfer, acting as the final quality gateway before sign-off and final payment
Regression testing: testing that seeks new bugs introduced into a working system by patches, enhancements or configuration changes, commonly by repeating previously successful tests

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the two point-of-view categories and their alternate names · gray-box definition and best use · classification by development level versus objective · unit testing definition, authorship and limits · integration testing inputs, process and output, and its box-method fit · system testing scope, black-box character, assemblages and external exchange · stress testing purpose, emphasis and goals · acceptance testing authorship, timing, criteria, sign-off and payment consequence, internal use and terminology overlap · regression testing triggers, intent and common method.

Read the original source

Test Execution

Performing and documenting the test activities is the primary focus of the testing methodology. Test professionals can use any number of methods to execute test events, and most fall into one of two categories: white-box testing or black-box testing.2 These approaches are based on the point of view a test engineer takes when executing test cases. White-box testing (also known as clear-box testing, glass-box testing, transparent-box testing, or structural testing) is a method of testing the internal structures or workings of a system, as opposed to its functionality; the tester is not concerned with how the system is supposed to behave or function, but rather with how the system is supposed to operate on an internal level. Black-box testing (also known as functional testing) is a method of software testing that tests the functionality of an application, as opposed to its internal structures or workings; the tester is only aware of what the system or application is supposed to do and has no knowledge of the internal operations of the system. A hybrid of the two approaches is known as gray-box testing, which is a combination of white-box and black-box testing approaches; the tester has some knowledge of internal structures and also understands the expected system functionalities. Gray-box testing is most useful when performing tests on existing systems that have been upgraded, patched or modified.

Test methods are classified and executed based on the level of the test or the specific objective of the test. During system development, tests are performed at specific levels of development: unit-level testing, integration testing and system testing. Test methods that are not associated with a specific level of development are classified by the testing objective, such as stress, user acceptance and regression testing.

Test Execution

Performing and documenting the test activities is the primary focus of the testing methodology. Test professionals can use any number of methods to execute test events, and most fall into one of two categories: white-box testing or black-box testing.2 These approaches are based on the point of view a test engineer takes when executing test cases. White-box testing (also known as clear-box testing, glass-box testing, transparent-box testing, or structural testing) is a method of testing the internal structures or workings of a system, as opposed to its functionality; the tester is not concerned with how the system is supposed to behave or function, but rather with how the system is supposed to operate on an internal level. Black-box testing (also known as functional testing) is a method of software testing that tests the functionality of an application, as opposed to its internal structures or workings; the tester is only aware of what the system or application is supposed to do and has no knowledge of the internal operations of the system. A hybrid of the two approaches is known as gray-box testing, which is a combination of white-box and black-box testing approaches; the tester has some knowledge of internal structures and also understands the expected system functionalities. Gray-box testing is most useful when performing tests on existing systems that have been upgraded, patched or modified.

Test methods are classified and executed based on the level of the test or the specific objective of the test. During system development, tests are performed at specific levels of development: unit-level testing, integration testing and system testing. Test methods that are not associated with a specific level of development are classified by the testing objective, such as stress, user acceptance and regression testing.2

Unit testing is performed by checking individual units of source code and sets of one or more computer program modules together with associated control data, usage procedures and operating procedures to determine if they are fit for use. Intuitively, one can view a unit as the smallest testable part of an application. Unit tests are created by programmers and white-box testers during the development process. They cannot validate overall functionality on their own but are used to ensure that individual pieces function independently.

Integration testing involves combining individual software modules, applications or units and testing them as a group to identify any issues in how the integrated components interface and interact with each other. Integration testing takes as its input, modules that have been unit tested, groups them into larger aggregates, applies tests defined in an integration test plan to those aggregates and delivers as its output the integrated system ready for system testing. Integration testing can be done using any of the box methods (white, black or gray) but is best suited for gray-box testing when the tester has some knowledge of the internal code of the individual units, as well as the expected system functionality.

System testing is conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing is one of the most common black-box testing methods and, as such, does not require knowledge of the inner design of the code or logic. System testing combines all of the integrated components that have successfully passed integration testing with software that has been integrated with hardware and tests them as a single system. The purpose of integration testing is to detect any inconsistencies between the software units that have been integrated (called assemblages) or between any of the assemblages and the hardware, as well as the exchange of data to external applications and systems.

Stress testing is a form of testing that is used to determine the stability of a given system. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. The stress test puts a greater emphasis on robustness, availability and error handling under a heavy load, rather than on what would be considered correct operation under normal circumstances. The goals of such tests may be to ensure the software does not crash in conditions of insufficient computational resources (such as memory or disk space), unusually high concurrency, or denial-of-service attacks.

Acceptance testing is conducted to determine if the requirements of a specification or contract are met and to validate successful system implementation. Acceptance testing is usually created by business customers (the clients or users, so also commonly referred to as user acceptance testing or UAT) and executed prior to accepting transfer of system ownership from the developer or vendor. Acceptance testing provides confidence that the delivered system meets the business requirements of sponsors, users and other stakeholders. The acceptance test may also act as the final quality gateway through which any quality defects not previously detected may be uncovered. Provided certain additional acceptance criteria are met (e.g., security testing, supportability and maintenance standards, usability standards and standards compliance), system sponsors will normally sign off on a system as satisfying contractual requirements and deliver final payment to the vendor upon successful completion of acceptance testing. Acceptance testing is also done internally when major upgrades, patches and the like are involved. The terms acceptance testing, system testing and integration testing may be synonymous in some organizations and in some testing situations.

Regression testing is any type of system testing that seeks to uncover new bugs or errors in an existing functional system that has been changed by implementation of patches, enhancements, or configuration changes. It is common for new issues to be uncovered through the introduction of new systems. The intent of regression testing is to ensure that a planned change in software or hardware did not introduce new faults or defects into the production environment. A common method of regression testing includes repeating previously successful tests and checking to see if program behavior has changed or previously fixed bugs have reemerged after a system change.

Chapter 7 · Testing and Evaluation · Lesson 4 of 6

Test Controls

Big picture

This section covers the controls that protect data and system management while testing runs across environments. It follows execution because controls are the fourth methodology step and exist to keep testing from becoming its own source of risk. The larger problem it solves is concurrency: multiple versions and multiple people working at once produce lost work and untraceable defects without control. Version control and change control are the pair to separate, since one tracks what the artifact is and the other governs whether a change happens at all.

Walkthrough

What controls protect

System controls protect the confidentiality, integrity and availability of data and the overall management of a system across environments during design, development, testing and deployment.
The most common types of test controls are version controls, also called revision controls, security audits and change controls.

Question:

State what test controls protect and name the three types.

Version control

Version control tracks and provides control over changes to source code.
Developers and testers also use version control software to maintain documentation and configuration files as well as source code.
It is common for multiple versions of the same software to run at different sites while developers work simultaneously on updates.
Bugs or features are often present only in certain versions, because some problems are fixed while new ones are introduced as the program develops.
For locating and fixing bugs it is vital to be able to retrieve and run different versions to determine which versions contain a problem.

Example

Two developers editing the same file without version control lose one set of changes silently. The control that was missing is the one that would have made the conflict visible.

Question:

What does version control cover beyond source code, and why does retrieving old versions matter?

Security audits and change control

Security audits are manual or automatic systematic, measurable technical assessments of a system or application.
Manual assessments include interviewing staff, performing security vulnerability scans, reviewing application and operating system access controls and analyzing physical access to systems.
Automated assessments include system-generated audit reports and software that monitors and reports changes to files and settings.
Systems requiring security audits include personal computers, servers, network routers and switches.
Change control is a formal process ensuring changes to a product or system are introduced in a controlled and coordinated manner.
It reduces the possibility that unnecessary changes will be made without forethought, introducing faults or undoing changes made by other users.
Typical activities calling for change control are software patches, system configuration changes, installation of new operating systems, upgrades to network routing systems and changes to the electrical power systems supporting the infrastructure.
Change control is also the means by which the number of changes in an environment at any one time is controlled.

Question:

Name the manual and automated components of a security audit.
State the two purposes of change control, including the one about volume of change.

Memory tips

Three controls: version, security audit, change. Confidentiality, integrity and availability are what they protect.
Version control cue: source code plus documentation and configuration files, with retrieval of old versions for bug isolation.
Security audit split: manual is interviews, scans, access control review, physical access; automated is generated reports and file and setting monitors.
Change control does two things: prevents unconsidered changes and limits how many changes happen at once.
Overwritten work between two developers points at missing version control, not change control.

Key concepts

Test controls: the controls protecting data confidentiality, integrity and availability and the overall management of a system across environments
Version control: the tracking of changes to source code, documentation and configuration files, allowing retrieval of specific versions to locate defects
Security audit: a systematic, measurable technical assessment performed manually through interviews, scans, access control review and physical analysis, or automatically through generated reports and change monitoring
Change control: the formal process introducing changes in a controlled and coordinated manner, preventing unnecessary or conflicting changes and limiting the number of simultaneous changes

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: what system controls protect and across which phases · the three common control types · version control scope, concurrency problem and version retrieval · security audit definition with manual and automated components and the systems requiring them · change control definition, purposes, triggering activities and control of simultaneous change volume.

Read the original source

Test Controls

System controls are implemented to protect the confidentiality, integrity and availability of data and the overall management of a system across environments during design, development, testing and deployment. Some of the most common types of test controls include version controls (also called revision controls), security audits and change controls.

Version control (or revision control) tracks and provides control over changes to source code. Software developers and testers sometimes use version control software to maintain documentation and configuration files, as well as source code. As teams design, develop and test software, it is common for multiple versions of the same software to be running in different sites and for the software's developers to be working simultaneously on updates. Often, bugs or features of the software will be present only in certain versions due to the fixing of some problems and the introduction of new ones as the program develops. Therefore, for the purposes of locating and fixing bugs, it is vitally important to be able to retrieve and run different versions of the software to determine in which version(s) a problem occurs.

Security audits are manual or automatic systematic, measurable technical assessments of a system or application. Manual assessments include interviewing staff, performing security vulnerability scans, reviewing application and operating system access controls and analyzing physical access to the systems. Automated assessments include system-generated audit reports and software that monitors and reports changes to files and settings on a system. Systems that require security audits can include personal computers, servers, network routers and switches.

Change control is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be made to a system without forethought, introducing faults, or undoing changes made by other users. Typical activities that would call for change control are patches to software products, system configuration changes, installation of new operating systems, upgrades to network routing systems and changes to the electrical power systems supporting the infrastructure. Change control is also a means by which the number of changes in an environment at any one time is controlled.

Chapter 7 · Testing and Evaluation · Lesson 5 of 6

Reporting Results and the Final Evaluation

Big picture

This section covers the last two methodology steps: reporting as testing proceeds and the final evaluation that closes a test event. It follows controls because reporting is what turns controlled testing into a decision. The larger problem it solves is audience: test data means nothing to a sponsor unless it answers whether the system is ready and what the risk of going live is. Reporting and final evaluation differ in timing and purpose, since one runs throughout and the other concludes.

Walkthrough

Test results reporting

Reporting occurs throughout the testing process, not just at the conclusion of a test event.
Stakeholders and sponsors may expect monthly, weekly or even daily updates on status, activities and schedules.
Reporting can be challenging and should be planned out early in the testing process.
Common challenges include tailoring reports to audiences, clarifying confusion about the intent of testing, explaining how testing is done and understanding which metrics are meaningful and why.
At a minimum, test reports should address the mission of the test, the systems or applications covered, the organizational risk of deploying the system, testing techniques, the test environment, updated testing status and obstacles to testing.

Question:

When does test reporting occur, and what must a report cover at minimum?
Name the common reporting challenges.

The final evaluation

For most testing projects the most important deliverable is the final evaluation report, containing the findings, conclusions and recommendations of the system test.
For successful tests the final evaluation confirms to stakeholders that the system achieved expected results and addresses how those results may affect anticipated outcomes or benefits.
For example, if a test shows implementation will significantly increase third-party insurance collections, the cost of the test is a sound investment and its benefits are clear.
The report should address common stakeholder questions: does the system meet our quality and performance expectations, is the system ready for users, what can we expect when a given number of people use it simultaneously, and what is our potential risk if we go live now.
Final evaluations may reveal the need for specific end-user training before go-live.
Lessons learned from each test event should be leveraged to improve the planning, execution and evaluation of future tests.
Validating that a system meets the terms of a contract and specification is the role of acceptance testing, with acceptance criteria defined in advance.

Example

A vendor reporting delivery complete while a contracted interface is missing is a question for acceptance criteria defined before testing, not a judgment call made at sign-off.

Question:

Name the four stakeholder questions the final evaluation report should answer.
What may a final evaluation reveal, and what should be done with lessons learned?

Memory tips

Reporting cadence: throughout, possibly daily, planned early.
Report minimum seven: mission, systems covered, organizational risk of deployment, techniques, environment, status, obstacles.
Final evaluation contents three: findings, conclusions, recommendations.
Four stakeholder questions: quality and performance, readiness for users, behavior under concurrent load, risk of going live now.
Acceptance criteria are defined before testing, which is what makes a contract dispute resolvable.

Key concepts

Test results reporting: status reporting throughout the testing process, planned early, covering the mission, systems, deployment risk, techniques, environment, status and obstacles
Final evaluation report: the deliverable containing findings, conclusions and recommendations, confirming expected results and their effect on anticipated benefits
Stakeholder questions: whether the system meets quality and performance expectations, whether it is ready for users, what to expect under simultaneous use and what risk going live now carries
Lessons learned: the material from each test event used to improve planning, execution and evaluation of future tests
Contractual validation: acceptance testing against criteria defined in advance, confirming the system meets the contract and specification

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: reporting throughout the process and expected cadences · planning reporting early · the named reporting challenges · minimum report contents · the final evaluation report as the most important deliverable and its contents · confirmation of results and their effect on benefits · the collections example · the four stakeholder questions · training needs revealed by evaluation · use of lessons learned · acceptance criteria and contractual validation.

Read the original source

Test Results Reporting

Test results reporting occurs throughout the testing process—not just at the conclusion of a test event. Stakeholders and sponsors may expect monthly, weekly or even daily updates on current testing status, activities, schedules and more. Test reporting can be challenging and should be planned out early in the testing process. Common challenges include tailoring test reports to your audience(s), clarifying confusion about the intent of testing, explaining how testing is actually done and understanding which testing metrics are meaningful and why. At a minimum, test reports should address the mission of the test, system(s) or application(s) covered, organizational risk of deploying the system, testing techniques, test environment, updated testing status and obstacles to testing.7

Final Evaluation

For most testing projects, the most important deliverable is the final evaluation report, which contains the findings, conclusions and recommendations of the system test. For successful system tests, the final evaluation should confirm to stakeholders that the system has achieved expected results and should specifically address how those test results may affect the anticipated outcomes or benefits. For example, if the results of a system test show that implementation of the system will likely significantly increase the organization's third-party insurance collections, the cost of conducting the test would be considered a sound investment and the benefits of the test would be clear. In addition, the final evaluation report should address the most common stakeholder questions at the conclusion of a test event, including (but not limited to)

Does the system meet our quality and performance expectations?

Is the system ready for users?

What can we expect when x people simultaneously use the system?

What is our potential risk if we go live with the system now?

Final evaluations may reveal the need for specific end-user training prior to the go-live event. Lessons learned from each test event should be leveraged by the team to improve the planning, execution and evaluation of future tests. Beyond the go-live date, evaluation continues to play a critical role in a system's life cycle. Post-implementation evaluations are critical for measuring initial and long-term user satisfaction, system usability, business and patient care impacts and benefits and the system's potential for expansion or integration with other organizational systems.

Chapter 7 · Testing and Evaluation · Lesson 6 of 6

Evaluating Benefits Beyond Go-Live

Big picture

This section extends evaluation past the go-live date into the system's life cycle. It closes the chapter because the question testing opened, whether the system delivers what was expected, is only answered after people use it. The larger problem it solves is that benefits claimed in a business case are assertions until they are measured against use. Benchmarking and post-implementation evaluation work together: one compares the organization against peers, the other measures the organization against its own expectations.

Walkthrough

Post-implementation evaluation

Beyond the go-live date, evaluation continues to play a critical role in a system's life cycle.
Post-implementation evaluations measure initial and long-term user satisfaction.
They measure system usability.
They measure business and patient care impacts and benefits.
They assess the system's potential for expansion or integration with other organizational systems.
Evaluating whether expected benefits were achieved uses metrics drawn from those areas rather than from test pass rates.
Comparing an organization's metric against peer organizations is benchmarking.

Example

A benefits report showing user satisfaction up and return on investment still negative after year one is not a contradiction. Satisfaction arrives with familiarity, while return depends on a cost curve that was front-loaded.

Question:

Name what post-implementation evaluation measures.
Distinguish benchmarking from post-implementation evaluation.
Why does evaluation continue past go-live at all?

Memory tips

Post-implementation measures four: user satisfaction initial and long term, usability, business and patient care impact, expansion and integration potential.
Benchmarking is external comparison; post-implementation evaluation is internal measurement against expectation.
Benefit metrics come from use, not from test results.
Mixed signals are normal early: satisfaction and financial return move on different clocks.

Key concepts

Post-implementation evaluation: the continuing measurement of initial and long-term user satisfaction, system usability, business and patient care impacts and benefits, and potential for expansion or integration
Benefits evaluation: assessment of whether expected benefits were achieved, using outcome and satisfaction metrics rather than test results
Benchmarking: comparison of an organization's metric against peer organizations

Practice questions

6 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the continuing role of evaluation beyond go-live · the measures post-implementation evaluation covers · assessment of expansion and integration potential · use of benefit metrics for evaluating achievement · comparison against peer organizations as benchmarking.

Read the original source

Test Results Reporting

Test results reporting occurs throughout the testing process—not just at the conclusion of a test event. Stakeholders and sponsors may expect monthly, weekly or even daily updates on current testing status, activities, schedules and more. Test reporting can be challenging and should be planned out early in the testing process. Common challenges include tailoring test reports to your audience(s), clarifying confusion about the intent of testing, explaining how testing is actually done and understanding which testing metrics are meaningful and why. At a minimum, test reports should address the mission of the test, system(s) or application(s) covered, organizational risk of deploying the system, testing techniques, test environment, updated testing status and obstacles to testing.7

Final Evaluation

For most testing projects, the most important deliverable is the final evaluation report, which contains the findings, conclusions and recommendations of the system test. For successful system tests, the final evaluation should confirm to stakeholders that the system has achieved expected results and should specifically address how those test results may affect the anticipated outcomes or benefits. For example, if the results of a system test show that implementation of the system will likely significantly increase the organization's third-party insurance collections, the cost of conducting the test would be considered a sound investment and the benefits of the test would be clear. In addition, the final evaluation report should address the most common stakeholder questions at the conclusion of a test event, including (but not limited to)

Does the system meet our quality and performance expectations?

Is the system ready for users?

What can we expect when x people simultaneously use the system?

What is our potential risk if we go live with the system now?

Final evaluations may reveal the need for specific end-user training prior to the go-live event. Lessons learned from each test event should be leveraged by the team to improve the planning, execution and evaluation of future tests. Beyond the go-live date, evaluation continues to play a critical role in a system's life cycle. Post-implementation evaluations are critical for measuring initial and long-term user satisfaction, system usability, business and patient care impacts and benefits and the system's potential for expansion or integration with other organizational systems.

Summary

Chapter 7 · Testing and Evaluation · Supplemental lesson

Test Types, FMEA and Root Cause Analysis

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

This lesson closes two gaps in the testing chapter: the full test type taxonomy and the prospective and retrospective risk analysis pair. Each test type answers a different question, and the two risk methods are mirror images separated by timing. An organization doing only root cause analysis is permanently reactive.

Walkthrough

The test type taxonomy

Unit testing asks whether an individual component works in isolation and is developer-run.
Integration or interface testing asks whether components and systems exchange correctly across their boundaries, which is where most healthcare defects live because most healthcare systems are assemblies.
System testing asks whether the assembled system meets its specified requirements end to end.
Regression testing asks whether a change broke something that previously worked, runs after every change indefinitely and is the most skipped and most regretted type.
User acceptance testing asks whether the intended users, performing real scenarios, agree the system does what they need. It is business-owned rather than IT-owned and is the acceptance gate.
Performance, load and stress testing ask whether the system holds up at expected volume and where it breaks.
Parallel testing runs the new and old systems simultaneously on the same live inputs and compares outputs, at high cost and high assurance, common for financial and results-reporting systems.
User acceptance testing is not a repeat of system testing by different people: it validates fitness for purpose against real workflow rather than conformance to specification.

Question:

Name the test types and the question each answers.
Distinguish UAT from system testing by owner and question.
Describe parallel testing and where it is used.

FMEA and RCA

Failure Mode and Effects Analysis is prospective: before deployment a multidisciplinary team maps the process, identifies every way each step could fail, traces the consequence of each and prioritizes.
Prioritization typically uses a risk priority number combining severity, occurrence and detectability.
FMEA asks what could go wrong and where the prevention budget should be spent.
Root Cause Analysis is retrospective: after an adverse event a team reconstructs what happened and works backward past the proximate cause to systemic contributors, producing corrective actions.
Accreditation requires root cause analysis after a sentinel event.
RCA asks why this happened and what will stop it recurring.
FMEA output should shape the test plan, since the highest-risk failure modes deserve explicit test cases.
RCA output should feed back into the test suite as regression cases and into self-assessment.

Example

A rare, undetectable, catastrophic failure scores high on a risk priority number precisely because nobody will see it coming. High RPN does not mean likely.

Question:

Contrast FMEA and RCA by timing, direction and trigger.
State the three factors in a risk priority number.
How should each method feed the test plan?

Memory tips

Test types by question: unit works alone, integration exchanges, system meets spec, regression checks for damage, UAT validates real need, performance checks volume, parallel compares old and new.
UAT is business-owned and is the acceptance gate.
FMEA is prospective and RCA is retrospective. Cleanest pair in the chapter.
RPN three: severity, occurrence, detectability.
Regression testing never ends; it is a permanent tax on every change.

Key concepts

Test type taxonomy: unit, integration or interface, system, regression, user acceptance, performance and load, and parallel testing
User acceptance testing: business-owned validation of fitness for purpose against real workflow, serving as the acceptance gate
Parallel testing: running new and old systems simultaneously on the same inputs and comparing outputs
FMEA: prospective, multidisciplinary identification of failure modes and effects, prioritized by a risk priority number combining severity, occurrence and detectability
Root cause analysis: retrospective, event-triggered reconstruction working backward past the proximate cause to systemic contributors, required after a sentinel event

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: each test type and the question it answers · where healthcare defects concentrate · regression's permanence · UAT ownership and purpose · parallel testing mechanics and use · FMEA's timing, team, method and risk priority number · RCA's timing, direction and accreditation trigger · how each feeds the test plan and self-assessment.

Read the supplemental lesson source

S7.1 — Test Types, FMEA and Root Cause Analysis

Chapter 7 · Tasks III.D.1–D.4 · About 12 minutes

1. Learn the topic

Where this fits

Chapter 7 is short and its Addendum B sources are shared with Chapter 5. This lesson closes the two specific gaps: the test type taxonomy and the prospective/retrospective risk analysis pair.

What it means: test types

Testing is not one activity. Each type answers a different question, and they run in a rough order.

Unit testing — does this individual component work in isolation? Developer-run.

Integration / interface testing — do components and systems exchange correctly across their boundaries? In healthcare this is where most defects live, because most healthcare systems are assemblies.

System testing — does the assembled system meet its specified requirements end to end?

Regression testing — did this change break something that previously worked? Run after every change, indefinitely. The most-skipped and most-regretted type.

User acceptance testing (UAT) — do the intended users, performing real scenarios, agree the system does what they need? Business-owned, not IT-owned. This is the acceptance gate.

Performance / load / stress testing — does it hold up at expected volume, and where does it break?

Parallel testing — the new system and the old run simultaneously on the same live inputs and outputs are compared. Expensive, high assurance, common for financial and results-reporting systems.

Usability testing — covered in lesson S5.1.

Two things people miss. UAT is not a repeat of system testing by different people — it validates fitness for purpose against real workflow, not conformance to spec. And regression testing never ends; it is a permanent tax on every change.

What it means: the risk-analysis pair

Two named methods, mirror images of each other.

FMEA — Failure Mode and Effects Analysis. Prospective. Before deployment, a multidisciplinary team maps the process, identifies every way each step could fail (failure modes), traces the consequence of each (effects), and prioritizes. Prioritization typically uses a risk priority number combining severity × occurrence × detectability. Effort goes to the highest-scoring modes. FMEA asks: what could go wrong, and where do we spend our prevention budget?

RCA — Root Cause Analysis. Retrospective. After an adverse event, a team reconstructs what happened and works backward past the proximate cause to the systemic contributors, producing corrective actions. Accreditation requires it after a sentinel event (lesson S1.1). RCA asks: why did this happen, and what will stop it recurring?

The pairing is the point. FMEA before, RCA after. An organization doing only RCA is permanently reactive.

How it works together

The requirements traceability matrix (lesson S4.1) links each requirement to the test that verifies it. FMEA output should shape the test plan — the highest-risk failure modes deserve explicit test cases. RCA output should feed back into both the test suite (regression cases for the failure) and the SAFER-style self-assessment (lesson S5.2).

Examples and non-examples

Straightforward. Before go-live on a new infusion integration, the team runs an FMEA and identifies that a pump-to-EHR mismatch in units could deliver a tenfold dose. Severity extreme, detectability poor. That becomes a dedicated test case and an interface validation rule.

Connecting to another concept. Regression testing is the operational expression of the sociotechnical insight that changes propagate. Dimension 1 or 2 changes; something in another dimension breaks.

Non-example. A vendor demonstration is not a test. Nothing is measured, the scenarios are chosen by the seller, and no acceptance criteria are applied. It informs selection, not verification.

Common misconceptions

"UAT is the last round of system testing." Different owner, different question. System testing verifies against specification; UAT validates against real need.

"FMEA and RCA are alternatives." They are complements, separated by timing.

"A high RPN means the failure is likely." RPN combines severity, occurrence and detectability. A rare, undetectable, catastrophic failure scores high precisely because you won't see it coming.

2. Exam focus

What you must know

The test types and the question each answers, especially regression (did I break something) and UAT (does it meet real need, business-owned).

Parallel testing = old and new running simultaneously on the same inputs, outputs compared.

FMEA = prospective, severity × occurrence × detectability, multidisciplinary, done before.

RCA = retrospective, event-triggered, works backward past the proximate cause, required after a sentinel event.

Traceability links requirements to tests.

Distinctions likely to be tested

FMEA vs. RCA — timing and direction. This is the cleanest pair in the chapter and near-certain to appear in some form.

UAT vs. system testing — owner and question.

Verification (built right, against spec) vs. validation (built the right thing, against need).

How this appears in a question

Descriptor-to-term items naming a testing activity, and scenario items where an organization has an event and you must choose the appropriate analysis. If the event already happened, RCA. If you're deciding where to spend prevention effort, FMEA.

3. Teach it back

Explain to a clinical director being asked to staff UAT:

1. Why IT cannot do UAT for them.

2. The difference between FMEA and RCA, using an example from their own unit.

3. Predict what happens over two years to a system where regression testing is dropped to save time.

<summary>Key-point checklist</summary>

[ ] UAT validates fitness for real workflow; only the people who do the work can judge that

[ ] FMEA prospective / RCA retrospective, with the direction of reasoning stated

[ ] Mentioned severity, occurrence and detectability, and that detectability matters independently

[ ] Described accumulating silent breakage from unverified changes

[ ] Kept verification (spec) and validation (need) distinct

</details>

4. Practice

Items SQ-38 to SQ-40.

5. Key takeaway

Each test type answers a different question, and regression testing is the one that never ends. On risk: FMEA looks forward, RCA looks back. An organization with only RCA is permanently reacting to harm it could have modelled.

Chapter 8 · Privacy and Security · Lesson 1 of 7

Requirements, Policies and Procedures for Data Protection

Big picture

This section covers the legal frame every privacy and security program is built on: HIPAA's administrative simplification structure, HITECH's breach notification duty and the GDPR. It opens the Privacy and Security chapter, which the exam treats as its own domain. The larger problem it solves is that requirements come from several jurisdictions at once, and an organization holding data on people outside its own country answers to more than one. Policies and procedures are the pair to hold apart throughout: policies define what an organization will do, procedures define how it will do it.

Walkthrough

Why the stakes changed and what the rules cover

Privacy concerns are not new to the electronic era; patients expected limited access and confidential contents in the paper era too.
What changed with electronic records is the ease with which records can be lost or breached, even from great distances, and the potential scale of these incidents.
Patients have the right to have health information protected regardless of the form the data is in.
The underlying principle is to do no harm to the patient.
Numerous international, national and state laws regulate the privacy and security of electronic health records.
A primary focus is patient-sensitive health information transmitted or maintained in any form or medium, with restrictions on how organizations may use or disclose it.
An organization may adopt policies that further restrict access, for example around research such as genetic markers whose meaning may change as science develops.

Question:

What changed about privacy risk with electronic records?
Give the source's example of why an organization might restrict access beyond legal requirements.

HIPAA privacy and security standards

The Title II Administrative Simplification section of HIPAA, enacted in 1996, established criteria for a covered entity to develop and maintain a program ensuring the confidentiality, integrity and availability of protected health information.
Confidentiality means the information cannot be disclosed to unauthorized persons or processes.
Integrity means data has not been altered or destroyed in an unauthorized manner.
Availability means data is accessible and usable on demand by an authorized person.
The compliance program positions a provider for unannounced inspections by the Office for Civil Rights, which enforces the standards.
Policies define what an organization will do; procedures define how it will do it.
A compliance methodology can run through project initiation and organization, developing and maintaining expertise, enterprise awareness and education, a baseline compliance assessment, a strategy and compliance plan, remediation of gaps, implementation and a plan to maintain compliance with change control and audits.
The privacy standards cover appropriate use and disclosure, consent and authorization, a Notice of Privacy Practices, patient rights to access, amend, restrict and receive an accounting of data flow, workforce training, a patient complaint process and sanction of violators with mitigation.
Business associates are contracted non-provider entities that must use patient information to provide a service, and are bound by a business associate agreement to maintain confidentiality, integrity and availability.
The HITECH Act of 2009 elevated business associates to the same level of accountability as a provider for privacy and security breaches.
The security standards consist of administrative, physical and technical safeguards plus organizational requirements.
A security program includes risk management, workforce security management, PHI access management and controls, awareness and training, a security incident process, contingency plans, facility access controls, workstation use and security, device and media controls, transmission security and business associate agreements.
Security standards are classified as required or addressable.
Required standards must be implemented; addressable standards must be documented as not reasonably and appropriately implementable, along with what can be implemented to meet the intent.
Both programs must be kept current, incorporated into the organizational culture and subject to constant auditing.

Addressable does not mean optional. It means the organization must document why the standard does not fit and what it does instead.

Question:

Define confidentiality, integrity and availability in the source's terms.
Explain the difference between required and addressable security standards.
What is a business associate, and what did HITECH change about their accountability?

Breach notification and the GDPR

HITECH established a breach notification process for healthcare similar to the one used in the financial industry.
A breach is the unauthorized acquisition, access, use or disclosure of unsecured PHI that compromises its security or privacy.
Providers must give timely and appropriate notice to affected individuals after a breach is confirmed.
The breach notification evaluation runs four steps: determine whether the incident involved unsecured information; determine whether there was an impermissible use or disclosure under the Privacy Rule; determine whether the incident falls under an exception to the breach definition; and assess the probability that the impermissible use would cause harm.
All inappropriate uses of PHI are presumed to be a breach unless it can be proven there is a low probability the PHI has been compromised.
Notification must occur without unreasonable delay.
The General Data Protection Regulation is an EU law implemented on May 25, 2018 requiring organizations to safeguard personal data and uphold privacy rights of anyone in EU territory.
Its seven protection and accountability principles are lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; and accountability.
Data subject rights include being informed, access, rectification, erasure, restriction of processing, data portability, objection and rights regarding automated decision making and profiling.
Technical measures expected include two-factor authentication and end-to-end encryption; organizational measures include staff training, a data privacy policy and limiting access to personal data.
Maximum penalty is 20 million euros or 4 percent of global revenue, whichever is higher, with other sanctions including a ban on data processing or public reprimands.
HIPAA covers U.S. covered entities handling PHI; the GDPR covers personally identifiable information of EU citizens.
A U.S. entity using or storing an EU citizen's PII must be GDPR compliant regardless of its location.
Under the GDPR the citizen must be informed of a breach within 72 hours, where HIPAA allows a longer timeframe and a process to evaluate harm.

Example

A U.S. health system enrolling an EU citizen in a registry is inside GDPR scope for that person's data, and its breach clock for them is 72 hours rather than the HIPAA timeline.

Question:

Reconstruct the four steps of the breach notification evaluation.
Name the seven GDPR principles and four of the data subject rights.
Compare HIPAA and GDPR on scope and breach notification timing.

Memory tips

Policy versus procedure: what we will do versus how we will do it.
CIA definitions: confidentiality is disclosure control, integrity is unaltered data, availability is usable on demand by the authorized.
Required versus addressable: implement, or document why not plus what you do instead.
Breach presumption: every inappropriate use is a breach unless low probability of compromise is proven.
GDPR anchors: May 25, 2018; seven principles; 72-hour notification; 20 million euros or 4 percent of global revenue.
HITECH did two things worth remembering: breach notification and business associate accountability.

Key concepts

HIPAA Administrative Simplification: the Title II requirement that covered entities maintain a program ensuring confidentiality, integrity and availability of protected health information, enforced by the Office for Civil Rights
Policies and procedures: policies defining what an organization will do and procedures defining how it will do it
HIPAA privacy standards: rules covering use and disclosure, consent and authorization, the Notice of Privacy Practices, patient rights, workforce training, complaints and sanctions with mitigation
Business associate: a contracted non-provider entity using patient information to provide a service, bound by agreement and, since HITECH, held to provider-level accountability for breaches
Required and addressable standards: standards that must be implemented, versus standards that must be documented as not reasonably implementable along with what is done instead
Breach: the unauthorized acquisition, access, use or disclosure of unsecured PHI compromising its security or privacy, presumed unless low probability of compromise is proven
Breach notification evaluation: the four-step determination of unsecured information, impermissible use, exceptions and probability of harm
GDPR: the EU law implemented May 25, 2018, with seven protection and accountability principles, defined data subject rights, 72-hour breach notification and penalties up to 20 million euros or 4 percent of global revenue

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the shift in scale and ease of breach with electronic records · patient rights regardless of medium and the do-no-harm principle · breadth of privacy law and further organizational restriction · HIPAA Title II and the CIA definitions · OCR enforcement · policy versus procedure · the compliance methodology steps · privacy standard contents · business associates and HITECH accountability · security standard safeguards and program contents · required versus addressable classification · program maintenance and auditing · breach definition, four-step evaluation, presumption and notification timing · GDPR date, principles, rights, technical and organizational measures, penalties, scope comparison with HIPAA and the 72-hour rule.

Read the original source

Introduction

Concerns about privacy and security of health records are not new to this age of electronic health records (EHRs). In the days of paper records, patients had valid concerns about the privacy of their health information. They expected access to those records would be limited and their contents would remain confidential. What has changed in the era of EHRs is the ease with which health records could potentially be lost or breached, even from great distances, and the potential scale of these incidents.

Patients have the right to have their health information protected regardless of the form the data is in. Providers are expected to safeguard the patient's health information in order to maintain the patient's privacy rights. The content of a patient's health record is a very valuable asset to the patient and to the provider giving care to the patient. The underlying principle is to do no harm to the patient. Having this health information in a complete and definitive format at the time care is rendered helps the provider make a more informed decision for the patient's plan of care. This formatted health information empowers the patient to be an active member of the care team by having their data readily available to them in many electronic formats and online.

Defining Requirements, Policies and Procedures

Today, numerous laws and regulations exist on international, national and state levels regulating the privacy and security of EHRs. As the use of technologies such as EHRs, personal health records (PHRs), health information exchanges (HIEs) and e-prescribing expands the need for organizations to implement and maintain strong security will continue to be of high importance.

A primary area of focus for many laws and regulations is patient-sensitive health information that is transmitted or maintained in any form or medium. Those rules may impose restrictions on how organizations (including governments in some cases) may use or disclose health information.

In some cases, an individual organization may elect to put in place policies that further restrict access for a variety of reasons, especially when dealing with research that is on the front lines of medical science. For example, the presence in an individual's DNA of a certain genetic marker may not indicate anything today, but as science develops, that same marker could predict a condition that might have negative consequences for the patient.

Health information has been digitized for many decades; however, the Title II Administrative Simplification section of the Health Insurance Portability and Accountability Act (HIPAA) of 1996 established criteria and requirements for a covered entity in the United States to develop and maintain a program to ensure the confidentiality, integrity and availability of this protected health information (PHI). The confidentiality of the data refers to the properties of the information, which render it unavailable such that it cannot be disclosed to unauthorized persons or processes. Integrity is the property that data or information has not been altered or destroyed in an unauthorized manner. Availability means the data is accessible and usable on demand by an authorized person.

This comprehensive HIPAA Administrative Simplification Compliance Program is designed to provide the appropriate policies and procedures to achieve and maintain compliance through internal and external certifications. The Compliance Program is to be in accordance to the published HIPAA Privacy and Security standards that will position a provider for unannounced inspections by the Office of Civil Rights (OCR), the government entity that will be enforcing compliance of these standards. HIPAA policies and procedures are to address each of the privacy standards and the security standards. Policies define what an organization will do. Procedures define how they will do it. A methodology to achieve and maintain HIPAA compliance can be: project initiation and organization; develop and maintain expertise; provide enterprise awareness and education; establish a baseline assessment of compliance; develop a strategy and compliance plan; remediate gaps in the baseline assessment; implement the program; and have a plan to maintain compliance, effect change control and complete compliance audits.

The HIPAA privacy standards consist of rules for appropriate use and disclosure of patient information; the consent and authorization of these uses; a Notice of Privacy Practices that details how the provider will maintain the privacy of the patient's information; the patient's rights to access, amend, restrict and have an accounting of the flow of their data; training of the provider's workforce members; a patient complaint process; and a process to sanction violators of the policies and procedures plus mitigation so the violation does not happen again. The privacy standards also address any entity the provider contracts with, who is not a provider, but must use the provider's patient information to provide a service. These entities are called business associates and are expected to maintain the confidentiality, integrity and availability of the patient's data in a private and secure manner. This expectation is defined in a business associate agreement with the provider. The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 elevated business associates to a level whereby they are held to the same level of accountability as a provider for breaches of privacy and security.

The HIPAA security standards consist of administrative safeguards, physical safeguards and technical safeguards along with organizational requirements. Providers are to have a security program that includes a risk management process, workforce security management, PHI access management and controls, awareness and training, security incident process, contingency plans to protect and ensure uninterrupted access to PHI, facility access controls, workstation use and security, device and media controls, transmission security and business associates agreements. The security standards are classified as either required or addressable. Required standards are to be implemented. Addressable standards are to be documented such that they cannot be reasonably and appropriately implemented and include what can be implemented to meet the intent of the standard. Providers are advised to do an assessment of each standard and document compliance with implementation.

Paramount to having these two programs is to keep them up-to-date, incorporate them into the organizational culture and to do constant surveillance (auditing) to ensure compliance so that the patient has the comfort level that their PHI is secure, handled with integrity and no breaches have occurred.

The HITECH Act established for the healthcare industry a breach notification process similar to the one used in the financial industry. A breach of this type is the unauthorized acquisition, access, use or disclosure of unsecured PHI that compromises the security or privacy of the PHI. Providers are to provide timely and appropriate notice to affected individuals after a breach has been confirmed and it is believed the PHI has been accessed, acquired or disclosed as a result of such breach. To confirm a breach, a breach notification evaluation can be used. Step one of the evaluation is to determine if the incident involved unsecured information. If there was unsecured information, step two is to determine if there has been an impermissible use or disclosure of PHI under the Privacy Rule. Step three is to determine if the incident falls under one of the exceptions of the breach definition. Step four is to assess the probability that the impermissible use of the PHI would cause harm to the patient. All inappropriate uses of PHI are to be presumed to be a breach unless it can be proven that there is a low probability that the PHI has been compromised. Providers are required to notify the patient of the discovery of a breach without unreasonable delay. For breaches that affect less than 500 individuals, providers are required to enter the breach in an online database with the Centers for Medicare & Medicaid Services (CMS). Providers are required to immediately notify the local media and the Secretary of HHS of any breaches affecting 500 or more individuals.

A prominent international law that includes medical information is the General Data Protection Regulation (GDPR). The GDPR.eu website1 provides an overview of this regulation. It states that the GDRP is a European Union (EU) law that was implemented on May 25, 2018, and requires organizations to safeguard personal data and uphold the privacy rights of anyone in the EU territory. This regulation includes seven protection and accountability principles of data protection that must be implemented. These principles are:

Lawfulness, fairness and transparency

Purpose limitation

Data minimization

Accuracy

Storage limitation

Integrity and confidentiality

Accountability

This regulation also includes eight privacy rights of the EU people. These rights are:

The right to be informed

The right of access

The right to rectification

The right to erasure

The right to restrict processing

the right to data portability

The right to object

Rights in relation to automated decision making and profiling

Some key GDPR legal terms to be familiar with are:

Personal data, which is any information about an individual who can be directly or indirectly identified. Personal data can include religious beliefs, web cookies and political opinions.

Data subject, which is the person whose data is being processed.

Data controller, who is the person who decides why and how personal data will be processed. This can be a business owner or an employee of the business. Data controllers have to be able to demonstrate they are GDPR compliant.

Data processor, a third party that processes personal data on behalf of the data controller. The data processor cannot legally process personal data unless they meet one of the following criteria:

The data subject has given consent to the processing of his or her personal data for one or more specific purposes

It is necessary to execute or prepare to enter into a contract

To comply with a legal obligation

To save someone's life

To perform a task in the public interest

There is a legitimate interest to process someone's personal data

Organizations who must be GDPR compliant are to implement appropriate technical measures such as two-factor authentication and end-to-end encryption to handle data securely. Organizations are also expected to implement organizational measures such as staff training, developing a data privacy policy and limiting access to personal data.

The fines for not being GDPR compliant are a maximum penalty of €20 million or 4% of global revenue, whichever is higher. Other sanctions can include a ban on data processing or public reprimands.

HIPAA covers US-based healthcare organizations (covered entities) that handle PHI. The GDPR covers the personally identifiable information (PII) of a EU citizen. This mean if a US-based healthcare covered entity uses or stores the PII of a EU citizen this US-based entity must be GDPR compliant regardless of the location of the US-based entity. If there is a breach of this EU citizen's PII, then according to GDPR, the citizen must be informed within 72 hours, where HIPAA has a longer timeframe of notice and a process to evaluate if harm has been done to the patient.

GDPR.eu is co-funded by the Horizon 2020 Framework Programme of the European Union and operated by Proton Technologies AG.

Chapter 8 · Privacy and Security · Lesson 2 of 7

Risk Assessment, Risk Management and Vulnerability Remediation

Big picture

This section covers how an organization finds out where it stands and what it does about the gaps. It follows the requirements because risk is measured against what the rules demand. The larger problem it solves is prioritization: no organization can close every weakness at once, so risk has to be scored before it is treated. Threat and vulnerability are the pair the exam leans on, since one is the potential event and the other is the flaw that lets it succeed.

Walkthrough

Assessing readiness

Once an organization understands applicable privacy and security requirements, it should assess its readiness against each of them.
The assessment focuses on identifying gaps between what is required and what actually exists in operations.
Tools include review of current policies, procedures, contracts and other relevant documents.
Organizational surveys or questionnaires measuring knowledge of and compliance with requirements.
Facility walk-throughs identifying areas where physical security limitations need to be addressed.
Technical penetration or intrusion attempts and other tests assessing security vulnerabilities.
Updated legislation, regulations or international agreements that may drive new approaches.
Root cause analysis of any security breach that occurred since the last assessment.

Question:

Name the assessment tools the source lists.
What is the assessment actually looking for?

Risk, threats and vulnerabilities

Risk is the likelihood of a given incident occurring together with the adverse impact of such an incident.
Threats are potential scenarios that would have a negative impact on security or privacy.
Threat sources are persons or events with the ability to actualize a threat.
Examples of threat sources include humans such as malicious hackers and employee saboteurs, natural disasters such as floods and earthquakes, and environmental events such as power grid failure or a nuclear or chemical accident.
Vulnerabilities are flaws or weaknesses that allow exploits or events to result in a security breach or other violation of security policy.
A risk management process identifies threats and vulnerabilities, assesses risk and executes steps to reduce risk to an acceptable level.
Risk is factored by assigning a numeric value to the probability a threat will exploit a vulnerability and a criticality value for how bad the result would be.
These values are commonly set to high, medium and low on a scale to produce a risk factor.
A risk-mitigation process states what will be done to reduce the risk, implements controls and documents the residual risk.

A threat without a matching vulnerability does not produce risk, and a vulnerability nobody can reach does not either. Scoring depends on the pair, not on either alone.

Question:

Define risk, threat, threat source and vulnerability, and give an example of each threat source category.
Describe how a risk factor is produced and what a mitigation process documents at the end.

Remediation

Risk assessment analysis identifies the most significant vulnerabilities an organization faces.
Audit reports, reports of atypical system behavior, vendor advisories and system security analysis also identify vulnerabilities.
Remediation reviews existing policies and procedures, develops new ones, delivers education and training and puts controls in place to safeguard critical systems and data.
Controls include physical, administrative and technical safeguards.
The organization can take one of two approaches to reduce risk to an acceptable level: no action, where the current risk level is deemed acceptable, or mitigate, implementing safeguards along with supporting policies and procedures.

Question:

Name the sources beyond risk assessment that identify vulnerabilities.
State the two approaches to reducing risk to an acceptable level.

Memory tips

Risk equals likelihood times impact, scored high, medium, low.
Threat is the scenario, threat source is who or what actualizes it, vulnerability is the flaw that lets it land.
Threat source categories three: human, natural, environmental.
Assessment tools six: document review, surveys, walk-throughs, penetration testing, regulatory updates, breach root cause analysis.
Two approaches: no action when risk is acceptable, or mitigate with safeguards and supporting policy. Residual risk gets documented either way.

Key concepts

Risk assessment: the readiness evaluation identifying gaps between what is required and what exists, using document review, surveys, walk-throughs, technical testing, regulatory updates and breach root cause analysis
Risk: the likelihood of an incident occurring together with its adverse impact
Threat and threat source: the potential negative scenario, and the person or event able to actualize it, whether human, natural or environmental
Vulnerability: a flaw or weakness allowing an exploit or event to result in a breach or policy violation
Risk management process: identifying threats and vulnerabilities, assessing risk by probability and criticality, and reducing risk to an acceptable level
Remediation: reviewing and developing policies and procedures, delivering training and implementing physical, administrative and technical controls
Risk responses: no action where risk is acceptable, or mitigation with safeguards and supporting policies, documenting residual risk

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the purpose of the readiness assessment and its gap focus · each named assessment tool · the definition of risk as likelihood and impact · threats, threat sources and their three categories with examples · vulnerability definition · the risk management process and numeric factoring · high, medium and low scaling · the mitigation process and residual risk · vulnerability identification sources · remediation activities and control types · the no-action and mitigate options.

Read the original source

Risk Assessment

Once an organization has developed an awareness and understanding of applicable privacy and security laws and requirements, it should undertake an assessment of the organization's readiness with regard to each of those elements. This assessment should focus on identifying gaps between what is required and what actually exists within the organization's operations. A number of tools may be used in such an assessment.2,3 Some examples include:

Review of current policies, procedures, contracts and other documents relevant to privacy and security

Organizational surveys or questionnaires that measure knowledge of, and compliance with, applicable privacy and security requirements

Facility walk-throughs to identify areas where physical security limitations need to be addressed

Technical penetration or intrusion attempts or other tests to assess security vulnerabilities

Updated legislation, regulations or international agreements that may drive new approaches

Root cause analysis of any security breach that may have occurred since the last assessment

This information should serve to give the organization a realistic assessment of its risk. We can think of risk as the likelihood of a given incident occurring, as well as the adverse impact of such an incident. We often think of such risks in terms of threats—potential scenarios that would have a negative impact on security or privacy—and threat sources—persons or events with the ability to actualize a threat. Examples of threat sources include humans (e.g., malicious hackers and employee saboteurs), natural disasters (e.g., foods and earthquakes) and environmental events (e.g., power grid failure and a nuclear or chemical accident). Threats and threat sources are dangerous to any organization that has not made itself entirely immune to them. We use the term vulnerabilities to describe flaws or weaknesses that allow exploits or events to result in a security breach or other violation of an organization's security policies.

Risk Management Process

A risk management process includes identifying threats and vulnerabilities, assessing risk and then executing steps to reduce the risk to an acceptable level. A threat is the potential for a thing to go wrong which triggers or exploits a specific vulnerability. A vulnerability is a flaw or a weakness in system components that can result in a breach or violation. Risk is factored by setting a numeric value to the probability a threat will exploit vulnerability and how bad (criticality numeric value) will the result be. These values are commonly set to HIGH, MEDIUM and LOW on a scale to come to a risk factor. A risk-mitigation process can be used to reduce the risk factor. The process can include what is to be done to reduce the risk, implement controls to reduce the risk and then document the residual risk.

Vulnerability Remediation

The analysis resulting from a risk assessment should go a long way toward identifying the most significant vulnerabilities an organization faces. Additionally, audit reports, reports of atypical system behaviors, vendor advisories and a system security analysis can be used to identify system vulnerabilities. Once those issues have been identified, the organization should embark on a remediation process to eliminate or mitigate the related risks. During the process of remediation, existing policies and procedures will be reviewed, new policies and procedures will be developed, education and training will take place and controls will be put into place to safeguard critical systems and data. The controls include physical safeguards, administrative safeguards and technical safeguards, which will be discussed below. With these tools at its disposal, an organization can decide to take one of two approaches to reduce risk to an acceptable level:

No action. The current risk level is deemed acceptable by the organization.

Mitigate. Implement safeguards to reduce risk to an acceptable level, along with policies and procedures in support of those safeguards.

Chapter 8 · Privacy and Security · Lesson 3 of 7

User Access Controls

Big picture

This section covers how an organization decides who gets in, what they can reach and how their activity is reviewed. It follows risk work because access is where most privacy risk actually lives. The larger problem it solves is that a system open enough to be useful is open enough to be misused, so the controls have to discriminate by role rather than by permission on or off. Authentication and access are the first two of the triple-A set, and accounting is the one most often left out of answers.

Walkthrough

The triple-A approach

To maintain confidentiality, integrity and availability, an organization must control access to systems and data.
User access controls prevent access by unauthorized users.
They break into three categories, sometimes termed the AAA or triple-A approach: authentication, access and accounting.
Authentication is the process of attempting to prove users are who they say they are before allowing them to access a system.
Three primary authentication methods exist: something a user knows, such as a PIN or password; something a user has, such as a smart card or token; and something a user is, such as a fingerprint, palm print or retina scan.

Question:

Name the three categories of user access control and define authentication.
Give the three authentication factor types with the source's examples.

Access privileges and credentials

Once a user is authenticated, an appropriate level of access must be set.
Access privileges are ideally set to allow the minimum access necessary to perform a job.
Role-based access is often defined by a user's role within the organization.
Physicians generally can place orders and create and sign documents a nurse may not access, while midlevel providers, medical students and pharmacists each hold different subsets or sets of rights.
All authorized users of PHI must access systems with a unique user identifier belonging to one person, which lets the system track what data was accessed, modified or deleted.
Strong password characteristics may include upper and lower case, numerical and special characters, a minimum length, not matching the user identifier, periodic change and no reuse.
User identifiers and passwords should not be written down, stored online, or sent in unsecured e-mail or text, and the password should not travel in the same correspondence as the identifier.
Passwords should not be stored on servers or other devices in clear text.
Security criteria set within system policies ensure the rules for identifiers and passwords are followed and not circumvented.
Passwords alone were once effective, but programs that crack passwords necessitate additional evidence from the user.
That additional evidence is two-factor or multi-factor authentication, known as strong authentication.
It can be a randomly generated code sent to a mobile device, a PIN, a smartcard, a digital certificate or a biometric.
The goal is to identify and validate that the user entering credentials is the one authorized to use the system.

Example

A shared login on a unit workstation defeats accounting entirely. The audit trail can say the account opened a record; it cannot say which person did.

Question:

Explain minimum necessary access and role-based access using the source's clinical examples.
Why must each user have a unique identifier?
What is strong authentication, and what forms can the second factor take?

Accounting

Accounting is the final piece of the user access puzzle.
Audit reports and other controls provide assurance that users are not accessing information not required for care delivery.
Such access may be forbidden by privacy laws, for example looking up coworkers, neighbors or celebrities.
Audit reports should be generated on both a scheduled and a random basis to ensure ongoing compliance.

Question:

What does accounting provide assurance about, and on what schedule should audit reports run?

Memory tips

Triple A: Authentication, Access, Accounting. Who are you, what may you reach, what did you do.
Three factors: know, have, are. Two or more of them is strong authentication.
Access rule: minimum necessary, assigned by role.
Unique identifier is what makes the audit trail attributable to a person.
Audit cadence: scheduled and random, both.

Key concepts

User access controls: the controls preventing access by unauthorized users, categorized as authentication, access and accounting
Authentication: proving users are who they say they are, using something they know, something they have or something they are
Minimum necessary access: access privileges set to the least needed to perform a job
Role-based access: privileges defined by the user's role, such as physicians, midlevel providers, students and pharmacists holding different rights
Unique user identifier: the single-person credential that lets the system track what data was accessed, modified or deleted
Strong authentication: two-factor or multi-factor authentication adding a code, PIN, smartcard, digital certificate or biometric to the password
Accounting: the audit reports and controls, run on scheduled and random bases, providing assurance that users access only information required for care delivery

Practice questions

14 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the purpose of access control and the triple-A categories · authentication definition and the three factor types with examples · minimum necessary and role-based access with clinical examples · unique user identifiers and traceability · strong password characteristics and handling rules · clear text prohibition · system-enforced security criteria · rationale for multi-factor authentication and its forms · accounting, forbidden access examples and audit report scheduling.

Read the original source

User Access Controls

To maintain data confidentiality, integrity and availability, an organization must control access to systems and data. User access controls prevent access by unauthorized users. User access controls can be broken down into the following categories, sometimes termed the AAA or the triple-A approach:4

Authentication

Access

Accounting

Authentication is the process of attempting to prove that users are who they say they are before allowing them to access a system. Three primary methods exist to authenticate users:

Something a user knows (e.g., personal identification number (PIN) or password)

Something a user has (e.g., smart card or token)

Something a user is (e.g., fingerprint, palm print or retina scan)

Once a user has been authorized or authenticated, an appropriate level of access must be set. Access privileges are ideally set to allow the minimum access necessary in order to perform a job. Role-based access is often defined by a user's role within the organization. For example, physicians generally have the ability to place orders and to create and sign documents to which a nurse may not have access. A midlevel provider and medical student may each have subsets of the rights granted to a physician, while a pharmacist may have yet another set of privileges in the system.

All authorized users of PHI are to access information systems with a unique user-id. This unique user-id belongs to one person and allows the system to track this user as they do their work to see what data was accessed, modified or deleted. Along with a user-id is the password. Think of the user-id as the key that goes into a door lock. The password allows the key to be turned to open the door. Passwords should have strong characteristics so they are not easily guessed by an unauthorized user or password tracker algorithms. Some of these characteristics of a strong password may include upper and lower case characters, numerical characters, special characters, minimum length, that it cannot match the user-id, is changed periodically and is not reused. User-ids and password should not be written down, stored online, sent to someone in an unsecured e-mail or text and the password should not be sent in the same correspondence as the user-id. Passwords should not be stored on servers or other devices in clear text form. Security criteria set within electronic policies within systems can ensure the rules for user-ids and passwords are followed and not circumvented.

At one time having a password was the effective way to activate a user-id and was very secure; however, advancement of technology and the ease of a program that can be written to crack a password necessitate the need for additional evidence to be entered by the user to further validate who they are. This additional evidence is referred to as two-factor or multi-factor authentication and is known as strong authentication. This additional evidence can be a randomly generated code sent to a mobile device, a PIN, a smartcard, a digital certificate, or a biometric. The goal is to identify and validate the user entering the authentication credentials is the one authorized to use the system. Accounting is the final piece of the user access puzzle. Audit reports and other controls will provide assurance that users are not overstepping their bounds by accessing information that is not required for care delivery and may be forbidden by many privacy laws (e.g., looking up coworkers, neighbors, or celebrities in the system). Audit reports should be generated on both a scheduled and a random basis to ensure ongoing compliance.

Chapter 8 · Privacy and Security · Lesson 4 of 7

Confidentiality, Integrity, Availability and the Three Safeguards

Big picture

This section defines the three security objectives and sorts the controls that serve them into administrative, technical and physical safeguards. It sits at the center of the chapter because every control elsewhere belongs in one of these three groups. The larger problem it solves is classification, since knowing which safeguard family a control belongs to is how a program is checked for gaps. Administrative and technical safeguards are the pair most often confused, and the deciding question is whether the control is an action and policy or an electronic mechanism.

Walkthrough

The three objectives

A primary focus of healthcare IT security is confidentiality, which limits disclosure of a patient's personal information to comply with policies and regulations and maintain patient trust.
Integrity refers to the accuracy and completeness of data.
Preserving integrity requires policies and procedures protecting data from unauthorized modification, deletion or destruction and keeping it consistent with its source.
The organization must also provide auditing mechanisms ensuring data has not been altered, deleted or destroyed in an unauthorized manner.
Availability calls for information to be protected from unplanned destruction, whether by accident, vandalism or natural disaster.
Availability also makes certain health information is available to patients when they need it.
Care must be taken to ensure records survive the organization in the event of closure, merger or similar events.

Question:

Define confidentiality, integrity and availability as this chapter states them.
What does availability require beyond protection from destruction?

What safeguards are for

Safeguards seek to control electronic access to systems containing sensitive patient or private data.
They control physical access to locations or devices with ready access to secure data.
They manage data in transit, including e-mail and file transfer.
They encrypt data on laptops, flash memory drives or other devices that might easily be lost or stolen.
Safeguards fall into three groupings: administrative, technical and physical.

Question:

Name the four goals safeguards pursue.

The three safeguard families

Administrative safeguards are administrative actions, policies and procedures deployed in support of security aims.
They include ongoing employee education on security requirements and on scenarios where data may or may not be used or disclosed, and development of the policies and procedures that create safeguards in the physical and technical realms.
Technical safeguards are electronic means of ensuring data is not accessible, or is encrypted so as to be useless to a third party.
Examples include network firewalls, secure protocols on public networks carrying patient data and encryption of storage media on laptops and mobile devices.
Physical safeguards are physical measures, policies and procedures protecting electronic information systems from natural and environmental hazards and from unauthorized intrusion.
Examples include data centers located outside a floodplain with redundant power, and limited access to server rooms or areas where data may be accessed or damaged.
One of the major threats security professionals face is cybersecurity, meaning unauthorized access and malicious attack of healthcare systems and data, and more recently ransomware, which holds patient health information hostage for payment.

Example

Training staff on when data may be disclosed is administrative. Encrypting the laptop that holds the data is technical. Locking the room the laptop sits in is physical. The same risk, three different families of control.

Question:

Sort a set of controls into administrative, technical and physical using the source's examples.
Define ransomware in the source's terms.

Memory tips

CIA in this chapter: confidentiality limits disclosure, integrity means accurate and complete data, availability means protected from destruction and there when needed.
Three safeguard families: Administrative is actions and policies, Technical is electronic means, Physical is the building and the hardware.
Training is administrative even though it is about technical topics. Ask what the control is, not what it is about.
Availability has a long tail: records must survive closure or merger.
Ransomware cue: holding patient information hostage for payment.

Key concepts

Confidentiality: limiting disclosure of a patient's personal information to comply with policy and regulation and maintain patient trust
Integrity: the accuracy and completeness of data, protected from unauthorized modification, deletion or destruction and verified by auditing mechanisms
Availability: protection of information from unplanned destruction and its accessibility to patients when needed, including survival through closure or merger
Administrative safeguards: administrative actions, policies and procedures including employee education and the policies that create physical and technical safeguards
Technical safeguards: electronic means such as firewalls, secure protocols on public networks and encryption of storage media
Physical safeguards: physical measures such as data center siting, redundant power and limited access to server rooms
Ransomware: a cybersecurity threat holding patient health information hostage for payment

Practice questions

10 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the confidentiality focus and its purpose · integrity's definition, protective requirements and auditing mechanisms · availability's two demands and survival through organizational change · the four safeguard goals covering electronic access, physical access, data in transit and encryption of portable media · the three safeguard groupings with definitions and examples · cybersecurity and ransomware as named threats.

Read the original source

Confidentiality, Integrity and Availability

A primary focus of healthcare information technology (IT) security is the area of confidentiality. Confidentiality is the process of limiting disclosure of a patient's personal information to comply with policies and regulations, and to maintain the trust that patients have placed in healthcare organizations.5 Two other areas that concern healthcare security professionals are integrity and availability of data. Integrity refers to the accuracy and completeness of data. To preserve the integrity of its health information, an organization must successfully implement policies and procedures to protect the data from unauthorized modification, deletion or destruction and to keep it consistent with its source. Additionally, the organization must provide auditing mechanisms to ensure data has not been altered, deleted or destroyed in an unauthorized manner. Availability calls for information to be protected from any unplanned destruction, whether by accident, vandalism, natural disasters and so on. Availability also makes certain health information is available to patients when they need it. Care must be taken to ensure that records will be available and survive the organization in the event of closure, merger or similar events. This could also apply to other countries and their internal and external ties through treaties and the like.

Data Management Controls

To ensure the security of protected data, a number of safeguards may be deployed. These safeguards seek to meet certain goals, including controlling electronic access to systems containing sensitive patient information or other private data; controlling physical access to locations or devices that may have ready access to secure data; managing data in transit, including e-mail and file transfer; and encryption of data on laptop computers, flash memory drives, or other devices that might be easily lost or stolen.

Safeguards can be categorized into three main groupings: administrative, technical and physical. Administrative safeguards are administrative actions, policies and procedures that an organization deploys in support of its security aims. Administrative safeguards include such actions as the ongoing education of employees on security requirements and scenarios in which data may or may not be used or disclosed, as well as developing policies and procedures that provide safeguards within the physical and technical realms.

Technical safeguards are electronic means of ensuring that data is not accessible, or that it is encrypted in a way that makes it useless to a third party. Examples of technical safeguards would include the use of network firewalls, secure protocols on any public networks carrying patient data and encryption of storage media on laptop computers and mobile devices.

The last type of measure, physical safeguards, consists of physical measures, policies and procedures that protect electronic information systems from natural and environmental hazards, as well as unauthorized intrusion. Examples would include data centers that are located outside a floodplain and have redundant sources of power, and limited access to server rooms or areas where data may be accessed or damaged. One of the major threats security professionals face today is cybersecurity—or the unauthorized access and malicious attack of healthcare information systems and patient health information data and more recently, ransomware—holding that patient health information “hostage” for payment.6

A data classification policy can be designed to support the minimum amount of data needed by a user to do their job. This ensures the information will be protected from unauthorized disclosure, use, modification and deletion. This policy is applicable to data is created, received, stored and/or maintained by the provider. This data is to be consistently protected throughout its life cycle, from origination to its destruction. Data will be protected in a manner commensurate with its sensitivity, regardless of where it resides, what form it takes, what technology was used to handle it and what purpose(s) it serves. Common data classifications are Public, For Internal Use Only, Confidential and Restricted Confidential. A data classification matrix can be developed to document for each classification examples, criteria, handling standards, copying standards, storage standards, destruction standards and workforce classification and access availability.

The volume of data being created, maintained, received, stored and transmitted by healthcare providers is enormous. Data management is necessary to ensure the most useful data is quickly available. Providers are advised to develop a data retention and destruction policy and procedure so non-useful data or data that has reached its end of life can be systematically destroyed. Destruction schedules can be developed to define the data and define the timeframes for destruction based on workflow process needs, regulatory reporting, state regulations, or federal regulations. The data owners (those who generate and maintain the data) can be the party to define the content of the destruction schedules. Review of these schedules should be done on a routine basis to stay abreast of any recent regulatory changes.

Chapter 8 · Privacy and Security · Lesson 5 of 7

Organizational Roles for Privacy and Security

Big picture

This section names who is accountable for the program and what that person does. It follows the safeguards because controls without an owner decay. The larger problem it solves is that privacy and security obligations are continuous while attention is not, so the law requires a named position. Privacy officer and security officer are the pair here: the standards require each, they may be two people or one, and both answer for policy development, maintenance and adherence.

Walkthrough

The named role and its tasks

An expert who understands which privacy laws apply and how to interpret them plays a crucial role in most healthcare organizations.
Laws in many jurisdictions require appointment of an individual, sometimes titled chief information security officer, tasked with these responsibilities.
Assessing and maintaining knowledge of rules and regulations.
Developing policies and procedures.
Cultivating organizational and cultural awareness and developing educational plans in support of policies.
Managing appropriate access for external business partners and ensuring documentation supports that access.
Monitoring compliance with policies.
Responding to complaints and other issues that arise.
Conducting or directing scheduled and random access audits.
Investigating known security breaches and reporting to regulatory or governmental agencies as required by law.

Question:

Reconstruct the task list for this role without looking.
Which tasks are proactive and which are triggered by an event?

Privacy officer, security officer and incident management

The privacy standards require the provider to identify a position responsible for the privacy program.
The security standards carry the same requirement, with that person responsible for ensuring security standards are consistently met.
These individuals are commonly referred to as the privacy officer and the security officer, and can be two distinct people or the same person.
They are responsible for development, maintenance and adherence to all policies and procedures needed for HIPAA compliance.
The security incident management process is an important process these officers can oversee.
All incidents, threats or violations that affect or may affect the confidentiality, integrity or availability of confidential information are to be reported and responded to according to policy and procedure.
The officers oversee these processes and take steps to mitigate so incidents are not repeated.

Example

A single-person office may hold both titles. The requirement is that each program has an accountable owner, not that the organization employ two people.

Question:

State what the privacy and security standards each require about roles, and whether the roles may be combined.
What must be reported under the security incident management process?

Memory tips

Two required owners: privacy program and security program. One person may hold both.
Task list splits into knowledge and policy, awareness and education, partner access, monitoring and audits, complaints and breach investigation with regulatory reporting.
Audit cadence repeats here: scheduled and random.
Incident scope is broad: anything affecting or potentially affecting confidentiality, integrity or availability.

Key concepts

Privacy and security officers: the positions required by the privacy and security standards, possibly held by one person, responsible for developing, maintaining and enforcing the policies and procedures needed for compliance
Chief information security officer: the title sometimes given to the individual jurisdictions require organizations to appoint for privacy and security responsibilities
Role tasks: maintaining regulatory knowledge, developing policies and procedures, building awareness and education, managing business partner access, monitoring compliance, responding to complaints, conducting scheduled and random audits and investigating breaches with required reporting
Security incident management: the process by which incidents, threats or violations affecting confidentiality, integrity or availability are reported, responded to and mitigated against recurrence

Practice questions

7 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the requirement to appoint an accountable individual and the CISO title · each named task · the privacy and security standards' role requirements and their possible combination · responsibility for development, maintenance and adherence · the security incident management process, its reporting scope and its mitigation aim.

Read the original source

Organizational Roles

An expert who understands which privacy laws apply to an organization and how they should be properly interpreted plays a crucial role in most healthcare organizations. Laws in many jurisdictions require that each organization appoint an individual, sometimes with the title of chief information security officer, who is tasked with these responsibilities. Among this individual's tasks will be:

Assessing and maintaining knowledge of rules and regulations

Developing policies and procedures

Cultivating organizational and cultural awareness and developing educational plans in support of policies

Managing appropriate access for external business partners and ensuring documentation exists in support of such access

Monitoring compliance with policies

Responding to complaints and other issues that arise

Conducting or directing others to conduct scheduled and random access audits

Investigating known security breaches and reporting information to appropriate regulatory or governmental agencies as required by law

The privacy standards require the provider to identify a position who will be responsible for the privacy program. The security standards have the same requirement and this person is responsible to ensure the security standards are consistently met. These individuals are commonly referred to as the privacy officer or the security officer. They can be two distinct people or they can be the same person. This person(s) is to be responsible for the development, maintenance and adherence to all policies and procedures needed for the provider to be HIPAA compliant.

An important process the privacy officer and/or security officer can oversee is the security incident management process. All incidents, threats or violations that affect or may affect the confidentiality, integrity, or availability of confidential information are to be reported and responded to in accordance to policy and procedure. The officers can oversee these processes and take steps to mitigate so the incidents will not be repeated in the future.

Chapter 8 · Privacy and Security · Lesson 6 of 7

Data Management Controls and Contingency Planning

Big picture

This section covers classification, retention and the contingency plans that keep data usable after a loss. It follows the organizational roles because these are the policies those roles own. The larger problem it solves is that protection has to scale with sensitivity across the data's whole life, from origination to destruction. The contingency plan elements are a named set of five, and testing and revision is the one most often dropped from answer options.

Walkthrough

Data classification

A data classification policy supports the minimum amount of data needed by a user to do their job.
It ensures information is protected from unauthorized disclosure, use, modification and deletion.
It applies to data created, received, stored or maintained by the provider.
Data is to be consistently protected throughout its life cycle, from origination to destruction.
Protection is commensurate with sensitivity regardless of where data resides, what form it takes, what technology handled it and what purposes it serves.
Common data classifications are Public, For Internal Use Only, Confidential and Restricted Confidential.
A data classification matrix can document, for each classification, examples, criteria, handling standards, copying standards, storage standards, destruction standards and workforce classification and access availability.

Question:

Name the four common data classifications.
What does a data classification matrix document for each level?

Retention and destruction

The volume of data created, maintained, received, stored and transmitted by providers is enormous.
Data management is necessary to ensure the most useful data is quickly available.
Providers are advised to develop a data retention and destruction policy and procedure so non-useful or end-of-life data can be systematically destroyed.
Destruction schedules define the data and the timeframes for destruction based on workflow process needs, regulatory reporting, state regulations or federal regulations.
Data owners, meaning those who generate and maintain the data, can define the content of destruction schedules.
Schedules should be reviewed routinely to stay abreast of recent regulatory changes.

Example

Keeping everything forever looks like caution and behaves like risk. Every extra year of retained data is another year it can be breached, and the destruction schedule is what ends that exposure deliberately.

Question:

What drives the timeframes in a destruction schedule, and who defines its content?

Disaster recovery and business continuity

Healthcare IT security professionals must be involved in developing the organization's disaster recovery and business continuity plans.
Analysis of applications and data criticality: applications and data should be prioritized by importance so a logical sequence of recovery can be planned.
Data backup plan: detailed plans ensuring a retrievable backup copy of critical data exists.
Disaster recovery plan: documented procedures defining how to restore data after any loss, for any reason.
Emergency-mode operation plan: downtime plans enabling the organization to continue operating while access to electronic data is not possible.
Testing and revision: all contingency plans must be routinely tested and revised to fill discovered gaps and address changing organizational needs and infrastructure.

Question:

Name the five contingency plan elements and what each provides.

Memory tips

Four classifications: Public, For Internal Use Only, Confidential, Restricted Confidential.
Classification principle: protection commensurate with sensitivity, regardless of location, form, technology or purpose, across the whole life cycle.
Destruction schedule inputs four: workflow needs, regulatory reporting, state regulation, federal regulation. Data owners define the content.
Five contingency elements: criticality analysis, backup plan, disaster recovery plan, emergency-mode operation plan, testing and revision.
Emergency-mode operation is the one about working without the system, as distinct from restoring it.

Key concepts

Data classification policy: the policy supporting minimum necessary data and protecting information across its life cycle, commensurate with sensitivity regardless of location, form, technology or purpose
Data classifications: Public, For Internal Use Only, Confidential and Restricted Confidential, documented in a matrix of examples, criteria, handling, copying, storage and destruction standards and workforce access
Retention and destruction policy: the policy and destruction schedules allowing systematic destruction of non-useful or end-of-life data, defined by data owners against workflow and regulatory timeframes and reviewed routinely
Contingency plan elements: criticality analysis of applications and data, a data backup plan, a disaster recovery plan, an emergency-mode operation plan, and testing and revision

Practice questions

9 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the purpose and scope of a data classification policy · life cycle protection and sensitivity-commensurate handling · the four common classifications and matrix contents · data volume and availability · retention and destruction policy, schedule drivers, data owner responsibility and routine review · security involvement in continuity planning · the five contingency plan elements including testing and revision.

Read the original source

The last type of measure, physical safeguards, consists of physical measures, policies and procedures that protect electronic information systems from natural and environmental hazards, as well as unauthorized intrusion. Examples would include data centers that are located outside a floodplain and have redundant sources of power, and limited access to server rooms or areas where data may be accessed or damaged. One of the major threats security professionals face today is cybersecurity—or the unauthorized access and malicious attack of healthcare information systems and patient health information data and more recently, ransomware—holding that patient health information “hostage” for payment.6

A data classification policy can be designed to support the minimum amount of data needed by a user to do their job. This ensures the information will be protected from unauthorized disclosure, use, modification and deletion. This policy is applicable to data is created, received, stored and/or maintained by the provider. This data is to be consistently protected throughout its life cycle, from origination to its destruction. Data will be protected in a manner commensurate with its sensitivity, regardless of where it resides, what form it takes, what technology was used to handle it and what purpose(s) it serves. Common data classifications are Public, For Internal Use Only, Confidential and Restricted Confidential. A data classification matrix can be developed to document for each classification examples, criteria, handling standards, copying standards, storage standards, destruction standards and workforce classification and access availability.

The volume of data being created, maintained, received, stored and transmitted by healthcare providers is enormous. Data management is necessary to ensure the most useful data is quickly available. Providers are advised to develop a data retention and destruction policy and procedure so non-useful data or data that has reached its end of life can be systematically destroyed. Destruction schedules can be developed to define the data and define the timeframes for destruction based on workflow process needs, regulatory reporting, state regulations, or federal regulations. The data owners (those who generate and maintain the data) can be the party to define the content of the destruction schedules. Review of these schedules should be done on a routine basis to stay abreast of any recent regulatory changes.

Disaster Recovery and Business Continuity Plans

While everyone has responsibility for protecting patient privacy and ensuring healthcare data security, the healthcare IT security professionals must be involved in the development of an organization's disaster recovery and business continuity plans. Contingency plans in this area should include the following:

Analysis of applications and data criticality. Applications and data should be prioritized in order of importance to the organization so a logical sequence of data recovery can be planned

Data backup plan. Detailed plans must be developed to ensure the existence of a retrievable backup copy of the organization's critical data

Disaster recovery plan. Procedures must be documented that define how to restore data after any loss, for any reason

Emergency-mode operation plan. Downtime plans should be spelled out that will enable the organization to continue to operate in emergency mode while access to electronic data is not possible

Testing and revision. All contingency plans must be routinely tested and revised to fill gaps that are discovered and to address changing organizational needs and infrastructure

Chapter 8 · Privacy and Security · Lesson 7 of 7

Auditing and Ongoing System Evaluation

Big picture

This section closes the chapter with the two activities that keep a program honest over time: auditing access and reevaluating security features as things change. It comes last because both depend on everything earlier being in place. The larger problem it solves is drift, since policies and access rights decay quietly while new applications and interfaces arrive. Internal audit and third-party assessment are complementary here, and the source is specific about what an external annual assessment covers.

Walkthrough

Auditing access

The ability to audit all access to protected data is an essential component of security plans.
No matter how good policies are or how strenuously access is limited, individuals may still access records they do not need for their duties.
Audit reports let an organization identify breaches or other policy violations, from employee snooping to a large criminal attack.
Validating consistent compliance with the HIPAA security standards means a structured security audit program and a risk-assessment process for any changes made to security features of systems in the provider's IT environment.
These audits can be done internally or externally by a third party.
Industry standard is annual external network penetration testing by an objective third party from outside the provider's network, to identify perimeter vulnerabilities that would allow unauthorized access to core network infrastructure or render the network inoperable.
The same testing can include an internal network vulnerability assessment, a wireless network assessment, a medical devices assessment, social engineering and a firewall rules review.
Third-party findings are incorporated into the risk-assessment process to document starting risk, mitigation, controls and residual risk, showing security features are maintained at the highest level of integrity.

Example

An annual external penetration test that never feeds the risk register produces a report and no change. The loop closes only when findings become documented risk, mitigation and residual risk.

Question:

What does the industry standard external assessment cover, and how often?
What happens to third-party findings afterward?

Ongoing system evaluation

Ensuring security is an ongoing and critical process, requiring continuous evaluation of security features of existing and new hardware and software.
Network diagrams including the location and configuration of firewalls, servers and routers must be maintained.
Documentation of software and hardware and vendor contact information must be kept up to date.
As new applications are introduced, technical and user interfaces and other data access points must be evaluated for new security vulnerabilities.
Existing applications must be reevaluated regularly in the face of organizational change and evolving local, national and international attitudes, laws and regulations.
Compliance programs, regular audits, data management controls and safeguards, regular risk assessments with mitigation plans, and documented recovery and continuity plans are all required on a consistent basis rather than periodic check-ins.
Although specific organizational roles are primarily responsible, health information privacy and security is everyone's responsibility.

Question:

Name what must be maintained and kept current for ongoing evaluation.
Why must existing applications be reevaluated even when nothing about them has changed?

Memory tips

Audit purpose: catch access that policy alone did not prevent, from snooping to criminal attack.
External assessment package: annual third-party penetration test from outside, plus internal vulnerability, wireless, medical device, social engineering and firewall rules review.
Loop closure: findings feed the risk assessment as starting risk, mitigation, controls, residual risk.
Ongoing evaluation maintenance: network diagrams, hardware and software documentation, vendor contacts, and review of every new interface and access point.
Closing claim: privacy and security is everyone's responsibility, even with named owners.

Key concepts

Access auditing: the capability to audit all access to protected data, identifying breaches and policy violations that limits alone do not prevent
Structured security audit program: the internal or external audit and risk-assessment process validating compliance with security standards after changes to security features
External penetration testing: the annual objective third-party test from outside the network, optionally including internal vulnerability, wireless, medical device, social engineering and firewall rule assessments
Ongoing system evaluation: continuous evaluation of security features, maintenance of network diagrams and hardware, software and vendor documentation, and reassessment of new and existing applications against organizational and regulatory change

Practice questions

8 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: auditing as an essential component and its purpose · the limits of policy and access restriction · structured audit programs and post-change risk assessment · internal versus third-party audits · the annual external penetration testing standard and its optional components · incorporation of findings into the risk-assessment process · continuous evaluation requirements · documentation maintenance · evaluation of new interfaces and access points · reevaluation of existing applications against change · the chapter's closing claims about consistency and shared responsibility.

Read the original source

Auditing

An essential component of an organization's security plans is the ability to audit all access to protected data. No matter how good an organization's policies and procedures are or how strenuously it works to limit access, individuals may still be able to access records they may not need to access to perform their daily duties. Audit reports enable an organization to identify any breaches or other policy violations, from employee snooping to a large criminal attack.

Validation of consistent compliance with the HIPAA security standards is a structured security audit program and risk-assessment process for any changes made to security features of all systems in the providers’ IT environment. These audits can be done internally or externally by a third party. Industry standard is to have an objective third party conduct annual external network penetration testing from outside the provider's network to identify vulnerabilities in the network perimeter that would allow unauthorized individuals to access the provider's core network infrastructure and render the network inoperable. This same testing can include an internal network vulnerability assessment, a wireless network assessment, medical devices assessment, social engineering and a firewall rules review. The findings from the third-party assessment can then be incorporated into the provider's risk-assessment process to document a starting risk, mitigation, controls and residual risk in order to show security features are being maintained at the highest level of integrity.

Ongoing System Evaluation

Ensuring security is an ongoing and critical process. Crucial to maintaining compliance is a continuous evaluation of the security features of existing and new hardware and software. Network diagrams that include the location and configuration of firewalls, servers and routers must be maintained. Documentation of software and hardware, as well as vendor contact information, must be kept up-to-date. As new applications are introduced, technical and user interfaces and other data access points must be evaluated and care must be taken to assess whether an application or interface might introduce new security vulnerabilities. Additionally, existing applications must be reevaluated on an ongoing and regular basis in the face of organizational changes and evolving local, national and international attitudes, laws and regulations.

Summary

Chapter 8 · Privacy and Security · Supplemental lesson

The HIPAA Rule Structure and the Framework Stack

Supplemental lesson. This material is not in the Review Guide chapter. It closes an Addendum B gap and is drilled by its own bank items.

Big picture

Chapter 8 mentions HIPAA repeatedly without laying out the rule structure it is named for. This lesson supplies that structure, the two de-identification methods and the security framework stack beside it. The distinction most certain to be tested is that addressable does not mean optional.

Walkthrough

The five rules

The Privacy Rule governs uses and disclosures of protected health information in any form, paper, electronic or spoken, establishes that treatment, payment and healthcare operations do not require patient authorization and defines individual rights to access, amendment, accounting of disclosures, restriction requests and confidential communications.
The Security Rule governs electronic PHI only, organized into administrative safeguards including risk analysis, workforce training, sanctions, contingency planning and security officer designation; physical safeguards including facility access, workstation use and security and device and media controls; and technical safeguards including access control, audit controls, integrity, person or entity authentication and transmission security.
The Breach Notification Rule presumes a breach unless a four-factor risk assessment demonstrates low probability of compromise: the nature and extent of the PHI, who used or received it, whether it was actually acquired or viewed and the extent to which risk has been mitigated.
Individuals must be notified without unreasonable delay and no later than 60 days; breaches affecting 500 or more in a state or jurisdiction additionally require prominent media notice and notice to HHS within 60 days, while smaller breaches are logged and reported annually.
The Enforcement Rule sets tiered civil monetary penalties by culpability from unknowing through wilful neglect uncorrected, enforced by the Office for Civil Rights.
The Omnibus Rule of 2013 extended direct liability to business associates and subcontractors, strengthened breach notification and implemented HITECH.
Security Rule implementation specifications are either required or addressable; addressable means assess whether the specification is reasonable and appropriate, implement it if so, and otherwise document why and implement an equivalent alternative where reasonable.

Example

A stolen laptop with unencrypted ePHI is an addressable-specification question. The position turns on whether encryption was assessed, and if declined, whether that was documented with an alternative in place.

Question:

Name the five rules and the scope of each.
State the four factors in the breach risk assessment and the notification thresholds.
Explain what addressable means and what it does not mean.

De-identification and the framework stack

Safe Harbor removes 18 specified identifiers, including names, geographic subdivisions smaller than a state, all date elements more specific than year, contact details, identifying numbers, biometrics and full-face photographs, with no actual knowledge that re-identification is possible.
Expert Determination has a qualified statistician document that re-identification risk is very small.
A limited data set is distinct: it retains some identifiers such as dates and certain geography, may be used for research, public health or operations under a data use agreement, and is not de-identified.
The NIST Cybersecurity Framework 2.0 has six functions: govern, identify, protect, detect, respond and recover, with govern the 2.0 addition.
405(d) and the Health Industry Cybersecurity Practices publish a healthcare-specific set of ten practices in volumes for small and for medium and large organizations.
Recognized security practices, under a 2021 HITECH amendment, may mitigate penalties for an organization demonstrating such practices were in place for the preceding 12 months.
HPH Cybersecurity Performance Goals are HHS's sector goals in essential and enhanced tiers, informed by HICP, NIST CSF and NIST SP 800-53.
Zero trust is an architectural principle rather than a product: never trust by network location, verify every request, enforce least privilege and assume breach.

Question:

Name the two de-identification methods and distinguish both from a limited data set.
Name the six NIST CSF 2.0 functions and which one version 2.0 added.
What does the recognized security practices provision offer, and over what period?

Memory tips

Five rules: Privacy any form, Security electronic only, Breach Notification, Enforcement, Omnibus.
Security safeguards three: administrative is the largest, then physical, then technical.
Breach numbers: four factors, 60 days, 500 threshold for media and HHS notice.
Addressable means assess, implement or document and substitute. Optional is the trap.
De-identification two: Safe Harbor with 18 identifiers, Expert Determination by statistician. A limited data set is neither.
NIST CSF 2.0 six functions with govern added; a five-function answer is version 1.1.

Key concepts

Privacy Rule: governs uses and disclosures of PHI in any form, permits treatment, payment and operations without authorization and defines individual rights
Security Rule: governs electronic PHI through administrative, physical and technical safeguards
Breach Notification Rule: presumes breach unless a four-factor risk assessment shows low probability of compromise, with 60-day notification and a 500-person threshold for media and HHS notice
Enforcement and Omnibus Rules: tiered penalties enforced by the Office for Civil Rights, and the 2013 extension of direct liability to business associates implementing HITECH
Required and addressable specifications: specifications that must be implemented, versus those that must be assessed and either implemented or documented with an equivalent alternative
De-identification methods: Safe Harbor removal of 18 identifiers and Expert Determination by a qualified statistician, distinct from a limited data set used under a data use agreement
NIST Cybersecurity Framework 2.0: the six functions of govern, identify, protect, detect, respond and recover
405(d) HICP and recognized security practices: the healthcare-specific ten practices and the penalty mitigation available when such practices were in place for the preceding 12 months
Zero trust: the architectural principle of verifying every request, enforcing least privilege and assuming breach

Practice questions

13 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the five HIPAA rules and their scopes · TPO and individual rights · the three safeguard categories and their contents · the four-factor breach assessment, 60-day notification and 500-person threshold · tiered enforcement and OCR · the Omnibus Rule's extensions · required versus addressable and the documentation requirement · Safe Harbor's 18 identifiers, Expert Determination and the limited data set distinction · NIST CSF 2.0's six functions · 405(d) HICP volumes and practice count · recognized security practices and the 12-month period · HPH performance goal tiers · zero trust principles.

Read the supplemental lesson source

S8.1 — The HIPAA Rule Structure and the Framework Stack

Chapter 8 · Tasks III.E.1–E.7 · About 15 minutes

1. Learn the topic

Where this fits

Chapter 8 mentions HIPAA fourteen times without laying out the rule structure it is named for. This lesson supplies that structure, the de-identification methods, and the security framework stack sitting alongside it — Rinehart-Thompson's Health Information Privacy and Security is the Addendum B source.

What it means: the rules

HIPAA is not one rule. Five components, each with a different scope:

Privacy Rule. Governs uses and disclosures of protected health information in any form — paper, electronic, spoken. Establishes that treatment, payment and healthcare operations (TPO) do not require patient authorization, and defines individual rights: access, amendment, accounting of disclosures, restriction requests, confidential communications.

Security Rule. Governs electronic PHI only. Organized into three safeguard categories:

Administrative — risk analysis, workforce training, sanctions, contingency planning, security officer designation. The largest category.

Physical — facility access, workstation use and security, device and media controls.

Technical — access control, audit controls, integrity, person or entity authentication, transmission security.

Breach Notification Rule. A breach is presumed unless a four-factor risk assessment demonstrates low probability of compromise: the nature and extent of the PHI, who used or received it, whether it was actually acquired or viewed, and the extent to which risk has been mitigated. Individuals must be notified without unreasonable delay and no later than 60 days. Breaches affecting 500 or more in a state or jurisdiction additionally require prominent media notice and notice to HHS within 60 days; smaller breaches are logged and reported to HHS annually.

Enforcement Rule. Tiered civil monetary penalties by culpability, from unknowing through wilful neglect uncorrected. Enforced by the HHS Office for Civil Rights.

Omnibus Rule (2013). Extended direct liability to business associates and subcontractors, strengthened breach notification, implemented HITECH.

The distinction that will be tested

Security Rule implementation specifications are either required or addressable.

Addressable does not mean optional. It means: assess whether the specification is reasonable and appropriate in your environment. If it is, implement it. If it is not, document why, and implement an equivalent alternative measure if one is reasonable. The documentation is not a formality — it is the compliance artifact.

Expect a distractor that reads "optional" or "at the organization's discretion." That is the trap.

De-identification

Exactly two methods under the Privacy Rule:

Safe Harbor — remove 18 specified identifiers (names, geographic subdivisions smaller than a state, all date elements more specific than year, contact details, identifying numbers, biometrics, full-face photographs, and any other unique identifier), and have no actual knowledge that re-identification is possible.

Expert Determination — a qualified statistician documents that re-identification risk is very small.

A limited data set is a third, distinct thing: it retains some identifiers (dates, certain geography) and may be used for research, public health or operations under a data use agreement. It is not de-identified, and calling it so is a common error.

The framework stack

Regulation says what outcome; frameworks say how.

NIST Cybersecurity Framework 2.0 — six functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern is the 2.0 addition; a five-function answer is version 1.1.

405(d) / HICP — Health Industry Cybersecurity Practices, a healthcare-specific set of 10 practices, published in a volume for small organizations and a volume for medium and large ones. It maps healthcare's actual threats to controls.

Recognized security practices — under a 2021 HITECH amendment, an organization that demonstrates it had recognized security practices (such as HICP or NIST CSF) in place for the preceding 12 months may have penalties mitigated. This is the concrete incentive to adopt a framework.

HPH Cybersecurity Performance Goals — HHS's healthcare-sector goals in essential and enhanced tiers, informed by HICP, NIST CSF and NIST SP 800-53.

Zero trust — an architectural principle, not a product: never trust by network location, verify every request, enforce least privilege, assume breach.

Examples and non-examples

Straightforward. A laptop with unencrypted ePHI is stolen. Encryption is addressable, so the question is whether the organization assessed it, and if it declined, whether it documented why and implemented an alternative. Absent that documentation, the position is very weak.

Connecting to another concept. OCR's enforcement pattern makes the risk analysis the load-bearing requirement — its Risk Analysis Initiative cites the same failure repeatedly: no accurate, thorough, organization-wide analysis. Every safeguard decision is supposed to derive from it. This is the same umbrella-versus-component shape as the rest of the exam: risk analysis is the foundation, the controls are what it enables.

Non-example. A cloud vendor's SOC 2 report is useful assurance. It is not HIPAA compliance, and it does not replace your own risk analysis or the BAA.

Common misconceptions

"Addressable means optional." No. Assess, implement or document-and-substitute.

"HIPAA requires encryption." It is addressable, not required — though the practical expectation is near-universal, and a proposed rule would change this.

"A limited data set is de-identified." It is not.

"The Security Rule covers all PHI." Electronic only. Paper PHI is Privacy Rule territory.

2. Exam focus

What you must know

Five rule components and their scopes; Security Rule = ePHI only.

Three safeguard categories: administrative, physical, technical.

Required vs. addressable, and what addressable actually obliges.

Breach: four-factor risk assessment, 60-day individual notice, 500-person threshold for media and prompt HHS notice.

De-identification: Safe Harbor (18 identifiers) and Expert Determination. Limited data set is separate, requires a DUA.

Risk analysis is the foundational administrative safeguard.

NIST CSF 2.0 = Govern, Identify, Protect, Detect, Respond, Recover.

HICP/405(d) = 10 healthcare-specific practices; recognized security practices = 12-month lookback for penalty mitigation.

Zero trust = principle, not product.

Distinctions likely to be tested

Required vs. addressable — the highest-value trap in the domain.

Privacy Rule (all PHI) vs. Security Rule (ePHI).

De-identified vs. limited data set vs. identifiable.

Covered entity vs. business associate vs. subcontractor — all directly liable post-Omnibus.

Regulation (what) vs. framework (how).

How this appears in a question

Definitional precision items on addressable and on de-identification; scenario items where the correct answer is "conduct or update the risk analysis" and the distractors are specific controls. When a stem asks what to do first, the answer is almost always the assessment, not the control.

Currency note — read once, and note the inversion. The HIPAA Security Rule NPRM published January 2025 would eliminate the addressable/required distinction and mandate MFA, encryption at rest and in transit, asset inventories and network maps, and scheduled scanning and penetration testing. As of August 2026 it remains proposed, not final. Here the current rule is the keyed answer and the proposed rule is the plausible distractor — the reverse of the Joint Commission situation in lesson S1.1. Also live: 42 CFR Part 2 (substance use disorder records) was aligned with HIPAA by a 2024 rule with a February 2026 compliance date, but remains stricter than HIPAA in two respects — it requires consent for TPO sharing, and it bars use of the records against the patient in proceedings absent consent or court order.

3. Teach it back

Explain to a department manager who has just read that encryption is "addressable":

1. What they are actually obliged to do, in three steps.

2. Why the risk analysis, not the control list, is the centre of the Security Rule.

3. Give an original example of a data set that is a limited data set and explain why it isn't de-identified.

<summary>Key-point checklist</summary>

[ ] Assess → implement if reasonable and appropriate → otherwise document why and substitute an equivalent

[ ] Named documentation as the compliance artifact, not a formality

[ ] Risk analysis is the foundation from which safeguard decisions derive

[ ] Limited data set retains identifiers (dates, some geography) and needs a DUA

[ ] Did not say addressable means optional

[ ] Kept Privacy Rule (all PHI) separate from Security Rule (ePHI)

</details>

4. Practice

Items SQ-41 to SQ-44.

5. Key takeaway

Five rules, three safeguard categories, two de-identification methods — and one word that carries more trap weight than any other in the domain: addressable means assess and document, never optional. Underneath all of it, the risk analysis is the foundation every other control depends on.

Chapter 9 · Management and Leadership · Lesson 1 of 18

Strategic Planning and the Organizational Environment

Big picture

This section defines the statements an organization uses to express where it is going and how a department shows its work supports them. It opens the Management and Leadership domain, the largest on the exam. The larger problem it solves is alignment: a department that cannot trace its projects to organizational goals cannot defend its budget or its priorities. Mission and vision are the pair the exam returns to, since both are set by the CEO and board and differ by tense.

Walkthrough

Mission, vision, values and goals

A strategy is a formal or informal plan of action to achieve a goal, focused on where the organization would like to be in the future.
Strategies are expressed through published statements of mission, vision, values and goals.
The mission is a statement of why the organization exists, its purpose, and the best ones are easily understood and remembered.
At the organizational level the CEO and board of directors set the mission, which does not change with any regularity unless the business or industry direction changes.
Each employee is responsible for understanding the mission and tying daily work to it.
The vision defines where the organization wants to go or what it wants to be, a futuristic perspective, also typically set by the CEO and board.
Depending on how far it reaches, the vision may be altered more regularly than the mission.
Values allow individuals to understand what the company supports and appreciates most, and examples in healthcare might include compassion, service and respect.
Employees should use values as guides for behavior and assess whether values align or conflict with work assignments; an initiative lacking alignment should be called into question.
Values also reflect the corporate culture, the set of attitudes, goals and beliefs about working for the organization.
Goals are the measures that support vision accomplishment and must be SMART: specific, measurable, attainable, relevant and time bound.
Example organizational goals include breaking even on Medicare reimbursement, leading in clinical quality and employing primary care providers of choice for the community.

Note the SMART expansion used in this chapter. Relevant appears here where the analytics chapter used realistic, and the exam tests the chapter's own wording.

Question:

Distinguish mission from vision, naming who sets each and how often each changes.
Expand SMART as this chapter states it and say what goals support.
What should an employee do when an initiative conflicts with an organizational value?

Showing departmental alignment

Every department of a large organization benefits from a formalized plan showing how its work aligns with strategic goals and objectives.
Complexity and detail vary by organization and by department size, and even very small departments benefit from a plan with objectives.
In many organizations it is satisfactory to create a table or spreadsheet that crosswalks the organizational vision and goals down through each project or initiative in a department.
Companies often engage leaders in formal governance and leadership committees to promote understanding of potential projects coming in the next 12 to 18 months, with a detailed plan created for that period.
Detailed planning much beyond 18 months, other than routine replacement, may be less valuable given rapid change in the IT industry.
A project crosswalk gives a visual summary of initiatives and can be used internally and at administrative reviews to show linkage between vision, goals and projects.
Projects can be weighted by scoring each against the organization's goals and priorities, producing a score and relative rank that adds objectivity to project priorities.

Example

Two departments each want the same analyst. Scoring both requests against organizational goals turns the argument from who asked louder into which initiative ranks higher.

Question:

What is a project crosswalk, and what does it demonstrate?
State the detailed planning horizon the source advises and the reason for it.

Memory tips

Mission is why we exist, vision is where we are going. Both set by CEO and board; vision changes more often.
SMART in Chapter 9: Specific, Measurable, Attainable, Relevant, Time bound. Relevant, not realistic.
Planning horizon: 12 to 18 months detailed, beyond that only routine replacement.
Crosswalk purpose: link vision and goals down to individual projects, then score and rank for objectivity.

Key concepts

Strategy: a formal or informal plan of action to achieve a goal, focused on a future position
Mission: the statement of why the organization exists, set by the CEO and board and rarely changed
Vision: the statement of where the organization wants to go, also set by the CEO and board and altered more regularly than the mission
Values: the published list of what the organization supports and appreciates, used by employees as behavioral guides and reflecting corporate culture
Goals: the SMART measures supporting vision accomplishment, meaning specific, measurable, attainable, relevant and time bound
Project crosswalk: the table linking organizational vision and goals to each departmental project, with scoring against goals producing rank and objectivity

Practice questions

14 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: definition of strategy · mission definition, authorship and stability · employee responsibility to tie work to mission · vision definition, authorship and change frequency · values, examples, behavioral use and corporate culture · goals as measures and the SMART expansion with examples · departmental plans regardless of size · the crosswalk table and governance committee horizon · the 12 to 18 month planning window · project scoring, ranking and objectivity.

Read the original source

Participation in Organizational Strategic Planning

Leaders are responsible for setting the strategic goals and priorities for the company, division, department and new initiatives. A strategy is a formal or informal plan of action to achieve a goal. Regardless of where an organization is today, its strategies focus on where it would like to be at some point in the future. To outline and explain its strategies, an organization typically will use one or a series of statements that will be published for the benefit of the employees and customers. These statements express the mission, vision, values and goals of the organization.

Mission

The mission is a statement of why the organization exists—its purpose. Mission statements can vary from simple and concise to complex and hard to understand. The best mission statements are those that can be easily understood and remembered by any member of the organization or those that may be customers of your organization. Once read, it is not easily forgotten.

At the organizational level, it is typically the chief executive officer (CEO) and board of directors who set the mission of the company. The mission does not change with any regularity unless the business of the company or direction of the industry is changing as well. Nevertheless, each employee of the company has a responsibility to understand the mission to be sure that as they are evaluating their daily work, they can tie that work to the mission of the company.

Vision

A second expression that a company uses is the vision statement. A vision is the company statement that defines where it wants to go or what it wants to be. The vision is what the company is striving to achieve as it completes the daily work, a futuristic perspective. The CEO and board also typically set the vision. Depending on how far the vision reaches into the future, it may be altered with more regularity than the mission.

Values

The addition of values to corporate ideologies is much more recent than mission and vision. A list of values allows individuals to understand what the company supports and appreciates most. Values are often presented in a list that individuals can compare against their own personal values, as well as the values that are built into the activities they undertake at work. Examples of a healthcare organization's values might include compassion, service and respect. Employees should use the values as guides for their behavior at work and assess whether the values align or conflict with your work assignments. If an initiative lacks alignment or it conflicts with at least one value, it should be called into question. Values also reflect the corporate culture in the organization. Corporate culture is an all-encompassing set of attitudes, goals and beliefs about working for the organization that all employees accept to be true. Healthy corporate culture is usually a set of positive feelings about working for a specific company.

Goals

Goals are the measures to support vision accomplishment. The list of goals must be SMART: specific, measurable, attainable, relevant and time bound. Examples of organizational goals might be breaking even on Medicare reimbursement, leading in clinical quality and employing primary care providers of choice for the community. Clearly articulated goals that support the mission and vision serve as guides against which to measure accomplishments of the organization.

Organizational Environment

Every department of a large organization can benefit from having a formalized plan that demonstrates how the work being performed aligns with the strategic goals and objectives of the organization. The complexity and detail of such a plan will vary by organization, as well as by the size and complexity of a department. For very small information management and systems departments, the question that arises is whether a full-fledged strategic plan is appropriate. A plan with objectives is a good idea regardless of the organization's size.

In many organizations, it will be satisfactory to create a table or spreadsheet that crosswalks the organizational vision and goals down through each of the individual projects or initiatives being worked on within a department or area. Companies often engage leaders in formal governance and leadership committees to promote understanding of the potential projects that may be coming in the next 12–18 months. A detailed plan is then created for that time period. Detailed planning much beyond 18 months out, other than for routine replacement, may be less valuable given the rapid changes in the IT industry.

Maintaining a project crosswalk provides a visual summary of the initiatives being handled by an area of service. This crosswalk can then be used within the department and at administrative review sessions to demonstrate the linkage between vision, goals and projects. Additionally, this same tool can serve as a link to the detailed work plans and project updates that are maintained by staff. In Figure 9.1, you can see how a series of projects are weighted by scoring each against the organization's goals and priorities. The resulting score and relative rank of each project is calculated, can be shared and helps provide objectivity to project priorities.

Chapter 9 · Management and Leadership · Lesson 2 of 18

Forecasting Needs and Developing the IT Strategic Plan

Big picture

This section covers how IT leaders anticipate organizational needs and turn them into a plan. It follows organizational planning because the IT plan is derived from it rather than written alongside it. The larger problem it solves is the direction of authority: operational goals direct IT and not the reverse, which is why the chapter insists there is no such thing as an IT project. Gap analysis and SWOT appear together here as the analytical core of the plan.

Walkthrough

Forecasting and the operations-to-IT relationship

IT leaders aid and direct in support of company goals and initiatives, balancing leadership and support.
Operational goals direct IT and not the reverse, and lack of clarity about that relationship puts projects at risk.
All projects need operational leadership and, as necessary, IT guidance and support.
IT leaders must know organizational goals and be ready to recommend systems and technologies supporting them.
When goal deviation is suspected, the IT leader challenges the request to get the project back on track.
Staying focused on goals helps avoid the service gap that occurs when requested services surpass what internal staff can provide.
New project requests come from varied sources at varied levels of development, and requestors need help defining scope, definition and objective.
Program evaluation staff can sit with requestors to work through a new request, since customers may propose a solution to a problem that has not been well defined.
Requestors need to understand new technology, device integration options, infrastructure limitations, the existing application portfolio and network services.
Leaders serve as the organization's conscience regarding IT requests and service overextension, and activities must be prioritized from an institutional strategic plan.
Leaders must know which personnel resources are available and their readiness for contingency planning when unexpected resource issues occur.
Leaders must facilitate a process in which all leaders define the organization's measures of progress, since without agreement on a measure it is difficult to know when a goal has been achieved.

Example

A request for a technology because a competitor has one names no organizational goal. The first question is which goal it serves, not which product to buy.

Question:

State the direction of authority between operations and IT, and what happens when it is unclear.
What is the service gap, and how is it avoided?
Why does the source insist on agreement about measures?

Building the plan

Begin with copies of both the current IT plan and the organizational strategic plan.
If the organizational plan has not been developed or refreshed in the last 12 months, validate the organizational strategies and tactics first.
The IT plan must be perfectly aligned with all organizational priorities.
Initiate the document by including the mission, vision, goals and strategies of the organization, since IT supports the business.
Identify the current state of systems and processes supporting the business and assess their effectiveness.
Define the gap between functions that are or can be provided and those that need to be developed or procured.
Compare the timeline for staff to manage development against the costs of external development or purchase.
Identify who will take responsibility for the initiatives to be addressed.
The plan reinforces that there is no such thing as an IT project; all projects are organizational and strategic, with IT one component, so every major initiative needs an operational sponsor.
A well-developed plan maps organizational strategies to supporting applications and processes, showing current system status, expected useful life or the gap between strategy and needed technology.
The remainder of the plan focuses on the gap analysis, outlining current and desired future state.
A SWOT analysis evaluates the strengths, weaknesses, opportunities and threats of the current organization.
Where a gap cannot be bridged by a single process or system change, the plan outlines steps, with detail only for the first step or two and higher-level treatment beyond, since technologies and priorities may change.
The plan outlines pure IT initiatives and personnel needs, such as virtual ICUs, cloud transitions, RFID, artificial intelligence and advanced device integration, plus upgrade or replacement strategies.
It covers current and future resourcing, transition and succession plans, since all organizations experience turnover and each leader should have a mentee being groomed to move up.

Question:

Reconstruct the steps for developing the IT plan.
Explain the claim that there is no such thing as an IT project and its consequence for sponsorship.
How should the plan handle a gap requiring several years of steps?

Keeping the plan alive

Once developed, the plan must remain a living object and be regularly maintained.
It should be part of the organizational strategic plan and updated whenever its companion changes.
Key IT objectives must be visible to the entire department so staff can see and commit to each objective regularly.
Annual performance objectives can be tied back to the plan, and regular reports used as measures against it.
Treat the plan itself as a project and maintain a color-coded scorecard of goal progress and achievement for all to see.

Question:

Name the four practices that keep the IT strategic plan current and visible.

Memory tips

Direction rule: operations direct IT. Every major initiative gets an operational sponsor.
Start condition: if the organizational plan is more than 12 months stale, validate it first.
Five plan steps: include organizational statements, assess current state, define the gap, compare build timeline against external cost, assign responsibility.
SWOT is the gap tool; detail the first step or two only when the path runs years.
Pure IT initiatives still belong in the plan: cloud, RFID, AI, device integration, upgrades, succession.

Key concepts

Operational direction of IT: the principle that operational goals direct IT and not the reverse, with every project requiring operational leadership
Service gap: the shortfall created when requested services surpass what internal staff can provide
IT strategic plan: the plan aligned to organizational priorities, opening with organizational statements and covering current state, gap, build versus buy timing and responsibility
No such thing as an IT project: the principle that all projects are organizational and strategic, making operational sponsorship necessary
SWOT analysis: evaluation of the current organization's strengths, weaknesses, opportunities and threats within the gap analysis
Living plan practices: embedding the plan in the organizational plan, making objectives visible, tying performance objectives and reports to it, and tracking progress on a color-coded scorecard

Practice questions

18 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the balance of leadership and support · operational direction of IT and project risk · recommending technologies and challenging deviation · the service gap · handling of new project requests and requestor support · leaders as organizational conscience · resource readiness and contingency planning · agreement on measures · plan inputs and the 12-month validation rule · the five development steps · the no-IT-project principle and operational sponsorship · strategy-to-application mapping · gap analysis and SWOT · multi-year step treatment · pure IT initiatives, resourcing and succession · maintenance, visibility, performance linkage and scorecard.

Read the original source

Forecasting Technical and Informational Needs of an Organization

Leaders in healthcare IT aid and provide direction in support of the goals and initiatives of the company. This requires a careful balance of leadership and support. It is important that all organizational leaders understand that operational goals direct IT and not the reverse. Lack of clarity regarding the relationship between operations and IT can put projects at risk. All projects need operational leadership and, as necessary, IT guidance and support.

Information management and systems leaders need to be keenly aware of organizational goals and be ready to actively recommend appropriate systems and technologies in support of those goals. Organizations that stay focused on goals will not catch the IT leader off guard. When goal deviation is suspected, the IT leader needs to be ready to challenge the request and to get the project back on track. Remaining focused on goals will help the IT leader and the organization to avoid creating the service gap that occurs when requested services surpass what the internal staff can provide.

New project requests are likely to come from a variety of sources. Some of the requests will be more fully developed than others. Requestors will need support in determining their project's scope, definition and objective. Requestors will also need potential relationship support with a vendor that can undertake the request. The IT leader needs to have program evaluation staff that can sit with requestors and help them work through a new project request. Lacking resources and structure, customers may suggest a solution to a problem that has not been well defined. They need to understand new technology, device integration options and infrastructure limitations. They also need to understand how to leverage the existing application portfolio and how to utilize network services. IT can assist with evaluation of new vendors and provide internal and external consulting services.

All leaders need to know how to assess the tactical steps that are in place to support the organizational goals. Focused goals will bring clarity to the strategies that need to be achieved. Be wary if an organization does not have the discipline to understand what is within its ability to accomplish in a defined time period. Leaders have a responsibility to serve as the organization's conscience regarding IT requests and service overextension. Activities must be clearly prioritized so that all leaders are operating from an institutional strategic plan.

Goals, strategies and tactics will inevitably require both redirection and an occasional time-limited expansion of scope. An IT leader must know which personnel resources are available and understand their readiness to manage contingency planning when unexpected resource issues occur. This knowledge will help the organization remain flexible and make more efficient and well-thought-out decisions in matters requiring IT support.

Not only must IT leaders understand and support the organizational goals with their system-level knowledge and expertise, but they must also have a methodology that supports the organization's ability to measure activities against their stated goals and objectives. They must facilitate a process in which all leaders work together to define the organization's measures of progress and, ultimately, success. If agreement cannot be reached on a measure, it will be difficult to know when the related goal has been achieved.

The measures can be used for internal benchmarking, in which the organization defines its current place, defines the objective and then measures activity against both the starting point and the end goal at regular reporting intervals. Local and national benchmarks may be available, but a contract may be required to use them. It can often be costly gain access to private benchmark data.

Benchmarking data are available in many, but not all, aspects of IT management. Be sure that any benchmarks used are comparable to the data your organization is capable of supplying. Careful clarification on the front end may decrease the challenges of apples-to-oranges comparisons, but a few disparate data points may well remain.

Developing the IT Strategic Plan

Among the many responsibilities of IT leaders is developing the IT strategic plan. In a very large organization, the IT strategic plan may serve as a reference tool for prioritizing the work that is to be done throughout the organization. In small or less complex organizations, the IT plan may be more appropriate as a section or addendum to the organizational strategic plan. When developing an IT strategic plan, it is important to include the input of operational leaders and the staff responsible for the actionable components.

Begin the process of developing an IT strategic plan with copies of both the current IT plan and the organizational strategic plan. If the organizational plan has not been developed or refreshed in the last 12 months, then you must start the process by validating the strategies and tactics of the organizational plan first. The IT strategic plan must be perfectly aligned with all the organizational priorities. If there is no previous IT plan to work from, a myriad of free templates and resources can be found on the Internet1 and used as models for formatting and organization.

Consider taking the following steps to develop your IT plan:

Initiate the document by including the mission, vision, goals and strategies of the organization. IT supports the business and therefore must be grounded in that business and its strategies

Identify the current state of the systems and processes that support the business and assess their effectiveness in meeting their stated functions

Define the gap that exists between the functions that are or can be provided and those that need to be developed or procured

Compare the timeline for staff to manage the development and costs associated with external development or purchase

Identify who will take responsibility for the initiatives to be addressed

The initial stages of the plan need to reinforce the idea that there is no such thing as an IT project. All projects are organizational and strategic in nature, and IT is only one component within the bigger initiative. Once top managers understand and agree to that, they will recognize why every major initiative will need to be sponsored by operational leaders. A well-developed plan will map the organizational strategies and the supporting applications and processes for each strategy. Once fully developed, the map will provide a visual representation of the current systems’ status, an indicator of the expected useful lifeline of the systems or the gap that exists between the strategy and the needed technology.

The remainder of the plan can focus on the gaps—the gap analysis. The plan can outline the current state and desired future state. An approach to consider would be to evaluate the strengths, weaknesses, opportunities and threats (SWOT) of the current organization. In cases where it is not likely that the gap can be bridged with a single process or system change, the plan needs to outline the steps that can be laid out to achieve the desired outcome. As many of the steps may each take several years to complete, the plan's details need only focus on the first step or two, and then more high level for the remaining steps. This is practical, as the technologies and organizational priorities may change during the interval.

Finally, the plan needs to outline some of the pure IT initiatives and personnel needs. Examples of this might include advanced technologies like virtual ICUs, system transitions to cloud technologies, radio-frequency identification (RFID), artificial intelligence and advanced device integration. The plan would include regular system upgrades or replacement strategies. Planning to accommodate current and future resourcing needs, as well as the transition and succession plans for staff and leaders is crucial to ensure consistent leadership. All organizations experience turnover. Is there someone who has the appropriate education and skill set to step into an interim role? Does that person have the qualities to take on the role permanently? How about key managers and supervisors? Each leader should have a mentee within the organization who is being groomed and educated to move up when the time is appropriate. A well-prepared organization has the bench strength to maintain leadership stability in the same way it has system redundancy to maintain continuity.

Chapter 9 · Management and Leadership · Lesson 3 of 18

Tracking Projects and Measuring Service

Big picture

This section covers the two kinds of measurement a department needs when it runs both projects and services. It follows planning because a plan without measurement cannot report progress. The larger problem it solves is that project work and service work fail differently, so one measure cannot cover both. Project plan and Gantt chart go together, as do service level agreement and dashboard, and the control chart is what tells signal from noise.

Walkthrough

Project tracking

Measures that monitor effectiveness and progress of departmental activities let leaders evaluate the performance of a work unit.
In a sector with both projects and services, two types of measures are necessary.
Tracking a project is most effective using a project plan and a related Gantt chart.
A project plan lists tasks with estimated timeframes, dependencies and responsible resources.
A Gantt chart includes rows detailing each step and substep, with columns identifying start dates, projected end dates and completion percentage.
Together they visualize an entire project in both highly summarized and detailed ways.
Commercial project-tracking products exist, but many organizations manage effectively with a simple spreadsheet.

Question:

Distinguish what a project plan lists from what a Gantt chart shows.

Service levels and dashboards

Where service is a component of the work, a service level agreement with indicators tracked at regular intervals is important.
The expected service level can be internally derived, negotiated with customers or driven by externally agreed benchmarks.
Service-level parameters are best measured using a dashboard visualization tool.
A dashboard is a series of graphs or tables indicating current performance, historic performance over an appropriate interval, expected quality of services and, if appropriate, acceptable variation below and above the stated goal.
A stretch goal is an internally desired target exceeding agreed quality-of-service parameters, and is not usually shown on a control chart.
A typical dashboard includes control charts, which add upper and lower control limits to account for natural variation around a mean.
When a series of points begins to move in one direction, the process should be reviewed for special-cause variation.
Variation often increases costs in any business, and in healthcare may signal changes in quality of patient care, warranting immediate attention.

Example

A help desk dashboard drifting steadily upward for six weeks is not six bad weeks. A directional run is the signal the control chart exists to expose.

Question:

Name the three sources of an expected service level.
What does a dashboard display, and what does a run of points in one direction indicate?
Define a stretch goal and say where it does not appear.

Memory tips

Two measures for two kinds of work: project plan and Gantt chart for projects, SLA and dashboard for services.
Gantt columns three: start date, projected end date, completion percentage.
SLA level sources three: internally derived, negotiated with customers, externally benchmarked.
Control chart reading: natural variation between the limits, special-cause variation when points trend in one direction.
Stretch goal is internal, above the agreed level, and stays off the control chart.

Key concepts

Project plan: the list of tasks with estimated timeframes, dependencies and responsible resources
Gantt chart: the row-and-column view of steps and substeps with start dates, projected end dates and completion percentage
Service level agreement: the agreement carrying service indicators tracked at intervals, set internally, by negotiation or by external benchmark
Dashboard: the set of graphs or tables showing current and historic performance, expected quality of service and acceptable variation
Control chart: the dashboard element adding upper and lower control limits, where directional runs indicate special-cause variation
Stretch goal: an internally desired target exceeding agreed quality-of-service parameters, usually not shown on a control chart

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the need for two measure types · project plan and Gantt chart contents and combined value · commercial tools versus spreadsheets · SLA indicators and the three sources of expected level · dashboard definition and contents · stretch goal definition and its absence from control charts · control limits, natural variation and special-cause review · the cost and quality significance of variation.

Read the original source

Implementing the IT Strategic Plan

Once developed, the IT strategic plan needs to remain a living object and therefore must be regularly maintained. To achieve this, the document needs to be part of the organizational strategic plan and updated accordingly with any changes to its companion. The key IT objectives must be visible to the entire department, so that they have an opportunity to see and commit to each objective regularly. Annual performance objectives can be tied back to this plan, and regular reports can be produced and used as measures against the IT strategic plan. Finally, treat the plan itself as a project. Maintain a color-coded scorecard of goal progress and achievement for all to see.

Reporting on System Performance, Evaluating Performance and Evaluating Customer Satisfaction

Measures that monitor the effectiveness and progress of departmental activities are necessary for leaders to evaluate overall performance of a work unit. In an operational sector that has both projects and services, two types of measures will be necessary.

Project Tracking

Tracking a project is most effective when using a project plan and a related Gantt chart. A project plan lists tasks with estimated timeframes, dependencies and responsible resources. A Gantt chart, associated with a project plan, includes a series of rows detailing each of the steps and sub steps to be completed within the project. Each row has multiple columns identifying start dates, projected end dates and completion percentage. The project plan and the Gantt chart provide an excellent way of visualizing an entire project in both highly summarized and detailed ways. Commercial project-tracking software products are available, but many organizations effectively manage projects using a simple spreadsheet. An example of measuring a project against goals is included later in this chapter.

In departments where service is a component of the work done, it will be important to have a service-level agreement (SLA) with indicators that are tracked at regular intervals. The expected service level can be internally derived, negotiated with the customers, or driven by externally agreed-upon benchmarks. Service-level parameters can best be measured using a dashboard visualization tool. A dashboard is a series of graphs or tables that indicate the current performance, the historic performance for an appropriate time interval, the expected quality of services, and if appropriate, the acceptable level of variation below and above the stated goal. In addition to the quality-of-service goal, there may be a stretch goal, though it is not usually on a control chart. The stretch goal is typically an internally desired target that exceeds any quality-of-service parameters that have been agreed to.

A typical dashboard includes a series of control charts. Control charts are statistical representations of the graphs discussed above. They add lines representing the upper control limit (UCL) and lower control limit (LCL). This considers that there will be natural variation in the results represented around a mean. To the extent that a series of points begins to move in one direction or the other, it will become necessary to review the process looking for special-cause variation. In any business, variation will often increase costs. In healthcare, variation may also signal changes in the quality of patient care and therefore warrants immediate attention and understanding.

Chapter 9 · Management and Leadership · Lesson 4 of 18

Assessment, Departmental Effectiveness and Customer Service

Big picture

This section covers how a leader finds out what stakeholders actually experience and how that differs from what the metrics say. It follows measurement because a dashboard can look healthy while users struggle. The larger problem it solves is isolation, since IT leaders often work away from where care is delivered. System effectiveness and departmental effectiveness are the pair to separate: one asks about the software, the other asks about the people who support it.

Walkthrough

Baseline and follow-up assessment

Leaders can become detached from the organization and stakeholders, and IT leaders are especially prone because they often work away from where care is delivered.
Regular departmental and system assessments prevent isolation and enhance communication with stakeholder communities.
Assessments must include the effectiveness of both the systems supported and the services provided.
Measuring system effectiveness starts with a baseline analysis, and requires both objective and subjective assessment of quality metrics.
Ninety-nine percent uptime tracks well on a control chart while customers struggle with an average of 1.75 hours of downtime each week, which is why customer assessment matters.
Environment factors in, since a 24/7 healthcare environment expects 99.999 percent availability.
Face-to-face interviews have value for systems affecting only a small number of stakeholders, especially in disparate parts of the company.
Unit rounding is effective when actual observation of the system in use is needed, and demonstrates interest in stakeholders' work.
Meeting a group of users together is usually most efficient, through existing departmental meetings, a town hall for a general situation or a focus group for specific ones, physically or virtually.
The baseline gathers data on the systems stakeholders use and how they are used, including expectations of availability and performance and past internal and external experience.
Be clear that not all requests can be accommodated while remaining open to meaningful feedback.
After the baseline, commit to regular follow-up analyses at an appropriate interval.
If the organization concurs that IT systems and services are satisfactory, an annual follow-up is enough; a lower assessment warrants a prompter turnaround and more frequent follow-up.
Follow-up can be by telephone or web-based survey, and in-application feedback tools prompt regular responses and spare users a help desk call.

Example

Ninety-nine percent uptime and 1.75 hours of weekly downtime are the same fact stated twice. One is the metric, the other is what the night shift lived through.

Question:

Why does the source pair objective metrics with subjective assessment?
Match face-to-face interviews, unit rounding and group meetings to when each is appropriate.
What determines the follow-up interval?

Departmental effectiveness and customer service

Departmental effectiveness must be differentiated from system effectiveness, since customers and stakeholders have different needs.
The methodology for gathering feedback can be the same but the objectives differ; departmental assessment examines how personnel respond and relate to others.
Departmental effectiveness is measured using interpersonal metrics reported by customers.
A typical first impression of customer service is formed by response time to inquiries.
Customers deliver clinical services and are rarely in one place for more than moments, so response time greater than a couple of minutes is likely to cause dissatisfaction.
The Information Technology Infrastructure Library is a popular service management framework to consider.
Additional satisfaction factors: does IT staff empathize with customer concerns and frustrations.
Does IT staff communicate regularly with customers while working on a problem that takes more than a short time.
Does IT staff communicate resolution of system issues back to the customers who reported them.
Healthcare is primarily a people business, calling for the organization to be customer focused, or customer centric.
HIMSS defines customer centric as placing the customer as the center or focus of design or service.
Internal customers include physicians, nurses, human resources representatives and others with a vested interest in the organization's success.
External customers include patients, consultants, vendors and others connected through services, a contract or an agreement.

Question:

Distinguish departmental from system effectiveness by what each measures.
Name the customer satisfaction factors beyond response time.
Give the HIMSS definition of customer centric and name internal and external customers.

Memory tips

Two effectiveness questions: does the system work, and do the people support it well.
Assessment method by situation: interviews for small or dispersed stakeholder groups, rounding when observation is needed, group meetings for efficiency.
Follow-up rule: satisfactory means annual, unsatisfactory means sooner and more often.
Uptime pair: 99 percent looks fine and means 1.75 hours a week; a 24/7 environment expects 99.999 percent.
Satisfaction factors four: response time, empathy, communication during work, communication of resolution.

Key concepts

Baseline analysis: the starting measurement of system effectiveness combining objective metrics with subjective customer assessment
Assessment methods: face-to-face interviews for small or dispersed groups, unit rounding when observation is needed, and departmental meetings, town halls or focus groups for groups
Follow-up cadence: annual where performance is judged satisfactory and more frequent where it is not, using telephone, web survey or in-application feedback
Departmental effectiveness: the interpersonal measure of how IT personnel respond and relate to others, distinct from system effectiveness
Customer satisfaction factors: response time to inquiries, empathy with concerns, communication during extended work and communication of resolution
Customer centric: placing the customer as the center or focus of design or service, per HIMSS
Internal and external customers: physicians, nurses and staff with a vested interest, versus patients, consultants, vendors and others connected by service, contract or agreement

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: leader detachment and the purpose of regular assessment · coverage of systems and services · baseline analysis with objective and subjective measures · the uptime example and environment expectations · interview, rounding and group methods with their conditions · baseline data gathered and expectation setting · follow-up interval rules and channels · in-application feedback · the distinction between departmental and system effectiveness · interpersonal metrics and response time · ITIL as a framework · the three additional satisfaction factors · customer centricity definition · internal and external customer lists.

Read the original source

Assessment

At times, organizational leaders may find that they have become too detached from the organization and the stakeholders they are serving. IT leaders may be especially prone to this because they often work in a separate location from where care services are provided or because the complexity of their work slowly removes them from the day-to-day environment of care. Regular departmental and system assessments will prevent isolation and enhance communication with stakeholder communities throughout the organization. The assessments need to include the effectiveness of both the systems supported and the services provided.

Measuring system effectiveness needs to start with a baseline analysis. This ties in very nicely with the earlier discussion of understanding service-level benchmarks. It is important to have both an objective and a subjective assessment of the quality metrics. A simple example of this can be seen in an assessment of system availability. Ninety-nine percent uptime for a computer system sounds highly efficient and tracks very nicely along a control chart. Customers, however, report that they struggle with the average of 1.75 hours of system downtime each week. Even though that falls within the 1% deemed acceptable, a customer assessment helps the leader understand the customer's point of view. Furthermore, the environment factors into this assessment. For example, the 24/7 healthcare environment has expectations of 99.999% system availability.

A baseline assessment can be accomplished in several ways. Face-to-face interviews have value for systems that affect only a small number of stakeholders, especially when they work in disparate parts of the company. Unit rounding will be effective when actual observation of the system in use is needed. What better way to demonstrate an interest in stakeholders’ work than to be present in their environment? Typically, it is most efficient to meet with a group of users together. This can be done by going to departmental or unit meetings that are already scheduled. Alternatively, you may choose to call a town hall meeting to look at a general situation or a focus group to examine specific situations. Both can be organized as either physical or virtual meetings.

The baseline assessment is designed to gather data regarding the systems that the stakeholders are using and the way they are being used. Take the time to understand the stakeholders’ expectations of system availability and performance. Listen to their past internal and external experiences and pay special attention if they note adverse changes in systems performance. Use the assessment time to accept feedback regarding opportunities for system operating improvements. Be clear that not all requests can be accommodated but remain open-minded to what will result if some meaningful feedback is directly addressed.

Once the baseline is determined, commit to a regular process of follow-up analyses. Identify the interval that is most appropriate. If the organization concurs with an initial assessment that the performance of IT systems and services is satisfactory, then an annual follow-up assessment will be enough. A lower than desirable assessment warrants a prompter turnaround and more frequent follow-up. Regular communication or monthly status reports should address commitments to improvement. Effectiveness should be reassessed at regular intervals agreed upon with customers.

The process for the follow-up assessment can be accomplished by telephone or web-based surveys. Providing easily accessible feedback tools within the applications themselves will prompt regular responses. Customers will appreciate the availability of immediately accessible feedback because it will enable them to avoid making calls to the help desk.

Departmental Effectiveness

Departmental effectiveness needs to be differentiated from system effectiveness as you do your assessment. The distinction is necessary because customers and stakeholders have a multitude of different needs. The methodology for retrieving feedback about the two can be essentially the same, but the objectives will be different. In the departmental assessment, the value is in understanding how the personnel respond and relate to others within the organization.

Departmental effectiveness is measured using interpersonal metrics reported by customers. Leaders have an advantage because they have also had the opportunity to receive customer service. A typical first impression of customer service is formed by the response time to inquiries. Keep in mind that customers are providing clinical services and therefore are not typically in one physical location for more than a few moments at a time. Any response time greater than just a couple of minutes is likely to cause dissatisfaction. A popular service management framework to consider is the Information Technology Infrastructure Library (ITIL).2

Additional factors to be considered when evaluating customer satisfaction include:

Does IT staff empathize with the concerns and frustrations of customers?

Does IT staff communicate regularly with customers when they are working on a problem that takes more than a short time to resolve?

Does IT staff communicate resolution of system issues back to customers who originally reported the problem?

Providing Customer Service

Healthcare is primarily a people business—it calls for the organization to be particularly customer focused, or customer centric. HIMSS defines customer centric as “placing the customer as the center or focus of design or service.”6 It is excellence in service that distinguishes the IT department as responsive and knowledgeable, or as customer centric. There are several specific factors and approaches to consider in organizing the customer service functions in the IT department. Leaders in healthcare IT are expected to have ethical working relationships with both internal and external customers. In the healthcare sector, internal customers can be physicians, nurses, human resources representatives and others with a vested interest in the success of the organization. External customers include patients, consultants, vendors and others connected to the institution via services, a contract or an agreement. The frame of reference is important when considering how to categorize a customer. In the example above, the entire hospital would be considered the frame of reference. In a situation where a single department is considered, internal customers might be the a much smaller group, and external customers might be others within the organization.7

Delivering outstanding service requires the building of a culture that focuses on customer relations. This can involve changing all aspects of an organization's service delivery. The investment of time and effort can be significant, but the rewards can be enormous, building long-term patient and customer loyalty and helping to ensure business profitability.

Chapter 9 · Management and Leadership · Lesson 5 of 18

Customer Relationship Management and Organizational Change

Big picture

This section covers how an organization builds and sustains service relationships, and the change model the chapter names. It follows the assessment work because feedback without a relationship strategy produces lists rather than improvement. The larger problem it solves is that healthcare is service driven rather than product driven, so relationships are the deliverable. ADKAR is the named change model here, and its last element is the one most often dropped.

Walkthrough

What CRM is and why healthcare differs

Customer relationship management is an organization's approach to interactions with customers, patients, vendors and other business associates.
It uses proven methods to attract new customers, retain current ones and reestablish relationships with past customers.
It leverages technology such as the Internet and social media alongside traditional marketing to organize, automate and synchronize business processes.
Through CRM, organizations can achieve increased quality and efficiency, reduced overall costs and greater profitability.
Unlike many product-driven industries, healthcare organizations are uniquely service driven, aimed at developing relationships that improve patient loyalty by getting the right information at the right time to everyone in the continuum of care.
Customizing service offerings to meet expectations and continuously training and rewarding employees produces profitable relations with patients, payers, regulators, vendors and other stakeholders.

Question:

Define CRM and name the three customer movements it addresses.
How does the source contrast healthcare with product-driven industries?

Building the service culture

Setting a clear customer experience strategy requires understanding the organization's vision and mission, determining customer service direction, slogan and values, sharing the strategy through a comprehensive communications program, emphasizing customer service as each department's responsibility and aligning it with other organizational strategies.
Interpersonal skills and the right attitude are the two critical employee qualities, with functional expertise and technical competence less important since many can be taught.
Four steps build a culture of excellent customer relations: provide training in key personal service skills; use ongoing coaching and feedback; regularly measure and monitor performance levels; and reward performance with monetary and nonmonetary awards.
Effective service delivery requires identifying preferred delivery processes, reviewing critical success points, determining service standards and objectives, establishing delivery procedures and creating service level agreements.
Improvement comes from soliciting customer feedback, teaching staff to handle complaints with the correct blend of empathy, apology and resolution, focusing on the root of the problem rather than symptoms and being proactive rather than reactive.
Senior management support is vital, but involving midlevel management as empowered change agents is essential, engaging them early, involving them in strategy, developing their coaching skills, using them as training facilitators and rewarding and motivating them.
Delivering outstanding service requires building a culture focused on customer relations, which can involve changing all aspects of service delivery.

Example

Hiring for technical skill and hoping for warmth inverts the source's advice. Attitude and interpersonal skill are the hard-to-teach half.

Question:

Name the four steps to building a customer relations culture.
Which qualities does the source prioritize in service staff, and why?
What role does midlevel management play in a CRM program?

The ADKAR change model

New projects bring significant change to organizational workflows and processes, so change management belongs in healthcare IT processes.
The ADKAR model emphasizes awareness of a project through communication.
It addresses the desire for change.
It creates knowledge around the change.
It considers the customer's ability to change.
It provides reinforcement of why the change occurred and the importance of keeping the change in place.
ADKAR change management certification can be attained through a three-day course or a condensed one-day course.
Adoption of a new system is often based on perceived benefit by end users.

A user who understands the new workflow and can perform it but chooses not to has knowledge and ability. What is missing is desire, which no additional training will supply.

Question:

Name the ADKAR elements and what each addresses.
Which element covers keeping the change in place after go-live?

Memory tips

CRM three movements: attract new, retain current, reestablish past.
Healthcare difference: service driven, not product driven; the deliverable is the relationship.
Culture four steps: Train, Coach, Measure, Reward.
Complaint handling blend three: empathy, apology, resolution.
ADKAR: Awareness, Desire, Knowledge, Ability, Reinforcement. Diagnose a stalled adoption by asking which letter is missing.

Key concepts

Customer relationship management: the organization's approach to interactions with customers, patients, vendors and associates, attracting, retaining and reestablishing relationships through method, technology and marketing
Service-driven healthcare: the contrast with product-driven industries, aiming at patient loyalty by getting the right information to everyone in the continuum of care
Customer relations culture: training in personal service skills, ongoing coaching and feedback, regular performance measurement and monetary and nonmonetary reward
Service staff qualities: interpersonal skills and the right attitude as critical, with functional and technical competence teachable
Midlevel management role: empowered change agents engaged early, involved in strategy, coached, used as training facilitators and rewarded
ADKAR: the change model of awareness through communication, desire for change, knowledge of the change, ability to change and reinforcement of why the change occurred

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the CRM definition and its customer movements · use of technology and marketing · CRM benefits · the service-driven contrast and stakeholder breadth · elements of a customer experience strategy · prioritized employee qualities · the four culture-building steps · service delivery design elements and SLAs · feedback, complaint handling blend, root cause focus and proactivity · senior and midlevel management roles · ADKAR elements and certification options · adoption based on perceived benefit.

Read the original source

Managing Customer Relationships with Business Leaders

Customer relationship management (CRM), a widely accepted practice in healthcare, is an organization's approach to interactions with customers, patients, vendors and other business associates.3 CRM involves using proven methods to attract new customers, retain current customers and reestablish relationships with past customers. It also involves leveraging technology, such as the Internet and social media, and traditional marketing techniques to organize, automate and synchronize business processes. Using CRM, healthcare organizations can achieve increased quality and efficiency, reduced overall costs and greater profitability.

Unlike many industries that are product driven, healthcare organizations are uniquely service driven, ultimately aimed at developing relationships to improve patient loyalty by getting the right information at the right time to everyone involved in the continuum of care. By customizing service offerings to better meet customer expectations, and by continuously training and rewarding employees for delivering exceptional customer service, healthcare organizations can achieve profitable customer relations not only with patients, but also with payers, regulators, vendors and other stakeholders.

To improve customer satisfaction levels, a comprehensive systems approach is recommended.5 It is critical to set a clear customer experience strategy. Customer service involves more than creating an organizational slogan. To establish a good strategy, it is important to understand the organization's vision and mission; determine the organization's customer service direction, slogan and values; share the customer service strategy by using a comprehensive communications program; emphasize customer service is a key responsibility for each department; and ensure the customer service strategy aligns with the other organizational strategies.

Selecting the right team and developing, motivating and managing staff members are some important areas of consideration. Interpersonal skills and the right attitude are two qualities critical for employees to possess when providing customer service. Emphasizing functional expertise, technical competence and knowledge is less important, and many of these can be taught. Employees working directly with the customer need to understand the organization's culture and learn key communication skills. Four steps needed to build a culture of excellent customer relations are as follows:

Provide training in key skills needed to deliver excellent personal service

Use ongoing coaching and feedback to reinforce improved customer relations

Regularly measure and monitor performance levels

Reward performance with both monetary and nonmonetary awards

Effective service delivery creates efficient customer interaction, eliminating the need for third-party intervention to keep customers satisfied. To help ensure a positive customer experience, it is important to identify preferred service delivery processes, review critical success points in those processes and determine service standards and objectives. In addition, it is vital to establish service delivery procedures to maximize material service and create SLAs to improve customer satisfaction.

Regardless of how well trained the staff is or how effective the organization's current service delivery processes are, opportunities for improvement can always be identified. It is important that problems and issues be resolved quickly by building continuous improvement into the service delivery procedures. To properly manage the customer experience, it is necessary to identify where opportunities for improvement are by actively soliciting customer feedback; teaching staff how to handle customer complaints effectively by using the correct blend of empathy, apology and resolution; focusing on the root of the problem and not just the symptoms; and being proactive in seeking to prevent issues instead of reacting to events that have already occurred.

Although senior management support is vital for creating and maintaining a successful CRM program, involving midlevel management in the change process and empowering them to be key change agents is essential. To do this, it is vital to engage the management team early and often, to involve management members in formulating the customer service strategy and to develop managers’ coaching skills so that they are able to understand and reinforce key personal service skills. In addition, management should include managers as facilitators during training sessions; reward managers for establishing, monitoring and updating service delivery processes; and motivate managers to be examples to their teams.

New projects can bring a significant change to organizational workflows and processes. It is important to include change management in healthcare IT processes. The ADKAR™ model for change emphasizes awareness of a project through communication, addressing the desire for change, creating knowledge around the change, understanding the customer's ability to change and reinforcement of why the change occurred and importance of keeping the change in place.4 ADKAR Change Management certification can be attained via a three-day course or a condensed one-day course.

Chapter 9 · Management and Leadership · Lesson 6 of 18

Developing Policies and Procedures

Big picture

This section covers when a policy is warranted, where to get one and what must be built into it. It follows the service material because policy is how expectations become enforceable. The larger problem it solves is unenforceable policy: a rule that cannot be audited creates exposure rather than control. Policy and procedure are the pair, with one formalizing what is expected and the other describing how the outcome is accomplished.

Walkthrough

Deciding whether a policy is needed

Policies and procedures standardize actions and operations for employees, patients and guests, and can be implemented at any level from the whole company to the smallest operation.
Leaders face two questions: is the policy really needed, and at what level of the organization must it be implemented.
To maintain accreditation in the United States, a healthcare organization must have a defined set of policies on information management and on security and privacy.
Leaders in other countries need to understand the accreditation standards applying to their operations.
Before implementing a policy, consider its purpose and whether a policy and procedure are necessary to govern that activity.
Do not begin from scratch; peers locally and nationally have addressed many of the same issues and will share advice and examples.
Start with a local survey of peers, which also builds networking connections and begins to create a community standard.
If local support is not available, move to national peer groups, but ask why you may be ahead of the curve for your community.
Organizations such as HIMSS, IFHIMA and IMIA, and other national professional associations, have examples of a variety of policies.

Question:

State the two questions a leader asks before writing a policy.
Where should a policy draft come from, and in what order?

Auditability and consequences

A reason not to adopt a policy or procedure is the inability to audit and report on its effectiveness.
Without the ability to audit, the organization risks a challenge by health system accreditors.
Do what is measurable, measure what you do, review what you have measured and act on the results of what you have reviewed.
Be prepared to act on audit measurements, and build the implications of failing to adhere into the policy itself.
Consequences of noncompliance embedded within policies and procedures help close the loop for employees.
If there needs to be room for exceptions, those exceptions must be outlined as part of the policy.
If there are no consequences for deviation, ask whether the policy is needed at all.

Example

A policy nobody can audit fails twice: it does not change behavior and it gives a surveyor a documented expectation the organization cannot show it meets.

Question:

Give the source's reason for declining to adopt a policy.
What must be built into a policy alongside the expectation itself?

Department policies and procedures

A department or organizational policy formalizes what is expected or required of employees.
A procedure document describes how an outcome is to be accomplished.
Policies and procedures serve two purposes: they set performance requirements usable to motivate or discipline employees, and they serve as ongoing references and orientation documents for new hires.
Department policies and procedures address security elements such as access control, entity authentication, audit trails, data encryption, firewall protection and virus checking.
They address privacy protection, including definitions of access rights and instructions for handling specific information and patients.
They address information retention and availability of medical information, communication of medical information, management of licensed software, handling of service requests, the IT strategic plan and the IT budget.
They also cover change management, project management and process improvement, development methods and standards, and copyrights and ownership.

Question:

Distinguish a policy from a procedure and name the two purposes they serve.
Name the areas department policies and procedures must address.

Memory tips

Two policy questions: is it needed, and at what level.
Drafting order: local peers first, then national peer groups and associations, never from scratch.
Auditability test: if you cannot audit it, do not adopt it.
Policy contents: the expectation, the consequences of noncompliance and any exceptions.
Policy versus procedure: what is required versus how it is accomplished; two purposes are performance requirements and reference or orientation.

Key concepts

Policy and procedure: the formal statement of what is expected or required, and the document describing how an outcome is accomplished
Policy necessity questions: whether the policy is really needed and at what organizational level it must be implemented
Peer sourcing: drafting from local peers first, then national peer groups and associations such as HIMSS, IFHIMA and IMIA
Auditability: the requirement that a policy's effectiveness can be audited and reported, without which accreditors may challenge the organization
Consequences and exceptions: the implications of noncompliance and any permitted exceptions, both built into the policy itself
Purposes of department policies: setting performance requirements usable for motivation or discipline, and serving as ongoing references and new-hire orientation

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: standardization purpose and implementation levels · the two leader questions · accreditation requirement for information management and privacy and security policies · international variation · the instruction not to start from scratch and the local-then-national order · named associations · auditability as grounds for declining a policy and the accreditor risk · the measure-review-act maxim · embedded consequences and exceptions · the no-consequences test · policy versus procedure definitions · the two purposes · department policy subject areas.

Read the original source

Developing Policies and Procedures for Information and Systems Management

The implementation of policies and procedures within an organization facilitates the standardization of actions and operations for employees, patients and guests. Often, policies and procedures can be implemented in any portion of the organizational structure, from the entire company to the very smallest operation. Leaders face two questions: Is the policy really needed? If so, at what level of the organization must that policy be implemented? To maintain their accreditation in the United States, a healthcare organization is required to have a defined set of policies on information management and security and privacy policies. IT leaders in other countries will need to understand the accreditation standards that apply to their operations.

Prior to policy implementation, consider for what purpose you are developing a policy, and whether it is necessary to have a policy and procedure to govern that activity or process. If so, do not begin from scratch. Peers, both locally and nationally, have addressed many of the issues you face, and those same peers will have advice and examples to share. Start with a local survey of your peers. This has the advantage of helping you establish local networking connections and begin to create a community standard for the policy in discussion.

If local support is not available, then move to national peer groups, but ask yourself why you may be in front of the curve for your community. You can always look to organizations like HIMSS,9 International Federation of Health Information Management Associations (IFHIMA),10 and International Medical Informatics Association (IMIA)11 or other national professional associations allied to the field. These organizations will all have examples of a variety of policies.

A reason for not adopting a policy or procedure is your inability to audit and report on the effectiveness of the policy in question. If you do not have the ability to audit, then you run the risk of a challenge by health system accreditors. Do what is measurable, measure what you do, review what you have measured and act on the results of what you have reviewed.

Be prepared to act on the results of your audit measurements, and make sure that the implications of failing to adhere to a policy are built into the policy itself. The consequences of noncompliance, when embedded within the policies and procedures, will help close the loop for employees. If there needs to be room for exceptions, those exceptions must be outlined as part of the policy as well. Once again, if there are no consequences for deviation from policy, then you must ask yourself whether there is a need for the policy in the first place.

The discipline of information and management systems includes a complex web of legal, regulatory, accreditation and other compliance issues. Each country is going to have its own sources of oversight. IT leaders have a responsibility for knowing the sources of those standards in their own country. In the United States, navigation of meaningful use, e-prescribing, conditions of participation and Health Information Portability and Accountability Act (HIPAA) is just the beginning of this complex responsibility. Effective leaders need to either understand the many nuances of these standards or have easy access to individuals who can assist in their understanding. Those individuals include the corporate compliance officer or equivalent, legal counsel and the lead Joint Commission liaison, among others.

Department Documentation

Department policies and procedures (P&Ps) help to guide the processes and actions employees should use to perform their work and are essential for healthcare organizations to achieve various accreditations. A department or organizational policy formalizes what is expected or required of employees, among other things. A procedure document describes how an outcome is to be accomplished. Therefore, policies and procedures serve two purposes: (1) they set performance requirements that can be used to motivate or discipline employees and (2) they serve as ongoing references for employees and orientation documents for new hires.28 In developing P&Ps, the following steps are useful: (1) identify a need; (2) draft a policy or procedure that addresses the need; (3) get management approval; (4) distribute the approved document to employees and educate them on its contents; (5) revise, replace or withdraw the policy or procedure as needed; and (6) coordinate with human resources, corporate compliance or other areas when applicable.

Department P&Ps will address elements such as security (e.g., access control, entity authentication, audit trails, data encryption, firewall protection and virus checking), privacy protection (definitions of access rights and instructions for handling specific information and patients) and information retention and availability of medical information. In addition, communication of medical information, management of licensed software, handling of service requests, the IT strategic plan and the IT budget should be addressed. It is also important to consider change management, project management and process improvement; development methods and standards; and copyrights and ownership in department P&Ps.

Chapter 9 · Management and Leadership · Lesson 7 of 18

Legal and Regulatory Compliance and Business Ethics

Big picture

This section names the bodies whose standards constrain health IT and the ethical frame leaders work inside. It follows policy development because policies encode these obligations. The larger problem it solves is that compliance knowledge is distributed and ever changing, so leaders need either expertise or fast access to it. CMS and the Joint Commission are the two most influential U.S. sources, and their instruments differ: conditions of participation versus voluntary accreditation.

Walkthrough

Sources of standards

Information and management systems involve a complex web of legal, regulatory, accreditation and other compliance issues, and each country has its own sources of oversight.
IT leaders are responsible for knowing the sources of those standards in their own country.
In the United States, navigation of meaningful use, e-prescribing, conditions of participation and HIPAA is only the beginning.
Effective leaders either understand the nuances or have easy access to the corporate compliance officer, legal counsel and the lead Joint Commission liaison.
Depending on organization size, responsibilities may fall on one individual or be distributed, coming together under a corporate compliance committee, a JCI steering committee or an audit and education committee.
The two most influential sources of standards for U.S. healthcare organizations are CMS and the Joint Commission, formerly known as the Joint Commission on Accreditation of Healthcare Organizations.
CMS is part of the Department of Health and Human Services.
The key operating document for a hospital receiving any CMS funding is Conditions for Coverage and Conditions of Participation.
An organization is held to those conditions in order to receive funds for services.
The Federal Register is the official daily publication for rules, proposed rules and notices of federal agencies, and the first and last indication of proposed rule changes.
Joint Commission International serves as the voluntary accreditation body for more than 100 countries, with organizations meeting published standards through preparation and a scheduled site review by JCI surveyors.

Question:

Name the two most influential U.S. standards sources and the Joint Commission's former name.
What is the key operating document for a CMS-funded hospital, and what does it govern?
Describe JCI's role and how accreditation is achieved.

Business ethics and corporate compliance

Corporate financial implosions and evidence of legal and ethical impropriety bring organizational and leadership ethics to the forefront.
As a leader and role model, adhere to an identifiable code of business or corporate ethics.
Leaders must understand and adhere to the corporate code of ethics and values established by the administration or board of directors.
At one end of the spectrum, business ethics ensure all members comply with local, state and federal laws and feel compelled and safe to report activities outside the scope of the law.
Both large and small organizations have a person or department charged with corporate compliance.
Corporate compliance programs comprise basic elements: senior management awareness and involvement; policies and procedures reflecting the organization's compliance procedures; education of management and employees; and monitoring programs and disciplinary procedures for those who do not adhere.
Actions need to be in the best interest of the company and absent any financial gain for individuals or members of their immediate family.
At the other end of the spectrum, business ethics extend fairness and equity inside and outside the organization, with an implied duty to contribute to the business and local communities.

Example

Vendor-paid travel during an active selection is the case the personal-gain clause is written for. The question is not whether the trip is useful but whose interest it serves.

Question:

Name the basic elements of a corporate compliance program.
Who establishes the corporate code of ethics, and what does the personal gain clause forbid?
Describe both ends of the business ethics spectrum.

Memory tips

Two U.S. sources: CMS for conditions of participation, Joint Commission for accreditation. JCAHO is the old name.
CMS sits inside HHS; the Federal Register is where rule changes first and last appear.
JCI anchor: voluntary accreditation in more than 100 countries, standards plus scheduled survey.
Compliance program four: senior involvement, policies and procedures, education, monitoring and discipline.
Ethics spectrum: legal compliance at one end, fairness and community contribution at the other.

Key concepts

Compliance sources: the legal, regulatory and accreditation web each leader must know, supported by the compliance officer, legal counsel and Joint Commission liaison
CMS: the HHS agency whose Conditions for Coverage and Conditions of Participation are the key operating document for funded hospitals
Joint Commission: the accreditation body formerly known as the Joint Commission on Accreditation of Healthcare Organizations, one of the two most influential U.S. standards sources
Federal Register: the official daily publication for federal rules, proposed rules and notices
Joint Commission International: the voluntary accreditation body serving more than 100 countries through published standards and scheduled surveys
Corporate compliance program: a program requiring senior management involvement, compliance policies and procedures, education of management and employees, and monitoring with disciplinary procedures
Business ethics spectrum: legal compliance and safe reporting at one end, and fairness, equity and community contribution at the other, with actions free of personal or family financial gain

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the complexity of compliance obligations and national variation · U.S. examples and internal expert resources · distribution of responsibility and the committee structures · CMS and the Joint Commission as the two most influential sources and the former name · CMS placement in HHS · conditions for coverage and participation and their funding consequence · the Federal Register's role · JCI country reach and accreditation mechanism · the ethical context and the code established by administration or board · the compliance end of the spectrum and safe reporting · corporate compliance program elements · the personal gain prohibition · the fairness and community end of the spectrum.

Read the original source

Depending on the size of the organization, all the responsibilities may fall on the shoulders of one individual. Most likely though, the responsibilities will be distributed around the organization, with those individuals coming together under the auspices of a corporate compliance committee, a Joint Commission International (JCI)12 steering committee, or perhaps an audit and education committee. The information that these individuals are responsible for is ever changing. Their knowledge comes from several key documents, most of which are available directly or by purchase over the Internet. In the United States, the information can be obtained from the Centers for Medicare & Medicaid Services (CMS),13 and internationally, from JCI.12

The two most influential sources of standards for healthcare organizations in the United States are CMS and the Joint Commission, formerly known as the Joint Commission on Accreditation of Healthcare Organizations.

CMS can be found at https://www.cms.gov/. CMS is a part of the Department of Health and Human Services (HHS). The key operating document for a hospital that receives any funding from CMS is “Conditions for Coverage and Conditions of Participations.” The details of this framework are found at https://www.cms.gov/Regulations-and-Guidance/Legislation/CFCsAndCoPs/. A healthcare organization is held to these conditions in order to receive funds for services. On a day-to-day basis, the Federal Register serves as the “the official daily publication for rules, proposed rules and notices of Federal agencies and organizations, as well as executive orders and other presidential documents,” and the first and last indications of proposed rule changes.14

JCI is located online at http://www.jointcommissioninternational.org/. It serves as the voluntary accreditation body for more than 100 countries throughout the world. Accreditation is accomplished by complying with a comprehensive list of standards published by JCI. Organizations meet the standards through preparation, followed by a scheduled site review by a team of JCI surveyors.

Adhering to Ethical Business Principles

Corporate financial implosions and evidence of legal and ethical impropriety bring the need for organizational and leadership ethics to the forefront. As an organizational leader, it is important to the practice of your profession and your position as a role model to your staff that you adhere to an identifiable code of business or corporate ethics.

In the context of your role, you must understand and adhere to the corporate code of ethics and values as established by the administration or board of directors of the organization where you work. On one end of the spectrum, business ethics are meant to ensure that all members of the organization are complying with local, state and federal laws in the work that they do, and that they as individuals feel both compelled and safe to report any activities that are not within the scope of the law. Both large and small organizations will have a person or department charged with corporate compliance.

Corporate compliance programs are made up of a set of basic elements. Senior management must be aware of and involved in the process of compliance. Policies and procedures must reflect the organization's procedures for achieving compliance. Education about compliance must be given to both management and employees. And, there must be both monitoring programs and disciplinary procedures to act on those who do not adhere to the compliance approaches. Actions need to be in the best interest of the company and absent of any financial gain for individuals or for any member of their immediate family.

At the other end of the spectrum, business ethics extend the concepts of fairness and equity both inside and outside the organization. The organization is a member of the business and local communities, and there is an implied duty to be a contributor to those communities.

Chapter 9 · Management and Leadership · Lesson 8 of 18

Comparative Analysis: Budgets, Indicators and Benchmarks

Big picture

This section covers the financial and comparative literacy an IT leader needs to operate as part of organizational leadership. It follows compliance because these are the numbers leaders are held to. The larger problem it solves is that IT leaders sit in operational leadership and are expected to read the organization's reports, not only their own. Days in accounts receivable and discharged not final billed are the pair most often confused, since both represent money owed but not received.

Walkthrough

Reading a budget

IT leaders are often part of the operational leadership of the entire organization and need to understand financial and budgetary reports, comparative benchmarks and overall performance.
Budget reports are typically summarized and reviewed by the organization's financial leaders.
They include annual budgets by line item and the projected budget and expenditures to date.
Variances between budgeted and actual expenditures to date are reported.
There may be a column enabling comparison with actual expenses for the most recent comparable historic period, often last year's same period.
Many expenses spread evenly over the year and are easy to predict, measure and compare.
Other expenditures have unique timing considerations that can lead to a false understanding of the reports if not understood.
Revenue and expenses recognized on a semiannual or quarterly basis can make year-to-date results appear far off target.

Example

A large negative variance in one quarter that disappears by year end is usually a recognition timing artifact, not overspending. Reading the timing before reacting is the skill.

Question:

Name the columns a budget report typically contains.
Why can quarterly or semiannual recognition distort a year-to-date view?

Financial and nonfinancial indicators

Financial and nonfinancial indicators compare one organization with another or against national benchmarks.
Days in accounts receivable expresses the average time it takes to receive payment from payers after bills are submitted to the guarantor.
Discharged not final billed indicates the expected amount to be billed to the guarantor but not yet submitted due to outstanding documentation or procedural issues.
Both indicators represent money due to the organization but not yet received.
Days cash on hand is the cash available to the organization, representing the number of days it could continue operating if no further funds were received.
The larger the days cash on hand number, to a point, the better for the organization.

Question:

Define days in accounts receivable, discharged not final billed and days cash on hand.
What do the first two have in common?

Benchmarks

Benchmarks for organizational operations, like those for information and management systems, include internal and external comparisons.
Internal benchmarks are usually set by operations or the board of directors and often reflect the financial indicators, with goals set for days in accounts receivable and days cash on hand.
External benchmarks may include additional financial indicators but are likely to reflect quality, safety, regulatory or accreditation measures.
Internal benchmarking defines the organization's current place, defines the objective and measures activity against both the starting point and the end goal at regular intervals.
Local and national benchmarks may be available but a contract may be required to use them, and access to private benchmark data can be costly.
Benchmarking data are available in many but not all aspects of IT management.
Any benchmark used must be comparable to the data the organization is capable of supplying, and careful clarification up front reduces apples-to-oranges comparisons.

Question:

Who sets internal benchmarks, and what do external ones typically reflect?
What must a leader verify before using an external benchmark?

Memory tips

Budget report columns: line-item budget, projected budget, expenditures to date, variance, prior-period comparison.
A/R days is payment speed after billing; DNFB is billing not yet sent because of documentation or procedure. Both are money owed, at different stages.
Days cash on hand is survival time without new funds; bigger is better, to a point.
Internal benchmarks come from operations or the board; external ones lean toward quality, safety, regulatory and accreditation.
External benchmark test: comparable to the data you can actually supply.

Key concepts

Budget report: the report showing annual budget by line item, projected budget and expenditures to date, variances and comparison to a prior comparable period
Days in accounts receivable: the average time to receive payment from payers after bills are submitted to the guarantor
Discharged not final billed: the expected amount to be billed but not yet submitted due to outstanding documentation or procedural issues
Days cash on hand: the number of days the organization could continue operating with no further funds received
Internal benchmarks: comparisons set by operations or the board, often reflecting financial indicators and measured against a starting point and an end goal
External benchmarks: comparisons that may add financial indicators and likely reflect quality, safety, regulatory or accreditation measures, sometimes requiring a paid contract

Practice questions

11 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: IT leaders' place in operational leadership · budget report contents and variance reporting · even versus uniquely timed expenditures · recognition timing distortion · the definitions of days in accounts receivable, discharged not final billed and days cash on hand · the shared meaning of the first two · internal and external benchmark sources and content · internal benchmarking method · contract and cost for external data · availability limits and the comparability requirement.

Read the original source

Employing Comparative Analysis Strategies

Organizational leaders need to understand more than their own departmental goals, measures and metrics. IT leaders are often part of the operational leadership of the entire organization. They need to understand the organization's overall financial and budgetary reports, its comparative benchmarks and its overall performance.

Budgets

To understand how the organization is doing financially, it is necessary to be able to read and understand a budget spreadsheet. Typically, such reports will be summarized and reviewed by the financial leaders of the company. These reports include the annual budgets by line item and the projected budget and expenditures to date. Variances between budgeted and actual expenditures to date will be reported, and there may also be a column that enables comparison with actual expenses for the most recent historic comparable financial period. This often consists of last year's expenses for the same time period. Many expenses are spread evenly over the year and are easy to predict, measure and compare. Other expenditures have unique timing considerations that, if not understood, can lead to a false understanding of the reports. Revenue and expenses that are recognized on a semiannual or quarterly basis can make year-to-date results appear far from expected, especially if the budget is constructed with an even distribution of those same expenses and revenues. A well-constructed budget report will include notations explaining the timing of events.

Other Financial and Nonfinancial Indicators

Financial and nonfinancial indicators are measured to compare one organization with another, or against national benchmarks. Days in accounts receivable, or A/R days, is an expression of the average amount of time it takes for the organization to receive payment from payers after the bills have been submitted to the guarantor. The discharged not final billed (DNFB) is an indicator of the expected amount of money to be billed to the guarantor, but not yet submitted due to outstanding documentation or procedural issues. Both indicators are important, as they represent money due to the organization but not yet received. Cash available to the organization is referred to as the day's cash on hand and represents the number of days the organization could continue to operate if no further new funds were received by the organization. The larger the number, to a point, the better it is for the organization.

Benchmarks

In addition to the previously discussed benchmarks specifically for information and management systems, there are benchmarks for organizational operations. These too are made up of both internal and external comparisons. The internal benchmarks are usually set by operations or the board of directors and are often reflections of the financial indicators listed above. Typically, the organization will set its goals for the number of days in A/R and days cash on hand. External benchmarks may include additional financial indicators, but are likely to reflect quality, safety, regulatory, or accreditation measures.

Quality Indicators

Quality indicators may be set by state or federal government agencies or payers to the organization. They may serve as goals to be met and aggregate data to establish benchmarks. Each country may have its own voluntary or required quality benchmarking processes. In the United States, the Department of Health and Human Services (HHS), which is a part of CMS, has several quality reporting programs depending on the type of setting. Other indicators are available from external services, such as the University Health System Consortium or Premier®. These entities will take extracts of your organization's data and aggregate them with comparable data from other organizations. This information is then distributed back to the data contributors so that each organization can compare its own results with different slices of the healthcare continuum. The advantage of these external comparison groups is that they enable an organization to compare itself with other organizations of like size, educational service, payer mix, geographic location and so forth. The downside is that some of these programs are subscription services that provide comparisons only to paid subscribers.

Chapter 9 · Management and Leadership · Lesson 9 of 18

Quality Indicators, Standards and Practices

Big picture

This section covers where quality indicators come from and what quality oversight means for an IT department that configures clinical software. It follows comparative analysis because indicators are the comparison material. The larger problem it solves is that software quality in healthcare is a patient safety matter, so configuration is subject to review rather than left to the builder. Quality indicators and quality assurance are different objects here: one is a measure set by outside bodies, the other is a practice inside the department.

Walkthrough

Where quality indicators come from

Quality indicators may be set by state or federal government agencies or by payers to the organization.
They may serve as goals to be met and aggregate data to establish benchmarks.
Each country may have its own voluntary or required quality benchmarking processes.
In the United States, the Department of Health and Human Services has several quality reporting programs depending on the setting.
Other indicators come from external services such as the University Health System Consortium or Premier.
These entities take extracts of an organization's data, aggregate them with comparable data from other organizations and distribute the results back to contributors.
The advantage is that an organization can compare its results with different slices of the healthcare continuum.

Question:

Name the sources of quality indicators and how external comparison services work.

Quality standards inside the department

Oversight of an IT department, especially one with software development responsibilities, requires careful attention to quality control standards.
The National Academy of Medicine, formerly known as the Institute of Medicine, has produced many publications on patient quality and safety, including Health IT and Patient Safety: Building Safer Systems for Better Care.
Although a U.S. publication, its principles and recommendations have international relevance.
Software as delivered, and its subsequent configuration by IT staff, requires comprehensive and regular review to ensure safe and high-quality performance.
Quality assurance begins with the staff who implement and configure the software technically.
Performance can be measured against testing results provided by software vendors and internally developed quality assurance scripts.
External quality and patient safety organizations such as the Leapfrog Group can provide testing to ensure appropriate decision support and alerts for computerized practitioner order entry.
Leaders must set clear expectations or a plan for the quality standards to be delivered, then measure, report and modify the plan to continually improve.
Publishing current performance alongside goals and objectives reminds the department of the expectations and aspirations it is striving for.

Example

An order set built correctly to specification can still fire the wrong alert in practice. External CPOE testing exists because the specification and the clinical result are not the same check.

Question:

What does quality assurance cover in an IT department, and against what is performance measured?
Name the former name of the National Academy of Medicine and the publication cited.
How do leaders sustain quality standards?

Memory tips

Indicator sources: government agencies, payers, and external comparison services such as UHC or Premier.
National Academy of Medicine was formerly the Institute of Medicine; the cited work is Health IT and Patient Safety.
Quality assurance scope: software as delivered plus its configuration by staff, tested against vendor results and internal scripts.
Leapfrog Group cue: external CPOE decision support and alert testing.
Sustaining method: set expectations, measure, report, modify, and publish performance against goals.

Key concepts

Quality indicators: measures set by government agencies or payers, serving as goals and as aggregate data for benchmarks
External comparison services: organizations such as the University Health System Consortium or Premier that aggregate contributed data and return comparisons across the continuum
National Academy of Medicine: the body formerly known as the Institute of Medicine, author of Health IT and Patient Safety: Building Safer Systems for Better Care
Quality assurance: the regular review of software as delivered and as configured, measured against vendor testing results and internal quality assurance scripts
External safety testing: testing by organizations such as the Leapfrog Group to ensure appropriate decision support and alerts for CPOE
Sustaining quality standards: setting clear expectations, then measuring, reporting and modifying the plan, and publishing performance against goals

Practice questions

4 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: sources of quality indicators and their dual use · national variation · HHS reporting programs by setting · external comparison services and their aggregation model · the comparison advantage · quality control attention in departments with development responsibility · the National Academy of Medicine, its former name and the cited publication · international relevance · review of delivered and configured software · quality assurance starting with implementing staff · vendor testing results and internal scripts · the Leapfrog Group and CPOE testing · leader expectations, measurement, reporting, modification and publication.

Read the original source

Quality Indicators

Quality indicators may be set by state or federal government agencies or payers to the organization. They may serve as goals to be met and aggregate data to establish benchmarks. Each country may have its own voluntary or required quality benchmarking processes. In the United States, the Department of Health and Human Services (HHS), which is a part of CMS, has several quality reporting programs depending on the type of setting. Other indicators are available from external services, such as the University Health System Consortium or Premier®. These entities will take extracts of your organization's data and aggregate them with comparable data from other organizations. This information is then distributed back to the data contributors so that each organization can compare its own results with different slices of the healthcare continuum. The advantage of these external comparison groups is that they enable an organization to compare itself with other organizations of like size, educational service, payer mix, geographic location and so forth. The downside is that some of these programs are subscription services that provide comparisons only to paid subscribers.

Quality Standards and Practices

Oversight for an IT department, especially one that has responsibilities for software development, requires careful attention to quality control standards. The National Academy of Medicine (formerly known as the Institute of Medicine (IOM)) has produced many publications citing issues with patient quality and safety, including Health IT and Patient Safety: Building Safer Systems for Better Care.15 While a U.S. publication, the principles and recommendations set forth have international relevance.

Software as delivered, and its subsequent configuration by IT staff, requires comprehensive and regular review to ensure safe and high-quality performance. Quality assurance begins with the staff that implement and configure the software technically. Performance can be measured against testing results provided by the software vendors themselves and internally developed quality assurance scripts. As an example, external quality and patient safety organizations such as the Leapfrog Group16 can provide testing to ensure appropriate decision support and alerts for computerized practitioner order entry (CPOE) programs.

Leaders must set clear expectations, or a plan, for the quality standards to be delivered and then measure, report and modify the plan to continually improve on the products delivered. Publishing current performance, as well as goals and objectives, will remind the entire department of the expectations and aspirations for which the group is striving.

Chapter 9 · Management and Leadership · Lesson 10 of 18

Managing Projects and Project Portfolios

Big picture

This section defines project work, the structures that hold multiple projects and the phases and knowledge areas of project management. It follows the quality material because projects are how most IT change is delivered. The larger problem it solves is that operations repeat while projects end, so the two need different management. Project portfolio management and enterprise project portfolio management are the pair to separate, and the nine PMBOK knowledge areas are the named set the exam draws from.

Walkthrough

Projects, matrixed organizations and portfolios

Project management is the discipline of planning, organizing, securing, managing, leading and controlling resources to achieve specific goals.
A project is a temporary endeavor with a defined beginning and end.
That temporary nature contrasts with operational initiatives, which are repetitive, permanent or semi-permanent functional activities.
Hospitals that support both project and functional initiatives are called matrixed organizations.
Where multiple interdependent projects exist, program management manages all the projects in a portfolio.
Project portfolio management is the centralized management of processes, methods and technologies used by project managers and PMOs to analyze and collectively manage a group of current or proposed projects based on key characteristics.
Enterprise project portfolio management manages initiatives through a single enterprise-wide system.
EPPM takes a more integrated and top-down approach to all project-intensive work and resources across the enterprise, in contrast to combining manual processes, desktop tools and best-of-breed applications per portfolio.

Question:

Define a project and contrast it with operational initiatives.
Distinguish program management, PPM and EPPM.

The five phases

Initiating: stakeholders are identified, the project charter and preliminary scope statement are developed and the charter is approved.
Planning: scope, quality and risk management and schedule are planned, including the project management plan, scope management plan and work breakdown structure, risk identification, analysis and response planning, and activity definition, sequencing, resource and duration estimation and human resource planning.
Executing: directing and managing execution, acquiring, developing and managing the team, performing quality assurance and procuring resources.
Monitoring and controlling: managing integrated change control, controlling quality, controlling changes in cost, schedule and scope, measuring performance and monitoring and controlling risks.
Closing: releasing final deliverables, handing over documentation, terminating supplier contracts, releasing resources, communicating closure and undertaking a post-implementation review for success and lessons learned.

An effective change control methodology addresses both reactive and requested changes and includes processes for categorizing changes and determining how they are requested, reviewed and implemented.
The project manager works with sponsors, the team and others to meet goals within budget and on schedule.
The project manager controls assigned resources, manages scope, schedule and cost, reports progress and facilitates and resolves issues, conflicts, risks and obstacles.

Example

A signed scope approved by the sponsor is what turns a later request into a change control decision rather than an assumption someone acts on.

Question:

Name the five phases and place the charter, the work breakdown structure, integrated change control and contract termination.
List the project manager's responsibilities.

The nine PMBOK knowledge areas

Scope management ensures all required work is performed, defining and controlling what is included and excluded, through the scope plan, scope definition, work breakdown structure, scope control and scope verification.
Scope creep is a key reason many projects fail, and is the undisciplined addition of new goals, objectives and milestones that may harm cost or timeline.
Time management develops and controls the schedule through activity definition, sequencing, resource scheduling, duration, schedule development and schedule control.
Cost management estimates cost and ensures completion within the approved budget through cost estimate, cost budgeting and cost control.
Human resource management obtains, develops and manages the team performing the work.
Procurement management manages acquisition of products and services from external sources, including planning acquisitions, negotiating contracts with sellers, selecting sellers, administering contracts and closing contracts.
Risk management identifies project risks and appropriate responses, performing risk analysis, developing a response plan and monitoring and controlling risks.
Quality management ensures the project satisfies its objectives and requirements through quality planning, assurance and control.
Integration management integrates project activities, including developing the plan, directing and managing execution, monitoring and controlling work and closing the project.
Communications management ensures project information is generated and distributed promptly, through communication planning, timely distribution, performance and status reporting and issue resolution among stakeholders.

Question:

Name the nine knowledge areas.
Place activity sequencing, seller negotiation and prompt information distribution in their areas.
Define scope creep and name the discipline that prevents it.

Memory tips

Project versus operations: temporary with an end, versus repetitive and permanent. Both together makes a matrixed organization.
Five phases: Initiating, Planning, Executing, Monitoring and controlling, Closing. Charter in initiating, WBS in planning, change control in monitoring, contracts terminated in closing.
Nine areas: scope, time, cost, human resource, procurement, risk, quality, integration, communications.
Area cues: sequencing is time, sellers are procurement, prompt distribution is communications, integrated change control is integration.
Scope creep is undisciplined addition; scope or project change control management is the answer.

Key concepts

Project: a temporary endeavor with a defined beginning and end, contrasted with repetitive operational initiatives
Matrixed organization: a hospital supporting both project and functional initiatives
Project portfolio management: centralized management of processes, methods and technologies used to analyze and collectively manage a group of current or proposed projects
Enterprise project portfolio management: an integrated, top-down, enterprise-wide approach to all project-intensive work and resources
Project phases: initiating, planning, executing, monitoring and controlling, and closing
PMBOK knowledge areas: scope, time, cost, human resource, procurement, risk, quality, integration and communications management
Scope creep: the undisciplined addition of new goals, objectives and milestones that may harm cost or timeline
Project manager responsibilities: meeting goals within budget and schedule, controlling resources, managing scope, schedule and cost, reporting progress and resolving issues, conflicts and risks

Practice questions

19 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: the definition of project management and of a project · the contrast with operational initiatives · matrixed organizations · program management for interdependent projects · PPM and EPPM definitions and contrast · the five phases and their contents · change control methodology · project manager responsibilities · the nine PMBOK knowledge areas with their components · scope creep and its cost.

Read the original source

Managing Projects, Project Portfolios and Vendors

Another major role of the IT professional is project management. Project management methodology is used in healthcare organizations to successfully implement new and complex IT systems. Project management is the discipline of planning, organizing, securing, managing, leading and controlling resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end. The temporary nature of projects stands in contrast with organizational operational initiatives, which consist of repetitive, permanent, or semi-permanent functional activities. Hospitals that support both project and functional initiatives are called matrixed organizations. In cases where multiple interdependent projects exist, program management is used to manage all the projects in a portfolio.

Health systems with multiple independent projects and resources that require a formalized framework for tracking, allocating and managing them effectively often adopt project portfolio management (PPM). PPM is the centralized management of processes, methods and technologies used by project managers (PMs) and PMOs to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. As the PPM landscape has been evolving rapidly, healthcare organizations are looking to manage their project initiatives through a single, enterprise-wide system called enterprise project portfolio management (EPPM).

In contrast to the traditional approach of combining manual processes, desktop project tools and best-of-breed PPM applications for each project portfolio environment, EPPM takes a more integrated and top-down approach to managing all project-intensive work and resources across the enterprise.

Project management has the following phases:

Managing Projects, Project Portfolios and Vendors

Another major role of the IT professional is project management. Project management methodology is used in healthcare organizations to successfully implement new and complex IT systems. Project management is the discipline of planning, organizing, securing, managing, leading and controlling resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end. The temporary nature of projects stands in contrast with organizational operational initiatives, which consist of repetitive, permanent, or semi-permanent functional activities. Hospitals that support both project and functional initiatives are called matrixed organizations. In cases where multiple interdependent projects exist, program management is used to manage all the projects in a portfolio.

Health systems with multiple independent projects and resources that require a formalized framework for tracking, allocating and managing them effectively often adopt project portfolio management (PPM). PPM is the centralized management of processes, methods and technologies used by project managers (PMs) and PMOs to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. As the PPM landscape has been evolving rapidly, healthcare organizations are looking to manage their project initiatives through a single, enterprise-wide system called enterprise project portfolio management (EPPM).

In contrast to the traditional approach of combining manual processes, desktop project tools and best-of-breed PPM applications for each project portfolio environment, EPPM takes a more integrated and top-down approach to managing all project-intensive work and resources across the enterprise.

Project management has the following phases:

Initiating phase. In this phase, project stakeholders are identified, the project charter and the preliminary scope statement are developed and the project charter is approved.

Planning phase. This phase involves planning the project scope, quality and risk management and schedule. The project scope is defined through creating the project management plan, developing the scope management plan and creating the work breakdown structure (WBS). Quality and risk management planning involves identifying and analyzing risks and planning the risk responses. The project schedule is developed by defining and sequencing activities, estimating activity resources and duration, determining the project schedule and planning human resources.

Executing phase. This phase involves directing and managing project execution; acquiring, developing and managing the project team; performing quality assurance; and procuring project resources.

Monitoring and controlling phase. This phase involves managing the integrated change control process; controlling quality; controlling changes in cost, schedule and scope; measuring performance; and monitoring and controlling risks. An effective change control methodology will address both reactive and requested changes and will include processes for categorizing changes and determining how changes will be requested, reviewed and implemented.

Closing phase. This phase involves releasing the final deliverables to the customer, handing over project documentation to the organization, terminating supplier contracts, releasing project resources and communicating project closure to all stakeholders. The final step is to undertake a post-implementation review to identify the level of project success and note any lessons learned for future projects.

According to the Project Management Body of Knowledge (PMBOK®) Guide, project management consists of nine knowledge management areas17:

Project scope management involves ensuring all the required work is performed to complete the project successfully. Scope creep is a key reason why many projects fail. Project scope management is accomplished by defining and controlling what is included in the project and what is not. Project scope management activities include the scope plan, scope definition, WBS, scope control and scope verification.

Project time management involves developing and controlling the project schedule. Project time management components include activity definition, activity sequencing, activity resource scheduling, activity duration, schedule development and schedule control.

Project cost management involves estimating the project cost and ensuring the project is completed within the approved budget. Accordingly, cost management includes the cost estimate, cost budgeting and cost control.

Project human resource management consists of obtaining, developing and managing the team who will perform the project work.

Project procurement management encompasses managing the acquisition of products and services from external sources in order to complete the project. Project procurement management includes planning acquisitions, negotiating contracts with sellers, selecting sellers, administering contracts with sellers and closing contracts.

Project risk management focuses on the identification of project risks and appropriate responses. Project risk management includes identifying risks, performing a risk analysis, developing a risk response plan and monitoring and controlling risks.

Project quality management involves ensuring the project satisfies its objectives and requirements. Project quality management includes performing quality planning, quality assurance and quality control.

Project integration management consists of the integration of the various project activities. Project integration management includes developing the project management plan, directing and managing project execution, monitoring and controlling the project work and closing the project.

Project communications management ensures project information is generated and distributed promptly. Project communication management activities include planning communication, distributing needed information to project stakeholders in a timely fashion, reporting the project performance and project status and resolving issues among the stakeholders.

The PM is an important stakeholder in bringing projects to successful completion. The PM is responsible for working with project sponsors, the project team and others involved in the project to meet project goals and deliver the project within budget and on schedule. The PM should also control the assigned project resources to best meet project objectives; manage project scope, schedule and cost; report on project progress; and facilitate and resolve issues, conflicts, risks and other obstacles to project success.

Chapter 9 · Management and Leadership · Lesson 11 of 18

Managing Vendor Relationships

Big picture

This section covers what happens after a vendor is chosen: monitoring performance, avoiding common failures and running the relationship to mutual benefit. It follows project management because most large projects are delivered with a vendor. The larger problem it solves is that selection is treated as the finish line when it is the starting line. The three pitfalls are a named set, and the first one is the one that creates the other two.

Walkthrough

The vendor management process

CIOs increasingly turn to vendors for expertise and support, making vendors key to organizational success.
A well-managed vendor relationship produces increased customer satisfaction, reduced costs, better quality and better service, and quicker remedies when problems arise.
Vendor management is not simply negotiating the lowest price possible.
It involves working with vendors on contract performance, schedules and costs, product functionality and support and maintenance agreements for mutual benefit.
The process begins with selecting the right vendor for the right reasons: analyzing business requirements, performing a vendor search, selecting the winning candidate and successfully negotiating the contract.
The contract should be examined so restrictions or exclusions, penalties and terms benefit both parties.
Once the relationship begins, vendor performance must always be monitored, with attention to the requirements most critical to the organization.
Regular communication helps avoid misunderstandings and address issues before they become problems.

Question:

Name the four activities that begin the vendor management process.
What does the source say vendor management is not?

The three pitfalls

Do not confuse vendor selection with vendor management; equal importance goes to managing the relationship during and after selection and contracting.
Do not select a vendor based on price alone; give priority to a vendor that understands the value of a mutually beneficial relationship.
Do not forget to evaluate how vendor relationships affect the business, beyond service level agreements and contract fulfillment, by determining whether the engagement brought value and whether both parties received a return.

Example

A vendor meeting every service level target while nobody can say what the engagement was worth is the third pitfall exactly. Compliance and value are different questions.

Question:

Name the three pitfalls in order and say what each protects against.

The ten principles

Use project management methodology, including a well-defined and properly planned project, effective sponsorship, clear roles, formal change control and effective issue management.
Understand vendor management is multifaceted, covering evaluation and selection, contract development, relationship management and delivery management.
Be aware of the contract details, including what the vendor is responsible for, managing to the contract and understanding what incentives motivate the vendor.
Formal documentation is key: all changes and communications must be in writing and formally controlled.
Contract complexity should be consistent with project risk, so procurement process and contract detail correspond to risk level.
Include all important deliverables in the contract, with specifications, creation methodology, resources, roles and responsibilities, planned communications, acceptance criteria and project success criteria.
Management commitment is key, since senior commitment and flexibility make the partnership work.
Focus on benefiting both customer and vendor, prioritizing mutually beneficial resolutions when tensions arise.
Clarify contractual terms and expectations, reviewing and explaining all terms and processes to avoid conflict.
Ensure vendor and customer roles and responsibilities are clear, with attention to interactions among procurement, the project team, the contract administrator, the project manager and the vendor's project manager, sales, accounting and legal.

Question:

Name five of the ten vendor management principles.
What does formal documentation is key mean in practice?
What should contract complexity be matched to?

Memory tips

Process order: requirements, search, selection, negotiation, then monitoring and communication.
Three pitfalls: selection is not management, price alone, and never evaluating the relationship's value.
Vendor management four facets: evaluation and selection, contract development, relationship management, delivery management.
Documentation rule: every change and communication in writing and formally controlled.
Contract detail scales with project risk, not with vendor size.

Key concepts

Vendor management: working with vendors on contract performance, schedules, costs, functionality and support for mutual benefit, rather than negotiating the lowest price
Vendor management process: analyzing business requirements, searching, selecting, negotiating, then monitoring performance and communicating regularly
Three pitfalls: confusing selection with management, selecting on price alone, and failing to evaluate the relationship's value to the business
Ten principles: project management methodology, multifaceted management, contract awareness, formal documentation, complexity matched to risk, deliverables in the contract, management commitment, mutual benefit, clarified terms and clear roles and responsibilities

Practice questions

16 items drawn from the canonical, stress, supplemental and scenario pools, mapped to this lesson. Answer, then check. The trap family in the feedback is the thing to log, not the miss itself.

Source fidelity

Covered from the source: reliance on vendors and the benefits of good management · what vendor management is not · the four process-opening activities · contract examination for mutual benefit · performance monitoring and regular communication · the three pitfalls and their reasoning · each of the ten principles and its content.

Read the original source

Managing Vendor Relationships

Healthcare chief information officers (CIOs) are increasingly turning to vendors for the expertise and support they need to meet the technology requirements of their organizations. This reliance on vendor partnerships enables vendors to play a key role in the success of many healthcare organizations. A well-managed vendor relationship will result in increased customer satisfaction, reduced costs, better quality and better service from the vendor. If problems arise, a well-managed vendor will be quick to remedy the situation. Vendor management is not simply negotiating the lowest price possible. It involves working with vendors on contract performance, schedules and costs, product functionality and support and maintenance agreements in order to mutually benefit both organizations.

The vendor management process begins with selecting the right vendor for the right reasons. This involves analyzing business requirements, performing a vendor search, selecting the winning candidate and successfully negotiating the contract. The contract should be carefully considered to ascertain that restrictions or exclusions, penalties and terms are beneficial to both parties. Once the relationship with the vendor has begun, vendor performance must always be monitored, with attention to the requirements that are most critical to the healthcare organization. Regular communication between the vendor and the healthcare organization will help to avoid misunderstandings and address issues before they become problems.

Three common pitfalls should be avoided in order to achieve successful vendor management.18 First, it is important not to confuse vendor selection with vendor management. Equal importance needs to be given to managing the vendor relationship during and after the selection and contracting phases. Second, do not select a vendor based on price alone. Instead, give priority to a vendor that understands the value of developing a relationship that is mutually beneficial. Third, do not forget to evaluate how your vendor relationships affect your business. In addition to examining SLAs and contract fulfillment, IT leadership determines whether an engagement has brought value to the organization and whether both parties have received a return on their relationship.

The following 10 vendor management principles will enable healthcare organizations to build effective relationships with their suppliers and service providers19:

Use project management methodology. Due to the high visibility and accountability of today's complex healthcare projects, attention should be given to the basics of project management, such as creating a well-defined and properly planned project, recruiting effective project sponsorship, clarifying roles and responsibilities, establishing formal change control management and ensuring effective issue management.

Understand vendor management is multifaceted. Effective vendor management involves evaluation and selection, contract development, relationship management and delivery management.

Be aware of the contract details. This includes understanding what the vendor is responsible for, managing the project and vendor according to the contract and understanding what incentives motivate the vendor.

Formal documentation is key. All changes to the project and communications must be in writing and formally controlled.

Contract complexity should be consistent with project risk. The procurement process and the contract's level of detail should correspond to the level of project risk.

Include all important deliverables in the contract. Important deliverable specifications; the methodology used to create the deliverable; specific resources, roles and responsibilities; planned communications; deliverable acceptance criteria; and project success criteria should be included in the contract.

Management commitment is key. Senior management's commitment and flexibility are important to making the vendor-customer partnership work.

Focus on benefiting both the customer and the vendor. Both parties to the contract should give high priority to developing mutually beneficial resolutions should issues and tensions arise.

Clarify contractual terms and expectations. All terms and processes in the contract should be reviewed, explained and clarified to avoid conflicts and misunderstandings.

Ensure vendor and customer roles and responsibilities are clear. All parties’ roles and responsibilities should be precisely defined in the contract. Particular attention should be paid to interactions between the procurement department and the project team, the contract administrator and the PM and the vendor's PM, sales team and accounting and legal departments.The PM is an important stakeholder in bringing projects to successful completion. The PM is responsible for working with project sponsors, the project team and others involved in the project to meet project goals and deliver the project within budget and on schedule. The PM should also control the assigned project resources to best meet project objectives; manage project scope, schedule and cost; report on project progress; and facilitate and resolve issues, conflicts, risks and other obstacles to project success.