Being a consultant company, we often run into questions related to the Patient Data Act (PDA), General Data Protection Regulation (GDPR) or other regulatory requirements and principles. We have developed a method to address regulatory and other non-functional requirements.
Our company has worked with customers within health- and biotech industry for several years. One of our customers is a health provider with clinics in more than 20 countries. Because they reside in many countries, we have multiple PDA and other regulations to consider and to implement in their software, processes and organisation. But are there any differences when we working with other industries, e.g. food or finance?
Of course, there are different regulations depending on the industry. The model we address the regulatory requirements, and use them in our processes and critical software, should be similar no matter which sector we work in.
IDENTIFY THE REGULATORY REQUIREMENTS
As you may know, to be compliant is not only about the software. How you work, your processes, your values, these are also parts of compliance. For this particularly customer, we collected the Patient Data Acts from all 20 countries and started to identify what requirements affected the software and what requirements affected the processes within the organisation. When we looked at the processes and the software from a holistic view, we quickly found out, many of the regulatory requirements could be treated as properties of the solution.
So, what is the best model to handle this type of requirement?
As an example, in the financial sector there are a lot of discussions about regulatory requirements in regards to Risk Management. One well known set of requirements from ECB is called BCBS239 (RDARR). When we read through those principles it’s obvious, the requirements are high level properties on the solution.
The traditional way to analyse requirement is to break them down into sub requirements until each detailed requirement can be solved with a pretty straight forward solution. However, when we work with non-functional requirements e.g. regulatory requirements, this method could be a trap which leads us into an extremely fragmented solution where we lose our eagle eye perspective and the ability to maintain the solution.
REGULATORY REQUIREMENT ARE PROPERTIES OF THE SOLUTION
With a superior list of principles e.g. BCBS239, we think it is best to use another approach. The experience we have gained, we can address the requirements as properties of a solution. When we use this model, we will move our focus from a pile of requirements into a solution with a set of properties. When we shift focus, we will soon find it much easier to work with the requirements and make our systems and processes compliant. It’s still a lot of work to do, but our effort will be much smaller and we will gain control of the implementation process.
BCBS239 describes properties of the solution not functional requirements. We can recognise this model from other quality standards e.g. ISO9126 or ISO25010. We treat the principles in BCBS239 as properties of the same solution. The scope will be smaller and easier to manage. It will also be easier to demonstrate compliance against the principles. The illustration in this article shows how to look on the solution from different views, each view with a property as the focus point.
During the process of making a change in our system, we always return to this model to verify we are still compliant. We look at the changes through the different views of the solution, the properties. This will let us know in an early stage, if we eventually will make a change against any of the properties. Once again, using BCBS239 as an example, we should verify the change we implement is compliant with the requirements of:
- Principle 1 – will the change affect the Governance?
- Principle 2 – will the change affect the IT Architecture?
- Principle 3 – will the change interfere with the Accuracy and Integrity?
- And so on…
When we design, and develop a solution, we work on the solutions in several layers before it is implemented. On the top layer, we design the solution on a conceptual level. The iterations will lead into a conceptual solution which can be verified against the different properties. Each layer has its own purpose, and the granularity is in more detail for each layer we pass through. At the bottom layer the solution is implemented and verified against the properties. This method helps us to secure we are compliant through the whole development process as well as the solution.
A common error some companies tends to do is to only make their software compliant. It is important, but the IT architects who understands the regulatory requirements can do this easily. Compliant software doesn’t necessary make your organisation compliant and the risk to fail in an audit or review is much higher. The processes and work instructions are even more important and easy to forget.
We use this model when we work with compliance and regulatory requirements. It helps us keep our focus on the requirements and the gain we receive is far beyond the effort. The model is not only applicable during an organizational change or during a development phase, but it is also applicable when the business is in normal operational state.
Our experience has shown the model is applicable cross-industry. Even if the requirements differ, the model to address them is the same.