NR 541 Week 4 Build Request Brief Example

Build Request Brief: Two Pages Asking the Clinical Systems Committee to Fund 58 Analyst Hours for a Single Isolation Status, Against a Queue of Forty Other Requests

Student Name

College of Nursing, Chamberlain University

NR 541: Practice of Nursing Informatics

Instructor Name

Month Day, Year

Build Request Brief: Two Pages Asking the Clinical Systems Committee to Fund 58 Analyst Hours for a Single Isolation Status, Against a Queue of Forty Other Requests

Request

The clinical informatics team requests 46 analyst hours for build and 12 hours for testing, a total of 58 hours in the next quarter, to replace the hospital's four unconnected isolation fields with one isolation status created by order and displayed identically in the record header, the patient lists, the door signs and the transport and procedure requests. The requirement statement and the consultation record are attached. This brief explains why the request should be funded this quarter ahead of other requests in the queue.

The Problem

Isolation status is currently recorded in four places that are not linked: a free-text header field, a checkbox on the admission form, a door sign template and a hand-completed field on transport requests. The request follows an event in which a blank transport request and a stale door sign together sent a C. difficile patient to radiology unprotected. A review of the last six months of event reports found seven more events involving mismatched or missing isolation information, none causing known harm, and an audit of 40 isolated patients found at least one of the four places inconsistent for 23 of them.

Guidance on isolation precautions places the burden of applying precautions on every staff member who contacts the patient (Siegel et al., 2007). That can only work if every staff member sees the same, current status. The hospital's own record currently prevents it.

The audit was simple. For each of 40 patients with an active isolation order during one week, a nurse from infection prevention compared the header field, the admission checkbox, the door sign and the most recent transport request. Any disagreement among the four counted as an inconsistency. The most common pattern was a correct header with a missing or outdated door sign, followed by a correct door sign with a blank transport field. Both patterns reflect the same cause: each place is updated by a different person at a different time, and nothing tells anyone that the others have changed.

What the Build Involves

The build creates one order with six precaution types, a reason and start and end dates; displays active orders in a header band and a patient list column; prints door signs and removal notices on signing and discontinuation; populates transport, radiology and procedural requests automatically; creates a nursing task to post each sign; notifies the attending provider when a nurse starts isolation; applies discontinuation rights by reason; and hides the legacy fields. Each element is specified in the requirement statement with acceptance criteria.

The analyst estimate of 46 hours was prepared by the lead analyst for orders and reviewed by the interface analyst for the printing and request components. The 12 testing hours include unit testing, integration testing of printing and requests, and user acceptance testing with nurses, clerks and transport staff.

The request has already been shaped by the people it affects. Eleven staff from nursing, the unit clerk role, transport, infection prevention, medicine and radiology were consulted, and four changes were made to the requirement as a result, including showing the words "Soap and water required" on transport requests for C. difficile. Those consultations are why the analyst estimate is unlikely to grow during the build: most of the questions that usually surface late have already been answered.

Priority Score

Five criteria make up the committee's scoring: safety, regulatory exposure, reach across users, effort and fit with strategy. Applying the committee's own scale, this request scores 4 of 5 on patient safety, because it addresses a documented pathway to transmission of infection; 3 on regulatory exposure, because infection prevention practices are reviewed in accreditation surveys; 5 on users affected, because every inpatient nurse, clerk and transporter uses isolation information; 4 on effort, because 58 hours is modest; and 4 on alignment, because the hospital's safety plan names hospital-onset infections as a priority. The weighted total is 4.1, which would place the request fourth in the current queue of 41.

What Happens if It Is Not Funded

If the request is deferred, the four fields will remain unconnected. Infection prevention has introduced a manual workaround, a daily check of door signs against the header field on each unit, which takes about 15 minutes per unit per day across nine inpatient units, or roughly 800 nursing hours a year. The workaround reduces but does not remove the risk, because transport requests remain hand-completed. Researchers describing errors related to patient care information systems have noted how fragmented displays and manual transcription between systems create conditions for error that workarounds rarely eliminate (Ash et al., 2004). Deferral therefore has a cost in staff time as well as risk.

Dependencies and Risks

The build depends on the vendor's standard order and banner functions, which are already licensed, and on the infection prevention department approving the sign templates and discontinuation rules, which it has done. The main risk is the printing component, because unit printers vary. The test plan will include each unit's printer. A second risk is resistance to losing the free-text header field, which some staff use for notes unrelated to isolation. Those notes will be moved to the existing patient note field, and the change will be announced two weeks before go-live.

A sociotechnical approach to health information technology treats technical components, workflow and organizational policy as interdependent (Sittig & Singh, 2010). The build request reflects that: the 58 hours buy software changes, but the consultation, policy agreement and communication that make those changes work have already been done.

Decision Requested

Approval is sought for 58 analyst and testing hours in the coming quarter and to schedule go-live for a Tuesday, following the committee's rule against Friday releases for clinical changes. The informatics team will report the outcome of the build, including the number of mismatched isolation records found in a repeat audit, at the committee's meeting three months after go-live.

If the committee prefers, the build could be split so that the transport and procedure request link, which addresses the event directly, is delivered first, with the remaining elements following in the next quarter. The informatics team does not recommend this, because it would leave the header, lists and signs unconnected for longer, but the option is available.

References

Ash, J. S., Berg, M., & Coiera, E. (2004). Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. Journal of the American Medical Informatics Association, 11(2), 104-112. https://doi.org/10.1197/jamia.M1471

Siegel, J. D., Rhinehart, E., Jackson, M., & Chiarello, L. (2007). 2007 guideline for isolation precautions: Preventing transmission of infectious agents in health care settings. American Journal of Infection Control, 35(10, Suppl. 2), S65-S164. https://doi.org/10.1016/j.ajic.2007.10.007

Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl. 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085