Access Control Models Versus Collaboration Support

The TMAC family and TRBAC offer two very different approaches to extending RBAC to in-clude a team component, and each of these approaches has similarities and differences to the

5.6 Conclusion 85

approach proposed here⁵. TMAC and its related models have an architecture similar to VOICE, but define system entities, such as teams, in a very different way. TMAC is disease, rather than patient-centric, and is not designed with flexibility in mind. In contrast, TRBAC is structurally very different from the VOICE model, but is more closely related conceptually. TRBAC is patient-centric and designed to be highly flexible (see Table 5.3). Despite these similarities, however, none of the access control models are appropriate for meeting the requirements consi-dered here. First, each of these models, by definition, aims to control or restrict access to system objects, which is not the aim of this research. Second, each of the models includes complexity which is necessary to support access restrictions, but which is not necessary to support team work. Finally, none of the models presented here convincingly provide the level of pro-active support and ease of information access necessary to meet the defined requirements.

So, although certain aspects of the VOICE conceptual model appear similar to approaches em-ployed in access control approaches, the objectives of our model are very different and, as a result, our model provides significantly different outcomes than the various access control mo-dels. Here, we use policies and teams to increase team members’ awareness of organisational information and to support communication and coordination within collaborative teams. Be-cause we are focused on improving awareness, the model presented here is simpler and more flexible and does not require the extra variables necessary to support access control. Additio-nally, the model presented here is able to support a range of functionality that goes beyond information access.

Model Focus Team Structure Evolvability Policies Access Aims

VOICE patient-centric Flexible High yes Organise

TMAC family disease-centric Pre-defined Low No Restrict

TRBAC patient-centric Flexible Very High No Control

Table 5.3: VOICE versus TMAC and TRBAC.

5.6 Conclusion

The move to a patient-centric approach in healthcare has led to a shift in working practices and, consequently, a change in the requirements for healthcare information systems. Traditional models of patient-centric work, however, emphasise only one aspect of this new way of working,

5It is worth noting that the authors of both TMAC and C-TMAC present their work as general models applicable across domains, but in both cases healthcare teams are used as an explicit example of an application for which their model would be suitable. TMAC04 and TRBAC, however, are presented as business oriented models, and their authors make no comment on suitability of these models to healthcare teams.

86 5.6 Conclusion

focusing either on clinicians as team members or on the interaction between clinicians and the patient record system. Here, a conceptual model is proposed that incorporates both aspects of patient-centric care teams- the care team as a distributed team that must work together and the information systems that support this distributed work. By considering both the human and technical aspects of the problem, a conceptual model has been developed that attempts to address the unique needs of patient-centric care teams. Specifically, this model supports efficient information access and exchange and pro-active, individualised access and support for care team members within the context of an integrated EPR.

At the highest level, the conceptual model proposed here incorporates two main ideas. First, the model identifies care teams as key objects within the system, and stores and tracks Team data as a means to provide appropriate support for care team members. Identifying and tracking care teams involves creating Teams as system objects and associating Users with patient care Teams.

As in RBAC, Users are also associated with Roles. However, in contrast to RBAC, the associa-tion between Users, Teams, and Roles here is a compound one - each User is assigned one or more Roles per care Team and Users are associated with Roles only through care Teams, rather than having a direct association between Users and Roles which restricts the Roles to which a User can be assigned. Second, to provide pro-active support for team members, the model incorporates system actions in the form of Policies. Policies define automatic system actions by specifying when action should be taken, what action to take, and to whom (in terms of Role), the action should be applied. Combining Policies with care Teams allows for system actions to be carried out at the individual User level. By incorporating the concepts of providing sup-port to users through the context of care teams and providing automated system actions through Policies, the model provides individualised patient record views to team members, supports information exchange, and provides individualised, automated communications pro-actively.

Because the model proposed here constitutes an extension of the RBAC access control model, it has similarities to other access control models, in particular the TMAC model and its extensions and the TRBAC model. However, the main aim of our model is not that of access control or restriction. As a result, the functionality provided by this model is very different from that provided by the access control models. Additionally, the access control models add complexity which is not needed to meet the requirements driving this research.

87

Chapter 6

Implementation

Overview

Chapter 3 identifies several high and low level requirements for future healthcare information systems to support practitioners working in collaborative care teams and Chapter 5 presents a conceptual model aimed at meeting some of those requirements. As part of the evolutionary development approach adopted for this research and in order to consider the remaining require-ments, a proof of concept prototype was also developed. This chapter discusses the prototype and its contribution to the research. Chapter 7 then covers the project evaluation, including the role of the prototype in the evaluation.