Clinical dashboards can expose sensitive information. Even aggregate data may be sensitive if site numbers are small or if filters allow users to identify individuals. A dashboard showing rare diagnoses, dates, and site information may create re-identification risk. Therefore, dashboard design must include data protection and governance considerations from the beginning.
Access should follow the principle of least privilege. A site coordinator may need to see records from their site but not other sites. A central data manager may need cross-site access.
An investigator may need aggregate summaries but not direct identifiers. Dashboard permissions should align with the study delegation log, REDCap user rights, institutional policies, and data sharing agreements.
Dashboards should also display data currency. Users need to know when the data were last refreshed. A dashboard based on last week’s export should not be interpreted as live. A refresh timestamp, export date, and data source description should be visible.
| Governance issue | Dashboard question | Good practice |
|---|---|---|
| Access control | Who can view which data? | Role-based permissions |
| Identifiability | Can users infer participant identities? | Limit identifiers and small-cell disclosure |
| Data currency | When were data last refreshed? | Display export and refresh timestamps |
| Metric definitions | What does each indicator mean? | Maintain a dashboard data dictionary |
| Validation | Are calculations correct? | Test against known outputs |
| Change control | Who approves dashboard changes? | Version scripts and document updates |
Dashboards should not bypass the approved database or query workflow. If a dashboard identifies a missing outcome, the correction should still occur through the source system and its audit trail.