Health Information & Coding · Independent exam preparation

AMIA AHIC: Applied Health Informatics Preparation Guide Study Guide

Practise safer system changes, protected-data sharing, meaningful exchange, sound analytics, and implementation decisions across the five domains of AMIA's AHIC examination.

By CertMedbry · Updated 29 October 2026

60 concepts explainedWorked examples & common pitfallsOfficial blueprint references

Decide how to validate exchanged data, protect confidential information, improve decision support, test system changes, evaluate predictive models, and lead implementation. These 60 concepts connect informatics principles to practical decisions across healthcare delivery, public health, and consumer health. They selectively sample the five official AHIC domains; AMIA's complete Outline of Exam Topics defines the full examination scope. Use the applications to practise reasoning, then explain why each tempting alternative fails.

Try 20 free practice questions

What is the exam format?

Check the question types, timing and outline before planning your revision.

Which certification does this guide address, and what does the historical Advanced label mean?

The certification addressed is AMIA Health Informatics Certification, administered through AMIA's autonomous Health Informatics Certification Commission. Successful certificants earn AMIA Certified Health Informatics Professional, or ACHIP. AMIA's June 29, 2016 announcement called the developing program Advanced Health Informatics Certification. Current issuer materials use AMIA Health Informatics Certification; the historical label does not establish a separate current Advanced examination or tier. AMIA has announced that the program will conclude; the program-status FAQ explains the transition.

AMIA Health Informatics Certification (AHIC) · AMIA Announces Advanced Health Informatics Certification Eligibility Requirements

How many questions are scored, and are there pretest questions?

The Program Guide describes 150 multiple-choice questions, all scored. It therefore identifies no unscored pretest questions within that total. Each official item has three answer options. Incorrect answers receive zero points without a penalty deducted from other answers.

AHIC Program Guide

How long is the examination, and how is it delivered?

Candidates have four hours for examination content. The Program Guide describes secure computer-based testing at Pearson VUE test centers worldwide, using multiple equated forms with items presented in random order. Pearson VUE's AMIA page describes both in-person test-center delivery and remotely proctored OnVUE delivery using the candidate's equipment. These published descriptions differ in their stated delivery options. During AMIA's announced program transition, neither description guarantees that a particular option remains available to an individual candidate. Candidates should confirm their authorized delivery arrangements with AMIA and Pearson VUE before scheduling.

AHIC Program Guide · AMIA AHIC Health Informatics Certification Exams | Health Informatics Credentialing · AMIA Online Exams with OnVUE | Requirements, Rules, and Setup · AMIA Health Informatics Certification (AHIC)

What passing score is supported by the current handbook?

The Program Guide specifies a scaled score range of 0–800 and a passing scaled score of at least 600. It describes modified Angoff standard setting. A scaled score of 600 must not be interpreted as a verified requirement to answer 75% of questions correctly; the raw-to-scaled conversion is not published in the guide.

AHIC Program Guide

Which blueprint and domain weights apply?

The content basis is the Outline of Exam Topics linked from AMIA's examination page and verified on October 11, 2026. Its weights are Foundational Knowledge 17%; Enhancing Health Decision-making, Processes, and Outcomes 21%; Health Information Systems (HIS) 21%; Data Governance, Management, and Analytics 20%; and Leadership, Professionalism, Strategy, and Transformation 21%. The 60 concepts are allocated 10, 13, 14, 12, and 11 respectively. Vendor evaluation and product selection belong primarily to HIS Task 3.03. The official outline remains the full scope.

AMIA Health Informatics Certification (AHIC) Exam · AMIA Health Informatics Certification: Outline of Exam Topics

What do the outline and Program Guide dates establish?

The outline carries a 2018–2021 copyright marking without a separately stated effective or revision date. AMIA's examination page attributes its supporting practice analysis to 2019, while the outline footnote identifies 2018. Neither establishes a blueprint effective date. The Program Guide available on October 29, 2026 has a January 16, 2026 cover revision, while internal footers retain Effective April 2021 and revision October 15, 2025. Those markings do not establish a new outline.

AMIA Health Informatics Certification: Outline of Exam Topics · AHIC Program Guide · AMIA Health Informatics Certification (AHIC) Exam

Do eligibility tracks or international applications lead to different examinations?

The Program Guide describes three eligibility tracks based on degree background and qualifying informatics experience. They lead to the same AHIC certification rather than separately named examinations. The handbook permits applicants outside the United States to qualify and states that examination scope reflects informatics practice within the United States, including US-specific law. International eligibility does not establish a separate jurisdictional blueprint. These handbook provisions do not establish application or examination availability during the announced program transition.

AHIC Program Guide · AMIA Health Informatics Certification (AHIC)

How should these practice questions and flashcards be used?

The 20 questions are independent four-option, single-best-answer drills. The official examination uses three options, so these drills are not a reproduction of its interface or item format. Question allocation is 3, 4, 4, 4, and 5 across the five domains; the 20 flashcards provide four per domain. These small sets approximate the published weights and support explanation-based review, not pass prediction.

AHIC Program Guide · AMIA Health Informatics Certification: Outline of Exam Topics

What is the AHIC program's status as of October 29, 2026?

AMIA has announced that the AHIC program will conclude and that existing ACHIP credentials will be preserved. AMIA states that guidance for individuals currently in the application or examination process is being developed. The announcement does not establish a final examination date, confirm that applications have already closed, or announce a replacement certification. Applicants and candidates should obtain AMIA's transition guidance before relying on the handbook's usual application, scheduling, or recertification procedures.

AMIA Health Informatics Certification (AHIC)

This guide addresses the operational informatics knowledge and professional judgment assessed by the multidisciplinary AMIA Health Informatics Certification examination associated with the ACHIP designation. Consult the program-status FAQ for AMIA's announced transition. The independently authored questions and flashcards are educational materials; they do not reproduce examination items or predict examination performance.

Outline used: Current AHIC Outline of Exam Topics linked from AMIA's official examination page, verified on 2026-10-11; outline copyright 2018–2021, with no separate effective or revision date stated. Current linked Program Guide: cover revision 2026-01-16; internal footers state Effective April 2021, revision 2025-10-15. Workbook label 'Health Informatics Certification (Advanced)' is mapped to AMIA's AHIC program: AMIA's 2016 announcement called the developing program Advanced Health Informatics Certification; current issuer materials call it AMIA Health Informatics Certification. The assigned slug is preserved.

60 key concepts: understand, apply and avoid the traps

Work through the questions by exam domain. Explain the answer in your own words, try the example, then check the common pitfall.

Foundational Knowledge17%

1.How do primary and foreign keys protect mandatory relationships?

A primary key uniquely identifies a row and cannot be null. A foreign key requires a non-null referencing value to match an allowed referenced key, preserving referential integrity between tables. A nullable foreign key can still permit a row without a patient reference. Requiring every encounter to reference an existing patient therefore needs both a foreign key and NOT NULL on the encounter's patient identifier. These constraints establish structural consistency, but they do not establish that the encounter belongs to the clinically correct person.

Apply it

An encounter import contains one missing patient identifier and another identifier absent from the patient table. NOT NULL rejects the missing identifier; the foreign key rejects the nonexistent patient relationship. Resolve both before loading the encounters.

Common pitfall: A foreign key alone does not require a relationship to be present. Even with NOT NULL, it can accept an existing but clinically incorrect patient identifier.

PostgreSQL Documentation: Constraints

2.What determines whether protected health information may be shared?

Privacy governs permissible uses and disclosures; confidentiality limits disclosure to authorized recipients. Under HIPAA, first establish whether the organization and information are within scope, then identify the disclosure's purpose, recipient, and legal basis. A covered entity needs a valid written authorization unless a Privacy Rule permission or requirement applies. Apply minimum necessary where required; disclosures to or requests by a health care provider for treatment are exempt from that standard. Permission is distinct from secure transmission. More protective applicable state law can still constrain disclosure. See [HHS Privacy Rule guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html).

Apply it

A life insurer requests an applicant's hospital records for underwriting. With no other applicable disclosure permission or requirement, obtain and validate the individual's authorization, including information covered, authorized parties, expiration, signature, and revocation provisions, before releasing records within its scope.

Common pitfall: Encryption does not create permission to disclose. A legitimate recipient, useful purpose, or signed general privacy notice does not automatically supply a valid authorization.

AMIA Health Informatics Certification: Outline of Exam Topics

3.When does a database check need a non-null constraint?

A check constraint evaluates whether a stored value satisfies an expression, but null handling matters. In PostgreSQL, a check is satisfied when its expression evaluates to true or null. Therefore a check such as age being nonnegative does not itself require age to be present. Use a separate non-null constraint when presence is mandatory, and reserve range checks for validating values that are supplied under the data model.

Apply it

A required encounter duration must be zero or greater. Define both a non-null requirement and a nonnegative check; test a missing duration separately from a negative duration during import validation before accepting the dataset.

Common pitfall: Treating a range check as a completeness rule leaves missing values admissible. Conversely, requiring values that are legitimately unknown encourages fabricated or misleading substitutes.

PostgreSQL Documentation: Constraints

4.What separates syntactic from semantic interoperability?

Syntactic interoperability concerns whether systems can exchange and parse an agreed structure. Semantic interoperability concerns whether the receiving system preserves the intended meaning of the information. A successfully parsed message can still contain an ambiguous code, incompatible unit, or locally defined interpretation. Investigate meaning when transport succeeds but clinical interpretation differs; investigate structure or transport when the receiver cannot reliably recognize the message or its elements.

Apply it

Two systems exchange a laboratory observation without parsing errors, but one displays a local test code as an unrelated analyte. Examine terminology identity and mapping before changing the network connection or message transport settings.

Common pitfall: A successful transmission acknowledgement proves neither clinical equivalence nor usable meaning. Technical delivery and semantic validation need separate acceptance criteria in an exchange project.

HL7 FHIR R5 Overview · HL7 FHIR R5: Using Codes in Resources

5.How do FHIR resources and references organize exchange?

FHIR represents healthcare information using resources with defined elements and relationships. References connect resources, allowing an observation, for example, to identify its subject without embedding an entire patient record. Resource choice should follow the meaning of the information and the applicable implementation requirements. Receiving a resource does not guarantee that every referenced resource is available, authorized for access, or sufficient for the intended workflow.

Apply it

An application receives an observation referencing a patient and an encounter. Its integration test checks that these references resolve appropriately and that the observation can be associated with the intended clinical context before display to users.

Common pitfall: Treating each resource as an isolated document can discard relationships needed for interpretation. References require deliberate handling of identity, availability, authorization, and clinical context.

HL7 FHIR R5 Overview

6.Why are FHIR profiles needed for implementation?

FHIR provides a general exchange framework, while profiles constrain or describe how resources are used for a particular purpose. A profile can narrow cardinality, specify terminology expectations, and define additional implementation requirements within FHIR's rules. The discriminating question is whether two parties merely support the same resource type or support compatible requirements for that use case. Confirm versions and implementation agreements before assuming practical interoperability.

Apply it

Two vendors both support Observation, but the receiving registry requires a coded category and specified terminology. Validate the sending resource against the agreed profile and version, then resolve any missing required content before deployment.

Common pitfall: A statement of FHIR support is too broad to establish compatibility. Profile, version, terminology, and workflow agreements determine whether a particular exchange actually works.

HL7 FHIR R5 Overview

7.Which details identify a coded clinical meaning?

A code is interpreted within a code system, not by its character string alone. FHIR coding can include the system identifier, code, display text, and version where relevant. A value set selects permitted codes for a context; it is distinct from the code system defining those codes. Preserve system identity and applicable version information when the same short code could occur in different terminologies.

Apply it

An interface receives the code 123 from two laboratories using different local systems. Retain each system identifier and resolve mappings separately, rather than merging observations because their short code strings happen to match in the incoming feeds.

Common pitfall: Display text helps people read a code but is not a reliable substitute for system and code identity. Similar labels can conceal different clinical meanings.

HL7 FHIR R5: Using Codes in Resources

8.When is a terminology mapping unsafe to treat as equivalent?

Mapping connects concepts across terminologies, but relationships can be broader, narrower, related, or equivalent. Differences in specimen, method, timing, or clinical context can make a superficially similar target unsuitable. Preserve the original coding and document the mapping relationship and limitations. Use an equivalence assumption only when the relationship supports the downstream task; aggregation may tolerate distinctions that a clinical decision rule cannot safely ignore.

Apply it

A warehouse proposes combining a general screening concept with a specific confirmatory test under one target code. Review the source meanings and intended analysis, preserving distinctions when the target would imply information the source never established.

Common pitfall: Choosing the closest label does not establish equivalence. A convenient mapping can silently add specificity or erase distinctions that matter for decision support and reporting.

HL7 FHIR R5: Using Codes in Resources

9.How do surveillance sensitivity and predictive value differ?

Surveillance sensitivity is the proportion of actual cases detected by the system. Predictive value positive is the proportion of reported or detected cases that truly meet the case definition. They answer different questions about missed cases and false reports. Calculate each using its correct denominator, and consider the purpose of surveillance: broad early detection may accept more false reports, while confirmatory investigation requires enough specificity to use resources effectively.

Apply it

A validation review finds 80 true detected cases, 20 missed cases, and 40 false reports. Sensitivity is 80 divided by 100, or 80%; predictive value positive is 80 divided by 120, about 67%.

Common pitfall: Using all reports as the denominator for sensitivity confuses detection with report credibility. A sensitive system can still generate substantial unnecessary investigation when false reports are common.

CDC: Updated Guidelines for Evaluating Public Health Surveillance Systems

10.Why can complete surveillance data still be unrepresentative?

Completeness concerns missing records or fields, whereas representativeness concerns how accurately surveillance describes the population, place, and time of interest. A dataset can have every field populated yet systematically omit people outside participating facilities. Compare coverage and subgroup inclusion with the target population before generalizing estimates. Better internal completeness cannot correct a biased sampling frame or unequal opportunities for events to enter the surveillance system.

Apply it

A city dashboard receives complete records from large hospitals but none from community clinics. Before describing citywide patterns, assess which neighborhoods and patient groups rely on those clinics and how their absence could distort the observed distribution.

Common pitfall: A high field-completion percentage can create false confidence about population coverage. Missing populations and missing values are different problems requiring different corrective actions and measures.

CDC: Updated Guidelines for Evaluating Public Health Surveillance Systems

Enhancing Health Decision-making, Processes, and Outcomes21%

11.How does patient context improve decision support?

Decision support becomes more useful when it incorporates information that changes the relevance or urgency of a recommendation. Context can include the patient's current circumstances, existing monitoring, and the task being performed. The design question is whether additional information separates actionable situations from low-value interruptions. Evaluate clinical usefulness and workflow effects together, because technically correct rules can still fail when they repeatedly interrupt users without changing an appropriate decision.

Apply it

A medication interaction rule fires repeatedly even when the documented management plan already addresses the interaction. Review the contextual information available to distinguish cases needing new action from cases already managed, then test the revised behavior with clinicians.

Common pitfall: Adding more alerts does not necessarily improve safety. Repeated low-value interruptions can reduce attention to consequential warnings and obscure the situations requiring prompt clinical review.

AHRQ: Creating Meaningful Decision Support to Reduce Drug-Drug Interactions

12.When should an alert interrupt the workflow?

An interruptive alert demands attention at the cost of delaying the user's current task. Match that burden to the seriousness, likelihood, timing, and actionability of the problem. Lower-urgency information may fit a passive display or a later workflow step. A useful discriminating cue is whether action must occur at that moment to prevent meaningful harm, rather than whether the underlying information is merely relevant to the patient.

Apply it

An organization reviews two reminders: an immediate ordering hazard and a routine review due next month. It tests an interruptive presentation for the time-sensitive hazard and a noninterruptive task reminder for the later review, measuring appropriate responses.

Common pitfall: Assigning the same interruptive presentation to every rule removes useful prioritization. Severity labels alone are insufficient when timing, patient context, and available actions differ substantially.

AHRQ: Creating Meaningful Decision Support to Reduce Drug-Drug Interactions

13.How should decision-support knowledge be maintained?

Decision-support content requires ownership, documented logic, version control, testing, and review after implementation. A change in terminology, available data, or workflow can alter a rule's behavior even when its written recommendation remains unchanged. Assign responsibility for evaluating evidence and local performance, and retain a way to trace which logic operated at a particular time. Review unexpected firing patterns as possible content or integration failures.

Apply it

After a terminology update, a screening reminder stops identifying eligible records. The content owner compares the deployed value set and rule version with the approved specification, tests corrected cases, and monitors firing behavior after the controlled release.

Common pitfall: Approving a rule once does not establish continuing validity. Unowned logic can become obsolete or malfunction as data definitions, interfaces, and workflows change around it.

SAFER: System Management · AHRQ: Creating Meaningful Decision Support to Reduce Drug-Drug Interactions

14.How does expected value support a decision under uncertainty?

Expected value combines each possible outcome's probability with its assigned consequence, then sums across outcomes for an option. The preferred option depends on both estimated probabilities and how benefits, harms, or costs are valued. State assumptions explicitly and test whether plausible changes alter the choice. Expected value supports transparent comparison; it does not eliminate uncertainty, establish fairness, or determine whose preferences should define the consequences.

Apply it

A support intervention costs 20 resource units and yields a benefit valued at 100 units when successful. With a 30% success probability, its expected net benefit is 30 minus 20, or 10 resource units.

Common pitfall: Selecting the option with the largest possible benefit ignores its probability and burdens. An average expected value can also conceal important differences between affected groups.

AMIA Health Informatics Certification: Outline of Exam Topics

15.Why distinguish absolute from relative improvement?

Relative change describes improvement in proportion to the baseline value, whereas absolute change describes the difference on the original scale. Both can be correct but communicate different practical implications. A reduction from 4% to 2% is a two-percentage-point absolute reduction and a 50% relative reduction. Use the baseline risk and relevant population size to assess likely impact rather than treating an impressive relative percentage as a complete decision basis.

Apply it

Two services each report a 50% reduction in a recorded event rate. One falls from 20% to 10%, the other from 2% to 1%. Compare the absolute changes before estimating workload or the number of events potentially avoided.

Common pitfall: Confusing percentage points with percent change exaggerates or understates impact. Relative improvement alone does not reveal the baseline burden or the expected number of affected people.

AMIA Health Informatics Certification: Outline of Exam Topics

16.When is risk adjustment appropriate for quality comparison?

Risk adjustment accounts for relevant differences in patient characteristics so that outcome comparisons better reflect the quality question being asked. Select variables using clinical reasoning, timing, and the measure's intended interpretation. A characteristic caused by the care being evaluated may be part of the outcome pathway rather than a legitimate adjustment factor. Adjustment reduces specified case-mix differences; it does not automatically remove bias or establish causation.

Apply it

A hospital comparison proposes adjusting for a complication that developed after treatment began. The measure team examines whether that complication reflects the care under evaluation before including it, while separately considering appropriate baseline patient characteristics in the model.

Common pitfall: Adding every available predictor can adjust away differences the measure should reveal. Predictive strength alone is insufficient justification for including a variable in a quality model.

CMS: Risk Adjustment and Risk Stratification in Quality Measurement

17.Why stratify outcomes as well as adjust them?

Stratification reports results separately for meaningful groups, making variation visible rather than combining everyone into one summary. Risk adjustment serves a different purpose by accounting for selected case-mix differences in comparisons. An overall adjusted result can conceal unequal outcomes or service access. Choose strata aligned with the improvement question, consider sample size and uncertainty, and examine whether observed differences require investigation rather than assuming a pooled average represents every group.

Apply it

A program's overall completion rate rises, but leaders suspect unequal access. Report completion by language group and location with denominators and uncertainty, then examine whether the apparent improvement occurred across groups or only in the largest group.

Common pitfall: An acceptable organization-wide average does not establish equitable performance. Stratification can expose differences, but small subgroup counts require careful interpretation rather than confident rankings alone.

CMS: Risk Adjustment and Risk Stratification in Quality Measurement

18.Which measures reveal improvement and unintended effects?

Outcome measures assess the result of interest, process measures assess whether intended activities occur, and balancing measures detect costs or harms elsewhere. Use them together to test a theory of improvement. A process can improve without changing outcomes, and a favorable outcome can coincide with an unacceptable burden. Specify operational definitions, denominators, and measurement timing so that changes can be interpreted against the intervention and its expected mechanism.

Apply it

A results-follow-up project measures completed follow-up as its outcome, assignment of an accountable clinician as a process measure, and staff time spent resolving duplicate messages as a balancing measure during each small test of the workflow.

Common pitfall: A single favorable metric can conceal displaced work or new safety problems. Choose balancing measures from plausible consequences of the intervention, not merely available dashboard fields.

Institute for Healthcare Improvement: Model for Improvement

19.How does a small PDSA test generate useful learning?

A Plan-Do-Study-Act cycle tests a specific change with a prediction, observes what happens, compares results with expectations, and adapts the next test. Starting small limits disruption while exposing practical failures quickly. The purpose is learning about how a change works in a particular setting, followed by broader testing under different conditions. Implementation follows sufficient evidence and operational preparation rather than a single encouraging demonstration.

Apply it

One clinician tests a revised handoff form during one shift, predicting fewer clarification calls. The team records calls and omitted information, studies the mismatch between prediction and observation, and revises the form before a larger test.

Common pitfall: Calling a full rollout a PDSA cycle does not make it a learning test. Without a prediction and observation plan, teams cannot explain what the result means.

Institute for Healthcare Improvement: Model for Improvement

20.How can a run chart distinguish fluctuation from a shift signal?

Plot observations in their natural time order and calculate the median when at least ten observations are available. Under IHI's Run Chart Rules Reference Sheet, a shift is six or more consecutive observations above or below the median when there are fewer than twenty total observations; with twenty or more total observations, use eight. Points on the median are excluded: they neither count toward nor interrupt the sequence. Annotate intervention dates and other relevant events. A shift signals a pattern warranting investigation; it does not independently prove that an intervention caused the change.

Apply it

Sixteen weekly waiting times in minutes are 12, 13, 9, 14, 8, 15, 16, 17, 18, 11, 9, 8, 7, 6, 5, 4. The middle two sorted values are 9 and 11, giving a median of 10. The final six observations are all below 10, satisfying this IHI method's shift criterion. Investigate the apparent improvement alongside intervention timing, case mix, and other process changes.

Common pitfall: One low observation does not satisfy the shift criterion. Count only observations strictly above or below the median, apply the threshold for the total series length, and distinguish a detected signal from evidence of intervention causation.

QIToolkit_RunChart.pdf · 11_RunChartRulesReferenceSheet.pdf

21.How can workflow mapping identify the right intervention?

Workflow mapping makes tasks, handoffs, decisions, queues, and exceptions visible. It helps distinguish a delayed action from the upstream condition that creates the delay. Observe actual work across roles rather than relying only on written policy. When information waits between teams, a clearer responsibility or handoff may be more effective than faster data entry. Select changes based on the demonstrated process failure and test their effects.

Apply it

Referral completion is slow despite rapid electronic submission. Mapping reveals that requests queue without an assigned reviewer. The team tests explicit ownership and escalation rules before investing in a faster referral-entry screen that does not address the queue.

Common pitfall: Automating the visible task can preserve the underlying bottleneck. A workflow map should include waiting, exceptions, and responsibility transfers rather than only the intended main sequence.

Health IT Playbook: Electronic Health Records · Institute for Healthcare Improvement: Model for Improvement

22.What makes care coordination a closed loop?

Closed-loop coordination connects sending information with confirmed receipt, accountable review, an appropriate action, and documented completion or escalation. Transmission alone leaves uncertainty about whether anyone acted. Define responsibility at handoffs, expected time frames according to urgency, and backup arrangements for absence or failed communication. A useful completion criterion asks whether the intended clinical task was resolved, not merely whether an electronic message left the sending system.

Apply it

A referral message reaches a specialty inbox but remains unreviewed. The organization adds acceptance tracking, an accountable reviewing role, and escalation for unresolved referrals, then checks whether the patient receives a documented disposition rather than only a delivered message.

Common pitfall: A delivery receipt is weaker than clinical completion. Counting transmitted messages as successful coordination can hide unreviewed requests, ambiguous ownership, and unresolved patient needs.

SAFER: Test Results Reporting and Follow-Up

23.How should patient-facing result communication support action?

Patient-facing communication should connect a result with understandable meaning, the expected next step, and a route for questions or assistance. Design must account for urgency, language, access, and whether a responsible clinician has reviewed the result. A portal release can support transparency but does not itself establish comprehension or completion. Evaluate the communication pathway using whether patients can obtain and act on the intended information.

Apply it

A patient sees an amended result in a portal but receives no explanation. The follow-up workflow assigns a clinician to communicate the change, confirm the required next step, and document contact attempts through an accessible communication method.

Common pitfall: Portal availability does not prove that a patient read or understood a result. Automated release must be integrated with accountable review and appropriate follow-up.

SAFER: Test Results Reporting and Follow-Up

Health Information Systems (HIS)21%

24.Which testing level addresses a cross-system failure?

Unit testing checks a component in isolation, integration testing checks interactions between components, and regression testing checks whether a change disrupted previously working behavior. Select tests according to the failure mechanism rather than treating these labels as interchangeable. A calculation can pass its unit tests while the interface supplies the wrong units. Cross-system workflows therefore require tests that exercise the actual exchanges, transformations, and downstream displays involved.

Apply it

A laboratory interface passes its parser tests, but the clinical display associates a result with the wrong encounter. Run an integrated order-to-result scenario that checks identifiers and associations through each participating system before approving the interface for release.

Common pitfall: Passing isolated component tests cannot establish that the complete workflow is safe. Integration defects often arise from assumptions that each component's local tests never exercise.

SAFER: System Management

25.How does user acceptance testing differ from technical testing?

User acceptance testing evaluates whether a configured system supports agreed operational needs through representative workflows and users. Technical correctness is necessary but does not establish that staff can complete their work safely. Include realistic roles, exceptions, handoffs, and expected outcomes. Acceptance criteria should be explicit enough to support a release decision, with unresolved defects assessed for their workflow and safety consequences rather than counted without context.

Apply it

A new discharge module saves records correctly, but nurses cannot document an exception needed for home support. Acceptance testing captures that scenario and compares it with agreed requirements before leaders decide whether the module is ready for clinical use.

Common pitfall: A vendor demonstration is not equivalent to local acceptance testing. Demonstrations may omit configuration differences, exception cases, and handoffs that determine whether actual work succeeds.

SAFER: System Management · Health IT Playbook: Electronic Health Records

26.Why control the environment used for system changes?

Separating development, testing, and production reduces the chance that unfinished changes directly affect clinical operations. A controlled release identifies the approved configuration, validates important workflows, coordinates dependencies, and defines rollback or mitigation. Test environments must represent relevant production behavior closely enough for results to be meaningful. The decision to release should consider unresolved safety defects and operational readiness, not simply whether software installation completed without an error.

Apply it

An upgrade modifies order routing and authentication. The release team tests both in a representative environment, confirms support coverage and recovery steps, and verifies the deployed configuration before exposing the changed workflows to all clinical users.

Common pitfall: A successful installation does not prove successful clinical operation. Configuration differences or untested dependencies can cause failures even when the vendor's underlying software behaves as designed.

SAFER: System Management

27.How should an interface be monitored beyond connection status?

An interface can remain connected while messages are delayed, rejected, duplicated, or misinterpreted. Monitor the flow of expected clinical information, including queue age, failures, acknowledgements, and downstream availability. Define who investigates exceptions and how affected workflows are protected. A useful distinction is between transport availability and end-to-end completion: the former shows connectivity, while the latter establishes that the intended information reached the correct destination in usable form.

Apply it

The integration dashboard shows a live connection, but results have accumulated in a rejected-message queue. Staff investigate rejection causes, assess affected patients, and verify safe reprocessing rather than treating the green connection indicator as evidence of successful delivery.

Common pitfall: Connection uptime can conceal clinically significant delivery failures. Replaying a queue without checking duplicates, ordering, and downstream effects may create a second set of errors.

SAFER: System Management

28.Who should participate in usability evaluation?

Usability evaluation should involve representative users performing realistic tasks in a context that captures relevant work demands. Expertise, role, environment, and time pressure influence whether a design succeeds. Observing task performance exposes problems that satisfaction surveys or expert demonstrations may miss. Recruit participants and scenarios that reflect intended use, especially consequential or uncommon workflows, and interpret findings according to the task and user population actually evaluated.

Apply it

A medication screen is evaluated only by informatics specialists. The team expands testing to intended clinical users who perform realistic ordering and correction tasks, observing where they hesitate, misinterpret information, or select an unintended item during use.

Common pitfall: An expert's ability to complete a task does not establish usability for the intended workforce. Familiarity with a system can conceal design problems encountered by ordinary users.

NIST Releases Technical Guidance for Evaluating Electronic Health Records

29.How does security risk analysis lead to effective mitigation?

HIPAA Security Rule risk analysis assesses threats and vulnerabilities affecting the confidentiality, integrity, and availability of ePHI throughout a regulated entity. Inventory data locations and flows, identify weaknesses and existing safeguards, and assess likelihood and impact. Risk management implements and evaluates measures that reduce the identified risks. Include administrative, physical, and technical safeguards; neither a vulnerability scan nor a backup policy covers the whole assessment. Document findings, accountable actions, and reassessment when conditions change. See [HHS risk-analysis guidance](https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html) and the [Security Rule summary](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html).

Apply it

An unauthenticated export endpoint exposes ePHI. Restrict access or isolate the endpoint, correct the configuration, and test that unauthorized requests fail. Backups address recovery but do not prevent this disclosure; logging supports detection and investigation.

Common pitfall: Confidentiality, integrity, and availability require distinct protections. A completed assessment records risks; mitigation requires implemented controls and evidence that they work.

AMIA Health Informatics Certification: Outline of Exam Topics

30.What makes an EHR downtime plan clinically usable?

A usable downtime plan defines how essential clinical work continues when electronic functions become unavailable. It addresses communication, access to necessary information, documentation, ordering, results, patient identification, and staff responsibilities. Plans need accessible materials and rehearsals under plausible conditions, including unplanned failures. The key criterion is whether staff can execute safe alternate workflows with the resources actually available, rather than whether a policy document exists.

Apply it

A hospital rehearses an unplanned EHR outage during an evening shift. Staff test access to downtime materials, identify patients, communicate urgent results, and document orders, then revise the plan where handoffs or supplies fail during the exercise.

Common pitfall: A downtime document stored only inside the unavailable system is not operationally sufficient. Plans that depend on absent personnel or untested supplies can fail when needed.

SAFER: Contingency Planning

31.How do recovery time and recovery point objectives differ?

A recovery time objective expresses the target interval for restoring a service after disruption. A recovery point objective expresses the tolerable amount of data loss in time, informing how current restored data must be. The objectives address different needs and should follow clinical impact and workflow dependencies. Rapid restoration from an old backup may meet a time target yet fail the data-loss target, requiring additional reconciliation and protection.

Apply it

A service must return within two hours, with no more than fifteen minutes of data loss. Its recovery test restores operation in ninety minutes but uses a six-hour-old backup, meeting the restoration target while failing the data currency target.

Common pitfall: Fast restoration is not equivalent to adequate data recovery. Backup frequency, restoration capability, and clinical reconciliation must be evaluated against distinct continuity requirements.

SAFER: Contingency Planning · nistspecialpublication800-34r1.pdf

32.Why does recovery require clinical reconciliation?

When electronic systems return, information created during downtime must be reconciled with restored records and current clinical work. Orders, administrations, results, and documentation may exist in paper, queued interfaces, and partially restored applications. Assign responsibility for incorporating needed information and preventing duplicate or omitted actions. Restoration is complete only when relevant workflows and information are dependable, rather than when users can simply log into the application again.

Apply it

After an outage, a paper order and a delayed electronic order represent the same request. The recovery team reconciles their status before re-entry or queue release, confirming what was already performed and what still requires action for the patient.

Common pitfall: Entering every downtime record as a new transaction can duplicate clinical actions. Recovery needs status reconciliation and accountable review, not indiscriminate transcription or message replay.

SAFER: Contingency Planning

33.How should patient matching handle demographic uncertainty?

Patient matching uses identifying information to determine whether records refer to the same person. Demographic fields can change, be mistyped, or be shared by different people, so uncertain matches require a defined review process. Standardized capture and verification improve the inputs to matching. Distinguish confidence in a candidate match from confirmation of identity, especially when an incorrect match would place another person's information into a clinical workflow.

Apply it

Registration finds two records with the same name and birth date but different addresses and histories. Staff follow the uncertain-match review process and verify additional identifying information instead of choosing whichever record appears first in the search results.

Common pitfall: A matching name and birth date do not guarantee identity. Increasing automatic merges to reduce duplicates can create overlays if uncertainty and conflicting evidence are ignored.

SAFER: Patient Identification

34.What distinguishes a duplicate record from an overlay?

A duplicate occurs when one person has more than one record. An overlay occurs when information from different people is combined within a record. Duplicates fragment information, whereas overlays can introduce another person's clinical facts into decisions. The corrective process must reflect the distinction: verified duplicates may require controlled consolidation, while overlays require careful attribution and separation of incorrectly combined information with attention to affected clinical decisions.

Apply it

A chart contains two incompatible surgical histories belonging to different people. Treat the event as a possible overlay, protect current care, and involve trained identity staff to separate and correct information rather than merging another chart into it.

Common pitfall: Applying a routine duplicate-merge procedure to an overlay can worsen contamination. Establish whose information belongs where before changing record relationships or redistributing clinical content.

SAFER: Patient Identification

35.How should temporary patient identities be reconciled?

Temporary identities allow care to proceed when a person's identity is initially unknown, but they require controlled naming, identification, and later reconciliation. Staff must preserve the connection between the patient, specimens, orders, and results throughout the transition. Once identity is verified, reconciliation should account for dependent systems and outstanding work. Changing a visible name alone does not establish that all associated clinical information and identifiers have been safely aligned.

Apply it

An unidentified patient receives imaging under a temporary record. After identification, staff reconcile the record and verify the imaging system, outstanding orders, specimen labels, and result routing so that ongoing care continues under the confirmed identity without losing prior work.

Common pitfall: A quick demographic edit can leave downstream systems inconsistent. Identity reconciliation must include active orders and results, not only the name displayed in the primary chart.

SAFER: Patient Identification

36.Which safeguards keep result routing accountable?

Reliable result routing requires an identified responsible recipient, coverage during absence, escalation when review or action is overdue, and handling of corrected or amended results. Routing configuration should be tested through realistic workflows, including staff transitions and disconnected ordering contexts. A result reaching an inbox is an intermediate event. Safety depends on accountable review and follow-up, with unresolved items visible to people who can act.

Apply it

An ordering clinician leaves the organization while pending results remain. The system assigns an authorized covering role, tests routing of subsequent and amended results, and tracks unresolved follow-up instead of allowing messages to accumulate in the inactive clinician's inbox.

Common pitfall: Automatic forwarding without defined responsibility can merely move an unattended queue. Coverage must establish who reviews, acts, documents completion, and escalates unresolved findings.

SAFER: Test Results Reporting and Follow-Up

58.How should vendors be compared against operational needs?

Vendor evaluation should use defined requirements and representative scenarios, with criteria linked to operational objectives, safety, integration, support, and total cost. Apply the same evidence expectations to each option so that polished demonstrations do not dominate the comparison. Involve relevant users and technical staff to examine configuration and dependencies. A capability matters when it supports the intended workflow under realistic conditions, not simply when it appears on a feature list.

Apply it

Three vendors demonstrate referral management using the same scenarios, including missing information, staff absence, and unresolved follow-up. Evaluators score observed performance against agreed criteria and examine interface and support requirements before selecting an option for the organization's implementation needs.

Common pitfall: A long feature list or attractive demonstration may omit consequential exceptions. Vendor comparison becomes unreliable when each option is judged using different scenarios or unstated priorities.

AMIA Health Informatics Certification: Outline of Exam Topics · Health IT Playbook: Electronic Health Records

Data Governance, Management, and Analytics20%

37.How do governance and stewardship resolve data disputes?

Data governance establishes decision rights, policies, accountability, and escalation for the organization's use of data. Stewardship carries out responsibilities such as maintaining definitions, resolving quality problems, and coordinating changes within that authority. A technical team can implement a rule but may lack authority to choose its business meaning. Resolve disagreements through designated decision makers and documented definitions so that competing reports do not quietly maintain incompatible interpretations.

Apply it

Finance and operations define an active patient differently. A designated governance group approves purpose-specific definitions and owners, while stewards update the dictionary and reporting rules so users can understand why the resulting counts differ between the two measures.

Common pitfall: Giving a database administrator responsibility for every disputed definition confuses implementation access with decision authority. Governance must identify who may approve meaning and resolve conflicts.

AMIA Health Informatics Certification: Outline of Exam Topics

38.Which metadata make a measure reproducible?

Useful metadata describe what a data element or measure means, where it originates, how it is transformed, and the conditions under which it should be interpreted. For a measure, document inclusion criteria, numerator, denominator, time basis, exclusions, and version. Reproducibility requires enough detail for another analyst to implement the same meaning. A familiar label such as completed visit is insufficient when organizations count different statuses or dates.

Apply it

Two analysts produce different monthly follow-up rates. They compare definitions of eligible patients, completed follow-up, date attribution, exclusions, and measure version, then identify that one report uses order date while the other uses completion date for the denominator.

Common pitfall: A column name and storage type describe structure but may omit essential meaning. Unrecorded exclusions and timing rules can produce different answers from the same dataset.

AMIA Health Informatics Certification: Outline of Exam Topics

39.How does provenance support trust in derived information?

Provenance records information about how a resource or data product came to exist, including relevant activities, agents, and source entities. It supports tracing a derived value back to its origins and understanding who or what transformed it. Resource history and provenance are related but serve different purposes: a sequence of versions alone may not explain the sources or activities responsible for a particular change or derived result.

Apply it

A registry value differs from the source EHR. The analyst traces its source resource, transformation activity, responsible software agent, and relevant versions to determine whether the difference arose from source correction, mapping logic, or a later processing step.

Common pitfall: A timestamp alone rarely explains origin or transformation. Provenance also does not prove that a source was accurate; it makes responsibility and lineage more inspectable.

HL7 FHIR R5: Provenance

40.Which validation layers catch different data errors?

Validation should address structure, allowed values, relationships, and fitness for the intended use. A date can be correctly formatted yet occur before an impossible prerequisite; a valid patient identifier can still be assigned to the wrong person. Combine automated constraints with checks based on domain meaning and reconciliation to expected totals. The most useful validation rule identifies a specific failure and defines how questionable records will be investigated.

Apply it

An import contains valid timestamps and existing encounter keys, but discharge precedes admission for several records. Quarantine those records for temporal review while separately checking row counts and required relationships before allowing the dataset into operational reporting or downstream analysis.

Common pitfall: Passing schema validation does not establish semantic or clinical accuracy. Conversely, deleting every unusual value can remove genuine events that deserve investigation rather than automatic rejection.

PostgreSQL Documentation: Constraints · AMIA Health Informatics Certification: Outline of Exam Topics

41.What distinguishes HIPAA de-identification from removing names?

HIPAA permits two de-identification methods. Safe Harbor requires removing all specified identifier categories and having no actual knowledge that remaining information identifies a person. This includes removing patient-related date elements except year, with additional restrictions for ages over 89. Expert Determination requires a qualified expert to document methods and results showing very small identification risk for anticipated recipients using reasonably available information. These criteria apply to recognizable identifiers in narrative text as well as structured fields. See [HHS de-identification guidance](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html).

Apply it

A proposed research extract removes names but retains full admission dates. It does not meet Safe Harbor. Evaluate documented Expert Determination or, if appropriate, a limited data set: PHI with specified direct identifiers excluded, restricted to research, public health, or health care operations under a data use agreement. See [45 CFR 164.514](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514).

Common pitfall: Removing names or assigning replacement identifiers does not by itself establish de-identification. A data use agreement alone cannot convert identifiable information into de-identified information.

AMIA Health Informatics Certification: Outline of Exam Topics

42.How can a valid join inflate a quality measure?

A join can preserve valid keys yet multiply rows when one record matches several records in another table. This changes the unit of analysis unless aggregation or deduplication is planned deliberately. Establish whether each row represents a patient, encounter, order, or event before calculating a measure. Compare expected cardinality and counts before and after joins, because referential integrity alone does not ensure that the resulting denominator matches the analytic question.

Apply it

A patient table joins to three contact records per patient, tripling rows. To calculate a patient-level completion rate, define one outcome per eligible patient or aggregate contacts appropriately rather than counting joined rows as separate eligible people in the measure.

Common pitfall: Using DISTINCT without understanding the intended grain can hide an incorrect join or remove legitimate events. Fix the relationship and unit of analysis before summarizing.

PostgreSQL Documentation: Constraints · AMIA Health Informatics Certification: Outline of Exam Topics

43.How does preprocessing cause data leakage?

Data leakage occurs when information unavailable during legitimate model training influences the fitted model or its evaluation. Imputation, scaling, and feature selection can leak information when fitted on the full dataset before splitting. Fit learned preprocessing steps on training data and apply the fitted transformations to validation or test data. Pipelines help preserve this boundary during cross-validation, provided the split itself matches the intended deployment setting.

Apply it

An analyst selects predictive variables using all labeled records, then cross-validates the classifier. Move feature selection inside the training pipeline for each fold so held-out labels cannot influence which variables the model receives during its evaluation in that fold.

Common pitfall: Splitting only before the final estimator is insufficient if earlier learned transformations saw held-out data. A pipeline helps only when every relevant fitted step is included.

scikit-learn: Common Pitfalls and Recommended Practices

44.When should model evaluation separate patients or time?

Evaluation data should reflect the independence and information availability expected in deployment. Randomly splitting encounters can place the same patient's closely related records in training and testing, while random time mixing can expose future patterns. Choose patient-grouped, temporal, or combined separation according to the intended prediction task. The decisive question is whether the test estimates performance on genuinely new situations rather than on information closely related to what training already revealed.

Apply it

A model will predict next month's new admissions, but its test set contains later encounters from patients already represented in training. Reconsider patient overlap and use an appropriate future evaluation period to estimate the performance needed for the deployment decision.

Common pitfall: A large random test set is not automatically independent or realistic. Repeated patients and future information can inflate performance despite an apparently clean train-test split.

scikit-learn: Common Pitfalls and Recommended Practices · NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)

45.Why assess calibration as well as discrimination?

Discrimination describes how well a model separates or ranks people with different outcomes. Calibration concerns whether predicted probabilities agree with observed outcome frequencies. Good ranking does not guarantee accurate probabilities, especially after transfer to a different setting. When decisions depend on an absolute risk threshold, calibration directly affects who receives an intervention. Evaluate the property needed for the decision and examine performance in relevant groups and conditions.

Apply it

A model ranks patients well, but among those assigned 20% risk, only about 5% experience the outcome in local evaluation. Investigate calibration before using the displayed probability to trigger a resource-intensive service based on a 15% risk threshold.

Common pitfall: A strong ranking metric cannot validate the numerical meaning of a risk estimate. Threshold-based decisions may fail when probabilities are systematically too high or too low.

1.16. Probability calibration — scikit-learn 1.9.1 documentation · NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0) · AMIA Health Informatics Certification: Outline of Exam Topics

46.How should a predictive threshold reflect operational capacity?

A classification threshold converts a continuous score into a decision, changing the balance of true detections, missed events, and false alerts. Select it using the consequences of errors and the capacity to respond, rather than defaulting to an arbitrary probability. Estimate expected alert volume and predictive value in the target population. A threshold that detects more cases can still undermine the service if it creates an unmanageable review queue.

Apply it

A team can review forty alerts daily. Local evaluation shows one threshold produces thirty alerts and another produces two hundred. Compare missed cases, true alerts, and review burden before selecting and testing a threshold with the people responsible for responding.

Common pitfall: Maximizing sensitivity alone can overwhelm follow-up capacity. A threshold's usefulness depends on outcome frequency, error consequences, and whether the triggered action can actually be delivered.

NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0) · CDC: Updated Guidelines for Evaluating Public Health Surveillance Systems

47.Why validate a model in its intended setting?

Model performance depends on population, data collection, outcome definitions, workflow, and how predictions are used. Evidence from a development dataset cannot establish suitability in every deployment setting. Local or external evaluation should test the intended use, relevant subgroups, and the consequences of acting on predictions. A technically accurate model can still be unsuitable if its inputs arrive too late or its recommended workflow cannot support an effective response.

Apply it

A model developed in a referral center is proposed for community clinics. Before adoption, evaluate local input availability, outcome definitions, subgroup performance, calibration, and the ability of clinic teams to act on predictions within the intended decision window.

Common pitfall: Published performance does not automatically transfer across settings. A matching software version cannot compensate for differences in population, measurement, workflow, or the timing of available information.

NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)

48.What should production monitoring detect after model deployment?

Production monitoring should detect changes in inputs, outcome performance, subgroup effects, and the behavior of the surrounding workflow. Input drift may signal a problem but does not alone prove that predictive performance declined. Establish accountable review, alert thresholds, and options to investigate, limit, or suspend use. Monitor with suitable outcome delays in mind, because immediate input checks and later outcome evaluation answer different questions about continuing fitness.

Apply it

After a laboratory coding change, many model inputs become missing while outcome labels will take months to mature. The monitoring team investigates the input pipeline immediately and assesses whether use should be limited while later performance evidence accumulates.

Common pitfall: Waiting for a yearly accuracy review can miss an abrupt input failure. Automatic retraining without investigating causes may preserve a broken pipeline or introduce new risks.

NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)

Leadership, Professionalism, Strategy, and Transformation21%

49.How should ethical review assess unequal model effects?

Ethical evaluation asks who benefits, who bears errors or burdens, and whether the system's intended use is justified in context. Aggregate accuracy can conceal different error patterns across groups. Examine relevant performance measures, access to the resulting intervention, and the consequences of mistakes with affected stakeholders. Fairness involves choices about context and harms; selecting one numerical parity metric does not by itself establish that a deployment is acceptable.

Apply it

An outreach model identifies patients similarly across groups, but only patients with portal access receive follow-up. Leaders evaluate the full service pathway and add accessible contact options, recognizing that equitable model scores do not guarantee equitable access to the intervention.

Common pitfall: Treating fairness as a single model statistic overlooks workflow and access. Equal predictions can still produce unequal benefits when the resulting service is delivered differently.

NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0)

50.When does a competing interest require management?

A competing interest arises when a personal, financial, or professional relationship could influence, or reasonably appear to influence, an entrusted judgment. Recognition and disclosure allow the responsible organization to determine an appropriate management response. Depending on the role and decision, that response can include limits on participation or recusal. Disclosure provides information for management; it does not automatically remove the conflict or authorize unrestricted involvement.

Apply it

A procurement committee member has a paid consulting relationship with a finalist. The member discloses the relationship before evaluation, and the organization determines participation limits so that vendor scoring and the final recommendation remain appropriately independent of that relationship.

Common pitfall: Believing oneself impartial does not eliminate a competing interest or its appearance. Disclosure should precede the decision, and management may require more than recording the relationship.

AMIA Conflict of Interest Policy · AMIA-Conflict-of-Interest-Policy.pdf

51.How does an informatics strategy connect to measurable value?

An informatics strategy connects an organizational problem with a proposed capability, expected outcomes, and a way to judge whether the investment helped. Define the baseline, target population, measures, ownership, and important dependencies before choosing technology. Measures should reflect the operational or health objective rather than only installation milestones. A system can be delivered successfully yet fail strategically if adoption, workflow, or service capacity prevents the intended benefit.

Apply it

Leaders propose a referral platform to reduce unresolved referrals. The business objective specifies a baseline completion rate, a defined patient population, accountable owners, and follow-up measures, linking platform implementation to the service outcome the investment is intended to improve.

Common pitfall: Counting installed modules as strategic success confuses delivery with value. A measurable objective must describe the intended change in service, outcomes, or organizational capability.

Health IT Playbook: Electronic Health Records

52.Why involve stakeholders before configuring a new workflow?

Stakeholders reveal requirements, dependencies, concerns, and work that may be invisible to the implementation team. Involving affected roles early helps identify how a proposed change redistributes tasks and where adoption barriers will arise. Participation should support concrete decisions and feedback rather than merely announce a completed design. Include people who perform the work and those affected by its results, especially when a change crosses organizational boundaries.

Apply it

A scheduling redesign moves verification tasks from registration to nurses. Early workshops include both groups and patients, allowing the team to test responsibility, staffing, and access implications before configuration fixes the new workflow and makes later changes more costly.

Common pitfall: Senior sponsorship does not substitute for understanding frontline work. Asking users for feedback only after configuration can leave consequential requirements expensive or impractical to address.

Health IT Playbook: Electronic Health Records

53.What should a project charter make explicit?

A project charter establishes the problem, intended objectives, high-level scope, sponsorship, authority, and conditions for success. It creates a shared basis for planning and later decisions about proposed changes. Clear boundaries help distinguish essential work from attractive additions. The charter should be specific enough to resolve foreseeable disagreements while leaving detailed execution to the project plan, requirements, and governance processes appropriate to the project's complexity.

Apply it

A results-management project initially covers outpatient laboratory follow-up. Its charter names the sponsor, accountable team, intended outcome, and excluded imaging workflows, giving the team a clear basis to evaluate a later request to expand the project to imaging.

Common pitfall: A broad aspiration such as improve digital care cannot reliably control scope. Without explicit objectives and authority, competing stakeholders may assume incompatible commitments and priorities.

PMI: Scope Change Control · AMIA Health Informatics Certification: Outline of Exam Topics

54.How should a requested scope change be evaluated?

A scope change should be described, assessed for effects on cost, schedule, resources, risk, and expected benefit, and decided through the authorized process. Approval should be followed by updates to the relevant baseline and plans. The size of the request is not determined only by its screen appearance; apparently small changes can affect interfaces, testing, training, or support. Make trade-offs visible before committing delivery work.

Apply it

During implementation, a sponsor asks for an additional reporting feed. The project manager documents the request, assesses interface and testing dependencies, estimates schedule and cost effects, and obtains the authorized decision before updating the delivery plan and assigning the work.

Common pitfall: Accepting every apparently small request can accumulate major unplanned work. Verbal enthusiasm is insufficient when the change alters commitments that other teams and resources depend on.

PMI: Scope Change Control

55.Why track dependencies rather than dates alone?

A project schedule represents relationships among tasks as well as planned dates. A dependent activity cannot be completed meaningfully until its required inputs are ready. Tracking dependencies reveals how a delay propagates and where mitigation can change the completion outlook. A milestone is useful evidence only when its completion criteria are defined. Reporting all tasks as nearly complete can conceal an unresolved prerequisite that prevents integrated testing or safe deployment.

Apply it

Training is scheduled before workflow configuration is finalized. The project manager identifies the dependency, assesses the risk of teaching an obsolete process, and adjusts sequencing or content approval rather than preserving a date that would undermine readiness for the actual release.

Common pitfall: Moving milestone dates without examining prerequisites can create an impossible plan. Task completion percentages are weak indicators when the remaining dependency blocks every downstream activity.

PMI: Scope Change Control · GAO: Cost Estimating and Assessment Guide

56.Which costs belong in an informatics business case?

A business case should consider costs across the intended life cycle, including acquisition, implementation, interfaces, data conversion, training, operations, support, upgrades, and retirement where applicable. Define scope, time horizon, assumptions, and the basis of estimates so alternatives are comparable. A lower purchase price can be outweighed by recurring or transition costs. Link benefits to plausible mechanisms and avoid treating uncertain future savings as already realized.

Apply it

Two systems have different license prices. The team compares a common five-year scope including migration, interface maintenance, staff backfill, training, hosting, and support, then documents which benefits depend on changes in workflow or service utilization after implementation.

Common pitfall: Comparing purchase prices alone rewards incomplete estimates. Omitting staff effort or ongoing maintenance does not eliminate those costs; it merely hides them from the decision.

GAO: Cost Estimating and Assessment Guide

57.How does sensitivity analysis improve an investment decision?

Sensitivity analysis tests how an estimate or preferred option changes when important assumptions vary. It identifies which inputs drive the conclusion and whether plausible uncertainty could reverse it. Distinguish a carefully specified base estimate from the range of possible outcomes. Focus additional investigation on influential uncertain assumptions, such as adoption or maintenance effort, rather than adding precision to minor inputs that barely affect the decision.

Apply it

A platform's financial benefit depends heavily on staff time saved. The team varies adoption and time-savings assumptions across plausible values, finds the investment is unfavorable at modest adoption, and strengthens the implementation plan before recommending funding for the proposed system.

Common pitfall: A precise single estimate can disguise fragile assumptions. Testing only favorable scenarios provides little insight into uncertainty or the conditions under which an investment fails.

GAO: Cost Estimating and Assessment Guide

59.Why should training follow roles and realistic tasks?

Training should prepare each role to perform its actual tasks, including exceptions, handoffs, and recovery from common errors. A single generic tour can leave users familiar with screens but unable to complete their work. Use representative scenarios and practice opportunities tied to the deployed configuration. Prioritize consequential workflows and verify task performance so that attendance or exposure is not mistaken for readiness to use the system safely.

Apply it

A new referral system gives schedulers, clinicians, and supervisors different responsibilities. Training uses role-specific cases and cross-role handoffs, then checks whether each group can complete ordinary and exception workflows in the configured environment before independent use of the system.

Common pitfall: Teaching every feature to every user can dilute essential practice. Completion certificates and favorable course ratings do not demonstrate that staff can perform their assigned work.

Health IT Playbook: Electronic Health Records

60.How should leaders govern workforce access to protected information?

Authentication establishes user identity; authorization determines permitted information and actions. HIPAA access policies must align ePHI access with workforce responsibilities. Define who approves access, the needed data and functions, and how privileges are reviewed, changed, or terminated as duties change. Unique user identifiers support individual accountability. See the [HHS Security Rule summary](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html), [unique-user guidance](https://www.hhs.gov/hipaa/for-professionals/faq/does-the-security-rule-permit-a-covered-entity-to-assign-the-same-log-on-id-to-multiple-employees/index.html), and [access-management audit criteria](https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html).

Apply it

Staff demonstrate referral completion in training but lack that function in production. Confirm the duty is authorized, approve the specific role permission, and verify task completion. Preserve restrictions on unrelated records and administrative functions, and remove obsolete permissions after reassignment.

Common pitfall: Successful login does not authorize every action. Shared accounts weaken accountability; blanket administrator privileges introduce unnecessary access instead of correcting a specific role gap.

AMIA Health Informatics Certification: Outline of Exam Topics

What to focus on during revision

The following are CertMedbry study suggestions. Use the official outline to check the full scope of your examination.

  • Use the official five-domain outline as the full scope, then prioritize unfamiliar operational tasks rather than only topics encountered in your current role.
  • Distinguish successful transmission from preserved meaning, and valid database structure from accurate patient or clinical relationships.
  • Establish disclosure authority, applicable minimum-necessary limits, role authorization, and de-identification criteria before choosing technical safeguards.
  • Connect decision-support interruptions, workflow changes, and quality measures to an explicit mechanism and an actionable response.
  • Practise end-to-end testing, security risk mitigation, identity reconciliation, downtime recovery, and accountable result follow-up through exception cases.
  • Explain how leakage, evaluation design, calibration, subgroup effects, and production changes alter the credibility of predictive analytics.
  • Make implementation trade-offs explicit through scope control, life-cycle estimates, stakeholder participation, and demonstrated task readiness.

A practical preparation plan

1. Map experience against the complete outline

For each official task and knowledge statement, record whether you can explain it, apply it, and recognize a failure mode. Use the published 17%, 21%, 21%, 20%, and 21% domain weights to distribute study effort while giving extra attention to genuine gaps.

2. Work through the concept applications

State the intended outcome, identify the decisive cue, and propose an action before reading each pitfall. For calculations, write the numerator, denominator, time basis, and unit of analysis explicitly. For data sharing, identify the legal basis, recipient, information scope, and applicable safeguards.

3. Trace complete operational workflows

Practise an order-to-result pathway, a patient identity correction, an interface failure, and an unplanned outage. Identify responsibility, authorization, exception handling, evidence of completion, and recovery steps at each handoff. Match security controls to the threats and vulnerabilities they address.

4. Challenge analytic conclusions

For each proposed dashboard or model, ask what population it represents, how data were transformed, whether evaluation information leaked, and which performance property supports the intended decision. Include subgroup and capacity implications, and distinguish de-identified data from identifiable or limited data sets.

5. Use drills to explain alternatives

Complete the 20 questions independently, then explain why every alternative is less appropriate. Review flashcards with active recall and return to the relevant concept when you cannot state the mechanism or boundary.

6. Close gaps beyond the selective guide

Revisit uncovered areas of AMIA's full outline using its suggested references, relevant primary standards, and practical observation of unfamiliar informatics roles. Keep administrative policies separate from substantive concept review.

Use your sample score as a starting point

The free set contains 20 original practice questions. It is a small learning sample, not an official examination or a validated pass prediction. Review each explanation and its source before moving to another topic.

Start the free sample

Official sources and updates

Confirm current eligibility, fees, scheduling and policies directly with the examination provider. CertMedbry is independent and is not endorsed by these organisations. How we handle content and corrections.