BioFlow Requirements
System Requirements
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.
  • 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.