CPHIMS domain 3: Healthcare Information and Systems Management, 30% of the exam

A. Analysis: the project before it is a project

Sub-area A is the front half of a project: everything that happens before anyone signs anything. Ten numbered topics, and they run in a recognisable order — understand the current process, find the gap, generate alternatives, cost them, write the case, tie it to a strategic objective, and put it into a procurement document.

What to prepare. Two lists, and they are the cheapest points in the domain. The first is the lifecycle in order: planning and analysis, design, build, test, implement, maintain. A scenario that drops you in the middle of it is really asking which phase you are in, because the phase determines the answer. The second is the procurement alphabet, which the handbook names outright — RFI, RFP, SLA, SOW, NDA.

The procurement documents, sorted by what you don't know yet

An RFI is what you send when you do not yet know what the market offers; it gathers options. An RFP is what you send when you know what you need and want priced, comparable proposals. An SOW says what will actually be delivered, by whom, by when. An SLA says how well the running service has to perform and how that is measured. An NDA goes out before anyone outside sees anything sensitive. Sort them that way and the questions stop being a memory test.

The usable trick. Cost-benefit analysis and strategic alignment are two topics in the handbook, and the exam treats them as one. A business case that proves a technical benefit but is not attached to an organisational objective loses to a weaker case that is. When two options are both financially sound, pick the one that names the strategic goal.

B. Design: what the system has to accommodate

Sub-area B is the smallest of the five by topic count and the most conceptual. It asks what a design has to accommodate, not how to build it: systems talking to other systems, medical devices in the same breath as software and network, compliance obligations, the infrastructure that keeps the organisation running when something fails, and data governance.

What to prepare. Be able to say what an interoperability standard is for rather than what is inside it. There are standards for exchanging data between systems — FHIR is the one most candidates already know — and separate standards that supply shared vocabulary so both ends mean the same thing, such as LOINC for observations. The exam cares that you know which job a standard does and who has to agree to it. It does not ask you to quote clauses, and any prep material reciting version numbers at you is preparing for a different exam.

The usable trick. B.6 is data management under a data-governance protocol, and governance is the word that decides these items. Governance answers who decides, who owns the data and by what policy; operations answers who runs the job tonight. When a stem describes inconsistent definitions across departments, or two systems that each believe they hold the master record, the fix is governance, not another interface.

C. Selection, implementation, support and maintenance

Sub-area C is the longest practical stretch of the domain and the one that reads most like a working week: choosing a product, changing it safely, teaching people to use it, holding scope and budget, then keeping it alive. Six topics, and the handbook is unusually concrete in them — it names demos, site visits and reference checks under selection, and it names the training methods.

Selection: where the evidence actually comes from

A vendor demo is a performance the vendor controls. A site visit and a reference call are not. When a selection scenario asks how to verify a claim, the answer is almost always the channel the vendor does not script — and the stakeholders in the room matter as much as the criteria, because a selection made without the clinicians who will use the system is a selection that fails at go-live.

Training: four methods, four situations

Computer-based training scales and lets people go at their own pace. Classroom suits a defined cohort learning the same thing at once. Train-the-trainer is how you cover a large organisation without a large training department. At-the-elbow superusers are for go-live and for workflow questions that only make sense on the unit. The exam rarely asks which is best in the abstract; it describes a situation and expects you to match.

• Changes are tested outside the live environment before they touch it.
• Priority is set by clinical and patient-safety impact, not by ticket age.
• Every change has a written backout plan agreed before the window opens.
• Configuration is version-controlled, so “roll it back” is a real option.
• Migrations run incrementally, with a validation cycle after each increment.
• Source and destination are reconciled by automated comparison, not by sampling.
• Clinical leadership knows the window and the downtime procedure before it starts.

The usable trick. C.6 lists what you analyse once a system is live: error reports, help-desk logs, user surveys, performance metrics, network monitoring. Each answers a different question. Help-desk logs tell you where users are stuck; error reports tell you where the software is failing; performance metrics and network monitoring tell you where the infrastructure is; surveys tell you what people believe. Items in this sub-area often hand you a symptom and ask which source to open — match the source to the kind of failure and it is a free point.

D. Testing and evaluation: proving it works, then proving it paid

Sub-area D is four topics and the tightest part of the domain. It covers formal testing method, the controls that stay in force while you test, validating what you built against what you bought, and measuring whether the promised benefit arrived.

What to prepare. The test ladder, in order, with what each one proves. Unit testing checks one component in isolation. Integrated testing checks the components talking to each other, which in a hospital means the interfaces. Stress testing checks behaviour at peak — a full clinic, month-end, the morning medication pass — not on a quiet Tuesday. Acceptance testing is the users confirming the system does the job they need, and it is the one they own.

The usable trick. D.4 is benefits realisation, and it closes the loop back to sub-area A. The cost-benefit case you wrote before the project is where the measurement after it comes from — same metric, two ends of the lifecycle. Read A and D together once and both get easier: the return, the benchmark and the user-satisfaction measure are not new content in D, they are the promises from A being checked.

The other half of D is easy to skip and shouldn't be. Internal controls do not pause for testing — security auditing, version control and change control apply to the test environment too, and questions built on that point usually involve real data landing somewhere it should not be.

E. Privacy and security: a management sub-area

Sub-area E carries seven numbered topics, more than any other part of domain 3, and it is written for a manager rather than an engineer. Policy, vulnerability assessment and mitigation, user access control, safeguards, who owns vulnerability management, how data is classified and eventually destroyed, and how you keep checking that the controls still work.

What to prepare. The safeguard classification, because it is the backbone of the sub-area: physical, technical, administrative. A locked server room is physical. Two-factor authentication and an automatic screen lock on an unattended workstation are technical. The policy that says workstations must lock, the training that explains why, and the review that confirms it happens are administrative. Practise sorting controls into the three buckets until it is automatic, because stems frequently give you a gap in one class and offer you a fix from another.

Data-management controls (E.6) run the full lifecycle: who owns a data set, how critical it is, how long it is kept, and how it is destroyed. Destruction is part of the policy, not an afterthought, and retention questions usually turn on the fact that keeping data longer than the policy allows is itself a finding.

The usable trick. Read the stem for whether the failure is a control failure or a governance failure. Nobody knew the policy, nobody owned the risk, nobody reviewed it — that is governance, and the answer is a role, a policy or a review cadence. Only when a specific control is missing does the technical option win.

Questions people ask