I have a general question about implementation in life science space to the community. I know at least @ZAP@kefl@michaelrcody@gil@Ilan@ctownkyle@william.miller work in this area, so your opinion would be greatly appreciated.
My question revolves around the completion records generated after operators performing various activities and signing off. I know the Tulip approach to this is that the completion record is immutable, but a data point isn’t necessarily as static as the concept might imply.
A few points to this:
In some cases operators wish to correct a previously recorded value. It is people operating the system so it happens and they do make mistakes.
Sometimes they need to append a comment to a previous entry. If a deviation is opened we might need to go back and work with a previous entry.
An entry might need to be reviewed subsequently by a colleague. In this process a comment might need to be appended, and as completions can only be presented in Record History widget & Analytics we can’t click / reference or otherwise interact with the data. This we manage by having a log entry that awaits a second person verification - but then we are moving into the minefield of making app specific log tables - which we should avoid!
We are on LTS10.6 and the record history widget has some presentation issues (which I know gets a bit better in LTS12). The concept of immutable records is quite restrictive and I do not believe ALCOA principles reject that data can be corrected or appended - just that we need to know who, when, why, what etc.
Two general workarounds exist. 1) Place data entries in log tables, but this is not recommended by Tulip and I agree that on a large scale it gets quite cumbersome to manage on Tulip platform. 2) Tell end users to just append a general comment as a new completion record and do their best to point to the previous entry by time/user/app and so forth. But that leaves that the original entry is wrong.
My question is: How have you overcome these challenges?
I am in Munich for the grand office opening event Wednesday afternoon May 15th. If anyone would be open to discuss this over a beer I am game
I know you are looking for some Community input here, so I wanted to prod some other folks I know work in the LS space / have experience with Completion Records & the Record History Widget to see if they’d like to chime in (or meet you in Munich for the Tulip Office Opening tomorrow ) @HCEH@jasonh@MarkStuttard@alec.giljohann@derrick.solidum@jjj@jacob.brightmeyer@edye@jmlowden I encourage any of you to share your learnings here, or if you have similar struggles, let us know as the Tulip team is here to listen and learn.
That being said, from the Tulip side of things, we really appreciate and understand the challenges you are bringing up here and will continue to discuss with our Product team the best ways to make completions records and the Record History widget easier to use for eBR/MBR/eDHR uses cases.
Thanks for bringing this up.
It is a very relevant discussion to take. Unfortunately I will not be able to join you in Munich this week, so I will give my 5 cents here and hope to get a rain check on that Bayern beer.
I am not sure why you think we should avoid using data log tables for capturing user entries. For us those tables are not single app specific but used across several relevant apps. Not sure how the data would be shared if app completion tables are used instead, but I haven’t dived deep into that yet.
We have been reassured by Tulip that using data log tables has virtually no limitation and we have not been advised to avoid it. So I am very much interested to hear your arguments for the opposite.
I can only agree with you with the limitations of using Completion tables for capturing user data entries, namely as you already mentioned.
Using data log tables would not solve the challenge of traceability between entries, e.g. a corrected entry would essentially be a new entry with a new unique ID without direct link to the “locked” original entry that needs to be corrected. Only text reference would link these together, but the text reference is only visible from the corrected entry.
This being said, we do operate with different statuses of entries, permitting correction of the “wrong” entries (e.g. appending extra comment) as long as they don’t get a final status whereby they get “permanently locked” for editing.
Late to the game here, but we are not really leveraging Completions data at all for our medical device distribution / inventory management use cases - pretty much all Tulip Tables, our enterprise standards and SDLC/CSV procedures require that we can access the record history (audit trail) for each GxP data table, so demonstration of this functionality has been included in each app’s UAT.
Normally operator corrections are performed within the same session as data entry, so we could use completion data for this, but in the event errors are identified after the app session closes, the table approach allows a “super user” to correct and annotate the record, which is clearly visible in the record history.
Yeah, generally agree with @jmlowden, if you have access to the record history widget then there isn’t much reason to use completion records. Their main benefit is immutability which becomes mostly unnecessary with RHW. However, there are some cases where you might want to build analyses or exports off of the completion logs. Tulip has not made much progress on exposing the RHW data to be used in more flexible ways or accessed via API.
