BioFlow Requirements
Software Requirements Specification
  • SYS-001
    reviewed 1. First-launch readiness for local enrolment UID: SYS-001 RELATIONS (Child): STATEMENT:

    When the device is opened on a workstation that has no pre-existing BioFlow data directory, a default local clinic shall be present and immediately available for the clinician to attach newly-enrolled patient records, without requiring the clinician to first create or configure a clinic record manually.

     RATIONALE:

    Stakeholder commitment: clinicians installing the device on a fresh workstation expect to enrol their first patient within minutes of starting the application, without learning a separate clinic-management workflow as a prerequisite. Auto-provisioning a default local clinic removes that friction.

     TYPE:

    functional

     ACTIVE:

    true

     REVIEWED_HASH:

    c22a517f428da0e422be230bae3d28a2b6c6f69e823c99a130b08e26cedb6c22

     REVIEWED_BY:

    @DougYoungberg
SRS-001
reviewed 1. First-launch database initialisation UID: SRS-001 RELATIONS (Parent): RELATIONS (Child): STATEMENT:

On first launch, when no database file exists at the configured application data path, the software shall create the local database, apply the current schema version, and create a default local clinic record that serves as the container for locally-created patient records.

 RATIONALE:

Refines SYS-001: the software-level mechanism that realises the device's first-launch readiness commitment. Establishes the minimum persistent state required for any subsequent clinical operation — without it, patient records cannot be stored and recording sessions cannot be attached to a patient.

 TYPE:

functional

 ACTIVE:

true

 REVIEWED_HASH:

b2dacb9770834083552885f0b26dfd623390ebf0a0cfa890795079d5b9acb043

 REVIEWED_BY:

@DougYoungberg

 NOTES:

coverage-plan: ST-001 on clean install — fresh workstation, first launch, verify the local clinic is visible in the Patients menu.
  • ARCH-001
    reviewed 1. Local persistence subsystem UID: ARCH-001 RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The local persistence subsystem owns the application's local database — a SQLite file encrypted at rest via SQLCipher, located under the configured AppData path — applies schema migrations via Drift on first open, and exposes a typed API to the application layer for the clinic, patient, and recording domain entities.

     RATIONALE:

    Hexagonal layer realising the broader local persistence concern. Encapsulates file lifecycle, encryption (SQLCipher), schema migration (Drift), and the typed domain-API contract — keeps the rest of the application unaware of storage details.

     TYPE:

    subsystem

     SAFETY_CLASS:

    B

     ACTIVE:

    true

     REVIEWED_HASH:

    1910b72998ec774f37586ae58434e21b6689aab3a07dcda6d78d70caf0cdf592

     REVIEWED_BY:

    @DougYoungberg
  • ST-001
    reviewedPassed 1. Local clinic visible in Patients menu UID: ST-001 RELATIONS (Parent): STATEMENT:

    With the application launched on a workstation that has no pre-existing BioFlow data directory, navigate to the Patients menu and open the clinics dropdown. The local clinic entry shall be visible in the dropdown.

     TEST_METHOD:

    automated

     TEST_TOOL:

    VisionTrace

     ACCEPTANCE_CRITERIA:

    Preconditions: application is launched on a clean workstation (no prior data directory); the main screen is visible. Steps: navigate to the Patients menu; open the clinics dropdown. Verification: a VisionTrace AI agent.verify(...) call confirms the local clinic is visible in the dropdown. No error dialog appears during launch or navigation.

     ACTIVE:

    true

     REVIEWED_HASH:

    362fe8cf9e9bbd843a2b2a0ad5eb7883748412bdbb21fff6694b075908e40dfe

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    Launching the application on a clean workstation is a test precondition handled by the VisionTrace app_session fixture, not a step in the test body. Test code lives in this repo at visiontrace_tests/bioflow/st001/, decorated with @visiontrace_test_case("ST-001"). The agent.verify(...) call takes a screenshot of the current UI and asks an AI model to confirm the described condition — for this test, that the local clinic is present in the dropdown. Running this test in CI requires VisionTrace to be installed in the CI environment and a Windows runner with a usable desktop session. Multi-link verifies SYS-001 (operator can enrol on first launch) and SRS-001 (software creates default clinic); both close via this same end-to-end observation.
  • SYS-002
    unreviewed 2. Confidentiality of patient data at rest UID: SYS-002 RELATIONS (Child): STATEMENT:

    The device shall keep clinic, patient, clinical-user, recording, and audit-log data stored on the local workstation confidential against any party gaining access to the workstation's filesystem without the operator's BioFlow credentials.

     RATIONALE:

    BioFlow workstations are deployed in clinical environments where multiple staff and IT roles share physical access, and the local data store carries identifiable patient records. HIPAA Security Rule §164.312(a)(2)(iv) (encryption of ePHI at rest) and GDPR Art. 32(1)(a) (encryption as appropriate technical safeguard) require that filesystem-level access does not yield readable PHI on its own.

     TYPE:

    regulatory

     STANDARD_REF:

    45 CFR §164.312(a)(2)(iv); GDPR Art. 32(1)(a)

     ACTIVE:

    true
SRS-002
unreviewed 2. Local database confidentiality at rest UID: SRS-002 RELATIONS (Parent): RELATIONS (Child): STATEMENT:

The software shall keep the local database file unreadable to any process that opens it without supplying the database credential, and shall reject database read and write operations when the credential is missing or incorrect.

 RATIONALE:

Refines SYS-002. A workstation that is lost, stolen, imaged, or backed up off-site shall not yield PHI from the local database file alone. Tying readability to a credential held outside the database file ensures offline copies of the file cannot be opened independently of the BioFlow application's credential pathway.

 TYPE:

security

 STANDARD_REF:

NIST SP 800-111; IEC 81001-5-1 §5.5

 THREAT_REF:

PHI exfiltration from a lost, stolen, or imaged Windows host

 ACTIVE:

true

 NOTES:

coverage-plan: IT-002 attempts to read the on-disk file without a credential and confirms the read does not yield plaintext records, then opens it through the application's pathway and confirms the records are readable.
  • ARCH-002
    unreviewed 2. Local database encryption UID: ARCH-002 RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The local SQLite database is encrypted on disk via the SQLCipher extension. The encryption key is held by flutter_secure_storage, which on Windows persists it as an entry in a DPAPI-encrypted file (flutter_secure_storage.dat) under the user's local app-data directory. On application bootstrap, the key is retrieved from secure storage and generated-and-persisted on first launch if absent. On every database connection open, the database connection service applies the key as the first statement (PRAGMA key) before any other operation; SQLCipher then transparently encrypts and decrypts SQLite pages.

     RATIONALE:

    Page-level encryption via SQLCipher avoids per-record encryption logic in application code. Holding the key in flutter_secure_storage (rather than alongside the database file) ensures a copy of the database file alone cannot be opened. Bootstrap-time key generation lets the application be self-installing on a fresh workstation without a manual setup step.

     TYPE:

    data

     ACTIVE:

    true