This page details the Labbit Release Management policy, which may be updated from time to time.
This is Semaphore’s customer-facing release management policy for Labbit.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
This document refers to and uses definitions derived from the FDA’s General Principles of Software Validation. Its purpose is to communicate to Labbit customers how the software is managed and specified in order that customers may incorporate Labbit into regulated environments. Labbit itself is not a medical device.
This is version 1.1.0 of the Release and Installation Policy, and is current as of Mar 31, 2023.
Errata
1.1.0 - Mar 31, 2023
- A typo was corrected in the “Customer Systems Version” section (“single version string in is required”).
- The section “Required Consultation” was added.
Structure of Labbit
For release management purposes, Labbit consists of three architectural tiers:
- 1. Configuration, outside of the scope of this document;
- 2. Platform, which consists of all elements of Labbit software written by Semaphore aside from configuration; and
- 3. Systems, which consist of all other elements of Labbit, including but not limited to Internet connectivity, operating systems, databases, and physical or virtual computers.
Description of a Customer Installation
Customer installations of Labbit consist of one instance of each of the two architectural tiers, each of which is described by a specification. Semaphore may add to these two specifications a separate Customer Systems Specification if necessary.
Each specification has a version, in the format defined by the Semantic Versioning specification 2.0.0.
All behaviour of a customer’s Labbit installation is defined by the particular versions of their installation specifications.
Revisions to Specifications
From time to time, Semaphore will provide customers with new revisions of Labbit specifications. Specifications shall be clearly labelled with their version in the format X.Y.Z where X Y and Z are integers.
Expanding on the definitions in the Semantic Versioning specification 2.0.0, Semaphore shall:
- - indicate to customers that a previously defined requirement will no longer be met by incrementing the MAJOR version number (X.0.0 where X is the next unused positive integer).
- - indicate to customers that a new requirement has been added and is met, by incrementing the MINOR version number (X.Y.0 where Y is the next unused positive integer)
- - indicate to customers that no additions or deletions have been made to requirements, by incrementing only the PATCH version number (X.Y.Z where Z is the next unused positive integer).
Changes to Customer Installations
Elements of a customer’s Labbit installation shall be versioned to match the version numbers of the specifications.
Changes to elements may be categorized as major, minor, or patch-level changes, depending on the amount of change to previously established specifications. The types of changes are defined below, with examples.
Customers must make their own determination as to when to perform a revalidation of processes that are affected by Labbit changes, however of the types of changes described below, Semaphore intends that only a Major Platform Change should result in a forced revalidation.
Systems
An example of an external systems requirement:
“The system shall reject HTTPS connections unless they use the TLS 1.2 or 1.3 protocol and one of the following ciphers: TLS-AES-128-GCM-SHA256, TLS-AES-256-GCM-SHA384, TLS-CHACHA20-POLY1305-SHA256.”
Systems Patch
Systems patches may be applied to customer installations, from time to time, to address security vulnerabilities, defects, or for any other reason.
Systems specifications shall not change as a result of a systems patch.
Semaphore may notify customers after systems patches are applied if customer relevant, for example when remediating well-known systems vulnerabilities.
Systems Minor Revision
In a systems minor revision, Semaphore may add new systems capabilities without disrupting current capabilities. These changes are termed “minor systems changes”. Systems minor revisions shall be applied to customer installations at the discretion of Semaphore.
Semaphore shall notify customers of new specifications within 30 days after a system minor revision is applied.
An example of a minor systems change would be the addition of a newly supported cipher to HTTPS connections.
Systems Major Revision
In a systems major revision, Semaphore may modify or terminate previously established systems capabilities. These changes are termed “major systems changes”. Systems major revisions shall be applied to customer installations at the discretion of Semaphore.
Semaphore shall notify customers of systems major revisions 1 calendar year before their application to a customer installation.
In the unlikely event that addressing a Critical security vulnerability requires a systems major revision, Semaphore reserves the right to apply the revision to a customer installation with minimal notice to customer.
An example of a major systems change would be the discontinuation of support for Transport Layer Security v1.2 for HTTPS connections.
Customer Systems Version
The Customer Systems Specification document is a separate document, but follows the above definitions of change and will be managed in the same way. When a single version string is required to describe customer systems, it shall be of the format:
{Systems Version}-{Short Customer Identifier}.{Customer Systems Version}
For example, for the fictional ABC Lab using systems specifications 1.19.1 and ABC Lab customer systems specification 1.4.0, the single string would be 1.19.1-abclab.1.4.0.
Platform
An example of a platform requirement:
“Authorized users shall be able to upload files to the system and shall receive a unique identifier of the uploaded file for future reference.”
Platform Patch Release
Platform patch releases may be applied to customer installations, from time to time, to address security vulnerabilities, defects, or for any other reason.
Platform specifications shall not change as a result of a platform patch release.
Semaphore shall notify customers after platform patch releases within 30 days.
Platform Minor Release
Platform minor releases may add new platform capabilities without disrupting current capabilities. These changes are termed “minor platform changes”.
Semaphore shall notify customers of platform minor releases 30 days in advance of their required application. Minor releases have an opt-in period.
An example of a minor platform change would be the addition of an option to provide a SHA-256 hash of a file’s contents when a file is uploaded, to verify the file’s contents are correct; or to allow anonymous users to upload files.
Platform Major Release
Platform major releases may modify or terminate previously established platform capabilities. These changes are termed “major platform changes”.
Semaphore shall notify customers of platform major releases 6 calendar months in advance of their required application. Major releases have an opt-in period.
In the unlikely event that addressing a Critical security vulnerability requires a platform major revision, Semaphore reserves the right to apply the revision to a customer installation with minimal notice to customer.
An example of a major platform change would be to require a SHA-256 hash of a file’s contents when a file is uploaded.
Definition of Opt-in Period
After a customer is notified but before the required application date (the opt-in period), customers may elect to schedule a date and time with Semaphore for a release to be applied to their installation.
Required Consultation
When considering major platform changes (as defined above), Semaphore will inform and consult with customers in order to minimize impact on customer operations. This consultation will take place no fewer than 9 calendar months before the required application of a major release that includes the change. Notifications of the opportunity to participate in consultation will be provided via e-mail to the customer 30 days in advance.
Support
Semaphore will support the most recent releases of both the current and previous major revisions of the platform, and any systems versions which are currently active on customer systems.
For example, if the most recent Platform release is 2.3.1, and the most recent release of the 1.x line is 1.18.5, we would support both Platform versions 2.3.1 and 1.18.5.
Relationship to Verification, to Validation, and to Installation, Operational, and Performance Qualification
Definitions
As stated at the beginning of this document, Labbit is not a medical device. Its use as part of a validated device (e.g. laboratory-developed tests) is intended to be facilitated by a customer’s verification and validation practices and documentation.
Verification “provides objective evidence” that software “output meets its input requirements”, using practices like “static and dynamic analyses”.
Validation is “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.”
The architecture of Labbit is specifically designed to enable verification to play a large role in qualification.
We define Qualification as a process of gathering objective evidence which demonstrates that a particular instance of the system meets its specifications.
Installation Qualification is qualification to gather evidence that Systems Specifications are met.
Operational Qualification is qualification to gather evidence that Platform Specifications are met.
Performance Qualification is qualification to gather evidence that user or configuration specifications are met, out of scope of this document.
Qualification Practices
Labbit specifications shall be associated with qualification plans which describe activities that will provide objective evidence that the described elements meet given requirements.
After changes to a Labbit customer installation, operational qualification will be performed if only Platform changes are made; both installation and operational qualification will be performed if Systems changes are made. Performance qualification is out of the scope of this document.