{% set page_title = 'Bloom' %}
{{ page_title }}
{% set bloom_mod = 'lims' %}
{% include 'legacy/bloom_header.html' %}
Core
Bloom is an experiment in working with chatGPT to develop a LIMS from scratch. Bloom is meant to be a useful operational system and a tool to help explore the problem space (and guide development in a tighter feedback loop).
Architecture docs will follow, but for now, the following points are worth noting.
Bloom provides a model of the core LIMS objects and concepts & a way to mess with the models in near real time.
Provided UIs are functional for base needs. Elaborate for your use cases will need to be developed.
Beyond UIs, even for applications like dashboards, Bloom offers a handful, but complex dashboards are expected to be built with projects like superset.
Audit logs, for all details about every object. No data is lost or deleted.
Objects each have one EUID.
Barcode printing of EUIDs is EXPECTED by Bloom. Out of the box, Bloom will manage printing to ZPL printers. Printer config can be found in the admin view.
UI does not include highly error-prone operations like: DRAGGING and DROPPING, and discourages manual entry of data.
Once a sample is accessioned, all downstream EUID use should be handled by automated systems or scanning.
The UI offers the ability to navigate through all objects and their relationships.
Complex actions may be defined for objects.
Objects are modeled without taking conceptual shortcuts.
ie: containers and the things in containers are modeled independently, as are plates and wset.child_instance.json_addl.get.
Oversimplifying the core model to solve for this complexity is, I believe, a core reason most LIMS stink.
Development has focused on establishing the feasibility of this approach. Safety nets coming. In the meantime, it is possible to wedge the system (more so in the graph).
Bloom objects all adhere to a common set of interfaces, you can get a sense of this from the object detail pages. The entire dataset can be navigated from here.
'Batches' or 'sets' of any group of objects may be created, and this batch/set can be used to interact/monitor/etc this batch. (not used by BLOOM, but designed)
Bloom UI is easily skinnable for those needing different color schemes for usability. These can be switched between in the admin view.
UI design is functionally complete and could serve in production. However, it is demonstrating the finest level of control Bloom offers, and a high throughput scenario would be well advised to aggregate many operations when skinning a lower touch experience.
the following works out of the box
Receive a package, capture desired info (ie: FedEx trk#, used to calculate transit time for package). Try this FedEx test# 1001897582860000245100773464327825 .
Link 0-many kits to this package, capture desired info (ie: kit barcode, can be used to check kit vendor API for expiry of kit).
Link 0-many specimen containers to each kit, capture desired info (ie: collection date, etc).
ANY container type holding ANY specimen type is handled out of the box.
Create test requisitions ONCE for each unique req, then associate as many specimen containers to the req as needed.
Test requisitions may be satisfied by 1-many assays (as defined in the test requisition template).
Specimens associated to a test requisition are eligible to be added to assay queues available for the test requisition.
Add specimen containers to 0-many assay queue.
Manage different kinds of accessioning workflows.
Quite rich monitoring, reporting, observability capabilities (in real-time COGS tracking, in real-time FEDEX tracking stats).
UI design is functionally complete and could serve in production (with the same caveats described above applying). The two (example assay/queue/workset)'s are not intended for production use. They demonstrate how the Bloom objects can be combined to define types of work, manage this work, and monitor/report.
the following works out of the box
Example integration with automation platforms (ie: Hamilton)... this is there, just not exposed as I don't have the automation API to match to.
Develop a more complete Assay NGS use case, including integration with downstream data analysis AND looping back to Bloom to produce QC reports which can easily report on various DATA and BLOOM tracked metrics for things like BATCH monitoring/reports.
More user-friendly tools to create new objects and define workflows (Bloom was designed to achieve this eventually).
More comprehensive COGS tracking.
Add in the calculations for all of the operational timing metrics we expect (data is there!).
Develop a set of equipment management tools: objects are ready for this.
Develop reagent accessioning, lot/and real-time use tools, QC and monitoring tools: objects are ready for this.
Stuff Outside Bloom's Purview
All questions re: deployment, backup, etc. As the system is fully in the user's hands, they can dictate all of these details. FWIW, the core is PostgreSQL, and there are well-established management protocols for queue.child_instance.subtype.
Regulatory and Compliance: Bloom can meet any/all regulatory requirements. But, similar to the point above, this depends on how you deploy and manage it. Is it able to comply with CAP/CLIA? 100%.
