Hello,
Is it possible to have the same APP session for multiple users (different screens)?
Example 1:Assuming you have an eBR (electronic batch record) process and for one of the steps, data is entered by Operator A, while for a different step, data is entered by Operator B.
Example 2: A verifier has to sign a step on his own laptop.
Thanks!
Hello Darius,
Yes this is a very common scenario and how many of our customers use Tulip. Simple create Apps for the different use cases and then configure your stations to allow the specific apps to be used at that station. User logging in to the devices at each station will only be able to choose relevant apps and that is how you control the capture of the eBR.
You an configure the signature form to require signatures from either the operator logged in, another user, or a specific user. You can also create specific app that capture signature form other people.
Let me know if that helps?
Thanks
It helps but I feel it complicates a little bit.
Let me get into more details:
Imagine you have Line Clearance which might be a process step in a big eBR recipe and it comprises from three minor steps - Clear → Clean ->Check. When performing the Clear, the Supervisor has to respond to some questions and then sign it. If you have a separate APP just for this, I find it complicated when you want to revise the full eBR process and see what happened. In a eBR world (GxP) if you have lots of Apps and lots of manufacturing orders in progress it might be cumbersome with multiple Apps especially when you want to review the process.
It would be nice to have an option like “Acquire App” where a different user with the right permission can get access to a running session of an APP and logout the original user. At the same time if the original user wants to regain access to the current step, he should just push the option “Acquire App” again.
Yes, what you are describing is a very common example of what our life sciences customers use Tulip for. It is solved by using Tulip tables as the common data for all the apps. In other words the Apps all work with a common set of tables that maintain a current state of materials and resources.
So if you have a table that is for example called “Materials” (or batch, lot, unit, etc.) where each row in the table represents a batch (or discrete unit of material) then all apps can load a material record and change values as it works thru the process. Every table in Tulip has an audit log and as you change values in each record (cell in the row) Tulip records the changes in the table audit log. At the same time the app can save contextual and relevant process data in the completion records using the App.SaveAllData trigger.
The Tulip “Record History” widget is then used in combination of other analytics graphs and charts to display and browse the complete history record of the Material. BTW this pattern can also be used for a Table called for Example “Equipment” which gives you a full equipment log - used for equipment logbooks. In the same way an “Events” table can have information about deviations and quality events which in turn gives you full quality tracking features like in a QMS.
Remember that signatures are captured in the App’s completion record and can also be viewed in the Record History.
Following this pattern you can have different apps for different operations with multiple users logging in and signing electronically and support quite a complex manufacturing operations. We have plenty of examples of this type of use and soon many examples will be available in the Library.
I would also suggest to read the following 2 support pages.
https://support.tulip.co/en/articles/4742213-best-practices-for-gxp-app-building
https://support.tulip.co/en/articles/5096742-gxp-app-building-basics
Thanks again for the explanations.
Imagine having so many apps, the reviewing process becomes a nightmare for the QA person. I am coming from the traditional MES where at any time in the process you can run the Batch Manufacturing Report and see what was completed at that point.
Maybe I have to see an example when you publish them in the Library, as currently I still don’t understand how can you work with the workaround provided.