# How to Write a Data Management Plan for Your Microbiology Laboratory By the end of this guide you will have a complete, signed [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) plan (DMP) for your microbiology laboratory, a repeatable inventory of every data file the laboratory produces, a quality control (QC) calculation that runs in seconds and prints an accept or reject decision, and written proof that your backups restore. To work through the walkthrough you need a workstation with PowerShell (Windows) or a Bash terminal (macOS or Linux), Python 3.8 or later with no extra packages, read access to your laboratory information system (LIS) export folders, a spreadsheet application, and your current quality manual together with your records retention schedule. A data management plan is a short, controlled document that answers six questions for every category of laboratory data. What is it. Where does it live. Who may change it. How do we know it is good. How long do we keep it. How does it leave the laboratory. Microbiology makes the exercise harder than most disciplines because a single bench can produce quantitative minimum inhibitory concentrations (MICs), qualitative organism identifications, interpreted susceptibility categories, instrument raw files, molecular amplification data, and stained smear images, and each of those fails in a different way. The cost of leaving data management implicit shows up in the literature from two directions. A consensus effort in a high-volume molecular diagnostics discipline concluded that data volume had outpaced guidance and called for comprehensive recommendations covering messaging, storage and retention, documentation, reporting, validation, and quality control, with explicit attention to keeping the burden feasible for working laboratories [1]. A cross-sectional study of government hospitals in Northwest Ethiopia identified weak documentation, uneven adherence to standard operating procedures (SOPs), and thin quality management among the administrative determinants that hold laboratory service quality down, alongside technical problems such as equipment reliability and workflow organization [2]. A written plan is the cheapest available countermeasure to both. ## What a Data Management Plan Does for a Microbiology Laboratory The DMP is the data chapter of your [laboratory quality management system](/knowledge/diagnostics/emerging-tech/laboratory-quality-management-systems-a-practical-implementation-framework-for-diagnostic-labora). It sits beneath the quality manual, beside the SOPs, and above the daily work of the bench. The quality manual states that the laboratory controls its records. The DMP states exactly how, in language a working technologist can act on during a shift. In practice the plan does five things. 1. It makes every data type findable, with a named owner. 2. It fixes the rules for naming, metadata, and entry so records stay retrievable for years. 3. It defines the QC gate that must pass before patient results are released. 4. It sets storage, backup, retention, and integrity checks. 5. It controls what leaves the laboratory and what record you keep when it does. Microbiology adds four data problems that a generic plan misses, and the plan should name each one. **Breakpoint drift.** A susceptibility category such as susceptible, intermediate, or resistant is an interpretation layered on a measurement. The Clinical and Laboratory Standards Institute (CLSI) revises its breakpoint tables on a regular cycle, so an organism reported as resistant in one year can carry the same MIC reported as susceptible in a later year. The plan must require that the breakpoint or interpretation version be stored with every interpretive result, because the MIC alone cannot explain the discrepancy later. **Nomenclature drift.** Organism names are revised as taxonomy changes, and clinicians search by the name they learned. The plan should require that prior organism names remain searchable, either through a synonym table in the LIS or through the middleware. **Proprietary raw formats.** Instrument raw files are often readable only by the vendor application at a specific software version. Retaining raw data without recording the software version that reads it is a silent failure that surfaces years later during an inspection or a research request. **Qualitative QC.** Rapid tests and some manual procedures produce reactive versus nonreactive or growth versus no-growth results rather than numbers. The plan must state how those control results are recorded, trended, and reviewed, because a Levey-Jennings chart is not available for them. These failure modes are not hypothetical. An analysis of SARS-CoV-2 Emergency Use Authorization diagnostics data documented four problems that transfer directly to laboratory records: tests that could not be told apart because of similar names and inconsistent naming conventions, documents that could not be tracked because identifiers and versioning were inconsistent, data that could not be retrieved because structure and formatting were heterogeneous, and records that drifted because amendments lacked traceable communication [3]. The authors framed the remedy with the FAIR principles, which ask that data be Findable, Accessible, Interoperable, and Reusable. Every naming rule in your plan is a small payment toward that target. ## What to Gather Before You Write Collect eight items first. If one is missing, that gap is the first finding of the exercise and belongs in the plan as an action item. 1. **An instrument register.** Make, model, serial number, firmware or application version, export format, and maintenance status for every analyzer, monitored incubator, and [mass spectrometer](/knowledge/molecular-biology/mass-spectrometer). The air quality sensor field ran a structured workshop on what makes sensor data credible and concluded that active management of the condition, or state of health, of deployed sensors, together with increased documentation of hardware and data handling, ranked among the most pressing needs [4]. Treat each analyzer the same way. Each one is a sensor with a firmware version, a maintenance history, and a failure mode. 2. **An assay register.** Every test offered, its method, its QC material, and the current version of its interpretation standard, whether that is a breakpoint table, a molecular target definition, or a manufacturer interpretation grid. 3. **The QC program.** Control materials and reference strains in use, testing frequency, current control charts, and the statistical rules applied. 4. **The external quality assessment (EQA) program,** also called proficiency testing. Provider, submission portal, shipping and testing windows, and where receipts are filed. 5. **LIS and middleware facts.** Vendor, version, where the database lives, which exports exist, who holds administrator rights, and how an interface retry behaves when a result is sent twice. 6. **The records retention schedule** from your accreditation body or regulator, with the required interval for each record class. 7. **A role roster.** Who directs, who manages quality, who stewards data, who works the bench. 8. **A simple network map.** Which servers and drives hold laboratory data, which of them are backed up, and which backup copies sit offsite. Integrated diagnostic protocols written for resource-limited laboratories now build internal and external quality assurance components, troubleshooting guidance, and recommendations for data management and sample traceability directly into the procedure document, aligned with ISO 15189 and CLSI recommendations [5]. That is the pattern to copy. Keep the plan short enough that a working technologist reads it on shift. ## The Plan Format: Eight Sections That Cover Everything This format fits a two-person bench and scales to a regional network. Keep each section to one page. Write in the present tense. If you search for a [data management plan template](/blog/guides/data-management-plan-template-a-practical-guide-for-researchers) you will mostly find academic versions written for grant funders, and the laboratory version differs in one way that matters: it is written to be audited, so every statement should point to evidence you can produce on demand. ### 1. Data Types and Sources List every data type with its source system, format, approximate volume, and named owner. Cover patient results in all three forms (quantitative, qualitative, interpretive), QC records, EQA records and receipts, instrument raw files, maintenance and calibration logs, training and competency records, deviation and corrective action records, and specimen accessioning or chain-of-custody data. A data type without a named owner is the one that disappears. ### 2. Metadata and Naming Conventions Define the required metadata for every exported file and every record row. A workable minimum is collection or run date in ISO 8601 format (YYYY-MM-DD), instrument identifier, assay or panel code, run or batch number, operator user ID, and a version field. File names carry no spaces and no patient identifiers. State the delimiter and the character encoding explicitly, and specify UTF-8 unless an instrument forces otherwise, because export encodings vary and silent mismatches corrupt downstream reads. This section is where the naming, versioning, and retrieval failures described above get prevented one rule at a time. ### 3. Collection and Entry Controls Free text is the enemy of a microbiology database. Organism names come from a controlled list. Susceptibility interpretations come from the middleware, never from the keyboard. Dates are validated at entry. Critical fields get a second read or a dual-verification step. Structured validation against a defined protocol, with consistency checks before data are accepted, is the same principle formalized in medical image annotation systems that run format validation and multi-annotator consistency analysis before anything reaches analysis [6]. Define what happens on a correction. The original entry stays, the correction is an addendum with a stated reason, and the audit trail records both. ### 4. Microbiology Quality Control Data This is the heart of the plan and the section an assessor reads most closely. State the following for each assay. - **Control materials,** including the standard reference strains used for antimicrobial susceptibility testing (AST) quality control, such as *Escherichia coli* ATCC 25922, *Staphylococcus aureus* ATCC 25923, and *Pseudomonas aeruginosa* ATCC 27853 from the American Type Culture Collection (ATCC). - **Testing frequency,** which in routine practice means each new lot or shipment of disks, cards, or reagents, each new calibration, and each day of patient testing for quantitative methods. - **The chart type.** Quantitative QC goes on a Levey-Jennings chart, which plots each result against the mean and standard deviation (SD) established from at least 20 initial in-control points, the conventional minimum. - **The acceptance and rejection rules,** typically the Westgard multirule set in the table below. - **For molecular assays,** the controls per run: an extraction control, an amplification control, and a no-template control, each with defined acceptance criteria. - **What happens on a QC failure.** Results since the last acceptable QC are quarantined, the cause is investigated across reagent lot, control lot, calibration, and instrument, the investigation is documented, controls are repeated, and only then are results released. - **Where QC data are stored, how often they are exported, and who reviews them and when.** Review is a same-day gate before reporting, not a monthly batch. | Rule | Pattern on the chart | Standard action | |--|--|--| | 1-2s | One result beyond 2 SD from the mean | Warning, check the other rules before accepting | | 1-3s | One result beyond 3 SD from the mean | Reject the run, investigate random error | | 2-2s | Two consecutive results beyond 2 SD on the same side | Reject, suspect systematic error | | R-4s | One result more than 2 SD high and the next more than 2 SD low | Reject, suspect random error | | 4-1s | Four consecutive results beyond 1 SD on the same side | Reject, suspect systematic error | | 10x | Ten consecutive results on one side of the mean | Reject, suspect systematic error | Networks should centralize. A regional laboratory center in Shenzhen deployed an integrated platform that pulled internal QC and external quality assessment into one system across five district hospitals, one central laboratory, and four community health stations, with a single electronic recording system overseeing documentation, analytics, and approval [7]. If your network spans sites, name the centralizing tool and the approval workflow in this section. ### 5. Storage, Backup, and Retention Apply the 3-2-1 rule: three copies of the data, on two different media, with one copy offsite and encrypted. Name the primary storage location, the backup schedule (a common pattern is nightly incremental plus weekly full), the offsite destination, and the restore test schedule. A restore test that has never been run is a hope, not a control. Retention intervals come from your accreditation body's records schedule, and the plan lists the exact interval per data type rather than a vague "as required" statement. Retention must also cover raw instrument files together with the software version needed to read them. For integrity, export files get a cryptographic checksum on creation, described in Step 3 below, and the checksum file is stored beside the data. ### 6. Access, Security, and Audit Trails Grant access by role and by least privilege. Named accounts only, no shared logins, and removal of access on the day a staff member leaves. Audit trails stay on for every system holding patient or QC data, and a monthly spot check of ten records verifies that changes carry a user, a timestamp, and a reason. Where records support regulated decisions, the system must capture who changed what and when in line with U.S. Food and Drug Administration expectations under 21 CFR Part 11, and platforms that unify LIMS and quality management system functions under a risk-based computer software assurance framework aligned with 21 CFR Part 11 and ISO/IEC 17025 now exist for exactly this purpose, with a pilot deployment across 187 laboratory requests logging 1,456 quality-control checkpoints and 43 deviation-handling episodes [8]. ### 7. Sharing, Reporting, and Release State what leaves the laboratory, to whom, through which channel, and what record you keep. Patient reports move through the LIS interface only, never as email attachments. Public health notifications follow the notifiable conditions list for your jurisdiction. EQA submissions go through the provider's portal before the deadline, and the submission receipt is filed with the EQA record the same day. Research or external extracts are de-identified, approved by the laboratory director, and logged with a purpose and a date. If you intend to publish or share datasets, adopt the FAIR principles as the design target and say so in this section. ### 8. Roles, Review Cycle, and Version History | Role | Responsibility in the plan | |--|--| | Laboratory Director | Approves the plan and any change to retention or release rules | | Quality Manager | Owns the document, schedules reviews, files the version history | | Data Steward | Runs exports, checksums, restore tests, and the indicator dashboard | | Bench Technologists | Follow entry rules and perform same-day QC review | Review the plan at least annually, and off-cycle after any LIS upgrade, new instrument, breakpoint revision that affects stored interpretations, or change in accreditation requirements. The version block at the top of the document carries the version number, effective date, approver, and a one-line change summary for each revision. ## Worked Example: A Filled-In DMP Excerpt The excerpt below shows the density to aim for. Every line names an artifact that either exists or is visibly missing. ```markdown # Data Management Plan, Riverside Microbiology Laboratory Version 2.1, effective 2026-02-01, approved by J. Ortiz, MD (Laboratory Director) ## 1. Data types | Data type | Source | Format | Owner | |---|---|---|---| | AST results (MIC and zone diameters) | AST-01 analyzer via middleware | HL7 to LIS, nightly CSV export | M. Chen, Data Steward | | Organism identifications | AST-01 and MALDI-MS | HL7 to LIS | M. Chen | | Quantitative QC | LIS QC module | Monthly CSV export | M. Chen | | EQA records and receipts | Proficiency provider portal | PDF receipts filed same day | S. Adeyemi, Quality Manager | | Instrument raw files | AST-01 workstation | Vendor proprietary, version recorded | M. Chen | ## 4. Quality control - Reference strains: E. coli ATCC 25922, S. aureus ATCC 25923, P. aeruginosa ATCC 27853 - Frequency: each new disk lot, each new calibration, and each patient-testing day - Chart: Levey-Jennings, mean and SD from the first 20 in-control points per lot - Rejection rules: 1-3s, 2-2s, R-4s, 4-1s, 10x - Review: same day, by the senior technologist on bench, before release - Export: monthly to \\labfs\qc\YYYY-MM\ with a SHA-256 checksum filed alongside ## 5. Storage and retention - Primary: LIS database on LAB-SQL-01 - Backup: nightly incremental to LAB-NAS-01, weekly full offsite to vendor vault - Restore test: first Wednesday of each quarter, logged in Appendix C - Retention: per current accreditation schedule, exact intervals in Appendix B ``` Here MALDI-MS means matrix-assisted laser desorption ionization mass spectrometry, the identification platform in this example. Note the properties that make the excerpt usable. The version block carries an approver. The QC section names strains, rules, timing, and the export path. Nothing says "as required" without saying where the requirement is listed. ## Step-by-Step: Build the Plan and Prove It Works ### Step 1. Inventory the data you already have On Windows, run this in PowerShell against the folder or share where instrument and LIS exports land. ```powershell Get-ChildItem C:\LabData\Raw -Recurse -File | Select-Object FullName, Length, LastWriteTime | Export-Csv C:\LabData\inventory.csv -NoTypeInformation Import-Csv C:\LabData\inventory.csv | Group-Object Extension | Select-Object Name, Count ``` Example output: ``` Name Count ---- ----- .csv 388 .pdf 61 .txt 12 ``` On macOS or Linux the equivalent is: ```bash find /labdata/raw -type f -printf "%TY-%Tm-%Td\t%s\t%p\n" | sort ``` Example output (tab-separated): ``` 2026-01-14 52130 /labdata/raw/ast/ast_export_2026-01-14.csv 2026-01-15 49877 /labdata/raw/ast/ast_export_2026-01-15.csv ``` To check the result is right, confirm three things. The file count is plausible for your testing volume. No unexpected file types appeared, because a surprise .exe or .zip in an export folder is an incident, not an inventory line. Everything the file system cannot see, such as paper registers, instrument-internal storage, and the LIS database itself, gets a manual line in Section 1 of the plan. Schedule the inventory monthly and save it to a known path, because a running series of inventories also documents growth in data volume for capacity planning. ### Step 2. Structure the QC export and verify the statistics ![Worked calculation converting the latest QC zone diameter of 27.0 mm into a z-score of +2.52 using a mean of 24.03 mm and SD of 1.18 mm.](/article-images/illustrations/data-management-plan-microbiology-laboratory-qc-z-score.webp) Agree the column structure first, because the same structure must hold for every monthly export. A minimal quantitative QC table looks like this. ```csv date,assay_id,instrument_id,control_strain,antibiotic,result_mm,analyst 2026-01-05,AST-DISK,AST-01,ATCC 25922,ciprofloxacin,23.5,JT 2026-01-06,AST-DISK,AST-01,ATCC 25922,ciprofloxacin,24.0,JT 2026-01-07,AST-DISK,AST-01,ATCC 25922,ciprofloxacin,24.5,RB 2026-02-03,AST-DISK,AST-01,ATCC 25922,ciprofloxacin,27.0,JT ``` In practice the file holds one row per strain and antibiotic per day. The Python below reads the export, computes the mean and SD, converts the latest result into a z-score, which is the number of standard deviations the newest point sits from the mean, and applies the two primary Westgard rules. ```python import csv import statistics with open("qc_export.csv", newline="") as f: rows = list(csv.DictReader(f)) values = [float(r["result_mm"]) for r in rows] mean = statistics.mean(values) sd = statistics.stdev(values) latest = values[-1] z = (latest - mean) / sd print(f"n={len(values)} mean={mean:.2f} mm SD={sd:.2f} mm") print(f"latest={latest:.1f} mm z={z:+.2f}") if abs(z) >= 3: print("1-3s REJECT: quarantine results since last acceptable QC") elif abs(z) >= 2: print("1-2s WARNING: apply 2-2s, R-4s, 4-1s, and 10x before accepting") else: print("IN CONTROL") ``` Example output: ``` n=30 mean=24.03 mm SD=1.18 mm latest=27.0 mm z=+2.52 1-2s WARNING: apply 2-2s, R-4s, 4-1s, and 10x before accepting ``` Each parameter matters. n is the number of in-control points feeding the estimates, and the conventional minimum for establishing the mean and SD is 20 points from a stable period. The mean is the center line of the chart. The SD sets the 2s and 3s limits. The z-score expresses today's result in SD units and drives the 1-2s and 1-3s decisions. The [coefficient of variation](/blog/research-skills/how-to-calculate-coefficient-of-variation) puts the SD in context as CV% = (SD / mean) × 100, here (1.18 / 24.03) × 100 = 4.9%, a figure you can compare month over month to detect widening dispersion before any rule breaks. To check the calculation is right, pick one stored value, subtract the mean, divide by the SD by hand, and confirm the z-score matches to two decimals. In the daily workflow, the senior technologist runs the check after QC results post and before the first patient report of the day goes out. If the script prints a reject, the expected next action on the bench is a quarantine, not a debate. ### Step 3. Fix integrity with checksums A checksum is a fixed-length digital fingerprint of a file. SHA-256 produces a 256-bit digest, and any change to the file, even one character, changes the digest. Create the digest when you export and verify it whenever the file moves. ```bash sha256sum /labdata/qc/2026-01/qc_export.csv > /labdata/integrity/qc_export_2026-01.sha256 sha256sum -c /labdata/integrity/qc_export_2026-01.sha256 ``` Expected output on a match: ``` /labdata/qc/2026-01/qc_export.csv: OK ``` Expected output on a mismatch: ``` /labdata/qc/2026-01/qc_export.csv: FAILED sha256sum: WARNING: 1 computed checksum did NOT match ``` A FAILED line means the file changed after the digest was created. On Windows the equivalent is the Get-FileHash command in PowerShell. File the digest beside the export and record the practice in Section 5 of the plan. ### Step 4. Write the backup rule and test a restore Write the rule in one sentence per copy, then prove it. A workable rule for a small laboratory: nightly incremental backup of the LIS database and export shares to a network appliance, weekly full backup to an encrypted offsite location, and a restore test on the first Wednesday of each quarter. The restore test has four steps. 1. Select one recent week at random and restore that week's backup into a sandbox system, never over the live database. 2. Open ten records at random from the restored copy. 3. Compare accession, result, and last-modified fields against the live system. 4. Log the test, the records checked, and the outcome in the plan's appendix. The check that matters is negative evidence. If a restored record is missing a field that exists in the live system, the backup is incomplete, and that finding goes into the corrective action log, not into a footnote. ### Step 5. Dry-run one external submission Before the next real EQA cycle, rehearse the submission path. Download the current round's instructions, prepare the result entry, and confirm you can produce, on demand, the submission identifier, the timestamp, and the receipt. In a Cambodian external quality assessment pilot for SARS-CoV-2 rapid diagnostic tests, participating laboratories submitted all results through a dedicated portal using QR code scanning, and the tier 1 reference laboratory reported 100 percent concordance with reference results while some facility-based laboratories did not, which is precisely the discrepancy EQA exists to expose [9]. Your plan should demand the same evidence trail for every submission. A submission without a filed receipt is not a submission. ### Step 6. Sign it, date it, schedule the next review Print the plan, obtain the laboratory director's signature, set the effective date, and place the next review date in the quality calendar. The signature is not ceremony. It converts the document from advice into a controlled record under your laboratory quality management system, which is what an assessor asks to see. ## Common Errors and Exact Fixes 1. `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte`. The export is UTF-16 or carries an unexpected byte order mark, which is common with instrument workstations. Read with the matching encoding, for example encoding="utf-16" in Python, or re-export as UTF-8, then record the encoding in Section 2 of the plan so the next person does not rediscover it. 2. `PermissionError: [Errno 13] Permission denied: 'qc_export.csv'`. The file is open in a spreadsheet application or your account lacks read rights on the share. Close the file or request read access, and never work directly on the only copy of an export. 3. `pandas.errors.ParserError: Error tokenizing data. C error: Expected 1 field in line 12, saw 7`. The delimiter is not the comma you assumed, often a semicolon-delimited export from a system set to a European locale. Read with the matching separator or re-save as a standard comma-separated file, and state the delimiter in the plan. 4. A spreadsheet converts identifiers into dates or strips leading zeros. A text token that resembles a date, such as the gene symbol SEPT1 becoming 1-Sep, is altered the moment the file is opened and saved. Import identifier columns as text, or move files with tools that do not reinterpret values, and flag every column that contains codes. 5. `FAILED` from a checksum verification after a server migration. The file was re-saved, truncated, or transferred in a mode that altered it. Re-transfer in binary mode, re-create the digest, and investigate what changed before trusting the file. 6. Two results for one specimen after an interface retry. The plan should name the LIS interface log as the arbiter, require that duplicates be resolved by addendum rather than overwrite, and count these events monthly as an indicator. ## How to Check the Plan Is Working Reduce the plan to five indicators, review them monthly, and record the numbers. Sensible choices are the percentage of QC runs with documented same-day review, the percentage of EQA challenges submitted before deadline with a filed receipt, the count of days since the last successful restore test, the percentage of exported files with a matching checksum, and the count of data errors by category. Set your own threshold for each and write it into the plan. The prioritization method matters as much as the indicators. A quality improvement program in Qatari primary care used a Delphi panel to agree on 17 key performance indicators, audited 450 real records against them, and then ranked interventions by clinical impact at 50 percent, feasibility at 30 percent, and urgency at 20 percent of the decision weight [10]. Borrow the structure at laboratory scale. Agree on the indicators in advance, audit against real records rather than memory, and fix the highest-impact failure first. Categorize every data error when you log it, because categories tell you where the fix belongs. A frozen section quality assurance program built custom software to monitor recognition, increase documentation, and drive communication of diagnostic discrepancies, and it categorized each discrepancy by source, such as interpretive versus technical, to understand how errors arise [11]. The microbiology equivalent tags each error as entry, interface, instrument, or interpretation, and the monthly counts point at the weak link. Traceability is the property that ties all of this together. Assisted reproduction laboratories, which operate under some of the strictest traceability demands in medicine, run documentation and traceability on electronic platforms with witnessing systems and track key performance indicators such as [fertilization](/blog/guides/fertilization), blastocyst formation, and cryosurvival rates as quality benchmarks [12]. The transferable pattern is simple. Every specimen movement and every data change should be attributable to a person and a time, and a small set of indicators should trend where the whole laboratory sees them. ## Common Mistakes and Limitations - Writing the plan around the software instead of around the data. Software changes at the vendor's pace, and the plan should survive an LIS replacement with section edits rather than a rewrite. - Naming conventions that depend on memory. If the rule lives in someone's head, it does not exist. Put the convention in the plan and enforce it in the export script. - Keeping the backup on the same hardware as the primary data. A single ransomware event or power event then removes both copies at once. - Treating QC review as a monthly batch. A rule violation discovered three weeks late has already released suspect results. - Letting the plan drift after an upgrade. A plan describing software that no longer exists is worse than no plan, because it teaches staff and auditors that the document is decorative. - Collecting fields nobody uses. Every required field should map to a decision, a report, or a requirement. Delete the rest. - Storing raw instrument files without the software version that reads them. The files become unreadable archives precisely when you need them. One limitation belongs in the open. This guide supplies the structure, the commands, and the worked calculations. The intervals, retention schedules, software choices, and release rules must be set by your laboratory director and quality manager against your accreditation body's requirements and your instruments, and individual patient results always require interpretation by qualified laboratory staff. ## Frequently Asked Questions ### What is a data management plan in a microbiology laboratory? It is a written, controlled document that states what data the laboratory produces, where each type is stored, who may change it, how quality is verified, how long it is retained, and how it is shared or released. ### What should a data management plan template include? Eight sections: data types and sources, metadata and naming conventions, entry controls, quality control data handling, storage with backup and retention, access and audit trails, sharing and reporting, and roles with a review cycle. ### How do I handle microbiology quality control data in the plan? Name the control materials and reference strains, the testing frequency, the chart type, the statistical acceptance and rejection rules, the same-day review requirement, and the export location with checksums. ### What is the difference between internal quality control and external quality assessment? Internal quality control uses known materials run alongside patient testing to check day-to-day performance, while external quality assessment compares your blinded results against a provider's reference results to check accuracy relative to other laboratories. ### Do we need a LIMS to follow the plan? No. The plan works with disciplined folders and spreadsheets, but a laboratory information system makes audit trails, access control, and retention far easier to sustain as volume grows. ### How does a data management plan support ISO 15189 accreditation? ISO 15189 requires control of records and documented quality management, and the plan gives an assessor one document that shows that control end to end. ### How often should the plan be reviewed? At least annually, plus after any LIS upgrade, new instrument, breakpoint revision affecting stored interpretations, or change in accreditation requirements. ### Who is responsible for the data management plan? The quality manager owns and updates it, the laboratory director approves it, a named data steward runs the exports and checks, and bench staff follow the entry and QC rules. ## Sources 1. [Recommendations for HLA Genotyping Data Standards and Clinical Laboratory Staffing Considerations.](https://pubmed.ncbi.nlm.nih.gov/42007733/) 2. [Determinants of quality laboratory service provision amongst government comprehensive specialized hospitals in Northwest Ethiopia.](https://pubmed.ncbi.nlm.nih.gov/41923262/) 3. [Challenges in Structuring SARS-CoV-2 Emergency Use Authorization Diagnostics Data: Leveraging Findable, Accessible, Interoperable, and Reusable Principles for the Next Era of Diagnostic Data Transparency.](https://pubmed.ncbi.nlm.nih.gov/41386638/) 4. [Air Quality Sensor Experts Convene: Current Quality Assurance Considerations for Credible Data.](https://pubmed.ncbi.nlm.nih.gov/39502563/) 5. [Integrated laboratory protocol for the diagnosis of Sexually Transmitted Infections (STIs): Standardized pre-analytical procedures, rapid screening, hemagglutination, and ELISA methods for use in resource-limited settings.](https://pubmed.ncbi.nlm.nih.gov/42085387/) 6. [Semi-automated end-to-end quality control system for annotation data based on automated Cobb angle measurement.](https://pubmed.ncbi.nlm.nih.gov/41491131/) 7. [Development and Implementation of an Internal Quality Control and External Quality Assessment Information System for a Regional Medical Laboratory Center: Pilot Design and Implementation Study.](https://pubmed.ncbi.nlm.nih.gov/41364922/) 8. [A cloud-enabled LIMS-QMS platform with large language model-assisted standard operating procedure generation for GLP/GMP-aligned theranostics laboratory operations.](https://pubmed.ncbi.nlm.nih.gov/42901382/) 9. [Piloting an external quality assurance program (QAP) for COVID-19 antigen rapid diagnostic tests (Ag-RDTs): findings and lessons learned from Cambodia.](https://pubmed.ncbi.nlm.nih.gov/39762057/) 10. [From Consensus Through Prioritization: A Delphi Method, Clinical Audit, and Analytic Hierarchy Process Framework for Quality Improvement in Primary Diabetes Care.](https://pubmed.ncbi.nlm.nih.gov/42313519/) 11. [Software solution for integration of frozen section quality assurance into daily practice.](https://pubmed.ncbi.nlm.nih.gov/39838842/) 12. [Quality Control in Assisted Reproduction Centers.](https://pubmed.ncbi.nlm.nih.gov/42441885/)