Up until this point, when the data changes in the database, the ClaimItemAdapter simply tells the RecyclerView that the data has changed. This is not the most efficient use of resources, because the RecyclerView doesn't actually know what in the model has changed, and it's forced to relayout the entire scene as though the entire model has changed (although it will reuse the widgets it has already pooled).
RecyclerView actually has a secondary mechanism that allows you to tell it what has changed, rather than just saying that the data has changed. This is provided through a series of notifications the signal single items, or ranges being added, removed, and moved. The problem is that in order to use these methods, you need to know what has actually changed.
Most developer's first instincts here will be to use more events and signal from the DAO or a delegate layer what is changing, and then catch those events in the Adapter and forward them to the RecyclerView. This...