By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of the Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: Requirements
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
Requirements are the needs, functions, and constraints that a particular software implementation or specification must satisfy. The HIMSS Dictionary frames them as a set of needs, functions, and demands. In health IT projects, requirements are the bridge between what clinicians and the organization need and what analysts, vendors, and developers build.
Requirements fall into several families. Business requirements describe organizational goals, such as reducing duplicate documentation. Functional requirements describe what the system must do, such as flagging a duplicate order. Non-functional requirements describe how well it must do it, such as response time, availability, security, and usability. Regulatory requirements come from laws and standards the system must follow.
| Type | What It Describes | Example |
|---|---|---|
| Business Requirement | Goal the organization wants to achieve | Reduce time spent on admission documentation |
| Functional Requirement | Specific behavior of the system | Pre-populate allergies from the prior encounter |
| Non-Functional Requirement | Quality attribute or constraint | Screens load within an agreed time; access is logged |
| Regulatory Requirement | Obligation from law or standard | Audit controls and access safeguards for PHI |
| Acceptance Criteria | Conditions that show a requirement is met | Test script with expected results |
⚠️ Exam Alert: A functional requirement states what the system does, while a non-functional requirement states how well or under what constraints. A requirement states a need, whereas a design describes how the need will be met. Acceptance criteria show whether the requirement was satisfied.
🌐 Why It Matters: Real-World Healthcare IT Context
Every later step in a health IT project depends on requirements. Vendor selection compares products against them, contracts reference them, build and configuration implement them, testing verifies them, and training teaches the workflows they describe. When requirements are missing or vague, problems show up late and cost more to fix, often as workarounds on the unit.
Good requirements share a few traits. They are specific enough to build from, testable so that someone can say whether they were met, prioritized so the team knows what must ship first, and traceable so each can be followed to a design decision, a test, and a go-live outcome. A statement such as the system should be user friendly cannot be tested. A statement such as a nurse can document a complete admission assessment in a defined set of screens without leaving the primary workflow can be tested in a simulation with real users.
Gathering requirements is a people skill as much as a technical one. Common methods include interviews, direct observation of work, workflow walk-throughs, focus groups, review of existing policies and reports, prototype demonstrations, and analysis of incident reports. Observation matters because people describe the work as it is supposed to happen, while observation shows the workarounds, interruptions, and paper tools that real work includes.
Research in health care supports a user-centered approach. A study on information systems for hemophilia care noted that many health IT projects fail from a lack of systematic consideration of human and non-technology issues, particularly in the requirements phase, and described combining task analysis, object-oriented analysis, and prototyping so that weaknesses in any single method are offset and emerging requirements are easier to elicit. A pilot study on interprofessional requirements engineering described a different challenge: when many professional groups contribute, requirements lists can become long, and teams may lack a common language, which made it hard to turn the catalog into clear priorities and working packages. The project introduced a structured tool called an Action Sheet to reorganize the work. Agile approaches add another option, with requirements refined in short cycles through user feedback, as one digital health platform case study described.
Prioritization is where leadership comes in. Not every request can fit within budget and schedule, so teams use methods such as sorting requirements into must have, should have, could have, and later categories. Clear governance for who may add or change a requirement prevents scope creep, and a change control process records the effect of each change on cost, time, and risk.
Safety and usability should appear in the requirements, not just the test plan. The SAFER Guides from ONC offer self-assessment checklists that organizations can use to identify safety-related practices that belong in their requirements and configuration decisions, and the ONC Health IT Playbook gives practical planning guidance for projects of this kind.
Common requirements problems:
- Vague statements that cannot be tested
- Requirements gathered from managers but not from frontline users
- Current workflow copied rather than examined for improvement
- Missing non-functional needs such as downtime, performance, and access control
- Requests added late with no impact review
- No link between requirements and test cases
What supports strong requirements:
- Representation from every affected role, including night shift
- Workflow observation alongside interviews
- Prioritized lists with owners and acceptance criteria
- A traceability matrix from requirement to test to go-live
- Change control with clinical governance
- Prototypes or demos to confirm understanding early
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses live with the results of requirements, whether they were written well or never written at all.
At the Bedside
A missing requirement shows up as a missing field, an extra click, or a report that does not fit shift handoff. Bedside nurses add the most value when they describe tasks concretely: what they do, in what order, what they need to see, and what interrupts them. Specific examples are more useful to analysts than general statements about what would be nice.
Nurses from different units often have different needs. Medical-surgical, intensive care, labor and delivery, and emergency settings do not document the same way, so requirements gathered from only one unit leave gaps elsewhere.
In Clinical Workflow
Nurse leaders and super users take part in workflow sessions, review draft designs, and join testing. They help distinguish true needs from preferences, and they speak up when a requirement conflicts with safe practice, such as a design that hides information needed at handoff.
Nurse informaticists translate clinical language into requirement statements that analysts and vendors can build, and they translate system language back for clinicians. They also help write acceptance criteria that reflect real tasks, such as a complete medication administration cycle on a busy shift.
In EHR Implementation (Go-Live Perspective)
During an Epic Go-Live, gaps in requirements surface quickly as questions at the elbow: where is this documented, why can’t this be done, who needs to see this. At-the-elbow support analysts record these gaps as they find them. Good teams sort each into training need, build change, or new requirement, so that the issues list feeds the optimization backlog instead of vanishing.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
Requirements appear in project lifecycle, analysis, and procurement questions:
| CAHIMS Domain | How Requirements Appear |
|---|---|
| Healthcare & Technology Environments | Regulatory and standards requirements, safety guidance |
| Clinical Informatics | Workflow analysis, stakeholder input, clinical content needs |
| Healthcare Information & Systems Management | System lifecycle, testing, traceability, non-functional needs |
| Management & Leadership | Scope, prioritization, governance, vendor contracts |
Key Terms to Know Alongside Requirements
- Functional Requirement — a behavior or feature the system must provide
- Non-Functional Requirement — a quality or constraint such as performance, security, or usability
- Stakeholder — a person or group affected by or influencing the system
- Requirements Traceability Matrix — table linking requirements to design, tests, and outcomes
- Scope Creep — uncontrolled growth in project requirements
- Acceptance Criteria — conditions that show a requirement has been met
HIMSS Organizational Position
HIMSS supports effective health IT planning, implementation, and optimization through its education, certification programs, and research. Members can find related resources through the HIMSS Resource Center.
🔗 Explore Further: External References
- ONC — Health IT Playbook https://playbook.healthit.gov/
- ONC — SAFER Guides https://healthit.gov/clinical-quality-and-safety/safer-guides/
- Teixeira et al. (2012), Computer Methods and Programs in Biomedicine — User-Centered Requirements Engineering in Health Information Systems: A Study in the Hemophilia Field https://pubmed.ncbi.nlm.nih.gov/21075471/
- Kunz et al. (2016), JMIR Human Factors — Strengthening Interprofessional Requirements Engineering Through Action Sheets: A Pilot Study https://pubmed.ncbi.nlm.nih.gov/27756716/
- Meinert et al. (2020), JMIR Public Health and Surveillance — Agile Requirements Engineering and Software Planning for a Digital Health Platform to Engage the Effects of Isolation Caused by Social Distancing: Case Study https://pubmed.ncbi.nlm.nih.gov/32348293/
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply