FC Documentation & Deliverables

February 2026 · 20 min

Why Documentation Matters

Documentation is the FC's primary deliverable. Code is written by developers; configurations are done in the system; but the bridge between business requirements and technical execution is always a document.

Poor documentation causes:

• Scope creep -- "I told you I needed X" vs "The document says Y"
• UAT failures -- testers don't know what to test because expected behaviour is undocumented
• Support nightmares -- the hypercare team cannot troubleshoot without knowing what was configured and why
• Legal exposure -- in healthcare, audit trails start with signed documents

Business Requirement Document (BRD)

The BRD captures what the hospital needs, not how the system will do it. It is the single most important document because everything flows from it.

BRD Structure:

1. Executive Summary -- 1 paragraph summarizing the project scope
2. Stakeholder List -- name, role, department, contact for every interviewee
3. Current State (As-Is) -- describe current workflows per department, pain points, volume metrics
4. Future State (To-Be) -- describe desired workflows with Bio Ecko, expected improvements
5. Requirement Matrix -- every requirement with ID, description, priority (MoSCoW), source department, acceptance criteria
6. Assumptions & Dependencies -- e.g., "Hospital will provide dedicated LAN by Week 4"
7. Out of Scope -- explicitly list what is NOT included to prevent scope creep
8. Sign-off Page -- signatures from hospital director, department heads, project sponsor

BRD Quality Checklist:

• Every requirement has a unique ID (e.g., BRD-OPD-001)
• Every requirement has clear acceptance criteria
• Priority assigned using MoSCoW (Must/Should/Could/Won't)
• No technical jargon -- written in hospital staff language
• Current volumes documented (patients/day, bills/day, tests/day)
• Signed by at least 3 department heads

Functional Requirement Specification (FRS)

The FRS translates the BRD into how Bio Ecko will meet each requirement. It is the FC's primary communication tool with the development team.

FRS Structure per Requirement:

Writing Tips:

• Use active voice: "System displays" not "The displayed information is shown"
• Be specific: "Max 20 appointments per slot" not "Limit appointments"
• Include negative scenarios: "If patient has no phone number, skip SMS step"

Configuration Workbook

The Configuration Workbook is a spreadsheet (or structured document) that records every setting configured in Bio Ecko during the implementation.

Why It Matters:

• It is the blueprint for reproducing the setup in another branch or hospital
• It serves as the audit trail for why a particular setting was chosen
• The support team uses it to troubleshoot post go-live

Workbook Sections:

1. Organisation Setup -- hospital name, branches, departments, floors, wards, beds, rooms
2. User & Role Setup -- user list, role assignments, permission overrides
3. Clinical Masters -- department list, doctor schedules, consultation fees, specialities
4. Service & Tariff Masters -- service catalogue, tariff plans (general/private/VIP), package rates
5. Pharmacy Masters -- drug catalogue, generic-brand mapping, formulary, controlled substance list, reorder levels
6. Lab & Radiology Masters -- test catalogue, normal ranges, panel configurations, equipment mapping
7. Billing Configuration -- tax settings (GST), discount rules, payment modes, receipt numbering, insurance TPA mappings
8. Notification Settings -- SMS templates, email templates, WhatsApp triggers
9. Print Templates -- prescription format, bill format, lab report format, discharge summary format
10. Integration Settings -- ABDM endpoints, payment gateway keys, external lab interfaces

Each entry records:

Test Cases & Scripts

Every configured workflow must have a corresponding test case. The FC writes test cases; the hospital staff (super users) execute them during UAT.

Test Case Structure:

Test Coverage Categories:

• Positive tests -- happy-path scenarios (80% of cases)
• Negative tests -- invalid inputs, boundary conditions, permission violations
• Integration tests -- cross-module flows (OPD -> Lab -> Pharmacy -> Billing)
• Regression tests -- re-run after bug fixes to ensure nothing broke
• Performance tests -- can the system handle peak load (Monday morning OPD with 200 concurrent users)?

Standard Operating Procedures (SOPs)

SOPs are written for hospital staff, not for the IT team. They describe how to perform a task using Bio Ecko in simple, step-by-step language.

SOP Writing Rules:

1. Use local language if staff are not English-fluent
2. Include screenshots for every step
3. Maximum 1 page per SOP (if longer, split into sub-SOPs)
4. Number every step sequentially
5. Include "What to do if something goes wrong" section
6. Print and laminate -- tape near the workstation

SOPs to Create per Department:

Training Manuals

Training manuals differ from SOPs. SOPs tell staff what to do. Training manuals teach them why and how the system works so they can handle variations.

Training Manual Structure (per role):

1. Introduction -- what Bio Ecko is, why the hospital adopted it, what changes for this role
2. Login & Navigation -- how to log in, dashboard overview, menu structure, common icons
3. Core Workflows -- step-by-step with screenshots for the 5-7 most common tasks
4. Advanced Features -- shortcuts, templates, bulk operations, report generation
5. Troubleshooting -- top 10 common errors and how to resolve them
6. FAQ -- answers to the 10 most-asked questions from that role during training
7. Quick Reference Card -- 1-page cheat sheet (printed separately for workstation)

Writing Tips for Training Manuals:

• Use "you" language: "You will see a green button" not "The user clicks the green button"
• Screenshot every 2-3 steps -- a wall of text is useless for a first-time user
• Use callout boxes for tips and warnings
• Include practice exercises: "Now try creating a test appointment for patient 'Demo Patient'"

Handover Document

The Handover Document is the FC's final deliverable, created at the end of hypercare to formally transfer knowledge to the hospital's internal IT team and the vendor's support team.

Handover Package Contents:

• Signed BRD (final version)
• Signed FRS (final version with all change requests incorporated)
• Configuration Workbook (updated to reflect all post go-live changes)
• Master Data Sheets (all imported data with row counts and checksums)
• Test Case repository with execution results
• Defect log with resolution status (all P1/P2 closed)
• Training manuals (per role)
• SOPs (per department)
• Integration credentials and endpoints (stored in password manager, not in document)
• Known Issues list (documented workarounds for items deferred to Phase 2)
• Escalation matrix (L1: hospital IT, L2: vendor support, L3: development team)
• Licence and subscription details

Handover Meeting Agenda:

1. Walk through the handover package (30 min)
2. Live demo of admin functions the hospital IT team will manage (60 min)
3. Q&A (30 min)
4. Sign-off (both parties sign the handover acceptance form)

Notes

Related topics