In my previous post, we discussed some examples of business rules that might be applied depending on how many people are performing a clinical data review. Today, we’ll discuss approaches for selecting the data that is being reviewed. In any data review that occurs multiple times during the course of a study there are two basic ways to review the data:
- Review All Data (even if only a small percentage of the data has changed)
- Review Changed Data (using the ability to filter data base on new/changed state)
Clearly, reviewing the changed data is a boon to the reviewers and change state should always be a requirement and design goal for data review applications in cases where data can change between reviews. A considerable amount of time can be spent in data reviews and not re-reviewing data that has not changed can cut a significant amount of time for the reviewer. Another consideration is the type class of data to review.
You also need to identify the granularity of the review. The review can be performed on a record-by-record basis, or can be captured at a summary level. This review granularity determination drives the underlying data architecture requirements and design. Performance is a potential concern and care should be given to the design.
The identification of the data that has changed involves a time-based comparison of the data being presented to the user. This comparison should be a real-time comparison using the date of the latest data against the latest review performed by the user, group, or team, depending on the business rule being implemented as discussed above. This requires a few elements in order to support the data comparison to establish the data state:
- A unique identifier for the reviewed data that does not change over time
This supports relating the previous and current records to be compared if the granularity of the data is at a record level. - Audit History, or other timestamp on the data being compared
This supports identifying if the data has changed – an MD5 hash or other audit data can be beneficial for this purpose - A Review Timestamp on the record of a review (for a single record – or set of implicit records if all were reviewed)
This helps identify the last review performed for a specific record or records and sets the review state for the record being reviewed in New, Changed Since Review, or Removed (if appropriate). Granularity of the review will determine if you record at a record level or for a summary review level. - User Identification
The user identification must be recorded in the review record and provides important details for group or team membership.
All four pieces of data are important in identifying the state of the data for the specific reviewer. This state derivation should be dynamic (possibly part of a view) in order to account for ongoing reviews by the user, group, or team.
If you are interested in learning how Perficient can help improve your clinical data review process, please send us an email or fill out the “contact us” form in the footer of this page.
