18.1 HIT Roles, Job Descriptions, and Staff Competency
Key Takeaways
- Task A.21 is define roles, responsibilities, and job descriptions for healthcare IT functions; a title or vendor certification is not a role.
- One person is accountable for each decision. Shared “co-ownership” is how downtime, identity, and the legal record lose an owner.
- Task A.22 is evaluate staff competency in information and management systems skills—observed performance against a defined standard.
- Training hours, years in seat, LMS completion, and a professional certificate (including CPHIMS) are not competency evidence.
- HIMSS does not publish a CPHIMS-official org chart or staff competency rubric. Use the organization’s HR system and the written IT plan.
18.1 HIT Roles, Job Descriptions, and Staff Competency
Quick Answer: Domain 4 task A.21 is define roles, responsibilities, and job descriptions for healthcare IT functions. Task A.22 is evaluate staff competency in information and management systems skills. A title is not a role. Training hours are not competency. Write who is accountable, then test whether people can do the work.
Management and Leadership is 25% of CPHIMS—about one scored item in four on the 100-scored-item, two-hour form. Chapters 15–17 taught strategy, performance, ethics, and change. This chapter is how HIT staffs, develops, sequences, and pays for that work. A.21 and A.22 are the people layer. If roles are slogans and competency is assumed from tenure, the later portfolio (A.23) and vendor stack (A.24) will look staffed on paper and fail at go-live.
Why roles and competency are leadership work
HIT failures are often labeled as “change resistance” or “vendor issues” when the real finding is nobody owned the function or the owner could not do the job. A.21 is design: which healthcare IT functions exist, who is accountable, and what the posted job actually requires. A.22 is evidence: can this person, in this role, perform the information and management systems skills the organization needs—now, not after the next outage.
HIMSS does not publish a CPHIMS-official org chart, job-family catalog, or competency rubric. Use the organization’s HR system and the written IT plan (section 15.4). What the exam tests is whether you define and evaluate, instead of cloning a vendor’s role names or treating a certificate as a skill.
Role, responsibility, job description, competency
Candidates collapse four different objects.
| Object | Job | What “done” looks like | Trap |
|---|---|---|---|
| Function | A durable HIT capability (identity, application support, clinical informatics, security, HIM integrity, analytics, PMO, vendor management) | Named in the operating model | Inventing a function around a product (“the EHR team” as the only identity) |
| Role | The part a person plays relative to a function | One accountable owner per decision | Three “co-owners” and no decider |
| Responsibility | Recurring work and decisions | Visible in a RACI and in the description | “Other duties as assigned” as the real job |
| Job description | The HR contract: purpose, essential functions, required versus preferred skills, reporting, on-call, PHI duties | Posted, graded, and used to hire | Written around one incumbent or one vendor module |
| Competency | Observed ability to perform a defined skill to a standard | Evidence from work, simulation, or audit | LMS checkmarks, years in seat, or “they have CPHIMS” |
A title is a label. “Analyst III” does not tell you whether the person builds order sets, maps interfaces, or resets passwords. A role answers: for this function, who is accountable, who performs, who must be consulted, and who is only informed. RACI is a useful tool; it is not a HIMSS-mandated template. The exam-relevant rule is one Accountable. Shared accountability is how a downtime viewer never gets an owner.
Healthcare IT functions you must be able to name
A.21 says healthcare IT functions, not “the IT department.” Typical function set:
- Clinical informatics (CMIO/CNIO partnership, content, CDS, workflow)
- Application management (EHR, revenue cycle, ancillary, ERP)
- Integration and data (interfaces, EMPI, warehouses, quality of secondary use)
- Infrastructure and cloud (network, identity, endpoint, shared-responsibility operations)
- Privacy, security, and access (not the same as HIM coding)
- Health information / record integrity (legal medical record, release, documentation integrity—RHIA depth)
- Analytics and reporting
- Service desk and desk-side support
- Training and adoption (feeds A.15)
- Project and portfolio management (A.23)
- Vendor and contract management (A.24)
Define functions first. Then attach roles. If you start from a vendor’s certification track, you will staff a product and orphan identity, downtime, and data quality.
Writing job descriptions that survive an exam stem
A usable description includes:
- Purpose tied to an organizational or departmental objective, not a product slogan.
- Essential functions in verbs (design, configure, escalate, validate, educate)—not “support the EHR.”
- Required versus preferred competencies, including privacy/security hygiene and downtime behavior.
- Authority boundaries. An analyst does not grant medical-staff privileges. A physician builder does not approve production directory accounts. A vendor contractor does not own the legal medical record.
- Reporting and matrix. Solid line for hire/fire and payroll; dotted line for clinical or security direction. Write both.
- Access and PHI duties. If the role can see or change ePHI, say so and name the workforce or BAA rules.
- On-call, after-hours, and go-live expectations. Hidden labor is a staffing lie.
- Dual-hat roles. A nurse informaticist needs both clinical practice expectations and IT accountabilities on paper. “Help us with the build when you can” is not a description.
Do not write the job around a single vendor product name if the function is broader than that product. Product shorthand can help recruiting. The description still needs the functions: documentation tools, order catalog, testing, change control, and competency to work a downtime.
Staffing demand is an A.21 output: FTE by function, with skills, not “we need more IT.” Capacity you invent here becomes the constraint in A.23 demand management.
Evaluating competency (A.22)
Competency is observed performance against a defined skill standard. It is not years in the role, conference attendance, LMS completion, a professional certificate (including CPHIMS), being well liked on the unit, or surviving the last go-live.
Evaluation methods that count as evidence:
- Structured observation of a build, a change, or a downtime drill
- Work-sample review (interface spec, test script, order-set, access recertification)
- Scenario simulation (failed interface, identity collision, ransomware ticket)
- Quality audit of tickets or changes (reopen rate, wrong queue, skipped change board)
- Peer or clinical co-evaluation for informatics roles
- Time-bounded skills checklist after a major release
Cadence: at hire or contractor onboarding, at the end of orientation, after a material system change, and on a regular cycle. Do not wait for a patient-safety event to discover that nobody on nights can run the downtime viewer.
Competency is role-specific. A service-desk specialist and a security engineer do not share one “IT competency score.” Foundational skills (identity hygiene, minimum-necessary, downtime, escalation) can be shared. Role skills cannot be averaged into a green dashboard.
Gaps from A.22 are inputs to educational strategy (A.15) and to hiring. They are also risk inputs (A.17): a single competent interface person is a concentration risk, not a staffing success.
Vendor and contract staff are not exempt. If a partner has production access, evaluate their competency and write it into the agreement (A.24). Shadow IT often starts when a department cannot get a competent official path and hires a “friendly” vendor instead.
Distinctions the exam will punish
- Role versus title versus product certification.
- Accountable versus helpful. Superusers who are not in a description will vanish at go-live.
- Competency versus training attendance.
- Clinical privileging versus IT access versus system competency. A credentialed physician is not automatically competent to approve an order catalog.
- Function versus department. HIM, quality, and biomedical may sit outside “IS” and still perform healthcare IT functions.
Scenarios and exam traps
Scenario. A chief nursing officer asks for “two superusers per unit” for an ambient-documentation rollout. There is no description, no time allocation, and no competency standard. Do A.21 first: define the function (workflow design, at-the-elbow support, escalation), write the role and protected time, and name the accountable informatics owner. Then A.22: what evidence will show those superusers can coach a note and escalate a privacy miss.
Scenario. The best application analyst is promoted to manager. Ticket quality was excellent. The new job requires coaching, vendor escalation, and portfolio intake. Evaluate manager competencies. Do not treat prior builder skill as proof.
Scenario. Leadership wants the CMIO to “own IT,” including the service desk and data center. Split functions. The CMIO role is clinical informatics authority, not a substitute CIO. Write the boundary or you will get a physician drowning in printer tickets.
Scenario. A contractor maps production interfaces. No skills evaluation, no named internal accountable. Stop. A.22 applies to anyone performing the function. A.21 still needs an employed owner.
Watch these traps:
- Posting a title and calling it a role design.
- Using LMS hours or a certificate as competency evidence.
- Writing descriptions around one vendor module and orphaning identity, downtime, and data quality.
- Leaving dual-hat and contractor work off the description.
- Waiting for harm to discover a competency gap.
- Inventing a HIMSS-official CPHIMS competency scorecard.
A chief nursing officer asks for two ambient-documentation “superusers” on every unit. There is no job description, no protected time, and no skills standard. What should the CPHIMS professional do first under tasks A.21 and A.22?
How should a CPHIMS professional evaluate an interface analyst’s competency in information and management systems skills?
A nurse informaticist is expected to keep a clinical assignment and also own order-catalog changes. What belongs in the job description?