Hello Community,
Does any of you use any workaround to prevent duplicates in event capture data collection, like we have unique key in Tracker.
1 Like
Thanks @Gassim sorry that i was not clear enough. It’s like a typical situation with event capture,
Let’s say Malaria Case Registration: If we have a name, age, gender, and household location and if we want to avoid same person data entering twice, we don’t have such a restriction in events. I think it’s more a design but would like to know if people have some work arounds on this to prevent such duplicate entry.
In tracker we can have Unique ticked in tracker entity attribute for enrollment.
Thanks!
I see that in the event program you are tracking TEIs; however, in an event program the information isn’t supposed to be “” Supposed to be unique in the first place. From the way I look at it, it might be better if Tracker program is used. 
Please find the video that explains the difference between events and tracker: Module 2: Subsection 1 - Event and Tracker Program Introduction [Part 1 of 3] - YouTube
1 Like
Technically i agree, but the problem is there are certain programs which is just a one type activity, and which doesn’t have stages.
So enrollment is too much of complication if they want to edit it later, it comes lot’s of tabs and stuffs which are confusing for the user when we display empty stages and other informations
Only limitation why in such cases of events is we can’t prevent duplicates.
1 Like
We’ve not personally been able to prevent duplicates in our event capture data collection, though its a big issue for us and we have several tools that help us find duplicates that may exist. Some time back there was mention that " Data element from the newest event in the current program or Data element from the newest event for a program stage " in program rule variables could assist with this, but we’ve only seen these function on the tracker side.
Given all the above, what I would recommend is making it as easy/clear as possible to discover duplicates, so that they can be highlighted, that users can be aware they created duplicates, and so they can be removed efficiently. That said–definitely interested if you find a preventative workaround!!!
2 Likes
Thanks for the clarification! We can look at this issue in two ways. Your use case is a tracker use case so it’d be great to discuss how to support it using the dedicated tool, and since you are already using the event program and facing an issue (as well as @Matthew_Boddie) we could discuss this issue to solve it for event programs.
First, if you don’t mind, I would like to ask if locking the layout would help. If I understood you properly, it seems that issue is not when entering data for the first time because it’s possible to enter data and enroll at the same time, but that editing a program stage seems to be ‘complicated’ for users in the field because of layout. Am I right?
I would like to make a suggestion/request to check out the option to lock the view. In the Tracker Capture app it is possible to remove widgets and lock the view and this method will keep users from seeing everything else except the data entry form for the one particular stage.
Please have a look at the screenshot below:
Would the layout above be helpful? (If the tracker program is configured to have only one event then the add buttons will be locked as well.)
If it is then I would also like to raise this issue to @tracker-products and @tracker-frontend to see how this can be taken into consideration in the Capture app (which will replace the Tracker Capture app in the future.)
Thank you @Matthew_Boddie for sharing your experience and challenges as well. I hope we find a good preventative workaround… Additionally, I’m raising this issue with the @dhis2-tracker team.
Thanks!
1 Like
Thanks @Matthew_Boddie & @Gassim for the insightful brainstorming on this.
Yes Gassim let me try locking and removing the tabs to make it user-friendly.
1 Like
If we were able to use the Program Rule Variables to pull from program stages in the same way it does in Tracker Capture, that would be a really cool improvement that would help alot. This is in our current theory that the plurality of duplicates come back-back (i.e. an entrant enters an event, and then unwittingly enters in the same event again directly after). Just saying that out loud @gassim
!
2 Likes
Yes May be i feel we can have a program rule function like checkDuplicate(#{datalementid})?
Also @Matthew_Boddie how about if we have an option like we have in tracker entity attribute, for data elements also. Like we can tick a data element to be unique and can even generate pattern like ID, if data element is selected as tracker ( i think challenge internally would be data element values are stored in json and not as individual row values like tracker attribute)
1 Like
@jthomas lets goooo these sound very interesting.
I like the toggleable unique DE tag. That’s an interesting and good point on the backend feasibility given the structure of the json. that said, the API can still search through events using DE values as a specific request, even though the event endpoint. So hypothetically they should be able to (without any structural edits) do an api call on the events with the current program, current OU, and specific DE UID.If the result is a count > 0, then it can flag.
I do think that RANDOM() is an operator that works in some version/space in DHIS2, but currently not functional for this purpose. But it would be nice if it were!
1 Like
also how cool would it be @jthomas if we could simply make a boolean request in a program rule that uses API request as the condition
1 Like
Thanks alot @Matthew_Boddie that’s a great brainstorming all these features looks very much feasible and gonna be a life saver for us during a single time Uniqe event data collection
2 Likes
@jthomas this is also a path worth looking into: Need help - Using count distinct clause to eliminate repetitive data
2 Likes