The Empty Box

Introduction:

We would like to propose a technique for allowing access control to the ‘empty box’ of the CDA based on user group defined roles. We intend this to complement the ‘Immunological Model of Access Control’ presented at the CDA conference in Berlin, October 2002. The model as stated then recognized the importance of local role sets, but did not detail just how a shared access process could deal with the proliferation of them which will occur. Our approach differs from that suggested by the authors of the latest proposal for RBAC suggested by ISO/TC215 N199 (dated May 2004). (1) We concur that

“..role assignments can show great variation from health care establishment to health care establishment, in granularity and hierarchical organisation”

However rather than require that their be detailed policy bridging and an inventory of roles before interoperability can occur, we propose that the way an institution or user defines its fine grain role structure can remain opaque to an outsider. Any registry which seeks to contain all the roles necessary to plot interoperability would expand exponentially with time, since there is literally no limit to task environments and changes in the division of labour which define roles.

We suggest that in the electronic era as in the paper based era, it should the ‘clinic’ or other healthcare institution that is the entity which has medico legally responsible for its own records and those it accesses from the regional servers.

The user role defined access process.

We suggest that a tripartite ‘division of data’ into ‘clinical’, ‘demographic’, and ‘administrative’ categories, complemented by a ‘secret’ category could provide a starter model for a global access system.

Fig 1 The CDA box.

To keep the generic ‘box’ truly empty, the purist might wish to re-label these compartments as ‘A’, ‘B’, ‘C’ and ‘D’. Our technique might still work. However to facilitate the implementation of an immediately applicable standard workable standard we will propose that the CDA is divided into four compartments which contain four base classes of data, each of which is sealed from the others for access privileges. If this is matched by three core Roles, ‘clinician’, ‘administrator’, ‘researcher’, and ‘self’ only access for the secret category, we have us far as the universal system need go in the design of a generic CDA body type, compliant with this access process.

However the realities of day to day business conducted in clinics and other medical institutions makes such clear cut division of labour rare. Within the boundaries of an institution there will be role hierarchies which are culture defined, and also defined by the day to day tasks performed. It is this ‘autopoitetic’ or ‘self defining’ character of real world institutions that we seek to capture and use for access control. [2]

Fig 2. The relationship between role, task, and model.

There is a three way relationship between the model of a process, the tasks derived from that model, and the roles which perform the tasks.

We make a distinction between ‘core Roles’, which are universal and correspond to a four compartment division of the CDA box, and user roles which are culture and institution specific. The institutional roles can change on a day to day basis. We propose that all sets of user roles are expressible by a combination of four variables which are universal to the technique proposed. These are:

1. need to know (defined by the task)2. core Role (for authentication)3. data grain range4. Role mix (including delegated Roles)

The task defines its own information requirements, or the ‘need to know’ required for enact ion of the task.. A clinic manager will allocate tasks to the individuals available, who have been authenticated in their core Roles, and have attribute certificates available for those roles. Attribute certificates also may contain delegation rights. A manager may need to delegate Role functions that the person who is to fulfil that role may not usually have, e.g. a member of the clerical staff may need to find clinical information on behalf of a clinician authorized by that clinician. Such a composite ‘role’ may be local to the institution, or even the search instance.

The degree to which roles conform to standard templates is a function of the size and organization of an institution. The devolution of responsibility for role definition to the distributed environment simply continues present paper based practices.The role key object is the product of the role filtering done by the search, and it is a composite of access constraints targeted at the distributed CDA data repository. It operates like a switch on the repository, finding opr not finding CDAs that it is targeting, as long as the core Role for access criteria are matched in the search. The ‘secret’ category we suggest is only accessed by the digital signature of the client/patient. There should be emergency access codes, but it will be a matter for

ROLE TASK

MODEL

acts ondefines

performs

each jurisdiction to decide if these over ride the secrecy made possible buy using the digital signature as an access code.

The Grain Filter.

The Hierarchical organization of knowledge means that the higher up a tree you go to access a node, the more information there is ‘downstream’. Grain range can usefully act as a filter. For example a high to medium grain partition will exclude fine grain details in a demographic knowledge base, which might protect name and address during a research exercise. Conversely, a grain filter which only lets through the fine grained detail might protect illegitimate browsing of other records in a similar category, i.e. the next node ‘up’ the tree.

Fig 3 the Grain Filter Access Window

For grain range to be useable in access control there must be some homogeneity of partitions as applied to different classes of data. There is a sort of theory that addresses this. From the perspective of the Theory of Granular Partitions (TGP), a partition consists of a network of cells and subcells, the latter being nestedwithin the former; the cells, in turn, are projected onto entities in reality or onto the cellsof other partitions…..Partitions are called ‘granular’ because they project onto reality in every case only at a certain level of granularity: [24] . Within a jurisdiction, there would normally be homogeneity in knowledge based hierarchies, but with wide use of a formal

ontology for knowledge hierarchies, useful grain filters might work across diverse domains.

CDA Compartment

The four compartment CDA box is diagrammed below:

Fig 4, The Four Compartment CDA

This can be considered both at the level of the CDA, and in the sense of compartments of the total CDA repository, constrained by other criteria. When a composite search is successful, CDA s containing appropriate data are mined from these virtual ‘compartments’, which can be grain filtered down to the individual CDA compartment, or only provide aggregated data from coarse grained categories such as geographical region or gross clinical entity e.g. ‘diabetes’.

*****insert animation sequence of CDAs crawling into their correct pots*****

The Role Key Object

The ‘Role Key’ Object is the final product of the search role filtering process which goes to the regional network to identify and hopefully retrieve the CDAs. Its place in the access process is illustrated in the class diagram for the process:Fig 5. The Search goes to the access control object in the requestor’s system which checks role and task, and role grain to construct a role request object. This is a compound object of the user’s digital certificate, attribute certificate, any delegated attribute certificates, public key, and search criteria.

What it establishes is a key/lock bind which liberates the CDA body information from its server(s) of origin, and transmits with dual key cryptography to the requestor. It deposits an entry in the audit log for the CDAs server of origin. Role key objects can be very diverse in their configuration, and reflect entirely local role sets. They act like a switch on the repository of access locks and DHOs . (Fig 6)

Fig 5 Class Diagram for the CDA access process

Fig.6 Generic access sequence diagram

Figure 6: An access lock/switch configuration for the CDA repository established by a search done by a role that has been locally defined. Configurations in this switch combined with core role match checks and ‘need to know’ defined by task may express any role.

The hierarchy of access roles and their rights within a realm or institutions are given different patterns of access consistent with the division of labour in that institution. The ‘filter window’ which is imposed on the data by the user’s system can be customized by the end user group to express any set of roles they like, and thus any division of labour in their work practices.

The ‘bar code’ for access rights to the different compartments would be a composite, determined by the local division of labour and role set within the participant institution. In the example, a clinician role can access all of the clinical, some of the demographic, and none of the financial information; an administrator role has rights in none of the clinical, all the demographic, and some of the financial information. An auditor role has rights to access all of the files in all of the compartments, in all of the CDAs. Clearly in this example some of the rights are redundant, but this would not invalidate the concept.

Access privileges defined in this way can apply both to single CDA, or a population of CDAs. The addition of the concept of a grain filter to constrain access to the 3

compartment CDA repository, along with core Role targeting and task based ‘need to know’ as constraints on access would give a very versatile constraint repertoire to express local role sets. Like the immunoglobulin molecule, the search of the CDA repository is allows configuration to an endless diversity of local role/tasks.

At the border:

Interoperability is assured because everything except local role is specified, and the switch opens compartments provided the key is valid. Cross border search where there has not been policy bridging and a role registry is achieved by proxy searches done at the portal of entry. It would need to be accepted that access control is lost when data is exported in this way, but this is inevitable and will usually be the least of the concerns of the communicating parties. but there would need to be informed consent for this – from the patient or other legitimated role in the host realm.

De identified data is simply achieved by simply not providing access codes for searches in the demographic compartment.

References:

[1] Health Informatics: Privelege Management and Access Control ISO/TC/215 N199 PDTS ISO22600-1 5.2.2. Roles p17[2] http://www.fact-index.com/f/fr/francisco_varela.html

“Revitalising Old Thoughts: Class diagrams in light of the early Wittgenstein” Christian Holmboe Department of Teacher Education and School Development University of Oslo, Norway christian.holmboe@ils.uio.noIn J. Kuljis, L. Baldwin & R. Scoble (Eds). Proc. PPIG 14 Pages 196-203 14th Workshop of the Psychology of Programming Interest Group, Brunel University, June 2002