CPHIMS Study Notebook

Chapter 1 · Source: Introduction

L1.1 · Introduction -- Health, the Four Pillars and the Macro Context

Walkthrough

The chapter opens by defining the thing the whole profession exists to serve. The World Health Organization (WHO) defines health as a state of complete physical, mental and social well-being — and not merely the absence of disease or infirmity. That definition has stood unamended since 1948.

That wording matters more than it looks. It is a three-part definition with an explicit negative clause, and both halves are testable.

Why the holistic framing drives everything else:

  • If people only present for care once disease is advanced, cost is high and outcomes are worse.
  • So care and the systems supporting it increasingly target activities with the greatest impact on the overall health of the community and patient populations, not just the visit.
  • Health is therefore pursued beyond the office visit and the admission — through wellness encounters with nonphysician providers, virtual encounters via telehealth or mobile health, and safety and preventive care outreach programs.
  • Rising healthcare costs strain national economies, forcing continual reevaluation of the delivery paradigm to optimize outcomes at an affordable cost. That is the macroeconomic backdrop for health IT work.

The four pillars

The source names four pillars that must be traded off dynamically:

  1. Quality
  2. Access
  3. Cost
  4. Value

Professionals are pressured to deliver the highest quality of care to the greatest portion of the supported population within tight cost constraints, while demonstrating the value of health IT. The image the source uses is a four-legged stool carrying additional weight from stakeholders.

The stakeholders stacked on top

The source names six stakeholder groups placing demands on that stool:

  • governments
  • consumer groups
  • professional associations
  • regulatory organizations
  • payers/insurers
  • suppliers

The international comparison layer

The Organisation for Economic Cooperation and Development (OECD) provides the basis for comparing how nations organize and resource healthcare, publishing key indicators of health system performance across countries. Figure 1.1 in the source shows wide variance in spending by country and in the proportion of public to private contribution to national health expenditure.

Named outcome and risk-factor data from the source:

  • Large reductions in cardiovascular and infant mortality rates.
  • More than 18% of adults still smoke daily.
  • Almost one-third of children aged 5-9 are overweight; the rate rose from 20.5% to 31.4% between 1990 and 2016.

Big picture

This is the framing section for the entire credential, not filler. Three things are being installed here that you will reuse in every later chapter:

  • A definition of the outcome. Everything downstream — interoperability, CDS, analytics, privacy controls — is justified by whether it moves physical, mental or social well-being.
  • A tension model. Quality, access, cost and value cannot all be maximized simultaneously. When Chapter 9 asks you to prioritize a project or Chapter 4 asks you to justify an investment, this is the trade-off frame the exam expects.
  • A macro lens. The exam is international in framing. Chapter 1 deliberately compares the UK, Canada, Germany, Japan, Australia and the US. Do not answer Chapter 1 questions as if the US is the default.

Nearby concepts you may confuse this with: the Triple Aim / Quadruple Aim (better care, better health, lower cost, + clinician well-being) is not the source's list. The Review Guide's list is quality, access, cost, value.

Key concepts

Health (WHO)

In plain English: Well-being in three dimensions — not just 'you don't have a disease.'

Technical meaning: A state of complete physical, mental and social well-being and not merely the absence of disease or infirmity. Unamended since 1948.

Picture it: A patient with a normal lab panel who is housing-insecure and socially isolated is, under this definition, not healthy.

The four pillars

In plain English: The four things healthcare is always trading off against each other.

Technical meaning: Quality, access, cost and value — requiring dynamic trade-offs under stakeholder pressure.

Picture it: Open a rural telehealth clinic and you buy access. You have just spent cost, and you now have to prove quality and value.

OECD

In plain English: The scorekeeper that lets you compare countries.

Technical meaning: Organisation for Economic Cooperation and Development — publishes key indicators on health system performance across countries, enabling comparison of national spending and the public/private funding split.

Picture it: The chart showing the US far right of every other country on health spend as a share of GDP is OECD data.

Real-world examples

A health system opens a pharmacy-based 'minute clinic' and a preventive outreach van. Neither is a hospital admission or an office visit, but both are squarely within the WHO framing — they move well-being upstream of advanced disease, where cost is lower and outcomes are better.

A CIO proposes a $4M analytics platform. The board asks what it buys. The answer must be phrased in pillar terms: does it raise quality, widen access, lower cost, or demonstrate value? 'It is modern architecture' is not an answer the four-pillar frame accepts.

Distinctions & exam traps

EXAM TRAP · WHO definition — the negative clause

The tempting confusion: Options that give only 'physical and mental well-being', or that define health as the absence of disease.

The deciding clue: Three dimensions — physical, mental, social — AND the explicit denial that health is merely the absence of disease.

Stem wording that triggers it: Any stem quoting or paraphrasing 'a state of complete ... well-being' is testing whether you kept all three dimensions and the negative clause.

EXAM TRAP · Four pillars vs. Triple Aim

The tempting confusion: Substituting the IHI Triple Aim (population health, experience of care, per capita cost) for the source's four pillars.

The deciding clue: The Review Guide's set is quality, access, cost, value. 'Safety' also appears later in the Government subsection as a fourth balancing term — read which list the stem is quoting.

Stem wording that triggers it: A multi-element list item naming three of the four pillars plus one substituted word is the classic one-altered-element trap.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Say the WHO definition of health out loud without looking. Did you keep all three dimensions and the 'not merely' clause?
  2. Name the four pillars, then describe one real decision at your organization where two of them pulled in opposite directions.
  3. Explain to a clinician why the shift toward wellness encounters, telehealth and outreach follows logically from the WHO definition rather than being a marketing trend.

Questions

No canonical items map to the Introduction. It is framing for the chapter and supplies vocabulary reused in Chapters 3, 4 and 9.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • WHO definition of health (three dimensions + 'not merely the absence of disease or infirmity'); unamended since 1948
  • Rationale for holistic health: late presentation -> high cost, poorer outcomes
  • Extension of care beyond office visits and admissions: wellness encounters with nonphysician providers, telehealth/mobile health virtual encounters, safety and preventive care outreach
  • Macroeconomic pressure of healthcare costs on national economies
  • Four pillars: quality, access, cost, value; dynamic trade-offs; four-legged stool image
  • Six stakeholder groups: governments, consumer groups, professional associations, regulatory organizations, payers/insurers, suppliers
  • OECD role: key indicators on health system performance across countries; Figure 1.1 spending variance and public/private proportion
  • Outcome and risk data: reductions in cardiovascular and infant mortality; >18% of adults smoke daily; ~1/3 of children 5-9 overweight; 20.5% -> 31.4%, 1990-2016
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 · Source: Healthcare Organizations > Hospitals

L1.2 · Healthcare Organizations -- Hospitals

Walkthrough

The source organizes the whole universe of healthcare organizations through the eyes of the patient: people say "I went to see my doctor at her office" or "I was in the hospital last week." From that, the chapter builds four buckets:

  1. Hospital-based care — also called inpatient care.
  2. Care from doctors' offices — called outpatient or ambulatory care.
  3. Providers of ancillary services — the diagnostics and pharmaceuticals that support the care process.
  4. Regulators and payers of care.

The source stresses that these structures vary not only by country but often by geographic location within countries.

The four hospital classification systems

The single most important sentence in this subsection: a hospital may be classified in more than one way at once. The source's own example — a hospital that is private, not-for-profit and specialty — falls into three categories simultaneously. The classification axes are independent, not mutually exclusive.

The four notable systems for classifying hospitals:

1. Ownership — public (government-managed) vs. private

  • Public hospitals: governments (national, provincial, state or other level) own and are responsible for operations. Providers in them are generally private practitioners, though in some countries providers are government employees as well — the source names the UK National Health Service (NHS) and the US Veterans Health Administration.
  • Private hospitals: staffing spans a broad spectrum of private practitioners or provider groups. In some countries private hospitals are further split into for-profit vs. nonprofit.
  • For-profit private hospitals, also called investor-owned, often exist as part of a multihospital system with varying degrees of interrelationship. Named examples: Hospital Corporation of America (HCA) and BMI Healthcare (UK).
  • Nonprofit private hospitals are not investor owned. They organize as nonprofit corporations under national and state law, which generally gives them the advantage of avoiding federal and property taxes. Canada's hospitals are publicly financed but almost exclusively private, nonprofit organizations, funded through provincial/territorial governments. Just over half of US hospitals are private, nonprofit.

2. Types of service provided

Most hospitals are general hospitals covering the most common medical and surgical needs. Specialty hospitals are becoming more prevalent, and the source names three:

  • psychiatric hospitals — mental healthcare;
  • rehabilitation hospitals — generally restoring neurological and musculoskeletal function after treatment in an acute care facility;
  • children's hospitals — care and treatment of children.

3. Teaching status

Teaching hospitals provide inpatient clinical services and train future physicians and other providers. Often associated with academic institutions, they may be further classified as academic medical centers or university hospitals. Many contribute substantially to medical research and publish knowledge advancing the science of medicine.

4. Geographic location

Urban hospitals are located in large cities; rural hospitals are substantially distant from major urban areas with greater resources. The source is explicit that this is not a cosmetic distinction: operating challenges differ enough to require programs of specialization, and meeting government standards for urban or rural classification may give access to special government funding programs.

Big picture

This subsection establishes the taxonomy discipline the exam uses all through Section I. Almost every Chapter 1 distractor works by mixing axes: it offers an ownership answer to a geography question, or a service-type answer to a population-served question.

Where it fits in the lifecycle: organization type determines nearly everything downstream that later chapters cover — which regulations apply, which accreditor surveys you, how you are reimbursed, what the IT department looks like (Lesson 1.8), and how big your interoperability problem is (Lesson 1.7).

Adjacent concepts likely to be confused: nonprofit (a tax and ownership status) vs. public (government-owned) vs. publicly financed (funding source). Canada is the source's deliberate trap case — publicly financed and private nonprofit at the same time.

Key concepts

Investor-owned hospital

In plain English: A for-profit hospital with shareholders.

Technical meaning: A for-profit private hospital, often part of a multihospital system with varying degrees of interrelationship among the system's hospitals.

Picture it: HCA in the US; BMI Healthcare in the UK.

Nonprofit private hospital

In plain English: Privately run, but organized so profits stay in the mission — and it does not pay most taxes.

Technical meaning: Not investor owned; organized as a nonprofit corporation under national and state law, generally avoiding federal and property taxes. Just over half of US hospitals.

Picture it: The defining exam fact is the tax advantage, not the ownership sentiment.

Teaching hospital

In plain English: A hospital that also trains the next generation of clinicians.

Technical meaning: Provides inpatient clinical services and trains future physicians and other healthcare providers; may be further classified as an academic medical center or university hospital; often a major research contributor.

Picture it: Teaching status is its own axis — a teaching hospital can also be public, general and urban.

Urban / rural classification

In plain English: Where the hospital sits — which changes what money it can get.

Technical meaning: Urban = large city; rural = substantially distant from major urban areas with greater resources. Different operating challenges require programs of specialization; meeting government classification standards may unlock special funding programs.

Picture it: The reason 'geographic location' is a real classification system and not trivia is the funding tied to it.

Real-world examples

A 90-bed children's rehabilitation hospital in a mid-sized city, owned by a nonprofit corporation and affiliated with a medical school, is simultaneously: private, nonprofit, specialty (two ways — rehabilitation and children's), teaching, and urban. Five labels, four axes, one hospital.

An IT director planning an EHR rollout across a five-hospital investor-owned system finds each hospital was acquired separately and has its own lab system. That is the 'varying degrees of interrelationship among the system's hospitals' clause showing up as an interface problem.

Distinctions & exam traps

EXAM TRAP · Classification axes are not mutually exclusive

The tempting confusion: Answering that a hospital falls under exactly one classification, or that choosing one axis excludes another.

The deciding clue: The source's own example places one hospital in three categories at once. Any option asserting a restriction on classification is inventing it.

Stem wording that triggers it: When every distractor restricts something — 'exactly one', 'restricted from', 'required to choose' — check whether the restriction is real. It usually is not. (Category outlier.)

EXAM TRAP · Nonprofit vs. public vs. publicly financed

The tempting confusion: Treating 'nonprofit' as meaning government-funded, or 'publicly financed' as meaning government-owned.

The deciding clue: Ownership, funding source and employment model are three different things. Nonprofit is a tax/corporate status. Public is government ownership. Canada is publicly financed AND private nonprofit.

Stem wording that triggers it: 'Receive direct operating funding from national government' describes a public hospital, not a nonprofit one. (Adjacent concept.)

EXAM TRAP · The fourth axis that is not an axis

The tempting confusion: Accepting a plausible-sounding but invented classification system — size of the health information staff, bed count, EHR vendor.

The deciding clue: The named set is exactly four: ownership, types of service provided, teaching status, geographic location.

Stem wording that triggers it: On a NOT/EXCEPT item, three options will come from that named list and the fourth from an entirely different domain. Find the one that does not belong to the family. (The negation.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. List the four hospital classification systems from memory, then classify your own organization on all four.
  2. Explain to a finance colleague why 'nonprofit', 'public' and 'publicly financed' are three different claims — and use Canada to make the point.
  3. Someone says a hospital 'has to pick a category.' Explain in your own words why that is wrong, using a single hospital that carries at least three labels.

Questions

4 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Patient's-eye categorization: inpatient/hospital-based, outpatient/ambulatory, ancillary service providers, regulators and payers
  • Structures vary by country and by geographic location within countries
  • A single hospital may be classified in more than one way (private + not-for-profit + specialty example)
  • Classification system 1 — Ownership: public (government-managed) vs. private; NHS and US Veterans Health Administration as government-employed-provider examples
  • For-profit private = investor-owned; multihospital systems; HCA and BMI Healthcare named
  • Nonprofit private: not investor owned; nonprofit corporation status; avoids federal and property taxes; Canada publicly financed but private nonprofit; just over half of US hospitals
  • Classification system 2 — Types of service: general hospitals; psychiatric, rehabilitation (neurological/musculoskeletal after acute care), children's
  • Classification system 3 — Teaching status: trains future physicians and providers; academic medical centers / university hospitals; research and publication contribution
  • Classification system 4 — Geographic location: urban vs. rural; different operating challenges requiring specialization; classification may unlock special government funding programs
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 · Source: Outpatient or Ambulatory Care--A Shift in the Care Setting

L1.3 · Outpatient or Ambulatory Care -- A Shift in the Care Setting

Walkthrough

When care does not require the intensive management of a hospital setting, it is generally delivered in an outpatient or ambulatory care setting — most frequently a doctor's office.

  • Most primary care — delivered by primary care providers (PCPs) or general practitioners (GPs) — happens in the ambulatory setting.
  • Most PCP/GP referrals to clinical specialists for evaluation are also completed in the ambulatory setting.

The shift, and what is driving it

The source frames the past decade as a dramatic shift from the acute care setting to less-expensive, more patient-friendly care settings. The named evidence:

  • Many less complicated surgical procedures that previously required an overnight stay have moved outpatient.
  • 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; urgent care or injury clinics are opening at a tremendous rate.
  • Nontraditional care settings are appearing — 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.
  • Patients are no longer content to call an office and wait for a callback, or wait weeks to see a specialist. Practices responsive to this new model will be the ones that thrive.

The three models of outpatient care

The source names three:

  1. Single independent provider offices
  2. Larger multi-provider group practices, in which a broader range of specialists may be available
  3. Hospital emergency departments — explicitly flagged as not a preferred approach from an expense perspective

Big picture

This is the source's only sustained treatment of demand-side change, and it is the seed for everything the exam later asks about patient engagement, portals, telehealth and access. Note that the chapter body describes the setting shift in detail but never systematically teaches telemedicine, portals, wearables or population health — those appear only in the chapter's learning objective. That gap is filled in Lesson 1.11, which is explicitly labeled supplemental.

Where it fits in the lifecycle: setting shift drives scope decisions in Chapter 4 (analysis), deployment strategy in Chapter 6 (implementation across many small sites rather than one campus), and the interoperability burden in Lesson 1.7 (more sites of care = more handoffs).

Adjacent concept to keep straight: the emergency department is an outpatient model in this taxonomy even though it sits inside a hospital. Setting of care is not the same as physical building.

Key concepts

Ambulatory / outpatient care

In plain English: Care where the patient goes home the same day.

Technical meaning: Care not requiring the intensive management of a hospital setting; most primary care and most specialist referral evaluations occur here.

Picture it: A total joint replacement performed at an ASC with same-day discharge is the source's headline example of how far the boundary has moved.

Ambulatory surgery center (ASC)

In plain English: A surgical facility built for same-day procedures.

Technical meaning: An outpatient facility where even major surgeries such as total joint replacement are now routinely performed with the patient going home the same day.

Picture it: Defined by the type of procedure and discharge model, not by ownership or rurality.

The three outpatient models

In plain English: Solo office, group practice, or the ED.

Technical meaning: Single independent provider offices; larger multi-provider group practices with a broader range of specialists; hospital emergency departments — the last explicitly not preferred on expense grounds.

Picture it: The ED being on this list is the part people forget. It is outpatient care, and it is the expensive way to get it.

Real-world examples

A patient wakes with knee pain. Options in this taxonomy: her PCP's single-provider office, a multi-specialty group practice with orthopedics on site, an urgent care clinic, a drugstore minute clinic, a video visit, or the ED. Five of the six are cheaper than the sixth, and the source says so directly.

A health system's ED volume is dominated by low-acuity visits. The strategic response the chapter implies is not more ED capacity — it is expanding the flexible-hours, walk-in and virtual options patients are already demanding.

Distinctions & exam traps

EXAM TRAP · What actually drove the setting shift

The tempting confusion: Attributing the shift to regulation banning inpatient elective surgery, to falling surgical demand, or to nursing shortages.

The deciding clue: The source names two drivers: less expensive, and more patient-friendly — reinforced by patient demand for always-on access.

Stem wording that triggers it: Nursing shortages are a real pressure of the same era. Ask whether the stated factor actually PRODUCES the described shift. (Correlation offered as cause.)

EXAM TRAP · Setting vs. stage of care

The tempting confusion: Choosing a skilled nursing or rehabilitation facility when asked where a same-day joint replacement is performed.

The deciding clue: Post-acute recovery follows the surgery; it does not perform it. Match the option to the exact stage the stem names.

Stem wording that triggers it: A distractor that is genuinely part of the patient's journey but at the wrong point in it. (Plausible-but-upstream / wrong-stage.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three models of outpatient care and say which one the source calls out as expensive — and why that one surprises people.
  2. Give the two drivers of the acute-to-ambulatory shift in your own words, then name a plausible-sounding driver that is NOT the reason.
  3. Explain to a colleague why 'the patient went home the same day' after a joint replacement is a bigger deal than it sounds.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Definition of outpatient/ambulatory care as care not requiring intensive hospital management
  • PCPs/GPs deliver most primary care in the ambulatory setting; most specialist referral evaluations also ambulatory
  • Dramatic decade-long shift from acute to less-expensive, more patient-friendly settings
  • Less complicated surgeries moved outpatient; total joint replacement routinely at an ASC with same-day discharge
  • Patient demand for flexible hours; rapid growth of urgent care/injury clinics
  • Nontraditional settings: drugstore minute clinics, walk-in options
  • Always-on, always-available patient expectation; direct appointment booking; virtual visits via video calling apps
  • Patients unwilling to wait for callbacks or weeks for specialists; responsive practices thrive
  • Three outpatient models: single independent provider offices, multi-provider group practices, hospital emergency departments (not preferred on expense)
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.

Chapter 1 · Source: Community Health Organizations

L1.4 · Community Health Organizations

Walkthrough

In healthcare, a "community" generally refers to the specific geographic location in which healthcare is delivered. Organizations serving a local population are therefore broadly called community health organizations. Community-centered hospitals and clinics in most nations provide most of the care available to their local populations.

Some nations give community healthcare organizations formal designations that impose both legally constrained definitions and operational characteristics. The source gives three:

Canada — community health centre (CHC)

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.

United States — community health center (CHC)

Generally associated with medically underserved areas as defined by the Health Resources and Services Administration (HRSA). These centers strive to provide comprehensive, culturally competent, quality primary healthcare services to medically underserved communities and vulnerable populations.

United States — critical access hospital (CAH)

Small community hospitals located in rural areas of the US may apply for designation as CAHs, which allows them to receive higher reimbursement rates.

Big picture

This subsection introduces a classification axis the hospital section did not use: population served. Ownership, service type, teaching status and geography describe the organization. CHC and CAH designations describe who the organization exists for and what the government will pay it as a result.

That is why the exam likes it. A question that asks which organization type serves medically underserved populations is testing whether you can switch axes mid-question. Three distractors will classify by ownership, mission or service type; only one classifies by population served.

Where it fits: this is also the first appearance of the idea that a designation unlocks money — the same logic that returns in Lesson 1.9 with deemed status and the ability to bill CMS.

Key concepts

Community (in healthcare)

In plain English: The local geographic area a provider serves.

Technical meaning: The specific geographic location in which healthcare is delivered; organizations serving local populations are community health organizations.

Picture it: Community-centered hospitals and clinics deliver most of the care most people in most countries actually receive.

Community health center (US)

In plain English: A clinic for people the system otherwise misses.

Technical meaning: Associated with medically underserved areas as defined by HRSA; provides comprehensive, culturally competent, quality primary healthcare to medically underserved communities and vulnerable populations.

Picture it: Defined by the population served, not by ownership or by procedure type.

Critical access hospital (CAH)

In plain English: A small rural hospital paid more so it can survive.

Technical meaning: A designation small rural US community hospitals may apply for, allowing higher reimbursement rates.

Picture it: Two constraints in one term: rural AND higher reimbursement. A stem giving both constraints has exactly one answer.

Real-world examples

A 20-bed hospital 60 miles from the nearest referral center applies for CAH designation. The application is not a quality program — it is a financial survival mechanism, and it changes the reimbursement math for every IT investment that hospital makes afterward.

An FQHC-style community health center in an HRSA-designated shortage area needs interpreter-integrated documentation workflows. 'Culturally competent' is in the source definition, and it has direct implications for how the EHR is configured.

Distinctions & exam traps

EXAM TRAP · CAH vs. FQHC vs. ASC vs. teaching hospital

The tempting confusion: All four are real designations, so any of them can look right to a skimmer.

The deciding clue: Match every constraint in the stem. CAH = rural + higher reimbursement. FQHC/CHC = underserved areas, and it is a clinic, not a hospital. ASC = defined by procedure type. Teaching = defined by training role.

Stem wording that triggers it: When a stem hands you two constraints, only one term satisfies both. (Adjacent term.)

EXAM TRAP · Switching classification axes mid-question

The tempting confusion: Answering a population-served question with an ownership or service-type answer.

The deciding clue: Ask what the stem is classifying BY. 'Serves medically underserved populations' is a population axis, so investor-owned, academic and ASC answers are all off-axis.

Stem wording that triggers it: Three distractors classifying by a different axis than the stem is the signature of a wrong-axis item. (Wrong classification axis.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define 'community' the way the source does, then explain why that definition makes CHC a geography-plus-population term rather than an ownership term.
  2. State the two constraints packed into 'critical access hospital' and explain why a teaching hospital cannot satisfy them.
  3. Explain the difference between the Canadian CHC and the US CHC descriptions without looking — what does each one emphasize?

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Definition of 'community' as the specific geographic location in which care is delivered
  • Community-centered hospitals and clinics provide most local care in most nations
  • Formal designations impose legally constrained definitions and operational characteristics
  • Canada CHC: key provider of local health services; access; comprehensive care; health promotion and illness prevention; publicly administered
  • US CHC: medically underserved areas as defined by HRSA; comprehensive, culturally competent, quality primary healthcare; medically underserved communities and vulnerable populations
  • US CAH: small rural community hospitals may apply for designation; higher reimbursement rates
Read the original source

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.

Chapter 1 · Source: Diagnostic and Pharmaceutical Services

L1.5 · Diagnostic and Pharmaceutical Services

Walkthrough

Effective treatment frequently requires diagnostic services and pharmaceutical treatments, which the source groups under a single term: ancillary services.

Who provides them:

  • Larger hospitals will generally have these capabilities in house.
  • Smaller hospitals and outpatient care centers will usually rely on external providers of such services to support comprehensive care.

The key services named in this area are exactly three:

  1. Laboratory and anatomic/anatomical pathology services
  2. Diagnostic imaging / radiology services
  3. Pharmacies

Close associations with these service providers are formed with provider offices and hospitals to ensure effective and comprehensive healthcare delivery.

Big picture

Short section, high interface load. Every one of these three ancillary categories becomes a system integration problem in later chapters: lab results interfaces, PACS and imaging, and e-prescribing/pharmacy systems. When Lesson 1.7 says outpatient providers "rely on external laboratory and radiology services," this is the section that told you why.

Where it fits: this is the supply side of the interoperability argument. The reason Chapter 1 spends so much energy on interoperability is that the diagnostic and pharmaceutical layer is frequently outside the organization delivering care.

Adjacent concept: 'ancillary' in this chapter means diagnostics and pharmacy. Do not stretch it to cover every non-clinical support service.

Key concepts

Ancillary services

In plain English: The lab, imaging and pharmacy support that treatment depends on.

Technical meaning: Diagnostic services and pharmaceutical treatments supporting the healthcare process. Key services: laboratory and anatomic pathology, diagnostic imaging/radiology, and pharmacies.

Picture it: A three-physician practice sends every specimen to a reference lab and every image to an imaging center. Both relationships are ancillary service relationships, and both are interfaces.

Real-world examples

A 15-bed rural hospital contracts out anatomic pathology and after-hours radiology reads. Each contract creates a results-delivery interface, a turnaround-time expectation, and a point where a result can fail to reach the ordering provider — which is exactly the failure mode Lesson 1.7 warns about.

Distinctions & exam traps

EXAM TRAP · The ancillary triad is a closed list

The tempting confusion: Assuming ancillary means 'any support service', so options like housekeeping, dietary or transport look acceptable.

The deciding clue: The source names three: laboratory/anatomic pathology, diagnostic imaging/radiology, pharmacies.

Stem wording that triggers it: An 'all of the above' item listing exactly those three is a genuine aggregator — confirm at least two independently, then take it.

EXAM TRAP · In-house vs. external is a size question

The tempting confusion: Reading the section as saying ancillary services are always outsourced.

The deciding clue: Larger hospitals generally have these capabilities themselves. Smaller hospitals and outpatient centers usually rely on external providers.

Stem wording that triggers it: A stem naming 'smaller hospitals and outpatient centers' is signaling the external-provider half of the sentence.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three ancillary services from memory and say which organizations typically outsource them.
  2. Explain why every ancillary relationship is also an interface, using one concrete result that has to get back to a provider.

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Ancillary services = diagnostic services and pharmaceutical treatments
  • Larger hospitals generally have these capabilities; smaller hospitals and outpatient centers rely on external providers
  • Key services: laboratory and anatomic/anatomical pathology; diagnostic imaging/radiology; pharmacies
  • Close associations formed with provider offices and hospitals to ensure effective and comprehensive delivery
Read the original source

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 · Source: Healthcare Payers

L1.6 · Healthcare Payers

Walkthrough

The source frames this from the perspective of the healthcare delivery organization: payments generally come from three types of entities.

  1. Government-financed and managed programs
  2. Insurance programs administered by private entities
  3. Personal funds

Memorize the framing as well as the list. The question is not "who pays for healthcare in society" — it is "who sends the provider organization money."

1. Government-financed and managed programs

Generally funded through a country's general taxes. Two structures:

  • Pay for the healthcare system directly — the single-payer model of the UK NHS, which finances hospitals and pays the salaries of most NHS providers.
  • Fund a national health insurance programCanada, where the program is administered through provincial health plans. Those plans fund hospitals through community trusts and pay providers through the government's insurance program.

Multipayer systems, such as the United States, are more complex to administer. The US programs named:

  • Medicarefederally managed; citizens 65 years of age and older have most healthcare needs provided for.
  • Medicaidshared-cost federal/state program supporting care for low-income families.
  • Children's Health Insurance Program (CHIP) — another federal/state program providing care to children of uninsured families that do not qualify for Medicaid.
  • Plus several others for smaller special populations.

These three programs cover roughly one-third of the US population.

2. Insurance programs administered by private entities

Generally funded by employers, citizens themselves, or a combination of both.

  • Germany mandates shared health insurance contributions from employers and employees, but the funds are administered by about 1,100 private, nonprofit sickness funds covering more than 90% of the population, making payments to hospitals and providers.
  • United States: roughly 55% have employer-based insurance; an additional 11% purchase insurance directly.
  • Even in many countries with universal healthcare programs, people who can afford private health insurance are usually allowed to buy it. Private insurance generally allows the purchaser to receive services not covered under a national benefit structure and may also improve access to care.
  • When organizations treat privately insured patients, they bill the private insurance entity rather than a government organization.

3. Personal funds

Healthcare is often personally funded by individuals who have government or employer-supported plans, as well as by the uninsured.

  • Co-payments were not required by many universal coverage programs in the past, but an increasing number of countries are adding this requirement to offset growing costs.
  • In the US, co-payments are required under most healthcare programs, whether government or privately managed.
  • Higher-income persons may choose to avoid the constraints of insurance programs and, being able to tolerate the financial risk, become cash payers.
  • The source's sharpest point: those who fail to qualify for programs such as Medicaid but still cannot afford insurance face premium, nonnegotiated rates — charged to those least able to afford them.

The financial-harm data the source cites

  • A 2019 study found 66.5% of all US bankruptcies from 2013 to 2016 were tied to medical issues, with 58.5% caused specifically by medical bills. The remainder met medical-bankruptcy criteria due to income loss related to illness.
  • The Patient Protection and Affordable Care Act, signed March 23, 2010, was intended to reduce these financial risks and make healthcare more affordable and accessible. Despite gains in coverage and access, findings suggest it did not change the proportion of bankruptcies with medical causes.

Big picture

Payment structure is the hidden variable behind most strategy questions on this exam. Who pays determines what gets measured, what gets reported, and therefore what the information systems must produce. A single-payer system and a multipayer system generate completely different data burdens for the same clinical care.

Where it fits in the lifecycle: reimbursement logic drives the business case in Chapter 4, the reporting requirements in Chapter 3, and the priority arguments in Chapter 9.

Nearby concepts to keep separate: single-payer (NHS — government finances and employs), national health insurance (Canada — government insurance administered provincially, providers private), mandated social insurance (Germany — mandatory contributions, private nonprofit sickness funds), multipayer (US). The exam builds four-option items out of exactly these four models.

Key concepts

Single-payer (NHS model)

In plain English: One government payer that also pays the doctors.

Technical meaning: Government funds the healthcare system directly, financing hospitals and the salaries of most providers.

Picture it: The discriminator vs. Canada is who employs and pays the providers.

National health insurance (Canada model)

In plain English: Government insurance, provincially run, private providers.

Technical meaning: Government funding for a national health insurance program administered through provincial health plans, which fund hospitals through community trusts and pay providers through the government's insurance program.

Picture it: Publicly financed care delivered by almost entirely private, nonprofit hospitals.

Multipayer system

In plain English: Many payers, each with its own rules — expensive to administer.

Technical meaning: A system such as the US with federal, federal/state and private payers operating simultaneously; explicitly described as more complex to administer.

Picture it: Medicare (65+), Medicaid (low-income, federal/state), CHIP (children above Medicaid thresholds, federal/state) — together roughly one-third of the population.

Co-payment

In plain English: The patient's share at the point of service.

Technical meaning: A patient contribution increasingly added by universal coverage programs to offset growing costs; required under most US programs, whether government or privately managed.

Picture it: The trend direction matters: more countries are adding co-payments, not fewer.

Cash payer

In plain English: Someone paying out of pocket by choice or by exclusion.

Technical meaning: Higher-income persons who avoid insurance constraints because they can tolerate the financial risk — distinct from the uninsured who cannot qualify for programs and face premium, nonnegotiated rates.

Picture it: Same payment method, opposite bargaining position. The source calls the second case 'perhaps most perversely.'

Real-world examples

A US hospital's registration workflow must identify, for every encounter, which of the three payer types applies — and often more than one (Medicare primary, supplemental private secondary, patient co-payment). That is the multipayer administrative complexity the source names, rendered as screen fields.

A German hospital bills one of roughly 1,100 sickness funds. The funds are private and nonprofit, but the contributions were mandated by government. Neither 'public' nor 'private insurance' alone describes it cleanly — which is exactly why it makes a good distractor.

Distinctions & exam traps

EXAM TRAP · The three payer types — one altered element

The tempting confusion: Lists that swap in 'employers', 'the uninsured' or 'charitable grants' as a third category.

The deciding clue: The three are government-financed and managed programs, insurance administered by private entities, and personal funds. Employers FUND private insurance; the uninsured pay from personal funds. Neither is its own category.

Stem wording that triggers it: Each distractor keeps two correct elements and swaps the third. Find the swapped item instead of reading all four lists whole. (One altered element.)

EXAM TRAP · Country model confusion

The tempting confusion: NHS, Canada, Germany and US Medicaid all appearing as options in the same item.

The deciding clue: Anchor on who employs and pays the providers. NHS pays provider salaries directly. Canada insures and pays through provincial plans. Germany routes mandated contributions through private nonprofit sickness funds. Medicaid is a shared federal/state program for low-income families.

Stem wording that triggers it: All four options describe real financing systems — so the item is decided by one distinguishing feature, not by ruling out absurdities. (Adjacent country model.)

EXAM TRAP · CHIP vs. Medicare vs. HRSA vs. the ACA mandate

The tempting confusion: Any program name can look right for a coverage question if you only read half the stem.

The deciding clue: CHIP has two constraints: children AND families that do not qualify for Medicaid. Medicare is 65+. HRSA designates underserved areas and funds health centers — it is not an insurance program. The individual mandate was a coverage requirement mechanism, not a program covering a population.

Stem wording that triggers it: Two constraints in the stem, exactly one option satisfying both. (Adjacent program.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: The chapter treats payment as a taxonomy of payer types and stops there. It has no treatment of how payment methods have shifted.

Current practice (2026): The dominant vocabulary is now the value-based continuum — fee-for-service -> pay-for-performance -> shared savings -> capitation. Named US programs include the Medicare Shared Savings Program (MSSP) (permanent, 5,000-beneficiary minimum), bundled/episode payment, MIPS and MVPs, and Medicare Advantage Star Ratings. ACO REACH concludes 31 December 2026 and is succeeded by the ten-year LEAD Model (performance year 1 begins 1 January 2027); TEAM (Transforming Episode Accountability Model) is a mandatory episode model; AHEAD is extended through 2035.

Does it matter for the exam? The 4th-edition source does not use the compound term "value-based," and the term ACO appears only three times across all nine chapters. Answer payer-type questions inside the source's three-category frame. If a newer program name shows up in a distractor, do not let it rattle you — and do not assume a newer name is automatically the correct answer.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three payer types in the source's own framing — from the delivery organization's perspective — and explain why 'employers' is not one of them.
  2. Describe the UK, Canada, Germany and US models to a colleague using one discriminator each. If you reach for the textbook sentence, you have recognition, not understanding.
  3. Explain the difference between a cash payer and an uninsured patient paying out of pocket, and why the source calls the second case perverse.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Three payer types from the delivery organization's perspective: government-financed and managed programs, insurance administered by private entities, personal funds
  • Government programs funded through general taxes; two structures — direct system financing vs. funding a national insurance program
  • UK NHS single-payer: finances hospitals and salaries of most NHS providers
  • Canada: national health insurance administered through provincial plans; hospitals funded through community trusts; providers paid through the government's insurance program
  • US multipayer complexity; Medicare (65+, federally managed); Medicaid (shared federal/state, low-income families); CHIP (federal/state, children of uninsured families not qualifying for Medicaid); several others for smaller special populations; roughly one-third of US population covered
  • Private insurance funded by employers, citizens or both; Germany's mandated employer/employee contributions administered by ~1,100 private nonprofit sickness funds covering >90% of the population
  • US: ~55% employer-based insurance, ~11% direct purchase
  • Private insurance permitted alongside universal programs; may cover services outside the national benefit structure and improve access; privately insured patients are billed to the private entity rather than a government organization
  • Personal funds cover co-payments for the insured and full cost for the uninsured; co-payments increasingly added by universal programs; required under most US programs whether government or private
  • Cash payers: higher-income persons avoiding insurance constraints and tolerating financial risk
  • Those failing to qualify for Medicaid but unable to afford insurance face premium, nonnegotiated rates
  • 2019 study: 66.5% of US bankruptcies 2013-2016 tied to medical issues; 58.5% caused specifically by medical bills; remainder due to income loss related to illness
  • Patient Protection and Affordable Care Act signed March 23, 2010; intended to reduce financial risk and improve affordability/accessibility; gains in coverage and access but no change in the proportion of bankruptcies with medical causes
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 · Source: Interrelations Within and Across Healthcare Organizations

L1.7 · Interrelations Within and Across Healthcare Organizations

Walkthrough

The six purposes — a named, complete list

The source states that the purposes of interrelationships among healthcare organizations are numerous, then names six key requirements:

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

The chapter then expands the first three into their own subsections. Items 4, 5 and 6 are named but not expanded — and the exam has tested item 4. Know all six.

Note what is not on this list: any financial relationship in exchange for referrals. That absence is itself testable.


Subsection 1 — Enabling Access to Comprehensive Care Services

Healthcare organizations rely on partners within or outside the organization to deliver comprehensive care. Specifically, outpatient providers often rely on external laboratory and radiology services for accurate diagnoses and on pharmacies to provide prescribed medications and complete the care plan.

  • Absent effective communications — increasingly electronic — the care process will break down and patient outcomes could suffer.
  • This is the area where technology is having the greatest impact.
  • Various public and private initiatives exist to facilitate the seamless, transparent interchange of patient clinical data.
  • "Interoperability" is the keyword here. 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.

That last sentence is the whole definition the exam uses. Transmission is sending. Interoperability is the receiving system being able to consume and use what was sent.


Subsection 2 — Assuring Effective Transfers of Care

When the scope of care required is outside a provider's capability, care is transferred to another provider or organization. Communicating health information during that transfer is exceptionally important to the patient's welfare.

When a complete set of information transfers with the patient, the receiving organization can advance treatment substantially more efficiently and effectively. The source names what "complete" contains:

  • history of the present illness
  • subjective and objective findings, including results of diagnostic tests performed
  • medications prescribed and administered

When such information does NOT accompany the patient:

  • precious time is lost;
  • information is re-created through repetitive evaluations;
  • diagnostic tests are repeated, sometimes invasive ones.

Both loss of time in treating an acute patient and repeating invasive tests can have adverse consequences.

The standard: to facilitate essential health information during transfer of care, a US initiative encourages use of Health Level Seven International's (HL7) Consolidated-Clinical Document Architecture (C-CDA)a standard for electronically transmitting continuity of care information.

Medication reconciliation. Not knowing what a patient is taking or has been given can be life threatening, which has driven national efforts. The US definition, given verbatim in substance by the source:

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.

Four attributes; comparison against an external list. Both halves are tested.


Subsection 3 — Ensuring the General Portability of Care

Even patients enrolled with a specific organization sometimes need care elsewhere — including when they travel away from their routine places of care. If a patient hundreds of miles from home becomes ill or is injured in an accident, having correct health information available can powerfully influence outcomes.

The source's canonical example: the new provider who does not know a patient's medication allergies.

To overcome this, some nations implement national health information exchanges (HIEs) aiming to provide virtual, real-time access to patients' health information. Named initiatives:

  • Canada — Canada Health Infoway: a nonprofit organization made up of the 14 federal, provincial and territorial deputy ministers of health. Vision: "healthier Canadians through innovative digital health solutions."
  • United States — work to define standards for sharing health information through HIEs at the state level and nationally via the Nationwide Health Information Network (NHIN) and, more recently, the Nationwide Interoperability Roadmap.
  • United Kingdom — NHS Digital (formerly the Health and Social Care Information Centre, HSCIC), which connects England's healthcare organizations to make clinical information available to support continuity of care and patient safety.

Big picture

This is the conceptual core of Chapter 1 and the section with the heaviest question load (8 canonical items). Everything the credential is about — moving the right information to the right place at the right time — is argued here in its simplest form.

Where it fits in the lifecycle: Chapter 2 gives you the technical standards layer; Chapter 3 gives you clinical use; Chapter 8 gives you the privacy constraints on all of it. Chapter 1 gives you the why.

Nearby concepts likely to be confused:

  • Transmission vs. interoperability — the single most tested distinction in Section I.
  • Document/transport standards (C-CDA, HL7 messaging, FHIR) vs. terminologies (SNOMED CT, LOINC, RxNorm) vs. imaging (DICOM). Chapter 1 only names C-CDA, but the exam will surround it with the others.
  • Primary vs. secondary use of health information. Primary = this patient's care. Secondary = anything else, with public health statistics and research as the standard examples.

Key concepts

Interoperability

In plain English: The other system can actually use what you sent — not just receive it.

Technical meaning: Transferred data is consumable by the receiving system, eliminating duplicate data entry and making the data instantly available to the treating provider.

Picture it: A faxed discharge summary is transmission. A discharge summary whose medication list populates the receiving system's med rec screen is interoperability.

C-CDA

In plain English: The standard document format for handing off a patient's story.

Technical meaning: HL7 Consolidated-Clinical Document Architecture — a standard for electronically transmitting continuity of care information, encouraged in the US to support transfers of care.

Picture it: Sort standards by job: C-CDA transports a document, SNOMED CT/LOINC/RxNorm supply vocabulary, DICOM handles imaging.

Medication reconciliation

In plain English: Checking what the chart says against what the patient is actually taking.

Technical meaning: Identifying the most accurate list of all medications the patient is taking — name, dosage, frequency and route — by comparing the medical record to an external list obtained from a patient, hospital or other provider.

Picture it: The discriminator is the word EXTERNAL. Reviewing your own chart against itself is not reconciliation.

Health information exchange (HIE)

In plain English: Infrastructure that makes your record findable when you are far from home.

Technical meaning: National or state initiatives providing virtual, real-time access to patients' health information across organizations. Named: Canada Health Infoway, NHIN and the Nationwide Interoperability Roadmap (US), NHS Digital (UK).

Picture it: Canada Health Infoway is a nonprofit made of the 14 federal, provincial and territorial deputy ministers of health — a governance fact the exam can key on.

Secondary use

In plain English: Using a patient's data for something other than treating that patient.

Technical meaning: Use of health information for a purpose other than the direct care of the individual — public health statistics and research being the standard examples. Corresponds to the source's named purpose 'reporting public and population health information.'

Picture it: One test question: is this for THIS patient's care? Yes = primary. No = secondary.

Real-world examples

A patient is transferred from a critical access hospital to a tertiary center. The C-CDA arrives with history of present illness, findings, test results and administered medications. The receiving team does not reorder the CT. Time saved, one invasive test avoided — the source's two named harms, both prevented.

The same lab result serves two purposes. Sent to the ordering physician to confirm a diagnosis, it is primary use. Aggregated into a state communicable-disease report, it is secondary use. Same data element, different purpose, different rules.

A patient collapses 400 miles from home. The ED has no record and no allergy list. This is the exact scenario the portability subsection exists to describe, and the exam's answer to 'greatest immediate clinical risk' is unknown medication allergies — not billing delay, not duplicate MPI records.

Distinctions & exam traps

EXAM TRAP · Transmission vs. interoperability

The tempting confusion: Treating successful sending as interoperability.

The deciding clue: The source's test is consumability by the receiving system without re-entry. If a human retypes it, you had transmission.

Stem wording that triggers it: 'Consumable by the receiving system', 'without re-entry', 'eliminate duplicate data entry' all point to interoperability. (Wrong layer.)

EXAM TRAP · Document standard vs. terminology vs. imaging

The tempting confusion: Choosing SNOMED CT or LOINC when the stem asks for a continuity-of-care transmission standard.

The deciding clue: C-CDA is a document/transport standard. SNOMED CT and LOINC are vocabularies. DICOM is imaging.

Stem wording that triggers it: 'Electronically transmitting continuity of care information' names a document, so vocabulary answers are off-layer. (Standards confusion.)

EXAM TRAP · Medication reconciliation vs. neighboring pharmacy processes

The tempting confusion: Formulary substitution, therapeutic interchange and order set validation are all real and all medication-related.

The deciding clue: Only reconciliation is defined by comparison against an externally obtained list.

Stem wording that triggers it: The stem hands you the phrase 'external list' or 'obtained from a patient, hospital or other provider.' (Adjacent process.)

EXAM TRAP · The purpose that is not on the list

The tempting confusion: A NOT/EXCEPT item where three options come from the six named purposes and the fourth is a referral kickback.

The deciding clue: Securing financial rewards in exchange for referrals is not a legitimate purpose and in many jurisdictions is unlawful.

Stem wording that triggers it: When a NOT item contains one ethically questionable option, that is almost always the answer. (The negation plus an ethics tell.)

EXAM TRAP · Consequence direction reversal

The tempting confusion: An option stating a real consequence of incomplete transfer with the sign flipped — 'reduced administrative burden on receiving staff.'

The deciding clue: Incomplete transfer INCREASES burden, because staff must re-create the missing information.

Stem wording that triggers it: On NOT items, watch for the correct consequence pointed backwards. (Direction reversal.)

EXAM TRAP · Ranking consequences

The tempting confusion: All four options are genuine consequences, so any can feel defensible.

The deciding clue: Read the qualifier. 'Greatest immediate clinical risk' ranks by patient harm and time horizon — not by frequency or by administrative cost.

Stem wording that triggers it: Superlatives plus a category word ('immediate clinical') are doing the work in the stem. (Consequence ranking.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: NHIN, the Nationwide Interoperability Roadmap, and state-level HIEs as the US national exchange story.

Current practice (2026): The framework is TEFCA — the Trusted Exchange Framework and Common Agreement, mandated by 21st Century Cures Act (2016) section 4003(b). TEFCA is live: 11 designated QHINs (Qualified Health Information Networks), with The Sequoia Project as the Recognized Coordinating Entity, and more than 10,600 organizations connected as of late 2025. QHINs are currently required to respond only to treatment and individual access services requests. Separately, the information blocking rule (also from Cures) prohibits practices likely to interfere with access, exchange or use of electronic health information, subject to defined exceptions. The federal office is now ASTP/ONC (Assistant Secretary for Technology Policy / Office of the National Coordinator), renamed in 2024, though 2026 standards bulletins are again published under "ONC" — treat them as the same body.

Does it matter for the exam? The 4th-edition source mentions none of this: 21st Century Cures Act, information blocking, TEFCA and QHIN all appear zero times across Chapters 1-9. A source-frame stem naming NHIN should be answered in the NHIN frame. But if a stem or distractor uses TEFCA or QHIN language, it is not a typo — and it is not automatically wrong.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name all six purposes of interorganizational relationships. Three are expanded into subsections; the other three are named only. Which three did you drop?
  2. Explain the difference between sending a record and achieving interoperability to a colleague who knows healthcare but not health IT.
  3. Take one lab result and give a primary-use and a secondary-use example of it.
  4. Recite the four attributes in the medication reconciliation definition and explain why the word 'external' carries the whole term.
  5. Explain why a referral kickback is not on the list of legitimate interrelationship purposes — and what that tells you about how NOT items are built.

Questions

8 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Six named purposes of interrelationships: enabling comprehensive care; assuring effective transfers of care; ensuring general portability of information; reporting public and population health information; obtaining appropriate reimbursement; supporting particular organizational models of care
  • Reliance on partners within or outside the organization; outpatient reliance on external laboratory and radiology services and on pharmacies
  • Communication breakdown risks care process failure and patient outcomes
  • Public and private initiatives for seamless, transparent interchange of clinical data
  • Interoperability definition: data consumable by the receiving system, eliminating duplicate entry, instantly available to the treating provider
  • Transfer of care occurs when required scope exceeds a provider's capability
  • Complete transfer contents: history of present illness; subjective and objective findings including diagnostic test results; medications prescribed and administered
  • Consequences of incomplete transfer: lost time, re-created information through repetitive evaluation, repeat diagnostic tests including invasive ones; adverse consequences for acute patients
  • HL7 Consolidated-Clinical Document Architecture (C-CDA) as the standard for electronically transmitting continuity of care information; US initiative encourages its use
  • Medication reconciliation definition: most accurate list of all medications — name, dosage, frequency, route — by comparing the medical record to an external list obtained from a patient, hospital or other provider; life-threatening risk when absent
  • Portability need when patients travel away from routine places of care; canonical example of unknown medication allergies
  • National HIEs providing virtual, real-time access; Canada Health Infoway (nonprofit of the 14 federal, provincial and territorial deputy ministers of health; stated vision); US state HIEs, NHIN and the Nationwide Interoperability Roadmap; UK NHS Digital (formerly HSCIC) connecting England's healthcare organizations for continuity of care and patient safety
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 · Source: Roles and Responsibilities of Healthcare Information and Management Systems Professions

L1.8 · Roles and Responsibilities of Healthcare Information and Management Systems Professions

Walkthrough

The source opens by making the range explicit: the number of position titles in health information management (HIM) and health information technology (HIT/IT) is quite large, and it scales with the organization.

  • In a single-provider office, the person doing the whole 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 executive roles — one verb each

Chief information officer (CIO). The top IT position in healthcare organizations. Generally accountable for a broad range of IT activities, including many not directly related to healthcare: organizational computing rooms, individual desktop computers, telephone communications (including a growing variety of mobile, BYOD (Bring Your Own Device) and IoT (Internet of Things) equipment), secure Internet access, local and wide area networks, and the organization's website.

Chief security officer (CSO). Endeavors to secure the organization's computing and communications assets from intentional or unintentional security breaches, from inside or outside the organization. Lead IT security personnel may hold the Certified Information Systems Security Professional (CISSP) credential from (ISC)2.

Privacy officer. 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 US, the Privacy Act and HIPAA, among others. A credential leveraged for this role is Certified in Healthcare Privacy and Security (CHPS).

Chief technology officer (CTO). 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 keep the organization competitive from a technology perspective — mobile computing platforms, cloud-based computing, state-of-the-art clinical applications.

Chief medical information officer (CMIO) and variants. AMIA advocates advanced training for clinicians to develop a clinical informatics subspecialty. A frequently used title is CMIO; popular variants are chief medical informatics officer and chief health information officer (CHIO). In nursing, the equivalent is chief nursing informatics officer (CNIO).

Anchor each title to one verb: CIO leads. CTO architects. CSO secures. Privacy officer authorizes access. CMIO/CNIO clinically translate.

Health information management

HIM professionals held roles in medical records departments for decades, but before EHRs were commonly available there was not a strong relationship between HIM and IT departments. As records functions became increasingly automated, culminating in EHRs of advanced capabilities, HIM departments are finding themselves at the center of IT activities in healthcare organizations.

Named HIM/HIT credentials:

  • Registered Health Information Administrator (RHIA) — US
  • Registered Health Information Technologist (RHIT) — US
  • Certification in Health Information Management (CHIM) — Canada
  • Certified Professional in Healthcare Information and Management Systems (CPHIMS) — broad base of knowledge and experience in healthcare information and management systems

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

The six IT functions a CIO may oversee

The source gives a sample organization structure. Variation is driven by organization size, geographical distribution and line of business, but a sample CIO structure could include:

  1. Application development and support
  2. Data center operations
  3. Database administration
  4. Desktop support
  5. Information security
  6. Network operations

The eight common IT staff positions

Roles vary by the functions the organization supports and could be filled by staff, consultants or contractors. Common types:

  1. Desktop support technician
  2. Database administrator
  3. Programmer/application developer
  4. Web developer
  5. Network engineer/analyst
  6. Systems analyst/administrator
  7. Project manager
  8. Security analyst

The source's closing point: there is great variation in the size and structure of IT departments, which drives the number and specialization of jobs within the IT organization.

Big picture

This section is where the exam tests whether you can tell neighbouring job titles apart — and Chapter 1 sets up distinctions that Chapter 8 (privacy and security) and Chapter 9 (management and leadership) then lean on hard.

Where it fits in the lifecycle: role clarity determines governance. When Chapter 9 asks who owns a decision, or Chapter 8 asks who is accountable for an inappropriate access, the answer depends on the CIO/CTO/CSO/privacy officer split established here.

Nearby concepts likely to be confused:

  • Privacy officer vs. security officer. Privacy governs who may appropriately access information. Security governs protecting assets from breach. The exam relies on candidates conflating them.
  • CIO vs. CTO. CIO is accountable for the breadth of IT activity and leadership. CTO owns technical architecture and market scanning.
  • IT supports it vs. IT owns it. IT supplies the nurse scheduling system; nursing administration owns nurse scheduling. This one distinction generates a large number of NOT items across the whole exam.

Key concepts

CIO

In plain English: The top IT leader — and the scope is wider than clinical systems.

Technical meaning: Accountable for a broad range of IT activities including many not directly healthcare-related: computing rooms, desktops, telephony, mobile/BYOD/IoT, secure Internet access, LAN/WAN, and the organization's website.

Picture it: If it plugs in and the organization depends on it, it is probably in the CIO's scope.

CSO vs. privacy officer

In plain English: One keeps intruders out; one decides who is allowed in.

Technical meaning: The CSO secures computing and communications assets from intentional or unintentional breaches, inside or outside. The privacy officer ensures PII including PHI is accessed exclusively by those authorized under law (Privacy Act, HIPAA).

Picture it: A clinician snooping a celebrity's chart is a privacy failure with no perimeter breach at all.

CTO

In plain English: The architect and the market scanner.

Technical meaning: Responsible for the technical architecture of IT systems, and scans the developing HIM/IT market to keep the organization technologically competitive — mobile platforms, cloud, state-of-the-art clinical applications.

Picture it: Ask 'who decides what the stack looks like in three years?' That is the CTO.

CMIO / CNIO

In plain English: The clinicians who translate between practice and systems.

Technical meaning: CMIO is the physician-side informatics executive (variants: chief medical informatics officer, CHIO); CNIO is the nursing counterpart. AMIA advocates advanced clinical informatics training as a subspecialty.

Picture it: Read the profession named in the stem before scanning titles — nursing in the stem means CNIO.

Credential map

In plain English: Sort credentials by the function they certify.

Technical meaning: CISSP = information security ((ISC)2). CHPS = healthcare privacy and security. RHIA/RHIT = US health information management. CHIM = Canadian HIM. CPHIMS = broad healthcare information and management systems.

Picture it: Three of those five are HIM or general HIT credentials; only CISSP is a pure security credential.

Real-world examples

An inappropriate chart access is discovered. The privacy officer owns the determination of whether the access was authorized. The CSO owns whether controls failed. The database administrator implements the technical control but holds neither accountability.

A single-provider practice's 'IT department' is the office manager working part time on it. A 600-bed academic medical center's is 100+ people split across six functions. Same job family, two orders of magnitude apart — which is exactly the source's closing point about variation driving specialization.

Distinctions & exam traps

EXAM TRAP · C-suite adjacency

The tempting confusion: Four real titles, each plausible, each with a distinct remit.

The deciding clue: One verb each — CIO leads, CTO architects, CSO secures, CMIO clinically translates, CNIO clinically translates for nursing.

Stem wording that triggers it: 'Technical architecture' = CTO. 'Accountable for the breadth of IT' = CIO. (Adjacent role.)

EXAM TRAP · Privacy vs. security

The tempting confusion: Choosing the CSO or a technical role when the stem asks who ensures PHI is accessed only by authorized individuals.

The deciding clue: Authorization to access = privacy officer. Protection of assets from breach = security.

Stem wording that triggers it: 'Accessed only by authorized individuals' is privacy language, not security language. (Adjacent role.)

EXAM TRAP · Supports-it vs. owns-it

The tempting confusion: Accepting clinical nursing staff scheduling as an IT function because IT provides the scheduling system.

The deciding clue: The six named IT functions are application development and support, data center operations, database administration, desktop support, information security, network operations. Nothing clinical is on that list.

Stem wording that triggers it: On a NOT item, the option describing a clinical or administrative process rather than an IT function is the answer. (Category outlier.)

EXAM TRAP · One altered element in the IT roles list

The tempting confusion: Lists keeping two genuine IT roles and substituting a clinical or HIM title — utilization reviewer, medical staff credentialer, clinical documentation coder.

The deciding clue: The eight named positions are desktop support technician, database administrator, programmer/application developer, web developer, network engineer/analyst, systems analyst/administrator, project manager, security analyst.

Stem wording that triggers it: Scan for the single non-IT title instead of evaluating each list whole. (One altered element.)

EXAM TRAP · Reversed trend

The tempting confusion: Options claiming HIM separated from IT, or was outsourced away, as records automated.

The deciding clue: The observed movement is convergence — HIM moved toward the centre of organizational IT activity.

Stem wording that triggers it: When a stem describes a historical shift, the strongest distractor is usually that same shift stated backwards. (Direction reversal.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: Chapter 1 covers organizational roles thoroughly but stops at the IT department boundary.

Supplemental gap (Tier A, from the Addendum B analysis): The chapter does not cover the governance layer that blueprint task I.A.3 also implicates — board fiduciary duty, medical staff self-governance, the credentialing vs. privileging distinction, and the CEO-board-medical staff triangle. If an item asks who grants a physician the right to perform a specific procedure (privileging) as opposed to verifying their qualifications (credentialing), that distinction is not taught in the 4th-edition Chapter 1 text.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give each executive title one verb, then say which one you would call about an inappropriate chart access — and why the other three are wrong.
  2. Recite the six IT functions and the eight IT staff positions. Then name one role people wrongly assume is IT and explain the supports-it/owns-it distinction.
  3. Map the five credentials to the function each certifies, without looking. Which is the only pure security credential?
  4. Explain in your own words why HIM moved toward the centre of IT rather than away from it.

Questions

7 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Large number of HIM/HIT position titles; single-provider office may have a part-time or office-manager hybrid; large AMC or IDS may exceed 100 IT personnel
  • CIO as the top IT position; broad accountability including non-healthcare IT: computing rooms, desktops, telephone communications, mobile/BYOD/IoT, secure Internet access, LAN/WAN, organizational website
  • CSO: secures computing and communications assets from intentional or unintentional breaches, inside or outside; CISSP credential from (ISC)2
  • Privacy officer: ensures PII including PHI is accessed exclusively by those authorized under law (US Privacy Act, HIPAA); CHPS credential
  • CTO: technical architecture of IT systems; scans developing HIM/IT market for competitiveness; mobile platforms, cloud computing, state-of-the-art clinical applications
  • HIM history: medical records departments for decades; weak HIM-IT relationship before EHRs; automation culminating in advanced EHRs moved HIM to the centre of IT activity
  • HIM/HIT credentials: RHIA, RHIT (US); CHIM (Canada); CPHIMS (broad healthcare information and management systems knowledge and experience)
  • Expanding role of clinical informatics professionals; covered in depth in Chapter 3
  • AMIA advocacy for advanced clinician training and a clinical informatics subspecialty; CMIO title; variants chief medical informatics officer and CHIO; CNIO in nursing
  • Six sample CIO functions: application development and support; data center operations; database administration; desktop support; information security; network operations
  • Structure driven by organization size, geographical distribution, line of business
  • Eight common IT positions: desktop support technician; database administrator; programmer/application developer; web developer; network engineer/analyst; systems analyst/administrator; project manager; security analyst; may be staff, consultants or contractors
  • Closing point: variation in IT department size and structure drives the number and specialization of jobs
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 · Source: Roles of Government, Regulatory, Professional and Accreditation Agencies in Healthcare

L1.9 · Roles of Government, Regulatory, Professional and Accreditation Agencies in Healthcare

Walkthrough

Because healthcare affects quality of life, longevity and survival — and costs enormous sums to deliver to large populations — the source says it is not surprising that a tremendous amount of government oversight and a great number of regulatory bodies are involved. This section walks four layers.

The organizing question for the whole section: who MAKES the rules, who CHECKS compliance with them, and who ADVOCATES for the professionals subject to them?


Layer 1 — Government

Governments are pronounced actors because most countries keep seeing increases in the proportion of GDP consumed by healthcare, and they fear these trends will weaken their national economies if not slowed, stopped or reversed. Stopping that growth requires exceptionally difficult decisions, because citizens have grown accustomed to existing health benefits programs.

The Peterson Kaiser Health System tracker data the source quotes:

  • Over four decades, the gap between US health spending as a share of the economy and comparable OECD countries has widened.
  • 1970: the US spent about 6% of GDP on health, similar to comparable countries (whose average was 5%).
  • The US tracked comparable countries until the 1980s, when its health spending grew significantly faster relative to GDP.
  • 2017: the US spent 17% of GDP on health consumption; the next highest comparable country, Switzerland, spent 12%.

Government responses named by country:

  • Australia — enhancements to the primary care delivery system to manage chronic diseases more effectively
  • Canada — experimentation with privatization
  • Germanyglobal 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 — encouraging development of ACOs with the goal of better health outcomes at lower cost

The source closes the subsection with the balancing set: quality, access, cost and safety for the greatest proportion of populations.


Layer 2 — Healthcare Regulators

Regulatory agencies serve a broad range of functions, generally by implementing the provisions of a nation's health laws through a more explicit system of regulations. That sentence is the definition: laws are passed; regulations implement them.

Named regulators:

  • United Kingdom — Health and Care Professions Council (HCPC). The statutory regulator for 15 professions with nearly 290,000 health and care professionals. Maintains standards of proficiency and conduct for the professions it regulates.
  • United States — CMS. The dominating regulatory entity. Drafts the rules and finalizes the regulations for the management of multiple federally subsidized healthcare programs, through a complex process of rulemaking involving public engagement.
  • United States — Food and Drug Administration (FDA). Evaluates and approves medical devices and new drugs used in the treatment of patients.
  • Canada — Health Canada's Therapeutic Products Directorate. Regulates medical devices.

The source then flags something important: it is a common belief that regulatory organizations are always government entities, but private-sector organizations, commissions and associations may perform in a regulatory capacity as well. That sets up the next two layers.


Layer 3 — Professional Associations

The source defines a profession (Merriam-Webster) 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.

Their primary role is to advocate on behalf of members and promote the profession. Named association functions:

  • 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 impact scope of practice, employment opportunities, and enhancing relationships with related professionals

Regulatory bodies, by contrast, have a purpose of protecting the public by regulating the profession. Named regulatory body functions:

  • 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

This pairing is the highest-yield conceptual contrast in Chapter 1: associations serve MEMBERS; regulators serve the PUBLIC.

Table 1.1 — Professional Associations Related to Healthcare and Healthcare IT

ClinicalAdministrative and IT
American Academy of PediatricsAmerican College of Healthcare Executives
International Confederation of MidwivesAmerican Health Information Management Association
International Council of MidwivesAmerican Medical Informatics Association
Royal College of General PractitionersHealthcare Information and Management Systems Society
World Dental FederationInformation Systems Security Association International
World Medical AssociationInternational Medical Informatics Association

Professional associations exist for nearly every medical specialty, nursing and allied health profession, health administration and IT profession.


Layer 4 — 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) are perhaps the most recognized AOs for the certification of hospitals in the US and internationally. JCI currently operates in more than 100 countries.
  • In the US, the AOs under CMS are very visible examples. CMS AOs determine compliance with Medicare CoP.
  • Deemed status: when an 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.

Read that carefully. Deemed status means "counts as compliant, and you may bill." It does not raise rates, does not exempt you from state licensure, and does not let you write your own CoP.

Table 1.2 — CMS-Approved Accreditation Organizations

OrganizationProgram Type
Accreditation Association for Ambulatory Health Care (AAAHC)Ambulatory surgical centers (ASCs)
Accreditation Commission for Health Care, Inc. (ACHC)Home health agencies (HHAs); Hospices
American Association for Accreditation of Ambulatory Surgery Facilities (AAAASF)ASCs; Outpatient physical therapy (OPT) providers; Rural health clinics (RHCs)
American Osteopathic Association / Healthcare Facilities Accreditation Program (AOA/HFAP)ASCs; Critical access hospitals (CAHs); Hospitals
Center for Improvement in Healthcare Quality (CIHQ)Hospitals
Community Health Accreditation Program (CHAP)HHAs; Hospice
DNV GL-Healthcare (DNVGL)Hospitals; CAHs
Institute for Medical Quality (IMQ)ASCs
National Dialysis Accreditation Commission (NDAC)ESRD facilities
The Compliance Team (TCT)RHCs
Joint CommissionASCs; CAHs; HHAs; Hospices; Hospitals; Psychiatric hospitals

The source closes by noting that interrelationships among government agencies, regulators, professional associations and AOs can be surprisingly complex — illustrated in Figure 1.3 by the many organizations involved in a physician assistant moving from training into practice.

Big picture

This is the section that makes Chapter 1 an exam section rather than background reading. Nearly every question here is a who-does-what question, and the distractors are always neighbouring bodies with genuinely similar-sounding remits.

Build the four-layer mental model and most of this section collapses into one sentence per layer:

  1. Government passes laws and funds programs.
  2. Regulators implement laws through explicit regulations (CMS writes the rules; FDA approves devices and drugs; HCPC regulates UK professions).
  3. Professional associations advocate for members and promote the profession — and may act semi-regulatorily.
  4. Accreditation organizations check compliance on behalf of government, and confer deemed status.

Where it fits in the lifecycle: this layering resurfaces every time a later chapter asks who must approve, who audits, or what happens on survey. Chapter 8's compliance obligations sit directly on top of it.

Key concepts

Regulation vs. law

In plain English: Legislators write the law; regulators write the detail that makes it operable.

Technical meaning: Regulatory agencies implement the provisions of a nation's health laws through a more explicit system of regulations.

Picture it: CMS does not pass Medicare. CMS writes the rules that make Medicare run, through public rulemaking.

Statutory regulator

In plain English: A body established in law with legal authority over practice.

Technical meaning: The HCPC is the UK statutory regulator for 15 professions covering nearly 290,000 professionals, maintaining standards of proficiency and conduct.

Picture it: The word 'statutory' in a stem is the discriminator — it rules out professional colleges and commissioning bodies.

Conditions of participation (CoP)

In plain English: The requirements you must meet to be allowed to bill Medicare.

Technical meaning: CMS-set standards; CMS-approved accreditation organizations determine compliance with them on CMS's behalf.

Picture it: CMS sets the CoP. The accredited organization never sets its own.

Deemed status

In plain English: Your accreditor's survey counts as CMS's survey.

Technical meaning: Certification by a CMS AO for compliance with CMS requirements means the organization is deemed to have met the requirements and may then bill CMS for covered services.

Picture it: Narrow benefit. Not higher rates. Not exemption from state licensure. Not self-defined CoP.

Association vs. regulatory body

In plain English: Associations serve their members. Regulators serve the public.

Technical meaning: Associations advocate with policy makers, market and promote the profession, provide CPD, and monitor developments affecting scope of practice and employment. Regulators set entry requirements, maintain the register of those eligible to practice, develop standards of practice, investigate complaints and discipline, and require CPD.

Picture it: Both may require continuing professional development — which is why the discriminator has to be WHO IS SERVED, not the activity.

Real-world examples

A hospital passes its Joint Commission survey. It is now deemed to have met Medicare CoP and may bill CMS for covered services. Its state licensure survey still happens, and its reimbursement rates do not change.

AHIMA publishes a position statement urging Congress to amend a reporting requirement. That is advocacy — an association function. If AHIMA instead investigated a credentialed member for practice misconduct and revoked the credential, that same body would be acting in a regulatory capacity, which is exactly what the source means by 'semi-regulatory.'

A physician assistant moving from training into practice passes through educational accreditors, a certifying body, a state licensing board and an employer's credentialing process. The source uses this to show that the four layers overlap in one career path.

Distinctions & exam traps

EXAM TRAP · Regulator vs. accreditor vs. program administrator

The tempting confusion: CMS, FDA, the Joint Commission and HCPC all feel like 'oversight.'

The deciding clue: CMS writes and finalizes the regulations for federally subsidized programs. FDA approves devices and drugs. AOs check compliance with CoP on CMS's behalf. HCPC is the UK professional regulator.

Stem wording that triggers it: Bind each body to a single object before reading the options. (Adjacent role / umbrella vs. agent.)

EXAM TRAP · Association vs. regulator — the category outlier

The tempting confusion: A NOT item where three options are genuine regulatory functions and the fourth is advocacy.

The deciding clue: Advocating for members' interests is the defining role of an association. Regulators protect the public — a different and sometimes opposing mandate.

Stem wording that triggers it: Three options serve the public, one serves members. (Category outlier.)

EXAM TRAP · Advocate vs. enact

The tempting confusion: Accepting that associations 'enact laws' or 'set reimbursement' because they clearly influence policy.

The deciding clue: The verb carries the item. Associations INFLUENCE policy; only governments MAKE it.

Stem wording that triggers it: Any option giving a non-government body lawmaking or rate-setting power is the outlier. (Adjacent role.)

EXAM TRAP · Deemed status overreach

The tempting confusion: Options that extend a real benefit further than it goes — exemption from state licensure, guaranteed higher rates, self-defined CoP.

The deciding clue: Deemed status is narrow: counts as compliant, may bill. Nothing more.

Stem wording that triggers it: When one option states the benefit plainly and three state it expansively, take the plain one. (Overreach.)

EXAM TRAP · Accreditor scope mismatch

The tempting confusion: AAAHC, CIHQ, CHAP and JCI are all genuine accreditors, so any can look right.

The deciding clue: Read the scope qualifier. JCI = more than 100 countries, international hospital certification. AAAHC = ASCs. CIHQ = US hospitals only. CHAP = home health and hospice.

Stem wording that triggers it: A stem naming international reach or a specific program type is handing you the discriminator. (Scope mismatch.)

EXAM TRAP · Federal agency adjacency

The tempting confusion: CMS, AHRQ, HRSA and FDA in the same four options.

The deciding clue: FDA = devices and drugs. CMS = payment programs and their regulations. AHRQ = health services and quality research. HRSA = underserved areas and health center funding.

Stem wording that triggers it: One object per agency. If you cannot name the object, you will guess. (Adjacent role.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: The Joint Commission appears throughout the chapters in passing, always as an accreditor. The 4th edition uses National Patient Safety Goals (NPSGs).

Current practice (2026): Effective 1 January 2026, the Joint Commission replaced NPSGs with 14 National Performance Goals (NPGs) under the Accreditation 360 model, removing more than 700 elements of performance from the hospital program and adding nurse staffing as a goal. The source also does not cover the accreditation vs. certification distinction, sentinel event and root-cause-analysis obligations, tracer methodology, or the competing accreditors DNV, NCQA, URAC and AAAHC as a comparative set. Quality-measurement vocabulary absent from the source but current in practice: HEDIS, NCQA, Star Ratings, HCAHPS, and the Baldrige Performance Excellence framework.

Does it matter for the exam? Yes, and this is the highest stale-key risk in Chapter 1. If a stem uses National Patient Safety Goals, answer inside that frame. If a stem or distractor uses National Performance Goals, it is not a typo. Do not "correct" the exam — just do not let the newer term unseat you.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. In one sentence each, say who MAKES the rules, who CHECKS compliance with them, and who ADVOCATES for the professionals subject to them.
  2. Recite the association functions and the regulatory body functions as two separate lists. Both include continuing professional development — so what is the actual discriminator?
  3. Explain why a professional association investigating its own members is a regulatory act rather than an advocacy one.
  4. State exactly what deemed status gets you, then name three things people wrongly assume it gets you.
  5. Bind CMS, FDA, AHRQ and HRSA each to one object, out loud, without looking.

Questions

9 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Rationale for heavy oversight: importance of healthcare to quality of life, longevity, survival; expense of delivering care to large populations
  • Government concern over rising healthcare share of GDP weakening national economies; difficulty of reversal because citizens are accustomed to existing benefits
  • Peterson Kaiser tracker data: widening US-OECD gap over four decades; 1970 US ~6% of GDP vs. comparable-country average 5%; divergence beginning in the 1980s; 2017 US 17% of GDP vs. Switzerland 12%
  • Country responses: Australia chronic disease management via primary care; Canada privatization experimentation; Germany global budgeting and sickness fund competition; Japan long-term care room and board charges; UK pro-market reforms; US ACO development for better outcomes at lower cost
  • Balancing set named: quality, access, cost and safety
  • Regulators implement provisions of health laws through a more explicit system of regulations
  • HCPC: UK statutory regulator, 15 professions, nearly 290,000 professionals, maintains standards of proficiency and conduct
  • CMS: dominating US regulatory entity; drafts rules and finalizes regulations for federally subsidized programs; complex rulemaking with public engagement
  • FDA: evaluates and approves medical devices and new drugs; Health Canada Therapeutic Products Directorate regulates devices in Canada
  • Regulatory capacity is not exclusive to government — private-sector organizations, commissions and associations may act in a regulatory capacity
  • Merriam-Webster definition of a profession: a calling requiring specialized knowledge and often long and intensive academic preparation
  • Professional associations proliferated; many serve a semi-regulatory role; primary role is advocacy on behalf of members and promotion of the profession
  • Association functions: advocate with policy makers in members' interest; market and promote the profession; provide continuing professional development; represent members' interests by monitoring developments affecting scope of practice, employment opportunities and relationships with related professionals
  • Regulatory body purpose — protecting the public by regulating the profession; functions: set entry requirements; maintain a list of individuals eligible to practice; develop standards of practice; receive and investigate complaints and administer discipline; require participation in continuing professional development
  • Table 1.1 — clinical and administrative/IT professional associations (all 12 entries)
  • Associations exist for nearly every medical specialty, nursing and allied health profession, health administration and IT profession
  • AOs have substantial interaction with healthcare organizations and play a semi-regulatory role, often serving on behalf of federal organizations to ensure standards or conditions of participation are met
  • Joint Commission and JCI as most recognized AOs; JCI operates in more than 100 countries
  • CMS AOs determine compliance with Medicare CoP; deemed status permits billing CMS for covered services
  • Table 1.2 — all eleven CMS-approved accreditation organizations and their program types
  • Complexity of interrelationships among government, regulators, associations and AOs; Figure 1.3 physician assistant pathway example
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.

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).

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 · Source: Summary

L1.10 · Summary

Walkthrough

The source's own closing statement of what the chapter covered:

  1. The breadth of organizational structures in the public and private domains.
  2. The nature of their interactions.
  3. The roles of healthcare information and management systems professionals.
  4. The great number of governmental, regulatory, professional and accreditation organizations affecting healthcare delivery today.

The source acknowledges that the complexity of the processes can be overwhelming, then names the counterweight: advances in automation — specifically inexpensive data storage, increasing network capacities and simplified software programming tools — will let healthcare information and management systems professionals make life simpler for those who deliver care by transferring much of the information processing requirements to automated tools.

That closing sentence is a compact statement of the profession's purpose, and it is worth being able to paraphrase.

Big picture

Use this as your chapter self-check. If you cannot give a two-minute account of each of the four items above, the corresponding lesson is the one to revisit — not the whole chapter.

The three named enablers (cheap storage, network capacity, simpler programming tools) are also the bridge into Chapter 2, which takes each of them apart technically.

Key concepts

The three named enablers

In plain English: Why automating healthcare information got practical.

Technical meaning: Inexpensive data storage, increasing network capacities, and simplified software programming tools.

Picture it: Chapter 2 is essentially the technical expansion of these three.

Real-world examples

Distinctions & exam traps

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give a two-minute spoken account of each of the four things the summary claims the chapter covered. Any one you cannot do is your revisit target.
  2. Paraphrase the closing sentence about automation without using the source's words.

Questions

No canonical items map to the Summary. Use it as a coverage self-check before moving to Chapter 2.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Four things covered: breadth of organizational structures in public and private domains; nature of their interactions; roles of HIM/systems professionals; the great number of governmental, regulatory, professional and accreditation organizations
  • Acknowledgement that process complexity can be overwhelming
  • Three named automation advances: inexpensive data storage, increasing network capacities, simplified software programming tools
  • Stated purpose: transfer much of the information processing requirement to automated tools to make life simpler for care deliverers
Read the original source

Summary

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

SUPPLEMENTAL — NOT COVERED IN REVIEW GUIDE

Chapter 1 · Source: Learning Objective 5 (not expanded in the Chapter 1 body)

L1.11 · SUPPLEMENTAL -- Technology Trends and Patient Outcomes

Walkthrough

SUPPLEMENTAL — NOT COVERED IN THE REVIEW GUIDE CHAPTER 1 BODY.

Chapter 1's fifth learning objective names four technology trends — telemedicine, patient portals, wearable devices, population health — and then the chapter body never systematically teaches them. Blueprint task I.A.5 tests them anyway, and seven canonical items map here. This lesson is authored to close that gap and is marked supplemental so you never mistake it for source-derived content.

The four named trends

1. Telemedicine. The patient-outcome argument is access: it extends specialist access without requiring patient travel, which matters most in rural communities where the alternative is a long drive or forgoing care entirely. Note the boundaries — telemedicine supplements rather than replaces local primary care, does not reduce documentation burden, and does not replace in-person examination for all conditions.

2. Patient portals. The most direct patient engagement mechanism: patients view results and notes, request refills, message the practice, and schedule. The discriminating feature is who the user is. A data warehouse serves analysts. PACS serves clinicians. An interface engine serves systems. The portal serves the patient.

3. Wearable devices. Genuine contributions: continuous physiologic data between visits, patient self-monitoring of chronic conditions, and early deterioration signals enabling timely intervention. The boundary: wearable data is supplemental and does not constitute the legal medical record, which remains the organization's own documentation subject to retention, integrity and governance requirements a consumer device cannot meet.

4. Population health management. Manages health outcomes across a defined group rather than individual patients. The unit of analysis is the discriminator. Utilization review evaluates the appropriateness of individual services. Case mix index summarizes patient complexity for reimbursement. Revenue cycle management runs the financial lifecycle of individual encounters. Only population health operates at the group level.

The record triad — EMR, EHR, PHR

Test these on two axes: how many settings, and who controls it.

SettingsControlled by
EMROne care settingProvider
EHRMultiple settings, longitudinalProvider
PHRAcross providersThe patient — created, edited, maintained and controlled by the patient; may import clinical data from other sources

A CCD/C-CDA is neither — it is a transfer document, not a maintained record.

Matching a trend to an outcome

For scenario items, match the intervention to the time window the outcome lives in. Readmissions accumulate in the post-discharge window, so remote monitoring plus structured post-discharge follow-up acts directly on the target. PACS improves image access, which does not touch that window. Payroll and server capacity do not touch clinical outcomes at all.

Big picture

This lesson exists because of a documented fidelity gap, not because the source teaches it. Chapter 3 (Clinical Informatics) covers EHR/PHR and clinical systems in depth; Chapter 2 covers the infrastructure. What is genuinely missing from all nine chapters is the population health data layer — and it is worth knowing that, because it changes how you read a stem.

Adjacent concepts most likely to trip you here: who the user is (portal vs. warehouse vs. PACS vs. interface engine), unit of analysis (population vs. encounter vs. individual service), and clinical value vs. legal record standing (wearables).

Key concepts

Telemedicine (outcome argument)

In plain English: It collapses distance so patients can reach specialists.

Technical meaning: Extends specialist access without requiring patient travel; supplements rather than replaces local primary care; does not replace in-person examination for all conditions.

Picture it: Distractors here overclaim — 'eliminates the need for', 'replaces for all conditions'. The measured claim usually wins.

Patient portal

In plain English: The patient's own window into their care.

Technical meaning: Provides results and note viewing, refill requests, secure messaging and scheduling — the most direct patient engagement mechanism.

Picture it: Ask who touches the system before evaluating its merits.

Wearables — value vs. legal standing

In plain English: Clinically useful, legally not the record.

Technical meaning: Supplies continuous physiologic data between visits, supports chronic-condition self-monitoring and signals early deterioration — but does not serve as the legal source of the medical record.

Picture it: Data can be clinically useful and still fail to qualify as the legal record. The exam separates usefulness from governance standing repeatedly.

Population health management

In plain English: Managing outcomes for a group, not a patient.

Technical meaning: Manages health outcomes across a defined group rather than individual patients; the unit of analysis shifts from individual to population.

Picture it: 'Defined group rather than individual patients' in a stem is the discriminator.

PHR

In plain English: The record the patient owns and runs.

Technical meaning: Created, edited, maintained and controlled by the patient; may import clinical data from other sources. Distinct from the EMR (one setting, provider-controlled) and EHR (many settings, provider-controlled).

Picture it: Two axes decide every item in this triad: how many settings, and who controls it.

Real-world examples

A rural critical access hospital adds tele-neurology for stroke assessment. The outcome argument is not cost and not documentation — it is that a neurologist evaluates the patient inside the treatment window without the patient being transported first.

A heart failure program issues connected scales and runs structured seven-day post-discharge calls. Both interventions sit inside the window where readmissions actually occur, which is why this is the right answer to a readmission-reduction scenario and a PACS upgrade is not.

Distinctions & exam traps

EXAM TRAP · Overclaiming in technology items

The tempting confusion: Options stating absolutes — eliminates the need for local primary care, replaces in-person examination for all conditions.

The deciding clue: Technology items rarely have absolute answers. The measured claim usually wins.

Stem wording that triggers it: Scan for 'all', 'eliminates', 'replaces', 'never'. (Overclaiming.)

EXAM TRAP · Who is the user?

The tempting confusion: Data warehouse, PACS and interface engine all sound like patient-facing capability if you do not ask who touches them.

The deciding clue: Warehouse serves analysts and leadership. PACS serves clinicians reviewing images. Interface engine is invisible infrastructure. Only the portal serves the patient.

Stem wording that triggers it: 'Supports patient engagement' is a user question, not a capability question. (Wrong layer.)

EXAM TRAP · Clinical value vs. legal record

The tempting confusion: Assuming that because wearable data is clinically useful it can serve as the legal record.

The deciding clue: The legal record remains the organization's own documentation, subject to retention, integrity and governance requirements a consumer device cannot meet.

Stem wording that triggers it: On a NOT item listing three genuine contributions plus one governance claim, the governance claim is the answer. (Category outlier.)

EXAM TRAP · The EMR/EHR/PHR triad

The tempting confusion: Any of the three, plus a CCD, offered for a 'who controls it' question.

The deciding clue: EMR = one setting, provider-controlled. EHR = many settings, provider-controlled. PHR = patient-controlled. CCD = transfer document, not a maintained record.

Stem wording that triggers it: 'Created, edited, maintained and controlled by the patient' names the PHR outright. (Adjacent term.)

EXAM TRAP · One altered element in the trends list

The tempting confusion: Lists swapping exactly one outcome trend for an administrative or financial system — payroll, bed management, general ledger.

The deciding clue: The four named trends are telemedicine, patient portals, wearable devices, population health.

Stem wording that triggers it: Find the substituted item rather than reading each list whole. (One altered element.)

EXAM TRAP · Match the intervention to the window

The tempting confusion: Choosing a genuinely valuable technology that does not operate in the time window the outcome lives in.

The deciding clue: Readmissions accumulate post-discharge. Only an intervention inside that window can act on them.

Stem wording that triggers it: When a stem names an outcome with a time window, check each option against the window before judging its merit. (Plausible-but-wrong-stage.)

CURRENT PRACTICE / SUPPLEMENTAL

SUPPLEMENTAL / CURRENT PRACTICE (2026).

The population health layer that makes the fourth trend operable is absent from all nine chapters. If you want to answer practitioner-framed population health items confidently, know:

  • SDOH (social determinants of health) as the data layer beneath population health.
  • ICD-10-CM Z codes Z55-Z65, a subset of the Z00-Z99 "factors influencing health status" range, used to capture SDOH.
  • The Gravity Project, an HL7 FHIR Accelerator standardizing SDOH capture and exchange.
  • Validated screening instruments: PRAPARE and AHC-HRSN.

None of this is in the Review Guide. Treat it as practitioner background, not as source content.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the four trends and give each one a single-sentence patient-outcome argument.
  2. Explain the EMR/EHR/PHR difference using the two axes — how many settings, who controls it — without using the textbook phrasing.
  3. Argue why a smartwatch reading is clinically valuable but not part of the legal record.
  4. Take one outcome with a time window (readmissions, sepsis mortality, no-show rate) and say which trend acts inside that window and which ones do not.

Questions

7 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • SUPPLEMENTAL LESSON — authored to close a documented gap between Chapter 1's fifth learning objective and the chapter body
  • Four named trends from learning objective 5: telemedicine, patient portals, wearable devices, population health
  • Telemedicine access argument and its boundaries (supplement not replacement; documentation burden unaffected; not universal substitute for examination)
  • Patient portal capabilities and the who-is-the-user discriminator
  • Wearable contributions and the legal-record boundary
  • Population health unit-of-analysis discriminator vs. utilization review, case mix index, revenue cycle management
  • EMR / EHR / PHR two-axis distinction; CCD as a transfer document
  • Intervention-to-time-window matching for outcome scenarios
  • Current-practice SDOH layer flagged separately: Z55-Z65, Gravity Project, PRAPARE, AHC-HRSN
  • Q039 (drivers of the care setting shift) is source-derived and mapped to Lesson 1.3, not here

Chapter 2 · Source: Introduction

L2.1 · Introduction — The Three Components of the Technology Environment

Walkthrough

The chapter opens with the one list you must be able to recite cold. There are three components of the technology environment:

  1. Applications — the software used by administrative, clinical and support staff to process and store data, manage patients' records, provide information and knowledge.
  2. Hardware — the actual servers (virtual, cloud and physical), network connections and devices used to access and generate information.
  3. 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 source calls the listing simplistic but essential, and warns that the contents of each component change frequently: decreased access time and increased processor and hard drive speed let applications return processed data to the requesting clinician far more quickly. Technology changes are supporting — and changing — the applications and their functions. The illustrations in the chapter are explicitly not intended to be a complete listing.

Context the source establishes

  • Healthcare adopted IT more slowly than other industries, but the EHR is now essential in every facility that provides care — from population health to the intensive care unit.
  • Most hospitals and outpatient sites provide one wireless network for staff and a different network for family and visitors.
  • Institutions that once forbade employees from accessing social networks now employ staff to monitor and update social media sites.
  • Many patients maintain personal health records (PHRs) online plus patient portal access through the facility's EHR.

Big picture

Chapter 1 told you why information has to move. Chapter 2 tells you what it moves through. The three-component frame is the organizing spine for the whole chapter — software, then hardware, then networks — and the chapter is written in exactly that order.

Where it fits in the lifecycle: Chapter 5 (Design) assumes you know these components when it asks about compatibility and interoperability; Chapter 8 (Privacy and Security) assumes you know the network and device layer.

Adjacent concepts to keep straight: hardware includes virtual and cloud servers, not just physical ones. Candidates who picture only a data center get the definition wrong.

Key concepts

The three components

In plain English: Software, the boxes it runs on, and the wires between them.

Technical meaning: Applications (software for processing/storing data, managing records, providing information and knowledge); Hardware (virtual, cloud and physical servers, network connections, devices); Networks (wired or wireless connections linking infrastructure and enabling accessibility).

Picture it: A list item that substitutes 'databases', 'interfaces' or 'people' for one of the three is the one-altered-element trap.

Real-world examples

A hospital deploys a new medication administration workflow. Applications: the EHR's eMAR module. Hardware: workstations on wheels and barcode scanners. Networks: the wireless access points on the unit. Remove any one and the workflow stops.

Distinctions & exam traps

EXAM TRAP · The three components — one altered element

The tempting confusion: Lists that swap in 'databases', 'interfaces', 'people' or 'policies' for applications, hardware or networks.

The deciding clue: The named set is exactly applications, hardware, networks.

Stem wording that triggers it: Find the substituted item rather than reading all four lists whole. (One altered element.)

EXAM TRAP · Hardware is not only physical

The tempting confusion: Treating 'hardware' as meaning on-premise physical servers only.

The deciding clue: The source names virtual, cloud and physical servers in the same breath.

Stem wording that triggers it: An option restricting hardware to on-premise equipment is narrower than the source. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three components of the technology environment and define each in one sentence.
  2. Explain why the source insists all three are required, using one clinical workflow that fails if any single component is missing.

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Three components of the technology environment: applications (software to process/store data, manage records, provide information and knowledge); hardware (virtual, cloud and physical servers, network connections, devices); networks (wired or wireless connections linking infrastructure and enabling accessibility)
  • All three required for a healthcare facility to function; component contents change frequently
  • Decreased access time and increased processor/hard drive speed return processed data faster
  • Technology changes support and change applications and their functions; listings are illustrative, not complete
  • Healthcare slower than other industries to adopt IT; EHR now essential from population health to the ICU
  • Separate staff and visitor wireless networks; shift from banning to staffing social media
  • Patients maintain PHRs online and patient portal access through the facility EHR
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 · Source: Software in Healthcare IT > Clinical Applications

L2.2 · Software — Clinical Applications

Walkthrough

Software provides the face of healthcare IT. Hardware is not typically visible to end users; the applications running on it are. End users interact through interfaces ranging from mobile devices to voice-enabled assistants.

The record triad — EMR, EHR, PHR

The source is explicit that these terms seem interchangeable when in fact they have different meanings:

TermScopeControlled by
EMRThe continuous, longitudinal electronic record in one specific setting — a provider's office, a hospital, or a home healthcare serviceProvider
EHRA longitudinal record covering multiple settings over timeProvider
PHRA medical record often created, edited, maintained and controlled by the patient, possibly including importation of clinical data from other sources; often created online and accessible by providers when the patient invites them using secure accessPatient

The EHR

Clinical applications support patient care wherever it is being delivered. The most apparent one is the EHR. In some institutions it 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 patient care — from medication administration to order entry — and to retrieve patient data from the lab or radiology. The provider's office can send electronic prescriptions to the patient's pharmacy and 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 clinical and operational activities. The data points driving these prediction models range from vital signs and lab results to the number of no-shows for outpatient visits. Enterprise EHRs can also include population health capabilities, clinical specialty modules and integration with outside regulatory and public health systems.

Specialty interfaces and regulators

The EHR interfaces with specialized systems in different departments. Named oversight bodies for radiology and pathology in the US: Clinical Laboratory Improvement Amendments (CLIA), the College of American Pathologists (CAP) and the American College of Radiology. In Europe, European Cooperation for Accreditation covers laboratory certifications. Professional dietitians, case managers and social workers all have specific software functionality needs, often dictated by professional or regulatory standards.

Clinical areas with specialized documentation and information needs named by the source:

  • Perinatal — labor and delivery, nursery, neonatal intensive care, postpartum
  • Perioperative — preoperative unit, operating rooms, post-anesthesia care unit
  • Critical care units
  • Outpatient centers for primary care
  • Special functions such as renal dialysis

PACS

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 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 — interoperability. The source states it plainly: data should not be entered into systems more than one time.

What point-of-care data availability changed

  • Clinicians no longer go to the radiology department to look at MRIs or CT scans; images are available in the EHR — saving time and money, since there are no films to create, store or retrieve.
  • Perinatal systems archive fetal monitor strips electronically, saving thousands of dollars in paper fetal strip storage charges.

Big picture

This is the section that supplies the vocabulary the exam uses for the rest of Section I and much of Section II. The EMR/EHR/PHR triad appears in both Chapter 1's supplemental trends material and here, in the source proper — this is where it is actually taught.

Where it fits: Chapter 3 takes clinical applications much deeper (CPOE, CDS, terminologies). Chapter 5 asks how you design for compatibility across exactly these specialty systems.

Nearby concepts likely to be confused: PACS (stores and displays images) vs. an interface engine (routes data between systems) vs. a data warehouse (consolidates for query). Three different jobs, three different answers.

Key concepts

EMR vs. EHR

In plain English: One setting versus many settings.

Technical meaning: EMR = the continuous, longitudinal electronic record in one specific setting. EHR = a longitudinal record covering multiple settings over time.

Picture it: The discriminator is the number of settings, not the sophistication of the software.

PHR

In plain English: The record the patient runs.

Technical meaning: Often created, edited, maintained and controlled by the patient; may import clinical data from other sources; providers see it when the patient invites them using secure access.

Picture it: Patient control is the defining attribute — not where it is hosted.

PACS

In plain English: The imaging library.

Technical meaning: Picture archiving and communication system — stores and displays images from ultrasounds to CT scans and MRIs; requires fine-resolution monitors, large storage drives, good bandwidth and large amounts of RAM.

Picture it: Expand the acronym exactly: Picture Archiving and Communication System.

Best of breed vs. single vendor

In plain English: One system that does everything, or many specialists stitched together.

Technical meaning: 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, requiring purchase and interface of niche systems per specialty.

Picture it: Best of breed buys depth and pays for it in interfaces.

Real-world examples

A radiologist reads a CT in PACS; the report flows to the EHR; the ordering hospitalist sees it without leaving the unit. The source's point is the money as much as the minutes — no film to create, store or retrieve.

An enterprise EHR flags a patient as high risk using vital signs, lab results and outpatient no-show counts. All three are the source's named prediction-model data points, and the last one is the surprising one.

Distinctions & exam traps

EXAM TRAP · EMR vs. EHR vs. PHR

The tempting confusion: Any of the three can look right if you only read half the stem.

The deciding clue: EMR = one setting, provider-controlled. EHR = multiple settings, provider-controlled. PHR = patient-created, edited, maintained and controlled.

Stem wording that triggers it: 'One specific setting' names the EMR outright; 'controlled by the patient' names the PHR. (Adjacent term.)

EXAM TRAP · PACS vs. interface engine vs. data warehouse

The tempting confusion: All three are real infrastructure and all three sound plausible for a 'which system' stem.

The deciding clue: PACS stores and displays images. An interface engine connects systems and matches data to the right patient. A warehouse consolidates data from many sources for querying.

Stem wording that triggers it: Match the verb in the stem — 'stores and displays images', 'connects', 'queried together'. (Adjacent role.)

EXAM TRAP · Acronym expansion precision

The tempting confusion: Near-miss expansions of PACS such as 'patient archiving' or 'picture access and communication'.

The deciding clue: Picture Archiving and Communication System — every word matters.

Stem wording that triggers it: Acronym items change exactly one word. Scan word by word. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define EMR, EHR and PHR in your own words on two axes: how many settings, and who controls it.
  2. Expand PACS and say what hardware it demands and why.
  3. Explain the trade-off between a single-vendor EHR and a best-of-breed approach to someone who has never bought software.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Software is the visible face of healthcare IT; interfaces range from mobile devices to voice-enabled assistants
  • EMR = continuous, longitudinal electronic record in one specific setting (provider's office, hospital, home healthcare service)
  • EHR = longitudinal record covering multiple settings over time
  • PHR = often created, edited, maintained and controlled by the patient; may import clinical data from other sources; often created online; accessible to providers when the patient invites them via secure access
  • EHR as one-vendor or best-of-breed; used for documentation from medication administration to order entry; retrieval of lab and radiology data; e-prescribing to the patient's pharmacy; import/export via HIE
  • EHR algorithms for stratifying clinical and operational activities; prediction data points including vital signs, lab results, outpatient no-show counts
  • Enterprise EHR population health capabilities, clinical specialty modules, integration with outside regulatory and public health systems
  • Specialty department interfaces; CLIA, CAP, American College of Radiology (US); European Cooperation for Accreditation (Europe); dietitian, case manager, social worker functionality needs
  • Specialized clinical areas: perinatal (labor and delivery, nursery, NICU, postpartum); perioperative (preoperative, operating rooms, PACU); critical care; outpatient primary care centers; renal dialysis
  • PACS stores and displays images (ultrasound, CT, MRI); requires fine-resolution monitors, large storage drives, good bandwidth, large amounts of RAM
  • Niche specialty system purchase and interface when the EHR vendor does not cover the area
  • Goal of all systems is interoperability; data should not be entered more than once
  • Point-of-care image availability eliminates trips to radiology and film creation/storage/retrieval costs; perinatal systems archive fetal monitor strips electronically
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 · Source: Administrative Applications; Financial Applications

L2.3 · Software — Administrative and Financial Applications

Walkthrough

Administrative applications

These provide support for clinicians as well as administrative staff. The source's named examples:

  • electronic time cards
  • intranet
  • payroll
  • staff competency record keeping
  • educational applications
  • 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, and are very helpful in getting patients into a room as soon as possible
  • equipment-tracking applications using radio frequency identification (RFID) technology, saving staff time spent hunting for needed equipment
  • web-based applications permitting staff to bid for understaffed shifts, reducing overtime labor costs and increasing staff satisfaction — as do self-scheduling systems

Financial applications

Financial applications cover all the features of any organization's financial needs, but with more variables than most businesses. They are needed from the solo provider's office to the multihospital, multi-provider health system.

Multiple regulations govern how billing can be done, how bills are submitted, and the details required — diagnosis codes, providers' licenses and billing numbers.

Named functions:

  • charge posting via both orders and manual charge entry
  • payment posting and billing based on the providers
  • insurance, coinsurance and deductibles in the calculations
  • revenue codes, supplies, tests and medications
  • distinguishing items that require a provider's order and cannot be billed without one from items that do not require an order
  • statements to patients and claims to insurance companies

These billing systems are commonly referred to as practice management systems.

Other financial components the source names:

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

Big picture

The exam uses this section for classification questions: given an application, which of the four families does it belong to? Administrative supports running the organization. Financial moves money. Clinical touches the patient's care. Consumer faces the patient.

Where it fits: Chapter 4 (Analysis) revisits these same families when categorizing needs; Chapter 9 uses financial vocabulary in the business case and budgeting material.

Nearby concept most likely to be confused: bed management, scheduling and time cards are administrative, not clinical, even though clinicians use them. Who uses it is not the same as what family it belongs to.

Key concepts

Administrative applications

In plain English: The systems that run the organization, not the care.

Technical meaning: Electronic time cards, intranet, payroll, staff competency records, educational applications, staff and patient scheduling, bed management, RFID equipment tracking, shift-bidding and self-scheduling.

Picture it: Bed management involves housekeeping and transport as well as clinicians — it is still administrative.

Practice management system

In plain English: The billing system.

Technical meaning: The common name for healthcare billing systems handling charge posting, payment posting, provider-based billing, insurance/coinsurance/deductibles, revenue codes, statements and claims.

Picture it: If a stem describes claims and statements, it is describing a practice management system.

RFID equipment tracking

In plain English: Tags that tell you where the infusion pump is.

Technical meaning: Radio frequency identification technology used in equipment-tracking applications, saving staff time spent hunting for needed equipment.

Picture it: The named technology is RFID specifically — not barcode, not Wi-Fi triangulation.

Real-world examples

A nurse manager posts an understaffed night shift to a web-based bidding application. Overtime cost falls and satisfaction rises — the source names both outcomes explicitly.

A charge for an implant posts from the OR order; a charge for a self-administered item posts manually. The practice management system has to know which items require an order before they can be billed.

Distinctions & exam traps

EXAM TRAP · Administrative vs. clinical classification

The tempting confusion: Classifying time cards, payroll, bed management or scheduling as clinical because clinicians use them.

The deciding clue: The family is defined by what the application does for the organization, not who touches it.

Stem wording that triggers it: 'Electronic time cards, payroll and bed management' is a pure administrative triad. (Wrong layer.)

EXAM TRAP · What financial applications do not do

The tempting confusion: A NOT item offering a genuinely real function that belongs to a different family — clinical documentation, order entry, results reporting.

The deciding clue: Financial handles charge posting, payment posting, billing, insurance calculations, revenue codes, statements and claims.

Stem wording that triggers it: On a NOT item, find the option from a different taxonomy entirely. (Category outlier.)

EXAM TRAP · The named tracking technology

The tempting confusion: Substituting barcode, Bluetooth or GPS for RFID in equipment tracking.

The deciding clue: The source names radio frequency identification.

Stem wording that triggers it: Technology-identification items change one named technology. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Sort ten applications from your own organization into clinical, administrative, financial and consumer without hesitating.
  2. Explain why bed management is administrative even though it is full of clinicians.
  3. Say what a practice management system does in one sentence, then name three things it must calculate.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Administrative applications support clinicians and administrative staff: electronic time cards, intranet, payroll, staff competency record keeping, educational applications, staff shift and patient procedure/visit scheduling
  • Bed management systems include housekeeping and patient transportation staff as well as clinicians; speed room placement
  • RFID equipment-tracking applications save staff time hunting for equipment
  • Web-based shift-bidding applications reduce overtime labor costs and increase staff satisfaction, as do self-scheduling systems
  • Financial applications span solo provider offices to multihospital multi-provider systems; more variables than most businesses
  • Regulations govern billing method, submission and required details: diagnosis codes, providers' licenses and billing numbers
  • Functions: charge posting via orders and manual entry; payment posting; provider-based billing; insurance, coinsurance and deductibles; revenue codes, supplies, tests, medications; order-required vs. non-order-required items; patient statements and insurance claims
  • Billing systems are commonly referred to as practice management systems
  • General ledger tracks charges, bills and payments
  • Payroll accepts electronic time card data; matches regular and overtime hours; calculates overtime pay, holiday bonuses, shift differentials, certification wages; tracks paid time off earnings usually based on hours worked
  • Accounts payable must be in sync; financial systems must communicate in real time
  • Supply chain must include all supply purchasing methods and invoice payment, correctly linked
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 · Source: Consumer Applications; Clinical Business Intelligence (CBI) and Analytics

L2.4 · Software — Consumer Applications and Clinical Business Intelligence

Walkthrough

Consumer applications

Consumers are increasingly involved in electronic records and their patient health information, and not infrequently request electronic versions of their charts. The source states the ownership question directly: 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, which permits the patient to:

  • view test results and clinical notes
  • ask for prescription refills
  • send the provider or office staff a secure e-mail
  • schedule an appointment

Some portals also permit patients to add comments or request amendments to their EHR.

Stand-alone PHRs

Some PHRs are stand-alone and not connected with an institution's EHRweb based, an application installed on the user's computer, or a mobile app.

  • In the US, CMS encourages the use of PHRs and provides a link to Blue Button, a PHR initiative that originated through the Veterans 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.
  • PHRs are becoming very popular in Europe, the United Kingdom and Scandinavia; vendor promotion is increasing across Europe, the UK and China.
  • Some organizations partner with web-based PHR vendors and upload records into patients' PHRs; some healthcare insurers also let patients create a PHR from their websites.

California Health Care Foundation (CHCF) survey findings:

  • PHRs actually support patients in improving their own health.
  • Caregivers 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 their physician or insurer provides.
  • Security is the major stumbling block to PHR adoption — patients look for evidence that information they enter is completely secure.
  • Patients found that after establishing a PHR through an insurer or third party, information could not easily be transferred to a different PHR, forcing re-entry.

PHR use has increased with the medical home and accountable care platforms, which provide incentives for keeping patients healthy, and with in-home health monitoring systems and wearable devices.

The UK Summary Care Record

The NHS Summary Care Record (SCR) is an electronic summary of key clinical information — including medicines, allergies and adverse reactions — sourced from the general practitioner (GP) record. It is used by authorized healthcare professionals, with the patient's consent. If you are registered with a GP practice in England, your SCR is created automatically unless you have opted out; 98% 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. In addition to the SCR, the Spine includes:

  • the Personal Demographics Service (PDS), storing demographic information about each patient and their NHS numberpatients cannot opt out of this component;
  • 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.

Electronic communication and record access

  • Patients are very interested in communicating electronically with providers; doctors are far behind the rest of the world in using electronic communications.
  • Most patient issues can be addressed by office staff, leaving only a few for the physician or nurse practitioner.
  • Both sides of the communication have to be secure; web-based and application-driven tools provide security and convenience where providers lack the skill.
  • The requirement to provide "human-readable" medical records in electronic format is very new to healthcare. Previously patients went to HIM, completed paperwork and often paid a per-page fee.
  • In the US, Stage 1 of CMS Meaningful Use requires a copy of the medical record be available to the patient within 24 hours of the request — deliverable on a flash drive or pushed out through an existing patient portal.

Clinical Business Intelligence (CBI) and analytics

Per 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." The source adds that quality in healthcare is being shaped by evidence-based medicine and the proper utilization of data.

Named uses:

  • improving patient safety and patient care
  • analyzing operating room use and staff overtime patterns
  • predictive analytics
  • documenting trends in patients' conditions, improvements in patients' status, and population health outcomes

Organizations implement CBI either by using specific applications or by constructing data warehouses.

Big picture

This section is where the source teaches patient-facing technology, and it is the natural anchor for portal and engagement questions. Note that the four-word CBI definition — collection, integration, analysis and presentation — is a named list and is exactly the kind of thing a multi-element item is built from.

Where it fits: Chapter 3 covers clinical decision support as a clinical function; CBI here is the analytics layer that informs it. Chapter 9 uses the same analytics vocabulary for benchmarks and KPIs.

Nearby concepts to keep straight: a patient portal is tethered to an institution's EHR; a stand-alone PHR is not. Both are consumer applications.

Key concepts

Patient portal

In plain English: The patient's door into the provider's record.

Technical meaning: A feature of most EHRs permitting patients to view test results and clinical notes, request prescription refills, send secure e-mail to the provider or office staff, and schedule appointments; some allow comments or amendment requests.

Picture it: Four named capabilities. An 'all of the above' item listing them is a genuine aggregator.

Clinical Business Intelligence (CBI)

In plain English: Turning clinical data into better decisions.

Technical meaning: Per the HIMSS CBI Committee: technologies, applications and practices for the collection, integration, analysis and presentation of clinical information, for the purpose of better clinical decision-making.

Picture it: Four verbs in order: collection, integration, analysis, presentation.

NHS Spine

In plain English: The UK's national record plumbing.

Technical meaning: A set of national services used by the NHS Care Record Service, including the Summary Care Record, the Personal Demographics Service (no patient opt-out) and the secondary uses service (anonymized/pseudonymised reporting).

Picture it: The opt-out asymmetry is the testable detail: you can opt out of the SCR, not the PDS.

Real-world examples

A patient with three chronic conditions and a family caregiver uses a PHR to hold medications, allergies and results across four practices. The CHCF finding is that for exactly this caregiver case, the PHR was described as almost a necessity.

An analytics team pulls OR turnover times and nursing overtime from the warehouse. Both are named CBI uses, and neither is direct patient care — which is why CBI is its own application family.

Distinctions & exam traps

EXAM TRAP · Portal capabilities aggregator

The tempting confusion: Assuming one listed portal capability must be the single best answer.

The deciding clue: The source names viewing results and notes, refill requests, secure messaging and scheduling as portal functions together.

Stem wording that triggers it: Confirm at least two options independently, then take 'all of the above'. (The aggregator.)

EXAM TRAP · CBI definition — one altered element

The tempting confusion: Lists that swap 'presentation' for 'storage', or 'integration' for 'validation'.

The deciding clue: Collection, integration, analysis and presentation of clinical information for better clinical decision-making.

Stem wording that triggers it: Definitional list items change exactly one verb. (One altered element.)

EXAM TRAP · Portal vs. stand-alone PHR

The tempting confusion: Treating the two as the same thing because both are patient-facing.

The deciding clue: A portal is provided through the institution's EHR. A stand-alone PHR is not connected to an institution's EHR and gives the patient full control of contents.

Stem wording that triggers it: 'Not connected with an institution's EHR' names the stand-alone PHR. (Adjacent term.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: Meaningful Use Stage 1 and its 24-hour record-copy requirement; Blue Button as the US PHR initiative.

Current practice (2026): Patient access is now governed by the 21st Century Cures Act information blocking rule rather than Meaningful Use stages, which were succeeded by Promoting Interoperability and, for clinicians, MIPS. Portal-based access to notes and results is the default rather than a stage requirement, and API-based access under SMART on FHIR replaces flash-drive delivery in practice.

Does it matter for the exam? The 4th-edition source frames access as a Meaningful Use requirement, and 21st Century Cures and information blocking appear zero times across all nine chapters. Answer Meaningful Use stems in the Meaningful Use frame.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. List the four things a patient portal lets a patient do, without looking.
  2. Give the HIMSS CBI definition in your own words, keeping all four verbs in order.
  3. Explain the difference between a patient portal and a stand-alone PHR, and say why security was the CHCF-identified barrier to adoption.
  4. Describe the NHS Spine and say which component a patient cannot opt out of.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Consumers increasingly involved in electronic records; frequent requests for electronic chart copies; record ownership decided in the patient's favor
  • Patient portal capabilities: view test results and clinical notes; request prescription refills; secure e-mail to provider or office staff; schedule appointments; some allow comments or amendment requests
  • Stand-alone PHRs: web based, installed application or mobile app; CMS encouragement; Blue Button originating through the Veterans Administration; National Committee on Vital and Health Statistics guidance
  • Web-based PHRs give patients full control of contents; import of prescription history from national drug store chains and lab results
  • PHR popularity in Europe, the UK and Scandinavia; vendor promotion across Europe, the UK and China; organization and insurer partnerships
  • CHCF survey: PHRs support patients improving their own health; caregivers found them almost a necessity for family members with multiple chronic conditions; most patients want PHRs their physician or insurer provides; security is the major adoption barrier; portability between PHRs is poor, forcing re-entry
  • PHR growth with medical home and accountable care platforms and with in-home monitoring and wearable devices
  • NHS Summary Care Record: key clinical information including medicines, allergies and adverse reactions sourced from the GP record; used by authorized professionals with patient consent; automatic creation in England unless opted out; 98% of practices
  • The Spine as national services for the NHS Care Record Service; Personal Demographics Service (demographics and NHS number, no opt-out); secondary uses service (anonymized/pseudonymised reports and statistics for research, planning and public health delivery)
  • Patient interest in electronic communication; providers behind; most issues addressable by office staff; both sides must be secure; web-based and application-driven tools available
  • Human-readable electronic record requirement is new; prior paper request process with per-page fees; CMS Meaningful Use Stage 1 24-hour availability; delivery by flash drive or patient portal
  • HIMSS CBI Committee definition: technologies, applications and practices for the collection, integration, analysis and presentation of clinical information for better clinical decision-making; quality shaped by evidence-based medicine and proper data utilization
  • CBI uses: patient safety and care improvement, operating room use and staff overtime analysis, predictive analytics, condition trends, status improvement, population health outcomes
  • CBI implemented via specific applications or constructed data warehouses
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

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 · Source: Hardware in Healthcare IT

L2.5 · Hardware — Infrastructure, Servers, Storage, Mobile and Medical Devices

Walkthrough

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. Named integral parts: physical routers, switches, and virtual and physical servers. Firewalls — both physical and software based — along with virus scanning systems, protect the network from unauthorized access and maintain security of the information in the system.

Servers

The image of a data center full of servers is no longer completely accurate. Most healthcare IT departments have virtual, physical and cloud servers. Which application goes on which type is determined by the vendors' recommendations and 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 provides alternative cost-effective options for organizations lacking space, resources, or the desire to house and maintain data in-house.

Data storage

  • Regulations govern how long patient data must be maintained, depending on the type of patient. Many organizations are simply resigned to keeping charts forever.
  • With paper records that means large amounts of money to store stacks of paper that will probably never be looked at again.
  • Historically most organizations stored paper charts off-site and ordered them when needed, adding transportation costs to record-keeping costs.
  • Some health systems scan paper charts and then appropriately dispose of 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, which can provide room even when 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.

  • Workstations on wheels (WOWs) with wireless access, plus smaller handheld devices.
  • WOWs can be configured for end-user needs: drawers for storage, holders for barcode medication scanners, locked drawers for security of medications; or with no drawers or scanners for outpatient clinics; or with medical devices mounted on them.
  • While standardization may be a goal, one documentation device will likely not meet every area or end-user need.
  • Smartphones are one of the most popular handheld devices; most EHR vendors have updated their applications for handheld devices.
  • Touchscreen devices are being configured for healthcare, with attention to infection control while using equipment touched by gloved hands. Several devices, such as MRI scanners, employ touchscreens to program examinations and review images.

BYOD security. A major concern with any handheld device connecting to the institution's network is security, especially when end users bring their own devices (BYOD). Before permitting personal device use in clinical areas, establish a policy to ensure:

  1. protected health information (PHI) is safe;
  2. the institution can wipe a device clean if it is compromised;
  3. passwords are required to access the device.

The decision to permit data storage on a personal device must depend on maintenance of the data's security.

Medical devices

Many physiologic devicescardiac monitors, ventilators, some IV fluid pumps, medication pumps and vital sign monitors — can send out the data they obtain, often in Health Level Seven (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 can translate it 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 conduct tests and export information to the EHR.
  • Radiologic images are typically stored in a PACS and viewed via a link from the EHR to the image in PACS or an enterprise imaging system.

Regulation of medical devices:

  • United States — the FDA regulates medical devices. IT must be aware of FDA laws and regulations applying to IT-supported hardware and software. FDA coverage includes radiologic images, any display of physiologic data such as heart rhythms, fetal monitor tracings, ventilator or heart waveforms, any implantable device such as an automatic cardiac defibrillator, and mobile medical apps — for example, applications displaying fetal heart tracings or cardiac waveforms on physicians' cell phones.
  • The institution's biomedical engineering department must work closely with IT to maintain these systems.
  • 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.
  • Russia — the Ministry of Public Health and Social Development of the Russian Federation controls medical devices.
  • The WHO publishes extensive medical device requirement information; per WHO, "65% of 145 countries have an authority responsible for implementing and enforcing medical device specific product information."
  • There is discussion that the European Commission's device regulations are not strong enough to really protect patients.

Big picture

Hardware is the layer the exam tests indirectly — through security (BYOD), through regulation (FDA), and through integration failures. The most examinable idea here is that connecting physically is not the same as being compatible, which Chapter 5 then makes the centerpiece of its design discussion.

Where it fits: Chapter 5 asks you to route device purchases through IT review for exactly the reasons this section describes. Chapter 8 takes the BYOD policy requirements much further.

Nearby concepts to keep straight: FDA regulates medical devices, including mobile medical apps — not the EHR generally, and not the network.

Key concepts

BYOD policy requirements

In plain English: Three things you must settle before staff use their own phones.

Technical meaning: PHI must be safe; the institution must be able to wipe a compromised device; passwords must be required for device access. Permitting data storage on a personal device depends on maintaining data security.

Picture it: The greatest concern named by the source is security of PHI on the personal device, not battery life or app compatibility.

Workstation on wheels (WOW)

In plain English: A rolling computer cart configured per unit.

Technical meaning: Wireless-access mobile workstations configurable with storage drawers, barcode medication scanner holders, locked medication drawers, or mounted medical devices — and configurable without them for outpatient areas.

Picture it: The source's point: standardization is a goal, but one device will not meet every area's needs.

Medical device data flow

In plain English: Monitors can talk to the chart — but a human has to confirm it.

Technical meaning: Physiologic devices send data, often in HL7 format, directly to preconfigured EHR fields or through a third-party translating device. Clinician validation is required before data is permanently stored in the EHR.

Picture it: Automation reduces transcription error; it does not remove the clinician from the loop.

FDA medical device scope

In plain English: Anything that measures or displays the body, including phone apps.

Technical meaning: In the US the FDA regulates medical devices, radiologic images, displays of physiologic data (heart rhythms, fetal monitor tracings, ventilator and heart waveforms), implantable devices such as automatic cardiac defibrillators, and mobile medical apps.

Picture it: A fetal heart tracing on a physician's cell phone is an FDA-regulated mobile medical app.

Real-world examples

A cardiac monitor streams vitals into the flowsheet in HL7. The nurse still has to validate the values before they are permanently filed — the source requires it, and the exam can test it.

A hospital lets physicians use personal iPhones. The policy must answer: is PHI protected, can we remote-wipe, and is a device password enforced. If any answer is no, the source says do not permit it.

Distinctions & exam traps

EXAM TRAP · BYOD — the greatest concern

The tempting confusion: Options naming cost, device diversity, support burden or battery life as the primary BYOD concern.

The deciding clue: The source names security — specifically the safety of PHI on a device the organization does not own.

Stem wording that triggers it: 'Greatest security concern' in a stem points to PHI exposure, not operational inconvenience. (Wrong layer.)

EXAM TRAP · Physical connection vs. compatibility

The tempting confusion: Assuming a device that joins the network successfully is integrated with the EHR.

The deciding clue: A new patient monitor may connect physically and still be incompatible with the aggregation system that distributes waveform data to the EHR.

Stem wording that triggers it: 'Connects to the network but cannot send data to the EHR' is a compatibility/interoperability failure, not a network failure. (Wrong layer.)

EXAM TRAP · Who regulates the device

The tempting confusion: Assigning device regulation to CMS, the Joint Commission or the EHR vendor.

The deciding clue: In the US it is the FDA — including mobile medical apps.

Stem wording that triggers it: Bind each body to one object before reading the options. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three things a BYOD policy must establish before personal devices are allowed in clinical areas.
  2. Explain to a biomed colleague why a device that connects to the network may still not be integrated.
  3. List what the FDA covers in this chapter — and include the surprising one.
  4. Explain why clinician validation is still required when a monitor auto-populates the flowsheet.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Hardware stores data, runs applications and connects them; physical routers, switches, virtual and physical servers; physical and software firewalls and virus scanning systems protect the network and maintain information security
  • Most IT departments have virtual, physical and cloud servers; placement determined by vendor recommendations and organizational support capability; servers among the most expensive equipment; cloud computing as a cost-effective alternative for organizations lacking space, resources or desire to host in-house
  • Retention regulations vary by patient type; many organizations keep charts forever; paper storage cost; off-site storage and retrieval transportation costs; scanning and disposal practice; EHRs reduced or eliminated paper chart storage; storage/backup/archive shifting to the cloud as needs may double every few years
  • Hardware designed to support clinical workflow; portable devices and wireless connectivity; workstations on wheels with configurable drawers, barcode scanner holders, locked medication drawers, no-drawer outpatient configurations, mounted medical devices
  • Standardization is a goal but one documentation device will not meet every area or user need
  • Smartphones as popular handhelds; most EHR vendors updated for handhelds; touchscreens configured for healthcare with infection control attention for gloved hands; MRI scanners use touchscreens to program exams and review images
  • BYOD security policy requirements: PHI safety, ability to wipe a compromised device, required device passwords; data storage on personal devices contingent on maintaining data security
  • Physiologic devices (cardiac monitors, ventilators, some IV fluid pumps, medication pumps, vital sign monitors) send data often in HL7 format; integration decreases data entry and transcription errors and saves time; direct preconfigured fields or third-party translation; clinician validation required before permanent EHR storage
  • Laboratory devices export test information to the EHR; radiologic images stored in PACS and viewed via EHR link to PACS or enterprise imaging
  • US FDA regulates medical devices, radiologic images, physiologic data displays (heart rhythms, fetal monitor tracings, ventilator/heart waveforms), implantable devices such as automatic cardiac defibrillators, and mobile medical apps
  • Biomedical engineering must work closely with IT
  • EU Parliament and Council directives for medical devices and in vitro diagnostics; Canadian and Japanese medical device regulations; Russian Ministry of Public Health and Social Development; WHO publications; WHO figure that 65% of 145 countries have an authority responsible for medical device specific product information; debate over strength of European Commission device regulations
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 · Source: Networks in Healthcare IT; Communications; Interoperability and Standards

L2.6 · Networks, Communications, Interoperability and Standards

Walkthrough

Network infrastructure

The network, while still dependent on network cables, is increasingly connected using wireless points. Putting information at the point of care requires wireless access points, not physical wires. Clinicians do not accept going to the patient's room and back to the nurse's station to log in and retrieve results; providers can now take the electronic chart into the room to review lab results, x-ray reports and other tests with the patient.

Named network technologies:

  • Virtual private networks (VPNs)
  • Voice over Internet protocol (VoIP) using fiber-optic and coaxial cables and supporting protocols, governing the connection of routers and switches
  • Local area networks (LANs) using Ethernet and a token ring
  • Wide area networks (WANs) using multiprotocol label switching (MPLS) or asynchronous transfer mode (ATM)

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.

Cabled access

Cabled access is more reliable and faster. Many institutions already have cable installed before wireless was within price and speed range. Clinical, administrative and support services usually have hardwired desktop computers. Some outpatient providers install a desktop or fixed device in each patient exam room. Specific clinical areas such as radiology examination rooms need larger, high-resolution monitors and high-speed graphic cards supporting detailed images. Hardware devices in patient care areas have to be cleaned with appropriate cleansing agents.

Regulatory context: guidelines, rules and standards require documentation about patients, the care given and procedures. One of the major requirements of an EHR is that it must support the documentation, order entry and lab results reporting required by regulations, professional standards and patient need. Ideally care is documented when and where it is provided, thereby reducing errors.

Communications

Many data communication protocols and media are available — from the standard telephone landline with conferencing and video capabilities to devices using VoIP and broadband access. Data communication protocols allow information to transmit from one point or media to another.

  • Some devices look like ordinary cell phones; some are clip-on, hands-free phones worn by staff.
  • Infection control is a major concern; materials need to be antibacterial and cleanable.
  • Some devices send and receive text messages, but 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 protocols: broadband access, Ethernet and Wi-Fi.

Interoperability and standards

An important facet of all healthcare IT applications is the use of standards. The named standards:

StandardWhat it is / does
HL7An international standard interface language used in healthcare
HL7 FHIRA next-generation standards framework leveraging the latest web standards
DICOMThe standard for images
SNOMED CTThe most comprehensive multilingual clinical healthcare terminology in the world
ICDProvides diagnosis codes for most disease conditions
CPTUS current procedural terminology codes

In the US, ICD and CPT codes classify patients' diagnoses and the procedures they had and provide a link between each procedure and the diagnosis that required it. In France, the International Society for Pharmacoeconomics and Outcomes Research (ISPOR) has developed charge codes for providers, including correct prices chargeable for a specific procedure. These codes can be entered by clerical staff as well as providers and largely determine whether an institution or provider receives the maximum or the minimum reimbursement.

The source's interoperability definition:

"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."

Both halves matter: exchange AND interpret; movement with meaning preserved and unaltered.

Without standards, interoperability is impossible. The source's image: healthcare IT would most resemble the Tower of Babel, with no system or device speaking the same language, resulting in duplicative effort and work from clinical and administrative staff as well as patient safety concerns. US 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.

Terminologies. Nursing and other disciplines' terminologies can be used by nurses and other providers, including physicians, to document care. Standardizing terms affects all parts of healthcare and especially impacts quality reporting. Standard words improve data, research and natural language processing (NLP), since it is clear what the terms mean.

Challenges. There are challenges to EHR interoperability worldwide. The integration effort in Europe is improving adoption chances and needs to move quickly, as the number of specialty systems is increasing — specialty systems often intended for one discipline only, moving away from an integrated EHR.

Big picture

This is the highest-yield section in Chapter 2. The exam builds items out of two things here: sorting standards by job, and the consequence of having no standards.

Sort them and they stop blurring: HL7 and FHIR move messages and resources. DICOM moves images. SNOMED CT, ICD and CPT supply vocabulary and codes. A "standard" that belongs to none of those jobs — a network protocol, an operating system, a device brand — is the outlier on a NOT item.

Where it fits: Chapter 1 introduced C-CDA and the transmission-vs-interoperability distinction. Chapter 2 supplies the full standards set. Chapter 3 uses the terminologies clinically. Chapter 5 makes standards compliance a design obligation.

Key concepts

Interoperability (Chapter 2 definition)

In plain English: Both systems can move the data AND understand it the same way.

Technical meaning: The extent to which systems and devices can exchange data and interpret that shared data; 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.

Picture it: Two clauses: exchange and interpret. An option covering only exchange is incomplete.

Sorting the standards

In plain English: Messages, images, vocabulary — three different jobs.

Technical meaning: HL7 = international standard interface language. FHIR = next-generation framework using the latest web standards. DICOM = images. SNOMED CT = most comprehensive multilingual clinical terminology. ICD = diagnosis codes. CPT = US procedure codes.

Picture it: Assign each standard a job before reading the options and the item usually collapses.

VPN

In plain English: A private encrypted tunnel into the network from outside.

Technical meaning: A safer, more secure method of remote access to an organization's network and servers, using tunneling protocols and encryption and requiring authentication to block unauthorized users.

Picture it: Three named mechanisms: tunneling, encryption, authentication.

Interface engine

In plain English: The traffic controller that puts data in the right chart.

Technical meaning: Permits systems to be connected correctly; sending data between applications is not enough because many rules must be followed. Interface engines match data and patients correctly in near real time.

Picture it: If data lands in the wrong patient's chart, the bill, the report and the care are all wrong.

Real-world examples

A lab result is transmitted from an outside reference lab. Without an interface engine applying matching rules, it could land in the wrong patient's chart — and the source names the three consequences: care, bill and final report.

A hospital deploys clip-on hands-free phones. Two of the source's concerns bite immediately: the housing has to be antibacterial and cleanable, and the messaging feature must not become an unsanctioned order channel that bifurcates the workflow.

Distinctions & exam traps

EXAM TRAP · Which standards belong to interoperability

The tempting confusion: A NOT item mixing genuine healthcare standards with a network protocol, operating system or unrelated technology.

The deciding clue: The named set is HL7, FHIR, DICOM, SNOMED CT, ICD and CPT. Anything from a different taxonomy is the outlier.

Stem wording that triggers it: Circle EXCEPT first, then find the option that does not belong to the standards family. (Category outlier.)

EXAM TRAP · Image standard vs. terminology

The tempting confusion: Choosing SNOMED CT or LOINC for an imaging question.

The deciding clue: DICOM is the image standard. SNOMED CT is a clinical terminology.

Stem wording that triggers it: 'Exchange of medical images' names DICOM outright. (Standards confusion.)

EXAM TRAP · The consequence of no standards

The tempting confusion: Options describing slower networks, higher hardware cost or vendor lock-in.

The deciding clue: The source's named consequences are duplicative effort and work from clinical and administrative staff, plus patient safety concerns — the Tower of Babel image.

Stem wording that triggers it: 'In the absence of standards' asks for duplication and safety risk, not cost. (Plausible-but-wrong-layer.)

EXAM TRAP · Interface engine vs. data warehouse

The tempting confusion: Both move data around, so either can look right.

The deciding clue: An interface engine connects systems and matches data to the right patient in near real time. A warehouse consolidates data from many sources in one place so it can be queried together.

Stem wording that triggers it: 'Queried together' names the warehouse; 'connected correctly' names the interface engine. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give each standard one job: HL7, FHIR, DICOM, SNOMED CT, ICD, CPT. No hesitation allowed.
  2. State the Chapter 2 interoperability definition keeping both clauses — exchange and interpret.
  3. Explain the Tower of Babel consequence in your own words: what actually goes wrong without standards?
  4. Distinguish an interface engine from a data warehouse using one lab result as your example.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Network increasingly wireless while still cable-dependent; point-of-care information requires wireless access points; clinicians reject the return-to-nurses-station model; providers take the chart into the room
  • Named network technologies: VPNs; VoIP over fiber-optic and coaxial cables with supporting protocols governing router and switch connections; LANs using Ethernet and token ring; WANs using MPLS or ATM
  • VPNs are a safer, more secure remote access method using tunneling protocols and encryption and requiring authentication
  • Cabled access more reliable and faster; legacy cable investment; hardwired desktops in clinical, administrative and support areas; fixed devices in exam rooms; radiology exam rooms need larger high-resolution monitors and high-speed graphics cards; patient-care hardware must be cleaned with appropriate agents
  • Regulatory documentation requirements; EHR must support documentation, order entry and lab results reporting required by regulations, professional standards and patient need; documenting when and where care is provided reduces errors
  • Communications: landline with conferencing and video; VoIP and broadband devices; data communication protocols transmit information point to point; cell-phone-like and clip-on hands-free devices; infection control requiring antibacterial cleanable materials; text messaging security concerns for patient orders and provider reluctance; bifurcated workflows can result in missed patient care; broadband, Ethernet and Wi-Fi
  • Standards named: HL7 as international standard interface language; HL7 FHIR as next-generation framework leveraging the latest web standards; DICOM for images; SNOMED CT as the most comprehensive multilingual clinical healthcare terminology; ICD for diagnosis codes; CPT for US procedures
  • US ICD/CPT classify diagnoses and procedures and link each procedure to the diagnosis requiring it; France's ISPOR charge codes with correct prices; codes entered by clerical staff and providers; codes largely determine maximum vs. minimum reimbursement
  • Interoperability definition: extent to which systems and devices can exchange data and interpret shared data; uniform movement of healthcare data with clinical or operational purpose and meaning preserved and unaltered
  • Without standards interoperability is impossible; Tower of Babel image; duplicative clinical and administrative effort and patient safety concerns; US Final Rule published by CMS in August 2012; Advisory Board for Health Standards in Europe
  • Nursing and other disciplines' terminologies usable by nurses and physicians; standardization affects all of healthcare and especially quality reporting; standard words improve data, research and natural language processing
  • Worldwide EHR interoperability challenges; European integration effort improving adoption and needing speed; increasing number of single-discipline specialty systems moving away from an integrated EHR
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.

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.

Chapter 2 · Source: Data Integration; Data Warehouses; Privacy and Security; Summary

L2.7 · Data Integration, Data Warehouses, Privacy and Security, Summary

Walkthrough

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 really drive the systems, matching data and patients correctly in near real time.

Without data integration and interface engines, the following would not be possible:

  • a national health information network
  • connections to EHRs with best of breed systems
  • EHR app integration using FHIR

Data warehouses

Data warehouses are highly prevalent in today's healthcare IT landscape. The value of storing and mining 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 data to different organizations — from the Bureau of Vital Statistics to the American Heart Association in the US, or the European Society of Cardiology. Often these organizations require the same quality improvement data elements but in a different format. The warehouse can support quality reporting, clinical research and analytics.

Data mining can be used to:

  • identify populations at risk
  • search for patterns of illness
  • identify potential study candidates or patient populations that are doing well

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.

Privacy and security

Maintaining patients' information — ensuring it is kept private and secure — is the first charge for EHR administration.

  • Patient data has to be shared through HIEs and Regional Health Information Organizations (RHIOs), and must remain confidential.
  • Data regulations increasingly include 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. The source's 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.
  • Disclosures can be made to appropriate agencies such as the patient's insurance provider, but those agencies cannot be given complete access — they must be given the minimum amount of information necessary.
  • Ethically, healthcare providers have an 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 the patient's information.

Summary

Understanding the basic foundations of healthcare technologies, applications and the tools used in connecting them provides the ability to create, support and maintain healthcare information. Knowledge of these fundamental areas, key issues and especially trends is the basis of building and designing healthcare IT and supporting providers in caring for patients safely, accurately and in a timely manner.

Big picture

This closing stretch supplies three ideas the rest of the credential leans on: integration is rule-governed, not just plumbing; the warehouse exists so one dataset can serve many reporting masters; and role-based confidentiality levels are a design requirement, not an afterthought.

Where it fits: Chapter 5 turns the design requirement into technical specifications; Chapter 8 turns confidentiality levels into access controls and the minimum necessary standard.

Nearby concepts to keep straight: minimum necessary appears here in Chapter 2 as well as in Chapter 8 — the phrase is the tell.

Key concepts

Data integration / interface engine

In plain English: Rules that make sure the right data lands in the right chart.

Technical meaning: Interface engines permit systems to be connected correctly; sending data is not enough because many rules must be followed. They match data and patients correctly in near real time, and without them a national health information network, best-of-breed EHR connections and FHIR app integration would not be possible.

Picture it: The failure mode named by the source is a wrong-chart landing that corrupts care, bill and report at once.

Data warehouse

In plain English: One place where data from many systems can be asked one question.

Technical meaning: Consolidates data from multiple sources such as the EHR and ancillary systems so it can be queried at the same time; supports quality reporting to multiple bodies, clinical research and analytics.

Picture it: Different bodies want the same elements in different formats. That is the warehouse's whole job.

Levels of confidentiality

In plain English: Different roles see different parts of the chart.

Technical meaning: The system must maintain levels of confidentiality — a nurse or physician can see laboratory results; a nurse's aide using the same EHR should not.

Picture it: Role determines visibility inside one system. This is a design requirement, not a policy afterthought.

Minimum necessary

In plain English: Give an outside agency only what it actually needs.

Technical meaning: Disclosures may be made to appropriate agencies such as the patient's insurance provider, but they cannot be given complete access to the record — only the minimum amount of information necessary.

Picture it: The phrase itself is the exam tell.

Real-world examples

A hospital reports the same cardiac quality elements to a national registry and to a state agency in two different formats. Building two extracts from two systems is fragile; building both from the warehouse is the source's point.

An insurer requests records to adjudicate a claim. The correct posture is not a full chart dump and not a refusal — it is the minimum amount of information necessary.

Distinctions & exam traps

EXAM TRAP · Interface engine purpose

The tempting confusion: Answering that interface engines exist to speed up networks, store data, or replace standards.

The deciding clue: They exist so systems are connected correctly and data is matched to the right patient in near real time under many rules.

Stem wording that triggers it: 'Exist primarily to' asks for the primary purpose — matching, not transporting. (Plausible-but-upstream.)

EXAM TRAP · Warehouse vs. interface engine vs. PACS

The tempting confusion: All three are named infrastructure in this chapter.

The deciding clue: Warehouse = consolidation for querying. Interface engine = correct connection and patient matching. PACS = image storage and display.

Stem wording that triggers it: 'Consolidates data from many source systems so it can be queried together' names the warehouse. (Adjacent role.)

EXAM TRAP · Confidentiality is role-based inside one system

The tempting confusion: Assuming everyone with EHR access sees the same content.

The deciding clue: The source's example puts a nurse's aide and a physician in the same EHR with different visibility.

Stem wording that triggers it: 'Maintain levels of confidentiality' points to role-based access, not to perimeter security. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Explain why sending data between applications is not the same as integrating it, using the wrong-chart failure.
  2. Name three things that would be impossible without data integration and interface engines.
  3. Explain the warehouse's value proposition to a quality director who reports the same measures to three different bodies.
  4. State the minimum necessary idea in your own words and apply it to an insurer request.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Data integration and interface engines essential; engines permit correct system connection; sending data is not enough because many rules must be followed
  • Wrong-chart data landing causes errors in the patient's care, bill and final report; engines match data and patients correctly in near real time
  • Without data integration and interface engines a national health information network, connections to EHRs with best-of-breed systems, and EHR app integration using FHIR would not be possible
  • Data warehouses highly prevalent; value of storing and mining data from multiple sources such as EHR and ancillary systems; single storage allows simultaneous querying
  • Multiple external submission requirements (Bureau of Vital Statistics, American Heart Association, European Society of Cardiology) often requiring the same quality elements in different formats; warehouse supports quality reporting, clinical research and analytics
  • Data mining identifies populations at risk, patterns of illness, potential study candidates and populations doing well
  • Data model definition, data mart vs. warehouse decision, and warehouse search design belong to an experienced database manager
  • Privacy and security as the first charge for EHR administration; data shared through HIEs and RHIOs must remain confidential
  • Regulations emphasize the EHR can and must be developed without compromising privacy; systems must provide the patient an accounting of disclosures
  • Systems must maintain levels of confidentiality; nurse/physician vs. nurse's aide laboratory results example
  • Disclosures to appropriate agencies such as insurers must be limited to the minimum amount of information necessary rather than complete access
  • Ethical obligation of providers; professional codes of ethics detailing nurse and physician obligations to protect patient information
  • Summary: foundations of technologies, applications and connecting tools enable creating, supporting and maintaining healthcare information; knowledge of fundamentals, key issues and trends underpins building and designing healthcare IT for safe, accurate and timely care
Read the original source

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.

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 3 · Source: Introduction; Global Aspects of Clinical Informatics; Domains of Clinical Informatics

L3.1 · Introduction — What Clinical Informatics Is, and Its Domains

Walkthrough

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 five areas:

  1. Methods to collect, store and analyze healthcare data
  2. The study of information needs and cognitive processes and optimal ways to meet those needs
  3. Methods to support clinical decisions, including summarization, visualization, provision of evidence and active decision support
  4. Optimizing the flow of information and coordinating it with care providers' and patients' workflows to maximize patient safety and care quality
  5. Methods and policies for information infrastructure, including privacy and security

Who clinical informaticists are

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.

Certification timeline:

  • Nurses established an early role, with certifications starting in 1992.
  • Physicians later followed with their own certifications through the American Medical Informatics Association (AMIA) in 2013.
  • HIMSS CAHIMS and CPHIMS are listed among the highest recommended informatics certifications for clinicians, along with board certifications.
  • Certification is a "highly-visible quality indicator and a tool to improve recognition among peers."

The informaticist's defining role: translators in the interprofessional team — a professional that speaks both informatics and healthcare.

Global aspects

  • Health information data can be stored across borders, which allows for the impact of international law with both data usage and patients' rights. This requires strong healthcare system and regulatory knowledge for the country of origin and any foreign locations.
  • AMIA leads a global health informatics working group (GHIWG) designed to work with resource-constrained countries.
  • Digital health is the term for clinical informatics more commonly used outside the United States.
  • HIMSS supports Canada, including its own certification CPHIMS-CA; the collaboration concentrates on strengthening the HIMSS Ontario Chapter, supporting existing associations and Canadian digital health initiatives (BCHIMPS, Canadian Trade Commission), and filling the void by bridging the clinical informatics gap. The Canadian Prairies Chapter and the HIMSS British Columbia Chapter were subsequently formed.
  • The EU–US eHealth Work Project, a Horizon 2020 project, ran 21 months from September 2016 to May 2018, with a goal 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." Its flagship survey drew over 1,000 respondents globally, primarily from the United States (72%) and Europe (19%). The most significant result was the need for increased clinical informatics education, with nurses, physicians and educators the top three — released as GAP1: eHealth knowledge and skills of healthcare professionals, of ten significant gaps identified in total. Other deficiencies: teacher/trainer knowledge, acceptance and usage of systems, availability of courses or programmes, and quality of current training materials.
  • The project updated the Health Information Technology Competencies (HITCOMP) Tool to version 2.0over 1,000 competencies, over 250 healthcare roles, in five major European languages.
  • The HIMSS TIGER Initiative continues through the Foundational Curriculum, the Interactive Web Platform TRIE (tools, resource, information, education) including the TIGER Virtual Learning Environment (VLE), and the skills and knowledge assessment and development (SKAD) framework.

The four domains of clinical informatics (AMIA)

"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."

Clinical informaticians use their knowledge of patient care combined with their understanding of informatics concepts, methods and tools to:

  1. Assess information and knowledge needs of healthcare professionals and patients
  2. Characterize, evaluate and refine clinical processes
  3. Develop, implement and refine clinical decision-support systems
  4. Lead or participate in the procurement, customization, development, implementation, management, evaluation and continuous improvement of clinical information systems

Big picture

Chapter 3 is the exam's largest single-chapter question block — 46 of the 230 canonical items, more than any chapter except 9. Most of those items test vocabulary and metrics rather than this framing section, but the framing tells you what the chapter is for: the informaticist is the translator between clinical work and information systems.

Where it fits: Chapter 1 named the informatics roles; Chapter 2 named the applications; Chapter 3 is what you do with them clinically. Chapters 4 through 7 then handle the lifecycle that builds and tests them.

Nearby concepts to keep straight: clinical informatics (the discipline) vs. digital health (the term used for it outside the US) vs. clinical decision support (one tool within it).

Key concepts

Clinical informatics (HIMSS definition)

In plain English: Making IT actually serve what clinicians are trying to do.

Technical meaning: 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.

Picture it: The test of an informatics decision is whether it supports the clinician's objective, not whether it is technically elegant.

The informaticist as translator

In plain English: The person who speaks both languages.

Technical meaning: A professional in the interprofessional team who speaks both informatics and healthcare; drawn from physicians, nurses, pharmacy, laboratory, radiology and other clinical professions.

Picture it: Nursing certifications began in 1992; physician certification through AMIA followed in 2013.

The four AMIA domains

In plain English: Assess needs, refine processes, build decision support, run the systems.

Technical meaning: Assess information and knowledge needs of healthcare professionals and patients; characterize, evaluate and refine clinical processes; develop, implement and refine clinical decision-support systems; lead or participate in procurement, customization, development, implementation, management, evaluation and continuous improvement of clinical information systems.

Picture it: Four domains, and the fourth is the whole system lifecycle compressed into one line.

Real-world examples

A nurse informaticist sits between a sepsis committee and the EHR build team. Neither group can specify the alert alone — the committee lacks the build vocabulary and the build team lacks the clinical judgment. That gap is the job.

Distinctions & exam traps

EXAM TRAP · The five areas of the field

The tempting confusion: Lists that swap in 'billing optimization' or 'network administration' for one of the five named areas.

The deciding clue: Collect/store/analyze data; information needs and cognitive processes; support clinical decisions; optimize information flow with workflows; information infrastructure methods and policies including privacy and security.

Stem wording that triggers it: One altered element in a five-item list. (One altered element.)

EXAM TRAP · Certification chronology

The tempting confusion: Reversing which profession certified first.

The deciding clue: Nursing informatics certification from 1992; physician clinical informatics board certification through AMIA in 2013.

Stem wording that triggers it: Nurses first, by two decades. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give the HIMSS definition of clinical informatics in your own words, and say what the word 'support' is doing in it.
  2. Name the four AMIA domains of clinical informatics.
  3. Explain what makes the informaticist a translator, using one project you have seen.

Questions

No canonical items map to the framing section. It establishes the definitions and domains that Lessons 3.2 through 3.6 test directly.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • HIMSS definition of clinical informatics: promotion of understanding, integration and application of IT in healthcare settings to ensure adequate and qualified support of clinician objectives and industry best practices
  • Five areas of the field: methods to collect, store and analyze healthcare data; study of information needs and cognitive processes and optimal ways to meet them; methods to support clinical decisions including summarization, visualization, provision of evidence and active decision support; optimizing information flow coordinated with provider and patient workflows to maximize patient safety and care quality; methods and policies for information infrastructure including privacy and security
  • 2018 digital health deals exceeding US$8 billion (Diana Nole, CEO of Wolters Kluwer Health); CDS as a powerful guidance tool; AI and machine learning adoption rising; increased focus on social determinants of health and patient-driven care
  • Clinical informaticists drawn from physicians, nurses, pharmacy, laboratory, radiology and other clinical professions; physicians and nurses the largest contributing group
  • Nursing informatics certifications starting 1992; physician certifications through AMIA in 2013; HIMSS CAHIMS and CPHIMS among the highest recommended informatics certifications; certification as a highly visible quality indicator and tool to improve peer recognition
  • Informaticist role as translator in the interprofessional team, speaking both informatics and healthcare
  • Cross-border health data storage and the impact of international law on data usage and patient rights; need for regulatory knowledge of origin and foreign locations
  • AMIA global health informatics working group (GHIWG) for resource-constrained countries; connection forum for exchanging informatics experiences and expertise
  • Digital health as the term for clinical informatics used more commonly outside the United States
  • HIMSS Canadian certification CPHIMS-CA; three collaboration areas — strengthening the HIMSS Ontario Chapter, supporting existing associations and Canadian digital health initiatives including BCHIMPS and the Canadian Trade Commission, and filling the void by bridging the clinical informatics gap; subsequent formation of the Canadian Prairies Chapter and the HIMSS British Columbia Chapter
  • EU–US eHealth Work Project as a Horizon 2020 project, 21 months from September 2016 to May 2018; goal 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
  • Consortium members: Omni Miro Systems/Med Solutions (Germany) as project coordinator, European Health Telematics Association (Belgium), University of Applied Sciences Osnabrück (Germany), Tampere University of Technology (Finland), Steinbeis 2i GmbH (Germany), and the HIMSS Foundation with fulfillment by the HIMSS TIGER Initiative
  • Survey of Current State and Needs of the eHealth Workforce: over 1,000 respondents, primarily United States (72%) and Europe (19%); most significant result the need for increased clinical informatics education, with nurses, physicians and educators the top three; released as GAP1 of ten significant gaps; other gaps in teacher/trainer knowledge, acceptance and usage of systems, availability of courses or programmes, and quality of training materials
  • HITCOMP Tool version 2.0: over 1,000 competencies, over 250 healthcare roles, five major European languages; focus on eHealth, digital skills research, education development, skills assessment and career progression
  • HIMSS TIGER Initiative Foundational Curriculum, Interactive Web Platform TRIE including the TIGER Virtual Learning Environment, and the SKAD framework promoting CAHIMS/CPHIMS
  • AMIA statement that clinical informaticians transform healthcare by analyzing, designing, implementing and evaluating information and communication systems enhancing individual and population health outcomes, improving patient care and strengthening the clinician-patient relationship
  • Four domains: assess information and knowledge needs of healthcare professionals and patients; characterize, evaluate and refine clinical processes; develop, implement and refine clinical decision-support systems; lead or participate in procurement, customization, development, implementation, management, evaluation and continuous improvement of clinical information systems
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.

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 · Source: Table 3.2 Prefixes; Table 3.3 Drug Routes; Table 3.4 Medical Specialties; Table 3.5 Clinical Abbreviations

L3.2 · Basic Clinical Vocabulary — Prefixes, Drug Routes, Specialties and Abbreviations

Walkthrough

This section is pure recall, and the exam tests it directly. Eight canonical items come from these four tables. There is no reasoning shortcut — but there is structure, and structure makes it learnable.

Table 3.2 — Clinical terminology prefixes

PrefixMeaningPrefixMeaning
Brachi/oArmLapar/oAbdomen, loin or flank
Cardi/oHeartMy/oMuscle
Cyt/oCellNeur/oNerve
Derm/a, derm/o, dermat/oSkinOcul/oEye
Encephal/oBrainOphthalm/oEyes
Gastr/oStomachOr/oMouth
Hemat/oBloodOt/oEar
Intestin/oIntestinePulmon/oLungs

Two pairs are built to be confused: ocul/o and ophthalm/o both concern the eye; or/o (mouth) and ot/o (ear) differ by one letter.

Table 3.3 — Drug routes and abbreviations

ClassificationRoutesAbbreviations
EnteralOral; Sublingual; Per rectumPO; SL; PR
ParenteralInjectionsSQ, IM, IV, IA, IT, IO, ID
InhalationLungsAerosols, steam
TopicalSkinEnepidermic, epidermic, insufflation, instillation, irrigation, swabbing

The classification split is the examinable point. Enteral routes are oral, sublingual and per rectum — all through the gut. Parenteral means injections, and the source lists seven abbreviations: SQ (subcutaneous), IM (intramuscular), IV (intravenous), IA, IT, IO, ID (intradermal). An item asking which routes are parenteral is asking you to pick the injection set. An EXCEPT item on enteral routes is asking you to spot the injection or topical route hiding in a list of gut routes.

Table 3.4 — Medical specialties (all seventeen)

SpecialtyAreaScope
Allergy and ImmunologyAllergiesDiagnosis and treatment of allergies, including allergy testing and medications
AnesthesiologySedation/anesthesiaAnesthesia, sedation and airway management; typically in the operating room during surgery
CardiologyCardiovascular systemHeart and blood vessel issues and disease processes
DermatologyIntegumentary systemAesthetics (laser treatments), rashes, skin cancers and other skin issues
EndocrinologyEndocrine systemDiseases such as diabetes and thyroid issues
Family PhysicianPrimary care providerBasic, typically nonspecialized care across all genders and ages
GastroenterologyDigestive systemEsophagus, stomach, intestinal issues including reflux, gallbladder, colitis
Infectious DiseaseInfectionsDifficult to diagnose or treat — tuberculosis, Zika, Dengue
Internal MedicinePrimary care providerSpecialized providers encompassing sub-specialties such as cardiology or endocrinology
NeurologyNeurologic systemSpinal issues, brain, nerves — Parkinson's, neuropathies
PediatricsPediatric careInfancy through age 18; well-checks, immunizations, physicals
OncologyCancer managementCancer, treatment side-effects, clinical trials, end-of-life care
Obstetrics/GynecologyWomen's healthReproductive and preventive care, pregnancy, menopause, contraception, infertility
OtolaryngologyEars, nose and throatENTs are often also surgeons — sinus issues, neck cancers
PsychiatryMental and behavioral healthcareCounseling, psychotherapy, analysis, hospitalization, medications
RadiologyImagingPhysician trained at interpreting diagnostic exams and testing
SurgerySurgical carePre-operative planning, surgery, post-operative needs, complications (orthopedics, general, bariatrics)

Thyroid → Endocrinology. Ears, nose and throat → Otolaryngology. Those two are directly tested.

Table 3.5 — Frequently used clinical abbreviations

Frequency and timing — the highest-yield cluster:

BIDTwice a dayTIDThree times a day
QIDFour times a dayQODEvery other day
QEveryQ2hEvery two hours
Q6hEvery six hoursQamEvery morning
QpmEvery nightHSAt bedtime
PRNAs neededSTATImmediately
ACBefore mealsAd libFreely
AnteBeforeAM / PMMorning / Evening

Laterality — the paired set that trips people:

EarEye
ADRight earODRight eye
ASLeft earOSLeft eye
AUBoth earsOUBoth eyes

A = ear (auris), O = eye (oculus). D = right (dexter), S = left (sinister), U = both.

Routes and administration: SL sublingual · SQ subcutaneous · ID intradermal · IM intramuscular · IV intravenous · IN intranasal · INJ injection · Supp suppository · Cap capsule · Amp ampule · Disp dispense · DC discontinue · Rx prescription

Status and clinical: NPO Nothing by mouth · NKDA No known drug allergies · N/V Nausea and vomiting · WNL Within normal limits · CC Chief complaint · HX History · H/O History of · PMH Past medical history · LMP Last menstrual period · BMI Body mass index · BP Blood pressure · BS Blood sugar · HR Heart rate · T Temperature · CXR Chest x-ray · ASA Aspirin · ER/EC/ED Emergency room · w/o Without

Units: L liter · mL milliliter · G gram · MCG microgram · Gr grain · mEq/L milliequivalent per liter · CM centimeter · Mm millimeter · oz ounce · HR hour

Big picture

This is the one lesson in the whole notebook where memorization is the correct strategy — there is no conceptual scaffolding underneath "TID means three times a day." Everything else in this notebook is built to give you understanding first. Here, put the recite-list drills in the middle section of the physical notebook and run them cold.

Three clusters carry most of the exam load: the frequency abbreviations, the laterality pairs (AD/AS/AU vs. OD/OS/OU), and the enteral/parenteral route split.

Where it fits: this vocabulary is assumed by every clinical scenario item elsewhere in the exam. A stem that says "a medication ordered TID" will not stop to define it.

Key concepts

Enteral vs. parenteral

In plain English: Through the gut, versus by injection.

Technical meaning: Enteral routes are oral (PO), sublingual (SL) and per rectum (PR). Parenteral routes are injections: SQ, IM, IV, IA, IT, IO, ID.

Picture it: If a route in an 'enteral' list involves a needle, that is the EXCEPT answer.

The frequency set

In plain English: How many times a day, or how many hours apart.

Technical meaning: BID twice daily; TID three times daily; QID four times daily; QOD every other day; Q2h every two hours; Q6h every six hours; Qam every morning; Qpm every night; HS at bedtime; PRN as needed; STAT immediately.

Picture it: BID/TID/QID count doses. Q-with-a-number counts hours between doses.

Laterality abbreviations

In plain English: Which ear, which eye, or both.

Technical meaning: AD right ear, AS left ear, AU both ears; OD right eye, OS left eye, OU both eyes.

Picture it: A for auris (ear), O for oculus (eye); D dexter (right), S sinister (left), U both.

Encephal/o

In plain English: Brain.

Technical meaning: The clinical prefix for the brain. Distinguish from neur/o (nerve), which covers the nervous system more broadly.

Picture it: Encephalitis is inflammation of the brain — the word carries its own definition.

Real-world examples

An order reads 'furosemide 40 mg PO BID.' Oral route, enteral classification, twice daily. Three separate table lookups in a five-word order.

A chart says 'NPO after midnight, NKDA.' Nothing by mouth, no known drug allergies — two of the most common abbreviations in the whole table.

Distinctions & exam traps

EXAM TRAP · Enteral EXCEPT items

The tempting confusion: A list of gut routes with one injection or topical route inserted.

The deciding clue: Enteral is exactly oral, sublingual and per rectum.

Stem wording that triggers it: Circle EXCEPT, then find the route that does not pass through the gut. (Category outlier.)

EXAM TRAP · Ocul/o vs. ophthalm/o vs. ot/o vs. or/o

The tempting confusion: Prefixes differing by one or two letters with entirely different meanings.

The deciding clue: Ocul/o eye; ophthalm/o eyes; ot/o ear; or/o mouth.

Stem wording that triggers it: Read the prefix letter by letter. (One altered element.)

EXAM TRAP · Q6h vs. QID

The tempting confusion: Both produce four doses a day, but they are not the same order.

The deciding clue: Q6h means every six hours. QID means four times a day, on the facility's schedule.

Stem wording that triggers it: Q-plus-number is an interval; the ID family is a count. (Adjacent term.)

EXAM TRAP · Endocrinology vs. Internal Medicine

The tempting confusion: Internal medicine encompasses endocrinology as a sub-specialty, so both can look right.

The deciding clue: A newly identified thyroid disorder goes to Endocrinology — the source assigns diabetes and thyroid issues to that specialty explicitly.

Stem wording that triggers it: When a specialty and its parent both appear, take the specific one named in the table. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite the enteral routes and the parenteral abbreviations from memory. Anything you drop goes in the recite-list section of the notebook.
  2. Write out the six laterality abbreviations and say what the letters stand for.
  3. Give the meaning of BID, TID, QID, QOD, Q2h, Q6h, HS, PRN and STAT without looking.
  4. Name the specialty for: thyroid disorder, ears/nose/throat, skin cancer, Parkinson's, and interpreting a CT.

Questions

8 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Prefixes: brachi/o arm; cardi/o heart; cyt/o cell; derm/a, derm/o, dermat/o skin; encephal/o brain; gastr/o stomach; hemat/o blood; intestin/o intestine; lapar/o abdomen, loin or flank; my/o muscle; neur/o nerve; ocul/o eye; ophthalm/o eyes; or/o mouth; ot/o ear; pulmon/o lungs
  • Drug route classifications: 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)
  • Medical specialties: Allergy and Immunology; Anesthesiology (sedation/anesthesia, airway management, operating room); Cardiology (cardiovascular); Dermatology (integumentary); Endocrinology (endocrine system, diabetes and thyroid); Family Physician (primary care, nonspecialized, all genders and ages); Gastroenterology (digestive, esophagus, stomach, intestinal, reflux, gallbladder, colitis); Infectious Disease (tuberculosis, Zika, Dengue); Internal Medicine (primary care encompassing sub-specialties such as cardiology or endocrinology); Neurology (spinal, brain, nerves, Parkinson's, neuropathies); Pediatrics (infancy through age 18, well-checks, immunizations, physicals); Oncology (cancer, treatment side-effects, clinical trials, end-of-life care); Obstetrics/Gynecology (reproductive and preventive care, pregnancy, menopause, contraception, infertility); Otolaryngology (ears, nose and throat, often surgeons, sinus issues, neck cancers); Psychiatry (counseling, psychotherapy, analysis, hospitalization, medications); Radiology (imaging, interpreting diagnostic exams); Surgery (pre-operative, surgery, post-operative, complications; orthopedics, general, bariatrics)
  • Clinical abbreviations — timing and frequency: AM morning; PM evening; AC before meals; Ad lib freely; Ante before; BID twice a day; TID three times a day; QID four times a day; QOD every other day; Q every; Q2h every two hours; Q6h every six hours; Qam every morning; Qpm every night; HS at bedtime; PRN as needed; STAT immediately
  • Laterality: AD right ear; AS left ear; AU both ears; OD right eye; OS left eye; OU both eyes
  • Routes and administration abbreviations: SL sublingual; SQ subcutaneous; ID intradermal; IM intramuscular; IV intravenous; IN intranasal; INJ injection; Supp suppository; Cap capsule; Amp ampule; Disp dispense; DC discontinue; Rx prescription
  • Clinical status abbreviations: NPO nothing by mouth; NKDA no known drug allergies; N/V nausea and vomiting; WNL within normal limits; CC chief complaint; HX history; H/O history of; PMH past medical history; LMP last menstrual period; BMI body mass index; BP blood pressure; BS blood sugar; HR heart rate; T temperature; CXR chest x-ray; ASA aspirin; ER/EC/ED emergency room; w/o without
  • Units: L liter; mL milliliter; G gram; MCG microgram; Gr grain; mEq/L milliequivalent per liter; CM centimeter; Mm millimeter; oz ounce; HR hour
Read the original source

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

Chapter 3 · Source: Table 3.6 Frequently Used Healthcare Information Technology Vocabulary; Basic Information Technology Vocabulary and Terms

L3.3 · Basic Healthcare IT Vocabulary

Walkthrough

Thirteen terms, each with a definition the exam quotes closely.

TermSource definition
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
DICOMDeveloped for the transmission of images and 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
HIPAAUS 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, nonprofit, standard-developing organization that creates methods for interoperability of healthcare data interchange; focuses on clinical and administrative data
ICD-10A 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
LOINCCoding system for the electronic exchange of laboratory test results and other observations; developed through a public-private partnership of several federal agencies, academia and the vendor community
MIPSDesigned 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)A branch of artificial intelligence that helps computers understand, interpret and manipulate human language; draws from computer science and computational linguistics, to fill the gap between human communication and computer understanding
SNOMED CTCreated from the combination of SNOMED-RT (Reference Terminology) and Read codes
UMLSDeveloped by the National Library of Medicine in an attempt to unify disparate medical vocabularies and facilitate sharing medical knowledge across information systems

Sorting the code sets and terminologies

The most tested skill here is assigning each standard its object:

  • CPTbilling of medical procedures
  • ICD-10diagnoses, symptoms and procedures classification and coding
  • LOINClaboratory test results and other observations
  • SNOMED CTclinical terminology (from SNOMED-RT + Read codes)
  • DICOMimages
  • HL7data interchange / interoperability, clinical and administrative
  • UMLSunifying disparate vocabularies

Note the distinction the exam exploits: LOINC names the test; SNOMED CT names the clinical concept; ICD codes the diagnosis; CPT bills the procedure. A question about encoding the name of a laboratory test result is a LOINC question, not a SNOMED CT question.

HL7 is an organization, not just a message format — the source defines it as an ANSI-accredited, nonprofit, standard-developing organization. A NOT item asking which items are clinical terminologies or code sets can use HL7 as the outlier, because it is a standards organization rather than a terminology.

Big picture

Eight canonical items come from this one table. All are recall or simple application, and all reward the same preparation: bind each acronym to exactly one object before you read the answer choices.

Where it fits: Chapter 2 introduced HL7, FHIR, DICOM, SNOMED CT, ICD and CPT from the interoperability side. Chapter 3 adds LOINC, UMLS, NLP, ACO, FQHC, ACA and MIPS and gives the coding standards clinical definitions.

Nearby concepts to keep straight: FQHC appeared in Chapter 1 as a community health organization type; here it appears as a vocabulary term with the same definition. Same answer, two chapters.

Key concepts

LOINC

In plain English: The naming system for lab tests and observations.

Technical meaning: Logical Observation Identifiers Names and Codes — a coding system for the electronic exchange of laboratory test results and other observations, developed through a public-private partnership of federal agencies, academia and the vendor community.

Picture it: 'Name of a laboratory test result' is the LOINC trigger phrase.

SNOMED CT origin

In plain English: Two terminologies merged.

Technical meaning: Created from the combination of SNOMED-RT (Reference Terminology) and Read codes.

Picture it: The origin question has one correct pair. Read codes is the half candidates forget.

Accountable Care Organization

In plain English: Providers who coordinate care together and are judged on quality.

Technical meaning: A group of healthcare providers who give coordinated care and chronic disease management and thereby improve the quality of care patients receive.

Picture it: Coordination plus chronic disease management plus quality improvement — all three in the definition.

Natural Language Processing

In plain English: Teaching computers to read human writing.

Technical meaning: A branch of artificial intelligence that helps computers understand, interpret and manipulate human language, drawing from computer science and computational linguistics to fill the gap between human communication and computer understanding.

Picture it: The phrase 'branch of artificial intelligence' is in the definition itself.

Federally Qualified Health Center

In plain English: Federally funded nonprofit clinic for underserved areas.

Technical meaning: Federally funded nonprofit health centers or clinics that serve medically underserved areas and populations.

Picture it: 'Medically underserved' is the phrase that names the FQHC in both Chapter 1 and Chapter 3.

Real-world examples

A lab interface must carry both the test identity and the patient's condition. LOINC names the test; SNOMED CT names the condition; ICD-10 codes the billed diagnosis. Three standards, one message.

An NLP engine reads free-text discharge summaries to find undocumented comorbidities. That is the source's 'interpret human language' definition doing clinical work.

Distinctions & exam traps

EXAM TRAP · LOINC vs. SNOMED CT

The tempting confusion: Both are clinical vocabularies, so either can look right.

The deciding clue: LOINC encodes laboratory test results and other observations. SNOMED CT is the clinical terminology built from SNOMED-RT and Read codes.

Stem wording that triggers it: 'Name of a laboratory test result' names LOINC. (Adjacent term.)

EXAM TRAP · Terminologies and code sets EXCEPT

The tempting confusion: A NOT item mixing genuine terminologies with a standards organization or a payment program.

The deciding clue: CPT, ICD-10, LOINC and SNOMED CT are terminologies or code sets. HL7 is a standards-developing organization; MIPS is a payment program.

Stem wording that triggers it: Circle EXCEPT, then find the item from a different taxonomy. (Category outlier.)

EXAM TRAP · CPT vs. ICD-10

The tempting confusion: Both are US code sets and both touch procedures.

The deciding clue: CPT codes are used for the billing of medical procedures. ICD-10 classifies and codes diagnoses, symptoms and procedures recorded in conjunction with hospital care.

Stem wording that triggers it: 'Billing of medical procedures' names CPT. (Adjacent term.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: ICD-10, MIPS, Meaningful Use, CPT and LOINC as the working code sets.

Current practice (2026): The United States Core Data for Interoperability (USCDI) now defines the minimum data classes and elements for nationwide exchange, and HL7 FHIR APIs are mandated for certified EHRs. TEFCA and its QHINs operate the national exchange framework. RxNorm is the standard for clinical drug naming — a code set the 4th edition does not list alongside LOINC and SNOMED CT.

Does it matter for the exam? USCDI, TEFCA, QHIN and RxNorm appear zero times across the nine chapters. Answer within the Review Guide's list.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Bind each of these to exactly one object, out loud: CPT, ICD-10, LOINC, SNOMED CT, DICOM, HL7, UMLS.
  2. Define an ACO and an FQHC without looking, and say what distinguishes each.
  3. Say what SNOMED CT was created from.
  4. Explain NLP in one sentence, keeping the phrase 'branch of artificial intelligence'.

Questions

8 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Affordable Care Act: comprehensive US healthcare reform law enacted March 2010, also known as Obamacare
  • Accountable Care Organization: a group of healthcare providers giving coordinated care and chronic disease management, thereby improving quality of care
  • Current Procedural Terminology: codes used for the billing of medical procedures
  • DICOM: developed for the transmission of images and used internationally for PACS
  • Federally Qualified Health Center: federally funded nonprofit health centers or clinics serving medically underserved areas and populations
  • HIPAA: US law providing privacy standards to protect patients' medical records and other health information provided to health plans, doctors, hospitals and other providers
  • Health Level Seven: ANSI-accredited nonprofit standard-developing organization creating methods for interoperability of healthcare data interchange, focused on clinical and administrative data
  • ICD-10: system used by physicians and other providers to classify and code all diagnoses, symptoms and procedures recorded in conjunction with hospital care in the United States
  • LOINC: coding system for electronic exchange of laboratory test results and other observations; developed through a public-private partnership of several federal agencies, academia and the vendor community; model applicable to other standards-setting domains
  • MIPS: designed to tie payments to quality and cost-efficient care, drive improvement in care processes and health outcomes, increase use of healthcare information and reduce cost of care
  • Natural Language Processing: branch of artificial intelligence helping computers understand, interpret and manipulate human language; draws from computer science and computational linguistics to fill the gap between human communication and computer understanding
  • SNOMED CT: created from the combination of SNOMED-RT (Reference Terminology) and Read codes
  • UMLS: developed by the National Library of Medicine to unify disparate medical vocabularies and facilitate sharing medical knowledge across information systems
Read the original source

able 3.6 Frequently Used Healthcare Information Technology Vocabulary15–19

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 · Source: Common Clinical Metrics in Informatics

L3.4 · Common Clinical Metrics in Informatics

Walkthrough

Where clinical metrics came from

Most clinical informatics professionals credit the birth of clinical metrics with the 1999 publication by the Institute of Medicine (IOM), "To Err is Human." That landmark report brought to light issues within the healthcare system responsible not only for significant financial loss but also loss of life. Since the IOM report there has been a significant surge in the development of methods to keep down cost, provide accessible healthcare and significantly improve patient safety.

One thing that sets clinical informatics apart from other types of IT is the focus on identification and adoption of clinical metrics.

The US regulatory drivers

  • the American Reinvestment and Recovery Act (ARRA)
  • the accompanying Health Information Technology for Economic and Clinical Health (HITECH) Act
  • the Patient Protection and Affordable Care Act

These reinforced the shift toward decreasing government spending on healthcare while improving patient safety. With CMS's introduction of Meaningful Use (MU), they created a rapidly changing landscape. Before these laws, adoption was slow at best. With HITECH incentives, a landslide of implementation of certified electronic health records (CEHRTs) was kick-started.

eCQMs

CMS has had many variations since 2009 of the expectations of meeting their electronic clinical quality measures (eCQMs). These tools were designed specifically to aid in measuring and tracking several aspects of healthcare. Reporting revolves around eligible providers (EPs), eligible hospitals, dual-eligible hospitals and critical access hospitals (CAHs). Per CMS (2019), the current version uses the 2015 version of CEHRT to meet the requirements of the promoting interoperability program (PIP). Each year CMS provides updates to the eCQMs, consisting of updates regarding evidence-based medicine, code sets and measure logic.

The six current measurement goals of eCQMs for Medicare and Medicaid:

  1. Patient and Family Engagement
  2. Patient Safety
  3. Care Coordination
  4. Population/Public Health
  5. Efficient Use of Healthcare Resources
  6. Clinical Process/Effectiveness

Six domains. A NOT item on "common clinical metric domains" is built from this list.

The quality organizations

Two of the more significant ones: the National Quality Forum (NQF) and the Agency for Healthcare Research and Quality (AHRQ).

NQF supports improving overall national health by:

  • setting national standards
  • recommendation of measures for use in payment and public reporting programs
  • identification of quality improvement (QI) priorities
  • advancement of electronic measurement
  • providing information and tools to help healthcare decision-makers

NQF tools: NQF Graphics Library (downloadable graphics) · Alignment Tool (align, expand or start measurement and reporting efforts to fit key national programs) · Health IT Knowledge Base (answers to technical questions on health IT and eMeasures initiatives) · My Dashboard · NQF's Action Registry (online collaboration space connecting frontline people, finding resources, distributing proven ideas) · Field Guide to NQF Resources

AHRQ is a US government agency within the Department of Health & Human Services. Its primary mission is to support research and produce evidence for the improvement of quality healthcare. It developed quality indicators to determine the standards of healthcare and whether providers are meeting them. Named goals: keeping patients safe, helping physicians and other providers improve quality, and developing data to track changes in the healthcare system.

AHRQ areas of focus:

  • Project ECHO (Extension for Community Healthcare Outcomes)training and supporting primary care clinicians in rural communities to provide specialized care; expanded from hepatitis C into mental health and substance abuse and HIV; adopted by the Veterans Health Administration
  • Re-Engineered Discharge (RED)a structured protocol and suite of implementation tools helping hospitals rework discharge processes to reduce readmissions; hospitals using them have seen a 30% reduction in hospital readmissions and emergency room visits
  • Centers of Excellencethree funded to study how high-performing healthcare systems promote evidence-based practices in delivering care

Working with metrics

Metrics such as average daily census, cervical cancer screening and diabetic eye exams require thorough investigation of the requirements as well as current and future state workflow assessments to determine how they can be met within a CEHRT. Subsequent reporting to government agencies for 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 to help meet these metrics — and to accomplish this, CDS systems are often brought into play.

The named clinical metrics

The chapter's learning objective names four explicitly:

  • Average daily censusthe average number of inpatients receiving care each day
  • Turnaround time — for laboratory, the interval from specimen collection to result availability
  • Adherence — whether clinicians are following a protocol or guideline as introduced
  • Barcode medication administrationscanning a patient wristband and a medication prior to administration

Big picture

Eight canonical items come from this section, and they split two ways: recall of named metric definitions and eCQM domains, and application items asking which metric answers a given question.

The application pattern is worth internalizing. If a stem asks whether clinicians are following a new protocol, the answer is an adherence measure — not an outcome measure, not a volume measure. If it asks about workload relative to staffing, the answer involves average daily census.

Where it fits: Chapter 9 revisits measurement as benchmarks, KPIs and comparative analytics at the management level. Chapter 3 is the clinical layer.

Key concepts

Average daily census

In plain English: How many inpatients you are caring for on a typical day.

Technical meaning: The metric expressing the average number of inpatients receiving care each day.

Picture it: A rising census with flat staffing is a workload problem, and the exam will ask you to read it that way.

Turnaround time

In plain English: How long from sample to answer.

Technical meaning: For the laboratory, the interval between specimen collection and result availability.

Picture it: The interval is measured to result availability — not to the clinician reading it.

Adherence

In plain English: Are people actually following the protocol?

Technical meaning: A process measure of whether clinicians are following a newly introduced guideline or protocol.

Picture it: Adherence measures the behavior. Outcomes measure the result of the behavior.

Barcode medication administration

In plain English: Scan the patient, scan the drug, then give it.

Technical meaning: Scanning a patient wristband and a medication prior to administration.

Picture it: Both scans, in that order, before the dose.

The six eCQM measurement goals

In plain English: The domains CMS measures quality across.

Technical meaning: Patient and Family Engagement; Patient Safety; Care Coordination; Population/Public Health; Efficient Use of Healthcare Resources; Clinical Process/Effectiveness.

Picture it: Six. A seventh plausible-sounding domain in an options list is the outlier.

Real-world examples

A hospital introduces a sepsis bundle. The measure of whether clinicians are using it is adherence — percentage of eligible patients receiving the bundle elements on time. Mortality is the outcome, and it moves later, if at all.

Average daily census climbs 12% over a quarter while nursing FTEs stay flat. That combination is the source's own workload signal, not a quality finding.

Distinctions & exam traps

EXAM TRAP · Adherence vs. outcome measures

The tempting confusion: Choosing mortality, length of stay or readmission when the stem asks whether a protocol is being followed.

The deciding clue: Following the protocol is adherence — a process measure.

Stem wording that triggers it: 'Whether clinicians are following' names adherence. (Wrong layer.)

EXAM TRAP · eCQM domains EXCEPT

The tempting confusion: A NOT item inserting a plausible domain — cost containment, staff satisfaction, technology adoption — into the six.

The deciding clue: The six are patient and family engagement, patient safety, care coordination, population/public health, efficient use of healthcare resources, and clinical process/effectiveness.

Stem wording that triggers it: Circle EXCEPT, then find the domain not on the list of six. (One altered element.)

EXAM TRAP · Turnaround time endpoints

The tempting confusion: Options measuring from order entry, or to clinician acknowledgment.

The deciding clue: Laboratory turnaround time is the interval between specimen collection and result availability.

Stem wording that triggers it: Both endpoints have to match. (One altered element.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: ARRA, HITECH, Meaningful Use and the Promoting Interoperability Program with 2015-edition CEHRT.

Current practice (2026): Meaningful Use stages have been fully succeeded by Promoting Interoperability for hospitals and MIPS for clinicians, and certification requirements now flow from HTI-1 and its successors rather than the 2015 edition alone. eCQM specifications continue to be updated annually.

Does it matter for the exam? The Review Guide teaches the Meaningful Use frame explicitly, including the PIP transition. Answer in that frame; treat newer certification rule names in distractors with suspicion.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define average daily census, turnaround time, adherence and barcode medication administration without looking.
  2. Recite the six eCQM measurement goals.
  3. Explain why a rising census with unchanged staffing is a workload signal rather than a quality signal.
  4. Say what NQF does and what AHRQ does, and name one AHRQ program.

Questions

8 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Birth of clinical metrics credited to the 1999 IOM publication 'To Err is Human', which surfaced issues causing significant financial loss and loss of life; subsequent surge in methods to reduce cost, provide accessible healthcare and improve patient safety
  • Focus on identification and adoption of clinical metrics as distinguishing clinical informatics from other types of IT
  • ARRA, HITECH and the Patient Protection and Affordable Care Act reinforcing the shift toward decreasing government healthcare spending while improving safety; CMS Meaningful Use creating a rapidly changing landscape; slow adoption before these laws; HITECH incentives kick-starting a landslide of CEHRT implementation
  • eCQMs with many CMS variations since 2009, designed to aid measuring and tracking aspects of healthcare; reporting by eligible providers, eligible hospitals, dual-eligible hospitals and critical access hospitals; 2015 CEHRT version used to meet promoting interoperability program requirements; annual updates covering evidence-based medicine, code sets and measure logic
  • Six eCQM measurement goals for Medicare and Medicaid: patient and family engagement; patient safety; care coordination; population/public health; efficient use of healthcare resources; clinical process/effectiveness
  • NQF methods: setting national standards; recommending measures for payment and public reporting programs; identifying quality improvement priorities; advancing electronic measurement; providing information and tools for healthcare decision-makers
  • NQF tools: Graphics Library; Alignment Tool; Health IT Knowledge Base; My Dashboard; Action Registry; Field Guide to NQF Resources
  • AHRQ as a US government agency within the Department of Health & Human Services; mission to support research and produce evidence for improving quality healthcare; quality indicators determining standards and provider performance; goals of keeping patients safe, helping providers improve quality and developing data to track changes
  • AHRQ areas of focus: Project ECHO training and supporting rural primary care clinicians, expanded from hepatitis C into mental health, substance abuse and HIV, adopted by the Veterans Health Administration; Re-Engineered Discharge protocol and implementation tools with a 30% reduction in readmissions and emergency room visits; three Centers of Excellence studying how high-performing systems promote evidence-based practices
  • Metrics such as average daily census, cervical cancer screening and diabetic eye exams requiring requirement investigation and current/future state workflow assessment for CEHRT capture; reporting for reimbursement incentives or penalty avoidance often becoming the primary goal; workflow and ease of usability also required; CDS systems brought into play
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 · Source: Clinical Content and Decision Support Tools; Table 3.11 Advantages and Disadvantages of CPOE

L3.5 · System Functionality — CPOE, CDS Advantages and Disadvantages

Walkthrough

The arc of clinical decision support

Clinical informaticists and clinicians have been making a significant impact in health IT since the late 1950s — from mathematical models used to aid providers in diagnosing medical conditions to today's AI, application programming interfaces (APIs), substitutable medical applications reusable technologies (SMART), the fast healthcare interoperability resources (FHIR), or a combination 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."

The ultimate goal is patient safety and improved patient experience, but good build design and implementation can also provide:

  • better patient outcomes
  • improved overall quality
  • reduced cost
  • improved documentation consistency and reliability
  • an enhanced clinician experience

"Acceptance and adoption of CDS is critical for successful implementation."

Where CDS appears. 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)
  • passive/active generalized alerts

It can also be seen in patient portals, health information exchanges, mobile applications and other health IT systems.

Why maintenance is not optional

  • 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.
  • "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."
  • To maintain this rapidly changing use of technology and medicine, skilled workflow assessments, governance and maintenance is a must.

Deming, quoted by the source: "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.

CPOE advantages and disadvantages (Table 3.11)

AdvantagesDisadvantages
Averting handwriting issuesPerceived as more work for clinicians
Drug/drug, drug/food, drug/allergy alertsProvider coding requirements
Formulary recommendationsBad use of CDS; design, maintenance
Safer or lower costDuplicate alert drop-down issue
Economic savingsNever-ending system demands
Better billing turn aroundHybridized paper/electronic workflows
Faster order transmission to lab/pharmacy/radiologyConstantly changing evidence and technology
Overdependence on CDS

CPOE = computerized provider order entry (the source also uses computerized practitioner order entry).

CDS advantages and disadvantages

Advantages of CDS:

  1. Increased quality of care and enhanced health outcomes
  2. Avoidance of error and adverse events
  3. Improved efficiency, cost–benefit and provider and patient satisfaction

Disadvantages of CDS:

  1. Alarm/alert fatigue
  2. Clinical burnout, documentation burden
  3. Delegation of order entry to other clinicians
  4. Data integrity
  5. Auto-population
  6. Design and implementation issues
  7. Lack of maintenance and governance

Alarm/alert fatigue is listed first among CDS disadvantages, and it is the source's named consequence of poorly governed CDS. Hybridized paper/electronic workflows appear as a CPOE disadvantage — the source elsewhere (Chapter 2) calls these bifurcated workflows that can result in missed patient care.

The five rights of CDS

Osheroff et al. recommend a five-rights framework for CDS, adopted and promoted as best practice by AHRQ:

  1. The right information — evidence-based, recognized guidelines; actionable, not too much information
  2. To the right person — the right decision-makers involved; include end users and the healthcare team; determine who needs to see it; is the person seeing it qualified to use it?
  3. In the right intervention format — alerts, passive or actionable? order sets, info buttons
  4. Through the right channel — EHRs, HIEs, patient portals, CPOE, forms
  5. At the right time in the workflow — when should the CDS be presented? workflow analysis; close the loop

There is also a need for increased usability, which relates directly to CPOE: the less a physician or advanced practice provider uses the order systems as designed, the less impactful CDS is. It will be alerting in the face of the incorrect people. Providers have to be well trained, well informed and satisfied with the usability of the system.

CDS tools are increasingly leveraging machine learning and artificial intelligence; machine learning algorithms can ingest large quantities of data, identify patterns and return detailed results to users.

Big picture

This lesson and the next carry thirteen canonical items between them, and the exam's favourite move here is the five rights as a diagnostic tool. When a scenario describes a decision-support failure, the item is asking which of the five rights was violated:

  • Fires but nobody can act on it → wrong person
  • Fires too late to change the decision → wrong time in the workflow
  • Fires constantly and gets dismissed → alert fatigue, a governance failure
  • Correct content delivered as an interruptive popup when a passive link would do → wrong format

Where it fits: Chapter 5's usability material and Chapter 6's change management both bear on CDS adoption. The source is explicit that acceptance and adoption determine whether CDS succeeds.

Key concepts

Clinical decision support

In plain English: Patient-specific guidance delivered where care happens.

Technical meaning: A category of concepts and methods designed to provide patient-specific clinical information to a healthcare provider at the point of care.

Picture it: Two qualifiers do the work: patient-specific, and at the point of care.

The five rights of CDS

In plain English: Right info, right person, right format, right channel, right time.

Technical meaning: The right information, to the right person, in the right intervention format, through the right channel, at the right time in the workflow. Recommended by Osheroff et al. and promoted as best practice by AHRQ.

Picture it: Use it as a diagnostic: when CDS fails, name which right was broken.

Info buttons

In plain English: Context-sensitive reference links inside the chart.

Technical meaning: Access to reference information within the EHR workflow, listed by the source alongside order sets, condition-specific clinical alerts and passive/active generalized alerts as forms of CDS.

Picture it: 'Context-sensitive links delivering reference knowledge inside the workflow' names info buttons.

Alert fatigue

In plain English: Too many warnings, so clinicians stop reading them.

Technical meaning: Alarm/alert fatigue, listed first among CDS disadvantages and the most commonly cited consequence of poorly governed clinical decision support.

Picture it: Routine override of most warnings is the clinical description of alert fatigue.

Hybridized paper/electronic workflows

In plain English: Half the process on paper, half in the system.

Technical meaning: Listed as a CPOE disadvantage; Chapter 2 describes the same pattern as bifurcated workflows that can result in missed patient care.

Picture it: The danger is not inefficiency — it is information falling into the gap between the two halves.

Real-world examples

A drug-interaction alert fires for a pharmacist who cannot change the order. Correct information, wrong person — the second right, broken.

A hospital adds 40 new alerts in one quarter without retiring any. Clinicians begin dismissing everything. That is alert fatigue produced by absent governance, exactly as the source predicts.

Distinctions & exam traps

EXAM TRAP · CPOE advantages EXCEPT

The tempting confusion: A NOT item mixing genuine advantages with items from the disadvantage column.

The deciding clue: Advantages: averting handwriting issues, drug/drug and drug/food and drug/allergy alerts, formulary recommendations, safer or lower cost, economic savings, better billing turnaround, faster order transmission to lab/pharmacy/radiology.

Stem wording that triggers it: Circle EXCEPT, then check whether the option sits in the disadvantage column. (Category outlier.)

EXAM TRAP · Diagnosing which right was broken

The tempting confusion: Multiple rights can sound plausible for one failure scenario.

The deciding clue: Cannot act on it = wrong person. Arrives too late = wrong time. Wrong delivery vehicle = wrong channel or format.

Stem wording that triggers it: 'Reaches a clinician who cannot act on it' names the right person. (Wrong layer.)

EXAM TRAP · Alert fatigue as the named consequence

The tempting confusion: Choosing burnout, data integrity or overdependence for a poorly governed CDS question.

The deciding clue: Alarm/alert fatigue is listed first among CDS disadvantages and is the most commonly cited consequence.

Stem wording that triggers it: 'Most commonly cited consequence of poorly governed CDS' names alert fatigue. (Plausible-but-adjacent.)

EXAM TRAP · The CDS advantages triad

The tempting confusion: A NOT item inserting a real CPOE advantage into the three CDS advantages.

The deciding clue: The three CDS advantages are increased quality of care and enhanced health outcomes; avoidance of error and adverse events; improved efficiency, cost-benefit and provider and patient satisfaction.

Stem wording that triggers it: Three items, not seven. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite the five rights of CDS in order and say who recommended them and who promotes them.
  2. Give three CPOE advantages and three disadvantages without looking at the table.
  3. Explain alert fatigue to a physician colleague and say what governance failure produced it.
  4. Explain why hybridized paper/electronic workflows are a patient safety problem, not just an efficiency problem.

Questions

9 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Clinical informatics impact since the late 1950s; mathematical models for diagnosis through present-day AI, APIs, SMART, FHIR and SMART on FHIR
  • CDS definition: a category of concepts and methods designed to provide patient-specific clinical information to a healthcare provider at the point of care
  • Ultimate goal of patient safety and improved patient experience; good build design and implementation providing better outcomes, improved overall quality, reduced cost, improved documentation consistency and reliability, and enhanced clinician experience
  • Informaticists translate workflow into CDS design and build; acceptance and adoption of CDS critical for successful implementation
  • CDS typically implemented within an EHR as order sets, condition-specific clinical alerts, access to reference information (info buttons) and passive/active generalized alerts; also in patient portals, HIEs, mobile applications and other health IT systems
  • Up to 17 years for translational research to reach clinical practice; maintaining current evidence-based content required for successful CDS; skilled workflow assessments, governance and maintenance a must
  • Medical knowledge doubling approximately every eight years; physician knowledge base outdated quickly after graduation; keeping up by reading journal articles impractical due to volume and lack of time
  • Deming quotation that a bad system will beat a good person every time; bad design and build causing implementation failure regardless of governance or expert opinion
  • CPOE advantages: averting handwriting issues; drug/drug, drug/food, drug/allergy alerts; formulary recommendations; safer or lower cost; economic savings; better billing turn around; faster order transmission to lab/pharmacy/radiology
  • CPOE disadvantages: perceived as more work for clinicians; provider coding requirements; bad use of CDS in design and maintenance; duplicate alert drop-down issue; never-ending system demands; hybridized paper/electronic workflows; constantly changing evidence and technology; overdependence on CDS
  • CPOE as computerized provider order entry / computerized practitioner order entry
  • 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
  • Disadvantages of CDS: alarm/alert fatigue; clinical burnout and documentation burden; delegation of order entry to other clinicians; data integrity; auto-population; design and implementation issues; lack of maintenance and governance
  • Five rights framework recommended by Osheroff et al., adopted and promoted as best practice by AHRQ: the right information, to the right person, in the right intervention format, through the right channel, at the right time in the workflow
  • Five rights detail: right decision-makers involved, end users and healthcare team included, evidence-based recognized guidelines, actionable and not too much information; determining who needs to see the CDS and whether they are qualified to use it; alerts passive or actionable, order sets, info buttons; channels of EHRs, HIEs, patient portals, CPOE and forms; timing in the workflow, workflow analysis and closing the loop
  • Need for increased usability relating directly to CPOE; less use of order systems as designed reduces CDS impact and alerts the incorrect people; providers must be well trained, well informed and satisfied with usability
  • CDS increasingly leveraging machine learning and AI; algorithms ingesting large data quantities, identifying patterns and returning detailed results
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.

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 · Source: Clinical Data Analytics Tools; Clinical Outcomes; Operational Outcomes; Common Data Analytics Tools; Summary

L3.6 · Clinical Data Analytics — Outcomes, SMART, Data Quality and Analytics Tools

Walkthrough

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 retrospective or predictive, informatics plays a vital role. Outcomes are a top goal, necessary to meet the goals set for providers and facilities, including lowering cost and improving the patient experience. This requires defining and understanding both clinical outcomes and operational outcomes.

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. Per McBride & Tietze: "data management, measures, and analytics are the foundations of improvement." Data warehouses — retrospective storage of data — can include clinical and operational data.

Clinical vs. operational outcomes

Clinical outcomes 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). Facilities often benchmark or compare themselves to other comparable facilities based on a shared standard, and this ranking is usually available to the public.

Operational outcomes 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. The source's example: if an academic department has a goal of increasing diversity, the department might have separate outcomes addressing recruitment of more diverse students and recruitment of more diverse faculty.

SMART

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

Outcomes should be SMART:

  1. Specific
  2. Measurable
  3. Attainable
  4. Realistic
  5. Timely

Note the source's wording: Attainable, Realistic and Timely — not "achievable," "relevant" or "time-bound." Other versions of SMART exist in general management literature; the exam follows this chapter.

Working with a data set

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.

Tools available for data analysis include Microsoft Excel, IBM SPSS, Tableau, business intelligence software and many more.

When you have identified and opened your data file, start with a visual inspection:

  1. What rows and columns do the data set reflect?
  2. How are the data structured?
  3. Are there visibly missing data apparent in the file?
  4. Do they appear to be sorted in some order?
  5. What variables in the data set represent dependent, independent and grouping variables?

The first question is about structure — what the rows and columns actually represent. That is the exam's answer to "an analyst receiving an unfamiliar clinical data set should first determine..."

Data integrity problems

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. The more common ones:

  1. Wrong patient data
  2. Height/Weight inaccuracies impacting drug calculations
  3. Allergies and medications documentation inaccuracies or omissions
  4. "Fat finger" errors — physically typing or entering the wrong data
  5. Overall missing data — forgetting, time constraints, fraudulent documentation
  6. Not documenting real time — e.g. a sepsis alert dependent on vital signs data entry

That last one is the source's own example of a timing failure defeating decision support, and it is directly tested.

Common data analytics tools and terminology (Table 3.13)

ToolPurpose / definitionExample
FieldsVertical column in a database that contains data with common characteristics for the entire record"First Name", "Last Name", "Date of Birth"
RecordsHorizontal rows in a database containing different pieces of data belonging to a given entityAll of the fields related to the row of "Billy"
TablesConsists of all records; combinations of all fields and records togetherAll horizontal and vertical rows together
ReportsAlternate view of data; typically assembled from a queryGenerally generated on paper, can also be electronic for distribution
QueryProcess of selecting desired records; pulling the dataPulling all female patients older than 50 with a history of colon polyps
Graphs and ChartsTool for examining and presenting dataScatter plot, pie charts, bar charts, flowcharts
Control ChartsTool for looking at a process over timeCommon and special-cause variation, upper and lower control limits
Predictive ModelingInstead of retrospective data analytics, the data is used to predict future outcomesPulling last five years of financial data to predict next year's budget needs

Fields are vertical columns. Records are horizontal rows. That pair is directly examinable and easy to invert under pressure.

For showing change in a single measure across twelve months, the tool for looking at a process over time is the control chart — the source assigns that job to control charts specifically, distinguishing them from graphs and charts generally, which examine and present data.

Big picture

This section supplies the analytics vocabulary the exam uses in Chapter 3 and again in Chapter 4. Three things carry the item load: SMART in the source's exact wording, the fields/records/tables distinction, and data quality failure modes.

The most conceptually interesting idea here is the timing failure: a sepsis alert that never fires because vital signs were documented hours late. The rule was correct, the data was correct, and the outcome was still a miss — because the data arrived after the decision point. That is a data integrity / real-time documentation failure, not a rule-logic failure.

Where it fits: Chapter 4's process improvement and Chapter 9's comparative analytics both build on this vocabulary.

Key concepts

SMART (source wording)

In plain English: Specific, Measurable, Attainable, Realistic, Timely.

Technical meaning: The acronym recommended in outcome development to assure a measurable outcome is designed.

Picture it: The source says Attainable, Realistic and Timely. Other literature says achievable, relevant, time-bound. Follow the chapter.

Clinical vs. operational outcomes

In plain English: Changes in the patient's health, versus improvements in how the place runs.

Technical meaning: Clinical outcomes relate to specific changes in health or health quality resulting from care received — readmission rates, CAUTIs. Operational outcomes are specific and measurable statements about improvements to processes or services, each flowing from a more general unit goal.

Picture it: Readmission rate is clinical. Reducing discharge turnaround is operational.

Fields vs. records

In plain English: Columns versus rows.

Technical meaning: A field is a vertical column in a database containing data with common characteristics for the entire record. A record is a horizontal row containing different pieces of data belonging to a given entity.

Picture it: 'First Name' is a field. Everything about Billy is a record.

Control chart

In plain English: Watching a process over time to see if it is behaving.

Technical meaning: A tool for looking at a process over time, showing common and special-cause variation with upper and lower control limits.

Picture it: Time on the horizontal axis and limits on the chart — that is what distinguishes it from a bar chart.

Real-time documentation failure

In plain English: Right rule, right data, too late.

Technical meaning: Not documenting in real time is a named data integrity problem — for example, a sepsis alert dependent on vital signs data entry failing because the data arrives late.

Picture it: The rule never fired because the input was not there when the decision was made.

Real-world examples

An analyst opens an unfamiliar extract. Before running anything, they establish what the rows and columns represent — the source's first visual inspection question, and the difference between analysis and guessing.

A quality team plots monthly CAUTI rates with control limits over twelve months and sees one point outside the upper limit. Common-cause variation and special-cause variation are the source's own vocabulary for reading that chart.

Distinctions & exam traps

EXAM TRAP · SMART expansion

The tempting confusion: Answering 'achievable, relevant, time-bound' from general management literature.

The deciding clue: The chapter says Specific, Measurable, Attainable, Realistic, Timely.

Stem wording that triggers it: Acronym items change one or two words. Follow the source. (One altered element.)

EXAM TRAP · Fields vs. records

The tempting confusion: Inverting vertical and horizontal under time pressure.

The deciding clue: Fields are vertical columns; records are horizontal rows.

Stem wording that triggers it: 'Vertical column ... common characteristics for every record' names the field. (Adjacent term.)

EXAM TRAP · Data quality problems EXCEPT

The tempting confusion: A NOT item inserting a plausible technical problem — network latency, storage cost, interface downtime — into the six named data quality issues.

The deciding clue: The six are wrong patient data, height/weight inaccuracies affecting drug calculations, allergy and medication inaccuracies or omissions, fat-finger errors, overall missing data, and not documenting in real time.

Stem wording that triggers it: Circle EXCEPT, then find the option that is an infrastructure problem rather than a data problem. (Category outlier.)

EXAM TRAP · Late documentation vs. rule error

The tempting confusion: Treating an alert that failed to fire as a decision-support logic failure.

The deciding clue: If the vital signs were documented hours late, the rule never had the data at the decision point. That is a real-time documentation / data integrity problem.

Stem wording that triggers it: 'Documented hours late' names the timing failure, not the rule. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite SMART in the chapter's own words and say where the common alternative wording differs.
  2. Distinguish a clinical outcome from an operational outcome with one example of each from your own organization.
  3. Define fields, records and tables without inverting them.
  4. Explain the sepsis alert example: what failed, and what did not fail.

Questions

13 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Clinical informatics centered on clinical data: entry, storage and use; retrospective and predictive analytics; outcomes as a top goal for lowering cost and improving patient experience; defining and understanding clinical and operational outcomes
  • Regulatory and accreditation requirements (Joint Commission, DNV GL) making functional data management challenging; data management, measures and analytics as the foundations of improvement; data warehouses as retrospective storage including clinical and operational data
  • Clinical outcomes related to specific changes in health or health quality resulting from care received; measurable through activity metrics such as hospital readmission rates and catheter-associated urinary tract infections; benchmarking against comparable facilities on a shared standard with publicly available rankings
  • Operational outcomes as specific and measurable statements about improvements to processes or services, each flowing directly from a more general goal of the unit; academic department diversity example with separate student and faculty recruitment outcomes
  • SMART outcomes: Specific, Measurable, Attainable, Realistic, Timely
  • Data process from learning about data, manipulating it, creating information and distributing knowledge and wisdom; determining data type (nominal, ordinal, interval, ratio) to examine or explore the data set
  • Analysis tools including Microsoft Excel, IBM SPSS, Tableau and business intelligence software
  • Visual inspection questions: what rows and columns the data set reflects; how the data are structured; visibly missing data; apparent sort order; which variables represent dependent, independent and grouping variables
  • Data integrity issues affecting accuracy or validity over the lifecycle: wrong patient data; height/weight inaccuracies impacting drug calculations; allergies and medications documentation inaccuracies or omissions; fat finger errors; overall missing data from forgetting, time constraints or fraudulent documentation; not documenting real time, e.g. sepsis alert dependent on vital signs data entry
  • Fields: vertical column in a database containing data with common characteristics for the entire record
  • Records: horizontal rows in a database containing different pieces of data belonging to a given entity
  • Tables: all records; combinations of all fields and records together
  • Reports: alternate view of data typically assembled from a query, generated on paper or electronically for distribution
  • Query: process of selecting desired records, pulling the data
  • 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: using data to predict future outcomes rather than retrospective analytics, e.g. five years of financial data to predict next year's budget needs
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 4 · Source: Introduction

L4.1 · Introduction — The Systems Development Life Cycle and the Analysis Phase

Walkthrough

Where healthcare IT spending sits

Per Deloitte's 2018 Global CIO Survey, only about 4.26% of revenues were spent on technology in the healthcare services industryup three quarters of a percent since the previous survey in 2017. In early 2019, Forrester Research and Gartner both predicted spending on healthcare would increase to nearly 9%. Gartner's breakdown showed 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.

The 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.

The five phases named:

  1. Investigation/planning
  2. Analysis
  3. Design
  4. Implementation
  5. Maintenance

During the planning phase — the phase prior to analysis — the initial idea for a 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, it then moves to the analysis phase.

What the analysis phase is for

The purpose of the systems analysis phase is to understand the business requirements and to build a logical model of the new system.

In this phase:

  • Requirements modeling is completed
  • Business processes are described and defined
  • Data, process and object modeling take place
  • A systems requirements document is produced describing the management and user requirements, alternative plans and costs, and an analysis of the recommendation

The four objectives that should be met during systems analysis:

  1. Gather, analyze and validate technical, functional and nonfunctional requirements.
  2. Evaluate the alternatives and prioritize the requirements.
  3. Examine the information needs of end users and establish the systems goals.
  4. Create software, hardware and network requirements documentation.

The failure chain

The source states it in three sentences, and the exam tests it directly:

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.

End user input → analysis quality → design quality → project outcome. Break the first link and everything downstream degrades. Note that validation with end users is part of objective 1 — gathering requirements is not the same as validating them.

Big picture

Chapter 4 owns the front half of the delivery lifecycle: understand the need, define the requirements, justify the investment. Chapter 5 then designs to those requirements, Chapter 6 buys and implements, Chapter 7 tests.

The exam's recurring move in this chapter is phase placement — given an activity, which SDLC phase does it belong to? Analysis gathers and validates requirements and evaluates alternatives. Implementation configures, trains and activates. Design produces specifications.

Where it fits: the four analysis objectives here are the direct upstream of Chapter 5's technical specification and Chapter 7's test cases. Requirements that were never validated cannot produce meaningful acceptance criteria.

Key concepts

SDLC

In plain English: The full arc from idea to ongoing upkeep.

Technical meaning: A process used to develop an information system — including requirements, validation, training and user ownership — through investigation/planning, analysis, design, implementation and maintenance.

Picture it: Five phases. Planning precedes analysis; maintenance never ends.

The systems analysis phase

In plain English: Work out what is actually needed, before anyone designs anything.

Technical meaning: Its purpose is to understand the business requirements and build a logical model of the new system, producing a systems requirements document covering management and user requirements, alternative plans and costs, and an analysis of the recommendation.

Picture it: A logical model, not a technical one. The technical model is Chapter 5's job.

The requirements failure chain

In plain English: Skip the users and the project fails three steps later.

Technical meaning: Lack of end user input means a weak analysis; a weak analysis leads to poor design; poor design can lead to failed projects.

Picture it: The failure surfaces at design or later, which is why the cause is easy to misdiagnose.

Real-world examples

A team documents 200 requirements from department directors and never shows them to the nurses who will use the system. The build passes internal review and fails at go-live. The source names that exact sequence.

Distinctions & exam traps

EXAM TRAP · Analysis vs. implementation activities

The tempting confusion: Placing requirements gathering in implementation, or training in analysis.

The deciding clue: Analysis gathers, analyzes and validates requirements, evaluates alternatives and prioritizes. Implementation configures, trains and activates.

Stem wording that triggers it: 'Belongs to the systems analysis phase rather than implementation' is a phase-placement item. (Plausible-but-upstream.)

EXAM TRAP · Gathering vs. validating requirements

The tempting confusion: Treating documented requirements as validated requirements.

The deciding clue: The objective is to gather, analyze AND validate — validation with end users is a separate act.

Stem wording that triggers it: 'Documented but never validated' points to the downstream design and project failure. (Plausible-but-upstream.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the five SDLC phases in order and say what happens in the one before analysis.
  2. Give the four objectives of the systems analysis phase.
  3. Recite the failure chain from missing end user input to failed project.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Deloitte 2018 Global CIO Survey: about 4.26% of revenues spent on technology in healthcare services, up three quarters of a percent since 2017; Forrester and Gartner early-2019 predictions of nearly 9%; Gartner breakdown showing money allocated mainly to supporting and maintaining current infrastructure rather than growing and transforming the business
  • SDLC as a process to develop an information system including requirements, validation, training and user ownership through investigation/planning, analysis, design, implementation and maintenance
  • Planning phase precedes analysis; initial project idea developed; feasibility, objectives and scope examined; current problems considered; recommended solution proposed; project moves to analysis if worth pursuing
  • Purpose of the systems analysis phase: understand business requirements and build a logical model of the new system; requirements modeling; business processes described and defined; data, process and object modeling; systems requirements document describing management and user requirements, alternative plans and costs, and analysis of the recommendation
  • Four systems analysis 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 as key; lack of end user input meaning a weak analysis; weak analysis leading to poor design; poor design leading 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 · Source: Healthcare Problems and Opportunities for IT Implementation

L4.2 · Healthcare Problems and Opportunities for IT Implementation

Walkthrough

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. A small group, or a project champion, identifies this need and then tries to mobilize a larger group of stakeholders. During systems analysis, the perceived gaps and opportunities are documented, with a strong focus on describing the desired benefits and why, and it may include the development of a high-level business case that compares the benefit with estimated costs.

Problems with traditional healthcare systems

  1. Poor quality of health information including redundancy and inconsistent standards for the collection and sharing of information
  2. Inability to obtain health information at the time and place where it is needed
  3. The data collected in health records is limited
  4. Some registers in health exist only in paper form, which limits quick access
  5. Inadequate procedures for the implementation of information systems not related to the relevant organizational changes
  6. 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
  7. Systems have been developed primarily to support the work of the administrative unit, only slightly adjusted to the needs of patients, doctors and other users
  8. Lack of computerized practitioner order information and histories for drugs and other substances, medical supplies, catalogs and lab test results
  9. Lack of an integrated, interoperable EHR, image and film archiving and associated communication systems, result analysis mechanisms, prescription error alert systems and electronic monitoring of high care patients

Opportunities — the five benefit categories

Hospital information system (HIS), healthcare information system and patient data management system (PDMS) all 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, integrating clinical, financial and administrative systems.

CategoryNamed benefits
OperationalIncreases 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
ManagerialImproves 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
StrategicSupports more effective planning, increases synchronous-asynchronous collaboration among actors (all human and non-human users that interact with the system), improves relationships with suppliers, improves knowledge sharing, improves population's health and increases survival rates and quality of life
IT InfrastructurePromotes reusability of objects, reduces development risk, supports 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
OrganizationalReduces 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 opportunity are spread across clinical, administrative and financial functions as well as infrastructure.

Applications by function

Clinical. EHRs standardize how 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 has been establishing an industry standard. Named clinical systems: CPOE (replacing conventional order cataloging and fulfillment, enhancing tracking, logistic synchronization and cost-effectiveness); clinical decision-support system (CDSS) giving informative guidelines regarding medication and procedures, including warning systems for high-risk medications and processes; PACS integrating inputs from multiple radiological and diagnostic tools; RFID to track patients within a medical unit; monitoring systems collecting pulse rate, temperature level, blood pressure and other metabolic/respiratory signals; automated dispensing machines (ADMs); and electronic materials management (EMM) systems operating like resource planning systems for pharmaceuticals, new drug development and coding.

Per a 2016 report, adverse drug events account for more than 3.5 million physician office visits and 1 million emergency department visits each year, and preventable medication errors impact more than 7 million patients and cost almost $21 billion annually across all care settings.

Administrative and financial. General ledger operations (revenue and cash flow, expenses, purchases, day-to-day transactions), billing, cost accounting systems, payroll, personnel management and integrated human resource functions, patient registration and booking, and electronic management of materials. Enterprise relational database management systems (RDBMSs) support employee management, role definition, reward and recognition support and performance development.

Infrastructure and security. Biometric sensorsfingerprint or palm scanners, voice recognition systems and eye scanners — for movement and access control, enhancing accountability in system access and supporting user logging. Also bar coding systems for medication grouping, ordering, cataloging and stock control, closed-circuit TV cameras and night infrared cameras. Patient information access logging is important for confidentiality and professionalism. The baseline network infrastructure includes servers, end user computer stations, switches, network access points, all associated cabling and external access infrastructure.

Big picture

This section is mostly context rather than a direct question source, but it supplies the framing the rest of the chapter uses: projects start from a documented gap, championed by someone, justified by a benefit case.

The five benefit categories — operational, managerial, strategic, IT infrastructure, organizational — are worth holding because Chapter 9 uses the same operational/managerial/strategic split when discussing planning horizons.

Where it fits: the problems list here is the raw material for the needs analysis in Lesson 4.3, and the benefit categories feed the cost–benefit analysis in Lesson 4.6.

Key concepts

Project champion

In plain English: The person who notices the gap and gathers people around it.

Technical meaning: A small group or a project champion identifies the need for change and mobilizes a larger group of stakeholders; gaps and opportunities are documented with a strong focus on describing the desired benefits and why.

Picture it: The champion's product is a documented gap plus a benefit argument, not a product choice.

The five benefit categories

In plain English: Day-to-day, management, long-range, technical, and how the place runs.

Technical meaning: Operational, managerial, strategic, IT infrastructure, and organizational benefits of integrated healthcare systems.

Picture it: Same operational/managerial/strategic ladder that Chapter 9 uses for planning.

HIS / PDMS

In plain English: The integrated system that runs the whole place.

Technical meaning: Hospital information system, healthcare information system and patient data management system all refer to integrated healthcare information systems — complete solutions for managing medical, administrative, financial and legal data, aiming to support patient care, achieve optimal financial performance and streamline administration.

Picture it: Three names, one concept, four data domains.

Real-world examples

A clinical director documents that referral bookings take up to two weeks and builds a benefit case around reduced wait time and recovered revenue. That documented gap plus benefit statement is what moves a project out of the planning phase.

Distinctions & exam traps

EXAM TRAP · Benefit category placement

The tempting confusion: Assigning 'improves allocation of resources' to strategic, or 'improves population's health' to operational.

The deciding clue: Managerial covers control, decision support and resource allocation. Strategic covers planning, collaboration, supplier relationships, knowledge sharing and population health.

Stem wording that triggers it: Population health and survival rates are strategic. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the five benefit categories of integrated healthcare systems and give one benefit from each.
  2. List four of the named problems with traditional healthcare systems.
  3. Explain what a project champion actually produces at this stage.

Questions

No canonical items map directly here. The section supplies the problem framing and benefit categories that Lessons 4.3 and 4.6 build on.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Improvements emerging from a need for change: existing system not meeting evolving needs, or emerging technologies allowing radically better systems; small group or project champion identifying the need and mobilizing stakeholders; gaps and opportunities documented with focus on desired benefits and why; possible high-level business case comparing benefit with estimated costs
  • Problems with traditional healthcare systems: poor quality of health information including redundancy and inconsistent collection and sharing standards; inability to obtain health information at the time and place needed; limited data collected in health records; paper-only registers limiting quick access; inadequate implementation procedures not tied to relevant organizational changes; existing solutions not ensuring interoperability, making information management impossible and adversely affecting accuracy, integrity, comparability and completeness; systems developed primarily for the administrative unit rather than patients, doctors and other users; lack of computerized practitioner order information and histories for drugs, substances, medical supplies, catalogs and lab results; lack of an integrated interoperable EHR, image and film archiving and communication systems, result analysis mechanisms, prescription error alert systems and electronic monitoring of high care patients
  • HIS, healthcare information system and PDMS as terms for integrated healthcare information systems; complete solutions for medical, administrative, financial and legal data; aim to support patient care, achieve optimal financial performance and streamline administration; integration of clinical, financial and administrative systems
  • Operational benefits: increased productivity, reduced cost, improved data quality, improved data sharing/flow, better access to data, easier data exchange, improved data presentation, reduced medical errors, satisfaction
  • Managerial benefits: improved managerial control, more understanding and control of processes, decision-making support, improved resource allocation, improved quality of care, improved work efficiency, increased performance, increased return on investment
  • Strategic benefits: more effective planning, increased synchronous-asynchronous collaboration among actors (all human and non-human users interacting with the system), improved supplier relationships, improved knowledge sharing, improved population health, increased survival rates and quality of life
  • IT infrastructure benefits: reusability of objects, reduced development risk, support for e-healthcare and telemedicine-based patient support models, non-invasive solutions, process integration, object/component integration, data integration, real-time integration, integration of custom and packaged systems and e-business solutions
  • Organizational benefits: reduced hospitalization need or length of stay, reduced waiting times, reduced cancelled operations, effective clinical and administrative management, increased business efficiency, clinical decision-making support, reliable data, increased data analysis, reduced paperwork
  • Clinical applications: EHR standardization of entry, storage and retrieval across organizations; industry standard as the biggest challenge; CPOE replacing conventional order cataloging and fulfillment to enhance tracking, logistic synchronization and cost-effectiveness; CDSS giving guidelines on medication and procedures including high-risk warnings; PACS integrating multiple radiological and diagnostic inputs; RFID patient tracking; monitoring systems collecting pulse rate, temperature, blood pressure and metabolic/respiratory signals; automated dispensing machines; electronic materials management systems
  • 2016 report: adverse drug events accounting for more than 3.5 million physician office visits and 1 million emergency department visits annually; preventable medication errors impacting more than 7 million patients and costing almost $21 billion annually across all care settings
  • Administrative and financial functions: general ledger operations covering revenue and cash flow, expenses, purchases and day-to-day transactions; billing, cost accounting, payroll, personnel management, integrated human resource functions, patient registration and booking, electronic materials management; enterprise RDBMSs for employee management, role definition, reward and recognition support and performance development
  • Infrastructure and security: biometric sensors including fingerprint or palm scanners, voice recognition and eye scanners for movement and access control, enhancing accountability and user logging; bar coding for medication grouping, ordering, cataloging and stock control; closed-circuit TV and night infrared cameras; patient information access logging for confidentiality and professionalism; baseline network infrastructure of servers, end user computer stations, switches, network access points, cabling and external access infrastructure
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 · Source: Needs Analysis in Healthcare Facilities; Functional Needs Assessment; Requirements Analysis; Document Analysis; Additional Inventories

L4.3 · Needs Analysis, Gap Analysis and Requirements

Walkthrough

Needs analysis = gap analysis

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 organization's systems to determine whether business requirements are being met and, if not, what steps should be taken to ensure they are met successfully.

These gaps help inform the overall needs assessment. The examinable phrasing is the difference between current capability and required capability.

The five needs analysis tools

Needs analysis can be conducted through a variety of tools. The most common include:

  1. Observation
  2. Interviews
  3. Review of documentation
  4. Surveys
  5. Data analysis

Five tools, and they are all information-gathering methods. A NOT item here inserts something that is not a gathering method — a vendor demonstration, a contract negotiation, a budget approval.

Operational needs categories

  • Staff productivity and satisfaction — reduces time wasted on administrative work, enhances patient attendance time, reduces unnecessary routines, improves employee satisfaction and reduces fatigue from extensive overtime; better productivity leads to increased patient volumes
  • Increased revenue and cost optimization — larger admissions and discharges per month following shortened lengths of stay, reduced unit costs for bulk purchases, improved ability to meet overhead; cost optimization through bulk purchases, efficient stock control and reduced cost per day for each patient
  • Patient safety — reducing adverse drug events from wrong prescriptions, admissions following ADEs, errors in surgical procedures, blood transfusions, and malpractice expenses including corrective procedures, court litigations and compensations
  • Quality of caretime of delay, time of treatment, appropriateness of procedures and drugs, professionalism, confidentiality and courtesy of staff; also recognition and accreditations, complication management, physician or nurse time with patients and reduced length of stay
  • Patient access to servicesdelay time for lab reports, billing, online viewing and scheduling, preventive care management and outpatient appointment bookings

Needs summary and prioritization

What is required is sufficient planning to implement safe, sustainable and cost-effective IT practices to help healthcare in four areas: (1) administrative, (2) operational, (3) patient-related and (4) industry-related functions.

Prioritization differs by perspective:

  • From an individual facility's perspective: patient safety, followed by profitability, then ease of processes, and lastly industry standardization.
  • From the healthcare industry's perspective: patient safety and security, professionalism, standardization, profitability and ease of processes.

Ease of processes is in most cases tied with profitability. The project must address IT implementation issues from both perspectives and attempt to strike a balance. The needs prioritization process helps drive the likelihood of project acceptance.

Patient safety is first from both perspectives. The source's reasoning: 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 in their other operations.

Functional needs assessment

Describes the key capabilities or application requirements for achieving the benefits of the system as the organization has envisioned it. It matters because every organization begins from a different starting point, every organization has different needs and every vendor offers a different approach.

Best achieved through surveying users and reviewing use cases. Users should be asked to identify what functionality they need and perhaps rank/prioritize them. Even where a user's understanding of what is possible is limited early on, capturing it matters because you may need to plan for additional functionality in later phases. It also allows users to be more engaged in the process, which is a critical component of implementation success.

A use case is a scenario that describes a system behavior as it responds to a request that originates outside of that system, describing the interaction between the actor who initiated the interaction (such as a clinician) and the system itself. The use case approach is often easier for clinicians to understand. Current functional capabilities can be inventoried, helping users see the scope of current capabilities and establish a foundation for understanding what essential functional capability may be missing.

Requirements analysis

The documented record of what the system actually does. It is:

  • critical to keep the project aligned with the identified scope
  • essential to the testing processthe information gathered will produce test cases that can then be used to validate that the system meets the project requirements
  • the document describing the future state and the primary input document for estimating resources, cost and time needed for the project

Requirements are categorized as: 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 and inventories

Workflow and process mapping should also be accompanied by a collection of all associated documents and a document analysis, which helps define the data requirements associated with each process.

Additional inventories:

  • Applications inventoryidentifies all applications that currently exist and how they may or may not be related to one another, helping identify functional requirements as the new system leverages and interacts with current applications, and identifying additional applications that could be replaced
  • Reports inventorya document of all current reports being used or produced by current systems, informing what may need to be produced from the new system

Big picture

The whole point of this section is that you cannot recommend a solution before you have defined the problem. That principle produces one of the exam's most repeatable answers: when a stem describes someone proposing a product before the requirement exists, the correct action is to go back and define the need.

Where it fits: the requirements analysis produced here becomes Chapter 5's specification input and Chapter 7's test cases. The source says so explicitly — test cases come from the requirements analysis.

Nearby concepts to keep straight: needs analysis and gap analysis are the same activity in this chapter. The functional needs assessment is a component within it, focused on application capabilities.

Key concepts

Gap analysis

In plain English: The distance between what you can do and what you need to do.

Technical meaning: A method of assessing the differences in performance between an organization's systems to determine whether business requirements are being met and, if not, what steps should be taken to ensure they are met successfully. Also called the needs analysis.

Picture it: 'Difference between current capability and required capability' is the exam phrasing.

The five needs analysis tools

In plain English: Watch, ask, read, survey, analyze.

Technical meaning: Observation, interviews, review of documentation, surveys and data analysis.

Picture it: All five gather information. Anything that decides or buys is not on this list.

Use case

In plain English: A story about what the system does when someone asks it something.

Technical meaning: A scenario describing a system behavior as it responds to a request originating outside the system, describing the interaction between the initiating actor (such as a clinician) and the system.

Picture it: Often easier for clinicians to understand than a requirements list.

Requirements analysis

In plain English: The written record of what the system will do.

Technical meaning: The documented record of what the system actually does; keeps the project aligned with scope; produces the test cases used to validate that the system meets project requirements; describes the future state; is the primary input for estimating resources, cost and time.

Picture it: If it is not in here, it cannot be tested for later.

Needs prioritization

In plain English: Safety first, from both points of view.

Technical meaning: Facility perspective: patient safety, profitability, ease of processes, industry standardization. Industry perspective: patient safety and security, professionalism, standardization, profitability, ease of processes.

Picture it: Both lists start with patient safety; the orderings diverge after that.

Real-world examples

A department asks IT to buy a specific scheduling product. Nobody has written down what problem it solves. The consultative response is to define the need first — the source's whole argument in this section.

An applications inventory reveals three overlapping systems doing patient outreach. That finding does two things at once: it shapes requirements and it identifies systems the new one could replace.

Distinctions & exam traps

EXAM TRAP · Needs analysis tools EXCEPT

The tempting confusion: A NOT item mixing observation, interviews, document review, surveys and data analysis with something from procurement or governance.

The deciding clue: All five named tools are information-gathering methods.

Stem wording that triggers it: Circle EXCEPT, then find the option that is not a way of gathering information. (Category outlier.)

EXAM TRAP · Solution before problem

The tempting confusion: Choosing a vendor evaluation, a pilot or a cost estimate as the first step when a solution has been proposed but the need is undefined.

The deciding clue: The needs analysis characterizes the problem, defines scope and value and establishes the framework for what the system will do.

Stem wording that triggers it: 'Before recommending a specific new system, the analyst should first' names defining the requirement. (Plausible-but-upstream.)

EXAM TRAP · Gap analysis naming

The tempting confusion: Confusing gap analysis with cost–benefit analysis or requirements analysis.

The deciding clue: Gap analysis identifies the difference between current and required capability. Requirements analysis records what the system will do. CBA compares benefits against costs.

Stem wording that triggers it: 'The difference between current capability and required capability' names gap analysis. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define gap analysis in the source's terms and say what other name the chapter gives it.
  2. Name the five needs analysis tools without looking.
  3. Explain why the requirements analysis matters to testing, not just to design.
  4. Give the facility priority order and the industry priority order, and say what they have in common.

Questions

4 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Needs analysis characterizing the problem, performing a cost–benefit feasibility study, defining scope and value and establishing the framework for what the system will do; also referred to as a gap analysis
  • Gap analysis definition: a method of assessing differences in performance between an organization's systems to determine whether business requirements are being met and, if not, what steps should be taken to ensure they are met successfully; gaps inform the overall needs assessment
  • Five most common needs analysis tools: observation, interviews, review of documentation, surveys, data analysis
  • Operational needs — staff productivity and satisfaction: reduced administrative time, enhanced patient attendance time, reduced unnecessary routines and non-work-related duties, improved employee satisfaction, reduced fatigue from overtime, increased patient volumes
  • Increased revenue and cost optimization: larger admissions and discharges per month, shortened lengths of stay, reduced unit costs for bulk purchases, improved ability to meet overhead; cost optimization through bulk purchases, efficient stock control and reduced cost per patient day
  • Patient safety needs: adverse drug events from wrong prescriptions, admissions following ADEs, surgical procedure errors, blood transfusion errors, malpractice expenses including corrective procedures, court litigations and compensations
  • Quality of care: time of delay, time of treatment, appropriateness of procedures and drugs, professionalism, confidentiality and courtesy; recognition and accreditations, complication management, physician or nurse time with patients, reduced length of stay
  • Patient access to services: delay time for lab reports, billing, online viewing and scheduling, preventive care management, outpatient appointment bookings; automation of routine work not requiring case-specific diagnosis; nonmonetary benefits of good patient–physician relationships and improved community health
  • Needs summary: safe, sustainable and cost-effective IT practices across administrative, operational, patient-related and industry-related functions; seamless backbone IT platform integrating the four needs with sustainable controls
  • Needs prioritization: facility perspective of patient safety, profitability, ease of processes, industry standardization; industry perspective of patient safety and security, professionalism, standardization, profitability, ease of processes; ease of processes usually tied with profitability; project must balance both perspectives; prioritization drives likelihood of project acceptance; safety failures risking license loss
  • Functional needs assessment describing key capabilities or application requirements for achieving envisioned benefits; necessary because organizations differ in starting point and needs and vendors differ in approach; achieved through surveying users and reviewing use cases; users identify and rank functionality; planning for later-phase functionality; user engagement critical to implementation success
  • Use case as a scenario describing system behavior responding to a request originating outside the system, describing interaction between the initiating actor and the system; easier for clinicians to understand; inventory of current functional capabilities establishing scope and revealing missing capability
  • Requirements analysis as the documented record of what the system does; keeps the project aligned with scope; essential to testing since it produces test cases validating that the system meets requirements; describes the future state; primary input for estimating resources, cost and time; informs needs assessment and prioritization
  • Requirement categories: 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; network
  • Document analysis accompanying workflow and process mapping, collecting associated documents and defining data requirements per process; vendor-provided tools or a spreadsheet
  • Applications inventory identifying existing applications and their relationships, informing functional requirements and identifying applications that could be replaced; reports inventory documenting current reports and informing what the new system must produce
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.

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.

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 · Source: Workflow and Process Mapping; Current Clinical Processes; Process Improvement; DMAIC; PDCA/PDSA

L4.4 · Workflow and Process Mapping, and Process Improvement

Walkthrough

What workflow and process mapping do

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 to support the functional data and technical strategies.

They also:

  • help identify broken processes and provide an opportunity to address them before a system automates them
  • help recognize the need for process improvement through automation
  • guide functional specifications where a product may not address all functionality an organization may need or want
  • help visualize the need for standard data structures
  • aid system configuration during implementation
  • provide scenarios to create test cases from
  • guide new users of the system regarding how the process will change

This can also be termed process redesign or process reengineering.

Workflow and process mapping identify how work is currently performed and the sequence of steps involved.

Named diagram tools: activity diagrams, swim lane charts, data flow diagrams, system flowcharts, entity relationship diagrams, class diagrams and use cases.

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. They use standard symbols, though different approaches and symbol sets may be used, e.g. ISO 5807 and Unified Modeling Language (UML).

Operations and processes in healthcare can be analyzed in four broad categories: administrative and financial, operational, process flow and standardization.

The referral example: the source's Figure 4.3 shows 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 delaysservice degradation for the patient and revenue loss for the care provider.

The key principle for the exam: mapping a broken process before automating it prevents you from automating the break.

Process improvement

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.

Other names: business process management (BPM), business process improvement (BPI), business process re-engineering and continual improvement process (CIP).

Everything everyone does in an organization is part of a process. To improve the organization, you must focus on the processes.

DMAIC

DMAIC stands for define, measure, analyze, improve and control. The DMAIC model is a data-driven quality strategy used to improve processes.

  1. Define the opportunity for improvement
  2. Measure the performance of the existing process
  3. Analyze the process to find any deficiencies
  4. Improve the process by addressing the root causes uncovered
  5. Control the improved process and future process performance to correct deviations before they result in defects and to prevent reverting back to the "old way"

The Control step has two jobs, both named: catch deviations before they become defects, and stop the organization sliding back.

PDCA / PDSA

PDCA/PDSA stands for plan, do, check/study and act. It is a cyclical model that is also iterative, following a four-stage management method used for the control and continuous improvement of processes.

StageWhat happens
PlanIdentify and analyze the problem or opportunity; develop hypotheses about the cause of the problem; decide which to test
DoTest the potential solution on a small scale; measure results
Check/StudyStudy results; measure effectiveness; decide whether the hypotheses are supported by the data or not
ActIf the pilot solution is successful, implement it

Two placements are directly tested:

  • Testing a potential solution on a small scale happens in Do, not Plan. Plan decides which hypothesis to test; Do runs the test.
  • After a successful pilot, the next step is Act — implement it. Not "check again", not "plan a second pilot."

Big picture

DMAIC and PDCA are the exam's two named improvement models, and the items test expansion and stage placement. Hold them apart by shape: DMAIC is a five-step data-driven strategy that ends in Control; PDCA is a four-stage cycle that ends in Act and starts over.

The workflow mapping material supplies the other reliable answer in this lesson: map the current state before you automate it, because automating a broken process makes it faster and no better.

Where it fits: Chapter 6 revisits workflow documents as maintained artifacts after go-live. Chapter 7 uses process maps as the source of test scenarios — the source says so here.

Key concepts

Process map / flowchart

In plain English: A picture of how the work actually flows today.

Technical meaning: A visual representation showing the boundaries of the process, the steps and the sequence in which the steps take place, using standard symbols; symbol sets include ISO 5807 and UML.

Picture it: 'Sequence of steps, decisions and handoffs in a current process' names the process map.

DMAIC

In plain English: Define, Measure, Analyze, Improve, Control.

Technical meaning: A data-driven quality strategy: define the opportunity; measure existing performance; analyze to find deficiencies; improve by addressing root causes; control to correct deviations before defects and prevent reverting to the old way.

Picture it: Five letters, five steps, and Control is the one people forget.

PDCA / PDSA

In plain English: Plan, Do, Check (or Study), Act — then go round again.

Technical meaning: A cyclical, iterative four-stage management method for control and continuous improvement. Plan identifies and analyzes the problem, develops hypotheses and decides which to test; Do tests on a small scale and measures; Check/Study studies results, measures effectiveness and decides whether hypotheses are supported; Act implements the successful pilot.

Picture it: Small-scale testing is Do. Implementing a successful pilot is Act.

Mapping before automating

In plain English: Fix the process first, or you will just automate the mess.

Technical meaning: Workflow and process mapping help identify broken processes and provide an opportunity to address them before a system automates them.

Picture it: The source is explicit that mapping happens before automation, not after.

Real-world examples

A team maps the referral booking process and finds a two-week wait produced entirely by communication handoffs, not clinical capacity. Automating the existing handoffs would have preserved the wait.

A unit pilots a new discharge checklist on one floor, measures results and finds the readmission signal holds. Under PDCA the next move is Act — implement it more widely.

Distinctions & exam traps

EXAM TRAP · DMAIC expansion

The tempting confusion: Substituting 'develop' for 'define', 'monitor' for 'measure', or 'implement' for 'improve'.

The deciding clue: Define, measure, analyze, improve, control.

Stem wording that triggers it: Acronym items change one word. Check all five. (One altered element.)

EXAM TRAP · PDCA stage placement

The tempting confusion: Placing small-scale testing in Plan, or implementation in Check.

The deciding clue: Plan decides which hypothesis to test. Do runs the small-scale test and measures. Check/Study evaluates. Act implements the successful pilot.

Stem wording that triggers it: 'Testing on a small scale' names Do; 'pilot succeeded, now what' names Act. (Plausible-but-upstream.)

EXAM TRAP · Current-state vs. future-state visualization

The tempting confusion: Choosing a single tool when the stem asks how to show the difference between the two states.

The deciding clue: Process mapping shows the current state; gap analysis identifies the difference between current and required capability.

Stem wording that triggers it: 'Difference between current-state and desired-state' calls for the combination, not one tool. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Expand DMAIC and say what the Control step is protecting against — both things.
  2. Walk PDCA and place these correctly: small-scale test, measuring effectiveness, implementing a successful pilot.
  3. Explain to a project sponsor why you map the current process before you automate it.
  4. Name four of the diagram tools the chapter lists for workflow and process mapping.

Questions

5 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Workflow and process mapping as mechanisms to understand current processes and how work is performed, to begin change management and support functional data and technical strategies
  • Identifying broken processes and addressing them before a system automates them; recognizing the need for process improvement through automation; guiding functional specifications where a product may not address all needed functionality; visualizing the need for standard data structures
  • Also termed process redesign or process reengineering; aids system configuration during implementation, provides scenarios to create test cases from, and guides new users on how the process will change
  • Diagram tools: activity diagrams, swim lane charts, data flow diagrams, system flowcharts, entity relationship diagrams, class diagrams, use cases
  • Process diagrams and flowcharts as visual representations showing process boundaries, steps and sequence; standard symbols with differing approaches and symbol sets such as ISO 5807 and UML
  • Healthcare operations analyzed in four broad categories: administrative and financial, operational, process flow, standardization
  • Lab report briefing process with repeated nurse contact attempts causing delay and fewer patients served; referral-patient booking process with up to two weeks between referral and appointment booking due to communication and work arrangement delays; service degradation for the patient and revenue loss for the provider; remote meetings, video and audio conferencing, web-based communication and patient portals, digital signing and registered mailing as remedies
  • Process improvement as identifying, analyzing and improving existing business processes to optimize performance, meet best practice standards or improve quality and user experience; alternate names business process management, business process improvement, business process re-engineering and continual improvement process
  • Everything everyone does is part of a process; improving the organization requires focusing on processes
  • DMAIC as define, measure, analyze, improve, control; a data-driven quality strategy; define the opportunity for improvement; measure performance of the existing process; analyze the process to find deficiencies; improve by addressing root causes uncovered; control the improved and future process performance to correct deviations before they result in defects and prevent reverting to the old way
  • PDCA/PDSA as plan, do, check/study, act; cyclical and iterative four-stage management method for control and continuous improvement; Plan identifies and analyzes the problem or opportunity, develops hypotheses about the cause and decides which to test; Do tests the potential solution on a small scale and measures results; Check/Study studies results, measures effectiveness and decides whether hypotheses are supported by the data; Act implements the pilot solution if successful
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.

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.

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 · Source: Deficiencies in Current IT Healthcare Practices; Alternative Approaches to Current Healthcare Processes; Comparative Analysis of Alternatives

L4.5 · Deficiencies, Alternatives and Comparative Analysis

Walkthrough

The four named deficiency areas

These obstacles are analyzed based on the industry's key performance indicators (KPIs).

  1. Patient support and satisfactionunnecessarily high numbers of patients leave healthcare units without treatment due to long waits; physicians see fewer patients per day when lengthy delays are caused by lack of proper equipment; slow systems lead to extra work for available personnel, causing degradation in service quality. Patient support and safety correlate with employee retention and employee satisfactionwhen healthcare workers are overwhelmed, they perform more poorly and have higher exit rates.
  2. Reduction in revenue generation — delays lead to low numbers of attended patients per day, patients leaving unattended, and lost potential clients who might have been referred; facilities incur extra expenses due to overtime work by doctors and nurses; inefficient facilities require significantly more workers, adding cost.
  3. Prescription errors — the system does not fully utilize software-supported decision-making for medication orders, resulting in prescription errors that may lead to adverse patient reactions and deaths, plus drug-related claims, legal penalties and license withdrawals.
  4. Industry standardizationcontinued lack of healthcare IT standards has led to the loss of tremendous opportunities to improve interoperability, data sharing and transitions of care.

Alternative approaches

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. Future initiatives might include a new integrated architecture meeting a cross section of market needs, linking with all major existing software and hardware configurations such as EHRs, data management systems (DMSs) and imaging programs.

Prescription errors. Unlike the global integration challenge, prescription errors can be handled from a local perspective while awaiting market integration standards. Avoidance of ADEs is one major KPI that can be addressed by IT implementation. A CDSS provides updated information regarding recommendations for prescriptions to nurses, physicians and other qualified healthcare workers, and is typically integrated with the EHR and CPOE systems to perform a proper scenario analysis with appropriate patient backup before a provider writes a prescription.

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, seeking to reduce query time and thus queue time, reduce waiting time through fast patient data retrieval and diagnostic support, and reduce laboratory scheduling and patient briefing time. An IT-based process would lead to higher levels of perceived efficiency, productivity, better customer experiences and satisfaction and therefore more referrals, generating more revenue and higher growth rates.

Comparative analysis of alternatives

This section summarizes the current versus expected status of various aspects of a healthcare IT implementation — presented in Table 4.1, Comparative Analysis of Core Processes in Healthcare.

That is the definition the exam wants: a structured comparison of current versus expected status across core process areas is a comparative analysis.

While the extent to which key industry players may benefit may vary, it is likely that the net results will be beneficial. The capital implications of implementing IT-based healthcare support systems are within investment range, and long-term investment costs should be recoverable from the benefits obtained from healthcare interoperability.

Big picture

This lesson supplies one crisp definition the exam tests — comparative analysis as current versus expected status across core process areas — and a set of causal chains worth understanding rather than memorizing: wait times cost revenue twice, once in patients not seen and once in referrals never made.

Where it fits: the alternatives formulated here become the options weighed in the cost–benefit analysis of Lesson 4.6 and the vendor evaluation of Chapter 6.

Nearby concepts to keep straight: comparative analysis (current vs. expected status), gap analysis (current vs. required capability), and cost–benefit analysis (benefits vs. costs over time). Three comparisons, three different objects.

Key concepts

Comparative analysis

In plain English: A side-by-side of where you are and where you expect to be.

Technical meaning: A structured summary of the current versus expected status of various aspects of a healthcare IT implementation, across core process areas.

Picture it: Current versus expected. Not current versus required — that is gap analysis.

The four deficiency areas

In plain English: Patients, revenue, prescriptions, standards.

Technical meaning: Patient support and satisfaction; reduction in revenue generation; prescription errors; industry standardization — analyzed against industry key performance indicators.

Picture it: Each has its own named alternative approach in the following section.

Workflow optimization as the revenue lever

In plain English: Faster flow means more patients and more referrals.

Technical meaning: Revenue generation draws primarily from workflow optimization — reducing query and queue time, reducing waiting through fast data retrieval and diagnostic support, and reducing laboratory scheduling and patient briefing time.

Picture it: The second-order effect the source names is referrals, not just throughput.

Real-world examples

A clinic cuts lab result turnaround with online delivery. The source's chain runs: less queue time → more patients seen → better experience → more referrals → more revenue.

Distinctions & exam traps

EXAM TRAP · Comparative vs. gap vs. cost–benefit analysis

The tempting confusion: All three are structured comparisons in this chapter.

The deciding clue: Comparative analysis = current vs. expected status across core processes. Gap analysis = current vs. required capability. CBA = benefits vs. costs over a defined period.

Stem wording that triggers it: 'Current versus expected status across core process areas' names comparative analysis. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the four deficiency areas and the alternative approach the chapter gives for each.
  2. Define comparative analysis and distinguish it from gap analysis in one sentence.
  3. Trace the revenue chain from queue time to referrals in your own words.

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Obstacles analyzed based on industry key performance indicators; client satisfaction, business growth through revenue generation, efficient service process arrangement and proper implementation integration attainable through corporate initiative
  • Patient support and satisfaction: patients leaving without treatment due to long waits; physicians seeing fewer patients when delays are caused by lack of proper equipment; extra work for personnel degrading service quality; correlation between patient support and safety and employee retention and satisfaction; overwhelmed workers performing more poorly with higher exit rates
  • Reduction in revenue generation: delays lowering patients attended per day; unattended patients causing business loss; loss of potential referred clients annoyed by wait times; extra overtime expenses for doctors and nurses; inefficient facilities requiring significantly more workers
  • Prescription errors: underuse of software-supported decision-making for medication orders; prescription errors leading to adverse patient reactions and deaths, drug-related claims, legal penalties and license withdrawals
  • Industry standardization: continued lack of healthcare IT standards causing loss of opportunities to improve interoperability, data sharing and transitions of care; change dependent on sustainable policy frameworks agreed by IT experts and enforced by government
  • HITSP and the Office of the National Coordinator achievements in IT integration; future initiatives including a new integrated architecture meeting cross-sectional market needs and linking with EHRs, data management systems and imaging programs
  • Prescription errors handled locally while awaiting market integration standards; avoidance of ADEs as a major KPI; CDSS providing updated prescription recommendations to nurses, physicians and other qualified workers, typically integrated with EHR and CPOE to perform scenario analysis with patient backup before prescribing
  • Financial processes easiest to simulate due to resemblance to other industries; revenue generation drawing primarily from workflow optimization to reduce query and queue time, reduce waiting through fast patient data retrieval and diagnostic support, and reduce laboratory scheduling and patient briefing time; online lab result delivery electronically signed by providers; higher perceived efficiency, productivity, customer experience and satisfaction leading to more referrals, revenue and growth
  • Comparative analysis of alternatives summarizing current versus expected status of aspects of a healthcare IT implementation (Table 4.1 Comparative Analysis of Core Processes in Healthcare); varying benefit across industry players with likely beneficial net results; capital implications within investment range; long-term investment costs recoverable from healthcare interoperability benefits
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.

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

Chapter 4 · Source: Work Plan Development; Proposal Evaluation; Cost–Benefit Feasibility Study; Proposal Sensitivity Analysis; Cost–Benefit Analysis

L4.6 · Work Plans, Proposals, Alignment and Cost–Benefit Analysis

Walkthrough

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
  • evaluating outcomes

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.

Sample elements of a work plan: Executive Summary · Introduction and Background · Goals and Objectives · Resources · Work Plan Accountability

The seven specific objectives named:

  1. Evaluation of the current operational situation in each healthcare facility — including analysis of current clinical processes such as process mapping and documentation of current administrative and operational trends and integration of workflows
  2. Identification of the major problems in these processes with respect to the optimization of IT usecomparing the efficiency of current processes with the efficiency typically achievable in a similar setting with IT implementation
  3. Identification of alternative solutions through the implementation of IT policies — including software and hardware recommendations and a proposal for a working interface with existing resources
  4. Carrying out a comparative analysis of the alternative processes and the original routinesflow charts, tables, process flows and other analytic tools showing relationships and deviations between the systems
  5. Evaluation of alternative solutions in alignment with the specific objectives set out in the planrethinking the project intentions and comparing them with realized outcomes to assess efficiency
  6. Evaluation of the ethical, legal, social and economic implications of the alternatives through a comprehensive cost–benefit analysis
  7. Developing a proposal for implementing recommendations and following up after the project to enable quality improvement

Resources are assigned as: Personnel (software support teams, simulation teams, project evaluation teams, engineers, technical teams); Partners (governments, government-sponsored partners, nongovernment organizations, private investment agencies); Equipment (facilities, computers, software, related capital purchases); and legal and regulatory infrastructure.

Work plan accountability: resources will be regulated and governed by a project management or steering committee responsible for budgetary allocations, expenditure monitoring and accounts reconciliation. Time management will be essential to complete the phases within the specified timeframe.

Proposal evaluation and strategic alignment

The organizational business plan for most healthcare facilities has four major objectives:

  1. Patient satisfaction
  2. Revenue generation
  3. Efficient processes that cut costs and increase profits
  4. Conformity to industry standards

The proposed solution model should meet all those requirements.

This is the source's basis for evaluating whether a proposed solution aligns with the organization's strategic and operational plans. The exam's angle: a solution with strong financial return but no connection to a stated strategic objective is not automatically approvable — alignment is a separate test from return.

Cost–benefit feasibility study

Stakeholders who stand to gain or lose: 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: finance, service quality, control and time, among others.

The important variables to be considered in the analysis:

  1. the time of implementation
  2. cost of implementation
  3. alternatives to the proposal
  4. impact on stakeholders
  5. impact on external parties
  6. sustainability versus ongoing operating costs per year
  7. value of time to be used in the implementation

Proposal sensitivity analysis. Any proposed IT implementation may exhibit various levels of sensitivity to different stakeholders at different times and to all stakeholders over the course of time. The project's sensitivity to these challenges or changes will rely on the establishment of a support team to ensure conformity of a project's various elements and initiatives.

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.

Costs considered: hardware, software, installation and training, maintenance and support.

Benefits considered: cost savings or avoidance achieved by the new functionality — the source's examples: charge capture, decision support, diagnostics studies, financial management, medical record operations, nursing department, referral management.

How it is built:

  • The net impact is determined for each year by subtracting the cost from the benefits.
  • An in-depth CBA factors in the present value (PV) and determines 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.
  • The CBA visually shows how costs change over timemany being front-loaded with lower ongoing costs, or some being one-time costsand 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, when the organization will actually see a financial benefit, and provides validation that the benefits of the recommended solution are equal to or greater than the costs.

The payback period is the point at which cumulative benefits equal cumulative costs. That is the directly tested definition.

Big picture

The exam mines this section for three things: the CBA definition and payback period, what a CBA does and does not consider, and the alignment test.

The alignment point is the conceptually interesting one. A proposal can pass the financial test and still fail the strategic test, because the two ask different questions: does this pay for itself? and does this advance what we said we were doing? The source's four business plan objectives are the yardstick for the second question.

Where it fits: the work plan here becomes Chapter 6's implementation plan; the proposal becomes the RFP in Lesson 4.7 and the contract in Chapter 6; the benefits become Chapter 7's benefits realization measurement.

Key concepts

Cost–benefit analysis

In plain English: Quantifying whether it is worth it.

Technical meaning: A process using quantitative techniques to evaluate and measure the benefit of providing products or services compared to the cost of providing them; costs include hardware, software, installation and training, maintenance and support; benefits include cost savings or avoidance from new functionality.

Picture it: Net impact per year = benefits minus costs, repeated across a period such as five years.

Payback period

In plain English: When you finally break even.

Technical meaning: The point at which cumulative benefits equal cumulative costs.

Picture it: Distinct from net present value, which discounts future cash flows to today.

Work plan

In plain English: The step-by-step for actually doing it.

Technical meaning: Establishes a step-by-step implementation setup including materials and equipment layout, intended workflow processes, managing the time, analyzing processes and evaluating outcomes; sample elements include executive summary, introduction and background, goals and objectives, resources and accountability.

Picture it: Five named contents. It is a plan for execution, not a justification.

Strategic alignment test

In plain English: Does it advance what the organization said it was doing?

Technical meaning: Evaluated against the organizational business plan's four major objectives — patient satisfaction, revenue generation, efficient processes that cut costs and increase profits, and conformity to industry standards.

Picture it: A separate test from financial return. Passing one does not pass the other.

Proposal vs. recommendation

In plain English: A proposal says how you will get the benefit, not just what to buy.

Technical meaning: A proposal develops recommended approaches and solutions AND plans for realizing benefits; the work plan, cost–benefit analysis and follow-up for quality improvement are part of it.

Picture it: The benefits realization plan is what a bare recommendation lacks.

Real-world examples

A five-year CBA shows heavy year-one costs, modest ongoing costs, and benefits ramping from year two. Cumulative lines cross in year three — that crossing is the payback period.

A proposal delivers strong ROI on supply chain automation but the strategic plan says nothing about supply chain. The correct response is not to reject it outright — it is to recognize that alignment has not been demonstrated.

Distinctions & exam traps

EXAM TRAP · Payback period vs. NPV vs. break-even

The tempting confusion: Several financial terms describe points on the same curve.

The deciding clue: The payback period is where cumulative benefits equal cumulative costs. Net present value discounts future amounts to today.

Stem wording that triggers it: 'Point at which cumulative benefits equal cumulative costs' names the payback period. (Adjacent term.)

EXAM TRAP · What a CBA considers EXCEPT

The tempting confusion: A NOT item mixing genuine CBA inputs with something outside its scope.

The deciding clue: Costs: hardware, software, installation and training, maintenance and support. Variables: implementation time and cost, alternatives, stakeholder and external impact, sustainability vs. ongoing operating costs, value of time.

Stem wording that triggers it: Circle EXCEPT, then find the option outside the cost/benefit frame. (Category outlier.)

EXAM TRAP · Return without alignment

The tempting confusion: Assuming strong ROI is sufficient grounds for approval.

The deciding clue: Alignment with the strategic plan is a separate evaluation from financial return.

Stem wording that triggers it: 'Strong ROI but supports no stated strategic objective' is an alignment question. (Wrong layer.)

EXAM TRAP · Proposal vs. recommendation

The tempting confusion: Choosing cost detail, vendor comparison or executive sponsorship as the distinguishing element.

The deciding clue: The learning objective names it: proposals include recommended approaches and solutions AND plans for realizing benefits.

Stem wording that triggers it: The benefits realization plan is the distinguishing element. (Plausible-but-adjacent.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define cost–benefit analysis and name the four cost categories the source lists.
  2. Define the payback period and say how it differs from net present value.
  3. Give the four objectives of the organizational business plan and explain how you would use them to test alignment.
  4. Explain what a proposal contains that a recommendation does not.

Questions

7 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Work plan establishing a step-by-step implementation setup including materials and equipment layout, intended workflow processes, managing time, analyzing processes and evaluating outcomes; procedures starting with primary priorities and proceeding to others
  • Work plan elements: executive summary; introduction and background; goals and objectives; resources; work plan accountability
  • Seven specific objectives: evaluation of the current operational situation including process mapping and documentation of administrative and operational trends and workflow integration; identification of major process problems relative to IT optimization by comparing current efficiency with typically achievable efficiency; identification of alternative solutions including software and hardware recommendations and a working interface proposal; comparative analysis of alternative and original processes using flow charts, tables, process flows and other analytic tools; evaluation of alternative solutions against plan objectives by comparing intentions with realized outcomes; evaluation of ethical, legal, social and economic implications through comprehensive cost–benefit analysis; developing a proposal for implementing recommendations with post-project follow-up for quality improvement
  • Resources: personnel including software support, simulation, project evaluation, engineering and technical teams; partners including governments, government-sponsored partners, nongovernment organizations and private investment agencies; equipment including facilities, computers, software and related capital purchases; legal and regulatory infrastructure
  • Work plan accountability through a project management or steering committee responsible for budgetary allocations, expenditure monitoring and accounts reconciliation; time management essential to complete phases within the specified timeframe
  • Organizational business plan four major objectives: patient satisfaction; revenue generation; efficient processes that cut costs and increase profits; conformity to industry standards; proposed solution model should meet all
  • Cost–benefit feasibility study stakeholders: healthcare facilities, patients, medical practitioners' representative bodies, drug and medical equipment manufacturers, state and federal governments and related authorities, computer equipment and software manufacturers and vendors
  • Expected cost–benefit elements: finance, service quality, control and time
  • Important CBA variables: time of implementation; cost of implementation; alternatives to the proposal; impact on stakeholders; impact on external parties; sustainability versus ongoing operating costs per year; value of time to be used in the implementation
  • Proposal sensitivity analysis: varying sensitivity to different stakeholders at different times and to all stakeholders over time; reliance on a support team to ensure conformity of project elements and initiatives
  • CBA definition: a process using quantitative techniques to evaluate and measure the benefit of providing products or services compared to the cost of providing them
  • CBA costs: hardware, software, installation and training, maintenance and support; benefits: cost savings or avoidance achieved by new functionality such as charge capture, decision support, diagnostics studies, financial management, medical record operations, nursing department and referral management
  • Net impact determined each year by subtracting cost from benefits; present value and accumulated net present value; typical period such as five years repeated annually; visual display of how costs change over time with front-loaded or one-time costs and when benefits are realized; identification of the payback period and when financial benefit appears; validation that benefits are equal to or greater than costs
Read the original source

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.

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.

Summary

Chapter 4 · Source: RFI/RFP/RFQ; Request for Information; Request for Proposal; Request for Quotation; Non-Disclosure Agreement

L4.7 · Business Documentation — RFI, RFP, RFQ and NDA

Walkthrough

The various processes of systems planning and systems analysis — determining the strategic objectives, defining the usability requirements, completing 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 (Chapter 6). In these earlier phases, information gathering regarding viable products and vendor selection begins with the RFI and RFP processes.

Through these two processes, the organization should be seeking to understand:

  1. Does the vendor share the same vision for the product as the organization?
  2. Does the product meet the key functionality needed to achieve the organization's strategic objectives?
  3. Does the product/vendor utilize the appropriate technology?
  4. Does the vendor qualify in regards to the organization's acquisition policies?
  5. Can the vendor support the organization's implementation strategy?
  6. What is the vendor's track record for operations and maintenance support?
  7. What is the vendor's viability in the market?

Request for Information (RFI)

RFIs are not utilized today as much as they used to be, since much traditionally requested information is available on a company's website and through demonstrations.

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.

Generally a two- or three-page set of questions on:

  1. Company background — size, years in business, number of employees, product lines
  2. Product information — product name, product history, technical platform, overview of product capabilities
  3. Market information — major competitors and identification of key differentiators
  4. Installed base and clients — number of products sold, how many are currently implementing, number fully installed
  5. Special criteria — anything the vendor has identified as unique or established as critical

This information plus website research should result in a pool of about 10 to 20 products/vendors, with the intent to narrow to only a handful. A vendor comparison map can plot responses to key criteria to help narrow the list.

Request for Proposal (RFP)

The RFP is a formal request sent to vendors that ultimately leads to a contract between the organization and the selected vendor(s).
  • Used to obtain more detailed information with more specificity 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.
  • Most appropriate to send the RFP to the four or five vendors that seem to best fit the organization's overall criteria.
  • Public organizations may be required to send RFPs to every eligible vendor.

The eight typical RFP components:

  1. Organizational profile — demographics, mission and goals, vision for the product, current information infrastructure, specific constraints, instructions for responding, how many copies, how vendor questions will be directed
  2. Vendor information — size and longevity, years in business, revenues, profitability, number of employees, product research and development history and plans, types of installations, corporate composition, references, user group information and contract history
  3. Functional specifications — functional capability and the processes and workflows the product supports
  4. Operational requirements — data architecture, analytical processes supported, necessary interfaces, reliability and security features, system capacity, expansion capabilities, response time, downtime and other system maintenance issues
  5. Technical requirements — the appropriate technical architecture to meet the functional specifications and operational requirements; specific hardware, networking and software requirements
  6. Application support — proposed implementation schedule covering data conversion, acceptance testing, training and documentation, ongoing support and maintenance, which may include service level agreements (SLAs) and upgrades
  7. Licensing and contractual details — specific bid for one-time and recurring costs, standard contract, financing arrangements, proposed relationship with hardware vendors, warranty information, any clauses that protect the organization should the vendor go out of business
  8. Evaluation criteria — provided to let the vendor know up front the most important elements of the evaluation and how certain factors are weighted

Note that Chapter 6 adds the defining contrast: an RFP always includes timelines and budget or cost information, whereas an RFI may or may not.

Request for Quotation (RFQ)

Although an RFP may include pricing information, it has become more commonplace to also complete an RFQ or a request for bid to obtain a price from which to negotiate. 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 (NDA)

The purpose of an NDA is to protect both companies from disclosing confidential information. It includes legal terminology stating 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.

  • Any vendor being sent confidential information about your company should be sent the NDA, and it should be signed and executed prior to releasing any information.
  • In some cases, similar terms may be included in a master client agreement, rendering an additional NDA unnecessary.
  • Breaching these agreements can be very costly, so it is important to understand the terms and identify what is considered confidential.
  • Your organization's legal counsel should be involved in reviewing the terms of any agreements that are signed.

Big picture

The document family is a classic adjacent-document trap set, and the discriminators are clean:

  • RFI — informal, no commitment from either party, high-level, gathers information, narrows 10–20 vendors to a handful
  • RFP — formal, leads to a contract, detailed requirements, same questions to all vendors, sent to four or five
  • RFQ — obtains a price to negotiate from, useful when a few products are already known to be very similar
  • NDA — protects confidential information, signed before anything is released, may be two-way

Where it fits: Chapter 6 continues the story with the selection review team, contracting and the RFI/RFP contrast on timelines and cost. Chapter 9 covers contract management once the vendor is chosen.

Key concepts

Request for Information

In plain English: An informal ask that binds nobody.

Technical meaning: An informal request for information that does not require commitment from either party; collects information on prospective vendors and their ability to meet the defined need or high-level requirements; covers company background, product information, market information, installed base and clients, and special criteria.

Picture it: 'Does not require commitment from either party' is the definitional phrase.

Request for Proposal

In plain English: The formal ask that ends in a contract.

Technical meaning: A formal request sent to vendors that ultimately leads to a contract; obtains detailed, specific responses against identified system requirements; all vendors asked the same questions; typically sent to four or five best-fitting vendors, though public organizations may be required to send to every eligible vendor.

Picture it: Leads to a contract, and includes timelines and cost information.

Request for Quotation

In plain English: Just give me a price to negotiate from.

Technical meaning: Obtains a price from which to negotiate, helping minimize the influence of cost on other critical evaluation factors; more suitable than an RFP when the organization has thoroughly studied products and concluded a small number are very similar.

Picture it: Separating price from the evaluation is the point.

Non-Disclosure Agreement

In plain English: Nobody talks about what we share.

Technical meaning: Protects both companies from disclosing confidential information; may be one-way or two-way; should be signed and executed prior to releasing any information; legal counsel should review terms.

Picture it: Signed before, not after. That sequencing is the practical point.

Real-world examples

An organization sends RFIs to eighteen vendors, plots the responses on a comparison map, and takes five forward to RFP. The source's own funnel: 10–20 down to a handful.

Two shortlisted products are functionally near-identical. An RFQ separates the price conversation from the capability conversation — exactly the situation the source names as RFQ-suitable.

Distinctions & exam traps

EXAM TRAP · RFI vs. RFP

The tempting confusion: Both are vendor-facing documents in the same process.

The deciding clue: RFI is informal and requires no commitment from either party. RFP is formal and leads to a contract, always including timelines and cost information.

Stem wording that triggers it: 'Informal ... no commitment from either party' names the RFI. (Adjacent document.)

EXAM TRAP · RFP characteristics EXCEPT

The tempting confusion: A NOT item mixing genuine RFP traits with an RFI or RFQ trait.

The deciding clue: The RFP is formal, leads to a contract, asks all vendors the same questions, and covers organizational profile, vendor information, functional specifications, operational and technical requirements, application support, licensing and contractual details, and evaluation criteria.

Stem wording that triggers it: Circle EXCEPT, then check whether the trait belongs to a different document. (Category outlier.)

EXAM TRAP · NDA timing

The tempting confusion: Treating the NDA as something signed alongside the contract.

The deciding clue: It should be signed and executed prior to releasing any information about your organization.

Stem wording that triggers it: Before disclosure, not after. (Plausible-but-upstream.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define RFI, RFP, RFQ and NDA in one sentence each, using the discriminator that separates it from its neighbors.
  2. Name five of the eight typical RFP components.
  3. Explain the vendor funnel: how many vendors at RFI, how many at RFP, and what narrows the list.
  4. Say when an NDA is signed and why the timing matters.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Systems planning and analysis processes — strategic objectives, usability requirements, functional needs assessment and buy vs. build strategy — contributing to the acquisition strategy; formal selection process discussed in Chapter 6; information gathering beginning with RFI and RFP
  • Seven understanding goals: vendor shares the same product vision; product meets key functionality for strategic objectives; product/vendor uses appropriate technology; vendor qualifies under acquisition policies; vendor can support the implementation strategy; vendor track record for operations and maintenance support; vendor viability in the market
  • RFIs less used today due to web and trade show information availability; RFI as an informal request for information requiring no commitment from either party; a collection of documents collecting information on prospective vendors and their ability to meet the defined need or high-level requirements
  • RFI content areas: company background (size, years in business, employees, product lines); product information (name, history, technical platform, capability overview); market information (major competitors, key differentiators); installed base and clients (products sold, currently implementing, fully installed); special criteria
  • RFI plus website research producing a pool of about 10 to 20 products/vendors, narrowed to a handful; vendor comparison map plotting responses to key criteria
  • RFP as a formal request sent to vendors that ultimately leads to a contract; obtains more detailed information with more specificity on identified system requirements; all vendors asked the same questions fostering consistent review and selection; typically sent to the four or five best-fitting vendors; public organizations may be required to send to every eligible vendor
  • RFP components: organizational profile; vendor information; functional specifications; operational requirements; technical requirements; application support including implementation schedule, data conversion, acceptance testing, training and documentation, ongoing support and maintenance, service level agreements and upgrades; licensing and contractual details including one-time and recurring cost bid, standard contract, financing arrangements, hardware vendor relationship, warranty and clauses protecting the organization should the vendor go out of business; evaluation criteria disclosing the most important elements and weighting
  • RFQ or request for bid obtaining a price from which to negotiate; minimizing the influence of cost on other critical evaluation factors; more suitable than an RFP when a small number of thoroughly studied products are very similar
  • NDA purpose to protect both companies from disclosing confidential information; legal terminology preventing vendor disclosure without express permission; may be a two-way NDA binding the organization as well; sent to any vendor receiving confidential information and signed and executed prior to release; similar terms may appear in a master client agreement making an additional NDA unnecessary; breaches can be very costly; legal counsel should review terms of any signed agreements
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.

Chapter 4 · Source: Learning objective: interpret and analyze disparate data sets (developed across the analysis chapter)

L4.8 · Interpreting Disparate Data Sets

Walkthrough

This learning objective is carried across the chapter rather than given its own heading, and the exam tests it in two items. The source material supporting it sits in the document analysis, additional inventories and requirements analysis discussions, plus Chapter 3's data quality material.

What "disparate data sets" means here

Data drawn from different source systems — the applications inventory exists precisely because the organization identifies all of the applications that currently exist and how they may or may not be related to one another. Different systems have different data models, different definitions and different data quality.

The first analytic risk

When combining data sets from different source systems, the first thing that can go wrong is that the same-named field does not mean the same thing in both systems. Chapter 4's own framing supports this: the requirements analysis has to cover data/database requirements, and the document analysis exists to define the data requirements associated with each process.

Chapter 2 supplies the reinforcing principle: without standards, interoperability is impossible, and the lack of co-operation between systems adversely affects the accuracy, integrity, comparability and completeness of data (Chapter 4's own problem list).

Four words from that problem list are the analytic checklist: accuracy, integrity, comparability, completeness.

What interpretation requires attention to

Drawing on the chapter's requirement categories and problem list, combining data sets requires attention to:

  • definitional consistency — does a field mean the same thing in both systems?
  • data quality and completeness — Chapter 3's named failure modes: wrong patient data, inaccuracies, omissions, missing data, late documentation
  • timeframe alignment — are the periods comparable?
  • source system context — what workflow produced this data, and does that workflow differ across sites?

What it does not require is that the systems share a vendor, a platform, or an identical schema — those are implementation facts, not analytic prerequisites.

Why this matters practically

The chapter's own problem statement names the consequence: 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. An analyst who merges two extracts without checking definitions produces a number that looks authoritative and is wrong.

Big picture

This is a small lesson carrying a disproportionately useful habit: before you combine, confirm the definitions match.

The exam frames it as "the first analytic risk," and the answer is always about meaning, not about volume, format or storage. Two systems can both have a field called "admission date" and mean different moments.

Where it fits: Chapter 3 gave you the data quality failure modes; Chapter 5's DAMA framework gives the governance answer (Reference & Master Data, Data Quality); Chapter 9 uses comparative analytics and benchmarks that depend entirely on this discipline.

Key concepts

Disparate data sets

In plain English: Data from systems that were never designed to agree.

Technical meaning: Data drawn from different source systems with different data models, definitions and quality characteristics, which the applications inventory and document analysis exist to surface.

Picture it: The applications inventory asks how existing systems relate to one another — that is the same question in a different form.

The four data properties at risk

In plain English: Accurate, unaltered, comparable, complete.

Technical meaning: The chapter names accuracy, integrity, comparability and completeness as the data properties adversely affected when systems do not co-operate.

Picture it: Comparability is the one that specifically breaks when you merge sources.

Definitional consistency

In plain English: Does this field mean the same thing on both sides?

Technical meaning: The first analytic risk when combining data sets from different source systems — whether identically named fields carry identical meaning.

Picture it: Two 'admission date' fields, two different moments, one wrong answer.

Real-world examples

Two hospitals report 'length of stay.' One counts midnights, the other counts hours divided by 24. Merged, the average is meaningless — and nothing in the data flags it.

An applications inventory reveals the outpatient system defines 'no-show' as a missed appointment not rescheduled within 24 hours, while the inpatient system has no such window. That definitional difference has to be resolved before any combined analysis.

Distinctions & exam traps

EXAM TRAP · First analytic risk

The tempting confusion: Choosing volume, storage capacity, format conversion or latency as the first risk when combining data sets.

The deciding clue: The first risk is whether the data means the same thing across sources — definitional and comparability failure.

Stem wording that triggers it: 'First analytic risk' asks about meaning, not mechanics. (Wrong layer.)

EXAM TRAP · Interpretation requirements EXCEPT

The tempting confusion: A NOT item mixing genuine analytic considerations with an implementation fact such as shared vendor or identical schema.

The deciding clue: Interpretation needs definitional consistency, data quality and completeness, timeframe alignment and source system context. It does not need the systems to share a vendor or platform.

Stem wording that triggers it: Circle EXCEPT, then find the option that is a technical coincidence rather than an analytic requirement. (Category outlier.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Explain what makes data sets 'disparate' and why that is an analytic problem rather than a technical one.
  2. Name the four data properties the chapter says are damaged when systems do not co-operate.
  3. Give an example from your own work where two systems used the same field name for different things.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Applications inventory identifying all existing applications and how they may or may not be related to one another
  • Document analysis defining the data requirements associated with each process
  • Requirements analysis covering data/database requirements alongside functional, reporting, regulatory, security, performance, disaster recovery, platform compatibility, interface and interoperability, physical plant, client device and network categories
  • Chapter problem statement that existing solutions do not ensure interoperability and that lack of co-operation between systems makes information management impossible and adversely affects the accuracy, integrity, comparability and completeness of data
  • Poor quality of health information including redundancy and inconsistent standards for the collection and sharing of information
  • Reports inventory documenting all current reports being used or produced by current systems
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 5 · Source: Introduction

L5.1 · Introduction — What System Design Is

Walkthrough

Two dictionary definitions anchor the chapter.

System design (Dictionary of Computing): "the activity of proceeding from an identified set of requirements for a system to a design that meets those requirements."

System (Oxford English Dictionary): "a set or assemblage of things connected, associated, or interdependent, so as to form a complex unity."

Note the direction of travel in the first definition: design starts from requirements and ends at a design that meets them. Requirements come from Chapter 4 (Analysis). Design does not invent them.

Health IT systems take that complexity to a new level in function and interoperability. They must support:

  • advanced clinical functionality
  • patient accounting
  • financial accounting
  • functionality demanded by new healthcare regulations, medical devices, mergers and acquisitions
  • changes and advances in the IT industry

Two key aspects of system design are named at the outset: compatibility and interoperability. Given the complexity and criticality of enterprise healthcare IT, 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. Organizations could face severe implications for not adhering. A key best practice in system design is the development of a comprehensive technical specification. The design team documents design specifications for infrastructure, network, security, application and use cases, based on the requirements uncovered during system analysis.

Big picture

Chapter 5 sits between Analysis (Chapter 4, what is needed) and Selection/Implementation (Chapter 6, how it gets bought and installed). Its recurring theme is that design is where you make commitments explicit — in the technical specification — before money is spent.

Where it fits: every trap in this chapter turns on the difference between what a system does (functional) and how it must behave (nonfunctional: response time, availability, recovery, security, monitoring).

Nearby concepts to keep straight: compatibility (will these components work together at all) vs. interoperability (can they exchange and cooperatively use data). The source treats them as two distinct dimensions.

Key concepts

System design

In plain English: Getting from a requirements list to something that satisfies it.

Technical meaning: The activity of proceeding from an identified set of requirements for a system to a design that meets those requirements.

Picture it: Requirements are the input. If the requirements are wrong, design cannot rescue them — that is why Chapter 4 comes first.

Technical specification

In plain English: The written commitment about how the system must behave.

Technical meaning: A comprehensive document produced by the design team covering infrastructure, network, security, application and use cases, based on requirements uncovered during system analysis.

Picture it: It is named as the key best practice in system design — not an optional artifact.

Real-world examples

A health system acquires two physician groups mid-project. Design must absorb it: the source names mergers and acquisitions as one of the forces new functionality has to accommodate.

Distinctions & exam traps

EXAM TRAP · Design does not generate requirements

The tempting confusion: Choosing an option where the design team determines what the business needs.

The deciding clue: Design proceeds FROM an identified set of requirements. Analysis produces them.

Stem wording that triggers it: 'Based on the requirements uncovered during system analysis' fixes the order. (Plausible-but-upstream.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define system design in your own words and say where the requirements come from.
  2. Name the five things a comprehensive technical specification documents.

Questions

No canonical items map to the Introduction. It supplies the definitions and the compatibility/interoperability framing used in Lessons 5.2 and 5.3.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • System design definition (Dictionary of Computing): proceeding from an identified set of requirements to a design that meets them
  • System definition (OED): a set or assemblage of things connected, associated or interdependent so as to form a complex unity
  • Health IT complexity in function and interoperability; support for advanced clinical functionality, patient accounting and financial accounting; new healthcare regulations, medical devices, mergers and acquisitions, IT industry advances
  • Compatibility and interoperability as two key aspects of system design; necessity of ensuring new medical devices, software, hardware or network components are compatible and interoperable
  • Standards compliance as fundamental; severe implications for non-adherence
  • Comprehensive technical specification as key best practice; design specifications for infrastructure, network, security, application and use cases based on requirements from system analysis
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.”

Chapter 5 · Source: Compatibility and Interoperability of System Components

L5.2 · Compatibility and Interoperability of System Components

Walkthrough

Any healthcare enterprise owns and continually purchases a plethora of hardware, software, network components and medical devices:

  • Hardware — laptop computers, servers, mobile devices and tablets, each running its own operating system (OS) that is not necessarily compatible with other operating systems.
  • Application software — patient accounting, payroll, laboratory, pharmacy, radiology, dietetics, digital pathology.
  • Network components — routers (wired and wireless), firewalls, cabling and Internet connectivity. Networks must support connectivity of devices within the enterprise as well as Wi-Fi access for patients and visitors.
  • Medical devices — ultrasounds, MRIs, patient monitors, ventilators and even blood pressure cuffs — all provide information digitally and must connect to the network.

The IT review process

Organizations should define a process by which the IT department reviews purchases of any of these components for compatibility and interoperability.

The source's warning: not all devices or software will work out of the box. There may be system upgrades involved to incorporate the device onto the network.

The worked 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 EHR.

The process dictates close cooperation between the IT department and the procurement/purchasing department so IT has a chance to review purchases, thereby avoiding hidden costs of system and/or device upgrades and potential delays.

That is the whole point of the review: hidden upgrade costs and delays, not procurement bureaucracy.

Interoperability — the HIMSS definition

Compatibility of medical devices and systems is just one dimension of systems design. Interoperability is equally important.

HIMSS: interoperability is "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."

Note the elements: connect in a coordinated manner; within and across organizational boundaries; access, exchange and cooperatively use data; goal of optimizing the health of individuals and populations.

In the patient monitor example, interoperability may translate to an HL7 interface to the patient monitor to enable admissions, discharges and transfers (ADT) notifications from the existing EHR system.

Big picture

This section is the reason Chapter 5 exists as a separate chapter. Chapter 2 told you the components exist; Chapter 5 tells you that assembling them is a governed process with a named failure mode — the device that plugs in but does not work.

Where it fits: it is the design-side answer to the interoperability argument Chapter 1 makes on clinical grounds. Chapter 6 then handles the contracting that enforces it.

Nearby concepts to keep straight: compatibility is about whether components can work together at all; interoperability is about coordinated access, exchange and cooperative use of data. Physical connection is neither.

Key concepts

Compatibility

In plain English: Will these two things actually work together?

Technical meaning: Whether newly purchased hardware, software, network components or medical devices function with existing systems — often requiring system upgrades, since not all devices or software work out of the box.

Picture it: The monitor that joins the network but cannot feed the waveform aggregation system is compatible on the wire and incompatible on the system.

Interoperability (HIMSS definition)

In plain English: Different systems connecting deliberately, across boundaries, to actually use each other's data.

Technical meaning: 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.

Picture it: Three verbs: access, exchange, cooperatively use. Any option stopping at 'exchange' is incomplete.

IT purchase review

In plain English: IT sees the purchase before it happens.

Technical meaning: A defined process by which IT reviews purchases of hardware, software, network components and medical devices for compatibility and interoperability, requiring close cooperation with procurement, in order to avoid hidden costs of system or device upgrades and potential delays.

Picture it: The named purpose is hidden cost and delay avoidance.

Real-world examples

A cardiology group buys a new ultrasound without IT review. It connects to the network, then needs a middleware upgrade to send images to the enterprise imaging system. That upgrade is the hidden cost the review process exists to catch.

Interoperability for the patient monitor case is concrete: an HL7 interface carrying ADT notifications from the EHR so the monitor knows who is in the bed.

Distinctions & exam traps

EXAM TRAP · Why purchases route through IT review

The tempting confusion: Answering that the purpose is cost negotiation, vendor consolidation or policy compliance.

The deciding clue: The named purpose is compatibility and interoperability review — avoiding hidden upgrade costs and delays.

Stem wording that triggers it: 'Primarily to' asks for the source's stated purpose, not a general procurement benefit. (Plausible-but-upstream.)

EXAM TRAP · What interoperability attention covers

The tempting confusion: A NOT item mixing genuine interoperability considerations with something from a different domain entirely.

The deciding clue: The considerations are operating systems, application software, network components including wired and wireless routers and firewalls, and medical devices that must connect and exchange data.

Stem wording that triggers it: Circle EXCEPT, then find the option from a different taxonomy. (Category outlier.)

EXAM TRAP · Connect vs. cooperatively use

The tempting confusion: Treating network connectivity as satisfying the interoperability definition.

The deciding clue: HIMSS requires connection in a coordinated manner AND access, exchange and cooperative use of data.

Stem wording that triggers it: 'Connects to the network but cannot send data' is the source's own counterexample. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. State the HIMSS interoperability definition keeping all three verbs and the boundary clause.
  2. Explain the patient monitor example to a procurement colleague and say exactly what the IT review would have caught.
  3. Distinguish compatibility from interoperability in one sentence each.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Enterprises continually purchase hardware, software, network components and medical devices
  • Hardware: laptops, servers, mobile devices, tablets, each with an OS not necessarily compatible with others
  • Application software purposes: patient accounting, payroll, laboratory, pharmacy, radiology, dietetics, digital pathology
  • Network components: wired and wireless routers, firewalls, cabling, Internet connectivity; support for enterprise device connectivity and patient/visitor Wi-Fi
  • Medical devices: ultrasounds, MRIs, patient monitors, ventilators, blood pressure cuffs — all digital and network-connected
  • Defined IT review process for purchases; not all devices or software work out of the box; possible system upgrades to incorporate a device
  • Patient monitor example: physical network connection without compatibility with the waveform aggregation and distribution system feeding the EHR
  • Close cooperation between IT and procurement/purchasing; avoids hidden costs of system/device upgrades and potential delays
  • Compatibility as one dimension; interoperability equally important
  • HIMSS interoperability definition: different information systems, devices or applications connecting 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
  • Interoperability in the monitor example as an HL7 interface enabling ADT notifications from the existing EHR
Read the original source

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 · Source: Standards Compliance; Process to Address Industry Trends

L5.3 · Standards Compliance and the Process to Address Industry Trends

Walkthrough

Standards compliance

Healthcare providers face a huge number of external standards from government and industry, in addition to their own internal standards. Some affect the entire organization; others affect just one department. Some countries even dictate which vendor IT system the organization must purchase.

Standards-publishing organizations named by the source:

  • ASTM International
  • HL7
  • DICOM
  • other international organizations
  • the Institute of Electrical and Electronics Engineers (IEEE), which 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.

The source's decisive sentence for design: system design should attempt to address standards by the clear definition of technical specifications. That is the mechanism — not audits, not training, not vendor promises. Write the standards into the technical specification.

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. Two named examples:

  • The digitization of telephone systems means these systems generally share the same networks as IT and have become part of the IT organization.
  • Medical deviceselectrocardiographs, ultrasound and MRI devicesnow 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.

That is the reason the process is needed: the boundary of IT keeps moving, and things that were somebody else's problem become IT's problem.

Cybersecurity and medical devices

One of the most critical trending issues facing healthcare IT is cybersecurity. The greatest threat to healthcare networks comes from medical devices.

Why:

  • 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.
  • Generally accepted IT security practices — anti-virus software, firewall software and frequent password changes — are in many cases not compatible with medical devices, or the devices have significant restrictions on using them.
  • 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.

Innovation centers

Many healthcare organizations have invested in Innovation Centers to develop and deploy healthcare technology innovations. The named example is the Emory Healthcare Innovation Hub, described as connecting the pieces of the healthcare continuum to validate, accelerate and realize ideas, with a mission to improve health outcomes, increase access to quality care, lower overall costs to the system and improve healthcare provider experiences.

Big picture

Two ideas here are heavily reusable. First, the mechanism for standards compliance is the technical specification — that answers "how do you demonstrate compliance" questions. Second, the reason a trends process is needed is scope drift: telephony and medical devices became IT's responsibility without anyone deciding they should.

Where it fits: Chapter 8 revisits medical device security as a vulnerability class. Chapter 9 revisits trend-scanning as a strategic planning function.

Nearby concepts to keep straight: an organization needs two separate processes in this chapter — one for compatibility of components, one for standards compliance — plus a third for trends. The exam can ask which process a scenario calls for.

Key concepts

Standards-publishing bodies

In plain English: Who writes the rules your design must meet.

Technical meaning: ASTM International, HL7, DICOM and other international organizations; IEEE publishes wired and wireless networking standards used by most countries in the world.

Picture it: IEEE is the networking one — that is the detail most candidates miss.

Compliance mechanism in design

In plain English: You prove compliance by writing it into the spec.

Technical meaning: System design should attempt to address standards by the clear definition of technical specifications; there must be an overlap between business process and compliance management.

Picture it: The specification is the artifact that carries the obligation forward into contracting and testing.

Why a trends process is needed

In plain English: IT keeps inheriting things it did not used to own.

Technical meaning: A process must exist to evaluate and incorporate industry, technology, infrastructure, legal and regulatory trends, and must address areas formerly governed by departments other than IT — digitized telephony now sharing IT networks, and medical devices generating medically relevant data that must be integrated into the record.

Picture it: Scope drift is the argument. Not curiosity, not innovation for its own sake.

Medical devices as the greatest network threat

In plain English: The riskiest things on the network are the ones you cannot patch.

Technical meaning: Enterprise security was not in the original product requirements; anti-virus, firewall software and frequent password changes are often incompatible or restricted; some vendors discourage anti-virus scanning of device files; others hard-code passwords or use obsolete commercial operating systems.

Picture it: Four named reasons. This is a list an exam item can be built from.

Real-world examples

A design team writes 'system must support HL7 v2.5.1 ADT, ICD-10 and DICOM' into the technical specification. That single act is the source's named compliance mechanism, and it carries into the RFP, the contract and acceptance testing.

An infusion pump fleet runs an obsolete OS the vendor will not let the hospital patch. Two of the source's four named device-security problems are present at once.

Distinctions & exam traps

EXAM TRAP · How compliance is demonstrated

The tempting confusion: Choosing staff training, vendor attestation or periodic audit as the most effective mechanism.

The deciding clue: The source names clear definition of technical specifications as the design-stage mechanism.

Stem wording that triggers it: 'Most effective mechanism' in a design context points to the specification. (Wrong layer.)

EXAM TRAP · Why a trends process is needed

The tempting confusion: Answering that it is to stay competitive, to satisfy the board, or to reduce cost.

The deciding clue: It is needed because areas formerly governed by other departments — telephony, medical devices — have moved into IT's scope and must be integrated.

Stem wording that triggers it: 'Needed primarily because' asks for the source's stated reason, not a generic benefit. (Plausible-but-upstream.)

EXAM TRAP · Standards bodies vs. regulators vs. accreditors

The tempting confusion: Offering CMS, the Joint Commission or the FDA as standards publishers for healthcare IT design.

The deciding clue: ASTM International, HL7, DICOM and IEEE publish the standards named here.

Stem wording that triggers it: Bind each body to its function before reading options. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the standards-publishing organizations this chapter lists, and say which one covers networking.
  2. Explain how a design team actually demonstrates standards compliance — and why training is not the answer.
  3. Give the four reasons medical devices are the greatest threat to healthcare networks.
  4. Explain scope drift using telephony and medical devices as your two examples.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Huge number of external government and industry standards plus internal standards; some organization-wide, some departmental; some countries dictate the vendor system to purchase
  • Standards publishers: ASTM International, HL7, DICOM, other international organizations; IEEE for wired and wireless networking used by most countries
  • Need for a standards-compliance process alongside the compatibility process; not a simple effort; overlap required between business process and compliance management
  • System design should address standards by clear definition of technical specifications
  • Process required to evaluate and incorporate industry, technology, infrastructure, legal and regulatory trends
  • Process must address areas formerly governed by non-IT departments: digitized telephone systems now sharing IT networks and part of the IT organization; medical devices (electrocardiographs, ultrasound, MRI) generating millions of bytes of medically relevant data requiring integration into the electronic patient record; IT participation required in device purchases
  • Cybersecurity as a critical trending issue; medical devices as the greatest threat to healthcare networks
  • Reasons: many computerized devices connect to enterprise networks; enterprise security absent from product requirements; anti-virus, firewall software and frequent password changes often incompatible or significantly restricted; vendors discouraging anti-virus scanning of device files; vendors hard-coding passwords or using obsolete commercial operating systems
  • Innovation Centers developing and deploying healthcare technology innovations; Emory Healthcare Innovation Hub example — validate, accelerate and realize ideas; mission to improve health outcomes, increase access to quality care, lower overall system costs and improve provider experiences
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.

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.

Chapter 5 · Source: Structure of the System Design Team; Detailed Technical Specifications

L5.4 · Structure of the System Design Team and Detailed Technical Specifications

Walkthrough

The system design team

Members may vary based on the complexity and scope of the project. The 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.

The nine potential team members:

  1. Project sponsor
  2. Project manager
  3. Solution architect
  4. Enterprise business architect
  5. Biomedical engineers
  6. Application developers
  7. Quality assurance analysts
  8. Information security officer
  9. Stakeholders/users

Note what is not on this list: board members, the CEO, external regulators. On a NOT item, an option from a governance layer rather than a design-practitioner layer is the outlier.

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.

The key areas — all eighteen — with the question each one answers:

  1. System and wired/wireless network architecture — Does the system have to fit into the organization's existing architectures, or may it vary?
  2. Security and data encryption — Does the system integrate into the organization's security standards?
  3. Disaster recovery — What is the recovery time objective (RTO), the time it will take to recover the system in a disaster? What is the recovery point objective (RPO), to what point in time must the system be restored?
  4. Data conversion — What are the conversion options when moving from one system to another with different data models?
  5. Response times — What are the expected response times and how will they be measured?
  6. System backups — What are the backup options? How long will backups run?
  7. System monitoring — How will the system be monitored? Will it fit the existing monitoring infrastructure?
  8. 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?
  9. Availability — What are the availability requirements? What is the downtime associated with system upgrades?
  10. Time zone and daylight savings time support — Does the system support multiple time zones? Are system outages required for clock changes?
  11. Standards — Does the system support integration standards such as HL7, ICD-10 or DICOM?
  12. Government regulations — Does the system meet current government regulations? What is the vendor commitment for turnaround of new regulations?
  13. System integration — How will the system integrate with other health IT systems and medical devices in the enterprise?
  14. Usability — including accessibility for persons with disabilities as well as use of mobile devices.
  15. Workflow definitions — definition of desired workflows.
  16. Data management — Does the system fit the organization's data management policies and procedures for backup, recovery and archiving?
  17. Antivirus/OS patching policy — Which anti-virus application and versions are supported? Is automated OS/security patching allowed?

RTO vs. RPO is the single most reliably tested pair in this chapter. RTO is time to restore service. RPO is the point in time to which data must be restored — that is, how much data loss is acceptable.

Big picture

The technical specification list is the practical heart of Chapter 5, and it is where the exam's "detailed technical specifications address all of the following except" archetype comes from. Most of the eighteen items are nonfunctional — they describe how the system must behave rather than what it does — which is exactly the distinction the source draws in its opening sentence.

Where it fits: these specifications become RFP content in Chapter 6, and acceptance criteria in Chapter 7. A requirement that never made it into the specification cannot be tested for later.

Nearby concepts to keep straight: RTO vs. RPO, and change management here (how the vendor handles changes to a purchased system) vs. change management in Chapter 6 (helping people adopt a new system). Same phrase, two meanings.

Key concepts

Recovery Time Objective (RTO)

In plain English: How long until the system is back up?

Technical meaning: The time it will take to recover the system in a disaster.

Picture it: A four-hour RTO means the service must be usable again within four hours.

Recovery Point Objective (RPO)

In plain English: How much recent data can we afford to lose?

Technical meaning: The point in time to which the system must be restored.

Picture it: If the system fails at 3 PM and the most recent usable backup is from 2 PM, the organization has lost one hour of data.

Nonfunctional specification

In plain English: Not what it does — how well it has to do it.

Technical meaning: Specifications addressing information infrastructure rather than system function: response times, availability, monitoring, backups, recovery, patching, time zone support.

Picture it: The source explicitly says the spec must cover function AND nonfunctional issues.

The design team

In plain English: Practitioners, plus a sponsor who starts it.

Technical meaning: Project sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, quality assurance analysts, information security officer, stakeholders/users.

Picture it: The sponsor sets business goals and how they will be measured, then steps back from detailed design meetings.

Real-world examples

A pharmacy system contract specifies a 2-hour RTO and a 15-minute RPO. Those two numbers drive completely different investments: RTO buys standby infrastructure; RPO buys replication frequency.

A team omits 'time zone and daylight savings support' from the spec for a multi-state system. Twice a year, an outage is required for clock changes that nobody budgeted for.

Distinctions & exam traps

EXAM TRAP · RTO vs. RPO

The tempting confusion: Swapping the two, since both are recovery objectives with three-letter acronyms.

The deciding clue: RTO is time until service is restored. RPO is acceptable data loss — the point in time to which data must be restored.

Stem wording that triggers it: If the stem asks 'to what point in time must data be restored', think RPO. If it asks how long until it is back, think RTO. (Adjacent term.)

EXAM TRAP · What the technical specification does not cover

The tempting confusion: A NOT item mixing real spec areas with something from procurement, staffing or clinical policy.

The deciding clue: The eighteen named areas are all technical/nonfunctional design questions.

Stem wording that triggers it: Circle EXCEPT, then look for the option from a different taxonomy entirely. (Category outlier.)

EXAM TRAP · Design team membership

The tempting confusion: A NOT item offering a governance-layer role — board member, chief executive — among design practitioners.

The deciding clue: The nine named members are project sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, QA analysts, information security officer, stakeholders/users.

Stem wording that triggers it: On a NOT item with two defensible answers, take the option from a different taxonomic layer. (Category outlier.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define RTO and RPO with a clock example, then say which one drives replication frequency.
  2. Name the nine design team members and say what the sponsor does — and stops doing.
  3. Recite as many of the eighteen technical specification areas as you can, then check which ones you dropped. The ones you drop twice go in the recite-list section of the notebook.
  4. Explain to a colleague why 'change management' means something different in this chapter than it does in Chapter 6.

Questions

No Chapter 5 canonical items map directly here, but the RTO/RPO pair and the specification list feed Chapter 7 acceptance testing and the Chapter 6 procurement documents. Q134 in Lesson 5.5 tests the BC/DR umbrella that these specifications quantify.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Design team membership varies with project complexity and scope
  • Project sponsor kicks off the project, helps determine business goals and how they are measured, then may not be needed in detail-oriented design meetings
  • Nine potential team members: project sponsor, project manager, solution architect, enterprise business architect, biomedical engineers, application developers, quality assurance analysts, information security officer, stakeholders/users
  • Technical specifications must cover system/application function and nonfunctional issues such as information infrastructure
  • System and wired/wireless network architecture; security and data encryption; disaster recovery with RTO (time to recover) and RPO (point in time to restore); data conversion between differing data models; response times and measurement; system backups and duration; system monitoring and fit with existing infrastructure; vendor change management schedule; availability requirements and upgrade downtime; time zone and daylight savings support including outages for clock changes; integration standards support (HL7, ICD-10, DICOM); government regulation compliance and vendor turnaround commitment for new regulations; system integration with other health IT systems and medical devices; usability including accessibility for persons with disabilities and mobile device use; workflow definitions; data management fit for backup, recovery and archiving; antivirus application/version support and automated OS/security patching policy
Read the original source

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

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?

Chapter 5 · Source: Usability; Information Infrastructure

L5.5 · Usability, Information Infrastructure, Business Continuity and Cloud

Walkthrough

Usability and the Usability Maturity Model

Interest in usability has grown significantly over the past decade due to increased EHR adoption. HIMSS created tools and forums to help clinicians and health IT professionals overcome common usability challenges, including the Usability Maturity Model (UMM). The UMM examines three nonhealthcare usability models and uses common themes from those models to create a healthcare model with five phases:

  1. Phase 1: Unrecognizedlack of awareness of usability
  2. Phase 2: Preliminarysporadic inclusion of usability
  3. Phase 3: Implementedrecognized value of usability and small teams using it
  4. Phase 4: Integratedbenchmarks implemented and have a dedicated user experience team
  5. Phase 5: Strategicbusiness 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 ten tactics to expand usability within the organization:

  1. Include usability in contracts
  2. Create feedback loops from users to vendors
  3. Talk about tasks and workflows
  4. Educate about return on investment related to usability
  5. Engage organizational leaders in usability
  6. Include usability metrics on one project
  7. Interview users to determine key usability issues
  8. Compile evidence from usability assessments
  9. Look for and document usability wake-up calls
  10. Find a business/organization driver supporting the need for usability

Phase order and phase names are both examinable. The progression is Unrecognized → Preliminary → Implemented → Integrated → Strategic.

Information infrastructure

The information infrastructure must be able to support today's business requirements and anticipate emerging or future business requirements.

  • Current trend example — BYOD. Doctors, nurses and other employees 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.
  • Future requirement example — ICD-11. Most healthcare organizations today utilize ICD-10. While today's applications do not support ICD-11, organizations should consider how new systems/applications will support it in the future.

An organization should have a process in place to examine or evaluate emerging trends and technologies, done on a regular basis as new technologies emerge or existing ones begin to be adopted. As part of the process, the organization should decide where it wants to be on the technology adoption curve.

Business continuity

As more healthcare records become 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.

That last clause is the examinable one: having the plan is not validation — testing it at frequent intervals is.

Cloud computing

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 resources 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.

Big picture

Three separate examinable structures live here: the five UMM phases, the technology adoption curve as a positioning decision, and the BCP/DR relationship.

On BC/DR, hold the containment relationship firmly: the business continuity plan is the umbrella and the disaster recovery plan is a component inside it. That umbrella-versus-component pattern recurs across the whole exam, and Chapter 5 is where it is taught.

Where it fits: Chapter 7 tests systems; this chapter tests the plan. Chapter 9 handles the leadership and change side of adoption.

Key concepts

Usability Maturity Model — five phases

In plain English: How seriously an organization takes usability, on a five-step ladder.

Technical meaning: Unrecognized (lack of awareness); Preliminary (sporadic inclusion); Implemented (recognized value, small teams using it); Integrated (benchmarks implemented, dedicated user experience team); Strategic (business benefit well understood, mandated, budgeted, results used strategically).

Picture it: Verify first and last on any sequence item: Unrecognized at the bottom, Strategic at the top.

Technology adoption curve

In plain English: Deciding whether to be early or late to new technology.

Technical meaning: As part of the emerging-technology evaluation process, the organization should decide where it wants to be on the technology adoption curve.

Picture it: The decision is a positioning choice, made deliberately and revisited regularly.

Business continuity plan vs. disaster recovery plan

In plain English: The umbrella and one thing inside it.

Technical meaning: Business continuity sustains operations through a disruption and contains the disaster recovery plan, which addresses restoring systems and data. BC planning covers natural and man-made disasters, off-site storage as a minimum requirement, DR vendor contracts covering data copies and full system restoration capability, mirrored data centers and network access to remote sites.

Picture it: Note which artifact CONTAINS the other. That containment is the tested relationship.

Validating a BCP

In plain English: A plan you have never tested is a guess.

Technical meaning: The business continuity plan must not only ensure remote sites are in place but also be tested at frequent intervals to make certain it can be executed.

Picture it: Documentation, board approval and vendor contracts do not validate a plan. Testing does.

Cloud computing

In plain English: Someone else's servers, on demand.

Technical meaning: Provision of applications over the Internet where customers do not invest in the hardware and software resources needed to run and maintain them; data sits on infrastructure not owned by the organization, so the organization's security requirements must be understood by the vendor and incorporated into the system design.

Picture it: The design obligation does not transfer with the servers.

Real-world examples

An organization has a documented BCP, contracted DR vendor and mirrored data center — and has never run a failover. Under the source's standard it is not validated.

A CIO decides the organization will be a fast follower rather than an early adopter, and reviews that stance annually. That is the technology adoption curve decision the source asks for.

Distinctions & exam traps

EXAM TRAP · BCP vs. DR plan — which contains which

The tempting confusion: Treating disaster recovery as the umbrella, or as a synonym for business continuity.

The deciding clue: The business continuity plan sustains operations through a disruption and contains the disaster recovery plan.

Stem wording that triggers it: 'Includes the disaster recovery plan' names the BCP. (Umbrella vs. component / wrong layer.)

EXAM TRAP · What validates a continuity plan

The tempting confusion: Choosing documentation, executive approval, off-site storage or a vendor contract.

The deciding clue: Testing the plan at frequent intervals to make certain it can be executed.

Stem wording that triggers it: 'Most directly validates' asks what proves it works, not what proves it exists. (Plausible-but-upstream.)

EXAM TRAP · UMM phase order and names

The tempting confusion: Sequences that swap two adjacent phases, or substitute a plausible synonym for a phase name.

The deciding clue: Unrecognized, Preliminary, Implemented, Integrated, Strategic.

Stem wording that triggers it: On sequence items, verify the first and last stages first — most distractors break in the middle. (One altered element.)

EXAM TRAP · Adoption curve vs. maturity model

The tempting confusion: Both are staged models about organizational posture toward technology.

The deciding clue: The technology adoption curve is about how quickly you adopt an emerging technology. The UMM is about how mature your usability practice is.

Stem wording that triggers it: 'Deciding how quickly to adopt' names the adoption curve. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite the five UMM phases in order with one clause each. Check first and last before the middle.
  2. Explain the BCP/DR relationship to someone who thinks they are the same thing.
  3. Say what actually validates a business continuity plan and why the other candidates fail.
  4. Explain why moving to the cloud does not move the security obligation.

Questions

3 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Usability interest grown with EHR adoption; HIMSS tools and forums; Usability Maturity Model drawn from three nonhealthcare models
  • Five UMM phases: Unrecognized (lack of awareness); Preliminary (sporadic inclusion); Implemented (recognized value, small teams using it); Integrated (benchmarks implemented, dedicated user experience team); Strategic (business benefit well understood, mandated, budgeted, results used strategically)
  • Ten UMM tactics: include usability in contracts; create feedback loops from users to vendors; talk about tasks and workflows; educate about ROI related to usability; engage organizational leaders; include usability metrics on one project; interview users for key issues; compile evidence from usability assessments; look for and document usability wake-up calls; find a business/organization driver
  • Information infrastructure must support current and anticipate future business requirements
  • BYOD as a current trend; investments in secure mobile communications platforms and network infrastructure
  • ICD-11 as a future requirement example; most organizations on ICD-10; today's applications do not support ICD-11; new systems should be evaluated for future support
  • Regular process to examine or evaluate emerging trends and technologies; decision about position on the technology adoption curve
  • Business continuity as key IT infrastructure; planning for natural and man-made disasters; off-site data storage as a minimal requirement; disaster recovery vendor contracts for data copies and full system restoration capability; multiple mirrored data centers in larger organizations; networks to access remote sites; BCP must ensure remote sites are in place AND be tested at frequent intervals to confirm it can be executed
  • Cloud-based applications enabling on-demand availability of computing resources; definition as provision of applications over the Internet without customer investment in hardware and software resources; security of application data and customer information as a particular healthcare concern; data on infrastructure not owned by the organization; organizational security requirements must be understood by the cloud vendor and incorporated into system design
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

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 · Source: Data Management; Summary

L5.6 · Data Management — the DAMA Framework

Walkthrough

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 eleven data management knowledge areas.

All eleven, with the source's own definitions:

  1. Data Governanceplanning, oversight and control over management of data and the use of data and data-related resources
  2. Data Architecturethe overall structure of data and data-related resources as an integral part of the enterprise architecture
  3. Data Modeling & Designanalysis, design, building, testing and maintenance
  4. Data Storage & Operationsstructured physical data assets, storage, deployment and management
  5. Data Securityensuring privacy, confidentiality and appropriate access
  6. Data Integration & Interoperabilityacquisition, extraction, transformation, movement, delivery, replication, federation, virtualization and operational support
  7. Documents & Contentstoring, 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
  8. Reference & Master Datamanaging shared data to reduce redundancy and ensure better data quality through standardized definition and use of data values
  9. Data Warehousing & Business Intelligencemanaging analytical data processing and enabling access to decision support data for reporting and analysis
  10. Metadatacollecting, categorizing, maintaining, integrating, controlling, managing and delivering metadata
  11. Data Qualitydefining, 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.

Note the direction: the process comes first; the system fits into it. Not the reverse.

Summary

The source's own closing points:

  • 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 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.

Big picture

DAMA is the exam's canonical named-list target in Chapter 5. Eleven items is too many to guess at, and multi-element list items here work by swapping one knowledge area for a plausible impostor — "data mining", "data entry", "data retention", "data stewardship". Learn the eleven and the impostors become obvious.

Where it fits: data governance underpins reporting and analytics questions across Chapters 2, 3, 4 and 9. When a stem says a capability "depends on" or is "based on" something, the answer is usually the governance foundation, not the activity it enables.

Nearby concepts to keep straight: data governance is one of the eleven areas AND the name of the overall framework. Read which sense the stem is using.

Key concepts

DAMA framework

In plain English: Eleven named areas that together cover managing an organization's data.

Technical meaning: A framework for data governance created by Data Management International defining eleven data management knowledge areas.

Picture it: The number is testable on its own. Eleven, not ten, not twelve.

Data Governance (the knowledge area)

In plain English: Who decides how data is managed and used.

Technical meaning: Planning, oversight and control over management of data and the use of data and data-related resources.

Picture it: Governance is the foundation layer; reporting and analytics are activities it enables.

Reference & Master Data

In plain English: One agreed version of shared values.

Technical meaning: Managing shared data to reduce redundancy and ensure better data quality through standardized definition and use of data values.

Picture it: One patient, one identifier, one agreed spelling of a facility name.

Process before system

In plain English: Define how you manage data, then make the system fit.

Technical meaning: The organization must define a process for addressing the data management functions; the system design team must then ensure the system fits into that process.

Picture it: Buying a system and letting it define your governance is the reversal the source warns against.

Real-world examples

An analytics team cannot reconcile two departments' patient counts. The failure is not in the report — it is in Reference & Master Data and Data Quality, two named knowledge areas.

A design team specifies where unstructured scanned documents will live and how they will be indexed and made available alongside database data. That is Documents & Content, and skipping it is a common omission.

Distinctions & exam traps

EXAM TRAP · DAMA knowledge areas — one altered element

The tempting confusion: Lists substituting a plausible impostor — data mining, data entry, data retention, data stewardship — for a genuine knowledge area.

The deciding clue: The eleven are Data Governance, Data Architecture, Data Modeling & Design, Data Storage & Operations, Data Security, Data Integration & Interoperability, Documents & Content, Reference & Master Data, Data Warehousing & Business Intelligence, Metadata, Data Quality.

Stem wording that triggers it: On a NOT item, scan for the single area that is not on the list rather than evaluating each. (One altered element / category outlier.)

EXAM TRAP · What DAMA defines

The tempting confusion: Answering that DAMA defines security controls, interoperability standards, or software development phases.

The deciding clue: It defines knowledge areas for data management, as a framework for data governance.

Stem wording that triggers it: 'The DAMA framework defines knowledge areas for' has one correct completion. (Adjacent term.)

EXAM TRAP · Foundation vs. enabled activity

The tempting confusion: Choosing reporting or analytics when a stem asks what a capability depends on.

The deciding clue: When a stem says 'depends on' or 'based on', the answer is the foundational layer — the data governance protocol — not the activity it enables.

Stem wording that triggers it: Foundation before activity. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite as many of the eleven DAMA knowledge areas as you can from memory. Whatever you drop goes in the recite-list section of the notebook.
  2. Explain the difference between Data Governance as a knowledge area and data governance as the name of the framework.
  3. Explain why the organization's data management process must exist before the system is designed to fit it.
  4. Give the four things the chapter summary says successful system design depends on.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • DAMA (Data Management International) created a framework for data governance defining eleven 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 & 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 unstructured data (electronic files and physical records) and making it available for integration and interoperability with structured 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
  • Organization must define a process for addressing data management functions; design team must ensure the system fits into that process
  • Summary: design centers on the design team with proper members; clear documented technical specifications; usability and data management as two ways to produce requirements; compatibility and interoperability of devices, software and hardware as fundamental; compliance with industry, regulatory and organizational standards; process for evaluating emerging technologies to support strategy and mission
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 6 · Source: Introduction; Solution Selection Criteria

L6.1 · Introduction and Solution Selection Criteria

Walkthrough

The systems selection process begins with the identification of a need and subsequent approval of a project proposal. Successful implementation and adoption depends on an organized system selection process, followed by a well-planned and executed implementation strategy.

Once a need has been identified, an effective governance committee evaluates it against the organizational mission, goals, objectives, IT strategic plan, budget and available resources.

RFI vs. RFP — the chapter's own contrast

A RFIA RFP
Is an informal request for information that does not require commitment from either partyIs a formal request that leads to a contract between the organization and the selected vendor(s)
Is a collection of documents designed to collect information regarding prospective vendors and their ability to meet the defined need or high-level requirementsIs a collection of documents that outline the detailed requirements and how each responding vendor will be compared for a final decision
May or may not include budget or cost informationAlways includes timelines and budget or cost information

"Always includes timelines and budget or cost information" is the RFP's defining trait in this chapter.

Evaluating the vendors that respond to the RFP includes on-site visits, reference checks, demonstrations and sometimes a trial version or trial period. After the list is narrowed 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.

The business case

The need and justification for a project are often described in a formal business case, project proposal, or a needs assessment, outlining the goal and objectives of the request along with the high-level resources required.

  • Most organizations request a business case prior to approving the proposed system selection process. If the organization does not require one, it is imperative that the IT governance committee request one.
  • The challenge is defining required resources this early; most often they are defined through scientific guesses. Market research can provide more accurate estimates, starting with high-level requirements, not the detailed ones identified later. Formal market research is completed through a process similar to the RFI process, but clearly stated as research only, with no intent to purchase at this time. Informal research is done through vendor exhibitions, Internet searches and contact with other similar organizations.
  • The business case should present the need and requirements, not necessarily the solution. It should avoid the identification of a single solution, presenting several solutions or recommendations instead.
  • 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.

The requirements list

The requirements go beyond end-user functionality to include nonfunctional necessities also. The source's named list:

Functional and application: 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) · 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

Services and process: 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 with constraints · expected availability, reliability and scalability · training requirements

The gap analysis might be the first step in defining these requirements. Requirement creep can occur very quickly if the team is not focused; the governance committee and executive sponsors help ensure the requirements fit within the defined goals and objectives.

Ranking requirements. Once defined, requirements should be ranked to show which are required, preferred, or optional. It is rare for vendors to meet every requirement, so clarity about which are absolutely necessary helps during evaluation. The rankings should be agreed upon by all committee members and used consistently for all vendors, and feed into the RFI or RFP documentation.

Build vs. buy. Factors: 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? The decision may occur early, after reviewing the RFI/RFP responses, or anytime in between.

Cloud vs. on premise. Criteria: personnel requirements to install and maintain the software, hardware purchase and maintenance, proper monitoring and auditing, and how well the system aligns with privacy and security requirements in the cloud.

The selection review team

Should include representatives from clinical, organizational operations, IT and the business department to ensure all affected areas are involved. Selection of the review team should be completed as early as possible, balancing the importance of including the right people with the need to keep the size manageable.

The nine roles:

  1. Facilitatorprovides overall leadership and coordination of the system selection process
  2. Executive sponsorprovides support, clarifies the mission, facilitates necessary resources and acts as champion within the organization
  3. Technical representativeprovides technical expertise, such as IT, biomedical and telecommunications
  4. Business representativeprovides business or clinical end-user expertise; highly knowledgeable about current business and workflows and represents the end users
  5. Program/project managerprovides implementation and methodology expertise
  6. Contracting representativeprovides contracting, negotiation and process expertise
  7. Financial representativeprovides budgetary expertise
  8. Organizational change leaderprovides expertise related to facilitating change within the organization
  9. Governance committeeprovides oversight but is often not directly involved in the team; the selection team reports to this group, which remains intact once implementation begins 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. Members should gather information from their peers to bring back to the team. All requirements should be reviewed and approved by the team.

Big picture

Chapter 6 picks up exactly where Chapter 4 left off. Chapter 4 defined the need and drafted the RFI/RFP; Chapter 6 runs the selection, signs the contract, implements, and then keeps the thing alive.

Two ideas here are heavily tested. First, the governance committee / steering committee identity — an advisory body of high-level stakeholders providing oversight, guiding policy and budgetary control, that the project team reports to. Second, the RFP's defining trait: it always includes timelines and budget or cost information, and it leads to a contract.

Where it fits: Chapter 5's technical specifications become requirements here; Chapter 7's acceptance testing gates the final payment agreed in this chapter's negotiation.

Key concepts

RFI vs. RFP (Chapter 6 contrast)

In plain English: Informal fact-finding versus the formal ask that ends in a contract.

Technical meaning: RFI: informal, no commitment from either party, gathers information on prospective vendors, may or may not include budget or cost information. RFP: formal, leads to a contract, outlines detailed requirements and how vendors will be compared, always includes timelines and budget or cost information.

Picture it: 'Always includes timelines and cost information' and 'leads to a contract' both name the RFP.

Governance / steering committee

In plain English: The senior group the project reports to.

Technical meaning: Provides oversight but is often not directly involved in the team; the selection team reports to it; it remains intact once implementation begins to monitor and ensure the project's success. In some organizations it is called a steering committee.

Picture it: An advisory committee of high-level stakeholders guiding policy and budgetary control — that phrasing names the steering committee.

The nine selection team roles

In plain English: Who sits on the team that picks the system.

Technical meaning: Facilitator, executive sponsor, technical representative, business representative, program/project manager, contracting representative, financial representative, organizational change leader, governance committee.

Picture it: The team is cross-functional by design: clinical, operations, IT and business.

Requirement ranking

In plain English: Required, preferred, optional.

Technical meaning: Requirements ranked so it is clear which are absolutely necessary, agreed by all committee members, applied consistently to all vendors, and fed into the RFI or RFP.

Picture it: Vendors rarely meet everything, which is why the ranking exists.

Requirement creep

In plain English: The list grows past what you set out to solve.

Technical meaning: Can occur very quickly if the team is not focused on the identified need; the governance committee and executive sponsors ensure requirements fit within defined goals and objectives.

Picture it: The governance committee's job here is subtractive, not additive.

Real-world examples

A department wants a scheduling system. The business case presents the need and several possible approaches, not one product. The source is explicit: avoid identifying a single solution.

The team ranks 140 requirements as required, preferred or optional. Two vendors both fail on optional items and only one fails on a required item. The ranking made that decision mechanical.

Distinctions & exam traps

EXAM TRAP · RFI vs. RFP

The tempting confusion: Both are vendor-facing documents in the same funnel.

The deciding clue: RFP is formal, leads to a contract, and always includes timelines and budget or cost information. RFI is informal, requires no commitment, and may or may not include cost.

Stem wording that triggers it: 'Leads to a contract and always includes timelines and cost' names the RFP. (Adjacent document.)

EXAM TRAP · Selection team membership

The tempting confusion: Options offering a vendor representative, a patient advisory member, or an external auditor among the team roles.

The deciding clue: The nine named roles are all internal to the organization and cover clinical, operations, IT and business.

Stem wording that triggers it: A vendor on the selection team is the outlier. (Category outlier.)

EXAM TRAP · Governance vs. project team

The tempting confusion: Treating the governance committee as part of the working team.

The deciding clue: It provides oversight, is often not directly involved, and the selection team reports to it.

Stem wording that triggers it: 'Advisory committee of high-level stakeholders guiding policy and budgetary control' names the steering committee. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give the three-line RFI/RFP contrast from this chapter without looking.
  2. Name six of the nine selection review team roles and what each contributes.
  3. Explain what a business case should and should not contain.
  4. Explain requirement ranking and why it exists.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Selection process beginning with identification of a need and approval of a project proposal; success dependent on an organized selection process followed by a well-planned and executed implementation strategy; governance committee evaluating the need against organizational mission, goals, objectives, IT strategic plan, budget and available resources
  • Objectives, goals and measures of success clearly defined once the decision is made; team assembled to analyze and further define requirements; appropriate team members ensuring all affected parts of the organization are included; opportunities for process improvement and workflow efficiencies identified
  • RFI: informal request for information requiring no commitment from either party; collection of documents collecting information on prospective vendors and their ability to meet the defined need or high-level requirements; may or may not include budget or cost information
  • RFP: formal request leading to a contract between the organization and selected vendor(s); collection of documents outlining detailed requirements and how each responding vendor will be compared for a final decision; always includes timelines and budget or cost information
  • Vendor evaluation including on-site visits, reference checks, demonstrations and sometimes a trial version or trial period; contract negotiations for the best deal on price, payment plan, support levels and ongoing support; verification of regulations as part of standard selection practice
  • Implementation strategies chosen to fit culture, objectives and available resources; proper planning and defined methodology decreasing project risk; planning for post-live activities including configuration management, user communication, user support, new employee training, operations and maintenance
  • System selection beginning with a defined need based on strategic objectives or a solution to a problem blocking an organizational or departmental objective; overlap with the systems analysis phase; the described process used as a modifiable template
  • Business case, project proposal or needs assessment outlining goal, objectives and high-level resources; most organizations requesting one before approving selection; imperative that the IT governance committee request one if not required; resources often defined through scientific guesses; market research providing more accurate estimates from high-level requirements; formal market research through an RFI-like process clearly stated as research only with no intent to purchase; informal research through vendor exhibitions, Internet searches and contact with similar organizations
  • Business case presenting need and requirements rather than a single solution, offering several solutions or recommendations; governance committee deciding whether to move forward based on strategic plan or operational goal fit and resource availability
  • Requirements list: functional requirements; organization-specific functionality; security and privacy; regulatory; standard and custom reporting; integration with other applications or devices; interoperability; access from multiple locations including acute care, long-term care and clinics; access from mobile devices; redesigned workflow; decision support functionality/nonfunctional requirements
  • Cloud infrastructure requirements: capacity; separate cloud environments for production, development, testing and training; load balancing configuration; software as a service or platform as a service
  • Facility IT infrastructure requirements: space, cooling and power; hardware for production, development, testing and training; 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
  • Service requirements: supplemental staffing for implementation, training and post-live support; independent verification and validation providing impartial reviews of business and technical aspects to reduce risk; processes for issue resolution and requests for enhancement; maintenance and support process and procedures; expected procurement and implementation timeline and constraints; expected availability, reliability and scalability; training requirements
  • Gap analysis as a possible first step in defining requirements; requirement creep occurring quickly without focus; governance committee and executive sponsors ensuring requirements fit defined goals and objectives
  • Requirements ranked as required, preferred or optional; rarity of vendors meeting every requirement; rankings agreed by all committee members and used consistently for all vendors; rankings feeding the RFI or RFP
  • Build vs. buy factors: organizational skill set to build and support; budget room to buy; expected timeline; fit with organizational IT strategy; existence of a vendor able to meet the need; decision possible early, after RFI/RFP responses, or in between
  • Cloud vs. on premise criteria: personnel requirements to install and maintain software; hardware purchase and maintenance; proper monitoring and auditing; alignment with privacy and security requirements in the cloud
  • Review team selected as early as possible, balancing the right people against manageable size; representatives from clinical, organizational operations, IT and business
  • Nine selection roles: facilitator (overall leadership and coordination); executive sponsor (support, mission clarification, resource facilitation, champion); technical representative (IT, biomedical, telecommunications expertise); business representative (business or clinical end-user expertise, knowledge of current business and workflows); program/project manager (implementation and methodology expertise); contracting representative (contracting, negotiation and process expertise); financial representative (budgetary expertise); organizational change leader (facilitating organizational change); governance committee (oversight, not directly involved, receives team reports, remains intact through implementation, sometimes called a steering committee)
  • Team members representing their area, gathering information from peers; all requirements reviewed and approved by the team
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.

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 · Source: Solution Selection Activities

L6.2 · Solution Selection Activities

Walkthrough

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 contractsome regulations are in place to avoid giving any one vendor an advantage.

The named selection activities, in order:

1. RFI. Provides a format for gathering information about which vendors are able to meet the high-level requirements. Responses are compared with the documented requirements, which may be modified prior to posting the RFP if some required items are unavailable or need more definition.

2. RFP. The official request for vendors to submit how they will meet the requirements, which are more defined and include timelines and budget details.

3. Evaluation of RFP responses. Reviewed and scored based on ability to meet required, preferred and optional requirements. Accomplished with the entire team doing independent scoring of each response, followed by team discussion and consensus on a final score. This is the first opportunity to eliminate any vendor that cannot meet the organizational need.

4. Comparison to IT strategic plan. Is the IT roadmap leading toward virtualization, simplification of technologies, or a decreased number of vendors? How does the offered solution fit? It might be OK if the solution does not fit, but that fact should be considered during selection.

5. Evaluation of a vendor's interoperability capabilities. To adopt best of breed solutions, it is absolutely critical to have interoperable systems that do not add burden to the end user workflow. Capabilities span a wide spectrum from core data integration, standard-based data sharing such as FHIR or HL7 Version 2, to optimal application integration using SMART on FHIR or CDS Hooks standards.

6. 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.

7. Background checks. Evaluation of 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 levelearly adopter who can tolerate issues in exchange for influencing new features, or a preference for a solid, reliable application the vendor has had time to refine. The outcome should be included in the scoring.

8. Demonstrations. Allows vendors to show how they can meet the request, providing a visual that is very beneficial — but often done with a generic version of the product that does not reflect how it can be customized to fit the organization's workflows or processes.

The rules for a fair demonstration:

  • Provide a list of scenarios to the vendors beforehand so they 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
  • Whenever possible, the same people should be invited to all scheduled demonstrations
  • Control the agenda very tightly, covering all scenarios, optionally allowing extra functionality at the end
  • Schedule demonstrations closely together so the information is fresh when scored

9. Trial period or trial version. With many cloud-based solutions it is becoming easier to offer trials. Lets the facility run through the end user scenarios to see fit for the requirements and identify roles and responsibilities needed for real implementation.

10. Site visits. Visiting a site that has already implemented the vendor's solution provides an opportunity to speak with people directly, ask specific questions and see how the solution works within their workflows and processes. Questions range from what it is like to work with the vendor, how they respond to support requests during implementation or after go-live, and how easy it is to customize or integrate the application. It is optimal if the organization, and not the vendor, chooses what sites to visit, but this is not always an option.

11. Client references. If a site visit is not possible, a call with the reference site still allows questions. Remote web meeting technologies can provide a demonstration of how a client uses the system without travel. Remember to ask about lessons learned. There should be predefined questions asked of each reference site.

12. Selection meetings. The team meets regularly to continuously evaluate and score the remaining vendors against new information from research, demonstrations, site visits and original proposal scores. Through this process, the number of vendors should be decreased to two or three.

13. Negotiation. The contract representative negotiates with the remaining vendors covering cost, software, hardware, implementation services, support and maintenance. The selection committee, as well as a legal representative, should carefully review all documents — once the papers are signed, they are a binding contract. Cost tables should include software licenses, integration, data conversions, training, implementation services, hardware and third-party software licenses.

14. Selection. Each step, along with the justification of the selection, should be documented in case any vendor chooses to contest the award. Final agreements often include 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.

15. Budget development. The budget is developed based on costs defined during negotiation and selection, and often needs to include costs beyond the system vendor: contractors to supplement 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.

Shortening the 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.

Big picture

The exam's angle on this section is which activity validates what. The activities are not interchangeable:

  • RFP scoring eliminates vendors who cannot meet requirements
  • Demonstrations show capability, but on a generic product
  • Site visits and client references are the only activities that reveal what the vendor is actually like to work with — support responsiveness, customization reality, lessons learned
  • Background checks validate financial stability and market position
  • Negotiation fixes cost and obligations

When a stem asks what best validates vendor claims for a shortlist, the answer is the activity that goes to an existing customer, not the one the vendor controls.

Where it fits: the final agreement terms named here — deliverables, penalties, acceptance — are what Chapter 7's acceptance testing validates against.

Key concepts

Site visit / client reference

In plain English: Ask someone who already lives with it.

Technical meaning: Visiting or calling a site that has implemented the vendor's solution to ask about working with the vendor, support responsiveness during implementation and after go-live, ease of customization and integration, and lessons learned; predefined questions for each reference.

Picture it: The one activity the vendor does not script.

Fair demonstration rules

In plain English: Same scenarios, same people, tight agenda, close together.

Technical meaning: Provide scenarios in advance so vendors show how they meet your needs rather than only chosen features; guide all vendors through the same scenarios; invite the same people to all demonstrations; control the agenda tightly; schedule demonstrations closely together so information is fresh for scoring.

Picture it: Without these, you are comparing four different sales pitches, not four products.

Independent scoring then consensus

In plain English: Everyone scores alone first, then the team agrees.

Technical meaning: The entire team scores each RFP response independently, followed by team discussion and consensus on a final score.

Picture it: Independent first prevents the loudest voice from setting the score.

Risk tolerance and product maturity

In plain English: Bleeding edge or proven.

Technical meaning: How long a product has been on the market and how many customers use it should be matched to the organization's risk tolerance — early adopter tolerating issues in exchange for influencing features, versus a refined, reliable application.

Picture it: Same idea as Chapter 5's technology adoption curve, applied to one purchase.

Real-world examples

Three shortlisted vendors all demo beautifully. Only the site visits reveal that one vendor's support queue runs two weeks and another requires professional services for every configuration change.

A budget is built and the team forgets workstations, integration services from a second vendor, and travel. The source lists all three explicitly as costs beyond the system vendor.

Distinctions & exam traps

EXAM TRAP · Validating vendor claims

The tempting confusion: Choosing demonstrations, RFP scoring or a trial when the stem asks what best validates vendor claims.

The deciding clue: Demonstrations use a generic product the vendor controls. Site visits and reference checks go to existing customers.

Stem wording that triggers it: 'Best validates vendor claims' points to the reference site, not the demo. (Wrong layer.)

EXAM TRAP · Budget scope

The tempting confusion: Limiting the project budget to the vendor's quoted cost.

The deciding clue: The budget must include contractors, change management, non-vendor hardware, third-party integration services, training, travel, and fixed or variable costs such as space and staffing.

Stem wording that triggers it: 'Beyond the system vendor' is the source's own phrase. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name eight of the selection activities in order.
  2. Give the four rules that make a vendor demonstration comparable.
  3. Explain why site visits reveal something demonstrations cannot.
  4. List five costs a project budget must carry beyond the system vendor's quote.

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Vendor search after requirements approval and the buy decision; consulting contracting or legal representatives about rules for contacting vendors prior to a signed contract; regulations avoiding advantage to any one vendor
  • RFI gathering information on which vendors meet high-level requirements; responses compared with documented requirements which may be modified before posting the RFP
  • RFP as the official request for vendors to submit how they will meet more defined requirements including timelines and budget details
  • Evaluation of RFP responses scored on ability to meet required, preferred and optional requirements; entire team scoring independently followed by discussion and consensus; first opportunity to eliminate vendors that cannot meet the need
  • Comparison to the IT strategic plan considering direction toward virtualization, simplification of technologies or fewer vendors; acceptable for a solution not to fit provided the fact is considered
  • Evaluation of interoperability capabilities as critical for best-of-breed adoption without adding end user workflow burden; spectrum from core data integration and standards-based sharing using FHIR or HL7 Version 2 to application integration using SMART on FHIR or CDS Hooks
  • Compliance with regulatory requirements listed as essential; all vendors evaluated against government, regulatory or security requirements
  • Background checks evaluating financial stability, market share and customer satisfaction; product time on market and customer count matched to organizational risk tolerance; early adopter versus refined reliable application; outcome included in vendor scoring
  • Demonstrations providing a beneficial visual but often using a generic product not reflecting customization; scenarios provided in advance so vendors show how the product meets your needs rather than chosen features; all vendors demonstrating the same scenarios; same people attending all demonstrations; tightly controlled agenda with optional additional functionality at the end; demonstrations scheduled closely together for fresh scoring
  • Trial period or trial version increasingly available with cloud-based solutions; running end user scenarios to assess fit and identify roles and responsibilities for real implementation and additional planning
  • Site visits to organizations that implemented the vendor's solution; speaking directly, asking specific questions and seeing the solution within their workflows; questions on working with the vendor, support responsiveness during implementation and after go-live, and ease of customization and integration; number of visits dependent on remaining vendors; participants determined by impact and travel distance; optimal for the organization rather than the vendor to choose sites
  • Client references by call when a site visit is not possible; remote web meeting demonstrations; asking about lessons learned; predefined questions for each reference site; web searches and informal peer contacts as additional reference information
  • Selection meetings continuously evaluating and scoring remaining vendors against research, demonstrations, site visits and proposal scores; narrowing to two or three vendors; final evaluations provided to the contracting representative for negotiations
  • Negotiation by the contract representative covering cost, software, hardware, implementation services, support and maintenance; careful review by the selection committee and legal representative since signed papers are a binding contract; multiple back-and-forth modifications; cost tables including software licenses, integration, data conversions, training, implementation services, hardware and third-party software licenses
  • Selection based on negotiations and final offers; documentation of each step and the selection justification in case a vendor contests the award; final agreements including payment schedule, vendor and client responsibilities, delivery schedule, system installation and configuration documentation, specific deliverables, standard project plan, penalties for missed deadlines, termination process, assignment of licenses and upgrade or update process
  • Budget development from negotiated and selection costs; inclusion of costs beyond the system vendor such as supplemental contractors, business change management requirements, non-vendor hardware including workstations and printers, integration services from other vendors, training, travel and standard fixed or variable costs such as space and staffing; budget typically finalized within 30 days after final contract award
  • Process formality, steps and length varying with contract size, time constraints or desire to stay with a single vendor; each cut step bringing risk; organization balancing risk versus benefit of shortening the process
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 · Source: Implementation Process; Change Management; Implementation Strategies

L6.3 · The Implementation Process and Change Management

Walkthrough

The eight implementation phases

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:

  1. Planning
  2. Analysis
  3. Design
  4. Build
  5. Test
  6. Train
  7. Implementation
  8. Closeout

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 must decide the project team's roles, which tasks belong to the facility project team vs. the vendor implementation team, the project manager's authority, the documentation and deliverables expected, and the role of the governance or steering committee.

The project management plan

The initial activity is to plan how the project will be accomplished, including 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.

The plans that together make up the project management plan:

  • the risk management plan
  • the change management plan
  • the training plan
  • the testing plan
  • the issue management plan
  • the work breakdown structure
  • the communication plan

When preparations begin for the activation (go-live), the activation plan is developed and approved.

The kickoff meeting

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 seven agenda items:

  1. The project scope
  2. The project management methodology, or how the project will be managed
  3. The change management process, or how changes are requested, analyzed and approved
  4. Identified risks and their mitigation strategies
  5. Introduction of the project team and their roles
  6. High-level milestones and schedule
  7. The communication plan

That agenda is the exam's answer to "which document introduces the project team, high-level milestones and the communication plan."

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 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 include members from all affected areas, so they have a sense of ownership and commitment to the project's success.
  • The team should identify clinical champions as well as IT champions who serve as the decision makers and point of contact for change management and risk-management activities.
  • The team should define a strategic plan similar to the project plan, taking 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.

On adoption: adoption is often affected by users' perceptions of how the system fits with their workflowdoes it provide efficiencies or appear to be extra work? Often, 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 about usability.

The five implementation strategies

StrategyDefinitionTrade-off
Big bangGoing live with all functionality in all locations at the same timeMay be the only option if a legacy system is being replaced; requires considerable coordination to ensure all areas are ready with hardware in place, training completed and enough support staff available
Phased by locationGoing live with all functionality in one location at a timeExtends the duration of activation; staff from live areas can support those that follow; lessons-learned meetings after each phase enable continuous improvement
Phased by functionalityGoing live in all locations with one feature at a time — e.g. admissions/ADT and demographics first, then CPOE, then clinical documentationExtends activation duration; allows users to gradually get accustomed to the system; lessons-learned meetings after each phase
PilotGoing live initially with one location as a pilot test, then following with everyone else in a phased big-bang processAllows the team to learn from a small group before going live with the entire user community
Like for likeGoing live with functionality to support the same processes that were in place prior to the project; extra functionality added later through configuration management or a later projectOften used when replacing a legacy system or during an upgrade; decreases the complexity of activation and the impact on end users; some users perceive this approach to be useless since they do not see an improvement

They should be evaluated early in the project to determine which one is the right fit for the organization and right for the current system implementation.

Big picture

Two things carry the exam load here: the kickoff meeting agenda (which is what the "introduces the project team, milestones and communication plan" item points to) and the change management principle that automating a bad process is not improvement.

The change management material also sets up Chapter 9's ADKAR and Kotter content. Note the recurring theme: adoption depends on perceived benefit, and perception is shaped by involving users in workflow redesign and hardware selection — not by communicating harder after the fact.

Where it fits: the testing plan named here is Chapter 7's input; the configuration management process is Lesson 6.5.

Key concepts

The eight implementation phases

In plain English: Plan, analyze, design, build, test, train, implement, close.

Technical meaning: Planning, analysis, design, build, test, train, implementation and closeout; methodologies differ only in terminology or number of phases.

Picture it: Train sits between test and implementation — training happens before go-live, not after.

The project management plan

In plain English: Seven plans bundled into one.

Technical meaning: Risk management plan, change management plan, training plan, testing plan, issue management plan, work breakdown structure and communication plan; the activation plan is developed later when go-live preparations begin.

Picture it: Scope is approved by the sponsors before any of these are finalized.

Kickoff meeting agenda

In plain English: The meeting that tells everyone what is happening.

Technical meaning: Project scope; project management methodology; change management process; identified risks and mitigation strategies; introduction of the project team and their roles; high-level milestones and schedule; the communication plan.

Picture it: Team introduction + milestones + communication plan together name the kickoff.

Improve, don't just automate

In plain English: A faster bad process is still a bad process.

Technical meaning: It is not good enough to just automate a process; the process should be improved through automation.

Picture it: Same principle as Chapter 4's 'map before you automate', stated from the change side.

The five implementation strategies

In plain English: All at once, by place, by feature, one pilot site, or same-as-before.

Technical meaning: Big bang; phased by location; phased by functionality; pilot; like for like.

Picture it: Phased approaches extend activation duration but let earlier groups support later ones.

Real-world examples

A three-site health system with rotating shifts and one week to go-live cannot get everyone through a classroom. Phased or role-based approaches plus super users and just-in-time support are what the source points to.

A hospital replaces a legacy EHR like for like to reduce activation complexity. Predictably, some clinicians complain they see no improvement — the source names that exact reaction.

Distinctions & exam traps

EXAM TRAP · Which document has team, milestones and communication plan

The tempting confusion: Choosing the project charter, the communication plan itself, or the work breakdown structure.

The deciding clue: The kickoff meeting agenda includes scope, methodology, change process, risks, team introduction, high-level milestones and the communication plan.

Stem wording that triggers it: Team introduction plus milestones plus communication plan names the kickoff. (Adjacent document.)

EXAM TRAP · Automate vs. improve

The tempting confusion: Options praising faithful automation of the existing process.

The deciding clue: The source rejects it outright: the process should be improved through automation.

Stem wording that triggers it: Any option that treats automation alone as the goal is wrong. (Plausible-but-upstream.)

EXAM TRAP · Strategy naming

The tempting confusion: Confusing phased by location with phased by functionality, or pilot with big bang.

The deciding clue: By location = all functionality, one site at a time. By functionality = one feature, all sites. Pilot = one site first, then a phased big bang.

Stem wording that triggers it: Read which dimension is being held constant. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the eight implementation phases in order.
  2. List the seven plans that make up the project management plan.
  3. Recite the kickoff meeting agenda.
  4. Describe the five implementation strategies and name the trade-off for each.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Implementation phases fairly standard with methodologies differing in terminology or number of phases: planning, analysis, design, build, test, train, implementation, closeout; all starting with information gathering and planning the required work, when and how; most projects failing due to lack of planning, poor planning, or not following the plan
  • Absent a defined project management strategy, deciding project team roles, allocation of tasks between the facility project team and vendor implementation team, project manager authority, expected documentation and deliverables, and the role of the governance or steering committee
  • Initial activity of planning how the project will be accomplished, defining what is within and outside scope; project sponsors approving scope before other plans are finalized
  • Project management plan components: risk management plan, change management plan, training plan, testing plan, issue management plan, work breakdown structure, communication plan; activation plan developed and approved when go-live preparations begin
  • Kickoff meeting at the end of planning after sponsor approval, communicating the project to all stakeholders; agenda of project scope, project management methodology, change management process for requesting, analyzing and approving changes, identified risks and mitigation strategies, introduction of the project team and roles, high-level milestones and schedule, and the communication plan
  • Change management: new systems impacting the organization; not good enough to just automate a process, the process should be improved through automation; changes affecting everyone from top management to end users; planning and evaluating change options beginning during procurement
  • Top-level support and a senior leadership member on the change management team to show commitment and provide strong leadership; members from all affected areas for ownership and commitment; clinical champions and IT champions serving as decision makers and points of contact for change and risk management activities
  • Strategic plan similar to the project plan considering organizational culture and politics around change; identifying types of resistance and strategies to break down resistance and move to acceptance; clear communication plan for proper dissemination
  • Adoption affected by users' perceptions of workflow fit and whether the system provides efficiencies or appears to be extra work; adoption often based on perceived benefit; staff readiness requiring stakeholder involvement in workflow redesign; end user involvement in hardware selection such as workstations on wheels or mobile devices providing usability feedback
  • Big bang: all functionality in all locations at the same time; possibly the only option when replacing a legacy system; requiring considerable coordination for hardware, completed training and sufficient support staff
  • Phased by location: all functionality one location at a time; extends activation duration; live areas assisting those that follow; lessons-learned meetings after each phase
  • Phased by functionality: one feature at a time in all locations, e.g. admissions/ADT and demographics, then CPOE, then clinical documentation; extends activation; users gradually accustomed to the system; lessons-learned meetings after each phase
  • Pilot: one location as a pilot test followed by everyone else in a phased big-bang process; learning from a small group first
  • Like for like: functionality supporting the same processes in place prior to the project, with extra functionality added later through configuration management or a later project; used when replacing a legacy system or upgrading; decreases activation complexity and end user impact; some users perceiving no improvement
  • Strategies evaluated early to determine fit for the organization and the current implementation
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.

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.

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.

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.

Chapter 6 · Source: Implementing Solutions; System Integration to Support Business Requirements; User and Operational Manuals and Training; Activation Planning and Immediate Post-Activation Activities

L6.4 · Implementing Solutions, Integration, Training and Activation

Walkthrough

Configuration and data migration

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.

Named configuration work: clinical documentation data entry into notes or flow sheets, as well as output as reports; each order that can be placed for a patient — medications, diagnostic tests, diets and consults; drop-down lists for a patient's religion during admission; how surgery will be scheduled.

Data conversion. 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 all data is in the new system at go-live. Care should 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 should also be implemented to align with industry standards such as RxNorm, SNOMED and LOINC.

Controlling scope during execution

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
  • 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.

Scope creep is the uncontrolled expansion of project requirements after approval — and the defined change process is the named defense.

Testing. Testing activities occur throughout the execution. A test plan, started during the planning and analysis phases, describes all the different testing activities. Often the first testing activity is verifying that the hardware and application were installed correctly, in each of the initial environments such as development, testing, or training.

System integration

It is rare in healthcare today to have a stand-alone system that does not share data with another in some way. Integration allows data to be in multiple systems without manual data entry.

The three integration types:

  1. Real-time data integrationsharing 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.
  2. Scheduled data integrationsharing of data in a batch according to a predetermined time frame, such as nightly at midnight or every so many hours; accomplished through formatted files or HL7 messages.
  3. Integration of data from devicesfeeding of data from a specific device into an application, 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. The source's example: a source system sends first name and last name, but the destination can only accept a full name; the interface engine combines them. 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.

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 to allow the training team to develop materials and hypothetical patient data for practice exercises.
  • Training activities are tricky to schedule because they need to take place on the system that will actually be in usethe training environment cannot be fully set up until the entire configuration is completed and a copy created.
  • Factors that determine training type: 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.
  • 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

Planning for go-live begins with the decision on implementation strategy 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.

  • Moving from a manual process to an automated one, or implementing a new system, the activation could be as simple as having users start using the system.
  • Migrating from a legacy system or upgrading, 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 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 and boosts the project team's level of confidence because they have already done the tasks at least once.

Beyond the tasks: where everyone will sit; whether a command center will be set up; whether food and drink will be available; whether there will be a place for staff to rest; what forms of communication will be available for anyone not in the command center; how status updates will be communicated to end users; how issues requiring escalation will be handled; and whether the vendor will be on-site or on the phone.

Post-activation support depends on the impact of the change and the amount of just-in-time training expecteda clinic might have support just before and during clinic hours for the first week; a new EHR in an acute setting might need support around the clock for the first few weeks.

Handling early change requests

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.

But 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.
  • The rest of the suggested changes should be evaluated one to two months after activation to see if they are still needed.

Big picture

This lesson holds the exam's scope creep definition and its training method items. On training, hold the vocabulary: train-the-trainer prepares selected staff to instruct their peers; super users are experienced end users providing real-time coaching on the unit during activation. Both appear in real implementations and both are distinct from classroom training and computer-based modules.

The other durable idea is the wait-one-to-two-months rule for non-critical change requests. Early complaints usually reflect unfamiliarity rather than defect, and the source says so plainly.

Where it fits: the testing that begins here is Chapter 7's subject; the configuration management process that governs post-live change is Lesson 6.5.

Key concepts

Scope creep

In plain English: The project quietly grows past what was approved.

Technical meaning: Uncontrolled expansion of project requirements after approval; prevented by a defined process for evaluating each change request's impact, identifying who can submit changes, how they are evaluated, what documentation is required and who decides.

Picture it: Requests may be approved, denied, or deferred — deferral is a real answer.

The three integration types

In plain English: Live, batched, and from devices.

Technical meaning: Real-time integration (near-simultaneous on entry, modification or trigger; standard is HL7); scheduled integration (batch at predetermined times, via formatted files or HL7); device integration (data fed from monitors, anesthesia machines, ventilators, often requiring verification before becoming official).

Picture it: Device data may need clinician verification — the same rule Chapter 2 states.

Just-in-time training

In plain English: Help at the elbow when it is actually needed.

Technical meaning: The best planning will not eliminate the need for it; filled by end-user manuals, quick reference guides and the presence of support staff during the initial week or two.

Picture it: Someone always misses class or forgets. Plan for it rather than treating it as failure.

Activation rehearsal

In plain English: A dress rehearsal for go-live.

Technical meaning: Tests the activation process and fixes mistakes; evaluating it refines the process and the checklist and boosts team confidence since the tasks have been done at least once.

Picture it: The checklist and the rehearsal work as a pair.

The one-to-two-month rule

In plain English: Don't rebuild the system in week one.

Technical meaning: Unless suggestions are critical to patient care, document them; critical issues are handled right away through the change management process; the rest are evaluated one to two months after activation to see if they are still needed.

Picture it: Most early suggestions evaporate once the workflow becomes familiar.

Real-world examples

Go-live is a week away, clinicians work rotating shifts across three sites, and classroom capacity is limited. Super users on the unit plus quick reference guides and around-the-clock support cover what training cannot reach.

A source system sends first and last name separately; the destination accepts only a full name. The interface engine concatenates them. That is the source's own worked example of interface-engine manipulation.

Distinctions & exam traps

EXAM TRAP · Scope creep naming

The tempting confusion: Choosing requirement creep, gold plating or change control.

The deciding clue: Uncontrolled expansion of project requirements after approval is scope creep; the defined change process is what prevents it.

Stem wording that triggers it: 'Uncontrolled expansion ... after approval' names scope creep. (Adjacent term.)

EXAM TRAP · Train-the-trainer vs. super users

The tempting confusion: Both involve staff teaching staff.

The deciding clue: Train-the-trainer prepares selected staff to instruct their peers. Super users are experienced end users providing real-time coaching on the unit during activation.

Stem wording that triggers it: 'On the unit during activation' names super users. (Adjacent role.)

EXAM TRAP · Acting on early change requests

The tempting confusion: Choosing to implement popular requests immediately to build goodwill.

The deciding clue: Unless critical to patient care, document and revisit one to two months after activation.

Stem wording that triggers it: Early requests usually reflect unfamiliarity. (Plausible-but-upstream.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define scope creep and name the four things a change management plan must identify.
  2. Describe the three integration types and say which standard governs real-time integration.
  3. Explain why the training environment cannot be built early, and what fills the resulting gap.
  4. Give the rule for handling non-critical change requests in the first weeks after go-live.

Questions

5 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Project team customizing the vendor's basic vanilla application; vendor training the project team on making changes; configuration of clinical documentation entry into notes or flow sheets and output as reports; configuration of every order type including medications, diagnostic tests, diets and consults; drop-down lists such as patient religion at admission; surgery scheduling
  • Data conversion or loading from a legacy system during this time; some migration occurring during activation to ensure all data is present at go-live; care to avoid data duplication; data validation after each migration with an action plan to resolve duplicate records; vocabulary mapping aligned to industry standards such as RxNorm, SNOMED and LOINC
  • Change requests during execution; defined evaluation process determining project impact and preventing scope creep; change management plan identifying who can submit changes, how they are evaluated, required documentation and who makes the final decision; requests approved, denied or deferred; project sponsors deciding with the project manager facilitating impact analysis
  • Testing throughout execution; test plan started during planning and analysis describing all testing activities; first activity often verifying correct hardware and application installation in development, testing and training environments
  • Rarity of stand-alone systems; EHR including lab and radiology data for medical decisions; demographic sharing between outpatient/office systems and the inpatient EHR; integration allowing data in multiple systems without manual entry
  • Real-time data integration sharing data nearly simultaneously on entry, modification or defined trigger, with HL7 as the standard defining interface message specifics so the source output is acceptable to the destination
  • Scheduled data integration sharing data in batch on a predetermined time frame such as nightly at midnight or every few hours, through formatted files or HL7 messages
  • Integration of data from devices feeding data from hemodynamic monitors, vital sign monitors, anesthesia machines and ventilators into an application; decreasing manual entry but possibly requiring verification before the data becomes official
  • Interface engine receiving information from the source system and passing it directly or modifying it first, e.g. combining first and last name into a full name; differing structural requirements and expected data locations; interface message sections and a mapping document describing expected data location and any needed manipulation
  • End user education through documentation and training as activation nears; training environment set up early for materials and hypothetical patient data; training must take place on the system actually in use, so the environment cannot be fully set up until configuration is complete and copied
  • Training type determined by organizational culture, extent of change, number of users, users' work hours and staff comfort with computers; delivery through computer-based training modules, lectures, demonstrations, hands-on exercises or a combination
  • Training occurring right before activation for retention; timing dependent on user numbers and class length; just-in-time training always needed; end-user manuals, quick reference guides and support staff presence during the initial week or two filling the gap
  • Activation planning beginning with the implementation strategy decision and continuing through the project; working with the vendor to define advance versus go-live-day activities; simple activation when moving from manual to automated or implementing new; complex activation with downtime when migrating from a legacy system or upgrading; detailed pre- and during-activation checklist; rehearsal testing the process and fixing mistakes, refining the checklist and boosting team confidence
  • Activation logistics: seating, command center, food and drink, rest space, communication for those outside the command center, status updates to end users, escalation handling, vendor on-site or by phone
  • Post-activation support type and duration dependent on change impact and expected just-in-time training; clinic support before and during clinic hours for the first week; acute EHR support around the clock for the first few weeks
  • Immediate user change suggestions; clear submission process showing input is valued; importance of not making changes too early since suggestions often reflect newness; documenting non-critical suggestions; handling critical issues right away through the defined change management process; evaluating the remainder one to two months after activation
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 · Source: Managing Healthcare Information Systems; Analyzing Data for Problems and Trends; Ensuring Critical Functions Are Repaired, Maintained or Enhanced; Business Continuity and Disaster Recovery Plans

L6.5 · Managing Healthcare Information Systems and Analyzing Data for Trends

Walkthrough

Operations and maintenance mode

Once the system is live, it moves into operations and maintenance mode. The IT department must ensure that it continues to support the mission and goals of the organization and remains reliable and stable.

Processes put in place during the implementation project in preparation for this phase: 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.

The seven operations and maintenance documents

  1. Communication plandefines how end users communicate with the IT department about the new system: how to request help for an issue, request modifications, and request help for general questions about how to use the system
  2. Service desk knowledge baseexplains how to identify and resolve issues when a user contacts the service desk, including questions to ask and decision trees to identify the resolution or the escalation process; 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
  3. Data flow documentsidentify 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, including the triggers that prompt the data to flow (a change in the patient's location triggering an update to the lab system)
  4. Workflow documentsexplain end users' workflows and how the system fits into users' daily activities
  5. Configuration management processdefines how changes are made and what levels of approval and documentation are required for each change
  6. Downtime proceduresidentify 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
  7. Manualsend-user manuals, training guides and the configuration manual that provides step-by-step directions on how to make changes in the system

Configuration and release management

Configuration management and release management are processes to control changes to the system, including software and hardware. They cover:

  • how changes are requested
  • the process for review and approval of changes
  • how changes are made and tested
  • the process for releasing changes to the different environments to ensure 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.

Updates. 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

Often provided through a help desk or a single phone number. Calls may pertain to an issue with the system; a problem with the usability of the system; or a training or how-to question. A good knowledge base that allows help desk staff to ask the right questions and 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 supportoften 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.

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.

Reasons to collect data and look for trends: levels of new system adoption over the months or years, user satisfaction with a system, trends in system performance.

Collection methods: 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.

Help desk logs are the source's named data source for recurring end-user problems after go-live.

Ensuring critical functions are repaired, maintained or enhanced

The technical staff receives many different kinds of requests for change: feedback from users through help desk calls, rounds, user groups and direct change requests. Some 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.
  • 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

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 are often done nightly and stored off-site on redundant servers or through a cloud-computing provider, typically for an indefinite amount of time. Hardware configurations that provide some level of continuity include automatic failover between clustered servers. For critical systems, some organizations have off-site facilities where they can recover the system from backup. 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 disasterhow the issue is identified and resolved, who is involved, and the process for a root cause analysis. 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, 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 whenever the downtime plan is required.

Big picture

The exam's angle on maintenance is which artifact or data source answers which question. Workflow documents explain how the system fits daily activities — that is why they are maintained after go-live, not archived. Help desk logs reveal recurring end-user problems. The configuration management process defines how changes are made and what approval each needs.

The other tested habit is investigate before you act. A help desk spike eight weeks after go-live is a signal, not a diagnosis — the first move is to analyze the tickets for the underlying pattern, not to retrain or reconfigure on assumption.

Where it fits: this closes the delivery arc. Chapter 5 designed the continuity capability; Chapter 8 governs its testing; Chapter 9 handles the management layer over all of it.

Key concepts

Configuration management process

In plain English: The rules for changing a live system.

Technical meaning: Defines how changes are made and what levels of approval and documentation are required for each change; with release management, controls how changes are requested, reviewed, approved, made, tested and released across environments kept in sync with each migration verified.

Picture it: Development → test → production, with regression testing after.

Workflow documents

In plain English: How users actually work and where the system sits in it.

Technical meaning: Explain end users' workflows and how the system fits into their daily activities; maintained as operations and maintenance documentation.

Picture it: Maintained after go-live because support and change decisions depend on knowing the workflow.

Help desk logs as a trend source

In plain English: The tickets tell you what is actually broken.

Technical meaning: Technical trend sources include error reports, help desk logs, monitor logs and unexpected downtimes, used to plan improvements in system performance.

Picture it: 'Most directly reveals recurring end-user problems after go-live' names help desk data.

First-year benefit review

In plain English: Did we get what we paid for?

Technical meaning: Within the first year after go-live, analysis should determine whether the application met the need identified prior to purchase, how well the investment goals were met and whether the expected return on investment was realized; results returned to the governance committee for possible action.

Picture it: The governance committee that approved it is the body that hears the result.

BCP vs. DR vs. downtime plan (Chapter 6 framing)

In plain English: Business functions, technical recovery, and operating on paper.

Technical meaning: The business continuity plan covers preparing for and maintaining business functions, including operations and maintenance, issue resolution, continuing without the system and recovering from a disaster. The disaster recovery plan focuses on technical aspects such as backup and recovery. The downtime plan focuses on business aspects — communication procedures, hard-copy forms and how data will be entered once the system returns.

Picture it: Consistent with Chapter 5: BCP is the umbrella; DR is technical; downtime is operational.

Real-world examples

Help desk volume for one module spikes eight weeks after go-live. The right first move is analyzing the tickets to find the pattern — a configuration gap, a training gap, or a workflow mismatch all look identical from the volume alone.

A hot fix arrives from the vendor. It still goes through evaluation and the configuration management process; if it is large enough, it becomes its own project.

Distinctions & exam traps

EXAM TRAP · Maintenance activities EXCEPT

The tempting confusion: A NOT item mixing configuration management, release management, service desk support and trend analysis with a selection-phase or design-phase activity.

The deciding clue: Maintenance covers operating, upgrading, supporting and analyzing the live system.

Stem wording that triggers it: Circle EXCEPT, then find the option belonging to an earlier lifecycle phase. (Category outlier.)

EXAM TRAP · Responding to a help desk spike

The tempting confusion: Choosing immediate retraining, a configuration change, or vendor escalation.

The deciding clue: Trend analysis exists to identify the underlying pattern before acting.

Stem wording that triggers it: 'Best first response' to a data signal is analysis, not remediation. (Plausible-but-upstream.)

EXAM TRAP · Why workflow documents are maintained

The tempting confusion: Answering that they exist for audit, for training materials, or for regulatory compliance.

The deciding clue: They explain end users' workflows and how the system fits into their daily activities — supporting operations, support and change decisions.

Stem wording that triggers it: 'Exist primarily to' asks for the stated purpose. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the seven operations and maintenance documents and say what each answers.
  2. Explain the environment path a change follows and what testing follows it.
  3. Say what the first-year post-go-live analysis is for and who receives the result.
  4. Distinguish the business continuity plan, the disaster recovery plan and the downtime plan in this chapter's terms.

Questions

5 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • System moving into operations and maintenance mode once live; IT ensuring continued support of organizational mission and goals and remaining reliable and stable; processes prepared during implementation including configuration management, release management, customer support through a service desk and resolution of trouble tickets; configuration documentation feeding operations and maintenance documentation
  • Communication plan defining how end users communicate with IT about the new system — requesting help for an issue, requesting modifications and asking general how-to questions
  • Service desk knowledge base explaining how to identify and resolve issues, including questions to ask and decision trees, and the escalation process covering how to approach the vendor and who has authority to contact them
  • Data flow documents identifying where and how data flows between systems or locations, dependencies between systems and triggers prompting data flow such as a patient location change updating the lab system
  • Workflow documents explaining end users' workflows and how the system fits into daily activities
  • Configuration management process defining how changes are made and what levels of approval and documentation are required for each change
  • Downtime procedures identifying end user procedures when the system is unavailable and technical staff procedures to identify and resolve the causing issue
  • Manuals ranging from end-user manuals to training guides and the configuration manual with step-by-step directions for making system changes
  • Configuration and release management controlling software and hardware changes: how changes are requested, reviewed and approved, made and tested, and released across environments kept in sync with each migration verified; changes made in development, tested in test and verified in production; regression testing after changes ensuring nothing else broke; controlling how and when changes are made avoiding unexpected negative results
  • Vendor update scheduling from small hot fixes to major upgrade releases keeping the system current and minimizing unexpected downtimes; each update evaluated before moving through configuration management; large updates managed as separate projects
  • Customer support through a help desk or single phone number; calls about system issues, usability problems or training and how-to questions; a good knowledge base enabling first-call resolution and high satisfaction; second-tier support process through a help desk or ticket management system or a custom database with workflows and notifications; timely customer feedback until resolution
  • Looking for trends in usage and problems throughout the application life cycle; first-year analysis determining whether the application met the identified need, how well investment goals were met and whether expected ROI was realized; results returned to the governance committee for possible action especially if the need was not met
  • Trend reasons: levels of new system adoption over months or years, user satisfaction, system performance trends; collection through surveys, user groups or visits to users; technical trends in error reports, help desk logs, monitor logs and unexpected downtimes informing performance improvement planning
  • Change requests from help desk calls, rounds, user groups and direct requests; some requiring vendor fixes or enhanced functionality; each change or group evaluated and, if approved, prioritized; smaller changes through configuration management assigned and migrated per the release management schedule; larger requests managed as separate projects following the project management process
  • System criticality defining disaster recovery and business continuity plans; business continuity plan defining how the organization prepares for and maintains business functions including operations and maintenance for stability, resolving issues causing unavailability, continuing without the system and recovering from a disaster
  • Disaster recovery plan focusing on technical aspects such as data backup and recovery; nightly backups stored off-site on redundant servers or through a cloud-computing provider, typically indefinitely; hardware continuity such as automatic failover between clustered servers; off-site recovery facilities for critical systems; technical downtime plan steps for non-disaster outages covering identification, resolution, involvement and root cause analysis; regular testing and updating
  • Downtime plan focusing on business aspects of operating without the electronic system: communication procedures, hard-copy documentation forms and plans for entering data once the system returns; user reluctance to use manual processes; regular downtime plan reviews and pre-downtime communication aiding adoption; support staff available whenever the downtime plan is required
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.

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.

Summary

Chapter 7 · Source: Introduction; Purpose of Systems Testing

L7.1 · Introduction and the Purpose of Systems Testing

Walkthrough

Healthcare organizations rely on information systems to manage the clinical, administrative, financial and legal aspects of daily operations. As new 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.

What testing is for

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 system performance;
  • the same knowledge to the user community, for optimizing system use and sustaining operations;
  • identification of the technical and operational limitations of the system under development so they can be resolved prior to production and deployment.

Information systems have become an integral part of healthcare operations and often have a direct impact on patient safety. With that in mind, identifying and testing for areas that are likely to be major patient safety risks is very important.

Hardware and software testing

System testing and evaluation are performed on both hardware and software.

  • Hardware testing includes evaluation of the physical components of the system — circuits, drives, internal components.
  • 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. It can also provide an objective, independent view of the software that enables the business to appreciate and understand the risks of implementation.

The six things comprehensive testing validates

Comprehensive testing is a process of validating and verifying that a system:

  1. Meets the requirements that guided its design and development
  2. Responds correctly to all kinds of inputs
  3. Performs its functions within an acceptable time
  4. Is sufficiently usable
  5. Can be implemented and run in its intended environments
  6. Achieves the general results the stakeholders desire

The cost of not testing

  • A NIST study released in 2002 reported that software bugs — coding issues as well as integration challenges — cost the US economy $59.5 billion annually.
  • More than a third of these costs could have been avoided if better testing was performed, 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, affecting at least 3.7 billion people.

The first step in executing a successful test is creating a test methodology.

Big picture

Chapter 7 frames testing as risk management, not quality assurance for its own sake. Every question in this chapter is easier if you hold that frame: the purpose is to know the system's limits before patients depend on it.

Where it fits: Chapter 5 wrote the specifications; Chapter 6 implemented against them; Chapter 7 verifies. Chapter 9 then handles ongoing performance evaluation.

Nearby concepts to keep straight: validation (are we building the right thing — does it meet the requirements) and verification (are we building it right). The source uses both words together in the comprehensive-testing definition.

Key concepts

Purpose of system testing

In plain English: Know what the system can and cannot do before it matters.

Technical meaning: To provide knowledge to assist in managing the risks involved in developing, producing, operating and sustaining systems and their capabilities; to give stakeholders and users knowledge of capabilities and limitations; and to identify technical and operational limitations so they can be resolved prior to production and deployment.

Picture it: Testing is a risk-management activity that happens to produce defects as a by-product.

Defect cost curve

In plain English: The later you find it, the more it costs.

Technical meaning: The earlier a defect is found within the product development life cycle, the cheaper it is to fix; NIST found more than a third of the $59.5 billion annual US cost of software bugs could have been avoided with better testing.

Picture it: This is the economic argument for testing early rather than at go-live.

Real-world examples

A CPOE build passes functional testing but has never been tested under simultaneous load. The unknown is not whether it works — it is whether it works at 7 AM shift change, which is precisely the patient-safety risk the source says to test for.

Distinctions & exam traps

EXAM TRAP · Testing's stated purpose

The tempting confusion: Answering that testing exists to prove the system works, to satisfy the vendor, or to meet a contractual formality.

The deciding clue: The source frames it as managing risk and surfacing capabilities and limitations before production and deployment.

Stem wording that triggers it: 'Fundamental purpose' points to risk knowledge, not defect counting. (Plausible-but-upstream.)

EXAM TRAP · The six validation criteria

The tempting confusion: Lists that swap in 'is delivered on budget' or 'satisfies the vendor's roadmap'.

The deciding clue: Meets requirements; responds correctly to all inputs; performs within acceptable time; is sufficiently usable; can be implemented and run in intended environments; achieves the general results stakeholders desire.

Stem wording that triggers it: One altered element in a six-item list. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. State the fundamental purpose of system testing without using the word 'bugs'.
  2. Recite the six things comprehensive testing validates and verifies.
  3. Explain the defect cost curve to a project sponsor who wants to compress the test window.

Questions

No canonical items map to the introduction. It supplies the risk framing and the six validation criteria used throughout the chapter.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Organizations rely on systems for clinical, administrative, financial and legal operations; stakeholders must weigh and mitigate risks of implementing or modifying systems; testing and evaluation as a critical risk-mitigation element
  • Fundamental purpose of system testing: knowledge to assist in managing risks in developing, producing, operating and sustaining systems and their capabilities
  • Provides capability/limitation knowledge to stakeholders for improving performance and to the user community for optimizing use and sustaining operations; identifies technical and operational limitations for resolution prior to production and deployment
  • Direct impact on patient safety; importance of identifying and testing likely major patient safety risks
  • Testing performed on both hardware and software; hardware testing covers physical components (circuits, drives, internal components); software testing investigates quality and validates functionality to find and fix defects before release and provides an objective, independent view enabling the business to understand implementation risk
  • Six validation/verification criteria: meets the requirements guiding design and development; responds correctly to all kinds of inputs; performs functions within acceptable time; is sufficiently usable; can be implemented and run in intended environments; achieves the general results stakeholders desire
  • NIST 2002 study: software bugs (coding and integration) cost the US economy $59.5 billion annually; more than a third avoidable with better testing; earlier defect discovery is cheaper
  • 2017 estimated cumulative worldwide cost of software bugs and failures $1.7 trillion, affecting at least 3.7 billion people
  • First step in a successful test is creating a test methodology
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 · Source: Test Methodology; Test Strategy; Test Tools

L7.2 · Test Methodology, Strategy and Tools

Walkthrough

The six-step test methodology

Testing methodologies are the strategies and approaches used to test a particular product to ensure it is fit for purpose. They 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;
  • in a worst case, will fail safely.

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, in this order:

  1. Define the test strategy
  2. Develop testing tools
  3. Execute testing
  4. Employ test controls
  5. Report on testing results
  6. Perform final evaluation

This order is examinable. Note that controls come after execution begins in the source's list, and that final evaluation is last.

Context the source gives for why methodology matters especially in healthcare: many healthcare organizations adopt a buy-not-build strategy, outsourcing development or purchasing off-the-shelf solutions, so 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 the delivered system meets the organization's needs.

Test strategy

The test strategy is a formal, high-level description of how a system will be tested. It is developed to address all facets of the testing process and ensure testing objectives are achieved. It is also referred to as the test approach, and 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
  • 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
  • risk assessments

Who writes what: the test strategy may be developed by a project manager, with the more detailed test plan created by a test lead or team. Once completed, both 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 depend on the testing method(s) employed. Generally, system testing is performed either manually or through the use of automated tools.

Manual testing is direct human interaction with a system, testing to identify defects or unexpected outcomes. A test team member plays the role of an end user and tests most features of the application to ensure correct behavior. To ensure completeness, the team often follows a written test plan or script leading them through a set of important test cases.

  • Tools required for manual testing: a written test plan, test script or scenarios to follow, and a method of recording and reporting the results.
  • Limitations: manual testing may find many defects but is laborious and time-consuming, and 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
  • performs other test control and test reporting functions

The most significant benefit of test automation is the ability to duplicate the testing process. Once automated, tests can quickly be run and repeated. This is often the most cost-effective method for systems that have a long maintenance life, because even minor patches over a system's lifetime can cause features to break that were working earlier, so repeated testing is required for each patch or upgrade.

Big picture

Two structures here carry most of the question load: the six-step methodology in order, and the strategy-versus-plan distinction.

Hold the strategy/plan split as a level-of-detail pair: strategy is the high-level how, written by the project manager; the plan is the detailed what, derived from documented business requirements, written by the test lead or team. That pairing follows the same umbrella-versus-component pattern as BCP/DR in Chapter 5.

Where it fits: the test plan's pass/fail criteria come from the technical specifications written in Chapter 5 and the contract terms negotiated in Chapter 6.

Key concepts

The six-step test methodology

In plain English: Strategy, tools, execute, control, report, evaluate.

Technical meaning: Define the test strategy; develop testing tools; execute testing; employ test controls; report on testing results; perform final evaluation.

Picture it: Verify the first and last steps first on any sequence item — strategy opens, final evaluation closes.

Test strategy vs. test plan

In plain English: The high-level approach versus the detailed script.

Technical meaning: Strategy = a formal, high-level description of how a system will be tested (scope, objectives, roles, reporting, automation and tools, deliverables, standards, metrics, risks, defect tracking, change/configuration management), often written by a project manager. Plan = derived from documented business requirements, containing test cases, conditions, scripts, schedules, environments, pass/fail criteria and risk assessments, written by a test lead or team.

Picture it: The plan may live inside the strategy or stand alone.

Manual testing

In plain English: A person using the system as a user would.

Technical meaning: Direct human interaction with a system to identify defects or unexpected outcomes, following a written test plan, script or scenarios, with a method of recording and reporting results; laborious and time-consuming, and weak at finding defects not immediately apparent to the end user.

Picture it: Three required tools: plan, script, and a recording method.

Automated testing

In plain English: Software that runs the tests for you, the same way every time.

Technical meaning: Special software separate from the software being tested that controls test execution, compares actual to predicted outcomes, sets up pre-conditions and performs other control and reporting functions. Its most significant benefit is the ability to duplicate the testing process.

Picture it: Most cost-effective for systems with a long maintenance life, because every patch requires repeating the tests.

Real-world examples

A hospital buys an off-the-shelf pharmacy system. Nobody on staff saw it built. The source's argument is that this is exactly when a defined testing methodology stops being optional.

A team automates the regression suite for an EHR upgraded three times a year. The payoff is not speed on the first run — it is that run four costs almost nothing.

Distinctions & exam traps

EXAM TRAP · The six-step order

The tempting confusion: Sequences that swap two adjacent steps, most often controls and reporting.

The deciding clue: Define strategy, develop tools, execute, employ controls, report results, perform final evaluation.

Stem wording that triggers it: Verify first and last, then check the middle pair. (One altered element.)

EXAM TRAP · Strategy vs. plan authorship and content

The tempting confusion: Attributing test cases and pass/fail criteria to the strategy, or roles and metrics to the plan.

The deciding clue: Cases, scripts, schedules, environments, pass/fail criteria and risk assessments sit in the PLAN. Scope, roles, reporting methods, tools, deliverables, standards, metrics and change management sit in the STRATEGY.

Stem wording that triggers it: 'Derived from the documented business requirements' names the plan. (Adjacent document.)

EXAM TRAP · Why automate

The tempting confusion: Answering that automation finds more defects or removes the need for a test plan.

The deciding clue: The most significant benefit named is the ability to duplicate the testing process — repeatability across patches and upgrades.

Stem wording that triggers it: 'Most significant benefit' points to repeatability, not coverage. (Plausible-but-upstream.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite the six methodology steps in order, then say which two you are most likely to swap.
  2. Explain the strategy/plan split to a project manager: who writes each, and what goes in each.
  3. Name the three tools manual testing requires and the two limitations the source gives it.
  4. State automation's most significant benefit in one sentence and say when it pays off.

Questions

1 mapped item. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Testing methodologies as strategies and approaches to ensure a product is fit for purpose: works per specification; no undesirable side effects outside design parameters; fails safely in a worst case
  • Scenarios vary and are tailored by test teams and stakeholders
  • Six-step methodology in order: define the test strategy; develop testing tools; execute testing; employ test controls; report on testing results; perform final evaluation
  • Buy-not-build strategy leaves IT staff with only a partial picture of development history, making a well-defined methodology critical
  • Test strategy: formal, high-level description of how a system will be tested; also called the test approach; may include testing scope and objectives, current business issues, roles and responsibilities, status reporting methods, test automation and tools, list of test deliverables, applicable industry standards, testing measurements and metrics, risks and mitigation, defect reporting and tracking, change/configuration management
  • Test plan: may live within the strategy or as its own document; derived from documented business requirements; may contain test cases, conditions, scripts, testing schedules, test environments, pass/fail criteria and risk assessments
  • Strategy may be developed by a project manager; detailed plan created by a test lead or team; both shared with the project team, end users and stakeholders for review and approval before testing begins
  • Test tools depend on the testing methods employed; testing performed manually or through automated tools
  • Manual testing: direct human interaction; tester plays the end-user role across most features; follows a written test plan or script through important test cases; requires a written test plan, script or scenarios, and a method of recording and reporting results; laborious and time-consuming; may miss defect classes not immediately apparent to the end user
  • Automated testing: special software separate from the software being tested that controls test execution, compares actual to predicted outcomes, sets up pre-conditions and performs other test control and reporting functions
  • Most significant automation benefit is duplication of the testing process; tests can be quickly run and repeated; most cost-effective for systems with a long maintenance life since minor patches can break previously working features, requiring repeated testing for each patch or upgrade
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 · Source: Test Execution

L7.3 · Test Execution — Box Methods and Test Levels

Walkthrough

Performing and documenting the test activities is the primary focus of the testing methodology. Most execution methods fall into two categories: white-box testing or black-box testing, based on the point of view a test engineer takes when executing test cases.

The three box methods

MethodAlso known asThe tester's view
White-boxclear-box, glass-box, transparent-box, structural testingTests internal structures or workings, not functionality; concerned with how the system operates on an internal level
Black-boxfunctional testingTests functionality, not internal structures; the tester only knows what the system is supposed to do and has no knowledge of internal operations
Gray-boxA combination; the tester has some knowledge of internal structures and also understands expected system functionalities. Most useful when testing existing systems that have been upgraded, patched or modified.

How test methods are classified

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 not associated with a specific level of development are classified by the testing objective: stress, user acceptance and regression testing.

That two-way classification is itself examinable: three level-based types, three objective-based types.

The six test types

Unit testing. 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. A unit is 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 ensure that individual pieces function independently.

Integration testing. 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. It takes as input modules that have been unit tested, groups them into larger aggregates, applies tests defined in an integration test plan, and delivers as output the integrated system ready for system testing. It can be done using any of the box methods 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. Conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. It is one of the most common black-box testing methods and does not require knowledge of the inner design of the code or logic. It combines all integrated components that successfully passed integration testing with software integrated with hardware and tests them as a single system. The purpose is to detect 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. 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. It puts greater emphasis on robustness, availability and error handling under a heavy load rather than on correct operation under normal circumstances. Goals may include ensuring 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. Conducted to determine if the requirements of a specification or contract are met and to validate successful system implementation. It is usually created by business customers — clients or users — hence user acceptance testing (UAT) and is executed prior to 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 may act as the final quality gateway through which previously undetected defects may be uncovered.

Provided certain additional acceptance criteria are met — 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 testing situations.

Regression testing. 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 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 includes repeating previously successful tests and checking to see if program behavior has changed or previously fixed bugs have reemerged after a system change.

Big picture

This is the densest and most heavily tested section of Chapter 7, and the pattern is consistent: each test type is defined by what question it answers.

  • Unit — does this one piece work by itself?
  • Integration — do the pieces work together?
  • System — does the whole thing meet the specified requirements?
  • Stress — where does it break?
  • Acceptance — does it meet the contract, and will the customer sign?
  • Regression — did our change break something that used to work?

Where it fits: acceptance testing is the hinge between Chapter 7 and Chapter 6's contract — it triggers sign-off and final payment. Regression testing links forward to Chapter 6's maintenance and upgrade material.

Key concepts

White-box / black-box / gray-box

In plain English: How much the tester knows about the insides.

Technical meaning: White-box (clear-, glass-, transparent-box, structural) tests internal structures. Black-box (functional) tests functionality with no knowledge of internal operations. Gray-box combines both and is most useful on existing systems that have been upgraded, patched or modified.

Picture it: Structural = white. Functional = black. Upgraded existing system = gray.

Unit testing

In plain English: Does this smallest piece work on its own?

Technical meaning: Checking individual units of source code and one or more program modules with associated control data, usage and operating procedures to determine fitness for use; created by programmers and white-box testers during development; cannot validate overall functionality alone.

Picture it: 'A single component functions as designed' names unit testing.

Integration testing

In plain English: Do the pieces talk to each other correctly?

Technical meaning: Combining unit-tested modules into larger aggregates and testing them as a group to identify interface and interaction issues; output is the integrated system ready for system testing; best suited to gray-box testing.

Picture it: Input is unit-tested modules; output is a system ready for system testing.

System testing

In plain English: Does the assembled whole meet the requirements?

Technical meaning: Conducted on a complete, integrated system to evaluate compliance with specified requirements; one of the most common black-box methods; detects inconsistencies between assemblages, between assemblages and hardware, and in data exchange with external applications and systems.

Picture it: 'Assemblages' is the source's own term for integrated software units.

Stress testing

In plain English: Push it until it breaks and watch what happens.

Technical meaning: Determines the stability of a system by testing beyond normal operational capacity, often to a breaking point; emphasizes robustness, availability and error handling under heavy load; targets insufficient computational resources, unusually high concurrency and denial-of-service conditions.

Picture it: '500 users log on at once' is a concurrency scenario — stress testing.

Acceptance testing (UAT)

In plain English: Does it meet the contract, and will the customer sign?

Technical meaning: Determines whether the requirements of a specification or contract are met and validates successful implementation; created by business customers; executed before accepting transfer of system ownership; acts as the final quality gateway; triggers sponsor sign-off and final vendor payment when additional criteria (security testing, supportability and maintenance standards, usability standards, standards compliance) are met.

Picture it: Follow the money — acceptance testing is the one tied to final payment.

Regression testing

In plain English: Did our change break something that already worked?

Technical meaning: Testing that seeks to uncover new bugs in an existing functional system changed by patches, enhancements or configuration changes; commonly repeats previously successful tests to check whether behavior changed or fixed bugs reemerged.

Picture it: The defining move is repeating tests that previously passed.

Real-world examples

A developer writes a check that one order-validation function rejects a duplicate order. Unit. The build team then verifies that the order module and the pharmacy module exchange the order correctly. Integration. QA then runs the whole assembled system against the requirements document. System.

Before final payment, clinical users run their own scripts against the contract's requirements. That is acceptance testing, and the vendor's cheque depends on it.

Distinctions & exam traps

EXAM TRAP · Unit vs. integration vs. system vs. acceptance

The tempting confusion: All four are levels of testing and all four sound defensible for a generic 'testing' stem.

The deciding clue: Unit = one component alone. Integration = components interacting. System = complete integrated system against specified requirements. Acceptance = against specification or contract, by the customer, before ownership transfer.

Stem wording that triggers it: 'A single component functions as designed' = unit. 'Against contractual terms' = acceptance. (Adjacent term.)

EXAM TRAP · Concurrency scenarios

The tempting confusion: Choosing system or performance testing when the stem describes many simultaneous users.

The deciding clue: Testing beyond normal operational capacity, including unusually high concurrency, is stress testing.

Stem wording that triggers it: '500 users log on at once' names stress testing. (Adjacent term.)

EXAM TRAP · Box method naming

The tempting confusion: Confusing 'structural' with 'functional' testing.

The deciding clue: White-box is also called structural. Black-box is also called functional.

Stem wording that triggers it: Alias items change one alias. (One altered element.)

EXAM TRAP · Regression vs. system testing

The tempting confusion: Both operate on an assembled system.

The deciding clue: Regression is specifically about whether a CHANGE introduced new faults, and works by repeating previously successful tests.

Stem wording that triggers it: 'After a patch or configuration change' names regression. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Give each of the six test types the one question it answers, out loud, without notes.
  2. Explain white-, black- and gray-box testing and say which one fits an upgraded existing system.
  3. Describe what integration testing takes as input and delivers as output.
  4. Explain why acceptance testing is the one tied to final payment, and what additional criteria have to be met first.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Performing and documenting test activities as the primary focus of the methodology; two categories based on the tester's point of view
  • White-box testing (clear-box, glass-box, transparent-box, structural): tests internal structures or workings rather than functionality; concerned with internal operation
  • Black-box testing (functional): tests functionality rather than internal structures; tester knows only what the system is supposed to do
  • Gray-box testing: combination; tester has some knowledge of internal structures and understands expected functionality; most useful on existing systems upgraded, patched or modified
  • Classification by level of test or specific objective; development levels are unit, integration and system testing; objective-based types are stress, user acceptance and regression testing
  • Unit testing: individual units of source code and one or more program modules with associated control data, usage and operating procedures; unit as the smallest testable part; created by programmers and white-box testers during development; cannot validate overall functionality alone; ensures individual pieces function independently
  • Integration testing: combining modules, applications or units and testing as a group to identify interface and interaction issues; input is unit-tested modules; groups into larger aggregates; applies integration test plan tests; output is the integrated system ready for system testing; can use any box method, best suited to gray-box
  • System testing: conducted on a complete integrated system to evaluate compliance with specified requirements; one of the most common black-box methods; no knowledge of inner design or logic required; combines integrated components that passed integration testing with software integrated with hardware; detects inconsistencies between assemblages, between assemblages and hardware, and in data exchange to external applications and systems
  • Stress testing: determines system stability; testing beyond normal operational capacity often to a breaking point; emphasis on robustness, availability and error handling under heavy load; goals include no crash under insufficient computational resources (memory or disk space), unusually high concurrency, or denial-of-service attacks
  • Acceptance testing: determines whether specification or contract requirements are met and validates successful implementation; usually created by business customers (user acceptance testing, UAT); executed prior to accepting transfer of system ownership from developer or vendor; provides confidence the delivered system meets business requirements of sponsors, users and stakeholders; may act as the final quality gateway; additional acceptance criteria include security testing, supportability and maintenance standards, usability standards and standards compliance; sponsors normally sign off and deliver final payment on successful completion; also done internally for major upgrades and patches; terms acceptance, system and integration testing may be synonymous in some organizations
  • Regression testing: any system testing seeking new bugs or errors in an existing functional system changed by patches, enhancements or configuration changes; new issues commonly uncovered through introduction of new systems; intent is to ensure a planned software or hardware change did not introduce new faults or defects into production; common method repeats previously successful tests to check for changed behavior or reemerged bugs
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 · Source: Test Controls; Test Results Reporting; Final Evaluation; Summary

L7.4 · Test Controls, Results Reporting and Final Evaluation

Walkthrough

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.

The three most common types of test controls:

  1. Version controls (also called revision controls)
  2. Security audits
  3. Change controls

Version control (revision control) tracks and provides control over changes to source code. 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, it is common for multiple versions of the same software to be running in different sites and for developers to be working simultaneously on updates. Bugs or features will often be present only in certain versions due to fixing some problems and introducing 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.

That last sentence is the exam answer for what version control protects against: losing the ability to identify which version a defect lives in — in practice, concurrent changes overwriting each other and untraceable defects.

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 requiring 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 without forethought, introducing faults, or undoing changes made by other users.

Typical activities calling for change control:

  • patches to software products
  • system configuration changes
  • installation of new operating systems
  • upgrades to network routing systems
  • 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.

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:

  • tailoring test reports to your audience(s)
  • clarifying confusion about the intent of testing
  • explaining how testing is actually done
  • understanding which testing metrics are meaningful and why

At a minimum, test reports should address:

  1. the mission of the test
  2. system(s) or application(s) covered
  3. organizational risk of deploying the system
  4. testing techniques
  5. test environment
  6. updated testing status
  7. obstacles to testing

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 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. The source's example: if test results show implementation will likely significantly increase the organization's third-party insurance collections, then the cost of conducting the test would be considered a sound investment and the benefits of the test would be clear.

The four common stakeholder questions the final evaluation report should address:

  1. Does the system meet our quality and performance expectations?
  2. Is the system ready for users?
  3. What can we expect when x people simultaneously use the system?
  4. 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
  • the system's potential for expansion or integration with other organizational systems

Summary

A successful way to mitigate risk in deploying new or modified systems is through the development of a thorough testing and evaluation strategy, and including the right people in this strategy, at the right time, is also a critical element of success. Healthcare systems support workflows for a variety of clinical users and clinical specialties and may be deployed across a complex healthcare network, so testing can be complex and time consuming but is nevertheless essential to ensuring consistent performance that supports the delivery of safe and efficient patient care.

Big picture

The controls trio — version control, security audits, change control — is a named, closed list and the obvious source of NOT items. Anything from a different domain (user training, budget approval, vendor selection) is the outlier.

The final evaluation section supplies the exam's benefits-realization vocabulary. Note that the source ties benefit claims to measured outcomes — the insurance-collections example is a measurable business result, not an opinion. When a stem asks how an organization should support a value claim, the answer is measured metrics, not testimonials.

Where it fits: this closes the delivery arc that began with Chapter 4's requirements. Chapter 9 picks up ongoing performance evaluation, benchmarks, KPIs and user satisfaction as management functions.

Key concepts

Test controls

In plain English: Three mechanisms that keep testing honest.

Technical meaning: Version (revision) controls, security audits and change controls — 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.

Picture it: Exactly three. Anything else offered is the outlier.

Version control

In plain English: Knowing exactly which version a bug lives in.

Technical meaning: Tracks and controls changes to source code, and may cover documentation and configuration files; necessary because multiple versions run at different sites and developers work simultaneously on updates, so defects exist only in certain versions.

Picture it: It protects against concurrent changes colliding and against being unable to trace a defect to a version.

Change control

In plain English: Nothing changes without a controlled, coordinated process.

Technical meaning: A formal process ensuring changes are introduced in a controlled and coordinated manner, reducing unnecessary changes made without forethought, faults introduced, or one user's changes undoing another's; also controls the number of changes in an environment at any one time.

Picture it: Named triggers include patches, configuration changes, new operating systems, network routing upgrades and electrical power system changes.

Final evaluation report

In plain English: The one deliverable that says whether you should go live.

Technical meaning: Contains the findings, conclusions and recommendations of the system test; confirms whether expected results were achieved and how they affect anticipated outcomes or benefits; answers whether the system meets quality and performance expectations, whether it is ready for users, what to expect at concurrency, and what the risk is of going live now.

Picture it: 'Is the system ready for users?' is the question everything else feeds.

Post-implementation evaluation

In plain English: Measuring whether the benefits actually showed up.

Technical meaning: Measures 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.

Picture it: Benefit claims are supported by measured metrics — the source's own example is third-party insurance collections.

Real-world examples

Two analysts modify the same order set in different environments. Without version control, one silently overwrites the other and nobody can say which build the resulting defect came from.

A CIO tells the board the new system 'delivered value.' The defensible version cites measured results — collections, satisfaction scores, benchmarks — which is exactly what the source's insurance-collections example models.

Distinctions & exam traps

EXAM TRAP · The three test controls

The tempting confusion: A NOT item mixing version control, security audits and change control with something from training, procurement or staffing.

The deciding clue: The named controls are exactly three.

Stem wording that triggers it: Circle EXCEPT, then find the option from a different taxonomy. (Category outlier.)

EXAM TRAP · What version control protects against

The tempting confusion: Answering unauthorized access, data loss or performance degradation.

The deciding clue: It protects the ability to retrieve and run different versions to determine where a problem occurs, and guards against simultaneous updates colliding.

Stem wording that triggers it: 'Protects primarily against' asks for the named purpose, not a general security benefit. (Wrong layer.)

EXAM TRAP · Validating against contract and design

The tempting confusion: Comparing the system to user expectations, vendor claims or industry norms.

The deciding clue: Validation means comparing the delivered system to the contractual terms and the documented design specifications.

Stem wording that triggers it: The two reference documents are the contract and the design spec — not opinion. (Plausible-but-upstream.)

EXAM TRAP · Supporting a value claim

The tempting confusion: Choosing user testimonials, vendor case studies or go-live success as evidence of delivered value.

The deciding clue: Evaluation ties benefits to measured outcomes — return on investment, benchmarks and user satisfaction measurement.

Stem wording that triggers it: 'Should support the claim with' asks for measured evidence. (Wrong layer.)

EXAM TRAP · What the final evaluation must answer

The tempting confusion: Options about budget performance, schedule adherence or vendor conduct.

The deciding clue: The four named questions concern quality and performance expectations, user readiness, concurrency behavior and go-live risk.

Stem wording that triggers it: 'Must answer whether' points to readiness and risk, not project administration. (Category outlier.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three test controls and say what each one protects.
  2. List the five typical activities that call for change control.
  3. Recite the seven things a test report should address at minimum.
  4. State the four questions a final evaluation report must answer, then say which one the sponsor actually cares about.
  5. Explain how you would support a claim that a new system delivered value, and why 'users love it' is not enough.

Questions

5 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • System controls protect the confidentiality, integrity and availability of data and overall system management across environments during design, development, testing and deployment
  • Three most common test controls: version controls (revision controls), security audits, change controls
  • Version control tracks and controls changes to source code and may maintain documentation and configuration files; multiple versions running at different sites and simultaneous developer updates; bugs or features present only in certain versions; vital to retrieve and run different versions to determine where a problem occurs
  • Security audits are manual or automatic systematic, measurable technical assessments; manual includes staff interviews, security vulnerability scans, review of application and OS access controls, analysis of physical access; automated includes system-generated audit reports and software monitoring and reporting file and setting changes; covered systems include personal computers, servers, network routers and switches
  • Change control is a formal process ensuring changes are introduced in a controlled and coordinated manner; reduces unnecessary changes made without forethought, introduced faults, and undoing of other users' changes; typical triggers are software patches, system configuration changes, new operating system installation, network routing upgrades and electrical power system changes; controls the number of concurrent changes in an environment
  • Test results reporting occurs throughout the process; stakeholders may expect monthly, weekly or daily updates on status, activities and schedules; reporting should be planned early
  • Reporting challenges: tailoring reports to audiences, clarifying confusion about testing intent, explaining how testing is done, understanding which metrics are meaningful and why
  • Minimum test report contents: mission of the test; systems or applications covered; organizational risk of deploying the system; testing techniques; test environment; updated testing status; obstacles to testing
  • Final evaluation report as the most important deliverable, containing findings, conclusions and recommendations; confirms achievement of expected results and addresses effects on anticipated outcomes or benefits; third-party insurance collections example making the test a sound investment
  • Four common stakeholder questions: does the system meet quality and performance expectations; is the system ready for users; what can be expected when x people use it simultaneously; what is the potential risk of going live now
  • Final evaluations may reveal need for specific end-user training prior to go-live; lessons learned improve future test planning, execution and evaluation
  • Post-implementation evaluations measure initial and long-term user satisfaction, system usability, business and patient care impacts and benefits, and potential for expansion or integration with other organizational systems
  • Summary: thorough testing and evaluation strategy mitigates deployment risk; right people at the right time; complexity of clinical workflows and networks makes testing complex and time consuming but essential to consistent performance supporting safe and efficient patient care
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.

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

A successful way to mitigate risk in deploying new or modified systems is through the development of a thorough testing and evaluation strategy. And including the right people in this strategy, at the right time, is also a critical element to the success of this phase and the overall project. Healthcare systems support workflows for a variety of clinical users and clinical specialties and may be deployed across a complex healthcare network, so testing can be complex and time consuming but is, nevertheless, essential to ensuring consistent performance that supports the delivery of safe and efficient patient care.

Chapter 8 · Source: Introduction; Defining Requirements, Policies and Procedures (HIPAA)

L8.1 · Introduction and HIPAA — Requirements, Policies and Procedures

Walkthrough

Concerns about privacy and security are not new to the age of EHRs. In the paper era patients had valid concerns and expected access would be limited and contents would remain confidential. What changed with EHRs is the ease with which records could 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. The underlying principle is to do no harm to the patient.

The CIA triad — the chapter's spine

Title II Administrative Simplification of HIPAA (1996) established criteria and requirements for a covered entity in the US to develop and maintain a program ensuring the confidentiality, integrity and availability of protected health information (PHI).

PropertySource definition
ConfidentialityThe properties of the information that render it unavailable such that it cannot be disclosed to unauthorized persons or processes
IntegrityThe property that data or information has not been altered or destroyed in an unauthorized manner
AvailabilityThe data is accessible and usable on demand by an authorized person

Learn these three verbatim. Every safeguard, control and audit in the chapter exists to protect one of them.

The HIPAA Administrative Simplification Compliance Program

Designed to provide the appropriate policies and procedures to achieve and maintain compliance through internal and external certifications, in accordance with published HIPAA Privacy and Security standards, positioning a provider for unannounced inspections by the Office of Civil Rights (OCR)the government entity enforcing compliance.

Policies define what an organization will do. Procedures define how they will do it. That one-line distinction is directly examinable.

The eight-step methodology to achieve and maintain HIPAA compliance:

  1. Project initiation and organization
  2. Develop and maintain expertise
  3. Provide enterprise awareness and education
  4. Establish a baseline assessment of compliance
  5. Develop a strategy and compliance plan
  6. Remediate gaps in the baseline assessment
  7. Implement the program
  8. Have a plan to maintain compliance, effect change control and complete compliance audits

The HIPAA privacy standards

Rules for:

  • appropriate use and disclosure of patient information
  • the consent and authorization of these uses
  • a Notice of Privacy Practices detailing 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
  • a process to sanction violators of the policies and procedures, plus mitigation so the violation does not happen again

Business associates. 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 are business associates, expected to maintain the confidentiality, integrity and availability of the patient's data in a private and secure manner, as defined in a business associate agreement. The 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

They consist of administrative safeguards, physical safeguards and technical safeguards, along with organizational requirements.

Providers must have a security program including:

  • 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
  • business associates agreements

Required vs. addressable. 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.

Addressable does not mean optional. It means you must document why the standard cannot reasonably be implemented as written and what you did instead. Providers are advised to do an assessment of each standard and document compliance with implementation.

Keeping both programs current, incorporating them into the organizational culture and doing constant surveillance (auditing) is paramount.

Breach notification under HITECH

HITECH established for healthcare a breach notification process similar to the one used in the financial industry.

A breach is the unauthorized acquisition, access, use or disclosure of unsecured PHI that compromises the security or privacy of the PHI.

The four-step breach notification evaluation:

  1. Determine if the incident involved unsecured information.
  2. Determine if there has been an impermissible use or disclosure of PHI under the Privacy Rule.
  3. Determine if the incident falls under one of the exceptions of the breach definition.
  4. Assess the probability that the impermissible use of the PHI would cause harm to the patient.

The breach presumption: 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.

Notification thresholds:

  • Notify the patient without unreasonable delay upon discovery.
  • Fewer than 500 individualsenter the breach in an online database (the source names CMS).
  • 500 or more individualsimmediately notify the local media and the Secretary of HHS.

Big picture

Chapter 8 is built on three named triads and a handful of binary distinctions. Get them cold and most of the chapter's items become mechanical:

  • CIA — confidentiality, integrity, availability.
  • Safeguards — administrative, physical, technical.
  • AAA — authentication, access, accounting (Lesson 8.3).
  • Required vs. addressable; policy vs. procedure; privacy officer vs. security officer.

Where it fits: Chapter 2 established that systems must maintain levels of confidentiality and the minimum necessary standard. Chapter 5 wrote security into the technical specification. Chapter 8 is the governance and control layer over both.

Key concepts

Confidentiality, integrity, availability

In plain English: Don't leak it, don't let it be altered, keep it reachable.

Technical meaning: Confidentiality = properties rendering information undisclosable to unauthorized persons or processes. Integrity = data has not been altered or destroyed in an unauthorized manner. Availability = data is accessible and usable on demand by an authorized person.

Picture it: Every control in the chapter maps to one of these three.

Policy vs. procedure

In plain English: What we do, versus how we do it.

Technical meaning: Policies define what an organization will do. Procedures define how they will do it.

Picture it: A one-line distinction the exam tests directly.

Required vs. addressable

In plain English: Must do, versus must document why you did it differently.

Technical meaning: Required standards are to be implemented. Addressable standards must be documented such that they cannot be reasonably and appropriately implemented, including what can be implemented to meet the intent of the standard.

Picture it: Addressable is never 'skip it'. It is 'justify and substitute, in writing'.

Business associate

In plain English: A contractor who has to touch PHI to do their job.

Technical meaning: Any entity a provider contracts with, who is not a provider, but must use patient information to provide a service; obligations set in a business associate agreement. HITECH elevated business associates to the same level of accountability as a provider for privacy and security breaches.

Picture it: Post-HITECH, the vendor carries the same breach accountability as the hospital.

Breach presumption

In plain English: Assume it is a breach until you can show otherwise.

Technical meaning: All inappropriate uses of PHI are presumed to be a breach unless it can be proven there is a low probability that the PHI has been compromised.

Picture it: The burden sits on the organization, not on the patient.

Real-world examples

A laptop with unencrypted PHI is stolen. Step one of the evaluation asks whether the information was unsecured. Because it was not encrypted, the presumption of breach applies and the organization must disprove compromise, not assume innocence.

An organization cannot implement automatic logoff at a shared clinical workstation without disrupting care. Addressable does not let it stop there — it must document why, and what compensating control it implemented instead.

Distinctions & exam traps

EXAM TRAP · Required vs. addressable

The tempting confusion: Reading 'addressable' as optional or discretionary.

The deciding clue: Addressable means document why it cannot reasonably be implemented and what you implemented to meet the intent.

Stem wording that triggers it: Any option treating addressable as skippable is wrong. (Adjacent term.)

EXAM TRAP · Policy vs. procedure

The tempting confusion: Using the two words interchangeably.

The deciding clue: Policy = what. Procedure = how.

Stem wording that triggers it: A stem describing step-by-step execution names a procedure. (Adjacent document.)

EXAM TRAP · Breach notification thresholds

The tempting confusion: Confusing the under-500 and 500-or-more obligations.

The deciding clue: Under 500 goes into an online database. 500 or more triggers immediate local media notification and notice to the Secretary of HHS.

Stem wording that triggers it: The number in the stem is doing the work. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define confidentiality, integrity and availability in the source's own terms, then give one control that protects each.
  2. Explain the difference between required and addressable to a colleague who thinks addressable means optional.
  3. Walk through the four-step breach notification evaluation and state where the presumption falls.
  4. Explain what HITECH changed for business associates.

Questions

No canonical items map directly here, but the CIA triad, the safeguard categories and the policy/procedure distinction taught here are the foundation for every item in Lessons 8.3 through 8.6.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Privacy concerns predate EHRs; paper-era expectations of limited access and confidentiality; EHRs changed the ease of loss or breach at distance and the potential scale
  • Patients' right to protection regardless of data form; provider duty to safeguard; do no harm principle; complete information supports informed care decisions and empowers patients as care team members
  • International, national and state laws regulating EHR privacy and security; expanding technologies (EHRs, PHRs, HIEs, e-prescribing) increasing the need for strong security
  • Focus on patient-sensitive health information transmitted or maintained in any form or medium; restrictions on use and disclosure; organizations may further restrict access, e.g. genetic markers whose meaning may change as science develops
  • HIPAA Title II Administrative Simplification (1996) established covered-entity criteria for a program ensuring confidentiality, integrity and availability of PHI
  • Confidentiality: properties rendering information undisclosable to unauthorized persons or processes; Integrity: data not altered or destroyed in an unauthorized manner; Availability: data accessible and usable on demand by an authorized person
  • HIPAA Administrative Simplification Compliance Program; internal and external certifications; unannounced OCR inspections; OCR as the enforcing government entity
  • Policies define what an organization will do; procedures define how they will do it
  • Eight-step compliance methodology: 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; implement the program; plan to maintain compliance, effect change control and complete compliance audits
  • Privacy standards: appropriate use and disclosure; consent and authorization; Notice of Privacy Practices; patient rights to access, amend, restrict and receive an accounting of data flow; workforce training; patient complaint process; sanction process for violators plus mitigation
  • Business associates defined; business associate agreement; HITECH (2009) elevated business associates to the same accountability level as providers for breaches
  • Security standards comprise administrative, physical and technical safeguards plus organizational requirements
  • Security program elements: risk management process; workforce security management; PHI access management and controls; awareness and training; security incident process; contingency plans for uninterrupted PHI access; facility access controls; workstation use and security; device and media controls; transmission security; business associates agreements
  • Required standards must be implemented; addressable standards must be documented as not reasonably and appropriately implementable, including what can be implemented to meet the intent; assessment and documentation of each standard advised
  • Programs must be kept current, embedded in culture, and continuously audited
  • HITECH breach notification process modeled on the financial industry; breach defined as unauthorized acquisition, access, use or disclosure of unsecured PHI compromising its security or privacy
  • Four-step breach notification evaluation: unsecured information; impermissible use or disclosure under the Privacy Rule; exceptions to the breach definition; probability of harm to the patient
  • Breach presumption: all inappropriate uses presumed a breach unless low probability of compromise can be proven
  • Notification without unreasonable delay; fewer than 500 individuals entered in an online database; 500 or more requires immediate notice to local media and the Secretary of HHS
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.

Chapter 8 · Source: Defining Requirements, Policies and Procedures (GDPR)

L8.2 · GDPR — Principles, Rights, Roles and Comparison with HIPAA

Walkthrough

The General Data Protection Regulation (GDPR) is a European Union law implemented on May 25, 2018, requiring organizations to safeguard personal data and uphold the privacy rights of anyone in the EU territory.

The seven protection and accountability principles

  1. Lawfulness, fairness and transparency
  2. Purpose limitation
  3. Data minimization
  4. Accuracy
  5. Storage limitation
  6. Integrity and confidentiality
  7. Accountability

Seven, not six or eight. Data minimization is the principle of collecting only the data required for a stated purpose — the most frequently tested single principle.

The eight privacy rights of EU people

  1. The right to be informed
  2. The right of access
  3. The right to rectification
  4. The right to erasure
  5. The right to restrict processing
  6. The right to data portability
  7. The right to object
  8. Rights in relation to automated decision making and profiling

Eight rights. Seven principles. Do not let the two numbers blur.

The key GDPR legal terms

TermDefinition
Personal dataAny information about an individual who can be directly or indirectly identified — can include religious beliefs, web cookies and political opinions
Data subjectThe person whose data is being processed
Data controllerThe person who decides why and how personal data will be processed — can be a business owner or an employee; controllers must be able to demonstrate they are GDPR compliant
Data processorA third party that processes personal data on behalf of the data controller

The data processor cannot legally process personal data unless one of six criteria is met:

  1. The data subject has given consent to the processing for one or more specific purposes
  2. It is necessary to execute or prepare to enter into a contract
  3. To comply with a legal obligation
  4. To save someone's life
  5. To perform a task in the public interest
  6. There is a legitimate interest to process someone's personal data

Compliance measures and penalties

Technical measures named: two-factor authentication and end-to-end encryption. Organizational measures named: staff training, developing a data privacy policy, and limiting access to personal data.

Fines: 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.

GDPR vs. HIPAA

HIPAAGDPR
CoversUS-based healthcare organizations (covered entities) that handle PHIThe personally identifiable information (PII) of an EU citizen
ReachUS covered entitiesA US-based covered entity using or storing the PII of an EU citizen must be GDPR compliant regardless of its location
Breach noticeA longer timeframe of notice, and a process to evaluate if harm has been done to the patientThe citizen must be informed within 72 hours

The 72 hours is the single most examinable number in this comparison.

Big picture

GDPR is the chapter's international counterweight to HIPAA, and the exam uses it for two things: named-list recall (seven principles, eight rights, six lawful bases) and the jurisdictional reach point — GDPR follows the EU citizen's data, not the organization's address.

Where it fits: Chapter 1 established that healthcare regulation is international in framing. Chapter 8 makes that concrete with a second regime that a US organization can fall under without operating in Europe.

Nearby concepts to keep straight: data controller (decides why and how) vs. data processor (processes on the controller's behalf). The controller carries the demonstrate-compliance obligation.

Key concepts

Data minimization

In plain English: Collect only what you actually need.

Technical meaning: The GDPR principle of collecting only the data required for a stated purpose.

Picture it: Sits alongside, but is not the same as, purpose limitation (using data only for the purpose you stated) or storage limitation (not keeping it longer than needed).

Data controller vs. data processor

In plain English: Who decides, versus who does it for them.

Technical meaning: The controller decides why and how personal data will be processed and must be able to demonstrate GDPR compliance. The processor is a third party processing personal data on the controller's behalf, and may only do so if one of six lawful bases is met.

Picture it: Structurally similar to the covered entity / business associate split under HIPAA.

GDPR reach

In plain English: It follows the EU citizen's data, not your address.

Technical meaning: A US-based healthcare covered entity that uses or stores the PII of an EU citizen must be GDPR compliant regardless of the location of the US-based entity.

Picture it: Geography of the organization is irrelevant; citizenship of the data subject governs.

72-hour breach notice

In plain English: Three days, no harm test.

Technical meaning: Under GDPR the citizen must be informed within 72 hours of a breach of their PII. HIPAA allows a longer timeframe and includes a process to evaluate whether harm has been done.

Picture it: GDPR is faster and does not gate on a harm assessment.

Real-world examples

A US academic medical center enrolls an EU citizen in a clinical trial and stores her data on servers in Ohio. GDPR applies. If breached, she must be informed within 72 hours regardless of the HIPAA harm evaluation timeline.

A registry asks for a patient's employer, income and marital status when the stated research purpose needs none of them. That collection fails data minimization before any breach occurs.

Distinctions & exam traps

EXAM TRAP · Seven principles vs. eight rights

The tempting confusion: Mixing a right into a principles list, or vice versa.

The deciding clue: Principles: lawfulness/fairness/transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, accountability. Rights: informed, access, rectification, erasure, restrict processing, data portability, object, automated decision making and profiling.

Stem wording that triggers it: Multi-element list items swap one item across the two sets. (One altered element.)

EXAM TRAP · Minimization vs. purpose limitation vs. storage limitation

The tempting confusion: All three constrain data handling and all three sound plausible.

The deciding clue: Minimization limits WHAT you collect. Purpose limitation limits WHY you use it. Storage limitation limits HOW LONG you keep it.

Stem wording that triggers it: 'Collecting only the data required for a stated purpose' names minimization. (Adjacent term.)

EXAM TRAP · Controller vs. processor obligations

The tempting confusion: Assigning the demonstrate-compliance duty to the processor.

The deciding clue: Controllers decide why and how, and must demonstrate GDPR compliance.

Stem wording that triggers it: 'Decides why and how' names the controller. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Recite the seven GDPR principles and the eight rights as two separate lists, and say which number goes with which.
  2. Explain the controller/processor split and map it onto the HIPAA covered entity / business associate split.
  3. State the GDPR reach rule in one sentence, using a US hospital as your example.
  4. Compare GDPR and HIPAA breach notification without looking.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • GDPR as an EU law implemented May 25, 2018, requiring organizations to safeguard personal data and uphold privacy rights of anyone in EU territory
  • Seven protection and accountability principles: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; accountability
  • Eight privacy rights: to be informed; of access; to rectification; to erasure; to restrict processing; to data portability; to object; rights in relation to automated decision making and profiling
  • Personal data: any information about a directly or indirectly identifiable individual, including religious beliefs, web cookies and political opinions
  • Data subject: the person whose data is being processed
  • Data controller: decides why and how personal data will be processed; may be a business owner or employee; must demonstrate GDPR compliance
  • Data processor: third party processing personal data on behalf of the controller
  • Six lawful bases for processing: data subject consent for one or more specific purposes; necessary to execute or prepare to enter a contract; comply with a legal obligation; save someone's life; perform a task in the public interest; legitimate interest
  • Technical measures such as two-factor authentication and end-to-end encryption; organizational measures such as staff training, developing a data privacy policy and limiting access to personal data
  • Fines: maximum €20 million or 4% of global revenue, whichever is higher; other sanctions include a ban on data processing or public reprimands
  • HIPAA covers US-based covered entities handling PHI; GDPR covers the PII of EU citizens; a US-based covered entity using or storing EU citizen PII must be GDPR compliant regardless of location
  • GDPR breach notice to the citizen within 72 hours; HIPAA has a longer timeframe and a harm evaluation process
  • GDPR.eu co-funded by the Horizon 2020 Framework Programme of the European Union and operated by Proton Technologies AG
Read the original source

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 · Source: Risk Assessment; Risk Management Process; Vulnerability Remediation

L8.3 · Risk Assessment, Risk Management and Vulnerability Remediation

Walkthrough

Risk assessment

Once an organization understands the applicable privacy and security laws, it should undertake an assessment of the organization's readiness with regard to each of those elements, focusing on identifying gaps between what is required and what actually exists within the organization's operations.

The tools named by the source:

  • 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

Note what these six have in common: they are all assessment activities. An option describing a remediation or operational activity — installing controls, training staff, deploying encryption — belongs to a later stage and is the outlier on a NOT item.

The threat / vulnerability / risk vocabulary

The source is precise, and the exam relies on the precision:

  • Risk is the likelihood of a given incident occurring, as well as the adverse impact of such an incident.
  • Threats are potential scenarios that would have a negative impact on security or privacy. A threat is the potential for a thing to go wrong which triggers or exploits a specific vulnerability.
  • Threat sources are persons or events with the ability to actualize a threat. Named examples:
  • humans — malicious hackers, employee saboteurs
  • natural disasters — floods, earthquakes
  • environmental events — power grid failure, nuclear or chemical accident
  • Vulnerabilities are flaws or weaknesses that allow exploits or events to result in a security breach or other violation of an organization's security policiesa flaw or weakness in system components that can result in a breach or violation.

Risk = likelihood × impact. A threat exploits a vulnerability. A vulnerability is the weakness itself.

The risk management process

A risk management process includes:

  1. identifying threats and vulnerabilities
  2. assessing risk
  3. executing steps to reduce the risk to an acceptable level

Risk is factored by setting a numeric value to the probability a threat will exploit a vulnerability and how bad (criticality numeric value) the result will 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 reduce the risk factor, and can include what is to be done to reduce the risk, implementing controls to reduce the risk, and then documenting the residual risk.

Vulnerability remediation

Sources for identifying vulnerabilities, beyond the risk assessment:

  • audit reports
  • reports of atypical system behaviors
  • vendor advisories
  • a system security analysis

During 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 are physical, administrative and technical safeguards.

The two approaches to reduce risk to an acceptable level:

  1. No actionthe current risk level is deemed acceptable by the organization.
  2. Mitigateimplement safeguards to reduce risk to an acceptable level, along with policies and procedures in support of those safeguards.

Only two. The source does not offer transfer or avoidance here. Accepting residual risk is a legitimate, documented decision — it is not negligence, and it is not the same as ignoring the vulnerability.

Big picture

This lesson supplies the vocabulary that Section III leans on hardest: threat, threat source, vulnerability, risk, residual risk. Confusing any two of them is the single most reliable way to lose a security item.

Where it fits: Chapter 5's medical device cybersecurity discussion identified the vulnerability class; this chapter gives you the process for handling it. Chapter 9 revisits risk identification, quantification, response and monitoring as project management functions — same words, project context.

Nearby concepts to keep straight: risk assessment identifies gaps; risk management decides what to do; remediation does it. A stem describing one and offering the others is testing stage placement.

Key concepts

Threat vs. vulnerability vs. risk

In plain English: The bad thing, the hole it gets through, and how likely and bad it would be.

Technical meaning: A threat is the potential for a thing to go wrong which triggers or exploits a specific vulnerability. A vulnerability is a flaw or weakness in system components that can result in a breach or violation. Risk is the likelihood of an incident occurring plus its adverse impact.

Picture it: Unpatched OS = vulnerability. Ransomware crew = threat source. Probability × criticality = risk.

Threat source

In plain English: Who or what can actually make the threat happen.

Technical meaning: Persons or events with the ability to actualize a threat — humans (malicious hackers, employee saboteurs), natural disasters (floods, earthquakes) and environmental events (power grid failure, nuclear or chemical accident).

Picture it: Three named categories: human, natural, environmental.

Risk factoring

In plain English: Score how likely it is and how bad it would be.

Technical meaning: Setting a numeric value to the probability a threat will exploit a vulnerability and a criticality numeric value for the result, commonly on a HIGH/MEDIUM/LOW scale, to derive a risk factor.

Picture it: Two inputs, one output.

The two risk responses

In plain English: Accept it, or reduce it.

Technical meaning: No action (the current risk level is deemed acceptable by the organization) or mitigate (implement safeguards to reduce risk to an acceptable level, with supporting policies and procedures).

Picture it: Documented acceptance of residual risk is a real, legitimate answer.

Residual risk

In plain English: What is left after you have done what you are going to do.

Technical meaning: Documented in the mitigation process after determining what is to be done and implementing controls.

Picture it: The starting risk, the mitigation, the controls, and the residual risk — the source's own four-part documentation chain.

Real-world examples

A penetration test finds an exposed legacy interface. The vulnerability is the interface; the threat is an external actor exploiting it; the risk is high probability × high criticality. The organization patches it and documents the residual risk. That chain is the source's whole process.

A minor vulnerability on an isolated internal system scores LOW/LOW. The organization documents 'no action — current risk level acceptable.' Under the source's own framework that is a correct response, not a failure.

Distinctions & exam traps

EXAM TRAP · What belongs in a risk assessment

The tempting confusion: A NOT item mixing genuine assessment activities with a remediation or operational activity.

The deciding clue: The six named tools are document review, surveys/questionnaires, facility walk-throughs, penetration/intrusion testing, updated legislation review, and root cause analysis of breaches since the last assessment.

Stem wording that triggers it: Circle EXCEPT, then find the option that acts on the risk rather than measuring it. (Category outlier.)

EXAM TRAP · Accepting residual risk

The tempting confusion: Treating a decision to take no action as negligence, avoidance, or a transfer of risk.

The deciding clue: 'No action — the current risk level is deemed acceptable' is one of the two named responses.

Stem wording that triggers it: A scenario where residual risk is judged acceptable names risk acceptance. (Adjacent term.)

EXAM TRAP · Threat vs. vulnerability

The tempting confusion: Using the two words interchangeably.

The deciding clue: The threat exploits; the vulnerability is what gets exploited.

Stem wording that triggers it: 'Flaw or weakness in system components' names the vulnerability. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define threat, threat source, vulnerability and risk in your own words, then apply all four to one real system at your organization.
  2. Name the six risk assessment tools and say what they all have in common.
  3. Explain why 'no action' is a legitimate risk response and what has to be true for it to be defensible.
  4. Walk the four-part documentation chain: starting risk, mitigation, controls, residual risk.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Assessment of organizational readiness against each applicable requirement; focus on gaps between what is required and what exists
  • Assessment tools: review of current policies, procedures, contracts and relevant documents; organizational surveys or questionnaires measuring knowledge of and compliance with requirements; facility walk-throughs for physical security limitations; technical penetration or intrusion attempts and other vulnerability tests; updated legislation, regulations or international agreements driving new approaches; root cause analysis of any security breach since the last assessment
  • Risk as the likelihood of an incident occurring plus the adverse impact of such an incident
  • Threats as potential scenarios with negative security or privacy impact; threat sources as persons or events able to actualize a threat — humans (malicious hackers, employee saboteurs), natural disasters (floods, earthquakes), environmental events (power grid failure, nuclear or chemical accident)
  • Vulnerabilities as flaws or weaknesses allowing exploits or events to result in a breach or violation of security policies; a flaw or weakness in system components
  • Risk management process: identifying threats and vulnerabilities; assessing risk; executing steps to reduce risk to an acceptable level
  • Risk factored by numeric probability that a threat will exploit a vulnerability and a criticality numeric value; commonly HIGH, MEDIUM and LOW
  • Risk-mitigation process: what is to be done to reduce risk; implement controls; document residual risk
  • Vulnerability identification sources: risk assessment analysis, audit reports, reports of atypical system behaviors, vendor advisories, system security analysis
  • Remediation activities: review of existing policies and procedures; development of new policies and procedures; education and training; controls to safeguard critical systems and data — physical, administrative and technical safeguards
  • Two approaches to reduce risk to an acceptable level: no action (current risk level deemed acceptable) and mitigate (implement safeguards plus supporting policies and procedures)
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 · Source: User Access Controls; Confidentiality, Integrity and Availability

L8.4 · User Access Controls and the CIA Triad in Practice

Walkthrough

To maintain data confidentiality, integrity and availability, an organization must control access to systems and data. User access controls prevent access by unauthorized users.

The AAA (triple-A) approach

User access controls break into three categories, sometimes termed the AAA or the triple-A approach:

  1. Authentication
  2. Access
  3. Accounting

Authentication

The process of attempting to prove that users are who they say they are before allowing them to access a system.

Three primary methods — the classic factor categories:

  1. Something a user knows — e.g. personal identification number (PIN) or password
  2. Something a user has — e.g. smart card or token
  3. Something a user is — e.g. fingerprint, palm print or retina scan

Two-factor / multi-factor authentication — called strong authentication — became necessary because advancement of technology and the ease of writing a password-cracking program made passwords alone insufficient. The 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 that the user entering the credentials is the one authorized to use the system.

The exam point: two-factor means factors from two DIFFERENT categories — knows, has, is. Two passwords are not two factors.

Access

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. The source's 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.

Unique user-id and passwords:

  • All authorized users of PHI are to access information systems with a unique user-id.
  • The 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.
  • The source's analogy: the user-id is the key that goes into a door lock; the password allows the key to be turned to open the door.

Strong password characteristics named:

  • upper and lower case characters
  • numerical characters
  • special characters
  • minimum length
  • cannot match the user-id
  • changed periodically
  • not reused

Password handling rules: user-ids and passwords should not be written down, stored online, or sent to someone in an unsecured e-mail or text; 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 are followed and not circumvented.

Accounting

Accounting is the final piece of the user access puzzle. Audit reports and other controls 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 — the source's examples: 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.

Confidentiality, integrity and availability in practice

Confidentiality is a primary focus of healthcare IT securitythe 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.

Integrity refers to the accuracy and completeness of data. To preserve it, an organization must:

  • implement policies and procedures to protect the data from unauthorized modification, deletion or destruction
  • keep it consistent with its source
  • 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. It also makes certain health information is available to patients when they need it. Care must be taken to ensure records will be available and survive the organization in the event of closure, merger or similar events — which could also apply to other countries and their internal and external ties through treaties and the like.

Big picture

AAA is the operational core of Chapter 8, and the three parts map cleanly onto three different exam answers: authentication answers "who are you", access answers "what may you see", accounting answers "what did you actually do".

The most common item here gives a scenario about users seeing only what their role requires — that is access, specifically role-based access, not authentication and not auditing.

Where it fits: Chapter 1's privacy officer accountability, Chapter 2's levels-of-confidentiality design requirement, and Chapter 7's security audits all converge here.

Key concepts

AAA (triple-A)

In plain English: Who are you, what may you see, what did you do.

Technical meaning: Authentication, access, accounting — the three categories of user access control.

Picture it: Three words, three different exam answers. Do not let a stem about one pull you to another.

The three authentication factor categories

In plain English: Something you know, have, or are.

Technical meaning: Something a user knows (PIN, password); something a user has (smart card, token); something a user is (fingerprint, palm print, retina scan).

Picture it: Two-factor authentication draws from two DIFFERENT categories. A password plus a security question is still one category.

Role-based access

In plain English: Your job title determines what you can open.

Technical meaning: Access privileges set to the minimum necessary to perform a job, often defined by a user's role — physicians ordering and signing, nurses, midlevel providers and medical students holding subsets, pharmacists holding a different set.

Picture it: The answer to 'users see only the data their role requires' is role-based access control.

Unique user-id

In plain English: One ID, one person, so the log means something.

Technical meaning: All authorized users of PHI access systems with a unique user-id belonging to one person, allowing the system to track what data was accessed, modified or deleted.

Picture it: Shared logins destroy accounting. That is why uniqueness is non-negotiable.

Accounting / audit reports

In plain English: Checking what people actually looked at.

Technical meaning: Audit reports and other controls provide assurance that users are not accessing information not required for care delivery — coworkers, neighbors or celebrities — and should be generated on both a scheduled and a random basis.

Picture it: Scheduled AND random. One without the other is incomplete.

Real-world examples

A nurse logs in with a password and a code texted to her phone. Something she knows plus something she has — two categories, therefore genuine two-factor authentication.

A random audit shows an employee opened the chart of a neighbor with no care relationship. Authentication succeeded, access control permitted it, and accounting caught it. All three A's did exactly their jobs.

Distinctions & exam traps

EXAM TRAP · Two-factor means two categories

The tempting confusion: Counting a password plus a security question, or two passwords, as two factors.

The deciding clue: The factors are something you know, something you have, something you are — two-factor draws from two different ones.

Stem wording that triggers it: 'Combines factors drawn from which categories' is testing category diversity. (Adjacent term.)

EXAM TRAP · Authentication vs. access vs. accounting

The tempting confusion: Answering 'authentication' or 'auditing' for a question about users seeing only what their role requires.

The deciding clue: Restricting what a user may see is access control — specifically role-based access.

Stem wording that triggers it: 'Best enforces that users see only the data their role requires' names role-based access. (Wrong layer.)

EXAM TRAP · Integrity vs. confidentiality vs. availability

The tempting confusion: Assigning an accuracy problem to confidentiality, or an outage to integrity.

The deciding clue: Confidentiality = limiting disclosure. Integrity = accuracy and completeness, protection from unauthorized modification, deletion or destruction. Availability = protection from unplanned destruction and accessibility when needed.

Stem wording that triggers it: Match the property to the harm described. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the three A's and give each one the question it answers.
  2. State the three authentication factor categories and explain why two passwords are not two-factor.
  3. Explain role-based access using the physician / nurse / medical student / pharmacist example.
  4. Say why audit reports must be both scheduled and random.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • User access controls prevent access by unauthorized users and maintain confidentiality, integrity and availability
  • AAA / triple-A categories: authentication, access, accounting
  • Authentication as proving users are who they say they are before granting system access
  • Three primary authentication methods: something a user knows (PIN, password); something a user has (smart card, token); something a user is (fingerprint, palm print, retina scan)
  • Two-factor/multi-factor authentication as strong authentication, driven by password-cracking programs; additional evidence may be a randomly generated code to a mobile device, a PIN, a smartcard, a digital certificate or a biometric; goal is to validate the credential-entering user is the authorized one
  • Access privileges set to the minimum access necessary to perform a job; role-based access defined by organizational role; physician ordering and signing rights vs. nurse; midlevel provider and medical student subsets; pharmacist's distinct privileges
  • Unique user-id for all authorized PHI users, belonging to one person, enabling tracking of data accessed, modified or deleted; user-id as key and password as the turning of the key
  • Strong password characteristics: upper and lower case characters, numerical characters, special characters, minimum length, cannot match the user-id, changed periodically, not reused
  • Password handling: not written down, stored online, or sent in unsecured e-mail or text; password not sent in the same correspondence as the user-id; not stored in clear text on servers or devices; electronic security criteria enforce and prevent circumvention
  • Accounting: audit reports and other controls providing assurance users are not accessing information not required for care delivery (coworkers, neighbors, celebrities); reports generated on both a scheduled and a random basis
  • Confidentiality as limiting disclosure of personal information to comply with policies and regulations and maintain patient trust
  • Integrity as accuracy and completeness; policies and procedures protecting from unauthorized modification, deletion or destruction; consistency with source; auditing mechanisms confirming data has not been altered, deleted or destroyed without authorization
  • Availability as protection from unplanned destruction by accident, vandalism or natural disasters; availability to patients when needed; record survival in the event of closure, merger or similar events, including across countries and treaties
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.

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.

Chapter 8 · Source: Organizational Roles; Data Management Controls

L8.5 · Organizational Roles, Data Management Controls and the Three Safeguards

Walkthrough

Organizational roles

An expert who understands which privacy laws apply to an organization and how they should be properly interpreted plays a crucial role. Laws in many jurisdictions require that each organization appoint an individual, sometimes with the title of chief information security officer.

The eight named tasks:

  1. Assessing and maintaining knowledge of rules and regulations
  2. Developing policies and procedures
  3. Cultivating organizational and cultural awareness and developing educational plans in support of policies
  4. Managing appropriate access for external business partners and ensuring documentation exists in support of such access
  5. Monitoring compliance with policies
  6. Responding to complaints and other issues that arise
  7. Conducting or directing others to conduct scheduled and random access audits
  8. Investigating known security breaches and reporting information to appropriate regulatory or governmental agencies as required by law

Privacy officer and security officer. The privacy standards require the provider to identify a position responsible for the privacy program. The security standards have the same requirement, and that person ensures 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. They are responsible for the development, maintenance and adherence to all policies and procedures needed for the provider to be HIPAA compliant.

Security incident management. 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 with policy and procedure. The officers oversee these processes and take steps to mitigate so the incidents will not be repeated.

The source is explicit elsewhere that health information privacy and security is everyone's responsibility — vulnerability management is not the sole property of one department.

The three safeguard categories

To ensure the security of protected data, a number of safeguards may be deployed, seeking to meet 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
  • 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.

CategoryDefinitionNamed examples
AdministrativeAdministrative actions, policies and procedures that an organization deploys in support of its security aimsOngoing education of employees on security requirements and use/disclosure scenarios; developing policies and procedures that provide safeguards within the physical and technical realms
TechnicalElectronic means of ensuring that data is not accessible, or that it is encrypted in a way that makes it useless to a third partyNetwork firewalls; secure protocols on any public networks carrying patient data; encryption of storage media on laptop computers and mobile devices
PhysicalPhysical measures, policies and procedures that protect electronic information systems from natural and environmental hazards, as well as unauthorized intrusionData centers located outside a floodplain with redundant sources of power; limited access to server rooms or areas where data may be accessed or damaged

One of the major threats security professionals face today is cybersecuritythe 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.

Data classification

A data classification policy can be designed to support the minimum amount of data needed by a user to do their job, ensuring information will be protected from unauthorized disclosure, use, modification and deletion. It applies to data created, received, stored and/or maintained by the provider, which 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.

The four common data classifications:

  1. Public
  2. For Internal Use Only
  3. Confidential
  4. 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.

Retention and destruction

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 define the data and 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.

Big picture

The three safeguard categories are the most reliably tested taxonomy in Chapter 8, and the sorting rule is simple: administrative = people and paper; technical = electronic; physical = walls, doors and weather.

The other high-yield idea here is distribution of responsibility. When a stem asks who manages vulnerabilities, the source's answer is not one office — it is information security, physical security and compliance working together, with the source's closing insistence that it is everyone's responsibility.

Where it fits: Chapter 1 established the privacy officer / security officer split; Chapter 8 gives both the full task list and confirms they may be one person or two.

Key concepts

Administrative safeguards

In plain English: People, policies and training.

Technical meaning: Administrative actions, policies and procedures deployed in support of security aims — including ongoing employee education on security requirements and use/disclosure scenarios, and developing policies and procedures that provide safeguards within the physical and technical realms.

Picture it: If it is written down or taught, it is administrative.

Technical safeguards

In plain English: Electronic controls.

Technical meaning: Electronic means of ensuring data is not accessible, or is encrypted so as to be useless to a third party — network firewalls, secure protocols on public networks carrying patient data, encryption of storage media on laptops and mobile devices.

Picture it: If software or a network device enforces it, it is technical.

Physical safeguards

In plain English: Doors, locks, floodplains and power.

Technical meaning: Physical measures, policies and procedures protecting electronic information systems from natural and environmental hazards and unauthorized intrusion — data centers outside a floodplain with redundant power, limited access to server rooms or areas where data may be accessed or damaged.

Picture it: A locked, access-controlled server room is the textbook physical safeguard.

Data classification

In plain English: Label data by sensitivity so handling follows automatically.

Technical meaning: Four common classifications — Public, For Internal Use Only, Confidential, Restricted Confidential — with a matrix documenting examples, criteria, handling, copying, storage and destruction standards, and workforce classification and access availability.

Picture it: Protection is commensurate with sensitivity regardless of location, form, technology or purpose.

Data owners and destruction schedules

In plain English: The people who generate the data decide when it goes.

Technical meaning: Data owners — those who generate and maintain the data — can define the content of destruction schedules, which set the data and destruction timeframes based on workflow process needs, regulatory reporting, and state or federal regulations, reviewed routinely for regulatory change.

Picture it: Ownership carries the retention decision, not IT.

Real-world examples

Servers in a locked, badge-controlled room in a building outside the floodplain, with redundant power: physical safeguard, twice over.

Annual security training plus a written sanction policy: administrative. Full-disk encryption on those same laptops: technical. All three categories can protect one asset simultaneously.

Distinctions & exam traps

EXAM TRAP · Sorting the three safeguards

The tempting confusion: Calling encryption physical because it protects a laptop, or calling training technical because it is about systems.

The deciding clue: Administrative = actions, policies, procedures, education. Technical = electronic means. Physical = physical measures against hazards and intrusion.

Stem wording that triggers it: 'Securing servers inside a locked, access-controlled room' is physical. (Adjacent term.)

EXAM TRAP · What administrative safeguards do NOT include

The tempting confusion: A NOT item mixing genuine administrative safeguards with a firewall, encryption or a locked door.

The deciding clue: If the control is enforced electronically or by a physical barrier, it is not administrative.

Stem wording that triggers it: Circle EXCEPT, then sort each option into its category. (Category outlier.)

EXAM TRAP · Who owns vulnerability management

The tempting confusion: Assigning it exclusively to IT, or to the security officer alone.

The deciding clue: Responsibility is best distributed across information security, physical security and compliance — and the source ends by stating it is everyone's responsibility.

Stem wording that triggers it: 'Best distributed among' asks for the multi-role answer, not a single owner. (Wrong layer.)

EXAM TRAP · Data management control scope

The tempting confusion: Limiting data management controls to access controls alone.

The deciding clue: They address ownership, criticality, security levels, protection controls, retention and destruction requirements, and access controls.

Stem wording that triggers it: The learning objective itself names the full set. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Sort ten controls from your own organization into administrative, technical and physical without hesitating.
  2. Name the four data classifications and say what a classification matrix documents.
  3. Explain who defines destruction schedules and why it is not IT.
  4. Give the privacy officer / security officer relationship: what each is responsible for, and whether they must be different people.

Questions

4 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Requirement in many jurisdictions to appoint an individual, sometimes titled chief information security officer, expert in applicable privacy laws and their interpretation
  • Eight named tasks: assessing and maintaining knowledge of rules and regulations; developing policies and procedures; cultivating organizational and cultural awareness and developing educational plans; managing appropriate access for external business partners with supporting documentation; monitoring compliance with policies; responding to complaints and other issues; conducting or directing scheduled and random access audits; investigating known security breaches and reporting to regulatory or governmental agencies as required by law
  • Privacy standards require a position responsible for the privacy program; security standards require the same for security; commonly the privacy officer and security officer; may be two people or the same person; responsible for development, maintenance and adherence to all policies and procedures needed for HIPAA compliance
  • Security incident management process overseen by the privacy and/or security officer; all incidents, threats or violations affecting or potentially affecting confidentiality, integrity or availability to be reported and responded to per policy and procedure; mitigation to prevent repetition
  • Safeguard goals: controlling electronic access to systems with sensitive data; controlling physical access to locations or devices with ready access to secure data; managing data in transit including e-mail and file transfer; encryption of data on laptops, flash memory drives and other easily lost or stolen devices
  • Three safeguard groupings: administrative, technical, physical
  • Administrative safeguards: administrative actions, policies and procedures supporting security aims; ongoing employee education on security requirements and use/disclosure scenarios; developing policies and procedures providing physical and technical safeguards
  • Technical safeguards: electronic means of making data inaccessible or encrypted so as to be useless to a third party; network firewalls; secure protocols on public networks carrying patient data; encryption of storage media on laptops and mobile devices
  • Physical safeguards: physical measures, policies and procedures protecting systems from natural and environmental hazards and unauthorized intrusion; data centers outside a floodplain with redundant power; limited access to server rooms or areas where data may be accessed or damaged
  • Cybersecurity as a major threat — unauthorized access and malicious attack of healthcare systems and PHI; ransomware holding PHI hostage for payment
  • Data classification policy supporting the minimum amount of data needed to do a job; protection from unauthorized disclosure, use, modification and deletion; applies to data created, received, stored and maintained; consistent protection throughout the life cycle from origination to destruction; protection commensurate with sensitivity regardless of residence, form, technology or purpose
  • Four common data classifications: Public; For Internal Use Only; Confidential; Restricted Confidential
  • Data classification matrix documenting examples, criteria, handling standards, copying standards, storage standards, destruction standards, and workforce classification and access availability
  • Enormous data volume; data management ensures the most useful data is quickly available; data retention and destruction policy and procedure for systematic destruction of non-useful or end-of-life data
  • Destruction schedules define the data and destruction timeframes based on workflow process needs, regulatory reporting, state regulations or federal regulations; data owners (those who generate and maintain the data) can define schedule content; routine review to stay abreast of regulatory changes
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.

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 · Source: Disaster Recovery and Business Continuity Plans; Auditing; Ongoing System Evaluation; Summary

L8.6 · Contingency Planning, Auditing and Ongoing System Evaluation

Walkthrough

Contingency plans — the five components

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 five components:

  1. Analysis of applications and data criticalityapplications and data should be prioritized in order of importance to the organization so a logical sequence of data recovery can be planned
  2. Data backup plandetailed plans must be developed to ensure the existence of a retrievable backup copy of the organization's critical data
  3. Disaster recovery planprocedures must be documented that define how to restore data after any loss, for any reason
  4. Emergency-mode operation plandowntime 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
  5. Testing and revisionall contingency plans must be routinely tested and revised to fill gaps that are discovered and to address changing organizational needs and infrastructure

Two of these are habitually confused. The disaster recovery plan documents how to restore data after any loss, for any reason. The emergency-mode operation plan is the downtime plan — how you keep operating while the data is unreachable. Different documents, different jobs.

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 provider's IT environment. These audits can be done internally or externally by a third party.

Industry standard: an objective third party conducts 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.

The same testing can include:

  • an internal network vulnerability assessment
  • a wireless network assessment
  • medical devices assessment
  • social engineering
  • 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.

Named obligations:

  • 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.
  • 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.

That last clause is the answer to why ongoing validation is required: the environment changes — new applications and interfaces appear, the organization changes, and laws and attitudes evolve. A system that was secure at go-live is not automatically secure two years later.

Summary

Ensuring privacy and security, while also guaranteeing confidentiality, integrity and availability of health information, is an ongoing and critical process. The source's closing checklist:

  • compliance programs must be in place
  • audits should be conducted regularly
  • data management controls and safeguards — administrative, technical and physical — should be in place
  • risk assessments that identify vulnerabilities should be occurring regularly, with mitigation plans enacted
  • disaster recovery and business continuity plans should be documented
  • contingency planning should be a continuous focus

It is not something that should be periodically "checked-in" on. And although there are organizational roles primarily responsible for this, health information privacy and security is everyone's responsibility.

Big picture

This closing lesson converts the chapter's principles into recurring operations. The exam's angle is almost always the same: security is a state you maintain, not a milestone you pass.

Where it fits: Chapter 5 designed the continuity capability; Chapter 7 tested the system; Chapter 8 requires that both be revalidated continuously as the environment changes.

Nearby concepts to keep straight: the disaster recovery plan (restore data after loss) vs. the emergency-mode operation plan (keep operating during downtime) vs. the data backup plan (ensure a retrievable copy exists). Three of the five contingency components, three different answers.

Key concepts

The five contingency plan components

In plain English: Prioritize, back up, restore, operate in the dark, and test.

Technical meaning: Analysis of applications and data criticality; data backup plan; disaster recovery plan; emergency-mode operation plan; testing and revision.

Picture it: Testing and revision is a named component, not an afterthought.

Disaster recovery plan

In plain English: How to get the data back.

Technical meaning: Documented procedures defining how to restore data after any loss, for any reason.

Picture it: 'After any loss, for any reason' is the source's own phrasing and the stem's likely tell.

Emergency-mode operation plan

In plain English: How to keep running while the systems are down.

Technical meaning: Downtime plans enabling the organization to continue operating in emergency mode while access to electronic data is not possible.

Picture it: Paper downtime forms and manual workflows live here, not in the DR plan.

External penetration testing

In plain English: Paying an outsider to try to break in, once a year.

Technical meaning: Industry standard is an objective third party conducting annual external network penetration testing from outside the provider's network to identify perimeter vulnerabilities allowing unauthorized access to core network infrastructure; may also include internal vulnerability assessment, wireless assessment, medical devices assessment, social engineering and firewall rules review.

Picture it: Findings feed the risk assessment: starting risk, mitigation, controls, residual risk.

Why ongoing validation

In plain English: The environment keeps changing underneath you.

Technical meaning: New applications, interfaces and data access points may introduce new vulnerabilities; existing applications must be reevaluated in the face of organizational changes and evolving local, national and international attitudes, laws and regulations.

Picture it: Security is not a state you achieve once.

Real-world examples

The EHR is unreachable for six hours. The emergency-mode operation plan governs how the units keep documenting; the disaster recovery plan governs how the data gets restored afterward. Confusing the two on the day is a patient safety problem.

A third-party pen test finds an exposed wireless segment. The finding does not stand alone — it is fed into the risk assessment and documented as starting risk, mitigation, controls and residual risk.

Distinctions & exam traps

EXAM TRAP · DR plan vs. emergency-mode operation plan vs. backup plan

The tempting confusion: All three are contingency components dealing with disruption.

The deciding clue: DR restores data after loss. Emergency-mode keeps operations running during downtime. The backup plan ensures a retrievable copy exists.

Stem wording that triggers it: 'Procedures for restoring data after any loss, for any reason' names the disaster recovery plan. (Adjacent document.)

EXAM TRAP · Why security features need ongoing validation

The tempting confusion: Answering that it is required by auditors, by the vendor, or to satisfy the board.

The deciding clue: New applications and interfaces may introduce vulnerabilities, and organizational change plus evolving laws, regulations and attitudes change the requirements.

Stem wording that triggers it: 'Must be validated on an ongoing basis because' asks for environmental change. (Plausible-but-upstream.)

EXAM TRAP · Testing is a named component

The tempting confusion: Treating testing and revision as good practice rather than a required part of contingency planning.

The deciding clue: It is the fifth named component: all contingency plans must be routinely tested and revised.

Stem wording that triggers it: A five-element list item missing testing is the altered one. (One altered element.)

CURRENT PRACTICE / SUPPLEMENTAL

Review Guide framing: HIPAA safeguards, GDPR, annual third-party penetration testing and continuous evaluation.

Current practice (2026): The dominant control framework in US healthcare security programs is NIST Cybersecurity Framework 2.0, whose functions are Govern, Identify, Protect, Detect, Respond, Recover — Govern having been added in the 2.0 revision. Health-sector specifics are commonly mapped through HICP (Health Industry Cybersecurity Practices) and, for safety-focused EHR configuration review, the ONC SAFER Guides. 42 CFR Part 2 governs substance use disorder treatment records with stricter consent rules than HIPAA and is a frequent real-world complication that the 4th edition does not cover.

Does it matter for the exam? These names do not appear in the Review Guide chapters. Answer HIPAA-framed and GDPR-framed stems inside those frames. If a newer framework name appears in a distractor, it is not automatically the answer.

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the five contingency plan components and distinguish the DR plan from the emergency-mode operation plan.
  2. Explain what an annual external penetration test is for and what else it can cover.
  3. Say why security features need ongoing validation, in terms of what changes rather than who requires it.
  4. Recite the chapter's closing checklist of what must be in place.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Everyone responsible for protecting privacy and ensuring data security; IT security professionals must be involved in developing disaster recovery and business continuity plans
  • Five contingency plan components: analysis of applications and data criticality (prioritization for a logical recovery sequence); data backup plan (retrievable backup copy of critical data); disaster recovery plan (documented procedures to restore data after any loss for any reason); emergency-mode operation plan (downtime plans to continue operating while electronic data is inaccessible); testing and revision (routine testing and revision to fill discovered gaps and address changing needs and infrastructure)
  • Ability to audit all access to protected data as an essential security plan component; individuals may access records not needed for daily duties despite good policies; audit reports identify breaches and policy violations from employee snooping to large criminal attack
  • Validation of consistent HIPAA security compliance through a structured security audit program and risk-assessment process for changes to security features of all systems; audits internal or external by a third party
  • Industry standard of annual external network penetration testing by an objective third party from outside the network to identify perimeter vulnerabilities permitting unauthorized access to core infrastructure and rendering the network inoperable
  • Same testing may include internal network vulnerability assessment, wireless network assessment, medical devices assessment, social engineering and firewall rules review
  • Third-party findings incorporated into the risk-assessment process documenting starting risk, mitigation, controls and residual risk to show security features are maintained at the highest level of integrity
  • Continuous evaluation of security features of existing and new hardware and software; maintained network diagrams with location and configuration of firewalls, servers and routers; up-to-date software, hardware and vendor contact documentation
  • Evaluation of technical and user interfaces and other data access points as new applications are introduced; assessment of whether an application or interface might introduce new security vulnerabilities
  • Ongoing reevaluation of existing applications in the face of organizational changes and evolving local, national and international attitudes, laws and regulations
  • Summary: ongoing critical process; EHRs shifted the landscape of maintaining and protecting records; growth of policies, procedures, laws, regulations, personnel and workforce; consistent rather than periodic focus; compliance programs, regular audits, data management controls and administrative/technical/physical safeguards, regular risk assessments with mitigation plans, documented DR and business continuity plans, continuous contingency planning; privacy and security is everyone's responsibility
Read the original source

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

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

Ensuring the privacy and security, while also guaranteeing the confidentiality, integrity and availability of health information, is an ongoing and critical process. The introduction of EHRs has also shifted the landscape of what maintaining and protecting a patient's record looks like. New policies and procedures, new laws and regulations and new personnel and workforce focused on these important tasks have grown significantly over recent years. It is important that organizations focus on privacy and security on a consistent basis. It is not something that should be periodically “checked-in” on. Compliance programs must be in place, audits should be conducted regularly, data management controls and safeguards, administrative, technical and physical, should be in place, risk assessments that identify vulnerabilities should be occurring regularly, with mitigation plans enacted, disaster recovery and business continuity plans should be documented and contingency planning should be a continuous focus. And, although there are organization roles that are primarily responsible for this, health information privacy and security is everyone's responsibility.

Chapter 9 · Source: Introduction; Participation in Organizational Strategic Planning; Organizational Environment; Forecasting Technical and Informational Needs; Developing and Implementing the IT Strategic Plan

L9.1 · Strategic Planning, the Organizational Environment and the IT Strategic Plan

Walkthrough

Management and leadership skills are critical for the success of healthcare IT organizations. Leaders interact with other management and employees at all levels, requiring expertise in planning, communicating, reporting, forecasting and understanding all intricacies of healthcare regulation and policy. Leaders in healthcare IT are expected to have ethical working relationships with both internal and external stakeholders.

The four components of a strategic plan

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. Organizations publish statements expressing the mission, vision, values and goals.

ComponentDefinitionWho sets it
MissionA statement of why the organization exists — its purposeCEO and board of directors
VisionDefines where it wants to go or what it wants to bewhat the company is striving to achieve as it completes the daily work, a futuristic perspectiveCEO and board
ValuesAllows individuals to understand what the company supports and appreciates most — e.g. compassion, service and respectAdministration/board
GoalsThe measures to support vision accomplishmentLeadership
  • The mission does not change with any regularity unless the business of the company or direction of the industry is changing as well. Each employee has a responsibility to understand the mission so they can tie their daily work to it.
  • Depending on how far the vision reaches into the future, it may be altered with more regularity than the mission.
  • Values are often presented in a list that individuals can compare against their own personal values. If an initiative lacks alignment or conflicts with at least one value, it should be called into question. Values also reflect the corporate culturean 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.
  • The list of goals must be SMART: specific, measurable, attainable, relevant and time bound. Examples: breaking even on Medicare reimbursement, leading in clinical quality and employing primary care providers of choice for the community.

Note the wording difference: Chapter 9 gives SMART as relevant and time bound; Chapter 3 gives realistic and timely. Both appear in the Review Guide.

Strategy vs. tactics. A strategic plan states where the organization wants to be; the tactics are the specific steps that get it there. 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.

The organizational environment

  • Every department can benefit from a formalized plan demonstrating how the work being performed aligns with the strategic goals and objectives of the organization. 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.
  • 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. Detailed planning much beyond 18 months out, other than for routine replacement, may be less valuable given the rapid changes in the IT industry.
  • A project crosswalk provides a visual summary of the initiatives and demonstrates the linkage between vision, goals and projects. Projects are weighted by scoring each against the organization's goals and priorities, producing a score and relative rank that helps provide objectivity to project priorities.

Assessing the organizational environment means understanding corporate culture, values and drivers — the attitudes and beliefs that determine whether an initiative will be accepted. That is why a technically sound initiative can succeed at one hospital and fail at another.

Forecasting technical and informational needs

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.
  • When goal deviation is suspected, the IT leader needs to be ready to challenge the request and get the project back on track. Remaining focused on goals helps avoid the service gap that occurs when requested services surpass what the internal staff can provide.
  • New project requests come from a variety of sources, some more fully developed than others. Requestors need support in determining their project's scope, definition and objective. 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, how to leverage the existing application portfolio and how to utilize network services.
  • Leaders have a responsibility to serve as the organization's conscience regarding IT requests and service overextension.
  • An IT leader must know which personnel resources are available and understand their readiness to manage contingency planning when unexpected resource issues occur.
  • Leaders must have a methodology that supports the organization's ability to measure activities against stated goals and objectives, facilitating a process in which all leaders work together to define the organization's measures of progress and success. If agreement cannot be reached on a measure, it will be difficult to know when the related goal has been achieved.

Internal benchmarking: the organization defines its current place, defines the objective, 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, and it can often be costly to gain access to private benchmark data. Be sure that any benchmarks used are comparable to the data your organization is capable of supplying, to decrease apples-to-oranges comparisons.

Developing the IT strategic 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, you must start by validating the strategies and tactics of the organizational plan first. The IT strategic plan must be perfectly aligned with all the organizational priorities.

The five steps to develop the IT plan:

  1. Initiate the document by including the mission, vision, goals and strategies of the organizationIT supports the business and therefore must be grounded in that business and its strategies
  2. Identify the current state of the systems and processes that support the business and assess their effectiveness in meeting their stated functions
  3. Define the gap that exists between the functions that are or can be provided and those that need to be developed or procured
  4. Compare the timeline for staff to manage the development and costs associated with external development or purchase
  5. Identify who will take responsibility for the initiatives to be addressed

The plan's central idea: 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.

The remainder of the plan focuses on the gaps — the gap analysis, outlining 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. Where the gap cannot be bridged with a single change, the plan outlines the steps to achieve the desired outcome, with details focused on the first step or two and more high level for the remaining steps, since technologies and organizational priorities may change during the interval.

The plan also outlines pure IT initiatives and personnel needs — examples: virtual ICUs, system transitions to cloud technologies, RFID, artificial intelligence and advanced device integration, plus regular system upgrades or replacement strategies.

Succession planning. All organizations experience turnover. 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.

Implementing the IT strategic plan

  • The plan needs to remain a living object and therefore must be regularly maintained.
  • 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 they can 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.
  • Treat the plan itself as a project. Maintain a color-coded scorecard of goal progress and achievement for all to see.

Big picture

Chapter 9 carries 57 of the 230 canonical items — a quarter of the whole bank. This first lesson holds ten of them, and they cluster around one principle: operations direct IT, not the reverse.

That principle generates several answers. Why does an IT plan start from the organizational plan? Because IT supports the business. Why must every major initiative have an operational sponsor? Because there is no such thing as an IT project. Why does a technically sound initiative fail at one site and succeed at another? Because the organizational environment — culture, values, drivers — differs.

Where it fits: Chapter 4's business case and Chapter 6's governance committee both assume this alignment logic. Chapter 9 is where it is stated.

Key concepts

Mission, vision, values, goals

In plain English: Why we exist, where we're going, what we stand for, how we'll measure it.

Technical meaning: Mission = why the organization exists, its purpose. Vision = where it wants to go or what it wants to be, a futuristic perspective. Values = what the company supports and appreciates most, reflecting corporate culture. Goals = the measures to support vision accomplishment, which must be SMART.

Picture it: CEO and board set mission and vision; the mission changes least often.

Corporate culture

In plain English: What everyone here believes about working here.

Technical meaning: 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.

Picture it: Assessing the organizational environment means understanding culture, values and drivers.

Operations direct IT

In plain English: The business says what it needs; IT says how.

Technical meaning: Operational goals direct IT and not the reverse; lack of clarity about this relationship puts projects at risk; all projects need operational leadership and, as necessary, IT guidance and support.

Picture it: 'There is no such thing as an IT project' is the same idea stated the other way round.

Strategy vs. tactics

In plain English: Where we're going, versus the steps to get there.

Technical meaning: A strategic plan states where the organization wants to be; tactics are the specific steps supporting the organizational goals, which leaders must be able to assess.

Picture it: If the stem says 'the plan states where we want to be, and X gets us there', X is the tactics.

The five IT plan steps

In plain English: Ground it, assess today, find the gap, cost the options, assign owners.

Technical meaning: Include the organization's mission, vision, goals and strategies; identify current state and assess effectiveness; define the gap between what can be provided and what must be developed or procured; compare staff timeline against external development or purchase costs; identify who takes responsibility.

Picture it: Step one is the organizational plan, not the technology inventory.

Service gap

In plain English: More asked of IT than IT can deliver.

Technical meaning: The gap that occurs when requested services surpass what the internal staff can provide; avoided by remaining focused on goals; leaders serve as the organization's conscience regarding IT requests and service overextension.

Picture it: The defense is goal discipline, not more staff.

Real-world examples

The same EHR optimization succeeds at one hospital and stalls at another with identical technology. The difference is culture, values and drivers — the organizational environment, which is what the source says to assess.

An IT plan opens with the organization's mission and goals rather than a technology roadmap. That ordering is step one, and it is what makes every later item defensible.

Distinctions & exam traps

EXAM TRAP · Strategy vs. tactics

The tempting confusion: Calling the implementation steps the strategy.

The deciding clue: The strategic plan states where the organization wants to be; the steps that get there are tactics.

Stem wording that triggers it: 'The tactics for getting there' has one correct completion. (Adjacent term.)

EXAM TRAP · Why an initiative fails at one site

The tempting confusion: Answering technical fit, vendor performance, or training quality when the same initiative succeeds elsewhere.

The deciding clue: Assessing the organizational environment means understanding corporate culture, values and drivers.

Stem wording that triggers it: Same technology, different outcome, points to environment. (Wrong layer.)

EXAM TRAP · IT strategic plan steps EXCEPT

The tempting confusion: A NOT item inserting a technology-selection or procurement activity among the five plan-development steps.

The deciding clue: The five steps are grounding in the organizational plan, current-state assessment, gap definition, timeline/cost comparison and ownership assignment.

Stem wording that triggers it: Circle EXCEPT, then find the step that belongs to selection rather than planning. (Category outlier.)

EXAM TRAP · How an IT plan is judged successful

The tempting confusion: Choosing on-budget delivery, technology currency, or number of projects completed.

The deciding clue: The IT strategic plan must be perfectly aligned with all the organizational priorities and is maintained against the organizational plan.

Stem wording that triggers it: Success is alignment with and support of organizational objectives. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define mission, vision, values and goals in one sentence each and say who sets the first two.
  2. Explain 'there is no such thing as an IT project' to an operational director.
  3. Name the five steps for developing an IT strategic plan.
  4. Explain what the service gap is and what prevents it.

Questions

10 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Management and leadership skills critical for healthcare IT success; interaction at all levels; expertise in planning, communicating, reporting, forecasting and healthcare regulation and policy; ethical working relationships with internal and external stakeholders; program management offices; managing projects, portfolios and change management; facilitating meetings; roles and positions in healthcare IT; educational strategies for IT teams
  • Strategy as a formal or informal plan of action to achieve a goal; strategies focused on where the organization would like to be in the future; statements expressing mission, vision, values and goals published for employees and customers
  • Mission as a statement of why the organization exists, its purpose; best mission statements easily understood and remembered; set by the CEO and board of directors; changing rarely unless the business or industry direction changes; every employee responsible for understanding it and tying daily work to it
  • Vision defining where the company wants to go or what it wants to be, a futuristic perspective; typically set by the CEO and board; may be altered more regularly than the mission
  • Values allowing individuals to understand what the company supports and appreciates most, e.g. compassion, service and respect; presented as a list to compare against personal values; initiatives lacking alignment or conflicting with a value should be called into question; values reflecting corporate culture as an all-encompassing set of attitudes, goals and beliefs accepted as true by all employees; healthy corporate culture as positive feelings about working for a specific company
  • Goals as the measures to support vision accomplishment; SMART as specific, measurable, attainable, relevant and time bound; examples of breaking even on Medicare reimbursement, leading in clinical quality and employing primary care providers of choice for the community; clearly articulated goals serving as guides against which to measure accomplishments
  • Formalized departmental plans demonstrating alignment with strategic goals and objectives; plan with objectives appropriate regardless of size; table or spreadsheet crosswalking organizational vision and goals through individual projects or initiatives; governance and leadership committees promoting understanding of projects coming in the next 12–18 months; detailed planning beyond 18 months less valuable other than routine replacement given rapid IT change
  • Project crosswalk providing a visual summary of initiatives and demonstrating linkage between vision, goals and projects; link to detailed work plans and project updates; projects weighted by scoring against organizational goals and priorities to produce a score and relative rank providing objectivity to project priorities
  • IT leaders aiding and directing in support of company goals requiring a balance of leadership and support; operational goals directing IT and not the reverse; lack of clarity about the operations/IT relationship putting projects at risk; all projects needing operational leadership and IT guidance and support
  • Leaders aware of organizational goals and ready to recommend appropriate systems and technologies; challenging requests when goal deviation is suspected; avoiding the service gap occurring when requested services surpass internal staff capacity
  • New project requests from varied sources with varying development; requestors needing support determining scope, definition and objective and vendor relationship support; program evaluation staff sitting with requestors; customers lacking resources and structure suggesting solutions to undefined problems; need to understand new technology, device integration options, infrastructure limitations, leveraging the existing application portfolio and utilizing network services; IT assisting with new vendor evaluation and internal and external consulting
  • Leaders assessing tactical steps supporting organizational goals; focused goals bringing clarity to strategies; wariness where an organization lacks discipline to understand what it can accomplish in a defined period; leaders as the organization's conscience regarding IT requests and service overextension; activities clearly prioritized from an institutional strategic plan
  • Goals, strategies and tactics requiring redirection and occasional time-limited scope expansion; IT leaders knowing available personnel resources and readiness for contingency planning when unexpected resource issues occur
  • Methodology supporting measurement of activities against stated goals and objectives; leaders working together to define measures of progress and success; difficulty knowing when a goal is achieved without agreement on a measure
  • Internal benchmarking defining current place and objective and measuring activity against both at regular reporting intervals; local and national benchmarks possibly requiring a contract and costly access to private benchmark data; benchmarks must be comparable to data the organization can supply to reduce apples-to-oranges comparisons
  • IT strategic plan as a reference tool for prioritizing work in large organizations or a section/addendum to the organizational plan in smaller ones; input from operational leaders and staff responsible for actionable components; beginning with copies of the current IT plan and organizational strategic plan; validating organizational strategies and tactics first if the organizational plan is more than 12 months old; perfect alignment with organizational priorities; free templates available as models
  • Five IT plan steps: initiate the document including organizational mission, vision, goals and strategies since IT supports the business; identify current state of systems and processes and assess effectiveness; define the gap between functions provided and those to be developed or procured; compare staff timeline against external development or purchase costs; identify who takes responsibility for the initiatives
  • No such thing as an IT project — all projects organizational and strategic with IT one component; every major initiative sponsored by operational leaders; plan mapping organizational strategies and supporting applications and processes; map providing visual representation of current systems status, expected useful lifeline or the gap between strategy and needed technology
  • Remainder of the plan focused on the gap analysis outlining current and desired future state; SWOT evaluation as an approach; multi-step outcomes with detail on the first step or two and higher-level treatment of later steps since technologies and priorities may change
  • Pure IT initiatives and personnel needs including virtual ICUs, cloud transitions, RFID, artificial intelligence, advanced device integration, regular upgrades or replacement strategies; planning for current and future resourcing and transition and succession plans; turnover in all organizations; each leader having a mentee groomed to move up; bench strength maintaining leadership stability as system redundancy maintains continuity
  • IT strategic plan remaining a living object regularly maintained; part of the organizational strategic plan and updated with its companion; key IT objectives visible to the entire department; annual performance objectives tied back to the plan; regular reports as measures against the plan; treating the plan as a project with a color-coded scorecard of goal progress and achievement
Read the original source

Introduction

Management and leadership skills are critical for the success of healthcare information technology (IT) organizations. Leaders and managers are expected to interact with other management and employees at all levels within an organization. This requires expertise in planning, communicating, reporting, forecasting and understanding all intricacies of healthcare regulation and policy. Leaders in healthcare IT are expected to have ethical working relationships with both internal and external stakeholders. Many organizations have implemented program management offices (PMOs) and this chapter covers managing projects, portfolios and change management. This chapter also reviews facilitating meetings, understanding roles and positions in healthcare IT and developing educational strategies for IT teams. Excellent leadership and management skills are necessary in all aspects of the work we do.

Introduction

Management and leadership skills are critical for the success of healthcare information technology (IT) organizations. Leaders and managers are expected to interact with other management and employees at all levels within an organization. This requires expertise in planning, communicating, reporting, forecasting and understanding all intricacies of healthcare regulation and policy. Leaders in healthcare IT are expected to have ethical working relationships with both internal and external stakeholders. Many organizations have implemented program management offices (PMOs) and this chapter covers managing projects, portfolios and change management. This chapter also reviews facilitating meetings, understanding roles and positions in healthcare IT and developing educational strategies for IT teams. Excellent leadership and management skills are necessary in all aspects of the work we do.

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.

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.

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 · Source: Reporting on System Performance; Project Tracking; Assessment; Departmental Effectiveness; Managing Customer Relationships; Providing Customer Service; Promoting Stakeholder Understanding of IT Opportunities and Constraints

L9.2 · Evaluating Performance, Customer Satisfaction and Stakeholder Understanding

Walkthrough

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 includes a series of rows detailing each of the steps and sub steps to be completed, with multiple columns identifying start dates, projected end dates and completion percentage.
  • Commercial project-tracking software products are available, but many organizations effectively manage projects using a simple spreadsheet.

Service level agreements and dashboards

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.

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 goaltypically an internally desired target that exceeds any quality-of-service parameters that have been agreed tothough it is not usually on a control chart.

A typical dashboard includes a series of control charts. They add lines representing the upper control limit (UCL) and lower control limit (LCL), recognizing 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.

Assessment — objective and subjective together

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.

Measuring system effectiveness needs to start with a baseline analysis. It is important to have both an objective and a subjective assessment of the quality metrics.

The source's worked example — and the exam's favourite scenario: 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 in — the 24/7 healthcare environment has expectations of 99.999% system availability.

Every SLA target can be met while customers remain dissatisfied. The answer is not to change the target first — it is to recognize that objective metrics and subjective customer assessment measure different things, and both are required.

Baseline assessment methods: face-to-face interviews (valuable for systems affecting a small number of stakeholders, especially in disparate parts of the company); unit rounding (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?); meeting with a group of users together at already-scheduled departmental or unit meetings; a town hall meeting for a general situation; a focus group for specific situations — both can be organized as either physical or virtual meetings.

The baseline assessment gathers data regarding the systems stakeholders are using and the way they are being used. 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. Be clear that not all requests can be accommodated but remain open-minded.

Follow-up. If the organization concurs that performance is satisfactory, 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. Follow-up can be accomplished by telephone or web-based surveys, and easily accessible feedback tools within the applications themselves will prompt regular responses.

Departmental effectiveness

Departmental effectiveness needs to be differentiated from system effectiveness. 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. A typical first impression of customer service is formed by the response time to inquiries. Customers are providing clinical services and therefore are not typically in one physical location for more than a few moments at a timeany 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).

Additional factors when evaluating customer satisfaction:

  1. Does IT staff empathize with the concerns and frustrations of customers?
  2. Does IT staff communicate regularly with customers when they are working on a problem that takes more than a short time to resolve?
  3. Does IT staff communicate resolution of system issues back to customers who originally reported the problem?

All three are about communication and empathy — not about technical accuracy or cost.

Customer relationship management

CRM is an organization's approach to interactions with customers, patients, vendors and other business associates. It involves using proven methods to attract new customers, retain current customers and reestablish relationships with past customers, and leveraging technology, such as the Internet and social media, and traditional marketing techniques to organize, automate and synchronize business processes.

Unlike many industries that are product driven, healthcare organizations are uniquely service driven, 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.

Setting a customer experience strategy requires: understand the organization's vision and mission; determine the organization's customer service direction, slogan and values; share the strategy using a comprehensive communications program; emphasize customer service is a key responsibility for each department; and ensure the strategy aligns with the other organizational strategies.

Staffing: interpersonal skills and the right attitude are two qualities critical for employees providing customer service. Emphasizing functional expertise, technical competence and knowledge is less important, and many of these can be taught.

The four steps to build a culture of excellent customer relations:

  1. Provide training in key skills needed to deliver excellent personal service
  2. Use ongoing coaching and feedback to reinforce improved customer relations
  3. Regularly measure and monitor performance levels
  4. Reward performance with both monetary and nonmonetary awards

Managing the customer experience: actively solicit customer feedback; teach staff how to handle customer complaints effectively using the correct blend of empathy, apology and resolution; focus on the root of the problem and not just the symptoms; and be proactive in seeking to prevent issues instead of reacting to events that have already occurred.

Midlevel management must be involved and empowered to be key change agents.

Customer centric is defined by HIMSS as "placing the customer as the center or focus of design or service." 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.

Promoting stakeholder understanding

Leaders must educate stakeholders by highlighting opportunities to be gained using technology as well as explaining any limitations.

SBARC is an acronym for situation, background, assessment, recommendation and communicationan extension of the SBAR (minus the communication step) developed at Kaiser Permanente by Michael Leonard. The one- to two-page SBARC proposal helps to frame a situation or request and a method of addressing it, providing a concise summary for leaders to assess prior to committing to a full project proposal or a pro forma financial plan.

Process improvement approaches named here: Lean (production practice looking at resource consumption) and Kaizen (continuous improvement processes).

Scope creep is defined here as the undisciplined addition of new goals, objectives and milestones that may have a negative effect on the cost or timeline of a project, occurring when inadequate analysis of suggestions occurs and additional work is added. A well-written plan signed off by all stakeholders helps eliminate it. Disciplined analysis of new opportunities is scope or project change control management. An effective way of avoiding scope creep is to anticipate it and have a method of reviewing recommended changes in scope with the project's leadership team on a regular basis.

Agile methodology is sometimes more appropriate: initial objectives are expressed and a series of sprints are defined; at the end of each sprint the team members review the product and suggest enhancements to be included in the next sprint interval, allowing more flexible development cycles.

Big picture

The single most instructive item in this lesson is the 99% uptime scenario. All SLA targets met, all customers unhappy. The source's resolution is that objective metrics and subjective assessment measure different things, and a leader needs both.

That distinction generalizes: departmental effectiveness (how personnel respond and relate — interpersonal metrics) is not the same as system effectiveness (uptime, response time). A stem describing dissatisfaction despite green dashboards is asking you to notice which one is being measured.

Where it fits: Chapter 7's benefits realization and Chapter 6's post-go-live trend analysis both feed this evaluation layer.

Key concepts

Service level agreement

In plain English: The written promise about service quality, with indicators.

Technical meaning: An agreement with indicators tracked at regular intervals; the expected service level can be internally derived, negotiated with customers, or driven by externally agreed-upon benchmarks.

Picture it: Evaluating performance against an SLA requires the indicators to be tracked at regular intervals, not reviewed once.

Objective vs. subjective assessment

In plain English: The numbers and the experience are two different measurements.

Technical meaning: It is important to have both an objective and a subjective assessment of quality metrics; 99% uptime can satisfy a control chart while customers struggle with 1.75 hours of downtime each week, and a 24/7 healthcare environment expects 99.999% availability.

Picture it: Targets met plus customers unhappy means the target does not reflect their experience.

Control chart limits

In plain English: Expected wobble, and the line where wobble stops being normal.

Technical meaning: Control charts add upper control limit and lower control limit lines around a mean; a series of points moving in one direction requires reviewing the process for special-cause variation. Variation increases costs and in healthcare may signal changes in quality of patient care.

Picture it: A stretch goal is an internal target exceeding agreed parameters, and is not usually on the control chart.

Departmental vs. system effectiveness

In plain English: How the people are, versus how the technology is.

Technical meaning: Departmental effectiveness is measured using interpersonal metrics reported by customers — response time, empathy, communication during and after issue resolution. System effectiveness covers availability and performance.

Picture it: Same feedback methods, different objectives.

SBARC

In plain English: A one-page way to frame a request.

Technical meaning: Situation, background, assessment, recommendation and communication; an extension of SBAR (developed at Kaiser Permanente by Michael Leonard) adding the communication step; a one- to two-page proposal framing a situation and an approach before a full project proposal or pro forma financial plan.

Picture it: The C is what distinguishes SBARC from SBAR.

Customer centric

In plain English: Design and service built around the customer.

Technical meaning: HIMSS definition: placing the customer as the center or focus of design or service. Internal customers include physicians, nurses and HR representatives; external customers include patients, consultants and vendors.

Picture it: The frame of reference determines who counts as internal — for one department, the rest of the organization is external.

Real-world examples

Every SLA target is green and clinicians say the system is unreliable. The source's answer is a subjective customer assessment: the 1% of downtime lands during the busiest hours, and the 24/7 environment expects five nines.

An analyst resolves a ticket and closes it without telling the nurse who reported it. Two of the three named satisfaction factors are missed at once — communication during, and communication of resolution.

Distinctions & exam traps

EXAM TRAP · Targets met, customers unhappy

The tempting confusion: Choosing to renegotiate the SLA, escalate to the vendor, or dispute the customer's perception.

The deciding clue: Objective and subjective assessment are both required; the metric may not reflect the customer's experience.

Stem wording that triggers it: Green dashboards plus complaints means measure the experience. (Wrong layer.)

EXAM TRAP · Customer satisfaction evaluation EXCEPT

The tempting confusion: A NOT item mixing empathy, ongoing communication and resolution communication with a technical or financial measure.

The deciding clue: The three named factors are all interpersonal.

Stem wording that triggers it: Circle EXCEPT, then find the option measuring the system rather than the relationship. (Category outlier.)

EXAM TRAP · Improving customer relations EXCEPT

The tempting confusion: A NOT item inserting an emphasis on technical competence among the four culture-building steps.

The deciding clue: The four steps are training in personal service skills, ongoing coaching and feedback, regular measurement and monitoring, and reward with monetary and nonmonetary awards. The source explicitly says functional expertise and technical competence matter less and can be taught.

Stem wording that triggers it: Technical skill emphasis is the outlier here. (Category outlier.)

EXAM TRAP · Explaining IT constraints

The tempting confusion: Answering budget alone, or vendor limitations alone.

The deciding clue: Leaders must highlight opportunities to be gained using technology as well as explaining limitations — infrastructure limitations, integration options, resource capacity and the service gap.

Stem wording that triggers it: 'Most often requires explaining' asks for the full constraint picture. (Plausible-but-narrow.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Explain the 99% uptime example and say what it proves about metrics.
  2. Distinguish departmental effectiveness from system effectiveness and say how each is measured.
  3. Name the three customer satisfaction factors and the four steps to build a customer relations culture.
  4. Expand SBARC and say what the C adds to SBAR.

Questions

6 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Measures monitoring effectiveness and progress of departmental activities necessary to evaluate work unit performance; two types of measures needed in sectors with both projects and services
  • Project tracking most effective using a project plan and related Gantt chart; project plan listing tasks with estimated timeframes, dependencies and responsible resources; Gantt chart rows detailing steps and sub steps with columns for start dates, projected end dates and completion percentage; commercial project-tracking software available though many organizations use a simple spreadsheet
  • Service-level agreement with indicators tracked at regular intervals for service departments; expected service level internally derived, negotiated with customers or driven by externally agreed benchmarks
  • Dashboard as a series of graphs or tables indicating current performance, historic performance for an appropriate interval, expected quality of services and acceptable variation below and above the stated goal; stretch goal as an internally desired target exceeding agreed quality-of-service parameters, not usually on a control chart
  • Control charts as statistical representations adding upper and lower control limit lines accounting for natural variation around a mean; points moving in one direction requiring process review for special-cause variation; variation increasing costs and in healthcare signaling changes in quality of patient care warranting immediate attention
  • Leaders becoming detached from the organization and stakeholders; IT leaders prone due to separate location from care services or work complexity; regular departmental and system assessments preventing isolation and enhancing communication; assessments including effectiveness of both systems supported and services provided
  • System effectiveness measurement starting with baseline analysis tied to service-level benchmarks; need for both objective and subjective assessment of quality metrics; 99% uptime example with 1.75 hours of weekly downtime within the acceptable 1% yet causing customer struggle; 24/7 healthcare environment expectations of 99.999% availability
  • Baseline assessment methods: face-to-face interviews for systems affecting few stakeholders in disparate parts of the company; unit rounding when observation of system use is needed and to demonstrate interest by presence; meeting with groups at existing departmental or unit meetings; town hall meetings for general situations; focus groups for specific situations; both physical or virtual
  • Baseline assessment gathering data on systems used and how; understanding stakeholder expectations of availability and performance; listening to past internal and external experiences and adverse changes in performance; accepting feedback on operating improvements while being clear not all requests can be accommodated
  • Regular follow-up analyses at an appropriate interval; annual follow-up if performance is satisfactory; prompter turnaround and more frequent follow-up if lower than desirable; regular communication or monthly status reports addressing improvement commitments; reassessment at intervals agreed with customers; follow-up by telephone or web-based surveys; in-application feedback tools prompting regular responses and avoiding help desk calls
  • Departmental effectiveness differentiated from system effectiveness; same feedback methodology but different objectives; value in understanding how personnel respond and relate to others; measured using interpersonal metrics reported by customers; first impression formed by response time to inquiries; clinical customers rarely in one location more than a few moments so response times beyond a couple of minutes causing dissatisfaction; ITIL as a popular service management framework
  • Customer satisfaction factors: does IT staff empathize with customer concerns and frustrations; does IT staff communicate regularly when working a problem taking more than a short time; does IT staff communicate resolution back to the customer who reported the problem
  • CRM as an organization's approach to interactions with customers, patients, vendors and business associates; proven methods to attract, retain and reestablish relationships; leveraging Internet, social media and traditional marketing to organize, automate and synchronize business processes; increased quality and efficiency, reduced costs and greater profitability
  • Healthcare uniquely service driven rather than product driven; developing relationships to improve patient loyalty by getting the right information at the right time to everyone in the continuum of care; customizing service offerings and continuously training and rewarding employees achieving profitable relations with patients, payers, regulators, vendors and other stakeholders
  • Customer experience strategy: understand vision and mission; determine customer service direction, slogan and values; share the strategy through a comprehensive communications program; emphasize customer service as a key responsibility for each department; align with other organizational strategies
  • Interpersonal skills and the right attitude critical for customer service employees; functional expertise, technical competence and knowledge less important and largely teachable; employees needing to understand organizational culture and key communication skills
  • Four steps to 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; reward performance with monetary and nonmonetary awards
  • Effective service delivery creating efficient customer interaction; identifying preferred service delivery processes, reviewing critical success points, determining service standards and objectives; establishing service delivery procedures and creating SLAs to improve satisfaction
  • Continuous improvement built into service delivery; actively soliciting customer feedback; teaching staff to handle complaints with the correct blend of empathy, apology and resolution; focusing on the root of the problem not just symptoms; being proactive rather than reactive
  • Senior management support vital while midlevel management involvement and empowerment as key change agents is essential; engaging management early and often; involving them in formulating strategy; developing coaching skills; including managers as training facilitators; rewarding them for establishing, monitoring and updating service delivery processes; motivating them as examples
  • HIMSS customer centric definition: placing the customer as the center or focus of design or service; internal customers including physicians, nurses and human resources representatives; external customers including patients, consultants and vendors connected via services, contract or agreement; frame of reference important in categorizing customers
  • Leaders responsible for discussing opportunities and systematic limitations of information systems; educating stakeholders by highlighting technology opportunities and explaining limitations
  • SBARC as situation, background, assessment, recommendation and communication; extension of SBAR developed at Kaiser Permanente by Michael Leonard; one- to two-page proposal framing a situation or request and a method of addressing it; concise summary for leaders prior to a full project proposal or pro forma financial plan; may be followed by formal business planning
  • Lean as a production practice looking at resource consumption; Kaizen as continuous improvement processes; framework including deliverables, cost and timing together defined as the scope of the project
  • Scope creep as the undisciplined addition of new goals, objectives and milestones negatively affecting cost or timeline, occurring when inadequate analysis of suggestions occurs; well-written plan signed off by stakeholders helping eliminate it; disciplined analysis referred to as scope or project change control management; amending the plan and communicating when a value-added suggestion is approved; anticipating scope creep and regularly reviewing recommended scope changes with the project leadership team
  • Agile methodology expressing initial objectives and defining a series of sprints, with team review and enhancement suggestions at the end of each sprint allowing more flexible development cycles
Read the original source

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.

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?

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.

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.

Promoting Stakeholder Understanding of IT Opportunities and Constraints

Health information and management systems’ leaders have a responsibility to discuss the opportunities and systematic limitations of using information systems to address organizational goals and objectives. Leaders must educate stakeholders by highlighting opportunities to be gained using technology as well as explaining any limitations.

The initiation of a project charter is a critical juncture in IT's support of the organization. Success can be achieved using a well-articulated and accepted process that facilitates understanding and communication between the leader and the stakeholders. A method for initiating a project is via the utilization of an SBARC. SBARC is an acronym for situation, background, assessment, recommendation and communication. This is an extension of the SBAR (minus the communication step) developed at Kaiser Permanente by Michael Leonard.8 The one- to two-page SBARC proposal helps to frame a situation or request and a method of addressing it. It is an easy way to document a situation and proposed approach to a very wide audience. The simplicity of the tool makes it easy for a knowledgeable team member to complete and provides a concise summary for leaders to assess prior to committing to a full project proposal or a pro forma financial plan.

The SBARC process begins a discussion of the key goals and objectives of an initiative and frames some of the potential strategies for resolution. As appropriate, the SBARC may be followed up with a more formal business planning process and pro forma financial plan. A disciplined approach to framing and initiating projects ensures that the stakeholder and the project team members are operating from an identical framework. Ways of assessing the process improvement needs might include the utilization of either a Lean (production practice looking at resource consumption) or Kaizen (continuous improvement processes) methodology as a tool for optimizing the performance of a system. Once developed, the framework includes the deliverables of the project, along with the cost and timing, together defined as the scope of the project.

A well-written plan that has been signed off on by all stakeholders will help to eliminate the opportunity for scope creep to infiltrate the project. Scope creep is a common event in the life of a project. New opportunities or events will warrant that new analyses occur. A disciplined analysis following the project planning approach outlined above will weigh the merits of new opportunities in the context of the project. This is referred to as scope or project change control management. If a value-added suggestion is made and approved, then the plan is amended and communication undertaken. Scope creep is the undisciplined addition of new goals, objectives and milestones that may have a negative effect on the cost or timeline of a project. This occurs when inadequate analysis of suggestions occur, and additional work is added to the project. An effective way of avoiding scope creep is to anticipate it and have a method of reviewing recommended changes in scope with the project's leadership team on a regular basis.

At times, a more appropriate method of project planning is the agile methodology. Using this approach, initial objectives are expressed and a series of sprints are defined. At the end of each sprint, the team members review the product and suggest enhancements to be included in the next sprint interval. This method allows for more flexible development cycles.

Chapter 9 · Source: Developing Policies and Procedures for Information and Systems Management; Adhering to Ethical Business Principles

L9.3 · Policies and Procedures, Legal and Regulatory Compliance, and Ethics

Walkthrough

Developing policies and procedures

The implementation of policies and procedures within an organization facilitates the standardization of actions and operations for employees, patients and guests. 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:

  1. Is the policy really needed?
  2. 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.

Do not begin from scratch. Peers, both locally and nationally, have addressed many of the issues you face. 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. If local support is not available, move to national peer groups, but ask yourself why you may be in front of the curve for your community. Named sources: HIMSS, the International Federation of Health Information Management Associations (IFHIMA) and the International Medical Informatics Association (IMIA).

The auditability rule — the source's decisive test:

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.

Consequences must be built in. 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. 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.

Legal and regulatory compliance

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, and 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 HIPAA is just the beginning. Effective leaders need to either understand the many nuances of these standards or have easy access to individuals who can assistthe corporate compliance officer or equivalent, legal counsel and the lead Joint Commission liaison, among others.

Responsibilities may fall on one individual in a small organization, but most likely will be distributed around the organization, with those individuals coming together under the auspices of a corporate compliance committee, a Joint Commission International (JCI) steering committee, or an audit and education committee.

The two most influential sources of standards for healthcare organizations in the United States are CMS and the Joint Commission.

  • CMS is a part of the Department of Health and Human Services. The key operating document for a hospital that receives any funding from CMS is "Conditions for Coverage and Conditions of Participations." A healthcare organization is held to these conditions in order to receive funds for services.
  • The Federal Register serves as the official daily publication for rules, proposed rules and notices of Federal agencies and organizations, as well as executive orders and other presidential documentsthe first and last indications of proposed rule changes.
  • JCI 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, met through preparation, followed by a scheduled site review by a team of JCI surveyors.

The most reliable way to sustain compliance is therefore an ongoing, distributed structure — a compliance committee, defined ownership, monitoring and audit — rather than a one-time review or reliance on a single expert.

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.

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.

The two ends of the ethics spectrum:

  • At one end, business ethics are meant to ensure that all members of the organization are complying with local, state and federal laws, and that they as individuals feel both compelled and safe to report any activities that are not within the scope of the law.
  • At the other end, 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.

That spectrum is the key distinction the exam tests: legal compliance is the floor; ethical principles extend beyond it into fairness, equity and community contribution.

Corporate compliance programs are made up of a set of basic elements:

  1. Senior management must be aware of and involved in the process of compliance.
  2. Policies and procedures must reflect the organization's procedures for achieving compliance.
  3. Education about compliance must be given to both management and employees.
  4. There must be both monitoring programs and disciplinary procedures to act on those who do not adhere.

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.

That last sentence is the direct answer to a conflict-of-interest scenario. A vendor offering personal benefit while a contract decision is pending creates exactly the financial gain the code excludes — the issue is the conflict itself, not whether the decision would actually have been influenced.

Big picture

Two principles here are worth more than the details. First, auditability determines whether a policy should exist at all — "do what is measurable, measure what you do, review what you have measured and act on the results." Second, ethics extends beyond law; a policy question about legality has a different answer from one about fairness and community contribution.

Where it fits: Chapter 8 handled privacy and security policy specifically; Chapter 9 handles policy as a management discipline. The corporate compliance program elements here mirror Chapter 8's HIPAA compliance methodology.

Key concepts

The auditability test

In plain English: If you can't measure it, don't write it.

Technical meaning: A reason for not adopting a policy is the inability to audit and report on its effectiveness; without audit ability you risk a challenge by health system accreditors. Do what is measurable, measure what you do, review what you have measured and act on the results.

Picture it: The same logic applies to consequences: no consequences means no need for the policy.

Consequences embedded in policy

In plain English: Say what happens if people don't follow it.

Technical meaning: The implications of failing to adhere must be built into the policy itself; exceptions must also be outlined as part of the policy.

Picture it: Embedding consequences closes the loop for employees.

Legal vs. ethical compliance

In plain English: Obeying the law versus doing right.

Technical meaning: At one end, business ethics ensure compliance with local, state and federal laws and that individuals feel compelled and safe to report activities outside the law. At the other end, ethics extend fairness and equity inside and outside the organization, with an implied duty to contribute to the business and local communities.

Picture it: Legal compliance is the floor; ethical principles reach past it.

Corporate compliance program elements

In plain English: Leadership, policy, education, monitoring and discipline.

Technical meaning: Senior management awareness and involvement; policies and procedures reflecting compliance procedures; education for management and employees; monitoring programs and disciplinary procedures. Actions must be in the best interest of the company and absent financial gain for individuals or immediate family.

Picture it: The financial-gain clause is the conflict-of-interest rule.

US standards sources

In plain English: CMS and the Joint Commission.

Technical meaning: The two most influential sources of standards for US healthcare organizations; CMS sits within HHS and its key operating document is Conditions for Coverage and Conditions of Participations; the Federal Register publishes rules and proposed rules; JCI accredits voluntarily in more than 100 countries via published standards and scheduled surveyor site reviews.

Picture it: Conditions of Participation are what funding depends on.

Real-world examples

A team drafts a policy on secure messaging but has no way to audit whether it is followed. Under the source's rule that is a reason not to adopt it — write something measurable instead.

A vendor offers an IT director personal travel while a contract decision is pending. The compliance rule is explicit: actions must be absent financial gain for individuals or immediate family. Declining and disclosing is the answer, regardless of intent.

Distinctions & exam traps

EXAM TRAP · Departmental IT policy scope EXCEPT

The tempting confusion: A NOT item mixing genuine policy subjects — security, privacy, retention, change management, licensed software, service requests, the IT strategic plan and budget — with something outside policy's remit.

The deciding clue: Policies formalize what is expected or required of employees; procedures describe how outcomes are accomplished.

Stem wording that triggers it: Circle EXCEPT, then find the option that is a technical artifact rather than a governed expectation. (Category outlier.)

EXAM TRAP · Sustaining regulatory compliance

The tempting confusion: Choosing an annual review, a single compliance expert, or vendor attestation.

The deciding clue: Responsibilities are distributed and coordinated through a corporate compliance committee, a JCI steering committee, or an audit and education committee, with ongoing monitoring.

Stem wording that triggers it: 'Most reliable way to sustain' points to ongoing structure, not a point-in-time act. (Wrong layer.)

EXAM TRAP · Ethics vs. legal compliance

The tempting confusion: Treating the two as the same requirement.

The deciding clue: Legal compliance ensures adherence to law; ethical principles extend fairness and equity inside and outside the organization, including community contribution.

Stem wording that triggers it: 'Differs from legal compliance' asks for the extension beyond law. (Adjacent term.)

EXAM TRAP · Conflict of interest

The tempting confusion: Reasoning that accepting is acceptable if the decision would not actually change.

The deciding clue: Actions must be absent of any financial gain for individuals or immediate family.

Stem wording that triggers it: The conflict is the problem, not the outcome. (Plausible-but-rationalized.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. State the auditability rule in the source's own four clauses.
  2. Explain why consequences and exceptions both belong inside the policy document.
  3. Name the four corporate compliance program elements.
  4. Explain how ethical compliance extends beyond legal compliance, with one example of each.

Questions

6 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Policies and procedures facilitating standardization of actions and operations for employees, patients and guests; implementable at any level from the entire company to the smallest operation; two leader questions of whether the policy is really needed and at what level it must be implemented
  • US accreditation requiring a defined set of policies on information management and security and privacy
  • Not beginning from scratch; peers locally and nationally having addressed the issues; starting with a local peer survey to establish networking connections and create a community standard; moving to national peer groups if local support is unavailable while asking why you are ahead of the curve; HIMSS, IFHIMA and IMIA as sources of policy examples
  • Inability to audit and report on policy effectiveness as a reason not to adopt a policy; risk of challenge by health system accreditors; do what is measurable, measure what you do, review what you have measured and act on the results
  • Acting on audit measurements; implications of failing to adhere built into the policy; consequences of noncompliance embedded to close the loop for employees; exceptions outlined as part of the policy; no consequences implying no need for the policy
  • Complex web of legal, regulatory, accreditation and compliance issues; each country with its own oversight sources; IT leaders responsible for knowing their country's standards sources
  • In the United States: meaningful use, e-prescribing, conditions of participation and HIPAA as the beginning; leaders understanding the nuances or having access to the corporate compliance officer, legal counsel and the lead Joint Commission liaison
  • Responsibilities on one individual in small organizations or distributed with coordination through a corporate compliance committee, a Joint Commission International steering committee, or an audit and education committee; ever-changing information from key documents available directly or by purchase; CMS in the United States and JCI internationally
  • CMS and the Joint Commission as the two most influential US standards sources; CMS part of the Department of Health and Human Services; Conditions for Coverage and Conditions of Participations as the key operating document for hospitals receiving CMS funding; organizations held to these conditions to receive funds
  • Federal Register as the official daily publication for rules, proposed rules and notices of federal agencies and organizations plus executive orders and presidential documents; first and last indications of proposed rule changes
  • JCI as the voluntary accreditation body for more than 100 countries; accreditation by complying with published standards; preparation followed by a scheduled site review by JCI surveyors
  • Corporate financial implosions and legal and ethical impropriety bringing organizational and leadership ethics to the forefront; leaders adhering to an identifiable code of business or corporate ethics as professionals and role models; understanding and adhering to the corporate code of ethics and values established by administration or the board
  • Business ethics at one end ensuring compliance with local, state and federal laws and that individuals feel compelled and safe to report activities outside the law; person or department charged with corporate compliance in both large and small organizations
  • Corporate compliance program elements: senior management awareness and involvement; policies and procedures reflecting compliance procedures; compliance education for management and employees; monitoring programs and disciplinary procedures for non-adherence; actions in the best interest of the company and absent financial gain for individuals or immediate family members
  • Business ethics at the other end extending fairness and equity inside and outside the organization; the organization as a member of the business and local communities with an implied duty to contribute
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.

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 · Source: Employing Comparative Analysis Strategies; Budgets; Other Financial and Nonfinancial Indicators; Benchmarks; Quality Indicators; Quality Standards and Practices

L9.4 · Comparative Analysis — Budgets, Indicators, Benchmarks and Quality

Walkthrough

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 and need to understand the organization's overall financial and budgetary reports, its comparative benchmarks and its overall performance.

Reading a budget

Budget 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 — typically last year's expenses for the same time period.

The timing trap: many expenses are spread evenly over the year and are easy to predict, measure and compare, but other expenditures have unique timing considerations that, if not understood, can lead to a false understanding of the reports. Revenue and expenses 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. A well-constructed budget report will include notations explaining the timing of events.

Financial and nonfinancial indicators

Measured to compare one organization with another, or against national benchmarks.

IndicatorDefinition
Days in accounts receivable (A/R days)The average amount of time it takes for the organization to receive payment from payers after the bills have been submitted to the guarantor
Discharged not final billed (DNFB)The expected amount of money to be billed to the guarantor, but not yet submitted due to outstanding documentation or procedural issues
Days cash on handThe number of days the organization could continue to operate if no further new funds were received

Both A/R days and DNFB are important, as they represent money due to the organization but not yet received. For days cash on hand, the larger the number, to a point, the better it is for the organization.

Benchmarks

A benchmark is a standard of comparison — drawn from peer organizations or industry norms.
  • Internal benchmarks are usually set by operations or the board of directors and are often reflections of the financial indicators listed abovetypically 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.

The comparability rule from Lesson 9.1 applies here directly: be sure that any benchmarks used are comparable to the data your organization is capable of supplying. A number far from a published benchmark is a prompt to investigate comparability and drivers — not automatic evidence of poor performance.

Quality indicators

Quality indicators may be set by state or federal government agencies or payers. 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, HHS 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 take extracts of your organization's data and aggregate them with comparable data from other organizations, distributing the information back to the data contributors so each organization can compare its own results with different slices of the healthcare continuum.

  • Advantage: they enable an organization to compare itself with other organizations of like size, educational service, payer mix, geographic location and so forth.
  • Downside: 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 with responsibilities for software development, requires careful attention to quality control standards.

  • The National Academy of Medicine (formerly the Institute of Medicine) has produced many publications citing issues with patient quality and safety, including Health IT and Patient Safety: Building Safer Systems for Better Care. While a US 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.
  • External quality and patient safety organizations such as the Leapfrog Group can provide testing to ensure appropriate decision support and alerts for 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. Publishing current performance, as well as goals and objectives, will remind the entire department of the expectations and aspirations.

Big picture

The exam tests two things here: the definition of a benchmark, and what to do when your number is far from it.

The second is the more interesting one. A published benchmark is a comparison standard, not a verdict. The source has already warned that benchmarks must be comparable to the data your organization can supply, and that external comparison groups exist precisely so you can compare against organizations of like size, payer mix and geography. So an outlying number prompts investigation of comparability and underlying drivers, not immediate cost-cutting.

Where it fits: Chapter 3 covered clinical quality measures; Chapter 9 covers the financial and organizational comparison layer. Chapter 4's cost–benefit analysis supplies the investment side.

Key concepts

Benchmark

In plain English: A standard you measure yourself against.

Technical meaning: A standard of comparison drawn from peer organizations or industry norms; internal benchmarks are set by operations or the board and often reflect financial indicators, while external benchmarks may include financial indicators but are likely to reflect quality, safety, regulatory or accreditation measures.

Picture it: Internal ones you set; external ones you are measured against.

A/R days and DNFB

In plain English: Money owed and money not yet billed.

Technical meaning: Days in accounts receivable is the average time to receive payment from payers after bills are submitted to the guarantor. Discharged not final billed is the expected amount to be billed but not yet submitted due to outstanding documentation or procedural issues.

Picture it: Both represent money due but not received. DNFB is often an information problem, which is why IT cares.

Days cash on hand

In plain English: How long you could run with no new money.

Technical meaning: The number of days the organization could continue to operate if no further new funds were received; the larger the number, to a point, the better.

Picture it: 'To a point' — hoarding cash has its own cost.

Budget timing distortion

In plain English: Quarterly items make even-spread budgets look wrong.

Technical meaning: Revenue and expenses recognized semiannually or quarterly can make year-to-date results appear far from expected when the budget assumes even distribution; a well-constructed report includes notations explaining the timing of events.

Picture it: Before calling a variance a problem, check whether it is a timing artifact.

Investigating a benchmark gap

In plain English: A gap is a question, not a conclusion.

Technical meaning: Benchmarks must be comparable to the data the organization can supply; external comparison groups exist to compare against organizations of like size, educational service, payer mix and geographic location.

Picture it: Ask whether the comparison is apples-to-apples before acting on it.

Real-world examples

An IT cost-per-user sits far above the published benchmark. Before cutting, check whether the benchmark's organizations carry the same scope — a department that includes biomedical engineering and telecom is not comparable to one that does not.

Year-to-date maintenance expense looks 200% over budget in March. The annual software maintenance invoice landed in Q1 while the budget spread it evenly. That is the timing artifact the source names.

Distinctions & exam traps

EXAM TRAP · Responding to a benchmark gap

The tempting confusion: Choosing immediate cost reduction, staff reduction, or dismissing the benchmark.

The deciding clue: Benchmarks must be comparable to your data, and comparison groups are built around like size, payer mix and geography.

Stem wording that triggers it: 'Appropriate response' to an outlying benchmark is investigation of comparability and drivers. (Plausible-but-upstream.)

EXAM TRAP · Benchmark vs. indicator vs. quality measure

The tempting confusion: All three are comparison-related terms in this section.

The deciding clue: A benchmark is the standard of comparison. Indicators are the things measured. Quality indicators may be set by agencies or payers and can themselves become benchmarks.

Stem wording that triggers it: 'A standard of comparison drawn from peers or industry norms' names the benchmark. (Adjacent term.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define benchmark, A/R days, DNFB and days cash on hand without looking.
  2. Explain the timing distortion in budget reports and how a well-built report prevents it.
  3. Say what you would do first if your cost per user sat far above the published benchmark, and why.

Questions

2 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Leaders understanding more than departmental goals, measures and metrics; IT leaders often part of overall operational leadership needing to understand organizational financial and budgetary reports, comparative benchmarks and overall performance
  • Budget reports summarized and reviewed by financial leaders; annual budgets by line item; projected budget and expenditures to date; variances between budgeted and actual; comparison column for the most recent historic comparable financial period, often last year's same period
  • Evenly spread expenses easy to predict, measure and compare; other expenditures with unique timing considerations leading to false understanding; semiannual or quarterly recognition making year-to-date results appear far from expected under even distribution; well-constructed budget reports including notations explaining timing of events
  • Financial and nonfinancial indicators measured to compare organizations or against national benchmarks
  • Days in accounts receivable as the average time to receive payment from payers after bills are submitted to the guarantor
  • Discharged not final billed as the expected amount to be billed to the guarantor but not yet submitted due to outstanding documentation or procedural issues; both A/R days and DNFB representing money due but not received
  • Days cash on hand as the number of days the organization could continue to operate with no further new funds; larger being better to a point
  • Organizational benchmarks made up of internal and external comparisons; internal benchmarks usually set by operations or the board of directors and often reflecting financial indicators including goals for days in A/R and days cash on hand; external benchmarks possibly including additional financial indicators but likely reflecting quality, safety, regulatory or accreditation measures
  • Quality indicators set by state or federal government agencies or payers; serving as goals to be met and aggregate data establishing benchmarks; each country with voluntary or required quality benchmarking processes; HHS quality reporting programs by setting type in the United States
  • External services such as the University Health System Consortium or Premier taking data extracts and aggregating them with comparable data, distributing results back to contributors for comparison across slices of the healthcare continuum; advantage of comparison with organizations of like size, educational service, payer mix and geographic location; downside of subscription services providing comparisons only to paid subscribers
  • IT department oversight, especially with software development responsibilities, requiring attention to quality control standards; National Academy of Medicine (formerly the Institute of Medicine) publications on patient quality and safety including Health IT and Patient Safety: Building Safer Systems for Better Care with international relevance
  • Software as delivered and its configuration requiring comprehensive and regular review for safe high-quality performance; quality assurance beginning with staff who implement and configure software technically; performance measured against vendor testing results and internally developed quality assurance scripts; external organizations such as the Leapfrog Group providing testing for appropriate decision support and alerts in CPOE programs
  • Leaders setting clear expectations or a plan for quality standards, then measuring, reporting and modifying to continually improve; publishing current performance, goals and objectives to remind the department of expectations and aspirations
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.

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 · Source: Managing Projects, Project Portfolios and Vendors; Managing Vendor Relationships

L9.5 · Managing Projects, Project Portfolios and Vendors

Walkthrough

Projects, programs 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. 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 and PMOs to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics.
  • Enterprise project portfolio management (EPPM) manages project initiatives through a single, enterprise-wide system, taking a more integrated and top-down approach to managing all project-intensive work and resources across the enterprise, in contrast to combining manual processes, desktop project tools and best-of-breed PPM applications for each project portfolio environment.

The discriminator: interdependent projects → program management. Independent projects competing for the same resources → project portfolio management.

The five project management phases

  1. Initiating phaseproject stakeholders are identified, the project charter and the preliminary scope statement are developed and the project charter is approved
  2. Planning phaseplanning the project scope, quality and risk management and schedule; scope defined through creating the project management plan, developing the scope management plan and creating the work breakdown structure (WBS); quality and risk planning involves identifying and analyzing risks and planning the risk responses; the schedule is developed by defining and sequencing activities, estimating activity resources and duration, determining the project schedule and planning human resources
  3. Executing phasedirecting and managing project execution; acquiring, developing and managing the project team; performing quality assurance; and procuring project resources
  4. Monitoring and controlling phasemanaging 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.
  5. Closing phasereleasing 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.

The project charter is developed and approved during initiating. That placement is directly tested.

The nine PMBOK knowledge areas

  1. Project scope managementensuring all the required work is performed to complete the project successfully; scope creep is a key reason why many projects fail; accomplished by defining and controlling what is included in the project and what is not; activities include the scope plan, scope definition, WBS, scope control and scope verification
  2. Project time managementdeveloping and controlling the project schedule; components include activity definition, activity sequencing, activity resource scheduling, activity duration, schedule development and schedule control
  3. Project cost managementestimating the project cost and ensuring the project is completed within the approved budget; includes the cost estimate, cost budgeting and cost control
  4. Project human resource managementobtaining, developing and managing the team who will perform the project work
  5. Project procurement managementmanaging the acquisition of products and services from external sources; includes planning acquisitions, negotiating contracts with sellers, selecting sellers, administering contracts with sellers and closing contracts
  6. Project risk managementidentification of project risks and appropriate responses; includes identifying risks, performing a risk analysis, developing a risk response plan and monitoring and controlling risks
  7. Project quality managementensuring the project satisfies its objectives and requirements; includes quality planning, quality assurance and quality control
  8. Project integration managementthe integration of the various project activities; includes developing the project management plan, directing and managing project execution, monitoring and controlling the project work and closing the project
  9. Project communications managementensures project information is generated and distributed promptly; includes planning communication, distributing needed information to stakeholders in a timely fashion, reporting project performance and status and resolving issues among stakeholders

The project manager is responsible for working with project sponsors, the project team and others to meet project goals and deliver the project within budget and on schedule, and should 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.

Managing vendor relationships

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. A well-managed vendor relationship will result in increased customer satisfaction, reduced costs, better quality and better service from the vendor.

The vendor management 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 carefully considered to ascertain that restrictions or exclusions, penalties and terms are beneficial to both parties. Once the relationship has begun, vendor performance must always be monitored, with attention to the requirements that are most critical to the healthcare organization. Regular communication will help to avoid misunderstandings and address issues before they become problems.

The three common pitfalls:

  1. Do not 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.
  2. Do not select a vendor based on price alone. Give priority to a vendor that understands the value of developing a relationship that is mutually beneficial.
  3. 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 ten vendor management principles:

  1. Use project management methodology — a well-defined and properly planned project, effective project sponsorship, clarified roles and responsibilities, formal change control management and effective issue management
  2. Understand vendor management is multifacetedevaluation and selection, contract development, relationship management and delivery management
  3. Be aware of the contract detailsunderstanding what the vendor is responsible for, managing the project and vendor according to the contract and understanding what incentives motivate the vendor
  4. Formal documentation is keyall changes to the project and communications must be in writing and formally controlled
  5. Contract complexity should be consistent with project riskthe procurement process and the contract's level of detail should correspond to the level of project risk
  6. Include all important deliverables in the contractdeliverable specifications; the methodology used to create the deliverable; specific resources, roles and responsibilities; planned communications; deliverable acceptance criteria; and project success criteria
  7. Management commitment is keysenior management's commitment and flexibility are important to making the vendor-customer partnership work
  8. Focus on benefiting both the customer and the vendorboth parties should give high priority to developing mutually beneficial resolutions should issues and tensions arise
  9. Clarify contractual terms and expectationsall terms and processes should be reviewed, explained and clarified to avoid conflicts and misunderstandings
  10. Ensure vendor and customer roles and responsibilities are clearprecisely defined in the contract, with particular attention 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

When a vendor underperforms, the principles point one way: manage the vendor according to the contract, document formally, and work toward a mutually beneficial resolution — not immediate termination and not informal tolerance.

Big picture

This lesson carries nine items and holds the exam's project vocabulary. Two discriminations matter most:

Program vs. portfolio management. Multiple interdependent projects → program management. Multiple independent projects competing for the same limited resources → project portfolio management. The word "independent" in a stem is doing the work.

Ethical vendor management. The principles consistently favour contract-based management, formal documentation and mutual benefit. Anything describing informal side agreements, price-only selection, or accepting personal benefit falls outside them.

Where it fits: Chapter 6 ran the selection; Chapter 9 manages the relationship afterward. The source is explicit that these are different disciplines and that confusing them is pitfall number one.

Key concepts

Project vs. operations

In plain English: Temporary with an end date, versus ongoing.

Technical meaning: A project is a temporary endeavor with a defined beginning and end; operational initiatives are repetitive, permanent or semi-permanent functional activities. Organizations supporting both are matrixed organizations.

Picture it: Matrixed is the named term for doing both at once.

Program vs. portfolio management

In plain English: Related projects, versus unrelated ones sharing resources.

Technical meaning: Program management manages multiple interdependent projects in a portfolio. Project portfolio management is the centralized management of processes, methods and technologies used to analyze and collectively manage a group of current or proposed projects based on key characteristics, adopted where multiple independent projects and resources need a formalized tracking and allocation framework.

Picture it: 'Independent projects competing for the same limited staff' names PPM.

The five project phases

In plain English: Initiate, plan, execute, monitor and control, close.

Technical meaning: Initiating (stakeholders identified, charter and preliminary scope statement developed, charter approved); planning (scope, quality and risk management, schedule, WBS); executing (directing execution, team, quality assurance, procurement); monitoring and controlling (integrated change control, quality, cost/schedule/scope changes, performance measurement, risk monitoring); closing (deliverables, documentation handover, contract termination, resource release, closure communication, post-implementation review).

Picture it: The project charter belongs to initiating.

The nine PMBOK knowledge areas

In plain English: Scope, time, cost, HR, procurement, risk, quality, integration, communications.

Technical meaning: Nine areas per the PMBOK Guide, each with named component activities.

Picture it: Scope creep is named as a key reason why many projects fail, under scope management.

Contract complexity matches risk

In plain English: Risky project, detailed contract.

Technical meaning: The procurement process and the contract's level of detail should correspond to the level of project risk.

Picture it: Not every engagement needs the same paperwork — the principle is proportionality.

Real-world examples

A health system runs eleven unrelated projects drawing on the same six analysts. Nothing is interdependent; everything competes. That is project portfolio management, not program management.

A long-standing vendor starts missing contracted response times. The principles say manage according to the contract, document formally, and pursue a mutually beneficial resolution — escalating within the relationship before ending it.

Distinctions & exam traps

EXAM TRAP · Program vs. portfolio

The tempting confusion: Both manage multiple projects.

The deciding clue: Program management is for interdependent projects; portfolio management is for independent projects requiring a formalized framework for tracking, allocating and managing resources.

Stem wording that triggers it: 'Many independent projects competing for the same limited staff' names PPM. (Adjacent term.)

EXAM TRAP · Project charter placement

The tempting confusion: Placing the charter in planning because it feels like planning.

The deciding clue: The initiating phase identifies stakeholders and develops and approves the project charter and preliminary scope statement.

Stem wording that triggers it: Charter = initiating. (Plausible-but-upstream.)

EXAM TRAP · Vendor management principles EXCEPT

The tempting confusion: A NOT item inserting price-only selection, informal agreements, or one-sided advantage among the ten principles.

The deciding clue: The principles favour project management methodology, contract awareness, formal documentation, proportionate contract complexity, complete deliverables, management commitment, mutual benefit, clarified terms and defined roles.

Stem wording that triggers it: Circle EXCEPT, then find the option that contradicts mutual benefit or formality. (Category outlier.)

EXAM TRAP · Responding to vendor underperformance

The tempting confusion: Choosing immediate termination, informal tolerance, or public escalation.

The deciding clue: Manage the project and vendor according to the contract, document formally and pursue mutually beneficial resolution.

Stem wording that triggers it: 'Appropriate response' works through the contract first. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define a project against operations and name what a matrixed organization is.
  2. Distinguish program management from project portfolio management using the word 'independent'.
  3. Recite the five project phases and say where the charter is approved.
  4. Name six of the ten vendor management principles.

Questions

8 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Project management as the discipline of planning, organizing, securing, managing, leading and controlling resources to achieve specific goals; methodology used to implement new and complex IT systems
  • Project as a temporary endeavor with a defined beginning and end, contrasting with repetitive, permanent or semi-permanent operational initiatives; hospitals supporting both called matrixed organizations
  • Program management used where multiple interdependent projects exist, managing all projects in a portfolio
  • Project portfolio management adopted by health systems with multiple independent projects and resources requiring a formalized framework for tracking, allocating and managing; centralized management of processes, methods and technologies used by project managers and PMOs to analyze and collectively manage current or proposed projects based on key characteristics
  • Enterprise project portfolio management managing initiatives through a single enterprise-wide system; more integrated and top-down approach to all project-intensive work and resources across the enterprise, contrasting with manual processes, desktop project tools and best-of-breed PPM applications per environment
  • Initiating phase: project stakeholders identified, project charter and preliminary scope statement developed, project charter approved
  • Planning phase: planning project scope, quality and risk management and schedule; scope defined through the project management plan, scope management plan and work breakdown structure; quality and risk planning identifying and analyzing risks and planning responses; schedule developed by defining and sequencing activities, estimating activity resources and duration, determining the schedule and planning human resources
  • Executing phase: directing and managing project execution; acquiring, developing and managing the project team; performing quality assurance; procuring project resources
  • Monitoring and controlling phase: managing integrated change control; controlling quality; controlling changes in cost, schedule and scope; measuring performance; monitoring and controlling risks; effective change control addressing reactive and requested changes with processes for categorizing changes and determining how they will be requested, reviewed and implemented
  • Closing phase: releasing final deliverables to the customer; handing over project documentation; terminating supplier contracts; releasing project resources; communicating closure to all stakeholders; post-implementation review identifying the level of project success and lessons learned
  • Nine PMBOK knowledge areas: project scope management (scope creep a key reason projects fail; scope plan, scope definition, WBS, scope control, scope verification); project time management (activity definition, sequencing, resource scheduling, duration, schedule development and control); project cost management (cost estimate, cost budgeting, cost control); project human resource management (obtaining, developing and managing the team); project procurement management (planning acquisitions, negotiating contracts with sellers, selecting sellers, administering contracts, closing contracts); project risk management (identifying risks, risk analysis, risk response plan, monitoring and controlling risks); project quality management (quality planning, quality assurance, quality control); project integration management (developing the project management plan, directing and managing execution, monitoring and controlling work, closing the project); project communications management (planning communication, timely distribution to stakeholders, reporting performance and status, resolving issues among stakeholders)
  • Project manager responsible for working with sponsors, the team and others to meet goals and deliver within budget and on schedule; controlling assigned resources; managing scope, schedule and cost; reporting progress; facilitating and resolving issues, conflicts, risks and obstacles
  • CIOs turning to vendors for expertise and support; well-managed vendor relationships producing increased customer satisfaction, reduced costs, better quality and better service; vendor management not simply negotiating the lowest price but working on contract performance, schedules and costs, product functionality and support and maintenance agreements for mutual benefit
  • Vendor management process beginning with selecting the right vendor for the right reasons: analyzing business requirements, vendor search, selecting the winning candidate and negotiating the contract; contract considered so restrictions or exclusions, penalties and terms benefit both parties; ongoing performance monitoring attentive to the most critical requirements; regular communication avoiding misunderstandings and addressing issues early
  • Three pitfalls: confusing vendor selection with vendor management; selecting on price alone rather than mutual benefit; failing to evaluate how vendor relationships affect the business beyond SLAs and contract fulfillment, including whether the engagement brought value and whether both parties received a return
  • Ten vendor management principles: use project management methodology; understand vendor management is multifaceted covering evaluation and selection, contract development, relationship management and delivery management; be aware of contract details including vendor responsibilities and vendor incentives; formal documentation with all changes and communications in writing and formally controlled; contract complexity consistent with project risk; include all important deliverables in the contract including specifications, creation methodology, resources, roles and responsibilities, planned communications, acceptance criteria and project success criteria; management commitment and flexibility; focus on benefiting both customer and vendor with mutually beneficial resolutions; clarify contractual terms and expectations; ensure vendor and customer roles and responsibilities are precisely defined with attention to interactions between procurement and the project team, the contract administrator and PM, and the vendor's PM, sales team and accounting and legal departments
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.

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.

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.

Chapter 9 · Source: Consulting Services; Preparing and Delivering Business Communications; Facilitating Group Discussions and Committee Meetings; Steering Committee Meetings

L9.6 · Consultative Services, Business Communications, Facilitation and Steering Committees

Walkthrough

Consulting services

Consulting services are frequently purchased when personnel resources are in short supply or when a specific skill is lacking within the organization. Most frequently, an organization goes to the outside to facilitate a large initiative when internal resources cannot be spared. It is possible to retain professional services on an issue-by-issue basis or to keep a firm on retainer. Additionally, an organization could supply in-house consultation as a means of managing, staffing, or advising on any manner of need.

In-house consultation can be provided by individuals on an as-needed basis, but larger organizations are beginning to implement a PMO. The IT and facility/plant management departments and staff often have the greatest depth of experience in managing large and complex projects, and the PMO may grow out of one or both of those areas. The PMO has personnel who are trained or certified in project management methodology as sponsored by the Project Management Institute (PMI).

PMO staff are skilled at:

  • meeting with operational personnel to understand the detailed requirements of the project at hand and translate those requirements into a plan for execution
  • the processes of resource gathering, project planning and project scope management
  • the tools for visualizing the life of the project
  • managing development of the project's pro forma financial statements and the ongoing project budget

IT leaders may also serve as the voice of internal expertise. As departments throughout the healthcare organization begin to automate, they may need guidance or advice as to how to incorporate technologies into their workflow. The IT leaders or the PMO can provide innovation support to explore existing technologies to implement or watch for these departments. Partnership between the operational and technology experts creates an opportunity for innovation.

The consultative posture, from Lesson 9.1: when customers suggest a solution to a problem that has not been well defined, the consultant's job is to help them work through the request — determining scope, definition and objective — before evaluating any product.

Preparing and delivering business communications

It is critical for leaders and managers to possess excellent written and verbal communication skills, and to have the ability to organize and manage business meetings. Organized meeting preparation helps attendees understand the goals and objectives of the meeting and the importance of the time invested.

A meeting agenda template for all meetings and minutes of the meeting will help meeting facilitators. Use of these tools creates a uniform method of communication that allows the staff to learn how to identify issues, actions and decisions in a consistent way. Variations in templates and formatting add a level of complexity for the meeting attendees and customers.

The agenda template sections: organization's name and committee name; Meeting Information (date, time, location); Attendees (expected participants and their roles); the agenda itself (each discussion point, the expected outcomes, the parties responsible to lead the discussion, and the time limit for presentation, discussion and decision); Committee Action Items (pending actions from the most recent meeting); Committee Action Register (actions from prior meetings); Open Issues (items not completed by the desired action during the previous meeting, including anything tabled); New Issues (a tracking section for the record keeper and chair, for issues needing attention between meetings).

It is acceptable to push back the date of some deliverables, but those changes should be made in a transparent way with the support of the committee.

Presentation skills. Presentation skills help define a leader. Leaders must speak clearly and with authority.

  1. First, let the audience know the purpose and the desired outcome of your presentation. Is the purpose to inform or to have an action result from the materials presented?
  2. During the presentation, include all the information that attendees need to understand, but highlight the key points rather than every detail.
  3. In closing, restate both the purpose and the desired outcome and address any questions or concerns, as this prevents disruption and loss of continuity during the presentation.

Opening with purpose and desired outcome is the source's explicit instruction — not background, not methodology, not a data walkthrough.

Status reports. Like other communications, status documents need to provide an initial brief summary and follow with necessary supporting documentation. For project communications, the timeline and the completion status are the best first materials for review. A color-coded summary of tasks and status provides valuable visual clues, and arrows provide quick indicators of the general direction of the elements compared to their immediately preceding status. Keep the reports simple by using red, yellow and green to identify tasks that are out of compliance, at risk or on track, respectively. Status reports need only be a single page with a table of color-coded tasks, a summary of the issues, the responsible parties for each task and the estimated date of resolution or completion.

Facilitating group discussions

It is important for a leader to facilitate conversations and it is equally important for a leader to guide a group through difficult discussions. This differs somewhat from a typical business meeting.

  • Knowing the issues, controversies and positions of meeting participants helps to manage the discussion.
  • Construct meeting agendas with consideration for the time it will take to resolve issues and keep controversial decisions at the top of the agenda or as the sole item so there is adequate time for discussion and resolution.
  • If able, meet with key committee members in advance and begin a process of negotiation and education.
  • Become familiar with Robert's Rules of Order and define the expected rules of participation with committee members at the formation of the committee or at the beginning of any particularly challenging meeting.
  • Keep a record of all motions and seconds. Record the essence of key discussions, including the names of participants when there is dissension. Ideally, decisions will be arrived at by consensus, but when necessary, keep a detailed record of the vote.
  • Do not let any committee members dominate the conversation. Ask speakers to clarify whether they are speaking in favor of or against the motion at hand. Do not hesitate to clarify whether a member is contributing new insights to the discussion or just echoing another's thoughts.
  • The committee chairperson must not dominate the conversation. The chair carefully guides the conversation through the selection of speakers, asks probing and clarifying questions and contributes or highlights commentary as necessary.

The straw poll. Identify those in favor of a motion and those who can live with the motion. If some attendees cannot live with the motion as stated, they should be asked to offer an alternative solution that serves the goals of all parties at the table. This keeps attendees accountable for problem solving.

Consensus is the process of guiding a group toward a decision all members can support — note the standard: not unanimous enthusiasm, but a decision everyone can live with.

When a meeting stalls over a disputed priority, the facilitator's first move is to clarify the positions and the underlying interests — asking speakers to state whether they favour or oppose, and whether they are adding new information — rather than escalating, voting immediately, or deferring.

Steering committee meetings

Nearly 72% of all IT organizations have steering committees. The use of IT steering committees ranks first as the most mature IT management practice out of 15 practices covered in the study.

A steering committee is defined as an advisory committee, usually made up of high-level stakeholders or experts, which provides guidance on key issues such as company policy and objectives, budgetary control, marketing strategy, resource allocation and decisions involving large expenditures.

IT steering committees are a best-practice approach for aligning strategic business and IT priorities. Steering committees, which usually include executives and department heads, focus on three main tasks: IT strategic planning, project prioritization and project approval. Clear mandates and a real ability to influence decision making through executive participation increase the value of IT steering committees.

Four strategies CIOs should consider:

  1. Create a committee charter that includes the desired outcomes — helping everyone understand the role and purpose of the group, promoting improved communication and recognizing the partnership required for a successful IT deployment
  2. Establish a scope that reflects a corporate-wide perspectivethe broader focus will be helpful when mediating conflicts in priorities or departmental perspectives that may not be in the best interest of the entire organization
  3. Consider indicating the specific level of authority of this group and its role in decision making — for example, a coordinating body that will resolve priorities, endorse proposals prior to approvals and monitor progress of major IT initiatives, but with no role in budget approval or other departmental expenditure decisions
  4. Designate someone other than the CIO to chair the IT steering committeeassigning a non-IT person, such as the COO, CMIO or CFO, communicates the message that IT is accepted as a critical resource and recognized as such by the entire organization

Three steps to form an effective committee: develop a case by aligning IT priorities with strategic business priorities (focusing on core IT strategic objectives and not IT resource allocation, stressing shared decision making and fostering a culture of communication between business units); develop a steering committee charter outlining key tasks and responsibilities; and keep the IT steering committee small and schedule regular meetings, ensuring membership is consistently informed, engaged as often as needed based on project scope and timelines, and includes executive decision-making authority.

Presenting data analysis to decision makers

Drawing on the presentation guidance and the analytics discipline established in Chapters 3 and 4: when presenting interpretations and recommendations of data analyses, the analyst's primary obligation is that the interpretation is accurate and faithfully supported by the data — including stating limitations and the basis for conclusions. Presentation should highlight key points rather than every detail, state purpose and desired outcome, and restate them in closing.

What does not belong is suppressing findings that complicate the recommendation. A recommendation stands on the data or it does not stand.

Big picture

This lesson holds nine items and covers the softer half of Section IV — but the exam tests it with the same precision as the technical chapters.

Two definitions are load-bearing. Consensus is guiding a group to a decision all members can support, and the straw poll's "can you live with it" standard is how you find it. A steering committee is an advisory committee of high-level stakeholders guiding company policy, budgetary control, resource allocation and large expenditures — the same body Chapter 6 called the governance committee.

Where it fits: Chapter 6's governance committee and Chapter 9's steering committee are the same structure viewed from selection and from management.

Key concepts

Consensus

In plain English: A decision everyone can live with.

Technical meaning: The process of guiding a group toward a decision all members can support; found using a straw poll identifying those in favor and those who can live with the motion, with dissenters asked to offer an alternative serving all parties' goals.

Picture it: Not unanimity. The 'can live with' standard is the operational test.

Steering committee

In plain English: Senior people who set direction and priorities.

Technical meaning: An advisory committee, usually made up of high-level stakeholders or experts, providing guidance on key issues such as company policy and objectives, budgetary control, marketing strategy, resource allocation and decisions involving large expenditures; focused on IT strategic planning, project prioritization and project approval.

Picture it: Best practice is that someone other than the CIO chairs it.

Executive presentation opening

In plain English: Say what this is for and what you want, first.

Technical meaning: Let the audience know the purpose and the desired outcome — whether the purpose is to inform or to produce an action — then highlight key points rather than every detail, and restate purpose and desired outcome in closing.

Picture it: Purpose and desired outcome open and close the presentation.

Status report format

In plain English: One page, colour-coded, with owners and dates.

Technical meaning: Initial brief summary followed by supporting documentation; timeline and completion status first; red, yellow and green for out of compliance, at risk and on track; arrows indicating direction against the previous status; a single page with a table of tasks, issue summary, responsible parties and estimated resolution dates.

Picture it: Red/yellow/green maps to out of compliance / at risk / on track — in that order.

Consultative technology services

In plain English: Advising the business on how to use technology.

Technical meaning: Guidance on incorporating technologies into workflow, innovation support to explore existing technologies to implement or watch, evaluation of new vendors, translating operational requirements into a plan for execution, and internal and external consulting.

Picture it: The partnership between operational and technology experts is where innovation comes from.

Real-world examples

A steering committee deadlocks over which of two departments goes first. The facilitator asks each speaker to state their position and whether they are adding new information, then runs a straw poll on the 'can live with it' standard. That sequence is straight from the source.

A department proposes a specific product for a problem it has not defined. The consultative move is to work through scope, definition and objective with the requestor before any product conversation.

Distinctions & exam traps

EXAM TRAP · Consensus vs. voting vs. compromise

The tempting confusion: All three resolve group disagreement.

The deciding clue: Consensus is guiding the group to a decision all members can support; a detailed vote record is kept only when necessary.

Stem wording that triggers it: 'A decision all members can support' names consensus. (Adjacent term.)

EXAM TRAP · Facilitator's first move in a stalled meeting

The tempting confusion: Choosing to call a vote, escalate to an executive, or table the item.

The deciding clue: Clarify positions — whether speakers favour or oppose, and whether they are contributing new insight — and use a straw poll to surface what people can live with.

Stem wording that triggers it: 'Should first' points to clarification, not resolution. (Plausible-but-upstream.)

EXAM TRAP · Presenting data analysis EXCEPT

The tempting confusion: A NOT item inserting omission of inconvenient findings among legitimate presentation practices.

The deciding clue: The obligation is accurate interpretation faithfully supported by the data, with limitations stated.

Stem wording that triggers it: Any option that suppresses findings is the outlier. (Category outlier.)

EXAM TRAP · Steering committee identity

The tempting confusion: Confusing it with the project team, the PMO, or a compliance committee.

The deciding clue: An advisory committee of high-level stakeholders guiding company policy, budgetary control, resource allocation and large expenditure decisions.

Stem wording that triggers it: That phrasing names the steering committee. (Adjacent role.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Define consensus and describe how a straw poll finds it.
  2. Give the steering committee definition and name its three main tasks.
  3. Say how you open an executive presentation and how you close it.
  4. Explain the consultative response to a department that has named a product but not a problem.

Questions

10 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Consulting services purchased when personnel resources are short or a specific skill is lacking; going outside to facilitate a large initiative when internal resources cannot be spared; professional services on an issue-by-issue basis or on retainer; in-house consultation for managing, staffing or advising
  • In-house consultation by individuals as needed; larger organizations implementing a PMO; IT and facility/plant management departments often having the greatest depth of experience in large complex projects, with the PMO growing out of one or both; PMO personnel trained or certified in project management methodology sponsored by the Project Management Institute
  • PMO staff skilled at meeting operational personnel to understand detailed project requirements and translate them into a plan for execution; resource gathering, project planning and project scope management; tools for visualizing the life of the project; managing pro forma financial statements and the ongoing project budget; IT project leaders shifting focus from operational leadership to true project management
  • IT leaders as the voice of internal expertise; departments automating needing guidance on incorporating technologies into workflow; IT leaders or the PMO providing innovation support to explore technologies to implement or watch; partnership between operational and technology experts creating opportunity for innovation
  • Leaders needing excellent written and verbal communication skills and ability to organize and manage business meetings; organized preparation helping attendees understand goals, objectives and importance of time invested; well-prepared documents outlining topics and time per issue
  • Meeting agenda template and minutes helping facilitators; uniform communication allowing staff to identify issues, actions and decisions consistently; variations in templates and formatting adding complexity for attendees and customers
  • Agenda template sections: organization and committee name; Meeting Information with date, time and location; Attendees with expected participants and roles; agenda listing discussion points, expected outcomes, responsible parties and time limits for presentation, discussion and decision; Committee Action Items for pending actions from the most recent meeting; Committee Action Register for prior meetings; Open Issues for items not completed or tabled; New Issues as a tracking section for the record keeper and chair
  • Acceptable to push back deliverable dates transparently with committee support
  • Presentation skills defining a leader; speaking clearly and with authority; letting the audience know the purpose and desired outcome and whether the purpose is to inform or produce action; including needed information while highlighting key points rather than every detail; restating purpose and desired outcome in closing and addressing questions to prevent disruption and loss of continuity
  • Project plans and status reports as important tools; status documents providing an initial brief summary followed by supporting documentation; timeline and completion status as the best first materials; color-coded summary of tasks and status; arrows indicating direction versus preceding status; red, yellow and green for out of compliance, at risk and on track; single-page reports with a table of color-coded tasks, issue summary, responsible parties and estimated date of resolution or completion
  • Facilitating conversations and guiding groups through difficult discussions differing from typical business meetings; knowing issues, controversies and participant positions; constructing agendas allowing time for resolution and keeping controversial decisions at the top or as the sole item; meeting key committee members in advance for negotiation and education
  • Robert's Rules of Order; defining expected rules of participation at committee formation or at the start of a challenging meeting; keeping a record of all motions and seconds; recording the essence of key discussions including names when there is dissension; decisions ideally by consensus with a detailed vote record when necessary
  • Not letting committee members dominate the conversation or speak out of turn; asking speakers to clarify whether they are in favor of or against the motion; clarifying whether a member is contributing new insights or echoing another's thoughts; focusing on the specific discussion and who supports or opposes
  • The chairperson not dominating; guiding conversation through selection of speakers, asking probing and clarifying questions and contributing or highlighting commentary as necessary
  • Straw poll identifying those in favor and those who can live with the motion; attendees who cannot live with the motion asked to offer an alternative solution serving the goals of all parties, keeping attendees accountable for problem solving
  • Nearly 72% of IT organizations having steering committees; IT steering committees ranking first as the most mature IT management practice of 15 practices studied
  • Steering committee defined as an advisory committee usually made up of high-level stakeholders or experts providing guidance on key issues such as company policy and objectives, budgetary control, marketing strategy, resource allocation and decisions involving large expenditures; best-practice approach for aligning strategic business and IT priorities; usually including executives and department heads; focused on IT strategic planning, project prioritization and project approval; clear mandates and real ability to influence decision making through executive participation increasing value
  • Four CIO strategies: create a committee charter including desired outcomes to clarify role and purpose, promote improved communication and recognize the partnership required for successful IT deployment; establish a scope reflecting a corporate-wide perspective helpful when mediating conflicts in priorities or departmental perspectives; indicate the specific level of authority and role in decision making, e.g. a coordinating body resolving priorities, endorsing proposals prior to approvals and monitoring progress but with no role in budget approval or departmental expenditure decisions; designate someone other than the CIO, such as the COO, CMIO or CFO, to chair, communicating that IT is accepted as a critical resource
  • Three steps to form an effective committee: develop a case aligning IT priorities with strategic business priorities, focusing on core IT strategic objectives rather than IT resource allocation, stressing shared decision making and fostering a culture of communication between business units; develop a steering committee charter outlining key tasks and responsibilities; keep the committee small with regular meetings and membership consistently informed, engaged as needed based on project scope and timelines, and including executive decision-making authority
  • IT steering committees as a proven method of driving better IT and business alignment, most effective in IT governance, strategic planning, project prioritization and project approval
Read the original source

Consulting Services

Consulting services are frequently purchased when personnel resources are in short supply or when a specific skill is lacking within the organization. Most frequently, an organization goes to the outside to facilitate a large initiative when internal resources cannot be spared. It is possible to retain professional services on an issue-by-issue basis or to keep a firm on retainer. Additionally, an organization could supply in-house consultation as a means of managing, staffing, or advising on any manner of need.

In-house consultation can be provided by individuals on an as-needed basis, but larger organizations are beginning to implement a PMO.20 The IT and facility/plant management departments and staff often have the greatest depth of experience in managing large and complex projects at any organization, and the PMO may grow out of one or both of those areas. The PMO has personnel who are trained or certified in project management methodology as sponsored by the globally recognized Project Management Institute, Inc (PMI).21

Staff of the PMO are skilled at meeting with operational personnel to understand the detailed requirements of the project at hand and translate those requirements into a plan for execution. They understand the processes of resource gathering, project planning and project scope management, as well as the tools for visualizing the life of the project. They have the skills to manage development of the project's pro forma financial statements and the ongoing project budget. As the organization moves from IT projects to strategic operational projects with IT components, the IT project leaders can begin to alter their focus from operational leadership to true project management.

IT leaders may also serve as the voice of internal expertise. As departments throughout the healthcare organization begin to automate, they may need guidance or advice as to how to incorporate technologies into their workflow. The IT leaders or the PMO can provide innovation support to explore existing technologies to implement or watch for these departments. Partnership between the operational and technology experts creates an opportunity for innovation

Preparing and Delivering Business Communications

It is critical for leaders and managers to possess excellent written and verbal communication skills, and to have the ability to organize and manage business meetings. Organized meeting preparation helps the attendees to understand the goals and objectives of the meeting and the importance of the time invested. Well-prepared documents outline the topics and time to be spent on each issue.

A meeting agenda template for all meetings and minutes of the meeting will help meeting facilitators. Use of these tools creates a uniform method of communication that allows the staff to learn how to identify issues, actions and decisions in a consistent way. Variations in templates and formatting add a level of complexity for the meeting attendees and customers.

The agenda template in Figure 9.3 starts with the organization's name and the committee's name. Each header defines the section to follow. “Meeting Information” states the date, time and location of the meeting, while the subsequent section, “Attendees,” lays out the expected participants and the roles they will play. The agenda itself lists each of the discussion points, the expected outcomes, the parties responsible to lead the discussion and the time limit for the presentation, discussion and decision, if necessary.

The “Committee Action Items” and “Committee Action Register” sections list the pending actions from the most recent meeting and other prior meetings, respectively. These sections enable all parties to have a comprehensive understanding of the status of all action items that remain open. Lacking those sections, it would be easy for a busy committee to lose track of items that have lower levels of priority than others do. It is acceptable to push back the date of some deliverables, but those changes should be made in a transparent way with the support of the committee.

The remaining sections of the agenda keep a record of actions and issues that are yet to be resolved. “Open Issues” lists items that were not completed by the desired action during the previous scheduled meeting. Any item that has been tabled will be left in the “Open Issues” section. “New Issues” serves as a tracking section for the meeting record keeper and the chair. This location is used to add issues that will need attention or completion in the time between meetings.

Presentation skills help define a leader. Leaders must speak clearly and with authority. First, let the audience know the purpose and the desired outcome of your presentation. Is the purpose to inform or to have an action result from the materials presented? During the presentation, include all the information that attendees need to understand, but highlight the key points rather than every detail. In closing restate, both the purpose and the desired outcome and address any questions or concerns, as this prevents disruption and loss of continuity during the presentation.

Project plans and status reports are important tools for everyone from executive leadership to project managers and staff. Figure 9.4 shows an example of a project status report for an organization's electronic health record (EHR) implementation. Like other communications, status documents need to provide an initial brief summary and follow with necessary supporting documentation. For project communications, the timeline and the completion status are the best first materials for review. In a project status report, a color-coded summary of tasks and status provides valuable visual clues. Use of arrows also provides quick indicators of the general direction of the elements compared to their immediately preceding status. Keep the reports simple by using red, yellow and green to identify tasks that are out of compliance, at risk or on track, respectively. Status reports need only be a single page with a table of color-coded tasks, a summary of the issues, the responsible parties for each task and the estimated date of resolution or completion.

Facilitating Group Discussions and Committee Meetings

It is important for a leader to facilitate conversations and it is equally important for a leader to guide a group through difficult discussions. This differs somewhat from a typical business meeting. Knowing the issues, controversies and positions of meeting participants helps to manage the discussion. Construct meeting agendas with consideration for the time it will take to resolve issues and keep controversial decisions at the top of the agenda or as the sole item so there will be adequate time for discussion and resolution. If able, meet with key committee members in advance and begin a process of negotiation and education.

Complex decisions and controversial topics can make meeting management a challenge. Become familiar with Robert's Rules of Order22 and define the expected rules of participation with committee members at the formation of the committee or at the beginning of any particularly challenging meeting in which you might anticipate conflict or debate. Keep a record of all motions and seconds. Record the essence of key discussions, including the names of participants when there is dissension. Ideally, decisions will be arrived at by consensus, but when necessary, keep a detailed record of the vote. As the discussion leader, do not let any committee members dominate the conversation, especially if they do not wait their turn in the queue. Ask speakers to clarify whether they are speaking in favor of or against the motion at hand. Do not hesitate to clarify whether a member is contributing new insights to the discussion or just echoing another's thoughts. In the interest of time, the focus needs to be on the specific discussion and who supports or does not support the topic.

The committee chairperson must not dominate the conversation. The chair carefully guides the conversation through the selection of speakers, asks probing and clarifying questions and contributes or highlights commentary as necessary. Use the straw poll as a tool. Identify those in favor of a motion and those who can live with the motion. If some attendees cannot live with the motion as stated, they should be asked to offer an alternative solution that serves the goals of all parties at the table. This keeps attendees accountable for problem solving.

Steering Committee Meetings

In today's complex healthcare environment, steering committees are essential in providing guidance and practical direction for IT project and operational initiatives. According to the Computer Economics IT Steering Committee Adoption and Best Practices 2017 study, nearly 72% of all IT organizations have steering committees.23 The use of IT steering committees ranks first as the most mature IT management practice out of 15 practices covered in the study.

A steering committee is defined as an advisory committee, usually made up of high-level stakeholders or experts, which provides guidance on key issues such as company policy and objectives, budgetary control, marketing strategy, resource allocation and decisions involving large expenditures.24 IT steering committees are a best-practice approach in healthcare organizations for aligning strategic business and IT priorities. Steering committees, which usually include executives and department heads, focus on three main tasks: IT strategic planning, project prioritization and project approval. Clear mandates and a real ability to influence decision making through executive participation increase the value of IT steering committees.

To ensure success in this important area of IT governance, healthcare CIOs should consider adopting four strategies:

Create a committee charter that includes the desired outcomes. This should help everyone understand the role and purpose of the group, which includes promoting improved communication and recognizing the partnership required for a successful IT deployment.

Establish a scope that reflects a corporate-wide perspective. The broader focus will be helpful when mediating conflicts in priorities or departmental perspectives that may not be in the best interest of the entire organization.

Consider indicating the specific level of authority of this group and its role in decision making. For example, the committee may be identified as a coordinating body that will resolve priorities, endorse proposals prior to approvals and monitor progress of major IT initiatives, but will have no role in budget approval or other departmental expenditure decisions.

Designate someone other than the CIO to chair the IT steering committee. Assigning a non-IT person, such as the chief operating officer (COO), chief medical information officer (CMIO), or chief finance officer (CFO), to chair the group communicates the message that IT is accepted as a critical resource and recognized as such by the entire organization.

To form an effective IT steering committee and keep it on track, three important steps should be considered25:

It is important to develop a case by aligning IT priorities with strategic business priorities. Focus on core IT strategic objectives and not IT resource allocation. In addition, stress shared decision making and foster a culture of communication between business units.

Develop a steering committee charter. It should outline the key tasks and responsibilities of the committee.

Keep the IT steering committee small and schedule regular meetings. Ensuring the membership is consistently informed, engaged as often as needed based on the project scope and timelines and includes executive decision-making authority, is critical to the success of the IT steering committee.

The use of IT steering committees is a proven method of driving better IT and business alignment. It is most effective in the area of IT governance, strategic planning, project prioritization and project approval. By developing an IT steering committee that has clear objectives, strong executive participation and a commitment to meeting regularly, IT leaders can significantly improve the value of IT to the organization.

Chapter 9 · Source: Managing Risk; Financial Risk Management; Budget Risk Management

L9.7 · Managing Risk, Financial Risk and Budgets

Walkthrough

The two dimensions of risk

A key piece of the IT planning process integrates with the organizational efforts to manage risk. Issues of risk can be addressed along two dimensions:

  1. Magnitude of riskif the event does occur, how big of an impact will it have on the organization, process or project?
  2. Likelihood of the riskwhat is the best estimate of the likelihood that the risk event will in fact occur?

Within each dimension, the risk is low, medium or high and assigned a point value of 1 to 3, respectively. The values of each pair of dimensions are multiplied to generate a numeric score. A score of 1 is the lowest risk, while a score of 9 indicates the greatest risk. Color-coding the scores highlights the degree of risk being borne.

Organizations' risk management strategies will vary depending on their tolerance for risk. Typically, scores of 6 or higher will warrant the creation of a contingency plan.

A contingency plan is an alternative path, project or process that would be considered if the primary path is disrupted.

The source's example: a backup plan to print and distribute paper reports if the electronic distribution process is disrupted for longer than a preset amount of time. Within any one very large project, there are likely to be multiple smaller contingency plans.

Risk management and business continuity planning are taking on great prominence in healthcare. Leaders have the responsibility to bring to light the full effects of system loss and the costs associated with mitigating those risks. The solutions are often expensive and will create considerable conversation, especially around the likelihood of any event happening.

Risk mitigation. Once a risk has been identified, a plan for risk mitigation is the next logical step. Risk mitigation helps the organization understand the risk and guides the organization to take steps to prevent a disaster. Risk mitigation should be applied to situations where both internal and external customers are involved. To mitigate internal customer risk, you might use a more collaborative approach, whereas to mitigate risk for an external customer, the process may be a bit more formal. The source's example: if the quality department identifies a risk, they typically work with the internal departments to prevent problems. If an external entity, a vendor for example, creates risk, then an organization must mitigate risk contractually or halt relations with the vendor.

The four components of risk management

Enterprise risk management (ERM) is a proven methodology that organizations use to manage overall risk. While ERM has been used to address clinical, human resource and legal risks in the hospital setting, it has not been frequently applied to financial risk management — possibly due to the complex and highly specialized nature of the tax-exempt capital markets.

Despite its complexity, financial risk can be handled in the same four steps as other forms of risk:

  1. Identificationlisting financial risks that can occur as a result of either negative factors or favorable events (e.g. when unexpected success leads to exponentially increased demand for services)
  2. Quantificationassessing the likelihood or probability a risk-related event will occur and the magnitude of its impact
  3. Risk responsedetermination and implementation of a response to the risk, such as acceptance, transference, mitigation or avoidance
  4. Monitoringcontinuous review of existing and future risks

These four components are the exam's canonical risk management list. Note two details:

  • Identification includes risks arising from favorable events, not only negative ones — unexpected success creating demand you cannot meet is a named example.
  • Monitoring is the fourth component, so after a risk has been identified, quantified and responded to, the remaining obligation is continuous review — the response does not close the risk.

Risk response options are four: acceptance, transference, mitigation and avoidance. (Chapter 8 offered only two — no action or mitigate — within its vulnerability remediation frame. Chapter 9's list is the fuller one.)

Core financial skills needed to reduce IT investment risk: budgeting and planning; financial purchasing options such as capitalized and depreciated assets; operating expenses; basic accounting principles and standards; financial models and methods; and compliance regulations.

Methods and tools: return on investment calculations, budget-tracking tools, revenue creation reports, monthly financial reports and variances, technology pilots where available, SLAs to improve vendor performance and soliciting buy-in for IT initiatives from business and clinical unit executives.

Budget risk management

Managing budgets is one of the basic disciplines that all managers must master. An organized approach to developing and maintaining the budget will go a long way in helping reduce risks. To prepare for the possibility that some risks will not be managed successfully, a risk contingency budget should be created. Funds from the risk contingency budget can then be used to prevent a project from going over budget.

Capital vs. operating expenditure:

Capital expendituresOperating expenditures
WhatPayments by the organization for fixed assets, such as buildings and equipmentIncurred in the course of ongoing, day-to-day business activitiesrent, utilities, salaries and benefits, training, software maintenance fees and telecommunications
Useful lifeMore than one yearOne year or less
DepreciationTypically depreciatedNot depreciated

The long-range capital plan, which covers five years or more, should be the result of an executive review process that determines the proper mix of existing assets and new investments needed to fulfill the organization's mission, goals and objectives, and should reflect the priorities for the year.

Other budget practices: understanding the annual budget cycle, particularly in avoiding the fiscal year-end crises; accurately assessing business requirements for expenses; developing the budget in detail at the line-item level; using a consistent model or software system; paying attention to contracts and maintenance fee increases and adjusting and reforecasting expenditures; maintaining multiple budget scenarios for times when revenue is low, when critical enhancements are made or when revenue-generating projects are planned.

The six important steps when managing budgets:

  1. Negotiate an effective budget to start withspending the necessary time at the beginning of a project will eliminate budget challenges later
  2. Plan for unexpected expensesallowing flexibility should unforeseen expenses arise
  3. Prepare early for year-end budget activitiesfinalizing budgets at the end of the fiscal year is important and time-consuming
  4. Stay close to budgetavoid being significantly over or under budget, as this will affect the following year's budget allocations
  5. Account for cost allocationsidentify charges or transfers that may occur to or from other departments
  6. Understand the key budget numbersknow all the critical numbers for your department and be aware if any of the numbers are wrong

Point 4 is counterintuitive and therefore testable: being significantly UNDER budget is also a problem, because it affects next year's allocation.

Big picture

Two named lists carry this lesson: the four risk management components (identification, quantification, risk response, monitoring) and the six budget steps.

The conceptual point worth holding is that risk work does not end at the response. Monitoring is a component, not an afterthought — which is why a stem describing a risk that has been identified, quantified and responded to is asking about continuous review.

Where it fits: Chapter 8's risk assessment and mitigation process is the security-specific version of this; Chapter 5's business continuity planning is where high-scoring risks end up.

Key concepts

The two risk dimensions

In plain English: How bad, and how likely.

Technical meaning: Magnitude of risk (impact on the organization, process or project if the event occurs) and likelihood (best estimate that the event will occur); each scored low, medium or high as 1 to 3, multiplied to give a score from 1 to 9.

Picture it: Scores of 6 or higher typically warrant a contingency plan.

The four risk management components

In plain English: Find it, size it, decide what to do, keep watching.

Technical meaning: Identification (listing financial risks arising from negative factors or favorable events); quantification (likelihood or probability plus magnitude of impact); risk response (acceptance, transference, mitigation or avoidance); monitoring (continuous review of existing and future risks).

Picture it: After identify, quantify and respond, the remaining obligation is monitoring.

Contingency plan

In plain English: The alternative route if the main one is blocked.

Technical meaning: An alternative path, project or process considered if the primary path is disrupted — for example printing and distributing paper reports if electronic distribution fails beyond a preset time.

Picture it: One large project can carry many small contingency plans.

Capital vs. operating expenditure

In plain English: Things you own for years, versus what it costs to run.

Technical meaning: Capital expenditures buy fixed assets with a useful life over one year and are typically depreciated; operating expenditures cover day-to-day activity — rent, utilities, salaries and benefits, training, software maintenance fees, telecommunications — with a useful life of one year or less and no depreciation.

Picture it: Software maintenance fees are operating, not capital.

Risk contingency budget

In plain English: Money set aside for the risks you didn't stop.

Technical meaning: Created to prepare for the possibility that some risks will not be managed successfully; funds can be used to prevent a project from going over budget.

Picture it: Distinct from planning for unexpected expenses generally — this one is tied to identified risks.

Real-world examples

A risk scores high impact (3) and medium likelihood (2) for a total of 6. That crosses the source's threshold, so a contingency plan is created — not just a note in the risk register.

A department finishes the year 18% under budget. Under the source's guidance that is a problem, because it affects the following year's allocation.

Distinctions & exam traps

EXAM TRAP · The four risk components

The tempting confusion: Lists substituting 'elimination', 'reporting' or 'transfer' for one of the four.

The deciding clue: Identification, quantification, risk response, monitoring. Transference is one of the response options, not a component.

Stem wording that triggers it: One altered element in a four-item list. (One altered element.)

EXAM TRAP · What remains after a response is implemented

The tempting confusion: Treating the risk as closed once mitigated.

The deciding clue: Monitoring is continuous review of existing and future risks.

Stem wording that triggers it: 'Remaining obligation' after identify, quantify and respond names monitoring. (Plausible-but-upstream.)

EXAM TRAP · Quantification vs. identification

The tempting confusion: Both are early risk activities.

The deciding clue: Identification lists the risks. Quantification assesses likelihood or probability and the magnitude of impact.

Stem wording that triggers it: 'Assessing the likelihood and the magnitude of its impact' names quantification. (Adjacent term.)

EXAM TRAP · Being under budget

The tempting confusion: Assuming underspending is always favourable.

The deciding clue: Stay close to budget; avoid being significantly over or under, as this affects the following year's allocations.

Stem wording that triggers it: Both directions are named. (One altered element.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Name the two risk dimensions and explain how the 1-to-9 score is produced and what threshold triggers a contingency plan.
  2. Recite the four risk management components and the four risk response options.
  3. Distinguish capital from operating expenditure with three examples of each.
  4. Give the six budget management steps and explain why being under budget is a problem.

Questions

5 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • IT planning integrating with organizational risk management; two dimensions of magnitude (impact on organization, process or project if the event occurs) and likelihood (best estimate the risk event will occur); each low, medium or high with point values 1 to 3; values multiplied to generate a score from 1 (lowest) to 9 (greatest); color-coding highlighting the degree of risk borne
  • Risk management strategies varying with risk tolerance; scores of 6 or higher typically warranting a contingency plan; contingency plan as an alternative path, project or process considered if the primary path is disrupted; paper report distribution example when electronic distribution is disrupted beyond a preset time; multiple smaller contingency plans within one large project
  • Risk management and business continuity planning taking on great prominence; leaders responsible for bringing to light the full effects of system loss and mitigation costs; solutions often expensive and creating considerable conversation about likelihood
  • Risk mitigation as the next logical step after identification; helping the organization understand the risk and take steps to prevent a disaster; applied where internal and external customers are involved; collaborative approach for internal customers and more formal for external; quality department working with internal departments; contractual mitigation or halting relations where a vendor creates risk
  • Enterprise risk management as a proven methodology for overall risk; used for clinical, human resource and legal risks but not frequently applied to financial risk management, possibly due to the complex and specialized nature of tax-exempt capital markets
  • Four risk steps: identification (listing financial risks from negative factors or favorable events such as unexpected success increasing demand for services); quantification (assessing likelihood or probability of occurrence and magnitude of impact); risk response (determination and implementation of a response such as acceptance, transference, mitigation or avoidance); monitoring (continuous review of existing and future risks)
  • Core financial skills for reducing IT investment risk: budgeting and planning; financial purchasing options such as capitalized and depreciated assets; operating expenses; basic accounting principles and standards; financial models and methods; compliance regulations
  • Methods and tools: return on investment calculations, budget-tracking tools, revenue creation reports, monthly financial reports and variances, technology pilots where available, SLAs to improve vendor performance, and soliciting buy-in for IT initiatives from business and clinical unit executives to minimize procurement risks
  • Managing budgets as a basic discipline; organized approach to developing and maintaining the budget reducing risks; risk contingency budget created for risks not managed successfully, with funds used to prevent a project going over budget
  • Solid budgeting and forecasting skills critical; understanding the annual budget cycle particularly to avoid fiscal year-end crises; accurately assessing business requirements for expenses; developing the budget in detail at the line-item level; differentiating capital and operating expenditures; identifying long-range capital planning
  • Capital expenditures as payments for fixed assets such as buildings and equipment, incurred when buying assets with a useful life of more than one year and typically depreciated; long-range capital plan covering five years or more resulting from an executive review process determining the proper mix of existing assets and new investments to fulfill mission, goals and objectives and reflecting the year's priorities
  • Operating expenditures incurred in ongoing day-to-day business activities including rent, utilities, salaries and benefits, training, software maintenance fees and telecommunications; relating to items with a useful life of one year or less and not depreciated
  • Consistent model or software system for managing the budget; addressing budget risk by attention to contracts and maintenance fee increases and by adjusting and reforecasting expenditures; maintaining multiple budget scenarios for low revenue, critical enhancements or planned revenue-generating projects
  • Six budget steps: negotiate an effective budget to start with, since time at the beginning eliminates later challenges; plan for unexpected expenses allowing flexibility; prepare early for year-end budget activities; stay close to budget avoiding significantly over or under, which affects the following year's allocations; account for cost allocations identifying charges or transfers to or from other departments; understand the key budget numbers and be aware if any are wrong
Read the original source

Managing Risk

A key piece of the IT planning process integrates with the organizational efforts to manage risk. Issues of risk can be addressed along two dimensions. The first is magnitude of risk: If the event does occur, how big of an impact will it have on the organization, process or project? The second dimension is the likelihood of the risk: What is the best estimate of the likelihood that the risk event will in fact occur? Within each dimension, the risk is low, medium or high and assigned a point value of 1 to 3, respectively.

The tool shown in Figure 9.5 depicts these two dimensions in a matrix. The values of each pair of dimensions are multiplied to generate a numeric score. A score of 1 is the lowest risk, while a score of 9 indicates the greatest risk. Color-coding the scores highlights the degree of risk being borne.

Organizations’ risk management strategies will vary depending on their tolerance for risk. Typically, scores of 6 or higher will warrant the creation of a contingency plan. A contingency plan is an alternative path, project or process that would be considered if the primary path is disrupted. A simple example would be a backup plan to print and distribute paper reports if the electronic distribution process is disrupted for longer than a preset amount of time. Within any one very large project, there are likely to be multiple smaller contingency plans to account for any individual event that may occur.

Risk management and business continuity planning are taking on great prominence in healthcare. Leaders have the responsibility to bring to light the full effects of system loss and the costs associated with mitigating those risks. The solutions are often expensive and will create considerable conversation, especially around the likelihood of any event happening.

Once a risk has been identified, a plan for risk mitigation is the next logical step. Risk mitigation helps the organization understand the risk and guides the organization to take steps to prevent a disaster. Risk mitigation should be applied to situations where both internal and external customers are involved. To mitigate internal customer risk, you might use a more collaborative approach, whereas to mitigate risk for an external customer, the process may be a bit more formal. For example, if the quality department identifies a risk, they typically work with the internal departments to prevent problems. If an external entity, a vendor for example, creates risk, then an organization must mitigate risk contractually or halt relations with the vendor.

Financial Risk Management

It is important for healthcare organizations to make sound decisions in order to manage financial and budget risks. Without a solid understanding of financial risks and their impact, they cannot be expected to make the right decisions about their capital and operating investments. The fundamental idea behind managing financial risk in healthcare is to reduce and protect against the inherent unpredictability of future costs.

Enterprise risk management (ERM) is a proven methodology that organizations use to manage overall risk. While ERM has been used to address clinical, human resource and legal risks in the hospital setting, it has not been frequently applied to financial risk management. This could be due to the complex and highly specialized nature of the tax-exempt capital markets, which can be intimidating to many risk management professionals. Despite its complexity, financial risk can be handled in the same four steps as other forms of risk:

Identification—Listing financial risks that can occur as a result of either negative factors or favorable events (e.g., when unexpected success leads to exponentially increased demand for services)

Quantification—Assessing the likelihood or probability a risk-related event will occur and the magnitude of its impact

Risk response—Determination and implementation of a response to the risk, such as acceptance, transference, mitigation or avoidance

Monitoring—Continuous review of existing and future risks

Core financial skills are needed to reduce the risks associated with IT investments. Today's IT professionals should be knowledgeable about budgeting and planning; financial purchasing options, such as capitalized and depreciated assets; operating expenses; basic accounting principles and standards; financial models and methods; and compliance regulations. In addition, the IT professional should use a broad range of methods and tools, such as return on investment (ROI) calculations, budget-tracking tools, revenue creation reports, monthly financial reports and variances, technology pilots where available, SLAs to improve vendor performance and soliciting buy-in for IT initiatives from business and clinical unit executives to minimize and reduce IT procurement risks.

Budget Risk Management

Managing budgets is one of the basic disciplines that all managers must master. An organized approach to developing and maintaining the budget will go a long way in helping reduce risks. In addition, to prepare for the possibility that some risks will not be managed successfully, a risk contingency budget should be created. Funds from the risk contingency budget can then be used to prevent a project from going over budget.

For today's IT managers, having solid budgeting and forecasting skills is critical in reducing budget risk. Understanding the annual budget cycle is important, particularly in avoiding the fiscal year-end crises that often occur as organizations attempt to balance their budgets. The business requirements for expenses should be accurately assessed. The budget should be developed in detail. At the line-item level, capital and operating expenditures should be differentiated and long-range capital planning should be identified. Capital expenditures are payments by the organization for fixed assets, such as buildings and equipment. Capital expenses are incurred when a company buys assets that have a useful life of more than one year and are typically depreciated. The long-range capital plan, which covers five years or more, should be the result of an executive review process that determines the proper mix of existing assets and new investments needed to fulfill the healthcare organization's mission, goals and objectives, and should reflect the priorities for the year. Operating expenditures are incurred in the course of ongoing, day-to-day business activities and include payments for rent, utilities, salaries and benefits, training, software maintenance fees and telecommunications. Operating expenses relate to items that have a useful life of one year or less and are not depreciated.

It is important for a consistent model or software system to be used to manage the budget. Budget risk can be addressed by paying attention to contracts and maintenance fee increases and by adjusting and reforecasting the expenditures. Healthcare organizations may be required to make budget reductions; therefore, maintaining multiple budget scenarios is important. These can be reserved for times when revenue is low, when critical enhancements are made or when revenue-generating projects are planned.

The following important steps should be considered when managing budgets26:

Negotiate an effective budget to start with. Spending the necessary time at the beginning of a project will eliminate budget challenges later in the project schedule.

Plan for unexpected expenses. This will allow for flexibility should unforeseen expenses arise.

Prepare early for year-end budget activities. Finalizing budgets at the end of the fiscal year is an important and time-consuming activity. It is best to start planning for this early or on an ongoing basis.

Stay close to budget. Attempt to finish as close to budget expectations as possible and avoid being significantly over or under budget, as this will affect the following year's budget allocations.

Account for cost allocations. Identify charges or transfers that may occur to or from other departments to your department.

Understand the key budget numbers. Know all the critical numbers for your department and be aware if any of the numbers are wrong.

Chapter 9 · Source: Roles and Responsibilities for IT-Related Functions; Staff Competency; Employee Development; Performance Evaluation; Developing Educational Strategies for IT Staff; Current IT Technologies and Trends; System, Operational and Department Documentation

L9.8 · Roles, Staff Competency, Educational Strategies, Change Management and Documentation

Walkthrough

Roles and responsibilities

Healthcare IT is the area of IT involving the design, development, creation, use and maintenance of information systems for the healthcare industry. It includes electronic coding, accounting and billing systems; EMRs or EHRs; clinical or departmental applications such as lab, radiology, pharmacy and nutrition; support for ancillary systems such as cardiology and radiology; and practice management systems in the ambulatory space handling appointment scheduling, billing and patient follow up.

IT-related careers in healthcare are found in hospitals, physician clinics, payer organizations, HIEs, community health centers, long-term care, ambulatory surgery centers, plus educational institutions, academic medical centers, government agencies, the military, vendor organizations and consulting companies.

Senior management roles. Board of director, executive management and medical executive committee support are essential. The CIO is generally the most senior-level IT executive, often also carrying vice president or senior vice president designation. Additional IT executive leadership roles: CMIO, chief nursing information officer (CNIO), CTO, CISO, chief health information officer (CHIO) and chief pharmacy information officer (CPIO). Second-level leadership typically entails IT department directors, clinical informaticists and physician and nurse champions. Recently, health systems have developed new roles such as chief innovation officer, chief applications officer, chief digital officer, chief experience officer, chief business development officer and chief privacy officer.

General IT roles are categorized as senior level, midlevel and entry level with titles such as director, manager, architect, analyst, engineer, technician, administrator, programmer and developer. Common responsibility areas divide into three major sections:

  • The infrastructure teamthe data center, IT helpdesk, communications, database administration, backups, network support and IT security
  • The business groupapplications supporting human resources, payroll, supply chain, finance, marketing and web development
  • Clinical applications teamsEHRs and all clinical ancillary applications

Technical integration teams support interfaces between all types of systems.

Healthcare IT roles. In-demand clinical and business positions are analyst roles covering all categories of applications, administrative services, customer support, workflow analysis and configuration. Others: informatics, clinical engineering, go-live events, implementation consulting, integration, project management, quality assurance, usability and human factors analysis. Trainers are crucial for all personnel and all applications. Change management, transformation and IT communications teams are also becoming more common.

Defining roles, responsibilities and job descriptions primarily enables clear accountability and appropriate skill matching across these functions.

Staff competency and employee development

Some applications require professional certification in order to perform configuration within. A solid plan for team development can reduce turnover and increase employee satisfaction.

Employee development is a key component in ensuring healthcare IT staff attain the necessary competency. Mastering those skills, along with developing the soft skills needed to collaborate and work together as a team, is essential.

Delivery methods: training and in-service programs, certification classes, community college or university educational courses, conferences and workshops, professional association involvement and self-study through books, industry magazines, videos and online resources. Effective leaders also provide opportunities for employees to mentor others or ask senior colleagues for mentorship. Shadowing an executive for a day can be an enriching experience. It is common practice to implement goals during the annual review process; adding a "stretch" goal takes someone out of their comfort zone and gives the individual the opportunity to grow and learn.

Sources of training: human resources typically has responsibility for organization-wide training requirements (security and safety regulations, discriminatory practice and quality improvements); supervisory, management and leadership development may be designed by a leadership department or HR; the employee's own department provides in-service or online training; and IT projects usually include a training budget for system developers, administrators and end users.

Certifications have two main advantages: they provide a framework by which technical staff can learn and gain a level of proficiency in a specific IT-related topic, and they provide a credential showing a defined body of knowledge in a specific area. A certification by itself will not qualify a person for a new job or promotion, but it does demonstrate mastery and is often viewed as a positive contributing factor in hiring decisions. Clinicians should keep clinical licensure and certifications active even if no longer in a clinical role.

CPHIMS is described as an essential credential for all healthcare IT management, management engineering and process improvement professionals, military personnel and consultants, developed and sponsored through HIMSS, demonstrating an international standard of professional knowledge and competence in healthcare information and management systems. CAHIMS allows those who do not qualify for CPHIMS eligibility to demonstrate their professional knowledge.

Other named certifications: PMP, ITIL and Lean Six Sigma, plus ADKAR Change Management certification (a three-day course or a condensed one-day course).

Change management — ADKAR

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.

The five elements: Awareness, Desire, Knowledge, Ability, Reinforcement.

The diagnostic use is the exam's angle. Each letter fails differently:

  • No Awareness — people do not know why it is happening
  • No Desire — they know why and do not want it
  • No Knowledge — they want to but do not know how
  • No Ability — they know how but cannot yet do it in practice
  • No Reinforcementthey can do it and revert to old workarounds after a month

Staff who understand a new system, can use it, and then revert are a Reinforcement failure. Knowledge and Ability are present; what is missing is the reinforcement of why the change occurred and the importance of keeping it in place.

Performance evaluation

Performance evaluation is the ongoing process in which employees' work, outcomes, attitudes and interpersonal skills, professional growth and adherence to organizational values are assessed and feedback is provided. The employee's actual performance is compared against the expected performance.
  • To be effective and objective, the process must start with specific and measurable performance goals, defined and communicated to the employee at the start of the year.
  • The most common method is the rating scale, specifying personal traits and behaviors expected — teamwork, communication skills, adherence to values, dependability and initiative — and specific job attributes such as quality and quantity of work, each accompanied by a range of numbers and words the evaluator marks.
  • The 360-degree method asks other individuals to rate the employeeteammates, subordinates, peers in the same department, employees in other departments and sometimes outside customers and vendors — with the employee also given the opportunity to perform a self-assessment, and confidentiality provided to the raters.
  • Feedback must be provided at regular intervals during the year. Employees should never be surprised during a formal appraisal. Sub-par performance should be dealt with as soon as it is identified. Interim positive feedback helps preserve excellent performance. It is advisable to complete a formal, written interim review if performance requires improvement.
  • Disciplinary action must be based on clear facts with documented justification and done progressively over timestarting with verbal discussions, then written and verbal communication and possibly ending with terminationcommunicating with and seeking advice from human resources at all steps.

Note what the evaluation covers: work, outcomes, attitudes and interpersonal skills, professional growth and adherence to organizational values. An analyst who meets every deadline but cannot explain technical decisions to clinicians has a genuine, evaluable competency gap on the interpersonal and communication dimension.

Educational strategies for IT staff

Staff will continue to gain experience as they do their jobs, but there is very little opportunity for them to continue their education and expand their knowledge unless someone creates opportunities for them.

  • At the very least, education needs to be valued. Commit to the time and to supporting the cost.
  • Encourage staff to broaden their skills by taking opportunities to stretch their current skills or cross-train in areas beyond their current experiences.
  • When it becomes tempting to reduce costs by eliminating educational support, also consider how much it will cost to recruit new staff and whether the skills sought are those the current staff may be lacking.
  • Low-cost opportunities: sign staff up as members of all vendor user groups, locally and nationally; professional societies, interest groups and local educational opportunities; local presentations and educational dinner meetings; professional associations like HIMSS offering local and global membership with education often free and in multiple media formats — in person, webcasting, webinars and other telecasting options; free vendor educational opportunities.
  • When funds are available, have staff take turns attending vendors' user conferences or professional society conferences so staff members can attend every couple of years. Ask those who go to explore specific sessions of interest to the whole organization, and on return arrange a team luncheon at which that person reports on information learned and shares materials. Most societies and large user groups make conference presentations available online.
  • Succession planning is an important part of the overall IT planning process.

Educational strategy should be driven by the competencies the organization needs — the gap between current skills and required skills — which is why the source ties it to recruitment cost and to skills the current staff may be lacking.

Current IT technologies and trends

Team members need to stay connected to a variety of disciplines related to their specific sphere of expertise. The greatest opportunity for this added education comes from within the organization itselflisten to the feedback of colleagues and peers, be engaged and ask questions.

Outside your own colleagues, a valuable educational resource is the media and printed press. The Guardian, Healthcare IT News, People's Daily and the Wall Street Journal are often the first to pick up on and report trends or activities that have national or international significance. Organizational leaders will be regularly asked to comment on materials in those publications. Many publications offer really simple syndication (RSS) or other services that will e-mail headlines or article titles aligned with subjects of interest. Given the option of being proactive or reactive, a successful leader will choose the former path.

Maintaining competency in current trends is therefore sustained through ongoing, structured engagement — professional associations, user groups, monitored publications and internal peer exchange — not a periodic training event. Failing to maintain awareness risks the organization falling behind on technologies and opportunities its peers are already adopting.

Documentation

With the vast amount of expertise required to manage healthcare applications, it is crucial that teams develop detailed documentation to create a knowledge base for auditing and use by teams.

System documentationdocuments that support analysis, decision making, acquisition and implementation processes; system features and functional and technical requirements; systems analysis documentation covering collecting, organizing and evaluating data about IT system requirements and the environment in which the system will operate; functional requirements, design specifications, requests for information and proposals and related vendor responses; procedure manuals, computer programs and machine operating manuals; details of standards compliance; and records of the initial system testing process and results.

Operational documentationrelates to ongoing systems operations and maintenance; includes ongoing testing of systems and results, audit processes and database management, training manuals, implementation time frames, flowcharts and progress reports, data backup and recovery procedures, and system retirement, tuning and logistic support requirements.

Department documentationdepartment policies and procedures guide the processes and actions employees should use to perform their work and are essential for achieving various accreditations. A 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: (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.

The six steps in developing P&Ps: (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 address: security (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); information retention and availability of medical information; communication of medical information; management of licensed software; handling of service requests; the IT strategic plan; the IT budget; change management, project management and process improvement; development methods and standards; and copyrights and ownership.

Big picture

This closing lesson carries ten items and holds two of the chapter's most reliably tested structures: ADKAR and performance evaluation.

ADKAR rewards diagnostic use rather than recall. The letters describe five different failure modes, and the exam gives you a scenario and asks which one broke. Understand it, can do it, then revert is always Reinforcement.

The other durable idea is that competency is not just technical. Performance evaluation explicitly covers attitudes, interpersonal skills, professional growth and adherence to values — which is why an analyst who hits every deadline but cannot communicate with clinicians has a real, assessable gap.

Where it fits: Chapter 6's change management team and champions are the operational version of what ADKAR models. Chapter 3's informaticist-as-translator is the competency this lesson says to evaluate.

Key concepts

ADKAR

In plain English: Awareness, Desire, Knowledge, Ability, Reinforcement.

Technical meaning: A widely used change model emphasizing 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 the importance of keeping the change in place.

Picture it: Reversion after a month, by people who understand and can use the system, is a Reinforcement failure.

Performance evaluation

In plain English: Comparing actual work against what was expected, with feedback.

Technical meaning: The ongoing process in which employees' work, outcomes, attitudes and interpersonal skills, professional growth and adherence to organizational values are assessed and feedback is provided; actual performance compared against expected performance; requires specific measurable goals defined and communicated at the start of the year.

Picture it: Interpersonal skills are inside the definition, not adjacent to it.

360-degree appraisal

In plain English: Feedback from everyone around the person.

Technical meaning: Raters may include teammates, subordinates, peers in the same department, employees in other departments and sometimes outside customers and vendors; the employee also performs a self-assessment; confidentiality is provided to raters.

Picture it: Self-assessment is part of it, and rater confidentiality is required.

Progressive discipline

In plain English: Escalate in steps, with documentation.

Technical meaning: Based on clear facts with documented justification, done progressively over time — verbal discussions, then written and verbal communication, possibly ending with termination — communicating with and seeking advice from human resources at all steps.

Picture it: Employees should never be surprised at a formal appraisal.

The three documentation types

In plain English: About the system, about running it, about the department.

Technical meaning: System documentation (analysis, decision making, acquisition, implementation, requirements, specifications, RFIs/RFPs and vendor responses, manuals, standards compliance, initial testing records); operational documentation (ongoing testing and results, audit processes, database management, training manuals, timeframes, flowcharts, progress reports, backup and recovery, retirement, tuning, logistic support); department documentation (policies and procedures).

Picture it: Policy = what is expected. Procedure = how it is accomplished.

Real-world examples

Staff attend training, pass competency checks, use the new documentation workflow for three weeks, then quietly return to the old shortcut. Knowledge and Ability were achieved; Reinforcement was not.

An analyst delivers everything on time and cannot explain a configuration decision to a nursing committee. Under the source's definition of performance evaluation, that is a competency gap in interpersonal skills, and it is evaluable.

Distinctions & exam traps

EXAM TRAP · ADKAR diagnosis

The tempting confusion: Choosing Knowledge or Ability for a reversion scenario.

The deciding clue: If staff understand the system and can use it, Knowledge and Ability are satisfied; reverting to old workarounds is a Reinforcement failure.

Stem wording that triggers it: 'Revert after a month' names Reinforcement. (Wrong layer.)

EXAM TRAP · ADKAR expansion

The tempting confusion: Substituting 'action', 'adoption' or 'results' for reinforcement.

The deciding clue: Awareness, desire, knowledge, ability and reinforcement.

Stem wording that triggers it: The fifth letter is the one distractors change. (One altered element.)

EXAM TRAP · Educational strategies EXCEPT

The tempting confusion: A NOT item mixing conferences, user groups, professional associations, cross-training and mentorship with something outside education.

The deciding clue: All named strategies develop staff skills; several are explicitly low-cost.

Stem wording that triggers it: Circle EXCEPT, then find the option that is not a development activity. (Category outlier.)

EXAM TRAP · What drives educational strategy

The tempting confusion: Answering budget availability, vendor offerings, or staff preference.

The deciding clue: Strategy follows the competencies the organization needs — the gap between current and required skills, weighed against recruitment cost.

Stem wording that triggers it: 'Driven primarily by' asks for organizational need. (Plausible-but-upstream.)

EXAM TRAP · Maintaining trend awareness

The tempting confusion: Choosing an annual conference, a single training event, or vendor briefings alone.

The deciding clue: Sustained through ongoing engagement — professional associations, user groups, monitored publications with RSS, and internal peer exchange; proactive rather than reactive.

Stem wording that triggers it: 'Best sustained through' points to ongoing structure. (Wrong layer.)

Optional teach-back

TRY A TEACH-BACK · optional, never tracked

Close the app. Say each one out loud to a colleague who knows healthcare but not health IT, then write it from memory in the notebook. Nothing here is scored, and no answers are supplied on purpose.

  1. Expand ADKAR and give the failure mode for each letter.
  2. Define performance evaluation in the source's terms, and name everything it assesses.
  3. Describe the 360-degree method and say what protections it requires.
  4. Name the three documentation types and give the policy-versus-procedure distinction.

Questions

10 mapped items. Choose an answer, then check it.

Source fidelity

SOURCE FIDELITY

Accounted for from the source section:

  • Healthcare IT as the area involving design, development, creation, use and maintenance of information systems for healthcare; electronic coding, accounting and billing systems; EMRs or EHRs; clinical or departmental applications such as lab, radiology, pharmacy and nutrition; support for ancillary systems such as cardiology and radiology; ambulatory practice management systems handling appointment scheduling, billing and patient follow up
  • IT careers in hospitals, physician clinics, payer organizations, HIEs, community health centers, long-term care, ambulatory surgery centers, educational institutions, academic medical centers, government agencies, the military, vendor organizations and consulting companies; clinical background transition opportunities; HIMSS job descriptions document in the Resource Center
  • Board of director, executive management and medical executive committee support essential; CIO as the most senior-level IT executive, often with vice president or senior vice president designation; additional executive roles of CMIO, CNIO, CTO, CISO, CHIO and CPIO; second-level leadership of IT department directors, clinical informaticists and physician and nurse champions; new roles of chief innovation officer, chief applications officer, chief digital officer, chief experience officer, chief business development officer and chief privacy officer
  • General IT roles staffed by internal FTEs or outsourced staff; job descriptions categorized as senior level, midlevel and entry level with titles including director, manager, architect, analyst, engineer, technician, administrator, programmer and developer; infrastructure team responsible for the data center, IT helpdesk, communications, database administration, backups, network support and IT security; business group managing applications for human resources, payroll, supply chain, finance, marketing and web development; clinical applications teams supporting EHRs and clinical ancillary applications; technical integration teams supporting interfaces between all types of systems
  • Healthcare IT roles requiring a blend of healthcare business, clinical, management and technical experience; in-demand analyst roles covering all categories of applications, administrative services, customer support, workflow analysis and configuration; informatics, clinical engineering, go-live events, implementation consulting, integration, project management, quality assurance, usability and human factors analysis; trainers crucial for all personnel and applications; change management, transformation and IT communications teams becoming more common
  • Professional development, training and competency considerations for supported applications; some applications requiring professional certification for configuration; others requiring one-time certification; solid team development plans reducing turnover and increasing satisfaction
  • Employee development ensuring competency in information and management system tools and skills; soft skills for collaboration and teamwork essential; staff improvement programs providing proficiencies and qualifications for advancement and helping form positive attitudes and interpersonal skills
  • Development through training and in-service programs, certification classes, community college or university courses, conferences and workshops, professional association involvement and self-study through books, industry magazines, videos and online resources; mentoring opportunities and executive shadowing; stretch goals during the annual review process
  • Training sources: human resources for organization-wide requirements such as security and safety regulations, discriminatory practice and quality improvements; leadership department or HR for supervisory, management and leadership development; the employee's department for in-service or online training; IT project training budgets for system developers, administrators and end users
  • Certification advantages: a framework for learning and gaining proficiency in a specific IT-related topic, and a credential showing a defined body of knowledge; certification alone not qualifying a person for a job or promotion but demonstrating mastery and viewed as a positive contributing factor in hiring; clinicians keeping clinical licensure and certifications active; IT professionals keeping in-demand certifications active
  • CPHIMS as an essential credential for healthcare IT management, management engineering and process improvement professionals, military personnel and consultants; developed and sponsored through HIMSS; demonstrating an international standard of professional knowledge and competence; CAHIMS for those not eligible for CPHIMS
  • ADKAR model emphasizing 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 the importance of keeping the change in place; ADKAR Change Management certification via a three-day or condensed one-day course
  • Vendor-specific certifications available only to employees of organizations deploying a specific product; generally available certifications valued including PMP, ITIL and Lean Six Sigma
  • Miscellaneous professional development through healthcare IT conferences and workshops; national and local professional association programs such as HIMSS; university certificate programs and bachelor's, master's and doctorate degrees in healthcare IT, informatics, information management and information systems; self- or group study using books, industry magazines or journals, videos, white papers, webinars, conferences and training; employees typically responsible for costs though many companies pay as a benefit
  • Performance evaluation as the ongoing process in which employees' work, outcomes, attitudes and interpersonal skills, professional growth and adherence to organizational values are assessed and feedback provided; actual performance compared against expected; requiring specific and measurable performance goals defined and communicated at the start of the year
  • Rating scale as the most common method, specifying personal traits and behaviors such as teamwork, communication skills, adherence to values, dependability and initiative, plus job attributes such as quality and quantity of work, each with a range of numbers and words the evaluator marks
  • 360-degree method with raters including teammates, subordinates, peers in the same department, employees in other departments and sometimes outside customers and vendors; employee self-assessment; all assessments considered in the final evaluation; confidentiality provided to raters
  • Regular interim feedback; employees never surprised during a formal appraisal; sub-par performance dealt with as soon as identified; interim positive feedback preserving excellent performance; formal written interim review advisable when performance requires improvement
  • Disciplinary action based on clear facts with documented justification and taken progressively over time — verbal discussions, then written and verbal communication, possibly ending with termination; notes to the personnel record and written warnings with substantive examples; communicating with and seeking advice from human resources at all steps
  • Leaders hired for experiences and skills and selecting staff similarly; little opportunity for continued education unless someone creates it; education needing to be valued with commitment to time and cost; encouraging staff to stretch current skills or cross-train; weighing elimination of educational support against recruitment cost and missing skills
  • Low-cost educational opportunities: membership in all vendor user groups locally and nationally; professional societies, interest groups and local educational opportunities; local presentations and educational dinner meetings; HIMSS local and global membership with free education in multiple media formats including in person, webcasting, webinars and telecasting; free vendor educational opportunities
  • When funds are available, staff taking turns attending vendor user conferences or professional society conferences every couple of years; attendees exploring sessions of interest to the whole organization and reporting back at a team luncheon with shared materials; conference presentations available online; succession planning as part of overall IT planning; investment in education expanding IT staff capabilities
  • Team education extending beyond serviced applications and immediate issues; staying connected to related disciplines; greatest opportunity from within the organization by listening to colleagues and peers and asking questions; overlap of work expanding effectiveness
  • Media and printed press as a valuable educational resource; The Guardian, Healthcare IT News, People's Daily and the Wall Street Journal often first to report nationally or internationally significant trends; leaders regularly asked to comment; RSS or e-mail services delivering headlines aligned with subjects of interest; successful leaders choosing proactive over reactive
  • Detailed documentation creating a knowledge base for auditing and team use; system, operational or departmental in nature; ensuring teams are organized and customers understand the IT process
  • System documentation supporting analysis, decision making, acquisition and implementation; addressing system features and functional and technical requirements; systems analysis documentation covering collecting, organizing and evaluating data about IT system requirements and the operating environment; functional requirements, design specifications, requests for information and proposals and vendor responses; procedure manuals, computer programs and machine operating manuals; details of standards compliance; records of the initial system testing process and results including data collection and input procedures
  • Operational documentation relating to ongoing systems operations and maintenance: ongoing testing of systems and results, audit processes, database management, training manuals, implementation time frames, flowcharts and progress reports, data backup and recovery procedures, and system retirement, tuning and logistic support requirements
  • Department policies and procedures guiding processes and actions and essential for accreditations; policy formalizing what is expected or required of employees; procedure describing how an outcome is accomplished; two purposes of setting performance requirements usable to motivate or discipline employees and serving as ongoing references and orientation documents for new hires
  • Six P&P development steps: identify a need; draft a policy or procedure addressing it; get management approval; distribute the approved document and educate employees on its contents; revise, replace or withdraw as needed; coordinate with human resources, corporate compliance or other areas when applicable
  • Department P&Ps addressing security (access control, entity authentication, audit trails, data encryption, firewall protection, virus checking); privacy protection (access rights definitions and instructions for handling specific information and patients); information retention and availability of medical information; communication of medical information; management of licensed software; handling of service requests; the IT strategic plan and IT budget; change management, project management and process improvement; development methods and standards; copyrights and ownership
Read the original source

Roles and Responsibilities for IT-Related Functions

The increased adoption of technology in healthcare has greatly expanded the role of IT. In addition to traditional IT functions, healthcare IT has created exciting new roles and responsibilities. Healthcare IT is the area of IT involving the design, development, creation, use and maintenance of information systems for the healthcare industry. Healthcare IT includes electronic coding, accounting and billing systems; electronic medical records (EMRs) or EHRs; and clinical or departmental applications, such as lab, radiology, pharmacy and nutrition. It includes support for ancillary systems such as cardiology and radiology. Clinics in the ambulatory space require practice management systems that handle appointment scheduling, billing and patient follow up.

IT-related careers in healthcare can be found in many different types of organizations. These include hospitals, physician clinics, payer organizations, health information exchanges (HIEs), community health centers, long-term care, ambulatory surgery centers and more. Health IT is also prevalent in educational institutions, academic medical centers, government agencies, the military, vendor organizations and consulting companies. Both general IT and healthcare IT roles exist in these organizations. Individuals with a clinical background who are interested in a career in healthcare IT will find excellent opportunities in many of the organizations listed above. To make the transition from clinical practice to IT or from general IT to healthcare IT can be challenging; however, those who do it successfully often thrive in their new careers. The HIMSS Professional Development Staff and associated professional development committees have created a document that contains job descriptions for health information technology professionals. This document can be found on the HIMSS web site in the Resource Center.

Senior Management Roles and Responsibilities

Board of director, executive management and medical executive committee support are essential for the success of IT in a healthcare organization. The CIO is generally the most senior-level IT executive. In many health systems, this role also carries the vice president or senior vice president designation. Additional IT executive leadership roles can include the CMIO, the chief nursing information officer (CNIO), the chief technology officer (CTO), the chief information security officer (CISO), chief health information officer (CHIO) and chief pharmacy information officer (CPIO). Second-level leadership typically entails IT department directors, clinical informaticists and physician and nurse champions. Recently, health systems have developed new roles, such as the chief innovation officer, chief applications officer, chief digital officer, chief experience officer, chief business development officer and chief privacy officer positions, to meet the dynamic and complex technology environment.

General IT Roles and Responsibilities

Healthcare organization IT departments are staffed with internal full-time employees (FTEs) or outsourced staff that support traditional IT-related roles. Job descriptions for these roles are categorized as senior level, midlevel and entry level and typically include titles such as director, manager, architect, analyst, engineer, technician, administrator, programmer, analyst and developer. Common areas that these roles are responsible for are generally divided into three major sections. The infrastructure team is usually responsible for the data center, IT helpdesk, communications, database administration, backups, network support and IT security. The business group manages applications to support human resources, payroll, supply chain, finance, marketing and web development. Clinical applications teams support EHRs and all clinical ancillary applications. Technical integration teams support interfaces between all types of systems.

Healthcare IT Roles and Responsibilities

To meet the evolving technology demands of healthcare organizations, particularly considering the increased usage of EHRs, many clinical, business and project-related roles now require healthcare IT knowledge and a blend of healthcare business, clinical, management and technical experience. Some of the most in-demand clinical and business positions are analyst roles. These include specialty roles covering all categories of applications, administrative services, customer support, workflow analysis and configuration. Other important healthcare IT roles include informatics, clinical engineering, go-live events, implementation consulting, integration, project management, quality assurance, usability and human factors analysis. Trainers are crucial in healthcare for all personnel and all applications. Change management, transformation and IT communications teams are also becoming more common in healthcare institutions.

Staff Competency in Information and Management System Skills

With the myriad of roles in a typical healthcare IT department, it is important to consider professional development, training and competency for the applications supported. Some applications require professional certification in order to perform configuration within. Others require one-time certification. A solid plan for team development can reduce turnover and increase employee satisfaction.

Employee Development

Employee development is a key component in ensuring that healthcare IT staff attain the necessary competency in information and management system tools and skills. Mastering those skills, along with developing the soft skills needed to collaborate and work together as a team, is essential in ensuring the success of the organization. Staff improvement programs provide employees with the proficiencies and qualifications needed for advancement within the organization, and help staff form positive attitudes and interpersonal skills to work effectively. Employee development can be provided through training and in-service programs, certification classes, community college or university educational courses, conferences and workshops, professional association involvement and self-study through books, industry magazines, videos and online resources. Effective leaders also provide opportunities for employees to mentor others or ask senior colleagues for mentorship. Shadowing an executive for a day can be an enriching experience for an employee. It is common practice to implement goals during the annual review process, adding a “stretch” goal or a goal to take someone out of their comfort zone gives the individual the opportunity to grow and learn.

Organizational Training and In-Service Programs

Training and in-service programs may originate from several sources. Human resources typically have responsibility for organization-wide training requirements (e.g., security and safety regulations, discriminatory practice and quality improvements). Supervisory, management and leadership development may be designed and offered by a leadership department within the organization or through human resources. The department or group in which an employee works provides programs such as in-service or online training. In addition, IT projects for information and management system deployments usually include a training budget for system developers, administrators and end users who will be supporting and using the product.

Job-Related IT Certifications

IT-based certifications have long been a mainstay of IT education and professional credentials. Certifications have two main advantages. First, they provide a framework by which technical staff can learn and gain a level of proficiency in a specific IT-related topic. Second, a certification provides the recipients with a credential showing they have a defined body of knowledge in a specific area. Although a certification by itself will not qualify a person for a new job or promotion, it does demonstrate that the individual has mastered either a basic or advanced level of a specific knowledge area and it is often viewed as a positive contributing factor in the decision of whom to hire. It is recommended that clinicians keep their clinical licensure and certifications active and up-to-date, even if they are no longer in a clinical role. Similarly, IT professionals should also consider keeping their IT certifications active, particularly those certifications that are in high demand in healthcare IT.

The Certified Professional in Healthcare Information and Management Systems (CPHIMSSM) certification is an essential credential for all healthcare IT management, management engineering and process improvement professionals, military personnel and consultants. Developed and sponsored through HIMSS, eligible candidates become certified by passing the CPHIMS examination. The CPHIMS certification demonstrates an international standard of professional knowledge and competence in healthcare information and management systems. Similarly, HIMSS offers the Certified Associate in Healthcare Information and Management Systems (CAHIMSSM) certification allowing those who do not qualify for eligibility for the CPHIMS, an opportunity to demonstrate their professional knowledge.

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.

Many of today's highly sought-after healthcare IT certifications can be obtained only by employees of organizations that are engaged in a specific vendor product deployment, such as an EHR or healthcare information systems project. However, healthcare systems also value generally available certifications, particularly if they are in the process of deploying related methodologies throughout their organization. These include certifications such as the Project Management Professional (PMP®), ITIL® and Lean Six Sigma.

Miscellaneous Professional Development

Healthcare IT professionals should consider other professional development and education opportunities. These are particularly useful in helping individuals become well rounded and remain current in the rapidly evolving healthcare environment. Employees are typically responsible for the costs of their professional development, but many companies pay for such education as a benefit of employment. Several of the more common sources of professional development are healthcare IT conferences and workshops; programs sponsored by national and local professional associations, such as HIMSS; university certificate programs and bachelor's, master's and doctorate degrees in healthcare IT, informatics, information management and information systems; and self- or group study using books, industry magazines or journals, videos and such online resources as white papers, webinars, conferences and training.

Performance Evaluation

Performance evaluation is an important tool that healthcare administrators can utilize to monitor and improve employee competencies. Performance evaluation is the ongoing process in which employees’ work, outcomes, attitudes and interpersonal skills, professional growth and adherence to organizational values are assessed and feedback is provided. In the evaluation process, the employee's actual performance is compared against the expected performance. In order to be effective and objective, the performance evaluation process must start with specific and measurable performance goals. The performance goals should be defined and communicated to the employee at the start of the year.

A variety of methods can be used in the performance evaluation process, the most common being the rating scale. The scales will specify personal traits and behaviors expected, such as teamwork, communication skills, adherence to values, dependability and initiative. Also specified will be specific job attributes, such as quality and quantity of work.26 Each trait or behavior is accompanied by a range of numbers and words that the evaluator marks to indicate an employee's level of performance.

Some organizations use the 360-degree method of performance appraisal. In this method, other individuals are asked to rate the employee on specific criteria. Raters may include individuals who work with the employee on teams, subordinates, peers in the same department, employees in other departments and sometimes outside customers and vendors. The employee is also given the opportunity to perform a self-assessment. The results of all these assessments are taken into consideration in the final evaluation that is completed for the employee. In this process, it is important to provide confidentiality to the raters for the evaluations they provided.

During the performance appraisal process, it is important for the manager to provide feedback to employees at regular intervals during the year. Employees should never be surprised during a formal appraisal that they were found to be performing at a less than adequate level in some aspect of their role. Sub-par performance should be dealt with as soon as it is identified. This type of feedback gives the employee an opportunity to improve performance. Alternatively, if an employee is performing at an excellent or exceptional level, the interim positive feedback will help to preserve that positive behavior. Although interim reviews can be done formally or informally, it is advisable to complete a formal, written interim review if an employee's performance requires improvement.

When disciplinary action is needed, it must be taken based on clear facts and with documented justification. If disciplinary action is needed, it should be done progressively over time—starting with verbal discussions, then utilizing written and verbal communication and possibly ending with termination. This approach provides consistent communication to the employee about what needs to be done to resolve the problem. Communication may be oral at first. If the problem persists, documentation should be completed in the form of notes to the employee's personnel record and written warnings with substantive examples of the inadequate performance. At all steps during the process, it is advisable to communicate with and seek the advice from the human resources department.

Developing Educational Strategies for IT Staff

Leaders are hired due to a combination of their experiences and skills. They will likely select individuals to work for them based on similar criteria. The staff will continue to gain experience as they do their jobs, but there is very little opportunity for them to continue their education and expand their knowledge unless someone creates opportunities for them. Education can be provided in many ways and at relatively little overall cost.

At the very least, education needs to be valued. Commit to the time it will take for staff to complete further education and commit to supporting the cost of the education as well. Encourage staff to broaden their skills by taking opportunities to stretch their current skills or cross-train in areas that are beyond their current experiences. When it becomes tempting to reduce costs by eliminating educational support, also consider how much it will cost to recruit new staff and whether the skills sought are those the current staff may be lacking.

Initiate your educational support by creating low-cost educational opportunities for the staff. Ensure that staff members are signed up as members of all the vendor user groups, both locally and nationally. Take advantage of professional societies, interest groups and other local educational opportunities as well. Many of these organizations sponsor local presentations and educational dinner meetings as conveniences to their members. Professional associations, like HIMSS, offer both local and global membership. In many cases, education is free and is often available in multiple media formats so that individuals can attend in person or via webcasting, webinars and other telecasting options. Many vendors will also make free educational opportunities available to the staff.

When funds are available, consider having staff take turns attending vendors’ user conferences or professional society conferences. That way, staff members can attend conferences every couple of years. Ask those staff who go to take time to explore specific educational sessions of interest to the whole organization. Upon the conference attendee's return, arrange for a team luncheon at which that person can report on information learned and share any gathered materials. Most societies and large user groups make their conference presentations available online, so it is very easy to share content with staff.

As noted earlier, succession planning is an important part of the overall IT planning process. An investment in education and the thoughtful application of the new skills expands the capabilities of the IT staff and helps to ensure a well-balanced, mature and knowledgeable department.

Current IT Technologies and Trends

The overall education of the IT team members extends beyond the applications they service and the immediate issues and objectives that are at hand. Team members need to stay connected to a variety of disciplines related to their specific sphere of expertise. The greatest opportunity for this added education comes from within the organization itself. Listen to the feedback of colleagues and peers. Be engaged and ask questions to become more knowledgeable. So much of the work we do overlaps with the work of others. Knowledge will expand your effectiveness in the work you do.

Outside of your own colleagues, a valuable educational resource is the media and printed press. The Guardian, Healthcare IT News, People's Daily and the Wall Street Journal are often the first to pick up on and report trends or activities that have national or international significance in many disciplines. Take the time to review the headlines and articles in order to stay up on current events. Organizational leaders will be regularly asked to comment on materials in those publications.

Many publications now offer really simple syndication (RSS) or other services that will e-mail the headlines or article titles that align with subjects you are interested in. Given the option of being proactive or reactive, a successful leader will choose the former path.

Developing System, Operational and Department Documentation

With the vast amount of expertise required to manage healthcare applications, it is crucial that teams develop detailed documentation to create a knowledge base for auditing and use by teams. The documentation can be system, operational, or departmental in nature. This ensures that teams are organized, and that customers understand the IT process.

System Documentation

System documentation includes the documents that support analysis, decision making, acquisition and implementation processes. It also addresses system features and functional and technical requirements. Systems analysis documentation includes the information gathered in the process of “collecting, organizing, and evaluating data about IT system requirements and the environment in which the system will operate.”27 It also includes documents such as functional requirements, design specifications, requests for information and proposals and related vendor responses. Also considered part of system documentation are procedure manuals, computer programs and machine operating manuals; details of standards compliance; and records of the initial system testing process and results (e.g., data collection and input procedures).

Operational Documentation

Operational documents relate to ongoing systems operations and maintenance. They include information about ongoing testing of systems and results, audit processes and database management, as well as training manuals. Operational documents also encompass implementation time frames, flowcharts and progress reports; data backup and recovery procedures; and system retirement, tuning and logistic support requirements.

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.

Summary

Settings

Progress is stored in this browser only. The file opens from disk with no server.

How this notebook is built