Health Information & Coding · Independent exam preparation
AMIA Health Informatics Certification (AHIC): Applied Preparation Guide Study Guide
Practise safer system design, workflow improvement, data governance, model evaluation, and leadership decisions across the five official AHIC examination domains.
By CertMedbry · Updated 29 October 2026
Practise choosing useful decision support, investigating interface failures, defining trustworthy measures, evaluating predictive models, and leading accountable implementation. This selective guide develops 60 substantive concepts aligned with the published outline for AMIA's transitioning AHIC program; examination arrangements require confirmation under AMIA's transition guidance. The official AHIC Outline of Exam Topics defines the full examination scope; use it to identify additional knowledge statements and gaps beyond this guide. Concept allocation is 10/13/12/12/13 across the domains in outline order, approximating the published weights.
Try 20 free practice questionsWhat is the exam format?
Check the question types, timing and outline before planning your revision.
What has AMIA announced about the program's status?
AMIA's program page announces that the current AHIC program will conclude and that existing ACHIP holders will retain their credential permanently. AMIA is developing transition guidance for applicants and examinees; no replacement program has been finalized. The announcement does not establish a closure date or assure current examination scheduling. Consult AMIA's program page and certification staff for the arrangements applicable to your situation. The examination logistics below describe the dated Program Guide, rather than establishing unchanged availability during the transition.
AMIA Health Informatics Certification (AHIC) · AHIC Program Guide
What certification and professional level does this guide address?
This guide addresses AMIA Health Informatics Certification, administered through AMIA’s independently governed Health Informatics Certification Commission. Successful candidates earn the AMIA Certified Health Informatics Professional designation, ACHIP. The program assesses experienced professionals applying informatics to operational challenges across healthcare, public health, and consumer health.
AMIA Health Informatics Certification (AHIC) · AHIC Program Guide
How do the historical name and different eligibility tracks relate to this examination?
AMIA’s 2016 position-paper abstract used “advanced health informatics certification” for the developing initiative. Issuer materials name the program AMIA Health Informatics Certification. The Program Guide with cover revision 2026-01-16 describes eligibility tracks based on informatics graduate degrees, related graduate degrees, or relevant baccalaureate degrees, with qualifying experience requirements. These are routes to the same AHIC examination, rather than separate nursing, physician, or computing examinations. This guide covers their shared examination outline; transition guidance governs any changes affecting applicants.
Creating advanced health informatics certification · AHIC Program Guide · AMIA Health Informatics Certification (AHIC)
How many questions are scored, and are there pretest questions?
The Program Guide with cover revision 2026-01-16 specifies 150 multiple-choice items, all scored. It therefore identifies no unscored pretest items within that total. Each actual examination item has three answer options. These are the dated handbook's specifications, subject to AMIA's program-transition guidance.
AHIC Program Guide · AMIA Health Informatics Certification (AHIC)
How long is the examination, and how is it delivered?
The Program Guide with cover revision 2026-01-16 allows four hours and describes secure, computer-based delivery through Pearson VUE test centers worldwide, using multiple equated examination forms with items presented in random order. It does not describe computer-adaptive delivery; randomized presentation should not be interpreted as adaptivity. The handbook's delivery description does not confirm current appointment availability during the program transition.
AHIC Program Guide · AMIA Health Informatics Certification (AHIC)
How are scores reported?
The Program Guide with cover revision 2026-01-16 states that scores range from 0 to 800 and that a scaled score of at least 600 is required to pass. This is not a published raw percentage threshold. Incorrect responses receive zero points, without a penalty. Reports summarize performance by major domain without identifying individual answered items. These scoring details describe the dated handbook.
Which blueprint and dates apply?
The issuer-linked outline bears copyright 2018–2021 and states no separate revision or effective date. Its domain 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 Program Guide has a cover revision of 2026-01-16, while internal footers retain “Effective April 2021, Rev. 2025-10-15.” These dates do not establish a new outline effective date or resolve examination availability under AMIA's program-transition announcement.
AMIA Health Informatics Certification: Outline of Exam Topics · AHIC Program Guide · AMIA Health Informatics Certification (AHIC)
Does AHIC include United States practice requirements?
Yes. The Program Guide states that the examination reflects the scope of health informatics practice within the United States and includes US-specific material, such as relevant law. Eligible applicants may reside or have trained outside the United States. HIPAA examples in this guide explicitly concern US covered organizations; they should not be treated as universal privacy rules.
AHIC Program Guide · Guidance Regarding Methods for De-identification of Protected Health Information
How should the practice questions and flashcards be used?
The 20 original practice questions use four options to support discrimination between plausible decisions, although the dated Program Guide specifies three options for actual AHIC items. They are independent learning drills, without a simulated adaptive pathway or pass prediction. Questions and flashcards use a 3/4/4/4/5 domain allocation to approximate the blueprint in a small set. The official outline remains the full scope.
AHIC Program Guide · AMIA Health Informatics Certification: Outline of Exam Topics
AHIC assesses operational health informatics competence across professional backgrounds. This independent guide addresses the published AMIA Health Informatics Certification examination outline and the associated ACHIP designation. The historical phrase “advanced health informatics certification” describes the program’s development, rather than a separate examination.
Outline used: Current issuer-linked AHIC Outline of Exam Topics, copyright 2018–2021, consulted 2026-10-11; no separate outline revision or effective date stated. Current linked AHIC Program Guide cover: Rev. 2026-01-16; internal footers: Effective April 2021, Rev. 2025-10-15. The workbook label 'Advanced Health Informatics Certification' maps to AMIA's historical development terminology, evidenced by its 2016 position-paper abstract; the current official examination is AMIA Health Informatics Certification (AHIC). 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.What distinguishes syntactic from semantic interoperability?
Syntactic interoperability lets systems parse exchanged structures; semantic interoperability preserves the intended meaning of their contents. A correctly formatted message can still misrepresent a measurement when units, codes, or contextual definitions differ. FHIR supplies exchange structures, but useful interoperability also requires agreements about terminology and interpretation. The discriminating question is whether the receiving system can use the information correctly, rather than merely accept its format or display its text.
Apply it
Two laboratories exchange valid observations, but one reports a concentration in a different unit. Require explicit units and validated interpretation at the receiving system before allowing either result to drive the same decision rule.
Common pitfall: Treating successful transmission as proof of shared meaning overlooks unit mismatches, ambiguous local codes, and contextual differences that can survive structural validation.
2.How do FHIR resources and references represent clinical information?
FHIR organizes information into resources representing defined concepts, such as patients, observations, and encounters. References connect resources so that a result can identify its subject and relevant context without embedding every related record. The important distinction is between a resource’s own identity and the identities it references. Receiving systems must resolve or otherwise handle those relationships according to the exchange agreement; a readable observation without a reliable subject link remains operationally incomplete.
Apply it
An application receives an observation and its patient reference, but the referenced patient cannot be resolved. Investigate identifier handling and reference resolution before presenting the result as belonging to a locally selected patient record.
Common pitfall: Assuming a resource is self-sufficient can detach a result from its patient or encounter, even when the resource itself passes structural validation.
3.Why are FHIR profiles and implementation agreements necessary?
FHIR’s base specification supports varied use cases, leaving choices that implementations must narrow. Profiles constrain resource use, including cardinality, terminology bindings, and required elements, while implementation agreements specify shared behavior for a particular exchange. Two systems can both support FHIR yet make incompatible choices. When an integration fails despite valid base resources, examine the agreed profiles, versions, terminology, and supported interactions before concluding that the transport mechanism is defective.
Apply it
A referral receiver requires a coded urgency field that the sender omits. Compare both implementations against the agreed referral profile, establish the required binding and cardinality, and test representative referrals before enabling production routing.
Common pitfall: Buying two products advertised as FHIR-enabled does not establish agreement about versions, required fields, terminology, authentication, or the supported exchange workflow.
4.When should transactional and analytical database workloads be separated?
A transactional database supports frequent, consistent updates to operational records; an analytical store supports queries across large collections and historical periods. A normalized relational design separates related entities and uses keys to reduce redundant facts and inconsistent updates. An analytical warehouse may reorganize those facts into dimensions and event tables for reporting. Choose architecture according to update consistency, query workload, historical requirements, and acceptable data latency. Separating workloads can protect operational responsiveness, but introduces a data-transfer process whose completeness and freshness must be checked.
Apply it
A hospital's nightly historical reports slow order entry when they scan the operational database. Consider a separate analytical store with a defined refresh interval, preserve patient and encounter relationships during transfer, and show the refresh time so users do not mistake yesterday's snapshot for current operational status.
Common pitfall: A warehouse is not automatically suitable for real-time decisions. Conversely, adding reporting indexes alone may not address competition between heavy analytical scans and time-sensitive transactional updates.
AMIA Health Informatics Certification: Outline of Exam Topics
5.What do sensitivity and specificity measure?
Sensitivity is the proportion of people with the target condition who test positive: true positives divided by true positives plus false negatives. Specificity is the proportion without the condition who test negative: true negatives divided by true negatives plus false positives. Their denominators begin with actual condition status. These measures answer different questions from predictive values, which begin with the observed test result. Always construct the two-by-two table before interpreting an unfamiliar performance claim.
Apply it
Among 200 people known to have a condition, a classifier flags 170. Its sensitivity is 170 divided by 200, or 85%. The remaining 30 are false negatives, regardless of results among people without the condition.
Common pitfall: Dividing true positives by all positive results calculates positive predictive value, not sensitivity. Changing the denominator changes the question being answered by the statistic.
6.Why does prevalence affect positive predictive value?
Positive predictive value is the proportion of positive results that are true positives. With sensitivity and specificity held constant, lower prevalence generally reduces positive predictive value because unaffected people contribute more false positives relative to true positives. A detector’s apparent success in a high-prevalence sample therefore may not transfer to broad screening. Use the target population’s prevalence and a complete two-by-two table when estimating the work generated by positive results.
Apply it
In 1,000 people, 10 have the condition. A detector finds nine and produces 99 false positives. Positive predictive value is 9 divided by 108, about 8.3%, creating substantial review work despite finding most cases.
Common pitfall: High sensitivity alone does not mean most positive alerts are correct. Predictive value also depends on false positives and the population’s underlying prevalence.
7.How do data grain and keys prevent misleading analyses?
Data grain defines what one row represents, such as a person, encounter, order, or result. A key identifies a row at that grain and allows relationships to be checked. Before calculating a rate or joining tables, specify both the analytical unit and the expected relationship between records. Patient-level and encounter-level questions require different denominators. Repeated identifiers may be correct in an encounter table but signal a defect in a supposedly unique patient table.
Apply it
A report asks how many patients attended follow-up, but its source has one row per visit. Count distinct eligible patients using a defined patient key, and separately report visit volume if operational workload is also relevant.
Common pitfall: Counting rows as people inflates results when individuals have multiple encounters. Removing all repeats can instead destroy legitimate event-level information needed for other questions.
AMIA Health Informatics Certification: Outline of Exam Topics · Common Data Elements: Standardizing Data Collection
8.Why can a database join multiply records?
A join produces a row for each matching combination. If an encounter has three orders and four diagnoses, joining both child tables directly by encounter can yield twelve rows. The multiplication is a consequence of relationship cardinality, rather than evidence of twelve separate orders. Determine the intended output grain, inspect uniqueness, and aggregate or link each source appropriately. Reconcile counts before and after joining so valid relationships do not become inflated measures.
Apply it
An analyst joins orders and diagnoses, then reports four times as many orders. Aggregate diagnoses to the required encounter-level feature or use an appropriate existence test, and verify that each order retains its intended counting unit.
Common pitfall: Applying a blanket distinct operation may conceal the join problem while dropping legitimate repeated events. Correct the relationship and counting rule before deduplicating results.
AMIA Health Informatics Certification: Outline of Exam Topics
9.What separates de-identification from restricted access?
Restricted access controls who may obtain data; de-identification addresses whether information identifies individuals under an applicable standard. For a US HIPAA covered organization, removing direct names does not alone establish de-identification. HIPAA recognizes Safe Harbor and Expert Determination methods, each with specific conditions. A dataset may be securely protected yet remain identifiable. Decide separately whether the planned use is authorized, what access safeguards apply, and whether a recognized de-identification method has actually been satisfied.
Apply it
A hospital proposes sharing a password-protected file containing full service dates but no names as de-identified data. Evaluate a recognized HIPAA method and the remaining identifiers; password protection alone does not establish de-identification status for the proposed release.
Common pitfall: Encryption and confidentiality agreements reduce exposure but do not themselves turn identifiable information into de-identified information under HIPAA or remove applicable disclosure requirements.
Guidance Regarding Methods for De-identification of Protected Health Information
10.How does the payment model change an informatics investment's financial case?
Fee-for-service payment generally links revenue to separately reimbursable services, whereas capitation pays a defined amount per covered person for an agreed period and scope of services. These arrangements distribute financial consequences differently. Preventing an avoidable visit may reduce a payer's spending, reduce a provider's service revenue, or reduce costs borne by a provider receiving a fixed payment, depending on the contract. Separate patient benefit, resource use, and each stakeholder's cash flow. Evaluate payment terms, covered services, and variable versus fixed costs before claiming savings.
Apply it
Compare an outreach service under two hypothetical contracts. Under a fixed payment that includes the avoided visits, the provider may retain reduced variable costs. Under payment per visit, avoided visits may also reduce revenue. In both cases, budget outreach staffing and technology, and distinguish released staff capacity from actual expenditure reductions.
Common pitfall: Multiplying avoided visits by charges does not establish cash savings. Payment rates, contractual incentives, avoidable costs, and the stakeholder bearing those costs determine the financial effect.
AMIA Health Informatics Certification: Outline of Exam Topics
Enhancing Health Decision-making, Processes, and Outcomes21%
11.Which decision support fits the decision being improved?
Decision support should address a defined decision, reach the responsible person at a useful point in work, and offer an actionable response. Interruptive alerts consume attention and are best justified by sufficient importance and relevance. Other approaches include order design, contextual information, and noninterruptive reminders. Start with the failure mechanism: missing information, forgotten action, ambiguous options, and unclear responsibility call for different interventions. Evaluate whether the chosen support improves the intended behavior and outcome.
Apply it
Clinicians repeatedly omit a routine field needed later, while urgent warnings already interrupt ordering. Test a clearer field and contextual completion cue at entry, then measure completeness and added task time before considering another interruptive warning.
Common pitfall: Selecting an alert because it is easy to configure can add noise without addressing the actual cause, timing, or responsible actor in the workflow.
12.Why does alert fatigue require selective optimization?
Alert fatigue develops when frequent or low-value warnings desensitize users, making important warnings easier to overlook. Optimization therefore examines clinical relevance, interruptiveness, duplicate firing, timing, and available actions. Override rates can identify candidates for review but do not alone prove an alert is useless, because some overrides are appropriate. Assess response patterns alongside safety outcomes and user experience. Prefer selective changes with monitoring over indiscriminate removal or universal escalation of all warnings.
Apply it
An alert fires on nearly every order and is usually overridden. Review sampled cases and downstream events, identify irrelevant triggers, and test a more specific rule while monitoring whether clinically important warnings remain visible and acted upon.
Common pitfall: A high override rate is a signal for investigation, not sufficient evidence to disable a warning. Raising every warning’s severity can worsen desensitization.
13.How should decision-support knowledge be maintained?
Decision support is maintained knowledge implemented in software. Its logic, evidence basis, terminology dependencies, owner, approval history, and review triggers should be traceable. Changes in source guidance or local workflows can make a previously useful rule inaccurate or disruptive. Before releasing a revision, assess its downstream effects and test representative cases, including boundary conditions. Monitoring after release checks whether the updated rule behaves as intended in actual work and whether unexpected consequences require correction.
Apply it
A local order code used by a reminder is retired. The rule owner updates the mapping, tests eligible and ineligible cases, obtains approval, and monitors firing rates after release to detect silent loss of the intended decision support.
Common pitfall: Changing narrative guidance without changing encoded logic leaves the operational recommendation stale. Updating code without ownership and review makes later interpretation and correction difficult.
14.How should a decision threshold reflect consequences?
A threshold converts a score into an action. Lowering it commonly increases sensitivity while creating more positive classifications and false positives; raising it commonly does the reverse. The appropriate choice depends on missed-case consequences, unnecessary-action harms, available capacity, and the intended population. Rank discrimination alone cannot select the threshold. Compare plausible thresholds using their expected workload and error patterns, then evaluate the resulting intervention rather than assuming that the most sensitive setting is automatically best.
Apply it
A review team can investigate 40 cases daily. A proposed threshold identifies 300, mostly false positives. Compare thresholds and workflow alternatives using missed-case consequences and review capacity before authorizing an operating point that cannot be acted upon.
Common pitfall: Maximizing one performance statistic can ignore consequential errors and operational capacity. A detector provides little benefit when positive classifications cannot receive the intended response.
Principles of Epidemiology: Lesson 5, Appendix A · AI Risks and Trustworthiness
15.What distinguishes outcome, process, and balancing measures?
Outcome measures assess the result an improvement seeks, process measures assess whether intended actions occur, and balancing measures detect adverse effects elsewhere. Together they connect intervention delivery to benefit while exposing tradeoffs. A higher completion rate for a new workflow is a process change until its intended result is demonstrated. Choose measures that are feasible, operationally defined, and sensitive to the proposed change, and review them together rather than letting one favorable number dominate.
Apply it
A team introduces faster discharge preparation. Track discharge delay as the outcome, completion of preparation steps as the process, and staff overtime as a balancing measure to detect whether faster throughput shifts an unsustainable burden onto staff.
Common pitfall: A process measure may improve without improving the intended outcome. A favorable outcome can also conceal new burdens when balancing measures are absent or ignored.
16.How do operational definitions make improvement measures trustworthy?
An operational definition specifies exactly what is counted, the eligible denominator, relevant timestamps, exclusions, and collection method. It allows different observers or systems to calculate the same measure consistently. Ambiguous terms such as timely or completed permit inconsistent classification and undermine comparison. Define the measure before testing a change, document revisions, and examine whether apparent improvement coincides with a collection change. Consistency supports learning without implying that a measure captures every dimension of quality.
Apply it
A project defines timely review as acknowledgment within an agreed interval from result availability, with a specified eligible-result set. Analysts test the definition against sample records before comparing baseline and post-change performance across sites using identical rules.
Common pitfall: Allowing each team to interpret completion locally makes aggregate trends difficult to explain. Retrospectively changing the definition can manufacture improvement without changing underlying performance.
Model for Improvement: Establishing Measures · Common Data Elements: Standardizing Data Collection
17.Why should improvement results be stratified?
An overall average can hide different experiences or outcomes across relevant groups. Stratification examines whether a change benefits populations comparably or leaves a subgroup behind. Select meaningful strata, check data completeness, and interpret small groups cautiously. Improvement should be assessed both overall and across the groups relevant to the intervention. A successful aggregate result does not establish equitable benefit, especially when access to the technology or completeness of follow-up differs across the population.
Apply it
Portal-based reminders improve overall appointment attendance. Stratify by preferred language and portal access, then investigate whether people without usable portal access experienced little improvement and need a different contact channel to receive the same intended support.
Common pitfall: Reporting only the aggregate can conceal worsening disparities. Conversely, unstable percentages from very small groups should trigger careful investigation rather than sweeping causal conclusions.
18.How does a PDSA cycle create actionable learning?
Plan-Do-Study-Act tests a change by stating a prediction, trying it on an appropriate scale, comparing observations with the prediction, and deciding what to adapt next. The cycle’s value comes from explicit learning, rather than simply completing four named stages. Small tests reduce exposure while revealing practical conditions and unexpected effects. Record what happened and why the next test differs. Repeated cycles can expand across users, settings, or workload conditions as confidence grows.
Apply it
A clinic tests a revised handoff with one team for one shift, predicting fewer clarification calls. It records calls and delays, compares results with the prediction, and revises the handoff before testing under a busier shift.
Common pitfall: Calling a large rollout a PDSA cycle does not supply a prediction, study findings, or adaptation. Activity without explicit learning is weak evidence for spread.
19.When is a tested change ready for broader implementation?
Testing asks whether and how a change works under specified conditions; implementation establishes the structures needed for routine use. Before broader adoption, examine evidence across relevant settings, shifts, and users, including balancing effects. A successful initial test supports another informed decision, not automatic universal spread. Implementation then requires ownership, training, resources, and ongoing measurement. The discriminating clue is whether the organization has demonstrated dependable performance and can support the change beyond the original enthusiastic team.
Apply it
A workflow succeeds during a weekday pilot with an experienced team. Before making it standard, test evening coverage and unfamiliar staff, address observed failures, and establish responsibility for training and routine monitoring after the broader implementation.
Common pitfall: Success under unusually favorable pilot conditions may not transfer to routine operation. Endless testing without an implementation decision can also delay a well-supported improvement.
Model for Improvement: Testing Changes · SAFER: Organizational Responsibilities
20.How does workflow mapping reveal improvement opportunities?
Workflow mapping makes the sequence of tasks, decisions, information transfers, and responsible roles explicit. Observation of current work helps reveal waiting, duplicate entry, unclear handoffs, and differences between policy and practice. Map the current process before assuming what a new system should automate. Then evaluate proposed future work with the people performing it. The most useful map answers who acts, using what information, under which conditions, and what happens when the normal path fails.
Apply it
Referral delays appear to originate in software, but mapping shows that incomplete requests wait in an unassigned queue. Redesign required information and queue ownership, then test elapsed time and rework before deciding whether additional automation is necessary.
Common pitfall: Automating an assumed workflow can accelerate an unreliable process. A map based only on policy documents may miss informal coordination that currently keeps work functioning.
21.What can repeated workarounds reveal about process design?
A workaround is an adaptation that bypasses or supplements the designed process. Repeated workarounds may reveal unmet information needs, poor task sequencing, access limitations, or conflicting demands. Observe the conditions and consequences before choosing a response. Some adaptations sustain necessary work while introducing new risks, such as delayed documentation or untracked handoffs. Redesign should preserve the useful function the workaround serves while reducing its hazards and making responsibility and information flow visible.
Apply it
Staff maintain an unofficial spreadsheet because the official referral queue cannot show pending follow-up. Identify the missing tracking function, assess privacy and reconciliation risks, and test a supported queue view that provides status and ownership within normal work.
Common pitfall: Banning the workaround before replacing its useful function can disrupt care coordination. Formalizing it without examining risks can institutionalize duplicate records and hidden dependencies.
22.Why does result follow-up require more than acknowledgment?
Result availability, delivery, acknowledgment, and appropriate follow-up are separate events. A closed-loop process identifies who owns review, how action is documented, who covers absence, and when unresolved results escalate. An acknowledgment can show that someone opened or accepted a result without establishing that the required next step occurred. Measure the endpoint relevant to the intended safety goal, and investigate failures at each transition rather than treating electronic delivery as completion of the clinical communication process.
Apply it
A dashboard shows every result acknowledged, yet several requested repeat tests were never arranged. Add explicit follow-up status and responsible ownership, with escalation for overdue actions, while retaining acknowledgment as a separate intermediate event in the process.
Common pitfall: Equating a viewed result with completed care can hide unresolved action. Escalation without a receiving owner merely sends additional messages into an unaccountable process.
23.How should population outreach effectiveness be evaluated?
Outreach effectiveness requires a defined eligible population, evidence that contact occurred, and an outcome aligned with the program’s aim. Message delivery is a process measure, while completed follow-up may be the desired result. Separate unsuccessful contact, refusal, unavailable services, and undocumented outcomes so different barriers remain visible. Review balancing effects and subgroup performance. A high response among reachable people can coexist with poor population coverage when those excluded from digital contact disappear from the denominator.
Apply it
A reminder campaign reports excellent completion among message recipients but excludes people with missing contact details. Retain all eligible patients in the population measure and separately assess reach, completion, access barriers, and performance across relevant groups.
Common pitfall: Restricting analysis to people successfully contacted can overstate population benefit. A delivered message is evidence of transmission, not proof of understanding or completed follow-up.
Model for Improvement: Establishing Measures · Workflow Assessment for Health IT Toolkit
Health Information Systems (HIS)21%
24.How should requirements become testable acceptance criteria?
A useful requirement states the user need and conditions under which a system must perform. Acceptance criteria translate that need into observable behavior, including important exceptions. Vague requests such as make results safer cannot establish whether a delivered feature is adequate. Link requirements to workflow, risk, and test cases, and involve affected users in validation. The discriminating question is whether an independent reviewer could determine, from agreed evidence, that the required behavior has been achieved.
Apply it
A clinic requests reliable coverage for absent result reviewers. Define how absence is recorded, which covering role receives results, how unresolved work escalates, and which test cases must demonstrate these behaviors before the feature is accepted.
Common pitfall: A feature demonstration can appear convincing while omitting exception paths. Accepting vague requirements shifts disagreements to implementation, when correction is more disruptive and costly.
Workflow Assessment for Health IT Toolkit · SAFER: Test Results Reporting and Follow-Up
25.Why is end-to-end interface testing necessary?
Component tests establish that individual parts perform specified functions; end-to-end tests examine the complete information path and resulting workflow. A message may leave one system correctly yet arrive with an altered code, unit, patient association, or display. Test representative inputs through transmission, transformation, storage, presentation, and downstream use. Include relevant exceptions and verify the final operational meaning. Successful transport acknowledgments cannot by themselves demonstrate that a result is safe to interpret or act upon.
Apply it
An interface receives a successful acknowledgment for each laboratory message. Test selected source results through the receiving display and decision support, checking patient identity, units, reference information, and final routing before concluding that the exchange works correctly.
Common pitfall: Testing only message acceptance misses downstream transformation and display errors. Testing only the screen misses whether stored values and automated rules receive the same meaning.
26.How should testing change after a system update?
An update can alter both the intended feature and dependent functions. Risk-based regression testing selects existing workflows whose behavior could be affected, alongside tests of the new capability. Interface mappings, routing, identity handling, and decision support deserve attention when their dependencies change. Preserve a known configuration baseline and compare expected results with actual behavior. Post-release monitoring complements testing by detecting unexpected patterns, but it does not replace pre-release evidence for foreseeable high-impact failures.
Apply it
A terminology update changes a result code used by an interface and reminder. Test the new mapping and rerun representative result display, routing, and reminder cases, then monitor production volumes for unexpected disappearance or duplication after release.
Common pitfall: Restricting testing to the advertised new feature ignores shared dependencies. Assuming unchanged code guarantees unchanged behavior overlooks altered data, configuration, terminology, and external interfaces.
27.How should uncertain patient matches be handled?
Patient matching compares identifying information to determine whether records belong to the same person. Similar names or partial demographic agreement are insufficient when conflicting evidence remains. A safe process defines matching rules, identifies uncertain candidates, and routes ambiguity to trained review rather than forcing a merge. The decision balances duplicate creation against wrong-person association. Consistent registration practices and monitoring of matching errors support reliability; an attractive match score does not erase contradictory identifying information.
Apply it
Two records share a name and birth date but have conflicting addresses and other identifiers. Hold the automated merge and follow the organization’s manual verification process, documenting the evidence used to confirm or reject the proposed match.
Common pitfall: Automatically merging the nearest candidate may reduce duplicate counts while creating wrong-person records. Name agreement alone cannot resolve identity when other evidence remains inconsistent.
28.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 in one record. Their remediation differs because combining true duplicates may be appropriate after verification, whereas an overlay requires separating incorrectly associated information and assessing consequences. Investigate identity evidence, affected data, downstream systems, and prior use of the record. A merge is therefore a controlled correction for verified circumstances, rather than a universal remedy for identity errors.
Apply it
A patient sees another person’s laboratory history in an otherwise familiar chart. Treat this as a possible overlay, contain further incorrect use, and involve identity specialists to separate records and assess downstream effects rather than simply merging additional charts.
Common pitfall: Calling every identity defect a duplicate can lead to another merge when separation is needed. Corrections must address downstream copies as well as the main chart.
29.What makes a downtime plan operationally usable?
A downtime plan specifies how essential work continues when normal electronic functions are unavailable. It requires accessible procedures and forms, identifiable roles, alternative communication, staff preparation, and a recovery approach. The plan must match actual dependencies, including services unavailable during the outage. Exercise realistic scenarios so staff can find materials and perform tasks under disrupted conditions. A backup copy of data helps only if the organization can access it appropriately and integrate it into workable care processes.
Apply it
A hospital stores downtime instructions inside the unavailable electronic record. Move required procedures and forms to an approved accessible location, clarify order and result communication, and drill staff on their use during a simulated system outage.
Common pitfall: A written plan that cannot be accessed or practiced during an outage offers little operational protection. Data backups alone do not define continuity workflows.
30.Why does recovery require reconciliation after downtime?
Restoring technical availability does not automatically restore a consistent record of work performed during an outage. Orders, administrations, results, and follow-up tasks may exist on paper or in temporary systems. Reconciliation verifies what occurred, identifies outstanding actions, and prevents duplicates when information returns electronically. Assign responsibility, define the sequence, and preserve original timing where appropriate. Recovery is complete operationally only when critical information and tasks have been reconciled, rather than merely when users can sign in again.
Apply it
After restoration, paper orders and delayed electronic messages arrive together. Reconcile which orders were carried out and which remain pending before re-entering or releasing them, so an already completed action is not inadvertently repeated during recovery.
Common pitfall: Bulk re-entry without checking completion status can create duplicates. Assuming delayed messages provide a complete history can leave paper-only actions and unresolved tasks missing.
31.How should a security threat assessment guide access-control decisions?
A threat assessment connects an asset, a possible threat, an exploitable vulnerability, and the resulting consequences. Consider confidentiality, integrity, and availability, then assess likelihood and impact to select controls. Authentication verifies a user's claimed identity; authorization determines permitted actions. Role-based permissions and least privilege limit access to the work required, while individual accounts and audit records support accountability. Stronger authentication reduces some credential risks but does not correct excessive permissions. Emergency access should provide necessary continuity with explicit justification and review.
Apply it
Temporary scheduling staff need appointment details but inherit a role permitting unrestricted chart export. Assess the exposure from misuse or compromised accounts, create a narrower scheduling role, remove unnecessary export permission, and test both permitted scheduling tasks and denied actions. Review temporary access when the assignment ends.
Common pitfall: A successful login proves neither appropriate authorization nor safe activity. Shared accounts obscure accountability, and broad permanent access granted for rare emergencies creates avoidable exposure.
AMIA Health Informatics Certification: Outline of Exam Topics
32.How does usability evaluation differ from user preference?
Usability evaluation examines how representative users perform relevant tasks in context, including errors, completion, effort, and information comprehension. Preference is useful feedback but does not establish safe or effective performance. Observe realistic tasks and exception paths, particularly when visual similarity or hidden state can cause confusion. A design can be popular yet promote wrong selections, or unfamiliar yet improve performance after appropriate learning. Connect findings to task consequences rather than relying only on satisfaction scores.
Apply it
Users like a compact selection screen, but observed tasks show frequent confusion between similar entries. Test clearer differentiation and context with representative users, measuring selection errors and task completion before deciding which interface should become standard.
Common pitfall: Aesthetic approval is not evidence of reliable task execution. Testing only expert users can miss difficulties experienced by occasional, new, or differently situated staff.
33.Why must system safety be assessed throughout its lifecycle?
Safety depends on configuration, interfaces, users, workflows, and organizational support, all of which change after implementation. Initial acceptance therefore cannot establish permanent safety. Ongoing assessment uses incidents, near misses, operational signals, and multidisciplinary review to identify new hazards and verify corrective actions. Assign accountable leadership and resources so findings lead to decisions. The discriminating clue is an evolving dependency or work condition: a previously acceptable design may need reassessment even without a major software replacement.
Apply it
A new service begins using an existing system with different staffing and handoffs. Review identity, communication, and coverage risks for that service, test relevant workflows, and assign ongoing monitoring rather than relying solely on the original implementation approval.
Common pitfall: Treating safety as a one-time go-live checklist overlooks later workflow and dependency changes. Collecting incident reports without ownership or corrective follow-through also limits learning.
SAFER: Organizational Responsibilities · SAFER: System Management
34.How does configuration control support safe rollback?
Configuration control identifies the approved baseline, evaluates proposed changes, records authorization, and tracks what was actually released. A rollback depends on knowing the prior state and understanding whether data or dependent systems also changed. Reverting application files alone may leave incompatible mappings or stored data. Establish release and recovery criteria before deployment, and verify the resulting configuration. Traceability supports incident investigation by connecting observed behavior to the exact settings, versions, and decisions in effect.
Apply it
An interface release produces incorrect displays. Use the recorded baseline and dependency assessment to restore the compatible mapping and application configuration, then verify representative messages and account for information processed while the defective release was active.
Common pitfall: Keeping a software backup without configuration and dependency records may not permit a safe rollback. An undocumented emergency fix can make the active baseline uncertain.
NASA Systems Engineering Handbook: Configuration Management · SAFER: System Management
35.Which monitoring signals reveal silent interface failures?
Silent failures can occur when an interface remains available but transmits incomplete, delayed, duplicated, or misinterpreted information. Monitoring should therefore examine operational behavior as well as connection status. Useful signals include unexpected volume changes, processing delays, rejected messages, unresolved queues, and mismatches between source and destination counts. Select signals tied to the interface’s expected work and assign response ownership. A normal uptime indicator cannot establish that all intended information reached the correct destination with preserved meaning.
Apply it
An interface reports continuous availability while result volume drops abruptly. Compare source production with destination receipt, inspect queued and rejected messages, and verify mappings and routing before assuming the decline reflects a genuine change in clinical activity.
Common pitfall: Monitoring only server availability misses semantic and workflow failures. A volume alert without contextual investigation may also confuse real demand changes with technical defects.
Data Governance, Management, and Analytics20%
36.How do data owners and stewards divide accountability?
Data governance assigns decision rights and accountability for how data are defined, used, protected, and maintained. An accountable owner authorizes decisions within the organization’s governance structure, while stewardship performs or coordinates definition, quality, and lifecycle work. Titles vary, so documented responsibilities matter more than labels. When definitions conflict, identify who can approve the shared meaning and who will implement and monitor it. A technical custodian alone may lack authority to resolve a substantive business disagreement.
Apply it
Two departments disagree about what counts as an active patient. Route the definition decision to the accountable governance body or owner, have stewards document the approved criteria, and update affected reports with an explicit definition version.
Common pitfall: Assigning a steward without decision authority or escalation routes creates responsibility without resolution. Letting each report silently choose its own definition fragments organizational meaning.
AMIA Health Informatics Certification: Outline of Exam Topics · Common Data Elements: Standardizing Data Collection
37.What makes a common data element reusable?
A common data element specifies a precisely defined variable together with its response format and, where applicable, allowable values. Reuse depends on consistent collection and interpretation, rather than sharing a familiar label. Metadata should clarify what is measured and how responses are represented. Before combining sources, compare their definitions and value domains. Two fields named functional status may measure different constructs, time points, or scales and therefore require harmonization rather than direct pooling.
Apply it
Three sites collect mobility status using different labels and response lists. Select a shared element with an agreed definition and permissible values, map existing responses where defensible, and retain unmappable distinctions rather than forcing inaccurate equivalence.
Common pitfall: Identical field names do not prove equivalent variables. Standardizing the column heading while leaving different questions and response formats unchanged preserves the underlying incompatibility.
Common Data Elements: Standardizing Data Collection · NIH Common Data Elements Repository
38.Why must missing data be interpreted in context?
A blank value can represent not collected, unavailable, not applicable, unknown, or a failure in transmission. These meanings affect analysis differently and should not be collapsed automatically. Examine collection workflows, source definitions, and missingness patterns across time and groups. A sudden increase may indicate a pipeline defect, while systematic absence in one population can threaten representativeness. Record explicit missing-value meanings where possible and evaluate how exclusions change the population described by an analysis.
Apply it
A dashboard’s improvement coincides with missing outcomes from one clinic after an interface change. Investigate the collection and transmission pathway, compare missingness by site, and withhold causal interpretation until the affected denominator and outcome capture are understood.
Common pitfall: Replacing every missing value with zero converts unknown information into an asserted measurement. Excluding incomplete records without examining patterns can produce a systematically different population.
Common Data Elements: Standardizing Data Collection · Model for Improvement: Establishing Measures · SAFER: System Management
39.How should data transformations be validated?
Transformation validation checks that extraction, mapping, conversion, aggregation, and loading preserve the intended information. Compare source and target counts, value distributions, units, identities, and representative records, with tests for known exceptions. Document transformation rules and versions so discrepancies can be reproduced. A pipeline that completes successfully may still apply an incorrect conversion or silently omit records. Validation should therefore test substantive expectations about the data, rather than only whether the software returned a success status.
Apply it
A pipeline converts measurements into a shared unit. Test known values and boundary cases, reconcile source and target counts, inspect missing units, and verify that the conversion is applied exactly once before releasing the harmonized dataset.
Common pitfall: A successful job status confirms execution, not correctness. Comparing only total row counts can miss wrong values, switched identities, and compensating omissions and duplicates.
40.What does provenance add to a transformed dataset?
Provenance records how information came to exist in its current form, including source entities, activities, and responsible agents. It supports interpretation, traceability, and investigation when data have been copied, corrected, or transformed. FHIR Provenance associates such history with target resources. Distinguish a source value from a derived value and retain enough lineage to explain the transformation. A timestamp alone cannot show which source, rule, or actor produced the current representation or whether it supersedes an earlier version.
Apply it
Two dashboards disagree after a unit conversion. Use provenance to identify each source dataset, transformation activity, rule version, and responsible agent, then reproduce the derivation and determine which representation preserves the intended measurement and meaning.
Common pitfall: Recording only the most recent update time leaves the derivation unexplained. Provenance also does not independently prove that the source or transformation was correct.
41.How should terminology mappings preserve meaning?
A terminology mapping asserts a relationship between source and target concepts. Meaning can be lost when a broad local term is forced into a more specific target, or when distinct local meanings collapse into one code. Compare definitions, context, units where relevant, and mapping purpose; document limitations and review changes. Successful code substitution is insufficient. The discriminating clue is whether the target expresses what the source actually supports without adding unsupported specificity or removing distinctions needed for downstream use.
Apply it
A local result label combines several specimen contexts, but the proposed target code describes only one. Obtain additional context or retain a broader justified representation, and prevent the mapping from implying a specimen distinction the source never recorded.
Common pitfall: Choosing the nearest-looking label can create false precision. A mapping suitable for broad reporting may still be inadequate for a more specific decision-support use.
Introducing HL7 FHIR · Common Data Elements: Standardizing Data Collection
42.Which conditions matter for HIPAA Safe Harbor?
For a US HIPAA covered organization, Safe Harbor requires removal of the specified identifier categories and no actual knowledge that the remaining information could identify an individual, alone or combined with other information. All date elements directly related to an individual must be removed except years, subject to an important exception: ages above 89 and all date elements, including years, indicating such ages must also be removed or generalized. These ages and related date elements may be aggregated into a single category of age 90 or older. Removing names alone or retaining only years therefore does not automatically satisfy Safe Harbor.
Apply it
A hospital proposes releasing admission dates and birth years. It must remove admission months and days. For a patient aged 95 in 2025, retaining birth year 1930 alongside encounter year 2025 still indicates an age above 89, even after birth month and day are deleted. Remove or generalize the birth-year information that reveals the prohibited age and represent the age as 90 or older if age information is needed. Check the remaining fields for other dates or statements that reveal the same advanced age, and assess all other Safe Harbor requirements.
Common pitfall: The permission to retain years is conditional. Replacing an explicit age of 95 with 90 or older while retaining a birth year that reveals the advanced age does not resolve the problem. Likewise, a random study identifier does not cure retained disallowed dates or other identifiers. Safe Harbor and Expert Determination are distinct HIPAA de-identification methods; analytical usefulness alone does not justify retaining information prohibited under Safe Harbor.
Guidance Regarding Methods for De-identification of Protected Health Information
43.When is Expert Determination the relevant de-identification route?
HIPAA Expert Determination uses a person with appropriate statistical and scientific knowledge and experience to determine that identification risk is very small under the anticipated conditions of use. The expert documents methods and results. This route can evaluate information configurations that do not meet Safe Harbor, but it is not a blanket exemption. The assessment depends on the data, reasonably available external information, and anticipated recipients and use, so a prior determination may not automatically apply to a changed release.
Apply it
A US research partnership needs date detail incompatible with Safe Harbor. Engage a qualified expert to assess the proposed data and recipient context, document methods and conclusions, and implement the release conditions on which the determination depends.
Common pitfall: Calling an internal review expert determination without the required expertise and documented assessment is insufficient. Approval for one dataset does not automatically cover later additions.
Guidance Regarding Methods for De-identification of Protected Health Information
44.How do discrimination and calibration differ?
Discrimination describes how well a model separates or ranks people with and without the outcome; AUROC is a common discrimination measure. Calibration describes agreement between predicted probabilities and observed outcome frequencies. A model can rank people well while systematically overestimating risk in a particular range. Evaluate both when probabilities inform decisions. For a group assigned approximately 20% risk, an observed outcome frequency near 20% supports calibration in that group, without establishing calibration across every risk level.
Apply it
A model has strong AUROC, but patients assigned about 20% risk experience outcomes at about 8%. Investigate overprediction in that range and its decision consequences; strong ranking does not validate the numerical probabilities used for action.
Common pitfall: High AUROC does not establish accurate absolute risk. Agreement in one risk stratum also cannot prove calibration throughout the model’s entire prediction range.
45.Why does a predictive model need external validation?
Performance in development data may not hold in another setting because populations, measurement practices, outcomes, and workflows differ. External validation evaluates the model on data meaningfully separate from its development context. Choose evaluation data representative of the intended use and examine discrimination, calibration, and relevant subgroup performance. Validation informs suitability rather than guaranteeing permanent reliability. A strong result elsewhere is a reason to investigate local applicability, not sufficient evidence that the same model and operating threshold will work locally.
Apply it
A hospital considers a model developed in another health system. Evaluate it using suitable local data and the intended outcome definition, inspect subgroup results and calibration, and assess workload at candidate thresholds before integrating its predictions into operational decisions.
Common pitfall: A random holdout from the same development source does not answer every transportability question. A model can retain ranking performance while its local probabilities become inaccurate.
AI Risks and Trustworthiness · Calibration: the Achilles heel of predictive analytics
46.How should deployed model performance be monitored?
Deployment creates an ongoing evaluation obligation because input data, populations, outcomes, and workflows can change. Monitor data availability, distributions, prediction behavior, relevant performance measures, and effects across groups. Assign investigation and response thresholds, recognizing that outcome labels may arrive later than predictions. A distribution shift is a warning to investigate, rather than automatic proof of harm. Document decisions to continue, modify, restrict, or suspend use, and reassess the model after consequential upstream or operational changes.
Apply it
After a documentation redesign, a model’s positive classifications fall sharply. Check input completeness and meaning, compare predictions and later outcomes, and involve the accountable owner in deciding whether use should continue while the discrepancy is investigated.
Common pitfall: Monitoring only average model output can miss subgroup failures. Automatic retraining without investigating a broken data feed can encode the defect into a new model.
47.How should confidence intervals inform a performance decision?
A sample performance estimate is subject to sampling uncertainty. A confidence interval describes its precision under the study's sampling and statistical assumptions. A 95% confidence procedure covers the population parameter in 95% of repeated samples under those assumptions; it does not assign a 95% probability to the fixed parameter after the interval is observed. Larger representative samples generally improve precision, but do not remove systematic bias. Evaluate the interval alongside the estimate, intended-use population, reference standard, and consequences of inadequate performance.
Apply it
Suppose a classifier's estimated sensitivity is 85%, with a reported 95% confidence interval from 76% to 91%. If an organization prospectively requires evidence supporting sensitivity above 80%, this interval leaves important uncertainty below that criterion. Seek a more precise, appropriately designed evaluation rather than accepting the point estimate alone.
Common pitfall: A narrow interval cannot rescue an unrepresentative sample or biased reference assessment. When a comparator is not a reference standard, agreement estimates should not be mislabeled sensitivity and specificity.
Statistical Guidance on Reporting Results from Studies Evaluating Diagnostic Tests - Guidance for Industry and FDA Staff | FDA · AMIA Health Informatics Certification: Outline of Exam Topics
Leadership, Professionalism, Strategy, and Transformation21%
48.What makes informatics governance actionable?
Actionable governance defines who can decide, who is accountable for consequences, what evidence informs decisions, and how unresolved issues escalate. A committee’s existence does not establish effective governance if no one can authorize resources or resolve tradeoffs. Match decisions to appropriate operational, clinical, technical, and executive participation. Document ownership and follow-through so recommendations become observable actions. The discriminating clue is whether a consequential issue reaches a responsible decision-maker and produces a tracked resolution rather than circulating indefinitely.
Apply it
A safety review repeatedly identifies failed result coverage, but no team can fund the correction. Establish an accountable executive sponsor, a decision route, and a tracked action owner with resources and deadlines appropriate to the identified risk.
Common pitfall: Broad consultation can still leave accountability absent. Assigning every participant joint ownership may make it unclear who must secure a decision and verify corrective action.
49.How should a conflict of interest be managed?
A conflict of interest arises when another interest could compromise, or appear to compromise, professional judgment. Disclosure makes the relationship visible but may need additional management, such as independent review or recusal from a decision. Use the applicable organizational process to assess the relationship and determine safeguards. The objective is trustworthy decision-making, not an unsupported assumption that every relationship causes misconduct. A technically sound proposal still deserves an impartial evaluation when a decision-maker has a competing financial interest.
Apply it
A selection-panel member owns shares in a shortlisted vendor. The member discloses the relationship, and the authorized body determines appropriate participation restrictions and independent evaluation before the procurement decision is made or scored by the panel.
Common pitfall: Disclosure alone may leave the conflict unmanaged. Conversely, assuming misconduct without evaluating the relationship confuses a potential competing interest with evidence of actual wrongdoing.
50.Why must human responsibilities around AI be explicit?
An AI system’s influence depends on how people interpret, act on, and challenge its output. Governance should identify intended use, decision authority, oversight responsibilities, limitations, and routes for reporting problems. Merely placing a person in the workflow does not establish effective oversight if that person lacks information, time, competence, or authority. Evaluate the human-system arrangement and its consequences. Responsibility for development, deployment, monitoring, and operational decisions should remain documented throughout the system’s lifecycle.
Apply it
A review team is told it may override an automated recommendation but receives no explanation or escalation route. Define decision authority, provide relevant limitations and supporting information, and test whether reviewers can identify and manage inappropriate recommendations.
Common pitfall: Calling a workflow human-supervised does not prove meaningful oversight. An override button cannot compensate for missing authority, inadequate information, or an unmanageable volume of cases.
51.How should stakeholders be aligned around a shared aim?
Stakeholder alignment begins with a concrete problem, intended benefit, affected groups, and explicit constraints. Clinical, operational, technical, and patient perspectives can reveal different consequences of the same proposal. Clarify the shared aim and how competing concerns will be evaluated, rather than seeking agreement on a product before understanding the work. Participation should include those who perform or depend on the workflow. A measurable aim provides a common reference when preferred solutions and priorities differ.
Apply it
Administrators want shorter waits while staff fear rushed handoffs. Agree on reducing avoidable waiting while preserving handoff completeness, involve affected roles in design, and track both intended benefit and balancing effects during an initial test of the proposed change.
Common pitfall: Consensus around buying a tool does not establish agreement about the problem or success criteria. Excluding frontline roles can leave critical workflow consequences undiscovered.
Model for Improvement: Establishing Measures · Workflow Assessment for Health IT Toolkit
52.How should informatics initiatives be prioritized?
Prioritization compares initiatives against explicit organizational aims, expected benefits, safety implications, feasibility, dependencies, and resource demands. The loudest sponsor or most visible technology may not address the most consequential problem. Use consistent criteria and make tradeoffs visible, including uncertainty in estimates. Consider whether unresolved foundational risks would undermine another project’s benefit. A defensible portfolio decision connects scarce resources to agreed objectives and accountable outcomes, rather than treating every attractive proposal as equally urgent or independently feasible.
Apply it
An organization must choose between a cosmetic dashboard update and correcting unreliable result coverage. Compare both against agreed safety, operational, and resource criteria, then document the rationale and accountable benefit owner for the initiative selected for the next release.
Common pitfall: Ranking by enthusiasm or novelty can displace essential safety work. Numerical scoring also provides false precision when assumptions and consequences remain unexplored or inconsistent.
SAFER: Organizational Responsibilities · AMIA Health Informatics Certification: Outline of Exam Topics
53.What should an informatics business case include?
A business case connects a defined problem and proposed intervention to expected benefits, costs, risks, resources, and assumptions. Informatics costs include implementation and ongoing responsibilities such as training, maintenance, monitoring, and support. Benefits need measurable indicators and an accountable operational owner. Distinguish estimated gains from demonstrated results, and consider alternatives that address the same need. A favorable acquisition price does not establish value when the organization cannot resource the work required for safe and sustained operation.
Apply it
A vendor’s proposal budgets software licenses but omits interface maintenance, staff training, and safety monitoring. Add lifecycle resource needs, define measurable benefits and assumptions, and compare feasible alternatives before presenting the proposal as an affordable operational improvement.
Common pitfall: Counting only purchase costs understates resource needs. Treating projected time savings as guaranteed cash savings ignores whether staffing, capacity, or actual expenditures will change.
SAFER: Organizational Responsibilities · AMIA Health Informatics Certification: Outline of Exam Topics
54.How should a proposed project change be controlled?
A proposed change should be assessed against the approved baseline, including its effects on scope, schedule, cost, interfaces, risks, and verification. The authorized decision-maker then approves, rejects, or defers it, and approved changes update the controlled baseline and relevant plans. Configuration management preserves traceability between the request, decision, and delivered state. A request’s apparent simplicity does not determine its impact; a small field change can alter reports, training, mappings, and acceptance tests.
Apply it
A sponsor requests a new coded field shortly before release. Assess downstream mappings, reporting, testing, training, and schedule effects, obtain the authorized decision, and update the baseline and acceptance criteria if the request is approved for implementation.
Common pitfall: Implementing a sponsor’s informal request bypasses impact assessment and can create hidden scope. Rejecting every change mechanically can also ignore justified safety or business needs.
55.Why must project dependencies be visible before commitment?
A dependency is work or a decision that another activity requires. Informatics projects often rely on approved definitions, interfaces, identity services, staffing, and external decisions. A credible plan makes these relationships and their owners visible before promising delivery. Completing individual tasks does not establish readiness if a prerequisite remains unresolved. Review how delays propagate and which dependencies affect testing or acceptance. Visibility supports informed sequencing, escalation, and tradeoffs rather than optimistic reporting based only on the number of completed activities.
Apply it
A dashboard build is nearly complete, but the denominator definition remains unapproved. Identify definition approval as a prerequisite for valid acceptance testing, assign its decision owner, and revise commitments rather than reporting readiness from coding completion alone.
Common pitfall: A percentage-complete report can hide a single blocking prerequisite. Adding developers may not accelerate a project waiting on governance, source access, or an external decision.
NASA Systems Engineering Handbook: Configuration Management · AMIA Health Informatics Certification: Outline of Exam Topics
56.What distinguishes a risk owner from a risk register?
A risk register records identified uncertainties, consequences, assessments, and planned responses. A risk owner is accountable for monitoring a particular risk and ensuring an appropriate response or escalation. Documentation supports accountability but cannot replace it. Define response triggers, authority, and residual-risk decisions so emerging evidence leads to action. When a risk becomes an actual issue, update the response accordingly. The discriminating clue is whether someone can explain what would trigger action and who is empowered to decide.
Apply it
A predictive tool may become unreliable after source-system changes. Assign an owner, define monitoring and reassessment triggers, and specify who can restrict or suspend use when evidence crosses the agreed threshold or reveals an unanticipated consequential failure.
Common pitfall: Listing a risk without an owner and response trigger creates an inventory rather than management. Assigning ownership to someone without authority can make escalation ineffective.
57.How should adoption barriers be diagnosed?
Low adoption can reflect poor workflow fit, unavailable resources, unclear benefit, usability problems, or missing skills. Diagnose the barrier through observation, user discussion, and task evidence before choosing an intervention. Training addresses a knowledge or skill gap but cannot repair every design or organizational problem. Distinguish whether users cannot perform the task, cannot fit it into work, or reasonably avoid an ineffective process. The response should target the identified mechanism and be evaluated through performance and outcomes.
Apply it
A new reconciliation tool is rarely used. Observation shows that staff cannot access it during the handoff when its information is needed. Redesign access and timing, then reassess use and handoff performance instead of repeating the same classroom training.
Common pitfall: Treating all low use as resistance can lead to ineffective retraining. High login counts also do not establish that the tool supports the intended work.
Workflow Assessment for Health IT Toolkit · SAFER: Organizational Responsibilities
58.How should workforce preparation demonstrate competence?
Workforce preparation should match role-specific tasks and the conditions in which staff must perform them. Attendance establishes exposure to instruction, whereas demonstrated task performance provides evidence of competence. Include important exceptions, coverage arrangements, and access to current procedures. Drills are particularly useful for infrequent but consequential workflows such as downtime. Use observed difficulties to improve both training and system design, and ensure new or reassigned staff receive preparation rather than relying only on initial implementation education.
Apply it
Staff completed a downtime presentation but cannot locate forms or route urgent results during a drill. Revise accessible materials and role instructions, practice the tasks again, and verify performance under realistic conditions before concluding the team is prepared.
Common pitfall: A completed attendance roster does not demonstrate operational readiness. Training people on a workflow that available equipment or permissions cannot support will not resolve the barrier.
SAFER: Contingency Planning · SAFER: Organizational Responsibilities
59.Why does multidisciplinary safety review improve decisions?
Informatics hazards cross boundaries among clinical work, software, data, operations, and leadership. Multidisciplinary review combines these perspectives to reconstruct the failure mechanism and identify workable corrective actions. Frontline observations can explain why a technically correct design fails in practice, while technical analysis can reveal hidden dependencies. Review should produce accountable actions and verification, not merely discussion. Encourage reporting of incidents and near misses so weak signals can be examined before they become normalized operational conditions.
Apply it
A near miss involves wrong-person selection during a busy registration period. Bring registration staff, clinicians, identity specialists, technical staff, and safety leadership together to examine the workflow and interface, then assign and verify changes addressing the identified mechanism.
Common pitfall: Blaming an individual before examining system conditions can suppress useful reporting. A multidisciplinary meeting without action ownership and follow-up may still leave the hazard unresolved.
SAFER: Organizational Responsibilities · SAFER: Patient Identification
60.How are improvement benefits sustained after project closure?
Sustaining benefits requires transferring responsibility from the project team to an operational owner with resources, measures, and response processes. Document the intended workflow, training needs, maintenance duties, and conditions that should trigger reassessment. Continue monitoring outcomes and balancing effects because initial gains can erode as staffing, demand, or systems change. Project completion is a delivery milestone; benefit realization depends on continued effective use. Define who will investigate deterioration and authorize adaptation after the original implementation team disperses.
Apply it
A referral project reduces delay during its pilot. Before closing the project, assign a service owner, retain delay and workload measures, establish review and escalation arrangements, and incorporate the revised workflow into ongoing onboarding and support.
Common pitfall: Declaring success at go-live confuses delivery with sustained benefit. A dashboard without an operational owner may display deterioration for months without prompting corrective action.
Model for Improvement: Establishing Measures · SAFER: Organizational Responsibilities
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, allocating study effort near 17%/21%/21%/20%/21% while increasing attention to personal gaps.
- Practise distinguishing successful data transmission from preserved meaning, and technical restoration from completed operational recovery.
- Calculate sensitivity, specificity, and predictive value from explicit denominators; distinguish model ranking from accurate probability estimates.
- Connect workflow redesign to outcome, process, balancing, and equity measures rather than relying on adoption or message-delivery counts.
- Learn US-specific privacy criteria precisely, especially Safe Harbor date handling and the documented basis for Expert Determination.
- Choose accountable ownership, evidence-based change decisions, and lifecycle monitoring in operational informatics scenarios.
- Compare transactional and analytical database needs, connect security threats to proportionate permissions, interpret confidence intervals, and distinguish financial effects under different payment arrangements.
A practical preparation plan
1. Map experience to the complete outline
For every official knowledge statement, record whether you can explain the principle, apply it to an unfamiliar case, and identify a tempting error. Use the published domain weights to organize your plan, then prioritize important gaps outside your usual professional role.
2. Build decision comparisons
Create paired comparisons for syntax versus semantics, duplicate versus overlay, acknowledgment versus follow-up, process versus outcome measures, and discrimination versus calibration. For each pair, write the observation that would change your decision.
3. Practise calculations and data tracing
Construct two-by-two tables, calculate predictive value at different prevalences, and inspect denominator changes. Trace a hypothetical result from source through mapping, identity association, display, routing, acknowledgment, and action, identifying a test or monitoring signal at each transition.
4. Study operational cases across roles
Work through interface changes, downtime recovery, population outreach, model deployment, and governance disputes. Explain the failure mechanism, affected stakeholders, accountable owner, required evidence, and measure of success. Seek a colleague or mentor whose work covers your least familiar domain.
5. Use drills to explain alternatives
Answer the 20 questions before reading explanations. Review every alternative by its text and explain why the decisive cue favors the best response. Use spaced flashcard review to strengthen principles, and return to the official outline for areas this selective set does not cover.
6. Verify readiness with unfamiliar scenarios
Revisit weak topics using changed populations, settings, and failure conditions. Readiness means transferring a principle to a new case and explaining its boundaries. Use practice performance to direct further learning rather than interpreting this small set as a predicted examination result.
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 sampleOfficial sources and updates
- AMIA Health Informatics Certification (AHIC)
- AMIA Health Informatics Certification (AHIC) Exam
- AHIC Program Guide
- AMIA Health Informatics Certification: Outline of Exam Topics
- Creating advanced health informatics certification
- Introducing HL7 FHIR
- FHIR Provenance
- Principles of Epidemiology: Lesson 5, Appendix A
- Alert Fatigue
- Model for Improvement: Testing Changes
- Model for Improvement: Establishing Measures
- Workflow Assessment for Health IT Toolkit
- SAFER Guides
- SAFER: Contingency Planning
- SAFER: System Management
- SAFER: Patient Identification
- SAFER: Test Results Reporting and Follow-Up
- SAFER: Organizational Responsibilities
- NIH Common Data Elements Repository
- Common Data Elements: Standardizing Data Collection
- Guidance Regarding Methods for De-identification of Protected Health Information
- AI Risks and Trustworthiness
- AI RMF Core
- AMIA Conflict of Interest Policy
- NASA Systems Engineering Handbook: Configuration Management
- Calibration: the Achilles heel of predictive analytics
- Profiling - FHIR v5.0.0
- References - FHIR v5.0.0
- PostgreSQL: Documentation: 18: 7.2. Table Expressions
- Statistical Guidance on Reporting Results from Studies Evaluating Diagnostic Tests - Guidance for Industry and FDA Staff | FDA
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.