This article assumes prior knowledge of basic Tulip concepts such as variables, tables, and completion records.


Language

The style and language of Apps should fit with their intended use. Standard operating procedures, work instructions and methods should be written in an imperative mandatory style.


Versioning

When publishing an App, it is recommended to describe the nature of the changes, e.g. UI refresh, error corrections or else, against the previously published App in the comment section.


Standard information to be displayed on each step

The following elements should be shown on each step in order to provide to the user the appropriate context:

  • The name or unique ID of the main item that the App is used to process. "Item" e.g. batch, order, equipment, or tool that is being used or processed. In some cases there could be multiple items. In most cases, this should be accomplished by creating or loading a table record containing the information at the beginning of the app.
  • The Logged-In User
  • The version of the App
  • The App Step name

It is also recommended to have a Log-Off button on all steps triggering an “Log-off current user” action.


Timestamps and date format

Timestamps in the completion record are captured in UTC with an offset for time zone. Date and time formatting can be set at the instance level for all Apps. This is done in the "Date and Time" section of the instance's "Settings" menu and needs to be configured by an Account Owner.


Capturing e-signatures with signature forms

In order to comply with ER/ES (Electronic Records / Electronic Signatures) regulations, a signature should give context to the signers:

  • “What”
    Context of the signature, e.g. batch, order, equipment, etc.
  • “Why”
    The reason of the signature, e.g. release of process order

The following structure is recommended for signatures:

  • Group steps that require an e-signature and include the signature form as the last step in the group
  • Create a summary step, if applicable, before the signature step showing all relevant data to provide the signer the context of the signature (“What”)
  • Use the form title, e.g. “Signature for label reprint”, and username label, e.g. “Supervisor”, to define the reason for the signature (“Why”).
  • Add a text input widget to the signature form for the signer to comment

When the signature form is submitted, Tulip automatically logs additional information:

  • “Who” signed the form
  • “When” the signature is submitted

It is mandatory to perform an App completion when submitting a signature form. It therefore may be required for an App to complete multiple times during execution. The following two subsections outline how data is handled during completion / cancellation.

App Completion

An App completion stores the current values of all App variables as well as the current field values of all loaded table records into the completion table of the App with one timestamp. The data in the completion table is immutable and cannot be deleted. An App completion resets all variables to their default value, but the ones which do have the option “clear on completion” deactivated. Additionally, all table record placeholders are cleared. After an App completion, it is possible to restart the same App from the beginning or proceed to a specific step within the same App or another App. This can be configured in the “transition” used to do the completion.

App Cancellation

An App cancellation is identical to an App completion however all variables will be reset to their default value.

Automatic App Initialization

For an App which needs to be completed multiple times during execution, i.e. due to multiple signatures, it is recommended to store its context before each completion, hence the App can be configured to automatically restore its context after it restarts. The context can be the ID of table records, e.g. current batch, and/or variables, e.g. a counter. It is recommended to store the App context in a table using the “App Info: Station Name” as the record ID. This record can be loaded on App (re)start using an “App Started” trigger. The same approach can be used to achieve a seamless transition to another App.

Similar principles can be applied to resume App execution after an App cancellation, i.e. due to an auto-logout or selecting “Restart” in the player menu. For these use cases, it is recommended to store a step name as additional context information for the App to open after restarting. This can either be the name of the last step shown, or a specific step that should be opened for recovery.


Exceptions and enabling review by exception

The use of one Tulip Table to collate all exceptions occurring during app execution is recommended. Every exception (defect, observation, etc.) should be stored as a single record in that Tulip Table including all relevant information on the exception, i.e. type, description, date/time, app, operator, etc. In addition this record should be linked using the “Linked Records” feature to the records of all artifacts related to the exception, i.e. batch, order, material, equipment, room, etc.


Records, Record Correction, Record History

It is recommended to store GxP relevant data as records into Tulip Tables with reference to its relevant artifacts, i.e. batch, order, material, equipment, room, etc.

It is recommended to correct GxP relevant data within the original record, as any changes will be reflected in the record history. The correction should be submitted by a signature form.

To facilitate record retrieval, it is recommended to assign an unambiguous and systematic ID for all entries, i.e. “<BatchNr>-<ValueID>”.

Record History

As described above, the values of variables are stored into a completion record at the time of completing or cancelling the App. In contrast, manipulation of data in a table happens in real time. Any change to any field of a table record will automatically be logged with contextual information (user, app, app version, station, timestamp) by Tulip.

Every Tulip Table record has a record history. This record history will show all the logged changes including the contextual information (user, app, app version, station, timestamp).

Furthermore, the record history will show the data of any App completion or cancellation in which the record is included, i.e. was loaded upon completion/cancellation. This includes any e-signatures logged in those completions/cancellations. Signatures will be shown in the record history timeline according to the timestamp when they were performed. All other completion data will be shown with the timestamp of the completion/cancellation.

Did this answer your question?