No products in the cart.
MODULE 9: THE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Section 4: Development & Build
An inside look at the “black box” of coding. While you won’t be writing code, you’ll learn how to effectively interact with developers, answer questions, and keep projects on track during the implementation phase.
SECTION 9.4
Inside the Engine Room: From Logic to Live Code
Your role shifts from architect to on-call clinical consultant, ensuring the build stays true to the patient safety blueprint.
9.4.1 The “Why”: The Cost of a Developer’s Assumption
The development phase is where the blueprints from the design phase are used to construct the final product. To many clinical stakeholders, this part of the project is an impenetrable “black box.” The requirements have been given, the designs have been approved, and now the developers disappear for weeks or months to “write the code.” A dangerous assumption can set in: the belief that your job is done until it’s time to test the final product. This is a critical error in judgment that can derail even the best-laid plans.
Developers are brilliant problem solvers and experts in logic, but they are not clinicians. They will inevitably encounter ambiguities in the specifications or face technical hurdles that require a deviation from the original design. When they do, they have two choices: they can either stop and ask for clarification, or they can make an assumption and keep going. A developer blocked by a question is a significant cost to the project’s timeline and budget. Therefore, a developer is highly incentivized to make their best guess and move forward. Sometimes, that guess is harmless. But in healthcare, a developer’s logical, well-intentioned assumption can have catastrophic clinical consequences.
Imagine a developer is building the logic for pediatric dosing. The specification says, “Dose should be calculated based on patient’s weight.” The developer sees that the patient object in the database has two weight fields: `admissionWeight` and `mostRecentWeight`. Lacking clinical context, they make a logical assumption that the most recent data is always the best data, so they code the calculator to use `mostRecentWeight`. They are unaware that for many pediatric chemotherapy protocols, all doses must be based on the `admissionWeight` for the entire duration of the treatment course to avoid toxicity. This single, logical assumption could lead to a wave of pediatric overdoses. Your role during the development phase is to be so accessible, responsive, and engaged that a developer never has to make an assumption about clinical logic. You are the project’s real-time safety net, the ever-present consultant who can provide a definitive clinical answer in minutes, saving the project from weeks of rework and protecting patients from the consequences of a logical guess.
Retail Pharmacist Analogy: The Expert Compounder
You have just written a complex formulation for a “magic mouthwash” for a patient undergoing chemotherapy. The formula—your **requirements and design document**—is precise: Lidocaine Viscous 2%, Diphenhydramine Elixir, Nystatin Suspension, Maalox, etc., with exact quantities for each. You hand this formula to your best technician to compound.
The Disengaged Pharmacist: You hand off the formula and immediately go to the front of the store to counsel patients. You are unavailable. Thirty minutes later, the tech comes to you with the finished product. You notice it’s slightly the wrong color. The tech says, “We were out of the 12.5 mg/5 mL Diphenhydramine Elixir, so I used the 50 mg/mL Diphenhydramine Injection and calculated the equivalent volume. I figured it would be fine.” While the math might be right, the injection contains benzyl alcohol, a preservative that is not meant to be swished and swallowed, and it tastes completely different. The compound is now unusable. The tech made a logical assumption in isolation, leading to wasted time, wasted inventory, and a delay in therapy for the patient.
The Engaged Informatics Pharmacist: You hand off the formula but remain in the pharmacy, working on other tasks but staying visible and accessible. The tech begins compounding and immediately runs into the same problem.
- The Developer’s Question: The tech doesn’t guess. They turn to you and say, “I’m blocked. The formulation calls for Diphenhydramine Elixir, but we’re out. We have the injection and we also have the 25mg capsules. What should I do?”
- Your Rapid Clarification: You don’t need a meeting. You provide an immediate, definitive answer. “Good catch. Do not use the injection because of the preservatives. Let’s use the capsules. Empty ten of the 25mg capsules and dissolve the powder in 100mL of sterile water to create a 2.5 mg/mL solution, then use the appropriate volume from that. Update the master formulation record to note this substitution.”
In this scenario, your constant availability and clinical expertise kept the process moving forward, prevented waste, and ensured the final product was safe and effective. This is your exact role during the software development phase: to be the on-demand clinical expert who resolves ambiguity and prevents developers from having to make dangerous assumptions.
9.4.2 Demystifying the “Black Box”: What Are Developers Actually Doing?
To interact effectively with developers, you need a conceptual understanding of the world they work in. You don’t need to know how to code, but you do need to understand the basic architecture of a modern software application. This knowledge will allow you to understand their challenges and communicate your needs more effectively.
A Pharmacy Model of Software Architecture
Imagine your pharmacy is the software application. It can be broken down into several key components:
The Front-End (The Pharmacy Counter)
The front-end is everything the user sees and interacts with. It’s the User Interface (UI)—the buttons, the forms, the menus, the reports. In our analogy, it’s the pharmacy’s public-facing area: the drop-off window, the consultation counter, the will-call bins, the design of the prescription label. It’s what the patient (the user) experiences directly. Front-end developers use languages like HTML, CSS, and JavaScript to build this visual and interactive layer.
Your Role: Feedback on the front-end is usually focused on UI and usability. “This button is too small.” “This text is hard to read.” “Can we move this field to the top of the screen?”
The Back-End (The Dispensing Area)
The back-end is the engine of the application. It’s the server, the application logic, and the database. This is where the actual “work” gets done. In our analogy, it’s the restricted-access dispensing area of the pharmacy. It contains the drug inventory, the pill counters, the compounding hood, and, most importantly, the pharmacist’s brain that performs the clinical checks. The user never sees the back-end, but they rely on it to function correctly. Back-end developers use languages like Java, C#, Python, and SQL to write this business logic.
Your Role: Feedback on the back-end is focused on clinical logic and rules. “The system needs to calculate a CrCl using the Cockcroft-Gault equation.” “A drug interaction alert should fire for this specific combination.”
The Database (The Prescription Files)
The database is where all the application’s data is stored in a structured way, typically in tables. It’s the system’s long-term memory. In our analogy, it’s the massive filing system of patient profiles and prescription hard copies. Every piece of information—patient demographics, allergies, medication history, lab results—lives in the database.
Your Role: You are the subject matter expert for the data itself. “We need to make sure the database table for medications includes a field to capture the NDC number.” “Is the ‘allergy’ field a free-text field or does it link to a structured drug dictionary? The latter is much safer.”
The API (The Pneumatic Tube & Phone Lines)
An API (Application Programming Interface) is a set of rules that allows different software systems to talk to each other. It’s the messenger that sends requests and brings back data. In our analogy, the API is the pharmacy’s communication system: the phone and fax lines used to receive e-prescriptions from a doctor’s office, and the pneumatic tube system used to send a request to the lab and get a stat potassium level back.
Your Role: You help define what information needs to be exchanged between systems. “When we send a request to the lab system’s API, we need to get back the Serum Creatinine, the collection time, and the reference range.”
Understanding the Developer’s Workflow: Source Control
One final concept is crucial to understanding how developers work as a team: **source control**. All the code for an application is stored in a central repository, and developers use a system like **Git** to manage changes to that code. Think of it like a master formulation record for a very complex compound. Every single change made by any developer is tracked. The system records who made the change, when they made it, and exactly what they changed. This provides three critical capabilities:
- Collaboration: Multiple developers can work on the same application at the same time without overwriting each other’s work.
- Traceability: If a bug is introduced, the team can look back at the history and pinpoint the exact change that caused the problem.
- Reversibility: If a new feature is released and it causes a major, unexpected issue in the live environment, the team can instantly “revert” the change and restore the application to its previous stable state.
9.4.3 Your Role in Development: The On-Demand Clinical Consultant
Your primary responsibility during the build phase is to make yourself an indispensable, accessible, and responsive resource for the development team. You are their guide to the complexities of the clinical world. This requires active participation in the team’s daily routines and a knack for translating technical questions into clinical scenarios.
Masterclass Table: Translating Developer Questions into Clinical Answers
| Developer’s Question | The Hidden Clinical Question | Your High-Value Pharmacist Answer |
|---|---|---|
| “The spec says to display the patient’s weight. What’s the acceptable range for this value? Should I validate it?” | How do we handle neonatal and bariatric patients? What is a clinically absurd weight that likely represents a typo? | “Great question. Let’s set the acceptable range from 0.5 kg to 500 kg. If a user enters a value outside that range, we should display a soft warning like, ‘This weight is unusual, please confirm it is correct.’ But don’t make it a hard stop, because we do occasionally have patients outside the normal range. This prevents a simple typo like ‘800’ instead of ’80’ from going unnoticed.” |
| “For the infusion rate field, should the data type be an integer or a decimal?” | Do any of our infusions, now or in the future, run at a rate that isn’t a whole number? | “It absolutely must be a decimal. Many of our critical care and neonatal drips, like dopamine or heparin, are titrated to rates like ‘1.5 mL/hr’ or ‘0.25 mL/hr’. Using an integer field would make it impossible to order these safely.” |
| “How should I sort the list of medications when a user searches for ‘lisinopril’?” | What is the most efficient and safest way for a clinician to find the exact product they are looking for to avoid a selection error? | “The sorting logic is critical for safety. It should be sorted first by brand/generic, then alphabetically, and then by strength, from lowest to highest. So, a search for ‘lisinopril’ should show ‘Lisinopril 2.5mg’, then ‘Lisinopril 5mg’, then ‘Zestril 10mg’. This is the most predictable pattern for prescribers.” |
| “The user story says to alert on duplicate therapy. How do I define ‘duplicate’?” | What constitutes a true therapeutic duplication that we need to warn about, versus an intended combination? | “This needs to be based on the therapeutic class, not just the generic name. For example, an order for ibuprofen should fire a duplicate therapy alert if the patient already has an active order for ketorolac, since they are both NSAIDs. However, an order for an ACE inhibitor should *not* fire a duplication alert if the patient is on an ARB, as this can be an intended combination. Let’s schedule 30 minutes to walk through the specific classes we need to build alerts for.” |
| “I’m working on the order verification screen. What happens if the pharmacist’s session times out while they have an order open?” | What is the safest state to leave an unverified order in if the workflow is interrupted to prevent a missed dose or an unverified order from appearing verified? | “This is a key safety scenario. If the session times out, the system must automatically release the lock on that order and return it to the general verification queue. It must not remain ‘locked’ to the pharmacist who timed out, otherwise that order could be delayed for hours. We should also log an event that the order was released due to timeout.” |
Participating in Agile Ceremonies
If your team is using Scrum, your participation in the daily “ceremonies” is non-negotiable.
- The Daily Stand-up: This is a 15-minute meeting each day where each team member briefly states what they did yesterday, what they will do today, and if they have any blockers. Your role is not to give a status report, but to listen intently for blockers that you can resolve. When a developer says, “I’m blocked on the chemotherapy dose rounding story because I’m not sure about the rules,” your response should be, “I can help with that. Let’s connect right after this meeting and I’ll walk you through the policy.”
- Backlog Refinement (Grooming): This is a regular meeting where you, as the Product Owner, review upcoming user stories with the development team. The goal is for the team to ask questions and discuss the stories so they can get a rough estimate of the effort involved. This is a crucial time for you to clarify requirements and add acceptance criteria based on the team’s questions, ensuring a story is “ready for development” before it gets pulled into a sprint.
9.4.4 Navigating the Inevitable: Constraints and Compromises
No project goes exactly as planned. During development, the team will inevitably run into technical limitations, unexpected complexity, or resource constraints that make the original design difficult or impossible to implement as specified. When a developer tells you, “We can’t do it that way,” your ability to understand the constraint and negotiate a clinically acceptable alternative is a critical informatics skill.
Understanding Common Technical Constraints
- Technical Debt: The system the team is working on might have been built 10 years ago using outdated technology. A seemingly simple change might require a major rewrite of an old, fragile part of the code. This is “technical debt”—the implied cost of rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
- Performance Impact: Your request might be possible, but it would slow the system down to an unacceptable degree. “Yes, we can cross-reference the patient’s entire medication history against their genomic data in real-time for every order, but it would make the CPOE screen take 45 seconds to load.”
- API Limitations: The team might be dependent on an external system that doesn’t provide the data they need. “We can’t display the patient’s insurance formulary status because the insurance company’s API doesn’t expose that information to us.”
The Art of the Compromise: The “Good, Better, Best” Framework
When you’re faced with a technical constraint, avoid a “yes/no” confrontation. Instead, facilitate a collaborative problem-solving session using the “Good, Better, Best” framework. Your goal is to find the most value you can get for the least technical cost.
Scenario: Your “Best” requirement was to have the EHR automatically pull in a patient’s full medication history from the state’s Prescription Drug Monitoring Program (PDMP) and auto-populate it in the medication reconciliation screen. The developer comes back and says, “We can’t do that. The PDMP’s API is old and doesn’t support that kind of direct integration.”
Your Negotiation:
- “Best” (Not Possible): “Auto-import and auto-populate the data.”
- “Better” (The Compromise): “Okay, I understand we can’t auto-import. How about this: can we place a button on the med recon screen labeled ‘View PDMP’? When the nurse clicks it, can it open a new browser window and pass the patient’s name and DOB to the PDMP login screen? That way the nurse doesn’t have to manually type the patient’s info.”
- “Good” (The Fallback): “If we can’t even pass the patient’s information, can we at least provide a simple hyperlink to the PDMP website from the med recon screen, so the nurse doesn’t have to remember the URL?”
By engaging in this way, you show the development team that you understand their constraints, but you also ensure that you are still solving the core clinical problem—making it easier for the nurse to access vital information. You have successfully negotiated a high-value compromise.
9.4.5 Conclusion: The Clinical Anchor in a Sea of Code
The development and build phase is the longest and most technically intensive part of the SDLC. While the developers are heads-down, turning logic into functional software, your role is to be the steadfast clinical anchor for the project. You are the constant, reliable source of truth for the thousands of small, seemingly minor clinical decisions that developers must make every day. Your responsiveness prevents delays, your clarity prevents rework, and your clinical judgment prevents safety errors from being coded into the system’s DNA.
This requires a shift in your professional mindset. You must be comfortable with the ambiguity of a work-in-progress. You must learn to speak the language of developers, translating their technical queries into real-world clinical scenarios. And you must be a skilled negotiator, knowing when to hold firm on a critical safety requirement and when to accept a creative compromise in the face of a technical constraint. By embracing this role, you ensure that the final product that emerges from the “black box” of development is not just what was specified in a document months ago, but is a robust, safe, and effective tool that truly meets the needs of your patients and clinical colleagues.
