ABPath Clinical Informatics common mistakes
ABPath Clinical Informatics · Understand the traps and how to avoid them.
Answering interoperability questions by matching a familiar acronym to the topic rather than to the exchange pattern described - e.g., picking HL7 v2.x whenever the stem describes querying discrete resources over HTTP with RESTful calls, or using SNOMED CT where the question is about billing/claims coding.
Acronym lists get memorized as vocabulary instead of as a map from problem to standard, so the candidate pattern-matches on the subject word (labs, orders, problems) instead of on the mechanism, directionality, and granularity the stem specifies.
What to do instead
Build and drill a four-column matrix for each standard (HL7 v2, v2 CDA/C-CDA, FHIR, DICOM, LOINC, SNOMED CT, ICD-10, CPT, UCUM, NCPDP): what it encodes, its unit of exchange, its typical direction, and one concrete failure it cannot handle. Before answering, restate the stem's exchange verb (send, query, subscribe, report) and match on that, not on the clinical topic.
Selecting 'build a new interruptive alert' as the answer for any clinical decision support scenario, even when the stem describes alert fatigue, low override rates, or a knowledge update problem that the existing alerting channel cannot solve.
Alerting is the only CDS modality most trainees have personally configured, so it feels actionable; distractors that also mention alerts look plausible, and the Five Rights framework gets recited rather than applied to locate which 'right' the vignette is actually violating.
What to do instead
For every CDS item, explicitly name which of the Five Rights is broken (right information, person, format/channel, time, workflow) and then choose the least intrusive intervention that satisfies it - reference links, order-set defaults, documentation template changes, or retiring an alert come before adding one. Practice sorting interventions into interruptive vs non-interruptive vs workflow-embedded before reading the answer options.
On 'what is the next step' implementation items, jumping to vendor demonstration, contract negotiation, build, or go-live because those steps are vivid, skipping earlier phases such as current-state workflow analysis, requirements definition, or problem framing.
Candidates with operational experience have lived mostly in the later phases, and the exam's answer options deliberately include a plausible mid-project action alongside the correct earliest unfinished step; urgency framing in the stem makes the flashier action feel appropriate.
What to do instead
Write out the lifecycle once as an ordered chain - problem/needs assessment, stakeholder and workflow analysis, requirements, market scan/RFP, contract and BAA, design and build, verification and validation, training, go-live, optimization - and on any sequencing question choose the earliest node not yet evidenced as complete in the stem. Underline the stem's time cues ('just hired a vendor', 'first meeting') to locate position in the chain.
Assigning accountability for data definitions, quality thresholds, and access decisions to the CIO, CMIO, or 'IT' when the question is about who owns or stewards a clinical data domain, and using owner, steward, and custodian as synonyms.
Governance is intangible; candidates anchor on the visible people who run systems rather than on the accountable clinical role, and the custodian/owner distinction is rarely taught explicitly in clinical training.
What to do instead
Memorize a three-role model with one sentence each: the data owner is the accountable clinical/business leader who approves definitions and access policy, the steward operationalizes definitions and quality monitoring for a domain, and the custodian (IT/vendor) maintains the physical and logical safeguards. Then classify every governance vignette by which of the three decisions is being made - definition, quality, or access - before choosing the role.
Treating HIPAA as a single permission gate - declaring a limited data set to be de-identified and freely usable, insisting all 18 identifiers must be removed before any research use, or answering a state-law item with the federal rule alone.
The identifier list is memorable and gets memorized in isolation, while the use-case decision tree around it (treatment/payment/operations, research with IRB review or waiver, limited data set plus data use agreement, safe harbor versus expert determination, public health reporting, preemption) is learned as a blur.
What to do instead
Draw a decision tree keyed on purpose of use, then attach the required mechanism to each branch, including which identifiers survive a limited data set, what the data use agreement adds, what expert determination requires, and where stricter state law controls. Answer privacy items by first naming the purpose of use out loud, then the mechanism, then checking the option against both.
Reaching for a retrospective root cause analysis when the stem asks about a hazard that has not yet caused harm, and describing a single-site before-and-after improvement project as if it established causation or as if it were a controlled trial.
RCA is the best-known safety tool, so it becomes the default; and improvement projects in training are usually reported as dramatic pre/post comparisons, which instills a causal reading of uncontrolled data.
What to do instead
Pair the tools explicitly: prospective risk assessment (FMEA, hazard analysis) for designs and planned changes, retrospective event analysis (RCA) after harm, and failure mode severity scoring to prioritize. For any outcome claim, ask whether there was a comparison group, randomisation, or a control chart with stable baselines, and choose the answer that describes association and iteration rather than proof.
Proposing mandatory training sessions, an email announcement, or a policy memo as the full response to a vignette about clinician resistance, uneven adoption, or a governance dispute, and selecting the technically superior system when the stem's conflict is organizational.
Education is a comfortable, low-cost lever that feels like a complete answer, and technically trained candidates weight functionality over stakeholder readiness, so they read past the human signals (champions, competing priorities, workload, trust) planted in the stem.
What to do instead
Before answering, list the stakeholders named in the stem and what each stands to lose; then choose a strategy that includes sponsorship, two-way engagement, champion networks, and a feedback loop with visible wins - training appears only as one component, never the whole plan. Practice classifying each leadership item as technical, structural, or people-facing and refuse to answer a people-facing item with a technical fix.
Losing track of where a specimen or result sits in the laboratory path - attributing positive patient identification to the LIS rather than to the barcoded label applied at collection, treating middleware as a replacement for LIS validation rules, or confusing an order interface with a results interface.
The laboratory data chain is long and mostly invisible to pathologists, who see the endpoints (the order and the result) rather than the accessioning, instrumentation, and interface hops in between, so descriptions of those hops read as interchangeable.
What to do instead
Rehearse the chain as a numbered sequence - order entry, collection with positive patient ID, transport, accessioning, analyzer, middleware with autoverification and delta checks, LIS with validation rules and reflex logic, result interface to the EHR, and reporting - and name both the system and the standard at each step. For any lab informatics vignette, state aloud which step the question is about before evaluating options.
Treating a test's positive predictive value as an intrinsic property that travels with the assay, and asserting that sensitivity changes when prevalence changes or that PPV is unaffected by it.
Sensitivity and specificity are the numbers reported in validation studies and quoted in the literature, so they feel like the 'real' characteristics of a test, while PPV's dependence on pre-test probability is a step that gets skipped under time pressure.
What to do instead
Before answering, sketch a 2x2 table with a concrete cohort size, compute sensitivity, specificity, and PPV, then rerun with prevalence doubled. Anchor on the rule that sensitivity and specificity are prevalence-independent while predictive values are not, and use that rule to eliminate options claiming invariant PPV before doing any arithmetic.
Choosing the answer that matches how the candidate's own institution configured the system, or the answer that is clinically ideal in an unconstrained setting, instead of the answer that follows from the generalizable informatics principle the item is testing.
Local configuration is a strong prior built from daily practice, and exam vignettes are deliberately generic; local habit fills in details the stem never supplied, including assumptions about staffing, budget, and policy that would make a different answer correct.
What to do instead
Before reading the options, write the governing principle for the item in one sentence (for example, least intrusive effective CDS, earliest unfinished lifecycle phase, purpose of use drives privacy mechanism) using only facts stated in the stem. Then eliminate options that require an assumption not in the stem, and reject any option whose only support is 'that is how we do it'.