Best Practice use of Completion Records & Table Records for Process Industry EBR

Support, Troubleshooting, & Help
1

We are working on a set of EBR applications for a Process Industry customer, where some of their processes can last multiple days, across multiple shifts and be updated by multiple users. Each EBR app has multiple pages and multiple entries per page.

What would be the best practice use of Completion Records & Batch Tables to ensure that each action has the current user assigned and a new user can load the app and pick up where the other left off?

They are mainly using tablets to enter the EBR data.

2

Hi @JezHarris, for a common approach on satisfying a ‘pick up where you left off’ use case, see the KnowledgeBase article ‘Pause and Resume Functionality’ within the ‘Regulated Industries’ series of articles.

Regarding Completion Records usage, you will see some discussion on best practices at ‘Best Practices for GxP App Building’ and ‘Best Practices for Storing Data in Tulip’.

Hope these help!

Tim Reblitz
Digital Transformation Consultant

1 Like
3

Hi @Tim_Reblitz,
Thanks for your reply, I had already found most of the knowledge articles that you suggested, and have already built the EBR apps for ‘Pause & Resume’ in alignment with them.
It is not to dissimilar to the way I have been working with MES for many many years…

I suppose what I am trying to understand is the best way to augment this with the Tulip Completion Records, which are new to me.
My intention was to use the completion records to link the user/s who performed each entry, rather than to double up each Record Table entry with a user column to record the user who entered it, which is a customer requirement.
By using a “Save all app data” trigger at the end of each page.

But not sure if this is the best route to take or how to retrieve & link the two sets of data later on?

4

@JezHarris , to simply record who did what step(s) and when, etc… the Tulip app completion records is the best/recommended route.

5

Hi @Tim_Reblitz
Many thanks, we will continue that approach
Record tables to store the values and completion records to store the who, what and when…

If in a few months they need to look into a specific batch, how as an end user do they link the values to the who, and when?
I assume the development of some analytics?
Are there any existing templates that we can use as a start?

6

Jez, assuming your Tulip instance licensing level is Regulated Industries, you can use the Record History Widget in addition to Analytics of Completion Records.

A basic eBR app suite template is available on the Tulip Library here, which uses the Record History Widget in the eBR review app.

7

Hi @Tim_Reblitz, a bit of background might help.
I am working as a solution architect / development lead with the team at ‘Bow and Stern’, developing my first set of Tulip apps for a client in the UK, our partner license allows for Regulated Industries, but the UK client only has a Professional license, therefore no Record History Widget!

Therefore just trying to best understand how the end user can make best use of the saved completion record… or if we need to provide some specific development to suit their use case.

Your help and suggestions are much appreciated

8

Hi Jez

Life Sciences customer here.

I will say first that if your process industry customer is FDA regulated I strongly recommend getting GxP licensing for them, as there are a large number of controls around user access and audit logs of record changes that are critical for ensuring compliance with FDA’s regulations around traceability of device history record/electronic batch record data.

However, if that is not a concern for you, how I have approached this in medical device manufacture is by using a table for all our assemblies. Along with other attributes, each assembly gets a

  • Location (Text)
  • Step (Integer)

Location corresponds to the app used for that part of the process, and step corresponds to how far through the app the device has proceeded. When users scan in their assembly, the app checks that the assembly is at the correct location, then directs the user to the appropriate step in the app based on the current step of the assembly.

When the user then finishes all the material on the step, the app either bumps the assembly to the next location, or bumps it to the next step (i.e., the next step of the process)

Note that this is indeed very similar to Tulip’s recommended pause/resume functionality, with the caveat that while Tulip uses step names, we do not. That is because we want to avoid a scenario where someone updates a step name and as a result assemblies get lost in translation.

In the case that you have data you need to be able to review later in the process, my recommendation would be to set up a generic data table that hashes the batch ID to labeled data. For example,

  • ID: MyBatch1/Cell1incubationTemperatureCelsius
  • Assembly ID: MyBatch1
  • Data Name: Cell1incubationTemperatureCelsius
  • Type: Number
  • Value: 20

If you then want to review what data was collected for a device later, you can retrieve it by querying all rows in this table that have Assembly ID == MyBatch1. You will probably want to alter this structure depending on how you manage your data. (For example, if you group batches by a purchase/work order, you will probably want to include purchase/work order as a field in this table

1 Like
9

Quick note on the item above:

If you go down the route of getting GxP licensing, you won’t need this generic data table in 90% of cases, since the record history widget allows you to attach arbitrary data to table records on an app-to-app basis. However, you may still want to do this if you intend to save data about a device at App A, and then use it for a calculation in App Z. We do this wrt our assets by using this structure to define arbitrary data about an asset, and let apps used to execute maintenance processes pull it in as desired later.

There are some changes to how you should approach logging data in GxP due mainly to some realities of how the record history widget produces data (it is an excellent audit log, but a not so excellent review UI), and if you choose to use a GxP approach I’d suggest ensuring you have some record that can act as a “bookmark” to help you retrieve process data associated with app executions, and act as an at-a-glance verification that an operation occurred.

10

Hi David,
Many thanks for your response…
The customer is not in a regulated industry, so trying to work a round not having the record history widget.
I have the pause and resume functionality working well, and this was my design from the start, as one of the processes can last over 3 days, and have data entered by more than one user (not at the same time), but possibly on more than one tablet device.

But there is also a requirement to log the user who entered each piece of data and for this my idea was to utilise Tulip Completion records as the source.

Having main batch record data values stored in Table Records, with the who and when stored in completion records. The data being linked by a Batch Number (ID).

Again all seems to be in place, just trying to understand the best way to retrieve and link both data sets when required to view.
The customer normally will only look back at all of this data by exception, if there is an issue discovered later on, it is not really used for trending or analytics from here.

11

Ah, I see

If you only wish to record who entered the data, you may be already all-set, as the completion record should natively include the username of the person generating the completion record. You can use a “table” style analysis to report out certain data you’d like tracked, the user ID, and the ID of the batch just to make this human readable. Then anyone should be able to pull of the analysis and search it for the batch ID, to get a roster of the data logged for that batch.

In short, just make sure

  • You are saving the batch record for analysis
  • You are saving the data you want recorded for analysis

And your completion record will always contain the User ID, data, and batch ID for you to retrieve.

2 Likes
12

Hey there! We just launched our Composable MES for Pharma, that illustrates our best practices to build eBR in Tulip.
If you have the chance to look at it, I would love to hear your perspective on it!

1 Like