Chapter 1
Biosafety at an institution is kept safe by people, facilities and procedures, but it is proven by records. This chapter explains why those records need a common data structure, and where WIA-BIO-017 fits among the laws, committees and manuals that already govern the work.
Ask a biosafety officer what takes up most of their week and the answer is rarely the laboratory itself. It is the paperwork around the laboratory: confirming that a new researcher finished training before receiving a door badge, chasing a principal investigator whose committee approval expires next month, reconstructing who was in a room on the day a near miss was reported, and assembling a binder for an inspection that is scheduled for Thursday. Each of these tasks is a question about records. Is the record present, is it current, does it agree with the other records, and can it be shown to someone who has the right to see it?
This book is about those records. It treats WIA-BIO-017 as a management and data standard: a shared vocabulary for facility registration, certification, training, access, incidents, custody and audits, together with an interface for checking those records against each other. It does not teach laboratory technique, and it deliberately leaves technical safety requirements to the national authorities and international manuals that own them. This first chapter sets out the reasons for that choice and builds the map that the rest of the book follows.
The three terms are often used interchangeably in conversation, but they answer different questions, and a record system that blurs them ends up storing the wrong things in the wrong places.
Biosafety asks how people and the environment are protected from unintentional exposure to, or release of, biological material. The WHO Laboratory Biosafety Manual (LBM) uses the term for the containment principles, technologies and practices that serve this purpose. In record terms, biosafety produces facility registrations, certification decisions, training and competency records, approved work authorizations, and incident reports.
Biosecurity, in the laboratory sense, asks how biological material, equipment and information are protected from loss, theft, misuse or intentional release. It produces a different set of records: who holds keys and credentials, who is authorized to access an inventory, where material was transferred and who confirmed receipt, and who may see sensitive facility details. Biosecurity also changes how the biosafety records themselves must be handled, because a complete list of rooms, holdings and access arrangements is itself sensitive information. Chapter 6 returns to this point.
Biorisk management is the umbrella. It is the organizational system that identifies, assesses, controls and monitors both kinds of risk, and it is the level at which institutions are audited. ISO 35001:2019, Biorisk management for laboratories and other related organisations, frames biorisk management as a management system with policy, planning, operation, performance evaluation and improvement. It replaced the earlier CEN Workshop Agreement CWA 15793, which the WIA-BIO-017 v1.0 specification still cites in §8.1.2 and §11.1. This book cites ISO 35001 as the current reference and lists the outdated citation among the v1.1 corrections in Chapter 8.
The fourth edition of the WHO Laboratory Biosafety Manual (LBM4, 2020) emphasizes a risk-based and evidence-based approach: rather than prescribing a fixed set of controls for each numbered level, it asks the institution to assess the risks of its own work and to choose and document proportionate control measures. Its framework is expressed as core requirements, heightened control measures and maximum containment measures. ISO 35001 takes the same direction from the management-system side, asking an organization to show that it has a policy, a process and evidence that the process works.
Both directions increase the weight of documentation. When the rule was "a level-N room needs items X, Y and Z", an inspector could walk through the room. When the rule is "you must show that you assessed the risk, chose controls, trained people, reviewed incidents and improved", the inspector reads records. The quality of the institution's biosafety program becomes visible mainly through the completeness, consistency and traceability of those records.
There are three reasons for the management-and-data framing.
In a mid-sized university or hospital research campus, the records that together describe the biosafety program are rarely held in one system. A common pattern looks like this:
Each system may be well run on its own. The difficulty is that a single compliance question almost always crosses several of them, and the systems do not share identifiers, time conventions or vocabularies.
The following walkthrough is an illustrative composite, not a description of any specific inspection regime. It shows the kind of questions a reviewer, whether an internal auditor, an IBC member or an external inspector, typically asks, and how many systems each question touches.
| Time (example) | Inspector's request | Records needed | Systems touched today |
|---|---|---|---|
| 09:00 | "Show me the registration and current certification status of the facilities in scope." | Facility registration, certification decision, expiry and next inspection date | Shared drive, spreadsheet |
| 09:40 | "Which projects are approved to run in Room B-214, and at what level?" | IBC approvals linked to facility and level | IBC document system, spreadsheet |
| 10:30 | "Pick three people on the access list. Show that their training was current on the dates they entered." | Access log, training record, competency assessment | Door controller, LMS, HR directory |
| 11:30 | "List incidents and near misses for the last reporting period, with status and corrective actions." | Incident reports, root-cause records, CAPA status | Email, EHS module, paper logbook |
| 13:30 | "Trace this material transfer from the sending facility to receipt." | Transfer record, approval reference, receipt confirmation | LIMS notes, courier paperwork |
| 14:30 | "Who changed this approval record, and when?" | Audit trail with actor, time and prior value | Often unavailable |
| 15:30 | "Show that last year's findings were closed." | Prior audit findings, linked actions and evidence of closure | Previous binder, email threads |
No single request is difficult. The cost comes from the joins. To answer the 10:30 request, someone has to match badge numbers from the door controller to employee numbers in the LMS, then compare entry timestamps (often in local time without an offset) with training expiry dates (often dates without a time). If one of the three people changed departments, a third identifier may be involved. The 14:30 request exposes a deeper gap: many spreadsheets and shared drives simply do not keep a trustworthy history of who changed what.
The failures that audits reveal are usually not missing effort. They are structural:
Each of these is a data-design problem with a data-design answer: stable identifiers, explicit validity periods, structured enumerations, append-only history and field-level export rules. Those answers are what WIA-BIO-017 is used for in this book.
A biosafety record system does not invent obligations; it reflects obligations that come from law, institutional governance and recognized guidance. The references below are named here so that later chapters can say which record each field supports. The table deliberately describes what kind of record each reference drives, not what the reference requires technically.
| Governance reference | Role | Records it typically drives |
|---|---|---|
| Korea: Act on the Transboundary Movement, etc. of Living Modified Organisms (LMO Act) and its subordinate rules | National legal framework for LMO research, including the research-facility permit and reporting regime | Facility registration and permit/report references, IBC approvals for LMO work, custody and transfer records, notification records |
| Institutional biosafety committee (IBC) and biosafety officer | Institution-level review, approval and oversight | Approval records with scope and validity, committee review history, officer sign-offs, incident review decisions |
| WHO Laboratory Biosafety Manual, 4th ed. (LBM4) | International guidance built on a risk-based approach | Risk-assessment records and their review dates, training and competency records, incident and near-miss learning |
| ISO 35001:2019 | Management-system standard for biorisk management | Policy, objectives, roles, internal audit results, nonconformities and corrective actions, management review records |
| US BMBL, 6th ed., and NIH Guidelines | US guidance; the NIH Guidelines are the origin of the IBC concept for recombinant or synthetic nucleic acid research | Approval and registration records, committee minutes, training records |
| EU Directives 2000/54/EC and 2009/41/EC | Worker protection from biological agents; contained use of genetically modified microorganisms | Risk-assessment documentation, notification and authorization records, worker lists and training records |
| Cartagena Protocol on Biosafety (Convention on Biological Diversity) | International agreement on transboundary movement of LMOs | Transfer and custody records crossing borders, references to national competent-authority decisions |
In Korea, research that involves living modified organisms is governed by the LMO Act (유전자변형생물체의 국가간 이동 등에 관한 법률) and its subordinate rules, which include a permit and reporting regime for research facilities. Within an institution, the framework relies on two roles that this book models directly: the institutional biosafety committee (IBC, 기관생물안전위원회), which reviews and approves work, and the biosafety officer (생물안전관리책임자), who manages the program day to day. Other laws apply to other categories of material and work, and different ministries and agencies are responsible for them.
The source material for WIA-BIO-017 contains no Korean regulatory thresholds, report deadlines or facility-category rules, and this book does not supply them. Such details change, and they must come from the competent authorities: the Korea Disease Control and Prevention Agency (KDCA), the Ministry of Science and ICT for research LMOs, and the national biosafety information center. The data model is built so that each regulatory reference is a field holding an identifier and a link, which means the institution can record the authority's current decision without the software encoding the rule.
The WHO LBM4 is the most widely used international reference and is written to support national regulation rather than replace it. The US Biosafety in Microbiological and Biomedical Laboratories (BMBL), 6th edition, published by the CDC and NIH, serves a similar role in the United States. The NIH Guidelines for Research Involving Recombinant or Synthetic Nucleic Acid Molecules established the institutional biosafety committee model that many countries, including Korea, now use in some form. In the European Union, Directive 2000/54/EC addresses the protection of workers from biological agents and Directive 2009/41/EC addresses the contained use of genetically modified microorganisms; each is implemented through national law in member states. The Cartagena Protocol on Biosafety under the Convention on Biological Diversity governs the transboundary movement of LMOs, and Korea's LMO Act is the national legislation that implements it.
For record design, the important observation is that these references overlap in the kinds of evidence they expect, even where their technical content and legal force differ. Nearly all of them expect an institution to show who approved what work, where, at what containment level, by whom it is performed, whether those people were trained, what went wrong and what was done about it. That overlap is the foundation of a shared data model.
Every chapter follows one editorial rule. When a governance reference contains a technical requirement, the book names the reference and tells the reader where the requirement lives. It does not restate the requirement. In the data model, the same rule becomes a design principle: a record stores a reference to a requirement (document, edition, clause or decision ID) and the institution's status against it, but never a copy of the requirement's technical content. That keeps the record system correct when the reference is revised, and keeps the software from being mistaken for an authority.
Two four-tier schemes appear throughout biosafety records. Biosafety levels (BSL-1 to BSL-4) describe the containment level of a facility or the level at which work is approved. Risk groups (Risk Group 1 to 4) are a classification applied to biological agents by national and international authorities. The two are related but not interchangeable, and LBM4 in particular cautions against assuming that a risk group automatically determines a containment level without a risk assessment.
In this book both schemes appear only as enumerated labels carried by records. The WIA-BIO-017 SDK defines them as follows (spelling preserved from the source, including the "Biosafty" typo discussed in Chapter 2):
// api/typescript/src/types.ts (excerpt)
export type BiosaftyLevel = 'BSL-1' | 'BSL-2' | 'BSL-3' | 'BSL-4';
export type RiskGroup = 1 | 2 | 3 | 4;
A facility record carries a bslLevel. An approval record carries the level at which the work was approved. A material registry entry carries the classification label assigned by the relevant authority. The software can then answer questions such as "is any approved project recorded at a level above the registered level of the room it is assigned to?" without knowing anything about what a given level requires physically.
What the book leaves out is equally deliberate. It does not describe the practices, equipment or facility engineering associated with each level. It does not list which agents belong to which risk group. Those determinations belong to authorities and qualified professionals, and they are published in the references named in section 1.3. The WIA-BIO-017 v1.0 specification does include such content in its sections 2 to 5. This book does not reproduce it, and Chapter 2 shows how to design records that do not depend on it.
Design principle. A level or risk-group value in a record is a label assigned by a person or body with authority to assign it. The record should also store who assigned it, on what basis (a document or decision reference), and when. The software checks consistency between labels. It does not derive the labels.
Section 9.1 of the WIA-BIO-017 v1.0 specification lists five components that any compliant system must include: a risk calculator, a BSL validator, a PPE recommender, an exposure assessor and an incident tracker. Read literally, three of those five components would make the software produce technical safety judgments. This book reframes the list as a set of record services so that the software supports the people and bodies who make those judgments without replacing them.
| Spec §9.1 component | Record service in this book | What the service does | Chapter |
|---|---|---|---|
| Risk Calculator | Risk-assessment record | Stores metadata about the institution's risk assessment: assessor, date, IBC approval ID, resulting level and review date. Any scoring is an opaque institutional hook, not a validated method. | 2, 4 |
| BSL Validator | Level-authorization validator | Checks that the level recorded on an approved project matches the registered and certified level of the assigned facility, and that certification is current. | 4 |
| PPE Recommender | Protective-equipment policy lookup | Returns a reference to the institution's approved policy or SOP version for a given approval. It does not generate equipment requirements. | 4, 6 |
| Exposure Assessor | Excluded | Exposure assessment belongs to qualified professionals and occupational-health services. The book names the SDK function and explains how to disable it. | 4 |
| Incident Tracker | Incident tracker | Structured incident and near-miss records, a status workflow, root-cause and CAPA records, and notification hand-off. | 3 |
| (not listed) | Compliance reporting | Produces compliance results, audit trails and evidence packages from the records above. | 4, 5, 7 |
The reframing is not a rejection of the specification. The data types behind each component, including facility, training, incident and compliance-result structures, are reused throughout the book. What changes is the boundary: every service reads and checks records that humans have authored and approved, and none of them issues a technical safety instruction.
To avoid misunderstanding by buyers, auditors or users of a WIA-BIO-017 based system, it helps to state the limits plainly:
certification block in a facility record stores that decision. It does not replace it (Chapter 7).https://api.wia-bio.org/bio-safety/v1 and the npm package name @wia/bio-017 are used in this book as the names given in the source repository. Readers should confirm availability before depending on them.The diagram below shows the record landscape that WIA-BIO-017 models, reduced to its entities and the identifiers that link them. Chapter 2 defines each entity field by field. For now, notice that nearly every link runs through three anchors: a facility, a person and an approval.
+-----------------------------+
| Governance references |
| (law, IBC, LBM4, ISO 35001) |
+--------------+--------------+
| cited by ID, never copied
v
+------------+ assigned +-----------------+ approved in +-------------+
| Person |------------->| Authorization |<----------------| Facility |
| (pseudo- | | (IBC approval, | | FAC-... |
| nymous ID)| | level label) | | bslLevel, |
+-----+------+ +--------+--------+ | cert. block |
| | +------+------+
| holds | documented by |
v v | logs
+------------+ +-----------------+ v
| Training | | Risk-assessment | +-------------+
| record | | record | | Access log |
| TRN-... | | (metadata only) | | entries |
+-----+------+ +-----------------+ +------+------+
| |
+--------------------------+-------------------------------------+
v
+-----------------------------+
| Incident / near-miss |
| INC-... -> CAPA records |
+--------------+--------------+
v
+-----------------------------+
| AuditEvent (append-only) |
| ComplianceResult, evidence |
+-----------------------------+Alongside the main specification, the WIA-BIO-017 repository contains four PHASE documents. Each has a short core followed by annexes on implementation notes, adoption, test vectors, versioning, interoperability profiles and reference topologies. The table summarizes how this book uses them.
| Document | Topic | Used in this book for | Chapters |
|---|---|---|---|
| PHASE-1 Data Format | Formats, schema validation, implementation notes | Timestamp and identifier conventions, schema evolution rules, retention and clock notes | 2, 5 |
| PHASE-2 API Interface | REST interface, authentication, rate limits | Resource design and error handling over the record model | 4 |
| PHASE-3 Protocol | Exchange protocol and quality topics | Message envelopes, interoperability profiles and federation topologies | 5 |
| PHASE-4 Integration | Security, privacy and integration | Encryption, RBAC and MFA, connection to LIMS, EHS and HR systems | 6 |
| Annexes E to J (all phases) | Implementation notes, roadmap, test vectors, versioning, profiles, reference topologies | Conformance tiers, evidence packages and deprecation policy | 7, 8 |
The PHASE documents are v1.0 drafts with visible template material: their short cores are nearly identical across all four files (the PHASE-3 core is even titled "Quality Metrics Specification"), so the topic column above reflects the file names and how this book uses each document rather than distinct normative content. Several of their quality-control metrics were written for a clinical-assay context and have no meaning for biosafety records, and some annexes refer to annexes that do not exist. This book uses the parts that apply to records, flags inconsistencies where they matter, and collects them in Chapter 8 as issues for version 1.1.
The repository also provides three tools. The TypeScript SDK (package name @wia/bio-017) exposes a BioSafetySDK class and the data types that later chapters use: facility, training, incident and compliance-result structures, plus a ValidationResult pattern. Chapter 4 uses it for record-consistency checks and states which of its functions are out of scope. The command-line tool wia-bio-017 wraps some of the same checks for batch use, and Chapter 4 shows how to run the record-level subcommands in continuous integration. The simulator is a browser page for exploring the concepts interactively. Where it helps to illustrate record screens, later chapters refer to it. Where its panels compute technical safety values, the book does not use them.
A short example shows the intended usage. A developer checks whether an approved project's level matches its assigned facility. The call returns a compliance result, and the developer stores it with the records it was computed from:
import { BioSafetySDK } from '@wia/bio-017';
const sdk = new BioSafetySDK();
console.log(sdk.getVersion()); // version string of the installed SDK
// Chapter 4 builds the full record-consistency check around
// validateBSLLevel() and stores the ComplianceResult alongside
// the facility and approval IDs it was computed from.Each later chapter takes one part of the landscape and does not repeat the others:
| Chapter | Focus | Key question it answers |
|---|---|---|
| 2 | Core data model | How are facilities, people, training and approvals represented and linked? |
| 3 | Incident and near-miss workflow | How is an event recorded, investigated, corrected and closed? |
| 4 | API and SDK | How do applications read, write and check these records? |
| 5 | Exchange and audit trails | How are records shared between institutions and proven unaltered? |
| 6 | Security, privacy and integration | Who may see which fields, and how do existing systems feed the model? |
| 7 | Conformance | How does an implementation demonstrate that it follows the standard? |
| 8 | Adoption and future | How does an institution roll this out, and what should v1.1 fix? |
Biosafety, biosecurity and biorisk management each generate records, and modern guidance such as LBM4 and ISO 35001 makes those records the main evidence of a working program. At a typical institution the records are spread across systems that do not share identifiers or history, so every audit becomes a manual join. The governance landscape, from Korea's LMO Act and the IBC system to the WHO manual, ISO 35001, US and EU references and the Cartagena Protocol, differs in technical content but largely agrees on the kinds of evidence it expects. WIA-BIO-017 is used in this book as a shared model for that evidence. Containment levels and risk groups are treated as labels assigned by authorities, the five components of spec §9.1 are recast as record services, and technical safety content is left to the bodies that own it.
Technical safety content: consult official biosafety authorities. This chapter covers management and records only. For containment requirements, risk-group classification, protective equipment, decontamination and all other technical biosafety matters, consult your national competent authority (in Korea, the KDCA, the Ministry of Science and ICT and the national biosafety information center), your institutional biosafety committee and biosafety officer, and current editions of the WHO Laboratory Biosafety Manual and the BMBL.