Why do we need a risk management framework?

Particularly since September 11th 2001, there has been increased interest in risk management in organisations. There have been several initiatives to produce technological risk management frameworks (RMF) as a tool for organisations to better manage risks associated with the use of information systems, with the general desire to reduce risk. On of the most notable RMF efforts has been by COSO (www.coso.org), an association sponsored by the American Accounting Association, the American Institute of Certified Public Accountants, the Financial Executives Institute, the Institute of Internal Auditors, and the National Association of Accountants (now the Institute of Management Accountants, with representatives from industry, public accounting, investment firms, and the New York Stock Exchange[1]. This framework is currently in its final draft, with a scheduled release in September 2004. With a strong bias towards management controls and financial issues, the COSO Framework appears to be heavily weighted towards individuals with experience in areas related to audit and controllership[2]. The need for such a standard for businesses is catalyzed by legislative and regulatory changes in the USA (for example, the Sarbanes Oxley Act of 2002) and by financial scandals (Enron, Martha Stuart Living, Parmalat, Nortel, etc). In this context, issues of risk management are seeking to reduce financial losses resulting from negative events, implement sound accounting and auditing practices and provide accurate financial reporting. Ethical issues may be considered, but are more concerned with protecting the reputation of the organisation.

Other RMF available result from Governments[3] and are intended for use by Ministries and Government agencies. These are also driven by financial responsibility and often by eGovernment initiatives.

A study of risk management practices in 31 financial institutions in 12 jurisdictions, described in [Basel, 2003] found that there are two important trends in risk management in these industries:

  • Greater emphasis on the management of risk on an integrated firm-wide basis, and
  • Related efforts to “aggregate” risks through mathematical risk models.

The [Basel, 2003] study found that these trends :

stem from the interest of firms in understanding better the variety of risks that they face, thereby enabling them to determine more accurately the amount of capital they need to operate their businesses.”

In the healthcare field, there are risk management frameworks, for example for public health or environmental risks, but we have not found any Information Technology (IT) RMF, specifically designed for healthcare organisations. At best, we are aware of initiatives to produce implementation guidelines for ISO 17799[4], but this international standard does not provide a comprehensive risk management, it is more of a best practices guide.

Other risk management initiatives provide risk assessment tools and methodologies. We have looked at published IT security risk management methodologies available, such as GMITS [ISO 13335-2], Octave [Alberts, 1999], MEHARI [Clusif, 2000], TSIT [GRC, 1994] or IVRI [Léger, 2004], and several others and found these to be focussed on risk assessment. While this is an important part of risk management, risk assessment, in our view, is only a part of the solution.

We are seeking to develop a risk management framework for use in healthcare with the implementation of Clinical Datawarehouses. It is intended for use, initially, in the Canadian not-for-profit public healthcare environment. In this environment the fundamental biases of frameworks like COSO, toward financial risks, seem to give more emphasis to financial issues while minimizing the impacts of risks shoes consequences are intangible or difficult to quantify in monetary terms, such as divulgation of an individual’s health data or loss of privacy. In our opinion, any RMF developed for use in healthcare needs to be more neutral in the weighing of financial issues and appropriately weigh issues related to ethics as a component of organisational risk. Most particularly, clinical datawarehouses, as technology used in clinical trials, are subject to complex ethical requirements[5] and deal with many sensitive ethical issues.

What is the framework?

We propose to create a risk management framework (RMF) specifically for healthcare. Having looked at what is out there and based on the experience in risk management of the researches involved in this project, we have developed a proposal of what this model would look like.

The proposed risk management framework is comprised of five layers:

  1. Risk mitigation measures;
  2. Risk assessment;
  3. Ethics and policy;
  4. The seven principle variables of risk (confidentiality, integrity, availability, origin of data, origin of access, access control and non-repudiation;
  5. Composition of the data.

The framework can be visualized as a set of filters. Different stakeholders would use it to help them with the issues that relate to their functions in an organisation. Looking at it from various points of view, for example the point of view of an IT practitioner, the point of view of a healthcare professional, or the point of view of a patient, would provide different views on the data elements contained in the CDW, that is positioned below the layer 5, which represents the composition of the data.

How would the framework be used?

There are many ways in which the framework could be used. An IT practionner would use the framework, for example, in the identification of risk mitigation requirements, for example to help them select encryption tools, firewalls or determine user account configuration. In order to do this, he would look at the framework through layer two. Patients, or subjects of a study, could be interested in the composition of the layers (the filters) to understand conditions under witch he is granting informed consent. A researcher, looking to access clinical data from a clinical data warehouse, would be looking from above layer one, through all layers, to see, for example, anonymized data in a secure manner, the resulting filtered data, as illustrated in the figure below.

In this example, a researcher looks at the Clinical Datawarehouse through the filters of the RMF. What he sees, from above, is clinical data filtered by the different layers. At the lowest level, the complete data is present, going trough the layer four, it is mapped to its basic variables and filters are applied, based on the ‘authorisation profile’ of the research. So looking from above, at the layer 3, the data is reduced. In a database application, it would be like reducing the number of rows in the tables of the database. At layer 3, ethical ‘rules’ are applied, so looking from above, certain elements of the data are masked by layer 3. Using the requirements in layer 4, layer 3 applies filter to data elements within the data received from layer 4. Again using a database analogy, this would be like hiding columns in the tables of the database.

Then at the risk management layer, provisions are made for the requirements in risk mitigation (layer 1). At this layer, security policies, for example, may dictate the manner in which data is to be delivered to specific locations. Again as an example, clinical data accessed from an off-site access point, may need to be delivered using Secure Socket Layer (SSL) encryption if it’s using a shared or public network. These kinds of rules are managed at this layer.

At layer 1, the data views from layer 3 are delivered to the data user (the researcher in our example), through some kind of combination of terminals, networks and software. The filters at this layer are concerned with how the data is transported and the impact of the transport mechanism on what can be carried over from the layer 3 to the user. In our example, should the researcher attempt, for example, a remote access to the clinical data from an access point that has too high risk to view some of the data, these elements would be filtered out.

There are many possible points of view, we have shown a few here as examples. In the course of our research project, several of these need to be developed to cover the principal processes.

As well there would be scenarios that cover RMF implementation, creation of CDW, data maintenance, and other processes involved with the creation, use and maintenance of CDWs.


We see several benefits associated with the use of our framework in healthcare. We list a few of them here:

  • Provides a standard vocabulary for the treatment of risk in CDW applications;
  • Provides standard measurements (benchmarks), for example to monitor risk over time, to compare healthcare organisations or to facilitate partnerships;
  • Provides well described processes for healthcare stakeholders to use in the treatment of risk;
  • Provides a framework to monitor the conformity of data use with the obligations derived from the informed consent;
  • Ensures that all the critical aspects of risk are included;
  • Ensures that adequate treatment of ethical issues, particularly the specific requirements present in healthcare;
  • Helps organisations select and implement risk mitigation tools;
  • Helps organisations make resource allocation decisions.

Description of the layers

The first layer deals with risk mitigation measures. These are the measures that help an organisation to achieve acceptable levels of risk, determined at layer two. As well, this represents technical controls implemented by an organisation to enforce the measures trough actual access. For example, Privilege management, authorization and access control, would be defined at this layer. As our management framework is primarily about helping organisations make risk management decisions, we feel that this layer is very important to IT practionners. They would be major stakeholders at this layer. This layer would act as a filter between risk (the second layer) and data components (the fifth layer) through the risk mitigation measures layer. Definitions of the requirements at this layer depend strongly on the result of risk assessments, performed at layer two. Ethical issues, at layer three, permeate to this layer through the risk assessment processes, at layer two. This layer is also concerned with access to the CDW, are it deals with technical aspects of risk mitigation as well as with processes. As a starting point, ISO 17799 will be used to provide guidance in this layer. Specific requirements are

The principal processes include:

  • Identification of risk mitigation requirements;
  • Evaluation of risk mitigation solutions;
  • Impact assessment;
  • Training; and
  • Automated audits.

The second layer is the risk assessment layer. In this layer, risk is identified and categorized by a form of organisational Risk Governance Committee (RGC) guided by a Risk Manager (RM). This is one of management committees that would be defined by the RMF. It would individuals from all the stakeholder groups. Assisted by a Risk Assessment Methodology (RAM), and eventually by software tools, the RGC would apply the RAM to produce a Risk Profile (RP). Here existing tools could be integrated, such as CRAMM.

The principal objective at this layer is to determine actual risk in relation to a determined organisational tolerance for risk. As well, at this layer management rules and organisational policies for risk management are set. Risks that exceed the organisational tolerance would be covered by the application of the first layer, risk mitigation measures, for treatment. Input into this layer is provided by the knowledge of the organisational culture and the organisational requirements, by the RGC, as well as by the requirements brought up by the other layers of the framework, notably by layer 3 (Ethics) and layer 4 (Risk variables). This layer would use a set of rules that would regulate the required treatments (in layer one) for the weighted data components, visible from layer two through the filter of layer three.

Classical elements, such as operational risks, financial risks and legal compliance of risk are integrated at this layer.

The principal processes include:

  • Threat assessment;
  • Risk categorisation;
  • Risk assessment;
  • Establishment of the organisational tolerance level for each category of risks;
  • Regular reviews.

The third layer is where we address the issues relating to ethics as a driver of risk. Ethical issues can add weight to the sensibility or vulnerability of the data components. At this layer we want to describe the ethical issues are reinforcing or reducing certain of the relative weight of the data components (layer five), categorized in relation to the seven variables (layer four). This layer seeks to act as an interface between the risk assessment (layer four) and the requirements of the stakeholders, as expressed in layer two). It would add, or subtract, relative weight to the requirements expressed in relation to the seven variables.

Principal stakeholders at this layer include the Ethics Committee of a healthcare organisation. They are responsible for determining and maintaining the definition of ethical use for a specific organisation. The expression of this layer should be a form of matrix of ethical issues in relationship to the requirements and expectations of the various stakeholders. This would allow examining the concerns of the various stakeholders in relation to the requirements they have for the data contained in the CDW. The definition of this layer is likely the most complex from the point of view of the discipline of health informatics and from the usual technology mindset, but it is the most crucial, in our view, to the specificity of our risk management framework to the healthcare field. It requires the definition and modelisation of ethical issues.

The forth layer would is composed of the seven principal variables of risk:

      • Confidentiality;
      • Integrity;
      • Availability;
      • Origin of data;
      • Origin of access;
      • Access control; and
      • Non-repudiation

We believe that most issues related to IT security risk can be described in relation to these variables and, therefore, this dimension would give depth to the data, at the first layer. This layer could be viewed as a mapping of the data components into standard blocks. In an Object Oriented world, it could be viewed as adding seven risk attributes to HL7 data objects. At this layer the principal stakeholders are the IT and IT security practionner and the records management experts (Archival or medial records management).

The fifth layer would relate to the composition, or the decomposition, of the data source, represented in HL7 format. At the base of the framework we find the data components. Expressed in HL7 format, this provides a Healthcare specific interface between the data elements, in whatever form it is stored or communicated and the framework. Using HL7 format at this layer makes the risk management framework healthcare specific; it also provides some formalism that will be beneficial to the process as a whole.

[1] From http://www.coso.org/

[2] http://www.delcreo.com/delcreo/free/docs/COSO%20ERM%20Framework%20DelCreo%20Comments.pdf

[3] see http://www.ogc.gov.uk/sdtoolkit/reference/documentation/p47_riskframe.html , http://www.tbs-sct.gc.ca/rm-gr/home-accueil.asp

[4] ISO TC215 work group 4

[5] Do we need to talk about Nuremberg or Belmont ?