1. Executive Summary

Blood Bank Management turns Dolibarr ERP & CRM into a complete operational system for a blood bank, a regional or national transfusion centre, a hospital blood depot, an authorised laboratory, a fixed collection unit, a mobile collection team or an NGO running donation drives. It covers the entire chain from donor registration to the delivery of a labile blood product to a healthcare institution, and back again through end-to-end traceability and hemovigilance.

The module is delivered as a native Dolibarr external module. It adds 51 business objects, 79 menu entries, 20 granular permission groups, a real-time operations command center, 11 decision reports, a REST API with 51 CRUD resources and 6 business routes, two scheduled surveillance jobs, a traceability trigger, a PDF generator covering 33 document families, and a complete demonstration dataset. It is available in French, English, Spanish, Italian and German.

1.1 Design position: a management tool, never a decision maker

This point governs the whole design. The module manages, records and traces. It never substitutes itself for a qualified professional. It does not perform donor medical assessment, does not decide to accept or exclude a donor, does not interpret biological results, does not validate a blood group, does not qualify a donation, does not release a blood product, does not validate compatibility, does not decide to transfuse, and does not take hemovigilance decisions.

These constraints are enforced in the code, not merely stated in the documentation:

 

2. Business Objectives

·       Guarantee the traceability of every blood product from the donor to the recipient, and back.

·       Secure donor identification and the double identification of bags, tubes and samples.

·       Structure biological qualification and enforce the double determination rule for blood groups.

·       Control product release: no unit leaves the bank without an explicit, signed, traceable decision.

·       Keep the cold chain under permanent surveillance and manage temperature excursions as a workflow.

·       Give real-time visibility on availability per blood group, with configurable critical thresholds.

·       Reduce loss through a FEFO logic that surfaces the nearest expiry first.

·       Handle transfusion requests, compatibility, reservations, deliveries, emergencies and returns.

·       Manage hemovigilance cases and product recalls, with the ability to reach every affected unit.

·       Support the quality system: audits, non-conformities, corrective and preventive actions, continuity plans.

·       Manage the equipment park, maintenance, calibration and availability.

·       Bill partner institutions, follow costs and profitability.

·       Open the data through a secured REST API for analysers, probes and third-party systems.

3. Functional Scope

 

4. User Roles and Permissions

The module ships 20 granular permission groups and 57 individual rights. Read and write are granted by default so the module is usable immediately after activation; delete and administration are off by default. The principle of least privilege is applied throughout: every page, list, card, report and API route is gated by the same mapping.

 

5. Dashboard

The home screen of the module is the Blood Supply and Transfusion Operations Command Center. It is organised in five layers, all refreshed from live data.

5.1 Blood product lifecycle

A horizontal ring shows the nine stages of the chain with their live counts: Donor, Collection, Sample, Qualification, Preparation, Release, Stock, Delivery, Traceability. It gives an immediate reading of where the volume currently sits.

5.2 Availability map by blood group

Eight tiles, one per ABO/Rh group, each showing available units, a fill gauge against the configured target, and a level: comfortable, to watch, low, critical, shortage. Levels come from the stock thresholds, which are configurable per group, per component and per site.

5.3 Alert tiles

Ten clickable tiles surface the operational signals that need action: critical blood groups, urgent requests, imminent expiry, out-of-range temperature, quarantined products, pending biological results, returns awaiting a decision, open hemovigilance cases, open non-conformities and unavailable equipment.

5.4 Key indicators

Thirty-eight indicators grouped by zone:

·       Collection: appointments today, expected donors, donors present, donations today and this month, donations in progress, regular donors, deferred donors, bags collected, declared donor reactions.

·       Laboratory and preparation: pending analyses, results to validate, components prepared, released, quarantined, rejected, release rate, control conformity rate.

·       Stock and delivery: total available stock, reserved units, near expiry, expired, requests received, urgent requests, deliveries today, returns.

·       Cold chain, quality and billing: cold chain alerts, open excursions, unavailable equipment, upcoming maintenance, open non-conformities, open incidents, average cost per donation and per component, revenue, payments received, outstanding amounts, rejection rate, expiry rate.

5.5 Charts

Four charts: donations per month over twelve months, stock by blood group, stock by component type, and requests by urgency level. Every monthly series produces twelve buckets even when a month has no data, so the trend cannot be misread.

6. Donors

The donor file holds the internal identifier and donor number, civility, name, birth date, administrative sex, national identifier, full address, phone, e-mail, preferred language, profession, employer, home site, declared and validated blood group, phenotype, emergency contact, family doctor, communication preferences, portal access, and the full donation history.

·       Duplicate detection through a normalised matching fingerprint stored on each record.

·       Multi-criteria search on number, name, birth date, national identifier, town, phone, e-mail and blood group.

·       Nine statuses: candidate, active, regular, occasional, temporarily deferred, permanently deferred, excluded, inactive, archived.

·       Deferral is carried explicitly: a deferral end date and a reason recorded by the professional.

·       Next eligible date computed from the last donation and the configured minimum interval.

·       Archiving and access restriction; every access and modification is written to the audit trail.

7. Donor Portal

The donor portal console manages the self-service requests received from donors and the population of donors who have portal access enabled.

·       Request queue with type, channel, subject, date, status and handling.

·       Request types: account creation, contact update, appointment booking, cancellation, preliminary questionnaire, consent signature, certificate request, document upload, administrative message.

·       Breakdown by request type and list of portal-eligible donors.

·       No sensitive biological result is exposed on the portal without a specific authorisation.

8. Donation Campaigns

A campaign carries its reference, name, type, organiser, partner company, site, mobile team, location, start and end dates, time slots, capacity, donation target, target audience, budget, and its results: registered, presented, collected.

·       Eight campaign types: company, school, university, municipality, association, military, place of worship, public event.

·       Ten statuses from draft through planning, to validate, validated, open, running, suspended, finished, closed, cancelled.

·       Campaign performance is reported: registration, attendance and collection conversion.

9. Appointments and Planning

Appointments cover whole blood, plasmapheresis, plateletpheresis, double red cell, granulocyte and programmed autologous donation.

·       Fourteen statuses tracking the donor's real journey: requested, to confirm, confirmed, reminded, arrived, waiting, in interview, authorised, collecting, in recovery, done, absent, cancelled, postponed.

·       Week planning board with one column per day, capacity load against the mobile teams' declared daily capacity, and campaign overlay.

·       Waiting list, reminders, confirmations, cancellations with reason, rescheduling.

·       The no-show rate counts only appointments whose date has passed, so it is not diluted by future bookings.

10. Admissions

The admission record opens the donor's on-site journey: donor, appointment, campaign, site, planned and actual arrival time, identity verified, contact details verified, questionnaire available, consent available, donation type, reception agent, status and observations.

·       Six statuses: registered, identity verified, documents missing, oriented to the interview, cancelled, done.

11. Pre-Donation Questionnaires

The questionnaire engine records the version of the form used, the fill date and mode (paper, tablet, portal, interview), the number of questions and the number of flagged answers, the declared items (travel, treatment, surgery, vaccination) and the vigilance points.

·       Five statuses: draft, submitted, reviewed by the professional, vigilance points, validated.

·       The module never decides fitness from a questionnaire. It surfaces vigilance points for a professional to weigh.

12. Donor Assessment and Pre-Donation Constants

The assessment record carries the interview and the measured constants: weight, height, body temperature, systolic and diastolic pressure, pulse, pre-donation haemoglobin, plus the verifications performed (identity checked, history reviewed).

·       Six decisions: fit, to review, temporary deferral, permanent deferral, cancelled, referred for medical advice.

·       A deferral records its duration and the review date.

·       Every decision is timestamped, attributed to the professional and journalised.

·       A donation can only be created when the assessment concluded 'fit'.

13. Consent Management

Consents are managed as versioned documents: donation consent, data processing, data retention, communications, donation reminders, and authorised research.

·       Each consent stores its type, document version, date and time, signature mode (handwritten, electronic, tablet, remote), signatory, collecting user, and the attached document.

·       Withdrawal is a first-class state with its own date.

14. Donation Management

The donation record holds reference, donor, appointment, campaign, assessment, site, station, donation type, date, start and end time, duration, collecting nurse, device used, kit lot number, collected volume, reaction flag, status and observations.

·       Nine statuses: planned, authorised, prepared, running, done, interrupted, cancelled, non-conform, archived.

15. Double Identification

Double identification is recorded on the donation and carried onto the bag and the samples. The donation stores whether the double check was performed and by whom.

·       Barcode and QR code are stored on bags, samples and components.

·       Bag, sample and component identifiers are derived from the same donation serial, so a mismatch is immediately visible.

·       The traceability page resolves a donor, donation, bag, barcode or component reference to the same chain.

16. Blood Bags

A bag carries a unique identifier, barcode, QR code, source donation and donor, bag type (single, double, triple, quadruple, apheresis kit), kit reference and lot, collection date and time, volume, anticoagulant, site, operator and status.

·       Eleven statuses: created, collecting, collected, waiting, in qualification, in preparation, released, quarantined, rejected, destroyed, used.

17. Samples and Tubes

Each donation generates its sample tubes: identifier, barcode, donor, donation, source bag, tube type (EDTA, dry, citrate, serum gel, heparin), planned analysis, draw date, collector, site, laboratory reception date and storage slot.

·       Nine statuses: created, drawn, received, accepted, in analysis, analysed, validated, rejected, destroyed.

18. Donor Reactions

A donor reaction records the donor, the donation, date and time, reaction type, declared signs, severity, immediate action, professional, referral and follow-up.

·       Reaction types: vasovagal, haematoma, nausea, paraesthesia, arterial puncture, syncope, citrate reaction, other declared sign.

·       Four severity levels and four statuses (declared, under review, follow-up, closed).

·       The module records declared signs. It never produces a diagnosis.

19. Laboratory Qualification

Analyses are organised in families: blood grouping, phenotyping, biological screening, internal quality control and other authorised analyses.

·       An analysis carries the sample, donor, donation, family, code, label, planned and run date, technician, biologist, analyzer, reagent lot, repeat count and status.

·       Eight statuses covering planning, assignment, running, result to validate, technical validation, biological validation, rejection and repetition.

·       Technical and biological validation are two distinct, separately recorded acts.

20. Blood Groups and Double Determination

The blood group record stores a first determination (ABO and Rh) and a second determination, the final group, the phenotype, the Kell antigen, both determination dates, the laboratory and the biologist.

·       Six statuses: declared, provisional, being verified, confirmed, discordant, invalidated.

·       A record only reaches 'confirmed' when both determinations agree; otherwise it stays 'discordant' with no final group, and a dashboard alert is raised.

·       The requirement can be enforced or relaxed from the module configuration.

21. Biological Results

Each result stores the analysis, sample, parameter code and label, value, unit, method, device, reagent lot, reference range, interpretation, date, technician and status.

·       Interpretations: negative, positive, non-reactive, reactive, indeterminate, conform, non-conform.

·       Statuses: raw, technically validated, biologically validated, rejected, repeated.

·       The module stores and displays results. It does not interpret them.

22. Analyzer Integration

The analyzer import journal records every batch received from a laboratory instrument.

·       Sources: CSV, Excel, REST API, SFTP deposit, watched folder, manual entry.

·       Each import stores the analyzer, file name, date, rows read, rows matched, rows rejected, duplicates, mapping profile, checksum, user, status and an error log.

·       Duplicate detection and reconciliation against the sample identifier are part of the import contract.

23. Component Preparation

A preparation transforms a bag into components: source bag, donation, date, protocol, operator, equipment, centrifuge program, consumable lot, input and output volume, number of components produced, yield and status.

·       Protocols: buffy coat, platelet-rich plasma, apheresis, cryoprecipitation, manual separation.

·       Component types produced: whole blood, red cell concentrate, fresh frozen plasma, standard platelet concentrate, apheresis platelet concentrate, cryoprecipitate, custom product.

24. Blood Components

The component is the unit that is stored, reserved and delivered. It carries a unique identifier, barcode, QR code, type, source preparation, bag, donation and donor, blood group, phenotype, volume, preparation date, expiry date, storage condition, storage unit, site, unit cost, sale price, irradiation and leucoreduction flags, status and label state.

·       Eleven statuses: prepared, in control, awaiting release, released, reserved, delivered, returned, quarantined, rejected, expired, destroyed.

·       Shelf life is applied per component type: 35 days for whole blood, 42 for red cells, 365 for frozen plasma and cryoprecipitate, 5 to 7 days for platelets.

25. Quality Controls

Quality controls are recorded per component: control type, date, operator, method, measured value, unit, minimum and maximum thresholds, conformity, status and corrective action.

·       Control types: volume, haemoglobin, haematocrit, platelet count, residual leucocytes, sterility, pH, visual inspection.

·       A component whose mandatory controls are not validated cannot be released.

26. Product Release

Release is the pivotal control point. The release record carries six explicit verifications: biological qualification completed, blood group validated, controls validated, labelling verified, expiry verified, lot status verified.

·       It also records the releasing professional, their role (biologist, medical director, quality manager, authorised technician), the signature and the date.

·       Only a released component enters available stock, can be reserved and can be delivered.

·       After release the critical fields are locked and any correction is traced.

27. Labeling

The labelling console lists the released components still awaiting a final label and previews the mandatory mentions.

·       A label carries the centre, the unique identifier, the barcode, the component type, the blood group in large type, collection, preparation and expiry dates, the volume, the leucoreduction and irradiation flags, and the storage condition.

·       Reprinting is controlled and journalised.

28. Quarantine

Quarantine blocks a product: it can no longer be reserved, delivered, transferred or used.

·       Reasons: pending biological result, discordant result, cold chain break, labelling anomaly, identification problem, declared incident, product recall, other.

·       The decision is explicit: pending, release, reject, destroy, transfer. It is never taken automatically.

·       Quarantined units are physically routed to a dedicated storage unit.

29. Rejection and Destruction

A destruction record carries the component, the source bag, date, reason, quantity, method, responsible person, witness, loss cost and status.

·       Reasons: non-conform result, identification problem, insufficient volume, expiry, cold chain break, preparation anomaly, storage anomaly, non-reintegrable return, incident, other.

·       Methods: incineration, autoclaving, approved provider, chemical inactivation.

·       The rejection rate reported by the module counts quality rejections only; end-of-life expiry loss is reported separately so neither figure misleads.

30. Inventory and Stock

Stock is managed by blood group, Rh, phenotype, component type, site, storage unit, status and expiry date.

·       The stock board shows available, reserved, quarantined and near-expiry volumes, the availability map, a blood group by component matrix, and the FEFO queue.

·       Physical inventories record theoretical quantity, counted quantity, gap and gap value.

·       Inter-site transfers and transports carry container, carrier, departure and arrival temperature.

31. FEFO and Expiry

The module applies a First Expired, First Out logic: when a request is served, the released units with the nearest expiry are proposed first.

·       The FEFO proposal is a logistics aid. It never replaces the validation of an authorised professional, and the API states this explicitly on every returned unit.

·       Alerts: imminent expiry, expiry today, expired product, high expiry rate, loss risk.

32. Critical Stock

Thresholds are configurable per blood group, per component type and per site, with an average daily use and a seasonal factor.

·       Five levels: normal, to watch, low, critical, shortage.

·       The availability map is computed live and drives both the dashboard tiles and the daily scheduled check.

33. Transfusion Requests

A request carries reference, institution, prescriber service, prescriber, recipient, declared blood group, component type, quantity requested and delivered, clinical indication, urgency level, request and wanted date, status and observations.

·       Nine statuses: draft, received, to check, validated, partially satisfied, satisfied, refused, cancelled, closed.

·       Four urgency levels: routine, urgent, very urgent, immediate vital emergency.

34. Recipients

The recipient file is structurally separate from the donor file: its own table, its own permission group, its own access restriction flag, and no foreign key joining the two.

·       It carries the internal identifier, identity, institution, service, blood group, phenotype, irregular antibodies, transfusion history, special requirements and access restriction.

·       The only link between a recipient and a donor is the product chain, which is exactly what regulated traceability requires.

35. Compatibility

A compatibility test links a request, a recipient and a component, and records both blood groups, the test type, method, date, technician, biologist, the rule consistency check, the result and the human validation.

·       Test types: ultimate ABO check, direct crossmatch, irregular antibody screen, phenotype match, electronic consistency check.

·       The module checks the coherence of configurable rules and raises alerts. It never validates clinical compatibility by itself.

36. Reservations

A component can be reserved for a request, a recipient, an institution, a surgical procedure, an emergency or a transfer.

·       The reservation stores its date, expiry, motive, FEFO rank, responsible person and status.

·       Six statuses: reserved, confirmed, delivered, released from reservation, expired, cancelled.

·       Expired reservations are surfaced in the alert centre.

37. Deliveries

A delivery carries reference, request, institution, service, recipient, date, number of units, responsible person, carrier, container, departure temperature, double check, emergency flag and level, deferred controls, receipt signature, billed amount and status.

·       A double check is recorded before delivery: right institution, right service, right recipient, right product, right group, right identifier, right date, right quantity, right temperature, right documentation.

·       Delivery lines carry the component reference, type, blood group, volume, expiry and unit price.

38. Emergency Workflow

Emergency deliveries are handled through a configurable workflow.

·       Emergency levels: none, relative urgency, immediate vital emergency, mass casualty influx.

·       Deferred controls are recorded explicitly with their justification, so a retrospective audit can always establish what was checked and when.

·       Request, preparation, departure and reception times are all timestamped.

39. Returns

A return records the delivery, the component, the institution, date, transport conditions, return temperature, integrity verification, reason, responsible person and decision.

·       Decisions: pending, reintegrate, quarantine, destroy.

·       The module never reintegrates a returned product automatically. The decision stays 'pending' until a human takes it.

40. Transfers and Transportation

Inter-site transfers and transports are managed as distinct objects.

·       Transfers: source and destination site, date, units, component type, container, carrier, departure and arrival temperature, arrival date, status.

·       Transports: type (internal, external, urgent, mobile team, inter-site, institution delivery), vehicle, plate, carrier, container, departure and arrival time and temperature, distance, cost, incident flag and receipt proof.

41. Cold Chain

The cold chain module covers refrigerators, freezers, platelet agitators, cold rooms, transport containers and refrigerated vehicles.

·       Each storage unit declares its minimum and maximum temperature, reading frequency, capacity, calibration dates and status.

·       The monitoring board shows every unit with its last reading in or out of range, and 21-day temperature curves per unit.

·       Readings can be entered manually, imported from CSV or Excel, pushed through the REST API by a connected probe, or captured on mobile.

42. Temperature Excursions

An excursion follows an explicit workflow: alert, identification of the affected products, blocking, quarantine, analysis, decision, release or transfer or destruction, report, closure.

·       The record stores the storage unit, start and end, duration, minimum and maximum temperature, number of components affected, immediate action, responsible person, decision, impact cost and status.

·       The decision is always human: pending, maintain and release, quarantine, transfer, destroy.

43. Equipment and Maintenance

The equipment park covers collection chairs, mixers, scales, centrifuges, separators, tube sealers, presses, analyzers, refrigerators, freezers, agitators, data loggers, probes, label printers, barcode scanners, computers, tablets, vehicles and containers.

·       Each record carries manufacturer, model, serial number, site, room, installation and commissioning dates, supplier, warranty, contract, purchase cost, failures, downtime, MTBF, MTTR, operational availability, next maintenance and next calibration.

·       Maintenance covers preventive, corrective, calibration, qualification and periodic control, with provider, technician, parts, costs, downtime and conformity.

44. Continuity Planning

Continuity plans cover the scenarios that can interrupt the activity.

·       Scenarios: power failure, refrigerator failure, freezer failure, analyzer failure, site unavailability, network incident, consumable shortage, stock shortage, mass casualty influx.

·       Each plan carries its criticality, procedure reference, backup site, emergency contacts, maximum acceptable downtime, last and next drill date and drill result.

45. Hemovigilance

A hemovigilance case carries reference, type, date, institution, donor, recipient, component, delivery, lot reference, description, severity, imputability, immediate action, investigation, responsible person, declaration to the authority and status.

·       Case types: donor incident, donation reaction, product incident, identification error, biological issue, delivery issue, transport issue, declared transfusion reaction, product recall.

·       Four severity grades and six imputability levels, from excluded to certain.

·       From any case, the full traceability chain of the implicated product is one click away.

46. Product Recall

A recall identifies the affected scope and follows the retrieval.

·       Scopes: single unit, whole donation, all donations of a donor, consumable lot, production batch.

·       The record tracks units in stock, delivered, returned and destroyed, the sites concerned and the institutions notified.

47. Quality and Non-Conformities

The quality system covers audits, non-conformities, corrective and preventive actions.

·       Audits are scoped to a process: donor reception, collection, laboratory, preparation, labelling, storage, delivery, transport, cold chain, hemovigilance, data security.

·       Each audit records the type (internal, external, certification, regulatory inspection), the standard reference, criteria, conformities, gaps and score.

·       A non-conformity carries the process, severity, immediate action, root cause, corrective and preventive action, responsible person, due date and effectiveness verification.

48. Partner Institutions

Institutions are linked to Dolibarr third parties and carry their convention.

·       Types: public hospital, private hospital, clinic, authorised laboratory, blood depot, NGO, other centre.

·       Each institution carries its convention reference, start and end dates, price list and payment terms.

·       Prescriber services are managed per institution with their head doctor and annual request volume.

49. Billing and Cost Management

Billable services cover collection, campaigns, analyses, preparation, delivery, transport, storage, laboratory services, hemovigilance services, convention fees and complementary services.

·       Each item carries the institution, delivery, request, designation, quantity, unit price, amounts, billing date, linked invoice, paid amount and status.

·       Cost items cover collection kits, consumables, reagents, staff, energy, preparation, storage, maintenance, transport, destruction, losses and external services.

·       Average cost per donation and per component are computed from actual cost lines; a unit with no recorded cost is treated as unknown, not as zero.

50. Reporting and Business Intelligence

Eleven decision reports are provided: donors, donations, laboratory, components, stock, requests, cold chain, equipment, hemovigilance, quality, billing.

·       Every monthly series produces twelve buckets even when a month is empty, so trends cannot be misread.

·       Analyses cover donation forecasting, needs forecasting, availability per group, shortage and expiry risk, rejection and loss rates, site load, campaign performance, donor retention, no-show rate, qualification, preparation and delivery lead times, consumption per institution, equipment utilisation, costs, margins and profitability.

·       These analyses are decision support for management. They are never converted into an automatic medical or biological decision.

51. Alerts and Notifications

The alert centre consolidates seventeen operational signals into summary tiles plus a detailed list of the offending records, each linked to its card.

·       Unconfirmed appointments, flagged questionnaires, analyses awaiting validation, discordant blood groups, quarantined components, imminent expiry, expired products, open urgent requests, expired reservations, returns awaiting decision, out-of-range temperature readings, open excursions, unavailable equipment, planned maintenance, open non-conformities, open hemovigilance cases, overdue invoices.

·       Two scheduled jobs feed the signals: an hourly cold chain check and a daily expiry and stock check.

52. REST API

The API exposes 51 CRUD resources plus six business routes, under /api/index.php/bloodbank/.

·       Business routes: stock availability, FEFO suggestion, forward traceability from a donation, backward traceability from a component, temperature reading push, consolidated indicators.

·       Authentication uses the Dolibarr API key; every route is gated by the same permission group as the user interface.

·       Sort and filter fields are whitelisted against the object's real columns; write payloads are filtered against the registry.

·       Structured errors: 401 unauthenticated, 403 insufficient rights, 404 unknown resource or record, 500 with a message.

53. Security and Confidentiality

Security is applied at every layer.

·       CSRF protection on all forms, XSS escaping on all output, parameterised and escaped SQL, strict input validation.

·       Twenty granular permission groups; least privilege by default; multi-company partitioning on every query.

·       Structural separation of donor and recipient data, with an access restriction flag on recipients.

·       Full audit trail: user, date, action, object, field, old and new value, result and IP address.

·       Locked critical fields after release, with traced corrections.

·       No sensitive personal data written to the system log.

54. End-to-End Traceability

Traceability works in both directions and is available from a dedicated screen and from the API.

·       Forward: donor, donation, bag, sample, analysis, component, release, stock, reservation, delivery, recipient.

·       Backward: a delivered unit resolves to its component, source bag, donation and donor.

·       A search accepts a donor number, a donation reference, a bag identifier or barcode, or a component identifier or barcode.

·       Every traceability lookup is written to the audit trail, and access is gated by the hemovigilance permission.

55. Demonstration Data

The module ships a complete demonstration dataset generator, reachable from the configuration page.

·       It creates around 11 700 rows across all 51 objects, forming one coherent chain from donors to deliveries.

·       Every row is tagged with the technical marker BBKDEMO and the mention 'fictitious demonstration data'.

·       The clear button removes exactly those rows inside a transaction, cascades to children created by users under a demonstration parent, clears the guard constant and returns a figure report.

·       Real data is never touched.

56. Installation and Deployment

The module installs as a standard Dolibarr external module.

·       Deploy module_bloodbank-1.0.zip from Home, Setup, Modules, Deploy external module, or copy the bloodbank folder into htdocs/custom.

·       Activate the module, configure thresholds and safety rules, assign permissions, optionally load the demonstration dataset.

·       Compatible with Dolibarr 16 to 23, PHP 8.0 and above, MySQL and MariaDB, mono and multi-company, single and multi-site.

·       Tables are created and self-healed on activation: a version upgrade adds any missing column automatically.

57. Deliverables

 

 

Blood Bank Management  ·  DoliResources  ·  www.doliresources.com