Patricia Mactaggart
email: patricia.mactaggart@gwumc.edu

Stephanie Fiore
email: stephanie.fiore@gwumc.edu

HEALTH CARE REFORM AND THE INTERNET

Keywords: Health Information Technology (health IT) Health Information Exchange (HIE), Health Insurance Exchange (HIE), privacy of protected health information (PHI), security

U. S. health care delivery and administration systems have undergone transformations that create an evolving demand for health information technology (health IT) infrastructure. The successes of both U.S. Health Care reform and the use of the Internet for Health Information Technology (health IT) rely on consumer/patient "trust" that information will remain private and secure and recognizing the interdependence of policy choices. Each decision is a balance between ease of use, privacy and security concerns of consumers/patients, practicality, costs and political will. Currently, U.S. stakeholders ranging from the federal government to private companies are working collaboratively to structure this balance. The U.S. opportunities and challenges of implementing a complete health IT picture in our current Health Reform and legal environment provides experiences for other countries to consider as health IT continues to develop internationally.

I. Introduction

Health care delivery and administration systems are undergoing transformations that are dependent on and creating an expansive demand for health information technology (health IT). These transformations include monitoring diseases and health related activities at an individual and population level, coordinating care across providers and specialties, treating patients outside of the traditional face-to-face encounters, and tracking patient data through secure and reliable systems. In addition, consumers and providers expect access to real time information at the point of clinical care. Administratively, payment and data collection methodologies demand consideration of various insurance coverage types, demographics, use of quality metrics and reporting, and the use of performance incentives.

The use of the Internet and broad adoption of health IT is growing at various rates across the U.S. and other countries, and there is a need to establish international standards and guidance. Decisions must be made balancing ease of use, privacy and security concerns of consumers/patients, practicality, costs and political will. The overall goal is determining the safest, most efficient methods for health IT implementation within an appropriate legal framework specific to each country, while also developing and adhering to standards that can be applied nationally as well as internationally.

II. Background

Health Information Technology "tools" help providers, consumers, vendors and stakeholders achieve efficient care and service delivery. Consistency and collaboration in policy development and implementation for use between regulatory agencies, participants (physicians, other providers and patients), and stakeholders is necessary to fully utilize the Internet and health IT to reach the U.S national goals of better health, better care and lower costs. i One of the first steps is for patients and providers to understand the terminology of the changing health IT environment. Every day, new terms and acronyms are created in the U.S. alone, and their meanings change over time. For example, in the U. S., electronic health records (EHRs) go across health organizations, while electronic medical records (EMRs) are within one medical facility. More importantly, U.S. providers receive "meaningful use" incentive payments for appropriate functional use of certified EHRs, but not EMRs. The national legal basis for much of U.S. Health Care Reform can be found in the American Recovery and Reinvestment Act ii (ARRA) and the Affordable Care Act iii (ACA). Each Act created a HIE, but the HIEs are not the same. ARRA HIEs are Health Information Exchanges with a focus on clinical information, while ACA HIEs are Health Insurance Exchanges with a focus on coverage, or payment system, Exchanges. Both use the internet and require a secure infrastructure. Both are consumer centric; however, they are not the same.

Next, it is important that patients and providers acknowledge that use of the Internet expands faster and safer movement of data, but also magnifies potential risks. Health data protection can be enhanced through encryption, role-based access and authentication when appropriately applied. In the U.S. and other countries, electronic health (ehealth) information, absent of privacy and security safeguards, is at risk of disclosure through human error such as laptop thefts and inadvertent data posting on the Internet, disregard of personal information, and breaches. Additional internet challenges include cloud computing and mobile devices that collect PHI, such as smart phones, tabulate computers, laptops, and PDAs. Many devices and systems have security capability, but with an emergent system and security rules, these options are not adequately pursued. The potential impact of privacy and security breaches not only involves invasion of privacy and finances, but also the risk of flawed medical decisions with life threatening results.

In response, security countermeasures to minimize and hopefully avoid risks are being implemented at various levels in U.S. systems and standards. They include physical access controls (locks on doors and computers), administrative controls (security and privacy training, authorization, and auditing) to technical controls (use of authentication, encryption and firewalls). (See Figure 1). The security process must address all the countermeasures and allow for cross-checks. At a granular level, systems must reason if an individual seeking access is permitted to view data, and if not, what is the procedure to ensure access if denied? In the internet environment, how does the system validate that the individual is the individual he/she indicates he/she is? If the individual is authorized to receive demographic data but not clinical, what are the policies and procedures in place to assure how authorization is granted and overseen? Since the data is transported, how does it remain secure during transport as well as at rest? And lastly, what is the audit trail and who is responsible for managing the process?

III. Privacy and Security Themes

As expected with any field dealing with consumer's personal information, there are numerous policy and operational issues related to privacy and security in health IT. Some concerns are based on perceptions and others on reality, but to the consumer the potential impact is the same. Current key critical privacy and security themes being addressed in U.S. policies and standards are identified as follows:

A. Adequacy vii and Genetic Information Nondiscrimination Act of 2008 (GINA) viii . U.S. policy makers must examine if existing laws and regulations are appropriate and necessary for the evolving e-health environment. For example, 42 CFR Part 2 regulations, related to confidentiality of alcohol and drug abuse patient records, was developed prior to a time when chemical dependency was considered a part of health care services.

While the examples are U.S. specific, the issues are the same for any country. For example, Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) and the European Union's Directive on Data Privacy (EU Directive) are both known for their strict regulations and potential burdens that limit flow of patient and consumer information. Privacy and security laws need to be reviewed to determine what is missing, what is no longer relevant and what amendments may be necessary due to the transformation of health care and evolution to "eeverything".

A public demand for enforcement when breaches occur will dictate further development, clarifications and modifications to existing language. Two changes that have already had significant positive impact in the U.S. are: 1) changes by Drug Enforcement Administration (DEA) related to twofactor authentication for prescribing controlled substances that make e-prescribing more viable and 2) Meaningful Use and Certification Criteria Stage 1 Privacy and Security measurements and provider attestation of a security risk assessment.

B.

Consent There are significant legal and consumer related considerations related to consent. For example, the U.S. HIPAA Privacy Act sets forth rules governing the use and disclosure of protected health information (PHI) by "covered entities" defined as health plans, health care clearinghouses, and health care providers who transmit health information in electronic form in connection with a covered transaction, such as submitting a health care claim to a health plan ix . HIPAA x establishes the national minimum compliance framework, but states within the U.S. can and have expanded the legal provisions in areas of concern to their constituents. In addition, implementation and enforcement varies across states.

Consent implementation issues relate to when and how often consent must be granted, the use of verbal or written consent, and the ability of patients to consent to the inclusion or exclusion of their personal health information. . In the U.S, legal requirements related to consent vary by the patient's age (adult or child), status (youth or emancipated adult), location of service (school or medical facility), type of service (behavioral health or substance use treatment) and purpose (secondary use of data or treatment). In addition, U.S policies include additional parameters related to disclosure and re-disclosure related to substance use treatment. Consent implementation issues are further complicated when certain services can be categorized different ways, such as pharmaceuticals used for behavioral health could be categorized as either a pharmaceutical or a mental health service. The consent requirements vary depending on the categorization.

C. Use of Data for Treatment

Data must be "near real-time," actionable, valid and credible to be of value to providers. Data that does not easily and quickly provide accurate information has limited value. Factors that affect the transformation of data into actionable information include the security of the data in storage and transmission, standardization of terminology and transmission systems, use of structured versus unstructured (free-text) data, access controls and the potentiality of "gaps" in vital data because of legal or consumer barriers that may result in liability concerns.

D. Use of Data Beyond Treatment

Additional and broader patient concerns arise related to secondary use of data for functions other than clinical care. This includes public health purposes such as epidemiological monitoring, administrative functions and quality improvement efforts.

For example, access to eligibility and enrollment into public or private health care coverage is important for appropriate cost-covered treatment in the U.S. and can decrease the administrative burden on consumers. It can can also be useful for focusing quality improvement efforts and measuring quality results. The existing U.S. policy issue is whether the data must be deidentified when used for a secondary purpose.

E. Identity Management

A sensitive privacy and security issue currently being debated in the U.S. is the use of a national unique patient identifier. Concerns include increased patient privacy risks related to the ability to secure information about individual, fears of personal data tracking. Implementation related issues (connecting to existing records), and cost when other alternatives might meet most of the needs. However, the cost of not implementing a national patient identifier has also had an impact as significant dollars and time are spent on identifying correct patient data.

From an emergency care perspective, efficient information access saves money by reducing unnecessary testing and admissions, but more importantly it aids physician care decisions. Ensuring that accurate information about the specific individual is easily accessed is very important. This is a critical policy area where the solution is a balance between accessibility to critical information while avoiding inappropriate access or disclosure of personal information.

F. Operational Requirements

As with any new area of development, there are known requirements and unknown areas to explore. Providing quick and consistent guidance regarding operational requirements will make implementation and ongoing use feasible for large and small users alike. Security questions remain regarding strength of authentication; when, with whom, and how to use digital credentials, and types of transactions to be authenticated.

Critical to efficient execution in the U.S. is intra-and interstate consistency through mechanisms such as uniform laws, model acts, regulatory action, and reciprocity laws. One source for U.S. uniformity is the National Health Information Network (NHIN) DURSA agreement. The NHIN DURSA agreement provides standardized language related to responsibilities regarding privacy and security controls linked to malicious software; privacy and security rules; breach notification and action; oversight of technology, and compliance with laws. International workgroups such as the Joint Initiative on SDO Global Health Informatics Standardization continue to develop standards and address issues that arise with the shift to increased health IT. The council aims for international standardization and to make all standards available through the ISO 2000 certification process, which is continually updated to meet changing needs and safety concerns. This internationally available certification process for IT systems, similar to the NHIN DURSA agreement in the U.S., encourages consistency for products in the market. However, these standards meet the challenges of enforceability and adhering to a broad range of country laws.

IV. Discussion

In the U.S., the technical architecture and capability to address privacy and security issues exists and is being actively addressed. Health IT implementation, in any country, also demands the technical capacity to identify and separate sensitive health information, and to differentiate information according to type, data source and patient. The ability to segment and manage data is technically feasible; however, the demands on technology are complex, costly, and dependent on the granularity (consent by data type) required. For example, in current U.S. systems, access controls can be based on different variables (user, role, location, and group) or be rule-based. The rule-based provides greater flexibility moving forward, but it also requires a complete understanding and agreement on the legal and policy framework, the technical and operational business rules and guidance, and sufficient human and financial resources to assure correct implementation and ongoing compliance.

Implementation additionally involves the more difficult task of developing systems that may potentially integrate on an international scale, while concurrently assessing more local policies and challenges. An example of a current health IT challenge in the U.S. is that due to existing U.S. laws, the most difficult population to address is adolescents. To assure their health care needs are not ignored or disenfranchised, health IT infrastructure must have the ability to address variations in state laws regarding minor consent and definitions of "emancipated". The system must also segment adolescent health records to avoid unauthorized disclosure through tagging all data related to a procedure to which a minor has consented, recording the related minor consent status in a structured field, and transmitting minor consent status and information tags. To add to the complexity, providers serving teens in foster care may release "confidential" HIV-related information to an authorized foster care agency, without permission, but are not required according to existing law. xi Foster care agencies, however, must release any HIV-related medical information to prospective foster or adoptive parents, but also safeguard this information from disclosure to others. Similar to perplexities created by U.S. laws established prior to the expansion of health IT, other countries may have also or will soon need to reassess existing laws and standards when implementing health IT practices. It is anticipated that countries positive, and negative, experiences may be shared to provide examples of practices to avoid or implement while developing health IT systems.

V. Conclusion

As health IT evolves and the U.S. health care reform moves forward, decisions will need to be made on when to enforce existing or create new policies, especially those guiding privacy and security. Providers must adjust workflow related to obtaining and managing consent and data systems. Consumers and patients will need to understand the vast changes to their own health care delivery and administration, and conflicting interests of stakeholders will need to be balanced to get to a sustainable, reformed health care and information technology system. Throughout these advancements, patient privacy and security must remain at the forefront of every decision as they are essential to keeping the system credible, trusted and operating. The current experiences of the U.S. health IT evolution and lessons learned from challenges such as reviews of privacy and security laws, consent and related legal issues, use of data for treatment and beyond and identity management, combined with other international experiences, can help guide future formation of international health IT standards related to privacy and security.

Figure 1 :

 1 Figure 1: Security Countermeasures for Protecting Health Information

  and Appropriateness of Current U.S. Privacy and Security Laws in an e-Health Environment Privacy and security of health information is not a new set of concepts. In the United States, diverse federal and state laws and regulations exist that seek to address privacy and security such as HIPAA Privacy and Security Rules, Privacy Act of 1974, 42 CFR Part 2: Confidentiality of Alcohol and Drug Abuse Patient Records Regulations iv , Family Educational Rights and Privacy Act (FERPA) v , Gramm-Leach-Bliley Financial Act vi , Federal Information Security Management Act of 2002 (FISMA)


Simon Mcginnes
email: simon.mcginnes@tcd.ie

The Problem of Conceptual Incompatibility Exploring the Potential of Conceptual Data Independence to Ease Data Integration

Keywords: Data integration, domain-independent design, conceptual data independence, archetypal categories

Application interoperability and data exchange are desirable goals, but conventional system design practices make these goals difficult to achieve, since they create heterogeneous, incompatible conceptual structures. This conceptual incompatibility increases system development, maintenance and integration workloads unacceptably. Conceptual data independence (CDI) is proposed as a way of overcoming these problems. Under CDI, data is stored and exchanged in a form which is invariant with respect to conceptual structures; data corresponding to multiple schemas can co-exist within the same application without loss of integrity. The use of CDI to create domainindependent applications could reduce development and maintenance workloads and has potential implications for data exchange. Datasets can be merged without effort if stored in a conceptually-independent manner, provided that each implements common concepts. A suitable set of shared basic-level archetypal categories is outlined which can be implemented in domainindependent applications, avoiding the need for agreement about, and implementation of, complex ontologies.

Introduction: The Problem of Conceptual Incompatibility

The present massive proliferation of databases, web pages and other information resources presents a data integration problem. There is a need to use data in a joinedup way, but mechanisms are lacking that allow easy data integration in the general case; it is often hard to combine data resources. A prime reason for this is that different datasets typically have incompatible conceptual structures. Common practice in information systems (IS) design leads each organisation or software vendor to create its own idiosyncratic data structures that are incompatible with those created by others; commercial pressures can have the same effect. Standard conceptual structures are normally used only in limited circumstances, when imposed by enterprise software platforms, legislative requirements or other external constraints. In the rush to create ever-more comprehensive and powerful IS, the increasing problem of heterogeneous, incompatible conceptual structures has been left for future technology to solve.

1.1

Why Do Current Methods of Integration Not Solve the Problem?

Developers have historically faced two issues with regard to integration of systems that have distinct conceptual data structures: physical incompatibility and conceptual incompatibility. Thankfully, many technologies now exist to resolve the first issue, by physically interconnecting heterogeneous platforms; these include RPC, CORBA and web services. Programs can also be linked simply by exchanging files using a common format such as XML. However, progress on physical compatibility has exposed the deeper second issue of conceptual or semantic compatibility: the problem of reconciling implicit conceptual models.

If we wish to use several data resources in an integrated way, they must share both a common vocabulary and a common conceptual framework. This fundamental and unavoidable principle of semiotics [START_REF] Liebenau | Understanding Information: An Introduction[END_REF] may be understood by analogy to human communication: if two people wish to exchange information effectively they must speak the same language, but they must also possess shared concepts. Conceptual compatibility thus runs deeper than mere language; for people to communicate they must interpret words identically, or nearly so, and there is no guarantee that this will be the case. Meaning is essentially personal and subjective, affected by context, culture, and so on.

Getting two programs to exchange data involves a similar problem. A common, recognisable vocabulary must be used by both sides, and the two programs must also have been programmed with common concepts, so that they can act on the data appropriately. Computers cannot yet understand data in the sense that a human does, but they can be programmed to deal sensibly with specific items of data provided that the data is of a known type; this is what we mean when we say that a program -understands‖ a particular concept. In practice, however, most IS share neither vocabulary nor concepts. It would be surprising if they did, given they ways they are developed and the rarity with which standard conceptual structures are applied. For this reason, linking real-world IS that have heterogeneous conceptual schemas is rarely a simple matter.

In trivial cases it can seem straightforward to map the conceptual models of distinct systems to one another. For example, two programs which manage data about customers might well use similar data structures and common terms such as name, address and phone number. But semantic complexity lurks even in apparently straightforward situations. Is a customer a person or an organisation? Are business prospects regarded as customers, or must we already be trading with someone for them to be considered a customer? What about ex-customers? Many such questions can be asked, highlighting the inconvenient truth that most concepts are more complex than they seem, when one scratches the surface, and certainly far more complicated and esoteric than the trivial example quoted above. Uniting separatelydeveloped conceptual structures can be challenging even for expert developers working with systems in closely-related domains [START_REF] Sowa | The Challenge of Knowledge Soup[END_REF]; it can be difficult to discern what data structures are intended to signify and what unstated assumptions have been made.

Another approach to data integration involves the use of automated schema matching, and tools for this purpose have been developed with some success [START_REF] Rahm | A survey of approaches to automatic schema matching[END_REF]. But there is an inherent limit to the ability of automated matching strategies to operate reliably in the general case. Software cannot easily call upon context, domain expertise and general knowledge to understand and disambiguate the meaning of conceptual structures [START_REF] Hauser | Searle's Chinese box: debunking the Chinese room argument[END_REF]. Again, the analogy of human understanding is relevant. When conversing with others, we draw upon our prior knowledge to understand what is meant. A person without prior knowledge has no hope of understanding what somebody else says. This analogy suggests that automated schema matching strategies must first overcome the grand challenge of accumulating and applying general knowledge before they can be expected to extract the semantics in arbitrary schemas with sufficient reliability [START_REF] Kalfoglou | Issues with Evaluating and Using Publicly Available Ontologies[END_REF].

In summary, semantic issues make it difficult, as a rule, to match conceptual models between IS-especially since most IS have idiosyncratic designs and complex conceptual structures that are based on unstated assumptions [START_REF] Taylor | Adhocism in software architecture-perspectives from design theory[END_REF]. Conceptual incompatibility therefore presents a major barrier when we attempt to link IS. And this ignores the scalability problem, that integrating systems typically requires a good deal of interface code which must be crafted, onerously, by hand.

Conceptual incompatibility is also a problem for end users [START_REF] Klein | Combining and relating ontologies: an analysis of problems and solutions[END_REF]. It means that we must adopt a different mental model of reality each time we use a different program. For example, consider how the concept person is treated in different software products from the same vendor. In Microsoft Word, people are represented merely as -users‖. In Microsoft Project, people are considered from a management perspective as -resources‖. In Microsoft Outlook people are considered as -contacts‖. Although these different treatments refer to the same underlying entity (a person), they are in fact three quite distinct mental concepts, each with its own meaning and implications.

The same applies to most software applications: each application takes a unique perspective on reality to suit its own purpose. The user is left to mentally reconcile the various perspectives. This is at best confusing, since the concepts may be overlapping or orthogonal, and applications rarely spell out precisely what they mean by any given term. It can also be a problem for developers, who often lack understanding of the domain concepts in applications [START_REF] Eick | Does code decay? Assessing the evidence from change management data[END_REF].

Standardisation of Conceptual Structures

The reliance on post-hoc system integration implicitly facilitates the trend towards growth in conceptual incompatibility. By allowing heterogeneous applications to proliferate, we are effectively supporting the development of incompatible conceptual structures. This is a major concern [START_REF] Fonseca | Toward an Alternative Notion of Information Systems Ontologies: Information Engineering as a Hermeneutic Enterprise[END_REF]; -the Semantic Web should not sit on the Tower of Babel‖ [START_REF] Fensel | Spinning The Semantic Web: Bringing the World Wide Web to Its Full Potential[END_REF]. Some means is needed of limiting heterogeneity or at least of facilitating the job of reconciling heterogeneous conceptual structures.

An alternative to the idea of reconciling data structures is to design IS such that they conform ab initio to standard conceptual structures. The use of standardised conceptual structures could have benefits for a software industry which is experiencing uncontrolled growth in conceptual incompatibility and its associated costs. This is an idea with some support, and many competing standards, formats and ontologies have been developed over the years for use in different application domains.

Parallels can be drawn with the development of other industries. For example, in the early railway industry, locomotives and track were crafted individually, resulting in a variety of incompatible gauges and coupling mechanisms [START_REF] Miller | railway. com[END_REF]. At first, the absence of standards was unimportant, because railways were not linked. But when integration of the network became important, the existing ad hoc design practices soon became a barrier to progress. Standards were needed, addressing not just infrastructure but also more fundamental concepts such as time [START_REF] Bartky | Selling the True Time: Nineteenth-century Timekeeping in America[END_REF]. Competing standards faced resistance and controversy. For example, broad gauge was regarded as technically superior, but lost out to standard gauge in some regions after decades of competition.

Table 1 lists other spheres in which integration has led to the need for standards, often despite conflict and opposition. In all of these domains, growth led to increasing interconnection and this in turn created a need for standardisation. In retrospect, the inevitability of such standards is obvious, given the need for interoperability, and the alternative is unthinkable. Nevertheless, the adoption of standards is often painful because it requires that some or all participants give up their own solutions. We argue that the software industry has yet to fully confront this issue with regard to conceptual structures. A common argument against standardisation is that a single solution cannot possibly be the best technical choice for every situation. Yet many IT standards have emerged despite superior competition. SQL became the standard database query language, despite the existence of languages considered more powerful and easier to use [START_REF] Siau | Effects of query complexity and learning on novice user query performance with conceptual and logical database interfaces[END_REF]. TCP/IP is dominant despite widespread promotion of the OSI standard [START_REF] Maathuis | The battle between standards: TCP/IP Vs OSI victory through path dependency or by quality? Standardization and Innovation in Information Technology[END_REF]. The QWERTY keyboard layout remains the standard despite the development of more ergonomic layouts [START_REF] David | Clio and the Economics of QWERTY[END_REF].

In all of these cases, adopting standards has provided widespread benefits despite the pain involved for those with vested interests. We suggest that the IS field could obtain similar benefits by standardising conceptual structures. Implementation of standard conceptual structures could make interoperation more straightforward, perhaps even offering the ability to integrate information resources in a plug-and-play fashion. The alternative is a future of information islands, multiple interfaces, frequent schema translation operations, with attendant complexity and opportunities for conceptual confusion.

Much current thinking on data integration centres on tagging, using technologies such as the Semantic Web, RDF, linked data, ontologies and microformats [START_REF] Craighead | Enabling the benefits of Supply Chain Management Systems: an empirical study of Electronic Data Interchange (EDI) in manufacturing[END_REF]. The hope is that tagging will allow applications to exchange and process data without intervention. -We're not that far from the time when you can click on the web page for the meeting, and your computer, knowing that it is indeed a form of appointment, will pick up all the right information, and understand it enough to send it to all the right applications‖ [START_REF] Hendler | Integrating Applications on the Semantic Web[END_REF].

How feasible is this? Referring to the discussion in Section II, this kind of interoperability would require both a shared vocabulary and a shared conceptual framework. That means that each piece of data must be named in a recognisable way (vocabulary) and its name must refer to some shared meaning (concept). Organisations wishing to exchange tagged data must therefore agree on a common terminology, which they can map to their proprietary data structures, and they must also agree on common concepts, which they can code into their applications. For an application to possess a concept means that the application recognises what to do with data pertaining to that concept. Asking two software applications to exchange data in the absence of common concepts is rather pointless, since the receiving application can do little with the data except store it.

Microformats offer an illustration. They provide a common terminology (hRecipe, hCard, etc.) and also a series of common, if rather simplistic, concepts that applications can be programmed to share. The development of microformats is perhaps a pragmatic reaction against large-scale ontology development, the seemingly never-ending effort to create universal -conceptual models of everything‖ [START_REF] Khare | Microformats: a pragmatic path to the semantic web[END_REF]. Microformats offer the potential for quick wins because they are intended as simple, uncontroversial conceptual model snippets. They are couched at an -everyday‖ level of generality and therefore easy to understand [START_REF] Pansky | The Basic-Level Convergence Effect in Memory Distortions[END_REF]. By definition, microformats ignore most of the complexity of real-life conceptual structures. In particular, they neglect the relationships between concepts, which is where most conceptual complexity lies. This is what allows developers to use microformats so readily.

But, while it is easy to envisage agreement on simple, well-known concepts such as recipes and appointments, it is in the nature of conceptual structures to quickly become complex. Efforts to create reusable, generic structures can soon result in hardto-understand abstractions that are less useful for any particular application. Microformats remain useful while they remain simple and disconnected from one another, but when there is a need for integration to reflect the real-world relationships between concepts, the complications associated with larger-scale ontologies quickly arise [START_REF] Heath | Ease of interaction plus ease of integration: Combining Web2. 0 and the Semantic Web in a reviewing site[END_REF].

In summary, it remains difficult to agree on standards for the domain-specific concepts found in much enterprise data, particularly when IS are viewed as a source of competitive advantage and best practice in IS design begins with idiosyncratic conceptual structures. Historically, previous efforts at conceptual standardisation have encountered similar problems for similar reasons [START_REF] Graham | The dynamics of EDI standards development[END_REF].

Ontologies as a Potential Solution to Conceptual Incompatibility

Ontologies are a current focus of attention in conceptual standardisation. Domain (industry-specific) ontologies are now available or in development, each created more or less in isolation to suit the needs of a particular business area. Domain ontologies are normally incompatible with one another and lack common concepts. As a result, matching two arbitrary domain ontologies can be challenging. In contrast, upper ontologies are more wide-ranging; so as to encompass a range of application domains they typically include broad and generic abstractions. One approach to ontology matching makes use of this by mapping domain ontologies to one another using the high-level abstractions in upper ontologies [START_REF] Musen | Wrestling with SUMO and Bio-ontologies[END_REF].

Ontologies offer a potential source of common conceptual structures and may therefore present a solution to the problem of conceptual incompatibility. They can be used to integrate applications in two primary ways. One is by acting as a design blueprint, so that applications are constructed to share a common conceptual model. This automatically renders applications compatible provided that they do not introduce extensions or subtle variations in semantics to suit their own needs. It is therefore possible that conceptual incompatibility could be resolved, if all applications were built to conform to a single upper ontology, linked in turn to an agreed set of domain ontologies, if the ontologies in question remained relatively static. However, the task would be enormous, even if everyone could agree on a single set of ontologies to suit all purposes. Given that reality can be modelled in an infinite variety of ways, this seems unlikely. As one researcher succinctly put it, -knowledge cannot be standardised, since each day more sprouts‖ [START_REF] Guzman-Arenas | Measuring the understanding between two agents through concept similarity[END_REF]. Others have observed that it might be more practical to have a flexible means of interpreting concepts at runtime rather than a conceptual language that is rigidly defined a priori.

The other way in which ontologies can be used to integrate applications is for each application to use its own conceptual structure or ontology, as at present, but to match up the distinct ontologies, so allowing translation and exchange of data. This is in effect the commonly-used approach. However, it seems unlikely that this approach can provide a lasting solution to the problem of integration on a large scale. It does not address the fundamental problem of conceptual fragmentation; as in schema matching, ontology matching is labour-intensive and fully-automated matching is currently infeasible in the general case.

Conceptual Data Independence

Below we propose an alternative solution to the problem of conceptual incompatibility. Our solution is based on conceptual data independence (CDI), which refers to the storage of data in a format that is invariant with respect to conceptual structures. A primary benefit of CDI is that it reduces the knock-on effects of changes to conceptual structures, so that development and maintenance costs can be reduced. However, CDI also offers the prospect of easier data integration. Below we give a brief explanation of CDI and how it can be achieved, and then discuss how it can assist in the data integration task. The scheme outlined below is not presented as the only or best way of implementing CDI, but as an example for illustrative purposes. We hope that it will stimulate discussion on alternative ways of achieving CDI and their respective advantages.

An aim of CDI is to avoid the need to modify applications whenever underlying conceptual structures change. This suggests that applications and databases should be designed using software structures which are independent of conceptual structures. For example, to store data about customers, one would have to construct a database structure without referring to the concept customer, or anything like it. This requirement contradicts current design practice, since one would normally expect to store data about customers in a -Customers‖ table or equivalent.

A step in the right direction is to find some invariant aspect of customers to use as a data structuring mechanism. The idea of a role is helpful here. If customers are people, then the concept customer is a role that people play. Roles are, by definition, transient and overlapping-we play them from time to time. The idea of a person is also a concept, but a less volatile and more universal one. Accordingly, it may help to base our data structure on the concept person rather than the role customer [START_REF] Wieringa | Roles and dynamic subclasses: a modal logic approach[END_REF].

In general, mental concepts may be divided into roles and non-roles. Non-roles can be recorded as invariant knowledge whilst roles may be better recorded as variant or volatile data. This idea is represented in the conceptual structures shown in Figure 1. The first structure shows concepts customer and supplier. In the second, substitution of these concepts with more general ones (person and organisation) transforms the role into a relationship.

The distinction between variant and invariant knowledge is not a very rigorous one. However, there can be practical value in distinguishing concepts, which are relatively

Person

Organisation is a customer of 0..m 0..m

Fig. 1. Conceptual structure representing a role as a relationship

Customer Supplier purchases goods from 0..m 0..m permanent, from roles, which are relatively impermanent. For example, without negotiation there is unlikely to be universal agreement on what a customer is and how a customer is defined. But it is possible to assume agreement that people exist, and this agreement is all that is needed to allow the most basic level of data exchange. Once again, the analogy of human communication is helpful; two individuals can converse effectively if they can safely assume that common basic-level concepts are shared (such as the idea of a person or a place) even if they have slightly different ideas about how these things might be defined in detail.

A more complex example follows. Consider a software application that handles information about product types, suppliers, stores, customers and the purchases that customers make. In a classically-designed database, the process of normalisation would lead to a separate table representing each entity type. A possible solution is illustrated in Figure 2.

We can simplify the structure as before by replacing the entity types with more general categories. To do this, we observe that customers are people, stores are places, suppliers are organisations, purchases are activities, and product types are categories. The result is illustrated in Figure 3. We now have a more general model with potentially wider applicability. Role-based concepts like customer and supplier have been replaced by more generic categories and encapsulated in relationships. Of course, this model is still subject to volatility, because the relationships are likely to alter over time. If these relationships were implemented in a database structure they would -fossilize‖ a particular snapshot of the conceptual structure, and make it hard to modify or extend later on. One way of avoiding that is to represent the entity types and relationships as data, using a structure similar to the one shown below. This provides a structure which is effectively a meta-model; it is designed to store conceptual models as data. We refer to a conceptual model stored in this manner as a soft schema. Soft schemas can be stored using any appropriate means, including in databases or as XML. The corresponding data described by each conceptual model can also be stored in a variety of ways, but XML is an obvious candidate, as shown in the example below.

<customer category="person"> <name>Joanne Wall</name> <id>2012</id> <address>43 Tows Str</address> </customer> <customer category="person"> <firstname>Maurice</firstname> <lastname>Smith</lastname> <id>2002</id> <address>3 Yannou Street</address> <phone>2273034397</phone> </customer> Fig. 5. Data fragment Note that this XML fragment exhibits CDI, because it does not conform to any particular conceptual structure. In effect, each instance of data carries its own conceptual structure. The example shows two data instances, and although both refer to the same concept (customer), the concept is defined differently in each instance. In a conventional database or application, this would be evidence of a failure of data integrity, and would probably cause the application to fail. But in a system with CDI, it merely reflects the fact that the conceptual structure has evolved over time, or is contingent on context, or data has been merged from heterogeneous applications, or some other circumstance. In other words, such differences in conceptual structure between data instances are natural and entirely to be expected. Any software application which uses this data would be required to cope smoothly with the difference in structure between the two instances.

With appropriate management software (analogous to database management software) domain-level semantic constraints can be enforced including referential integrity, subject to the constraint that data relating to multiple schema versions must be able to co-exist. It is envisaged that this layer of systems software would mediate between the data storage and applications which access it, in much the same way that database management software does.

This ability to store data instances corresponding to multiple schemas alongside one another provides a unique advantage. Because the architecture is not specific to any particular conceptual structure, it allows for the storage of data pertaining to any conceptual structure, and therefore any application domain. The logical consequence is that data could be stored for any and all domains using a single datastore. In other words, a single datastore could concurrently hold data corresponding to any number of distinct schemas. By implication, a single application could consult this datastore, responding in real time to the embedded conceptual structures to provide suitable functionality across multiple domains. We refer to applications with this property as domain independent [START_REF] Kapros | Multi-component Evaluation of an Adaptive User-interface for a "Generic Application[END_REF]. The potential for domain-specific design in such an application would be reduced and the consistency of application design would be increased, relative to current practice. This may or may not be an advantage and is a subject for further research. We note also in passing that the functions of such an application could easily be incorporated into an operating system or other system software.

Archetypal Categories as a Basis for Integration

The example above refers to a number of basic-level concepts which are considered relatively invariant. They include people, places, organisations, activities, and categories. This is not an arbitrary list of concepts; it stems from research into the cognitive aspects of conceptual modelling and system design [START_REF] Mcginnes | Accelerated Business Concept Modeling: Combining User Interface Design with Object Modeling[END_REF]. The list also includes documents, physical objects, conceptual objects and systems. These basiclevel concepts are termed archetypal categories.

According to one view of cognition, meaning is generated in the brain by unconscious feature-driven classification of perceptual inputs on the basis of similarity and associative recall. While it had been thought that the brain's neural networks were structurally indifferent to categories, evidence suggests that the mind has evolved to give preference to certain concepts in particular; examples from different studies include people, activities, tools and locations. It has been proposed that human memory tends to converge on such basic-level concepts, which are neither highly specific nor particularly generic [START_REF] Pansky | The Basic-Level Convergence Effect in Memory Distortions[END_REF]. Physical evidence from brain imaging studies also suggests that we may possess a limited number of hard-wired semantic regions into which perceptions are routed [START_REF] Mason | Thinking About Actions: The Neural Substrates of Person Knowledge[END_REF], corresponding again to categories pitched at a basic, everyday level [START_REF] Eysenck | Cognitive Psychology: A Student's Handbook[END_REF]. We suggest that IS could exploit the familiarity of these innate categories by storing and presenting data in terms of them. Further, we suggest that their use would make data exchange easier.

Ontologies typically include thousands of classes, but only a subset correspond to basic-level concepts. For example, the ontology SUMO contains the hierarchy sentient agent → cognitive agent → human → internet user [START_REF] Niles | Mapping WordNet to the SUMO Ontology[END_REF]. The class internet user is a role, and the classes sentient agent and cognitive agent are abstract; this leaves human as the only basic-level concept (essentially identical to our person). In a similar vein, animal might be more easily understood than organism, and man easier to deal with than hominid. In our list of archetypal categories person and organisation could be replaced by the more general concept party, but again this would not be pitched at a basic level and would therefore not be so understandable.

It should now be apparent how CDI and archetypal categories can offer a solution to the problem of conceptual incompatibility, allowing the exchange of conceptuallyincompatible data. IS could use a small vocabulary of archetypal categories, reflecting the mind's basic-level concepts. This would provide the common conceptual framework required for meaningful exchange of information [START_REF] Liebenau | Understanding Information: An Introduction[END_REF]. If data is expressed in terms of a small list of shared archetypal categories, it can be understood by both parties in the exchange even if no concepts per se are shared.

The example in Figure 5 is a simple illustration of this principle. Both instances of customer refer to the archetypal category person. To deal with the data, the receiving application would need to -understand‖ what people are and how to handle data about people-without expecting any particular conceptual structure attached to instances of the category person. The receiving application would thus not need to share a conceptual model or ontology with the sending application. The same argument applies for data corresponding to the other archetypal categories: places, organisations, documents and so on. Implementation of this simple set of archetypal categories in the context of domain-independent applications could therefore offer a convenient -middle road‖, allowing data to be exchanged meaningfully without the need for complex shared conceptual models or ontologies.

Conclusion and Further Work

To summarise, the argument for conceptual data independence is as follows. Interoperability between applications and easy exchange of data are desirable goals, but heterogeneous design makes them difficult to achieve. Standard design practices create ad hoc, incompatible conceptual structures. This was acceptable when there were relatively few applications and change was infrequent. However, as a result of the creation of many applications and increasingly rapid business change, conceptual incompatibility is causing an unacceptable increase in system development, maintenance and integration workloads.

The idea behind CDI is that data is stored and exchanged in a form that is invariant with respect to conceptual structures; each instance of data carries its own conceptual structure, which can be interpreted at runtime. This implies that data corresponding to multiple schemas can co-exist within the same datastore or application. When used in application design, CDI therefore has potential to reduce development and maintenance workloads substantially, because applications do not have to be domainspecific. In effect, one application with CDI could fulfil the function of many of today's domain-specific, non-CDI applications; the result could be a substantial reduction in cost and delay. CDI also has implications for data exchange; any two datasets can be merged without effort if they are stored in a conceptually-independent manner, provided that both use a common set of concepts. The use of archetypal categories provides such a set of common concepts which can easily be implemented in multiple domain-independent applications, because it does not rely on agreement about, and implementation of, complex ontologies.

Research is proceeding into the use of CDI. One project has produced a proof-ofconcept software prototype which demonstrates how the need to modify software applications can be avoided as conceptual structures evolve [START_REF] Kapros | Multi-component Evaluation of an Adaptive User-interface for a "Generic Application[END_REF]. Work is in progress on usability testing. Next, it is planned to proceed with the development of a fullyfeatured domain-independent application in order to test the impact of CDI on system maintenance and data integration. Overall, CDI represents a fundamentally different approach to information system construction; further empirical and theoretical research will be needed to explore the significant possibilities that it affords.

Fig. 3 .Fig. 2 .

 32 Fig. 3. Roles replaced with archetypal categories

Fig. 4 .

 4 Fig. 4. Concepts and relationships represented as data (for clarity, provision for storage of attributes is omitted)

Table 1 .

 1 Examples of Standards.

	Sphere	Examples of standards
	Finance	Accounting conventions
		International payment systems
	Law	Legal harmonisation within the European Union
		International double taxation treaties
	Electricity	Adoption of AC with standard frequency and voltage
		Use of standard electrical connectors
	Electronic media	VHS (despite alleged technical inferiority to Betamax)
		Blu-Ray


Maria B Line
email: maria.b.line@sintef.no

Erlend Inger Anne Tøndel
email: inger.a.tondel@sintef.no

Andreas Gjaere
email: erlend.andreas.gjare@sintef.no

A Risk-based Evaluation of Group Access Control Approaches in a Healthcare Setting

Keywords: Access control, privacy, health care, information security

This paper focuses on access control approaches usable for information sharing through large screens where several individuals are present at the same time. Access control in this setting is quite different from traditional systems where a user logs on to the system. The paper outlines a number of possible approaches to access control, and evaluates them based on criteria derived from risk analyses of a planned coordination system for the perioperative hospital environment. It concludes that future work should focus on extending the location-based approach with situation awareness, and add support for using pop-ups or handheld devices for sharing of the most sensitive information.

Introduction

There are a number of systems available whose main purpose is to inform the public about status and status changes. Examples are screens showing incoming flights at airports, or overviews of meeting room occupancy at hotels. In these example systems the information on the screen is unlikely to be sensitive, and thus there is no need to control information visualization. But imagine such information displays being used in healthcare or in other businesses where some status information should be considered internal.

In this paper we focus on access control solutions for wall-mounted screens that show status information in a perioperative hospital environment (before, during and after surgery). This environment is characterized by multidisciplinary teams, the need to react to unanticipated events, and utilization of expensive resources. Planning and coordination are difficult but important in such a setting [START_REF] Faxvaag | Visualizing patient trajectories on wall-mounted boards -information security challenges[END_REF]. To improve coordination, wall-mounted screens visualizing progress and current status can be placed at waiting rooms, wards, operating rooms, recovery rooms etc. where health care personnel is likely to see them. As a result it becomes easier to understand how the patient care is progressing and adapt own behaviour.

Access control in systems communicating via large public wall-mounted displays is quite different from traditional access control where a single user logs on to a system. First, it is difficult to know at a given point of time who is able to view the information on screen. In the perioperative environment, there can be a number of health care personnel having access to the location of a screen, in addition to patients, their next-of-kin, and other types of personnel such as cleaners or technicians. Still, if we were able to know who were present, it is not a straight-forward task to determine how this knowledge should affect what information to display. Access policies are normally defined on a single-user level, while the coordination system may just as well have none or several users to consider in its decisions on what to display. Second, the information -though it may be sensitive -is displayed because it is needed for a purpose. What to display in a given situation must be based on proper trade-off decisions between privacy on one hand and efficiency and patient safety on the other. This calls for access control solutions that are dynamic and context-aware, and that fit the way of work in the perioperative domain. To further complicate matters, there is in general no time for users to login to the system, as information should be available by just by taking a quick look at the screen.

In our previous work [START_REF] Faxvaag | Visualizing patient trajectories on wall-mounted boards -information security challenges[END_REF] we have decided on a strategy in order to overcome these challenges, termed flexible de-identification. With flexible we mean that decisions on what to display should not be static but adapted to the situation and current context. De-identification leads to solutions that go beyond the more traditional consideration of whether to display identifying information or not. Instead we assume that information needs not be at the highest level of granularity to be useful for coordination purposes.

In this paper we focus on providing flexible access control, while de-identification is left out1 . We do not consider access to information by single users, but instead how to determine access rights for a dynamically changing group of individuals. This group is likely to consist of personnel with different professions and different needs and rights for information, who -though they work together -will have different opinions as to what information gives meaning and is useful. We present several approaches to access control in this setting. Our main contribution is a preliminary evaluation of these approaches based on criteria derived from a risk analysis of a the COSTT system2 -a planned coordination system for the perioperative hospital environment.

The paper is organized as follows: Section 2 outlines relevant approaches for access control. Section 3 explains the method used to perform the risk analyses and to deduce evaluation criteria. Section 4 gives the results of the risk analyses, explains the evaluation criteria and applies them in order to evaluate the different access control approaches. Section 5 discusses the validity of the evaluation result, and suggests directions for future research, before section 6 presents our concluding remarks.

Access control related to shared disiplays have been given some attention from researchers, and proposed solutions include using special types of glasses to allow different people to see different types of information [START_REF] Shoemaker | Single display privacyware: augmenting public displays with private information[END_REF] and using visualizations (e.g. colors) instead of text to present the most sensitive information [START_REF] Tarasewich | What are you looking at[END_REF] (similar to our de-identification approach). Available research on how to determine access rights of dynamically changing groups of users is however sparse. We are only aware of one publication [START_REF] Bullock | An access control framework for multi-user collaborative environments[END_REF] that addresses this issue to some extent. This publication lists three different approaches that can be used in combination. The first approach is aggregation where the access rights of a group correspond to the sum of the access rights of the individuals in the group. As a result, larger groups are likely to get access to more resources than smaller groups. The second approach is maximum/minimum where the individual with the highest/lowest access rights determines access rights for the whole group. Third, the group structure approach computes access rights based on the structure of the group, e.g. ensures that at least two users with a certain access level are needed in order to gain access to a specific resource.

Current access control solutions developed for healthcare are mainly based on Role Based Access Control [START_REF] Ansi | American National Standard for Information Technology -Role Based Access Control[END_REF] where users are granted access based on their profession [START_REF] Appari | Information security and privacy in healthcare: Current state of research[END_REF] [START_REF] Ferreira | Access control: how can it improve patients' healthcare?[END_REF]. A study of an up-and-running Electronic Patient Record system at a Norwegian hospital [START_REF] Røstad | A study of access control requirements for healthcare systems based on audit trails from access logs[END_REF] identified the need for access control solutions more tailored to the needs of health care personnel. Solutions should be better able to handle dynamic events, workflow and collaboration.

Dynamic context-aware access control solutions have been suggested in various forms, some also specifically addressing health care (e.g. Hu et al. [START_REF] Hu | Dynamic, context-aware access control for distributed healthcare applications[END_REF]). We will not go into specifics on the different models, but rather point to parameters that can be used when creating more dynamic access control solutions in a health care setting. Hu et al. mention time, location, trust-level of authentication, relationship to patient, and specialist area. Most of these are also mentioned by Alam et al. [START_REF] Alam | Modeling and enforcing advanced access control policies in healthcare systems with SECTET[END_REF], who add device type, duration, purpose, number of accesses, user consent, presence of the patient, delegation and emergency situations to the list. Risk and benefit are also factors that can be taken into account in access control decisions. Examples of access control solutions that include the concept of risk is the work of Cheng et al. [START_REF] Cheng | Fuzzy mls: An experiment on quantified risk-adaptive access control[END_REF], Dimmock et al. [START_REF] Dimmock | Using trust and risk in role-based access control policies[END_REF] and Diep et al. [START_REF] Diep | Enforcing access control using risk assessment[END_REF].

Below we present the main access control approaches considered in this paper. It is assumed that we have technology available for authenticating and locating users 3 .

Location-based: Only the screen's location applies, which means that all screens have a given default view that can not be affected by persons being present. Access control to the screen is managed through physical access control; people being allowed to be at a certain location are also allowed to see all information displayed on the screen at the given location.

Minimum [START_REF] Bullock | An access control framework for multi-user collaborative environments[END_REF]: A group's access rights will correspond to the lowest level of access rights present in the group. This will clearly ensure patients' privacy, as nobody in the group will see more information than they are allowed to. However, the usefulness may be low, as the persons with higher levels of access rights will not always see all information meant for them.

Maximum [START_REF] Bullock | An access control framework for multi-user collaborative environments[END_REF]: A group's access rights will correspond to the highest level of access rights present in the group. This will ensure usefulness, as all health care workers will see all the information meant for them. However, the patient's privacy may be compromised.

Group structure [START_REF] Bullock | An access control framework for multi-user collaborative environments[END_REF]: The access level is decided by computations on the group structure. An average value is calculated based on who is present, including weighting of who is closest to the screen and considerations of how many is present with limited access rights vs. wide access rights.

Facilitator: One of the users in the group acts as a facilitator. The facilitator is authenticated, and makes decisions as to whether to include new users into the group and which information is needed/appropriate based on the users present.

Situation aware: The system is aware of the situation in which it operates, e.g. it combines information on type of patient and diagnosis with time of day and an understanding of whether this is an emergency or normal operation. Situational awareness is then used to decide access rights of the group.

Possible extensions: Pop-up window and handheld devices: All the suggested approaches can be extended with solutions that grant individual users access to more information. This can be done by utilizing small pop-up windows where e.g. surgeons can authenticate themselves and get access to more details shown in a limited part of the screen, or get the information sent to a handheld device. Getting access to information in a pop-up window limits the reading access for other people being within proximity, information is only readable for the one/those standing really close to the screen. Sending information to a handheld device further reduces the risk of confidentiality breaches.

Method

In this work, we use the results of two risk analyses of the planned COSTT system to identify criteria that the access control solution need to fulfil, and use these criteria to evaluate and compare the alternative access control approaches. The main motivation for using risk analysis in this respect is twofold. First, the results of the risk analyses are already available and provide valuable insight into the environment in which the access control solution will be put to use. Second, access control aims to protect (some of) the system assets by reducing risks, but may also introduce new risks. Performing a risk analysis is a good way to identify both the assets and the risks towards these assets. We recognise that using risk analysis of systems to evaluate access control policies is uncommon. Still, we uphold that the results of a risk analysis are useful for performing a preliminary evaluation of alternatives in order to decide which should be further investigated and evaluated. Two risk analyses have been performed, and both were carried out in two stages: 1) Asset identification 4 : "What are the most valuable assets in the COSTT system? What do you want to protect?", and 2) Risk identification and ranking: "What are the most important risks for COSTT? What are you most afraid of happening?". In each stage the participants were given five minutes to write down their answers to the questions posed. Both stages were summarized by organizing the brainstorming results into groups that the participants agreed upon. The risk identification stage also included ranking of the risks. Each participant was given three votes they could use to prioritize risks. The risks were then ranked according to votes in total.

The COSTT project group was used as participants. Together they represent a broad spectrum of specialist areas; IT, sociology, medicine, and technology management. The first risk analysis was performed at the stage where the system itself existed only as a concept and many decisions that would affect the outcome had not been made yet. The purpose of this preliminary analysis was to get an initial sense of what are the key risks as perceived by the project team. The second risk analysis of the future COSTT system was performed 10 months after the first one. The system itself still existed only as a concept but some research, including literature studies and empirical studies, had been performed. The purpose this time was to see if the results would differ a lot from earlier, and to identify the major changes, if any.

Results

In this section we present the results of the risk analyses, and use these results as a basis for identifying evaluation criteria. Then we show to what extent the identified access control approaches are able to meet the criteria.

Results of the risk analyses

The findings from the first risk analysis represent a starting point and a snapshot of the project status at that point of time. The second risk analysis revealed the same results, but both broader and in more depth. One of the main differences, was the ranking of the risks related to sensitive information and access control; as the participants increased their understanding of what the COSTT system will be, they also increased their worries of sensitive information leakage, while they decreased their worry of the access control mechanisms not being strong enough. We choose to present the results from the latter only, because that is sufficient in order to cover all identified issues.

Table 1 presents all assets and risks identified. Note that the categories of assets and risks are not considered to be mutually exclusive. The participants themselves sorted the input from their brainstorming process and gave names to the categories of information. The assets mainly include types of information available in the system; both to be displayed on the screen and underlying Info displayed to persons not concerned, deduction of patient having a sensitive diagnosis, unintended access to sensitive info, hacking/data theft, info is taken out from the hospital Unintended/erroneous use [START_REF] Bullock | An access control framework for multi-user collaborative environments[END_REF] Location tag theft, active bypassing of access control lists in other systems, bypassing physical access control, unhealthy changes in work processes, employees working against the system or refusing to use it, conflicts due to low efficiency Patient [START_REF] Gjaere | Personal health information on display: Balancing needs, usability and legislative requirements[END_REF] Patients choosing a different hospital, theft of patient data, patient info known to public press Access control [START_REF] Faxvaag | Visualizing patient trajectories on wall-mounted boards -information security challenges[END_REF] Limitations hide important data when it should be available, bugs giving illegitimate access Wrong focus [START_REF] Faxvaag | Visualizing patient trajectories on wall-mounted boards -information security challenges[END_REF] Fussbudget, loss of efficiency, debates on prioritizing, critical questions due to insignificant errors Relatives (0)

Creating unnecessary feelings, unhappy relatives calling frequently on health personnel Public (0)

Negative newspaper headlines information needed to make the system work properly. Also, parameters that can be deduced from information in the system are considered valuable assets. The risks span from concerns of the underlying sensors not being able to catch events to breaches of both patients' and employees' privacy. The numbers listed in parenthesis in the column of categories indicate the prioritizing done by the process participants. In the table, the risks are presented in prioritized order.

Identification of Evaluation Criteria

In the process of identifying evaluation criteria, we focused on the highest ranked risks. The criteria are referred to as C1, C2 etc., which constitutes a mapping to table 2 where they all are summed up.

Poor quality of data: The main risk was considered to be poor quality of data. As shown in table 1, this is mainly a concern about the underlying system not being able to catch and/or interpret events correctly. In the COSTT project, the coordination information that is to be displayed on the screens are built by capturing events in other information systems [START_REF] Wienhofen | Poster: Representing events in a clinical environment -a case study[END_REF]. Simple events (e.g. access to the medical record of patient A by a given health care personnel) are combined into composite events (e.g. cardiology assesment of patient A has been performed), and it is these composite events that will be displayed on the screens. It is however important to be aware of the uncertainty involved in the event enrichment process. As an example, access to medical record of patient A can indicate that the care personnel that accessed the record is performing an examination of the patient, but it can also be that the health care personnel is preparing for the examination. Thus, events in the COSTT system will be associated with a quality attribute that is a measure of the validity of the event [START_REF] Wienhofen | Poster: Representing events in a clinical environment -a case study[END_REF]. This quality attribute should ideally influence the access control decision, as presenting information that is correct is an important part of the information security of any system (integrity). This is reflected by the data quality awareness criteria (C1).

Surveillance of employees:

The next highest ranked risk was that of surveillance of employees. This covers the employees' fear of being monitored and the possibility for management to misuse registered data about their employees to measure efficiency or other statistics. Data registered for the purpose of COSTT may not give the complete and correct picture of employees' actions, which means that it should be used with high caution, if at all, for management purposes. Thus it is relevant to consider whether the solutions increase the need for surveillance, e.g. by requiring location information (C2). Employee surveillance is also related to what information is published on the screens (further addressed for the risk of sensitive personal information).

Sensitive personal information: The third highest ranked risk is that of displaying sensitive personal information in ways that makes the information available to unauthorised persons. It is important that solutions are able to maintain privacy of both patients and employees, and strive towards the ideal solution where everybody gets access to what they need -and no more. This is reflected by the privacy preserving criteria (C3).

Unintended/erroneous use: The risk related to sensitive personal information should also be considered together with the risk of unintended/erroneous use (rated fourth) and also the much lower prioritized risk related to access control. The concern that access control does not support the work flow is reflected in all these three risks. Failure in this respect can lead to active bypassing of access control due to important information not being available (C4). To meet this challenge it is important to consider dynamic and/or user controlled access control solutions that is able to fit into the way people work. It is also important to consider the effort required from users in order to use the systems in a secure manner (C5), as expectations on user involvement may require changes in work processes in itself in addition to requiring time and effort from the users. This The ability of the solution to take the data quality into account in the access control decisions.

C2 Minimisation of employee surveillance

The need for use of employee surveillance techniques, e.g. for monitoring the location of employees.

C3 Privacy preservation

The ability to restrict sensitive/private information to those that are authorized for access.

C4 Availability ensurance

The ability to ensure that information important for safe and efficient treatment of patients are available when needed. This can e.g. be ensured by using dynamic approaches able to adapt to the situation , or to ensure that users can override the access control decision.

C5 Workload reduction

The ease of use for users. Solutions that rely on user cooperation will require some time and effort on behalf of the users.

C6 Complexity

The more complex the access control mechanism is the higher risk of mistakes that may render the access control solution vulnerable. influences the perceived system efficiency and is likely to have an impact on the employees' attitudes towards the system; employees working against the system or refusing to use it. Risks related to access control can also increase with complexity (C6). With complex access control solutions it is easier to make mistakes e.g. during implementation or during policy specification.

Evaluation of access control approaches

Table 3 summarises the evaluation of the suggested access control approaches with respect to the evaluation criteria. A '+' indicates a positive score while a '-' indicate a negative score. A score of '-/+' indicates that the approach is able to meet the criteria to some extent, but not fully. A '?' is used in situations where the evaluation result will depend on trade-offs made when defining access control policies. A '*' is used to illustrate that the score depends on the mechanism used to determine who is present.

The location-based approach is in many ways the most simple approach. Its ability to meet the needs of COSTT is however dependent on how easy it is to determine beforehand which information should be available in given locations. As several of the envisioned locations (e.g. corridors and examination rooms) are likely to be accessed by a number of different groups of users, we envision that it will be difficult to make such pre-set trade-offs that are able to meet the criteria for both privacy and availability.

The minimum approach is unlikely to meet the availability requirements of the users in need for most information. The same way, the maximum approach will probably result in too many privacy breaches, as everybody will get access to whatever information should be available to the one present with the highest access rights. Considering group structure is likely to perform better than using the minimum/maximum access rights, but is complex and its success depends on the ability to make proper trade-offs between the access rights of the highest and lowest ranked users present.

Relying on a facilitator seems to be a solution that could fit COSTT well, as it is able to meet the majority of criteria to some extent. The privacy achieved will be dependent on whether we can trust the facilitator to make good decisions as to what information to display in given situations. In a study of clinicians' experiences related to privacy and security of health information systems [START_REF] Fernando | The health information system security threat lifecycle: An informatics theory[END_REF] Fernando and Dawson noticed that most clinicians used measures such as lowering their voices and omitting to ask relevant questions in order to protect privacy and security when residing in a shared workplace. At the same time they found that privacy and security implementations on electronic health information systems often took time from patient care, and were therefore considered to hamper patient care. Sharing of passwords was mentioned in this study, as well as in a study by Vaast [START_REF] Vaast | Danger is in the eye of the beholders: Social representations of Information Systems security in healthcare[END_REF]. In his study he also found that physicians were concerned that employees on wards were overwhelmed with work and therefore were likely to forget to close programs or patient charts. To be able to reach a conclusion as to whether the facilitator approach is adequate in the COSTT setting, more research is needed on the situation in which the COSTT system will operate when it comes to the work process and the general attitude of the employees.

Making the access control solution more situation aware is also likely to improve the trade-off between privacy and availability, but at the cost of complexity. This is the only approach that has the potential to meet the data quality awareness criterium.

The pop-up/handheld extension also seems promising, and is able to meet the majority of criteria. By implementing this extension one is able to introduce more flexibility and user involvement without sacrificing privacy. It should however not be used as the only approach.

To sum up, none of the access control approaches studied is able to meet all evaluation criteria. However, the ones that seem most promising are either using the facilitator role or using an access control solution that is situation aware. Alternatively, one of the more simple automatic approaches, e.g. the locationbased approach, can be combined with the pop-up/handheld extension.

The preliminary evaluation performed is based on a risk analysis of the COSTT system at an early stage and with participants from the project group. At this stage the project participants are the ones most likely to have the best understanding of how the COSTT system will work and what are the main challenges and risks. The results of the risk analysis would however be more reliable if it had included project-external representatives as well.

Basing the preliminary evaluation on the results of a risk analysis is useful in that the evaluation criteria will be risk-based and likely to reflect the top issues. The criteria derived are however high level and have not been evaluated by the intended users of the system. It is also not possible from this initial evaluation to state how the different access control approaches will perform in real life. User evaluations are needed in order to assess how the alternative approaches are able to fit the work processes of the perioperative domain. In particular we suspect that the facilitator-based approach, though getting good scores in the evaluation, will fail in this respect.

In the evaluation of the alternative access control approaches, we have studied the approaches individually and evaluated how they perform related to the identified criteria. It is however possible to combine several of the approaches into a final solution and in this way achieve a solution that better fits the needs of COSTT. To illustrate, screens in waiting rooms may have a preset access level (location-based approach) while screens at other locations may have a maximum access level that is determined by their location but where the group structure, the general situation or a facilitator determines the access level at a given point of time. It is also possible to use the extension suggested where individual employees can get access to more information by utilizing pop-up windows or handheld devices. The preliminary evaluation of the approaches suggests that future work looks into combinations of the location-based approach, the facilitator approach, the situation aware approach and the pop-up/handheld extension approach. The location-based approach is a simple one with the possibility of offering good baseline security. The facilitator approach is able to meet the majority of the criteria. The situation aware approach is the only one able to meet the data quality criterium, and has the potential to also perform well on most of the other criteria. The pop-up/handheld extension approach has good scores on both the privacy and availability criteria.

As the location-based approach is in many ways the most feasible solution, we plan to use this solution as a starting point and look into how it can be combined with risk-based access control approaches in order to add situation awareness. Making proper trade-offs between the risk of privacy breaches and the risk that information is not available is central to the success of the COSTT solution. Risk-based access control solutions can utilise knowledge of the screens' location in order to determine the probability of privacy breaches, as well as the availability requirements for an information item. Other context information, like the time of day and who is likely to be present, can influence the risk evaluation as well. This way, the combined solution will likely perform better on the criteria related to privacy (C3) and availability (C4). In addition, the quality of the information can be taken into account (criterion C1). Though the facilitator approach gets quite high scores on the criteria used in our evaluation, we believe that this solution will not be usable for this type of systems, as it requires quite a lot of interaction with the users. Instead we recommend using handheld devices in combination with large wall-mounted screens in cases where highly sensitive information is needed (to better meet criteria C3 and C4).

Conclusion

The main contribution of this paper is a preliminary evaluation of several approaches to access control for public screens used in a perioperative setting. The evaluation criteria used are derived from a risk analysis of the COSTT system. In the evaluation, the facilitator based and the situation aware approaches received high scores, and so did the possible extension of using pop-up windows or handheld devices to get access to additional information. Of the simpler and most feasible approaches, the location-based approach turned out to be the best candidate. As none of the approaches were able to perform well on all evaluation criteria, the results motivate to look further into combining access control approaches. As there are major usability concerns with the facilitator approach in this setting, we recommend focusing on extending the location-based approach with situation awareness, and add support for pop-ups or handheld devices.

Table 1 .

 1 Identified assets and risks

	Category	Assets
	Patient information	Identification, medical data, secret relations, irrelevant health
		history
	Employee information Name, role, actions, personal data
	Location data	Position for all tagged persons, info about rooms, movements
	Aggregated/reasoned	Efficiency of employees, process statistics, surveillance of proce-
	data	dures
	Deviations	Unwanted incidents, info on operations, system errors in hospital
	Usefulness	Utility value by using the COSTT system
	Category	Risks
	Poor quality of data	Drawing wrong conclusions on what info means, inaccurate
	(9)	catching of events, misinterpretation of events, coordination
		trouble due to erroneous data, patient injury
	Surveillance of em-	Management	monitoring	efficiency	of	employees,
	ployees (6)	wrong/incomplete statistics on employees, employees feel
		they are being monitored, public negative exposure of some
		employees
	Sensitive personal in-
	formation (6)

Table 2 .

 2 Identified criteria based on risk analysis

	Nr Criteria	Explanation
	C1 Data quality
	awareness

Table 3 .

 3 Evaluation of access control approaches with respect to the selected criteria

	Approach	C1 C2 C3 C4 C5	C6
		qual. surv. priv. avail. workl. compl.
	Location-based	-	+	?	?	+	+
	Minimum	-	-	+	-	+*	+
	Maximum	-	-	--	+	+*	+
	Group structure	-	-	?	?	+*	-
	Facilitator	-	+ -/+ +	-	+
	Situation aware	?	+	?	?	+	-
	Extension: Pop-up/handheld -	-/+ +	+	-	+

See Gjaere et al.[START_REF] Gjaere | Personal health information on display: Balancing needs, usability and legislative requirements[END_REF] for more information on de-identification solutions for this kind of systems.

Developed by the Co-operation Support Through Transparency (COSTT) research project. http://www.costt.no

The purpose of locating users will NOT be surveillance of all their movements and actions.

Inspired by the asset identification method described by Jaatun and Tøndel[START_REF] Jaatun | Covering your assets in software engineering[END_REF].

Acknowledgments

Thanks to the COSTT project group for participating in the risk analyses. Thanks also to Torstein Nicolaysen for his work in a related MSc thesis, and to Åsmund A. Nyre, Arild Faxvaag, Andreas Seim and Warren Sandberg for reading and commenting on this paper during the writing process. This work has been performed as part of the COSTT project that is supported by the Norwegian Research Council's VERDIKT program (grant no. 187854/S10).