Skip to content

Medically stationary date retrieval

A worker is medically stationary when no further material improvement is expected from treatment; the date matters because it opens the door to permanent disability determinations. This operation asks an Oracle procedure for that date for a given SAIF claim number and returns it as a read-only object, forcing the date to an empty value whenever the procedure returns an error message so that callers cannot act on a date that the database has disowned.

Field Value
Operation ID OP-BC-07
Trigger clsMedicallyStationaryDate.GetMedicallyStationaryDate(dataPortalInfo, saifClaimNum)
Inputs SaifClaimNum
Outputs The medically stationary date; ErrorMessage carrying the procedure's text
Primary components clsMedicallyStationaryDate.Criteria, clsMedicallyStationaryDate.BeforeRetrieve, clsMedicallyStationaryDate.AfterRetrieve
Entry point Business\SAIF.Business.Claim\clsMedicallyStationaryDate.vb

Steps

  1. Capture the claim number. The shared factory builds a Criteria holding the SAIF claim number and asks the framework data-access layer to retrieve the object.
  2. Bind the procedure call. BeforeRetrieve switches the request to stored-procedure mode, names the medically-stationary-date procedure, tags the request, binds the SAIF claim number as a seven-character input parameter, and adds an output cursor named recordset (SQL-024).
  3. Read the returned row. AfterRetrieve opens the cursor and, when a row is present, reads the medically stationary date and the procedure's error message into the object.
  4. Any exception raised while reading the row is caught and discarded, leaving the date and message at their initial values.
  5. Invalidate the date on error. When the returned error message has any content, the medically stationary date is overwritten with the minimum date value so no caller can mistake a rejected request for a real date.
  6. Return the read-only object. The object is marked read-only at construction and its create, insert, update, and delete SQL properties raise an application exception.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Caller requests the medically<br>stationary date]) --> Bind[Bind the SAIF claim number<br>and the output cursor]
    Bind --> Proc[Execute the medically<br>stationary date procedure]
    Proc --> Row{Row returned?}
    Row -->|No| Empty([Date and message<br>stay unset])
    Row -->|Yes| Read[Read the date and<br>the error message]
    Read --> Msg{Error message present?}
    Msg -->|Yes| Blank([Force the date to empty<br>and return the message])
    Msg -->|No| Ok([Return the medically<br>stationary date])

Failure and edge-case behavior

  • A procedure-reported error is not converted into a business rule failure; the caller must read the error message property, although the blanked date gives a second signal.
  • When the cursor returns no row the object is returned with an unset date and no message, which is indistinguishable from a claim that has never been declared medically stationary.*
  • The exception handler around the cursor read swallows all errors silently, so a schema or type mismatch surfaces as an unset date rather than a failure.
  • The claim number is bound as a seven-character parameter, so callers must pad or trim their claim number to match.*
  • The public property exposing the date is misspelled in source; renaming it would be a breaking change for existing callers.
  • The object is read-only, so the retrieved date can never be written back through this operation.

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\clsMedicallyStationaryDate.vb