Nakeisha Schimke

Mary Kuehler

John Hale

Preserving Privacy in Structural Neuroimages

Keywords: Medical image privacy, neuroimaging, de-identification, HIPAA

Evolving technology has enabled large-scale collaboration for neuroimaging data. For high resolution structural neuroimages, these data are inherently identifiable and must be given the same privacy considerations as facial photographs. To preserve privacy, identifiable metadata should be removed or replaced, and the voxel data de-identified to remove facial features by applying skull stripping or a defacing algorithm. The Quickshear Defacing method uses a convex hull to identify a plane that divides the volume into two parts, one containing facial features and another the brain volume, and removes the voxels on the facial features side. This method is an effective alternative to existing solutions and can provide reductions in running time.

Introduction

The digitization of health records and medical images has transformed healthcare and medical research. New technologies provide instant access to patient and subject data by automatically disseminating the information to healthcare providers and research collaborators. Expanded storage and transfer capabilities have made feasible the addition of medical images to these electronic records, but as the demand for capturing and storing images increases, so does the need for privacy measures. For shared data sets, the need for removing protected health information (PHI) is agreed upon, but the extent to which medical images constitute PHI is still debated.

The Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule [START_REF]HIPAA Administrative Simplification: Regulation Text[END_REF] defines "full face photographic images and any comparable images" as PHI. With respect to identifiability, high resolution structural magnetic resonance imaging (MRI) datasets are comparable to full face photographs, and volume rendering software is freely available. Fig. 1 is a volume rendering of a structural MRI using 3D Slicer [1], an open source software package for medical image analysis. The result is clearly identifiable as a human face.

The challenges of removing identifiable metadata are well documented, and there are numerous tools for automating the process. There are also formal models for privacy, such as k-anonymity [START_REF] Sweeney | k-anonymity: a model for protecting privacy[END_REF]. However, the inherent privacy risks of the neuroimages themselves is less well defined. The relative anonymity of subjects in structural MRI may be compromised by the image itself. This paper explores the potential privacy hazards associated with neuroimage datasets. It also proposes a new algorithm for image-based de-identification of neuroimages and evaluates its effectiveness and performance.

Background

Large scale collaborative research efforts have the potential to transform neuroscience. The Alzheimer's Disease Neuroimaging Initiative (ADNI) [START_REF]ADNI: Alzheimer's Disease Neuroimaging Initiative[END_REF] is a multisite collaborative research project that has collected images from over 40 sites and distributed data to more than 1,300 investigators to date [START_REF] Kolata | Rare Sharing of Data Leads to Progress on Alzheimers[END_REF][START_REF] Mueller | Ways toward an early diagnosis in Alzheimer's disease: The Alzheimer's Disease Neuroimaging Initiative (ADNI)[END_REF]. Its success has inspired similar initiatives for other diseases.

There are, however, obstacles to neuroimage data sharing that hamper collaboration. Solutions to technical challenges, including data storage, transmission, management, and dissemination, continue to evolve. The task of maintaining subject privacy while disseminating data has made significant progress. Metadata removal is routinely integrated into the scientific workflow. However, the determination of when and how to apply de-identification to the neuroimage itself has yet to be made. The benefits of sharing neuroimaging data are clear, but pressing concerns over subject privacy must first be addressed.

The terms anonymization and de-identification are often used interchangeably, but their subtle differences are significant to subject privacy. The core idea mechanism for patient privacy relies on obscuring the subject's identity by hiding medical and personal data, often applied to meet the de-identification requirements of HIPAA. A dataset de-identified under the HIPAA Privacy Rule can be distributed and used. HIPAA designates eighteen identifiers as PHI, including "full face photographic images and any comparable images" [START_REF]HIPAA Administrative Simplification: Regulation Text[END_REF].

Anonymization is not as clearly defined. True anonymity would prevent a dataset from ever being re-identified but is difficult to achieve while retaining useful data [START_REF] Ohm | Broken promises of privacy: Responding to the surprising failure of anonymization[END_REF]. Neuroimaging studies often require metadata such as gender and age for analysis, and removing these could negatively impact results. Practical anonymity inhabits a grey area between true anonymity and an acceptable yet undefined limit to the possibility of re-identification.

The need for re-evaluation of PHI is evident when a few pieces of seemingly innocuous data can be re-linked to identify a subject. Medical images belong to a class of health data that is inherently self identifying and laden with contextual information about the subject, their condition, treatment, and medical and personal history. The privacy issues associated with the storage and use of medical images warrant special consideration, and the current approaches of simply removing metadata may be insufficient.

Privacy Issues in Medical Images

While textual data can be redacted by simply removing or replacing the offending field, the image, which can constitute self identifying data, is not so easily sanitized. Removing identifying features in medical images may destroy the very information a researcher needs. The primary threats to subject privacy from medical images are listed in Table 1. A direct threat occurs when the image reveals a condition or other private information, but a more likely scenario is re-linkage, where the image is used to identify the subject along with metadata. The existence of a medical image or participation in a study may also suggest the presence of a condition, perhaps incorrectly. Neuroimages are particularly challenging because they are inherently identifiable. High resolution neuroimages contain detailed facial features that can be used to re-identify the subject. The neuroimage could be used to discover an identity from a large database of faces or to confirm a subject's identity.

Neuroimage Re-identification

There are many potential avenues for re-identifying a subject using their neuroimage. Re-identification occurs in two phases, reconstruction and recognition.

The reconstruction phase produces a likeness of the subject to be used in the recognition phase for discovering the subject's identity.

In forensic science, facial reconstruction requires a blend of artistic and scientific skills to reproduce a likeness of the subject. Reconstruction is more straightforward using structural MRI because of the high spatial resolution. Several packages for analyzing neuroimage data provide built-in volume rendering capabilities, including AFNI [START_REF] Afni | [END_REF], 3D Slicer [1], and MRIcron [START_REF] Rorden | MRIcron[END_REF]. Typical volume rendering software offers the ability to change lighting conditions and viewing angles. These features can be used to match rendered volumes against photographic facial images.

Facial recognition can be applied using a variety of techniques to achieve novel identification, attempting to discover an identity, or identity confirmation. Metadata can be used to guide a facial recognition search, narrowing down the potential subjects using basic non-PHI fields such as gender and age. The current limitations and relatively poor performance of facial recognition techniques make it tempting to dismiss the potential for re-identification based on flawed assumptions: (1) facial recognition will never improve, and (2) only correct identifications are problematic. The latter fails to consider the damage caused by incorrect identification. Challenging a false re-identification may require the individual to reveal their records.

The problems plaguing facial recognition techniques are not easily confronted, but researchers in the field are making progress. Facial recognition techniques are detailed with links to recent advances at the Face Recognition Homepage [START_REF] Grgic | Face recognition homepage[END_REF]. A NIST report on face recognition illustrates significant improvements in the field [START_REF] Grother | Report on the evaluation of 2D stillimage face recognition algorithms[END_REF].

Hardware advances can also improve the results of facial recognition. Increased storage capacity and computing power allow higher quality images to be stored and compared more quickly. Facial recognition software struggles when viewing angles and lighting vary [START_REF] Zhao | Face recognition: A literature survey[END_REF], but volume rendering software can generate multiple images with a wide range of light sources and angles to match source photographs. Therefore, if neuroimage-based recognition can perform with comparable results, they must be offered the same protection.

Neuroimage De-identification

There are two common approaches to de-identifying neuroimages, skull stripping and defacing. Skull stripping is the identification and removal of non-brain tissue as part of the typical analysis workflow. It has many benefits, including improved registration between images, removal of acquisition artifacts [START_REF] Smith | Fast robust automated brain extraction[END_REF], and de-identification by removing facial features.

There are several methods for skull stripping, and many are integrated with widely used neuroimage analysis software [START_REF] Afni | [END_REF][START_REF]BET -Brain Extraction Tool[END_REF]9,[START_REF] Smith | Fast robust automated brain extraction[END_REF][START_REF]FreeSurfer[END_REF][START_REF] Ségonne | A hybrid approach to the skull stripping problem in MRI[END_REF]. Several skull stripping methods are compared and analyzed in detail in [START_REF] Fennema-Notestine | Quantitative evaluation of automated skullstripping methods applied to contemporary and legacy images: Effects of diagnosis, bias correction, and slice location[END_REF]. Skull stripping methods are highly sensitive to parameters, which may often result into loss of desirable brain tissue. The results may also vary between methods and can require manual correction. Differences in data sets may impact further analysis, such as segmentation. Skull stripping may also favor a particular region based on the particular study [START_REF] Bischoff-Grethe | A technique for the deidentification of structural brain MR images[END_REF]. This complicates meta-analysis, data re-use, and collaboration by discarding potentially relevant voxels.

Unlike skull stripping, defacing techniques [START_REF] Bischoff-Grethe | A technique for the deidentification of structural brain MR images[END_REF] preserve non-brain tissue. The MRI Defacer approach removes only voxels with zero probability of containing brain tissue and non-zero probability of containing facial features using a manually labeled face atlas. The result appears as though the facial features were eroded, leaving the brain volume intact.

It is tempting to de-identify with skull stripping since it is part of analysis, but defacing techniques allow for more flexibility. Simply skull stripping an image may discard useful data. Defacing is an effective method for removing facial features, and it does not interfere with subsequent analysis. MRI Defacer relies on a face atlas to identify features, which may not apply well to all datasets.

Quickshear Defacing

Quickshear Defacing is a new technique for removing facial features from structural MRI. The primary objective is to provide an efficient and effective defacing mechanism that does not rely on external atlases. It uses a binary mask to identify the brain area to protect, as illustrated in Fig. 2. It identifies a plane that divides the volume into two parts: one containing the brain volume and another containing facial features. The voxels that fall into the latter volume F are removed, leaving the brain volume B untouched. Removing all facial features is not necessary to de-identify the image, and the subject's identity can sufficiently be obscured by removing the primary features (eyes, nose, mouth). The brain mask is created using a skull stripping technique, with the flexibility to use an existing skull stripped volume. Non-brain tissues such as cerebrospinal fluid and the optic nerve, among others, are often problematic for skull stripping techniques, which aim to include only brain tissue. Quickshear, however, does not need to fully distinguish between brain and non-brain tissue. To reduce complexity and simplify the process, a flattened, two-dimensional sagittal view of the brain is considered. The edge mask is used to find the convex hull. By definition, the convex hull of the brain will form a polygon so that all brain voxels are either on the boundary or inside.

Andrew's monotone chain algorithm is used to find the convex hull [START_REF] Andrew | Another efficient algorithm for conex hulls in two dimensions[END_REF], The algorithm sorts the points lexicographically and finds the lower and upper halves of the hull. Selecting the leftmost point (x 0 , y 0 )1 and the adjacent point (x 1 , y 1 ) on the hull ensures that all of the brain voxels are contained in the remaining portion of the hull.

The three-dimensional defacing mask is created by discarding all voxels that lie below the line formed by the points defined by

w j = y 1 -y 0 x 1 -x 0 (j -x 0 ) + y 0 -b . (1)
The value of b specifies a buffer to ensure preservation of the brain volume by shifting the line by -b values in the j direction. The methods were tested with the Multimodal Reproducibility Study data set from Landman, et al., using MPRAGE scans with a 1.0x1.0x1.2 mm 3 resolution. Acquisition is detailed in [START_REF] Landman | Multi-parametric neuroimaging reproducibility: A 3T resource study[END_REF]. The data set contains 42 images from 21 health subjects. Defacing was performed on Ubuntu 10.10 running in VirtualBox on an Intel i7-2600k with 2GB RAM. Running time is shown in Table 2 as an average per image, averaged over five runs. By design, Quickshear Defacing should not remove any voxels identified as brain by the binary mask it is given. This is a basic sanity check, where the defaced volume is compared voxelwise with the brain mask identified by each of three skull stripping techniques (AFNI 3dSkullStrip, FSL BET, and FreeSurfer HWA). On average, Quickshear Defacing discarded fewer brain voxels from fewer images than MRI Defacer.

Volume rendering was applied using MRIcron [START_REF] Rorden | MRIcron[END_REF] to the resulting defaced images and passed through the OpenCV Haar classifier [START_REF]OpenCV[END_REF] to detect faces. For Quickshear, 12 of 42 images were classified as containing a face, and for MRI Defacer, 9 of 12 contained faces. Quickshear tended to leave behind features such as the eye sockets and nasal cavity that may be triggering a false positive. Upon visual inspection, defacing appeared adequate using both methods. MRI Defacer left behind extreme features like the nose in some cases.

Conclusions

While the practical and effective discussion concerning privacy in structural neuroimages continues, there are effective measures that can be taken immediately to improve subject privacy. Adopting such measures to protect both metadata and pixel data can increase the flow of data both internal and external to research organizations and encourage collaboration. Metadata can be removed using existing anonymizing tools, such as the LONI De-identification Debabelet [START_REF] Neu | The LONI Debabeler: a mediator for neuroimaging software[END_REF] and DICOMBrowser [START_REF]DICOM Browser[END_REF]. To remove pixel data, skull stripping or one of the defacing algorithms is recommended. Skull stripping is an effective method for removing facial features, but it may discard desirable tissue. If reproducibility and peer review are the motivations for data sharing, skull stripping may be sufficient and can save time if it is part of the workflow. For data reuse, a defacing approach such as the one presented in this paper may be preferred.

Quickshear Defacing uses a two-dimensional view of the data to create a convex hull, which identifies a plane that divides the volume into two parts, one containing the entire brain and the other facial features. By removing all voxels on the face side, the image data is de-identified.

Quickshear Defacing preserves more brain voxels in more images than MRI Defacer. After MRI Defacer, fewer volumes were identified as containing faces by the Haar classifier. Visual inspection of both techniques showed that the remaining volumes were unlikely to be identified.

Further tests on the data should be applied to determine the effects of the new defacing technique proposed in this paper on further skull stripping. Additionally, implementing other techniques in addition to the Haar classifier to verify the removal of facial features may illuminate the performance of both defacing methods.

Fig. 1 .

 1 Fig. 1. Volume rendering using 3D Slicer. Sample MRI data is from 3D Slicer.

Fig. 2 .

 2 Fig. 2. Quickshear Defacing illustrated (left). Sample slice (middle) and volume rendering (right) after defacing.

Table 1 .

 1 Threats to subject privacy from medical images.

	Type	Description	Example
	Direct	Reveals a condition	X-ray reveals fractured wrist
	Re-linkage	Metadata reveals identity	Metadata includes gender, age, and
			zip code and tied back to patient
	Existential	Image known to exist	Subject in imaging study assumed
	Inference		to be a case rather than control
	Identification Inherently identifiable	Facial features identify subject

Table 2 .

 2 Performance for defacing per image of sample data set, averaged over five runs.

	Method	Skull Stripping	Defacing
		Time (s)	Time (s)
	MRI Defacer	-	260.17
	Quickshear	205.71	4.30

Table 3 .

 3 Average number of brain voxels discarded for each defacing mechanism (Number of images with voxels discarded).

			Brain Mask
	Defacing Method	AFNI	BET	HWA
	MRI Defacer	408.74 (12)	75271.93 (42)	422.0 (7)
	Quickshear	0.0 (0)	5560.76 (13)	0.0 (0)

The leftmost point is chosen as the starting point based on a space where +x-axis is the inferior to superior (front to back).

Acknowledgments

We gratefully acknowledge support from the William K. Warren Foundation.


S Berhe

S Demurjian

S Gokhale

J Pavlich-Mariscal

R Saripalle

Leveraging UML for Security Engineering and Enforcement in a Collaboration on Duty and Adaptive Workflow Model that Extends NIST RBAC

To facilitate collaboration in the patient-centered medical home (PCMH), our prior work extended the NIST role-based access control (RBAC) model to yield a formal collaboration on duty and adaptive workflow (COD/AWF) model. The next logical step is to place this work into the context of an integrated software process for security engineering from design through enforcement. Towards this goal, we promote a secure software engineering process that leverages an extended unified modeling language (UML) to visualize COD/AWF policies to achieve a solution that separates concerns while still providing the means to securely engineer dynamic collaborations for applications such as the PCMH. Once defined, these collaboration UML diagrams can be utilized to generate the corresponding aspect oriented policy code upon which the enforcement mechanism can be applied to at runtime.

Introduction and Motivation

Over the last five years there has been a dramatic shift towards collaborative computing in multiple domains. One such application domain is the patientcentered medical home (PCMH) where a primary physician coordinates care for a patient across a range of providers, who all must interact with one another across distance and time [1]. Our prior work in this regard has been a formal model for obligated collaboration on duty and adaptive workflow (COD/AWF) [START_REF] Berhe | Emerging Trends in Health Care Delivery: Towards Collaborative Security for NIST RBAC[END_REF] that extends the National Institute of Standards and Technology (NIST) Role-Based Access Control (RBAC) model [START_REF] Sandhu | The NIST Model for Role Based Access Control: Toward a Unified Standard[END_REF]. This COD/AWF model adds capabilities to NIST RBAC that include: secure collaboration to control access to data; obligated collaboration which denotes individuals that must participate and how they interact; team-based collaboration, which defines the collaboration with multiple individuals; and coordinated collaboration, which characterizes the way that individuals are allowed to interact with one another. These four components are grouped together into the following definition: Def. 1 COD = [COD ID , COD N AM E , T EAM, CODC, P, CW] is a uniquely COD ID named collaboration COD N AM E with a team of role types T EAM, a set of collaboration constraints CODC, a set of permissions P, and a collaboration workflow CW composed out of collaboration steps. The next logical step is to explore its integration into a software process that includes security engineering from design through enforcement. Towards this goal, we promote security engineering that leverages an extended unified modeling language (UML) to visualize COD/AWF policies to separate concerns while still providing the means to securely engineer collaborations for applications such as the PCMH. Defining collaborative security for PCMH will require role teams, obligations, collaboration steps, and workflows, resulting in requirements that are tangled with one another. The contribution of this work is two-fold, first we propose a set of new UML slice diagrams for COD/AWF that extends prior work on UML with roles, delegation, and user authorization diagrams [START_REF] Pavlich-Mariscal | A framework of composable access control features: Preserving separation of access control concerns from models to code[END_REF]. Second, these COD/AWF diagrams will be utilized to generate the corresponding policy code upon which the enforcement mechanism can be applied to. There has been a myriad of related work with regard to UML and access control and workflows [START_REF] Bertino | The Specification and Enforcement of Authorization Constraints in Workflow Management Systems[END_REF][START_REF] D'amour | A model and typology of collaboration between professionals in healthcare organizations[END_REF][START_REF] Juerjens | Secure Systems Development with UML[END_REF][START_REF] Pavlich-Mariscal | A framework of composable access control features: Preserving separation of access control concerns from models to code[END_REF][START_REF] Sun | Flexible Workflow Incorporated with RBAC[END_REF][START_REF] Thomas | Team-based access control (TMAC): a primitive for applying rolebased access controls in collaborative environments[END_REF][START_REF] Zarnett | Role-based access control (RBAC) in Java via proxy objects using annotations[END_REF], however none of it considers an integrated Collaboration on Duty (COD) approach which integrates the four components (Obligation, Access Control, Workflow and Teams) into a single formal model. Moreover, to the best of our knowledge no MDA-based approach has been done which extends UML with the four components facilitating separation of concerns and generating COD policy code. The remainder of this paper contains three sections. Section 2 introduces an approach for security engineering of COD/AWF with UML and proposed extensions. Section 3 presents the code templates that are collected together followed by concluding remarks in section 4.

Security Engineering of COD/AWF with UML

This section proposes four new UML diagrams that are utilized to constrain and define permissions associated with collaboration, namely: the positive and negative role slice diagrams and the team slice diagram in Section 2.1; the obligation slice diagram and the collaboration workflow slice diagram in Section 2.2. By differentiating between these four diagrams, we essentially separate the concerns to allow the different aspects of permissions to be characterized in different diagrams as illustrated in Figure 1.

UML Role and Team Slice Diagram

The role slice diagram in Fig. 1a defines permissions [START_REF] Centonze | Role-Based access control consistency validation[END_REF] sion getBillingHistory and getAppointmentHistory. During the collaboration, all activated permissions must be a subset of P (Def. 1), which is modeled using << RoleInheritance >> stereotype, such that the assigned P to the collaboration workflow (CW) is represented as the root role slice (Fig. 1c). This CW type is tracked through the use of UML tagged values (Type="CW" and Type="CS"). It's used to match role slices with the corresponding CW, CSs, and roles in the remaining slices (Figs. 1a, 1b, and 1d). All collaboration steps that are activities in the CW are only allowed to activate a subset of P. The current inheritance semantics allows adding additional positive permissions to any role slice [START_REF] Pavlich-Mariscal | A framework of composable access control features: Preserving separation of access control concerns from models to code[END_REF].

Our objective is to capture COD role slice inheritance semantics in which CSs are only permitted to activate the set of permissions which is not specified as negative and is present in the parent role slice [START_REF] Budd | An Introduction to Object-Oriented Programming[END_REF]. To enforce this semantic, we extend this notion of role slice with two new annotations: << P osRoleSlice >> which only allows the specification of positive permissions and is used in the root role slice to set the scope of allowed privileges throughout the collaboration; and, << N egRoleSlice >> which only allows the specification of negative permissions which is utilized to further restrict privileges in a particular collaboration step (CS).

The team slice diagram in Fig. 1a depicts a separate concern to capture permissions for the entire team. In the ERC example, each team contains the specific role slices that are needed; the latter is inclusive of all roles (entire team of four roles), the former limited to roles within a step. Using the sub-set << T eamSubset >> relationship for the team slice diagram, the root slice represents T EAM (Def. 1) and all CSs subset team members from this root team slice. A team slice is depicted as a UML package with the stereotype << T eamSlice >>. This package contains a set of role slices. Permissions are not specified -they are given in the role slice diagram in Fig. 1c -and the focus for team slices is to specify the participants of each step. For permission activation, team membership allows a role to be authorized to permissions.

UML New Obligation and Workflow Slice Diagram

The obligation slice diagram in Fig. 1b defines the set of permissions that are required to be activated and roles that must participate. These complement RBAC constraints and model the obligation requirement (who is allowed to perform which method at which time) [START_REF] Li | On mutually exclusive roles and separation-ofduty[END_REF]. In Fig. 1b, for the ERC team, a physician is a role that is obligated to participate. For example, during "Triage" CS, the physician must participate. In COD/AWF, obligated participation implies that a role must activate at least one of its permissions. With regard to obligated permission activation, getMedHistory must be activated before the collaboration terminates. The obligated activation of a permission requires its activation of any authorized role in the collaboration before it can terminate. Permissions from Fig. 1c are used to constrain the role slice elements within the obligation slice. Permission activation requirements are modeled as classes along with their obligated permissions that are elements of the obligation slice marked using the << obl >> stereotype. Similar to the team slices, the root obligation slice represents the set of obligations that must be activated during the entire collaboration, while each collaboration step only must fulfill a subset of it. This is depicted using the << ObligationSubset >> stereotype.

The collaboration workflow diagram leverages and extends the UML activity diagram and allows the security engineer to focus only on the design of the healthcare coordination requirements. In Fig. 1d, the ERC package is composed of 7 collaboration steps into a workflow. The annotation << CwSlice >> is in charge of matching the collaboration steps in the other COD slices with the corresponding collaboration workflow CW (Def. 1). Access control, obligation and team requirements are unified in this diagram by essentially linking across the four diagrams (1a-1d); while the concerns are separate, they are tied with one another though naming convention and are linked through the unique identifier where matching CS identifiers are located in the previous three slices.

Mapping to Enforcement Policies for COD/AWF

Section 2 visually specified COD/AWF via extended UML, and using that as a basis, this section explores the generation of enforcement code that exactly meets the COD/AWF requirements as defined in the UML slices (see Fig. 1a to 1d). Specifically, this section presents the mapping of the four new/extended COD/AWF UML diagrams to a policy code-based model, which are interfaces/ templates from which actual collaboration domain application can then be enforced at runtime. Accompanying these policy code templates is an authorization enforcement algorithm which checks if a user in a particular collaboration is permitted to activate a permission in a workflow at a particular step (not shown). Our intent in this section is to demonstrate the generated policy code model (templates) for the example as given in Section 2. Note that the COD/AWL UML new/extended diagrams and the code model are extensions to the formal UML Class meta model (not shown) [START_REF] Teilans | A Meta-Model Based Approach to UML Modelling[END_REF]. Finally, this work uses Java-like code templates to illustrate the code mapping of the COD/AWL diagrams.

The remainder of this section is organized as follows. Section 3.1 presents the code template for the role slice and the team slice diagram. Section 3.2 details the code template for the obligation slice and the collaboration workflow slice diagram.

Policy Code Template for the Role and Team Slice Diagram

The negative and positive role slices allow us to define the set of allowable permissions during the Emergency Room Collaboration (ERC) at the root slice node.

In this context, we utilize role slices to define the specific privileges that are associated with the ERC and each of its collaboration steps (e.g. Triage, Admission, etc.). The permissions assigned to the collaboration step/workflow are specified as interfaces which can be implemented by specific classes (e.g. Triage interface can be implemented for an ERTriage or RegularTriage class); this is shown by the code template a) for the slice of Fig. 1c. This allows this COD/AWF framework to be generic enough to adapt to the particular sub-domain (e.g., CDC, Hospital, Clinic, Family Practice, etc.). We utilize the ElectronicMedicalRecord (EMR) class to specify all of the privileges that can be performed against this patients' clinical data. The annotations @PosRoleSlice and @NegRoleSlice are applied to interfaces and enforce sub-interfaces to only specify positive (@pos) or negative (@neg) permissions. This requirement can be verified at runtime using meta programming. In this example, every class that implements the Triage collaboration step interface in the context of ERC is not allowed to activate both permissions getBillingHistory but only getMedHistory (see Code Template b).

Policy Code Template a)

Policy Code Template b) @PosRoleSlice @NegRoleSlice public interface ERC{ public interface Triage ext ERC{ public interface EMR { public interface EMR { @pos getMedHistory(); @neg getBillingHistory(); @pos getBillingHistory(); } } } }

In the code template for the collaboration team slice diagram, the root team slice specifies the entire team (from Triage to Admission/Discharge); this is shown by the code template c) for the slice of Fig. 1a. Each team is marked using the @TmSlice annotation. A particular collaboration step further restricts the participation of roles depending on the context using the subset relationship. In the policy code, this relationship is expressed through the @TmSubset annotation. Both annotations can only be applied to interface, which allows the specification of generic teams which can be customized in a particular domain through specific implementation. In this example, the ERC team is composed out of all roles depicted in Fig. 1a. During the Triage collaboration step, only users with the Physician is allowed to participate (policy code template d); all other roles are prohibited to participate in this collaboration step. Fig. 1a only contains a partial representation of who can participate in which steps; for a full collaboration, the diagram would have additional TeamSlice definitions for all collaboration steps.

Policy Code Template c)

Policy Code Template d) @TmSlice @TmSlice public interface ERC{ @TmSubset(name=TmSlice, val=ERC) public interface Roles { public interface Triage { public interface Nurse(); public interface Roles { public interface Physician(); public interface Physician(); } } } }

Policy Code Template for the Obligation and Workflow Slice Diagram

The obligation slice policy defines the permissions that must be activated and roles that must participate during a particular collaboration step. The root node defines the obligations that can be specified throughout the ERC collaboration workflow; this is shown by the code template e) for the slice of Fig. 1b. This is denoted using the @CodcSlice annotation. The @CodcSubest annotation further subsets the obligation requirements for a child collaboration step. All of the required roles and permissions are marked using @obl annotation. For example, during the Triage step (policy code template f), it is required to review the patients' medication history but not to read the billing. In terms of participation, Triage requires the Physician to participate. Again, the policy code templates e) and f) only presents a partial definition of the obligation slices. The final part of the COD/AWF policies specifies all of the collaboration steps and the order in which they must be activated. The << CollabSlice >> marks an interface as a collaboration step and the << N extCollabSlice >> states the subsequent collaboration steps; this is shown by the code template g) for the slice of Fig. 1d. The ERC interface name along with its collaboration step names are utilized to link them to the code as given in Figs. 1a-1c. The collaboration workflow is annotated using @CollabWorkflowSlice, and each of its collaboration steps with @CollabSlice. Moreover, each collaboration step contains the information about the subsequent collaboration steps using @NextCollabSlice. Again, the code template g) only shows the first two steps of the collaboration in Fig. 1d; the full code template would have all of the steps and represent the entire needed workflow for each collaboration.

Policy Code Template g) @CollabWorkflowSlice public interface ERC{ @CollabSlice @NextCS(name=CollabSlice value="Test, Admission, Discharge") public interface Triage(); @CollabSlice @NextCS(name=CollabSlice value="TestReview, Admission, Discharge") public interface Test(); }

Conclusion

Collaboration applications such as the patient-centered medical home (PCMH) require individuals to interact with one another towards a common goal (treat a patient) across time and under certain limitations; such applications must provide a means to facilitate access and interaction across a sophisticated workflow that is adaptable. The work reported herein extends our prior work on adding collaboration on duty and adaptive workflow (COD/AWF) to NIST RBAC by considering security engineering for collaborative applications that can leverage existing, extended, and new UML diagrams, thereby elevating security to a first class citizen in an integrated software process. Towards this objective, the paper: proposed four new collaboration diagrams that extend and augment UML to separate concerns for the COD/AWF model in Section 2; presented policy code templates a-g for the four new UML diagrams (Fig. 1a-d) of Section 2. Overall, we believe this work is a crucial step forward for both collaborative security and security engineering, particularly in applications like PCMH.

  Fig. 1. COD UML Slice Diagrams.