Skip to content

COVID-19 testing history

COVID-19 testing history is the simplest operation in the library: it records whether a worker was tested for COVID-19 and the resulting test-result code against a claim, and reads that history back newest first. It is deliberately append-only — the criteria classes throw on any attempt to reach an update or delete statement — and it registers no business rules at all.

Field Value
Operation ID OP-CM-10
Trigger Caller invokes clsCovid19TestingHistory.NewCovid19TestingHistory(dataPortal, claimID) to record a new entry, or clsCovid19TestingHistoryCollection.GetCovid19TestingHistoryCollection(dataPortal, claimID) to load the history, then calls Save() on the collection*
Inputs ClaimID (Decimal); TestedForCovid19Flag (one character); Covid19TestResultCode (five characters); data-portal info supplying the acting user
Outputs Inserted COVID-19 testing history rows; an in-memory collection of test-history objects sorted by create date descending; an insert error carrying the DB contention message when the insert affects no rows
Primary components clsCovid19TestingHistory (Create, BeforeInsert, AfterInsert, Load, Fill), clsCovid19TestingHistoryCollection (BeforeRetrieve, AfterRetrieve, Save, Add, Contains)
Entry point Business\SAIF.Business.Claim.Maintenance\clsCovid19TestingHistory.vb

Steps

  1. Dispatch on the caller's intent. The business object exposes two independent entry points:
  2. Recording a test: NewCovid19TestingHistory(inDataportal, inClaimID) builds a criteria and calls the portal's create, which routes to Create() (steps 2–6).
  3. Viewing history: GetCovid19TestingHistoryCollection(inDataportal, inClaimID) builds a criteria and calls the portal's retrieve, which routes to BeforeRetrieve (steps 7–10).
  4. Initialize the record. Create() copies the claim identifier and data-portal info from the criteria, sets the create user from the portal info, sets the create date to now, initializes the tested flag and result code to empty smart strings, and marks the object new.
  5. Set the test values. The caller sets the tested flag and result code; each setter compares the incoming value with the current one and marks the object dirty only on a change. No validation is performed in the setters.
  6. Build the insert. On save, the framework detects the new and dirty object and calls BeforeInsert, which builds a non-query request from the insert statement and binds the tested flag, result code, claim identifier, create user, and create date, re-reading the acting user from the portal info at that point (SQL-012, CL_COVID19_TESTING_HISTORY).
  7. Execute the insert. The data access layer runs the insert against the database (SQL-012).
  8. Check the result. AfterInsert reads the affected row count.
  9. If the row count is zero: add an insert error carrying the DB contention message, even though the statement itself carries no row-version check.*
  10. If the row count is nonzero: no error is added and the object is considered successfully persisted.
  11. Retrieve the history for a claim. GetCovid19TestingHistoryCollection(inDataportal, inClaimID) builds a criteria and calls the portal's retrieve, landing in BeforeRetrieve.
  12. Build the retrieve request. BeforeRetrieve builds the request from the retrieve statement and binds the claim identifier; the statement selects the claim identifier, create date, create user, tested flag, and result code for the claim, ordered by create date descending (SQL-063, CL_COVID19_TESTING_HISTORY).
  13. Materialize the rows. AfterRetrieve loops the reader and, for each row, creates a test-history object and calls Load, which calls Fill to map the tested flag, result code, claim identifier, create date, and create user, then assigns a fresh criteria and marks the object old; each item is added to the collection.
  14. Re-sort and return. When the collection is non-empty it is explicitly re-sorted by create date descending — redundant with the statement's own ordering, but guaranteeing in-memory order regardless of provider behavior — and the populated collection is returned to the caller.*
  15. Persist newly added items. Calling Save() on the collection applies the pending edit and delegates to the base save, which runs the insert path for each new or dirty child item.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller has data portal and claim id]) --> Which{Record or view?}
    Which -->|Record a test| New[NewCovid19TestingHistory<br>runs Create: user, date,<br>empty flag and result]
    New --> Set[Caller sets tested flag<br>and result code; MarkDirty]
    Set --> Save[Save on the item<br>or the collection]
    Save --> Ins[BeforeInsert binds values<br>and runs the insert]
    Ins --> Rows{RowsAffected = 0?}
    Rows -->|Yes| Err([Insert error with<br>DB contention message])
    Rows -->|No| Ok([Row appended to history])
    Which -->|View history| Ret[BeforeRetrieve builds select<br>by claim id ordered by create date desc]
    Ret --> Loop[AfterRetrieve loads one item<br>per row and adds to the collection]
    Loop --> Sort[Re-sort by create date desc]
    Sort --> Return([Collection returned to caller])
    Return --> Add[Caller may add new items]
    Add --> Save

Failure and edge-case behavior

  • When the insert affects no rows, an insert error carrying the DB contention message is added rather than an exception being thrown, leaving the object in an error state consistent with the pattern used elsewhere in the codebase.*
  • No update or delete statement exists for this table. Both the single-object and the collection criteria classes throw an invalid-statement application exception if their update or delete statement properties are accessed, matching the SQL catalog, which lists only the insert and the select for this table. The operation is intentionally append-only: once a test result is recorded it cannot be modified or removed through this business object.
  • The single-object criteria also throws on its create and retrieve statement properties, so the individual object supports only the insert path; retrieval happens exclusively in bulk through the collection.
  • The collection criteria likewise throws on its create and insert statement properties, because inserts are performed per child item rather than by the collection itself.
  • No validation or business rules are registered: the collection's rule-registration method is empty and the item class has none at all, so the only constraints on the tested flag and result code are the one- and five-character parameter lengths.
  • Equality, hash code, and string conversion are based solely on the claim identifier, so two different test-history rows for the same claim compare as equal, which affects the collection's containment checks when multiple rows exist for a claim — as is expected for a history list.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Claim.Maintenance\clsCovid19TestingHistory.vb
  • Business\SAIF.Business.Claim.Maintenance\clsCovid19TestingHistoryCollection.vb