Jump to main content
An independent study site · every fact links to the exam bodyFacts last checked: November 2026
Nurse Leader & Educator Certs

NI-BC · domain II, parts A–B

SDLC in nursing informatics: plan, analyze, build

Facts checked against nursingworld.org, codeofethics.ana.org and 2 more sites · Last checked Nov 6, 2026 · Not affiliated with ANCC, ANA, AONL, NLN or AACN.

35% of scored items come from the lifecycle domain, and this page covers its first half: everything before the first test script runs. Questions follow a project from a request on a unit to a finished build.

0 / 16 done · 0 correct16 questions

Inside planning, analysis and build

Outline section II.A–B; testing and go-live are on the second lifecycle page:

  • System planning: needs assessment with user stories and requirements, system-wide impact analysis, gap analysis, feasibility studies, vendor analysis, current-state and future-state process maps.
  • Project management fundamentals: the outline gives no list; scope, schedule, resources, stakeholders and change requests are the core.
  • Workflow and system together: how a clinical workflow and the system around it shape each other.
  • Diagramming: decision trees, swimlane diagrams, flowcharts and database diagrams.
  • Clinical content build: dashboards, documentation templates and report criteria.
  • Designing for the workflow: evidence-based decision support logic, the CDS five rights, prototypes and workflow maps.

16 planning and build questions

Question 1 of 16 · System Design Lifecycle: planning, analysis and build

An informatics nurse lists the current eMAR's functions next to those the new barcode workflow will require and documents what is missing. This activity is:

  1. A gap analysis sets the current state beside the required future state and documents what is missing, here eMAR functions the barcode workflow needs.
  2. A feasibility study judges whether a proposed solution is technically, economically, and operationally viable, not which functions are missing.
  3. A needs assessment establishes the problem and what users need in the first place; comparing an existing system with target requirements is the gap analysis that follows.
  4. An impact analysis traces how a change will ripple through other systems, interfaces, and workflows rather than listing missing functions.
Question 2 of 16 · System Design Lifecycle: planning, analysis and build

A feasibility study finds that nurses' current workflow and unit culture would not support using the proposed system as designed. This finding concerns which type of feasibility?

  1. Technical feasibility asks whether the hardware, software, and infrastructure can support the system, not whether nurses' workflow fits it.
  2. Economic feasibility weighs costs against expected benefits, which the finding does not address.
  3. Schedule feasibility asks whether the project can be finished within the required time frame.
  4. Operational feasibility asks whether the organization's people, workflow, and culture will actually use the system as designed.
Question 3 of 16 · System Design Lifecycle: planning, analysis and build

An EHR upgrade will change how medication concentrations are coded in orders. Besides pharmacy, which system most needs to be included in the impact analysis?

  1. The portal displays the medication list, but it does not act on concentration codes to deliver an infusion, so the safety impact is far smaller.
  2. ADT handles admissions and transfers and does not use medication concentration data.
  3. Pump interoperability passes order details, including concentration, to the pump and its drug library, so a coding change can cause mismatches or programming errors there.
  4. The laboratory information system interface exchanges test orders and results, not medication concentrations.
Question 4 of 16 · System Design Lifecycle: planning, analysis and build

A facilitated workshop in which nurses, physicians, pharmacists, and analysts work together to define and agree on requirements for a new order set is called:

  1. A focus group gathers opinions and perceptions, but it is not a facilitated working session that ends in agreed requirements.
  2. Joint application design brings users, subject experts, and analysts into structured, facilitated sessions to define and agree on requirements quickly.
  3. A heuristic evaluation has usability experts inspect an existing design against principles; it does not define requirements.
  4. The Delphi method builds consensus through anonymous rounds of questionnaires, with no face-to-face workshop.
Question 5 of 16 · System Design Lifecycle: planning, analysis and build

A quality measure requires counting patients with a stage 2 or higher pressure injury. Which documentation design most reliably supports this measure?

  1. Free text varies from nurse to nurse and cannot be counted reliably without manual review.
  2. NLP on narrative notes adds error and lag; it is a fallback for unstructured data, not a design choice for a new measure.
  3. A discrete coded field for stage can be counted reliably by a query, which is what a quality measure needs.
  4. A comment box is free text, so staging is hard to extract and count consistently.
Question 6 of 16 · System Design Lifecycle: planning, analysis and build

To reduce documentation burden in a new admission assessment, the design team should first:

  1. Reducing burden starts with cutting fields that no regulation, policy, or clinical use requires, so nurses document only what is used.
  2. Free text may feel faster but loses the structure needed for decision support, reporting, and quality measures.
  3. Widespread copy-forward saves clicks but carries old findings forward as if newly assessed, a safety and legal risk.
  4. Making everything optional lets required data go missing without reducing the clutter that causes the burden.
Question 7 of 16 · System Design Lifecycle: planning, analysis and build

A new alert states only 'Potassium abnormal,' with no value, trend, or recommended action, and nurses ignore it. Adding the value and an evidence-based next step addresses the CDS:

  1. Format is the kind of intervention, such as an alert, order set, or infobutton; the fix here changes content, not form.
  2. Channel is the medium, such as the EHR, a portal, or a mobile device; the alert already reaches nurses through the EHR.
  3. The right information right means the content is relevant and actionable, here the value, trend, and a recommended next step.
  4. Right time in workflow is not the gap here: the alert fires when the result posts; what is missing is its content.
Question 8 of 16 · System Design Lifecycle: planning, analysis and build

To review navigation across all 12 screens of a new admission workflow, the team builds a clickable model of every screen, but none of the screens saves data. This is a:

  1. An evolutionary prototype is refined step by step into the production system; nothing here suggests the model will become the real build.
  2. A vertical prototype builds one function deeply and in working form, the opposite of a clickable shell of all screens.
  3. A horizontal prototype shows the breadth of the interface, every screen and the navigation between them, without working functions underneath.
  4. An MVP is a working product with just enough features for real use; screens that save no data are not usable.
Question 9 of 16 · System Design Lifecycle: planning, analysis and build

While designing a wound care database, the analyst must show that one patient can have many wounds and each wound many assessments. The appropriate diagram is a(n):

  1. A data flow diagram shows how data move between processes and stores, not the cardinality of relationships.
  2. An entity-relationship diagram models entities, such as patient, wound, and assessment, and the one-to-many relationships between them.
  3. A swimlane diagram shows who performs each step of a process; it models workflow, not data relationships.
  4. A decision tree maps choices and outcomes for decision logic, not database structure.
Question 10 of 16 · System Design Lifecycle: planning, analysis and build

In a knowledge-based clinical decision support system, which component applies the stored rules to a patient's data to produce a recommendation?

  1. The inference engine applies the knowledge base's rules to the patient's data to generate advice.
  2. The user interface displays the recommendation and collects input but does not reason over the rules.
  3. The knowledge base stores the rules and facts; it does not execute them on its own.
  4. An interface engine routes and translates messages between systems; mixing it up with the inference engine is a common slip.
Question 11 of 16 · System Design Lifecycle: planning, analysis and build

The system will not let a nurse file a blood transfusion administration until a second nurse's credentials are entered. This design is a:

  1. A hard stop prevents the user from continuing until a condition is met, such as a second nurse's credentials for a transfusion.
  2. A passive alert shows information without interrupting or blocking the workflow.
  3. A default is a preselected value or order; it shapes choice but does not block filing.
  4. A soft stop warns but allows the user to proceed, usually with an override reason.
Question 12 of 16 · System Design Lifecycle: planning, analysis and build

Nurses override a new fall-risk alert 95% of the time because it fires at login, before any assessment has been documented. Which CDS 'right' is most clearly violated?

  1. The EHR is an appropriate channel for this alert, so delivery medium is not the issue.
  2. Right time in the workflow is violated: firing at login, before any assessment is documented, puts the alert where it cannot be meaningfully acted on.
  3. Nurses are the right recipients for a fall-risk alert; the problem is when it fires.
  4. An alert may be a suitable format; it fails because of its timing in the workflow.
Question 13 of 16 · System Design Lifecycle: planning, analysis and build

A new worklist signals overdue medications only by changing the patient's name from black to red. The main accessibility concern is that:

  1. There is no universal rule reserving red for allergies; the real problem is using color as the only signal.
  2. Relying on color alone breaks accessibility guidance (WCAG), because users with color vision deficiency cannot see the change; pair color with text, an icon, or position.
  3. Alert fatigue comes from too many interruptive alerts; a single color change is not alert overload.
  4. Printing is a minor issue for a live worklist and does not address users who cannot see the color on screen.
Question 14 of 16 · System Design Lifecycle: planning, analysis and build

When designing a nursing assessment flowsheet, rows such as 'lung sounds' should generally default to:

  1. Carrying forward the previous value invites unverified documentation of findings that may have changed.
  2. Prefilling a typical finding encourages accepting it without assessing the patient.
  3. A WNL default documents a normal assessment that may never have happened.
  4. Leaving assessment rows blank forces an active entry, so the record reflects what was actually assessed this time.
Question 15 of 16 · System Design Lifecycle: planning, analysis and build

Which deliverable translates approved requirements into detailed screen layouts, data fields, and rules for the build team?

  1. A test plan describes how the build will be checked, not how it should be built.
  2. The charter authorizes the project and sets its high-level scope, long before build detail exists.
  3. The requirements document states what the system must do; translating it into build detail is the next deliverable.
  4. The design specification translates approved requirements into screen layouts, data fields, and rules that the build team can follow.
Question 16 of 16 · System Design Lifecycle: planning, analysis and build

For a new wireless phone system, the team assesses who will carry the phones, how calls will be routed during rounds, and whether coverage reaches every room. This analysis addresses:

  1. Donabedian's structure-process-outcome model evaluates quality of care, not the readiness of a technology rollout.
  2. Strengths, weaknesses, opportunities, and threats (SWOT) is a strategic planning tool for internal and external factors, not an analysis of users, workflow, and coverage.
  3. Feasibility dimensions are used to decide whether to pursue a project; the stem describes planning how it will work in use.
  4. Who will use the phones, how the work will flow, and whether the technical coverage works are the three dimensions of the people-process-technology framework.

Your score shows up after the last answer.

Planning and build: the usual mix-ups

  • User story vs requirement. A user story states a need in the user's words and gives the reason: as a night-shift charge nurse, I want to see pending admissions on one screen, so that I can assign beds before they arrive. A requirement is the testable statement the build must satisfy. Stories start the conversation; requirements are what testers check later.
  • Map the current state first. Future-state design drawn before anyone has watched the work as it happens risks automating the workarounds. Observe and map the present workflow with the people who do it, then redesign.
  • Swimlane, flowchart or decision tree. A swimlane diagram puts each role in its own lane, so handoffs between people show at a glance. A flowchart shows the sequence of steps without who does them. A decision tree lays out branching choices and their outcomes.
  • RFI before RFP. In vendor analysis, a request for information surveys what the market offers; a request for proposal asks shortlisted vendors to answer your requirements with a priced bid.
  • Report criteria start with the denominator. A report request names the population, time frame, inclusions and exclusions and the data source before it names the columns.
  • A late request is a change request. New features asked for mid-build go through change control against scope, schedule and cost, not straight into the build.

Other informatics domains to study

Where this domain sits

Between build meetings

The same NI-BC questions with every option explained, in a study app.

App StoreGoogle Play

Planning and build, briefly

Which SDLC phase order does the exam use?

The outline orders it as planning and analysis, designing and building, testing, training and implementation, then monitoring and support. Textbooks name the phases differently; learn what happens in each and the order holds.

Do I need to know a project management method in detail?

The outline asks for project management fundamentals. Know scope, schedule, cost and resources, stakeholder roles and how change requests are handled, rather than one certification's vocabulary.