While there are many laws and regulations effecting the complex use and control of data in the Life Sciences industry, there are distinct patterns that emerge that transcend many of the laws and regulations. We believe that creating a data architecture that utilize patterns will provide significant benefits to your organization.
Although regulations tend to treat data as a risk, it is also your most important asset and these patterns can provide significant value to your organization. This blog provides a few data patterns that emerge from Life Sciences laws and regulations.
Within Life Sciences, there are a myriad of regulatory requirements and standards that you will encounter. A few are listed below with a summary of their intent:
1. 21 CFR Part 11 (ALCOA+) – All data related to patient and product safety must always be in a state of control.
2. HIPAA – All patient data is protected from unauthorized access, especially data that identifies an individual patient. This data is valuable for research purposes when de-identified, but you must ensure patient privacy with any use of this data.
3. GDPR – Consumers have a right to know what you are doing with their information and may require that you delete ANY trace of their information. You must know where your consumers (patients, health care professionals) personal data exists as it is used throughout your organization.
4. Transparency or Sunshine Act – All types of payment or incentives provided to Health Care Professionals must be tracked carefully and publicly reported. This requires that you combine disparate data from multiple applications.
5. FAIR – This is a standard that is typically used in research. For data to be valuable, you must be able to locate and access it. Synergy is created when data is combined from multiple sources and is made to be reusable.
Many organizations address these one at a time and even worse, project by project. We recommend that you step back and look at the patterns that emerge when you consider the total requirements:
A few patterns that emerge are as follow:
1. Vault. Some attributes such as patient identity require a deeper level of control and protection. This requires that your data architecture has attribute level security controls in place and centralized to ensure it’s always enforced. Patient outcomes become far more sensitive when the patient’s identity is added to the data stream. Your architecture must ensure that cannot happen without proper authorization. You need to put the most sensitive data in the vault and ensure that you only allow people to get to the data when authorized.
2. Compass. You need to know where your critical data is, where it goes, who is using it and how they are using it. This requires data governance and a centralized approach to sharing data. This also requires a data catalog that keeps track of critical data assets. Knowing this makes regulations like GDPR far simpler when you are asked to delete all instances of a customer’s data.
3. Parliamentary Procedures. You must have consistent business rules and quality checks for your data to ensure it is always accurate. This requires a centralized or hub approach to sharing and transforming data. It also means the business must provide corporate definitions for key data elements as they are the owners of the data.
4. Aggregation. Data is significantly more valuable when individual components or segments are brought together. For example, pairing results and demographics from commercial data with research data can yield great insights. This adds to the need for a centralized approach such as a data ecosystem for data storage, sharing and transformation. You can take a physical, virtual or data fabric approach, but the data management and rules need to be centralized regardless of where data is physically stored. This way, if a business rule changes, systems can either use or be notified about the changes.
Other patterns will emerge as you look at all regulatory requirements and consider them as one data architecture. There are techniques and tools in the marketplace to help, and as always, start small. Simply documenting your data definitions, ownership and movement through the organization is a great starting point. You can start with a spreadsheet tool and then move on to a data catalog when you are ready.
We value your feedback on these concepts and the names of the patterns. Are there better choices? What other patterns have you seen?
Rene Marcotte 
Sr. Vice President Delivery and Practice Management