1s.web.umkc.edu/ssk7bd/Project2.doc · Web viewProtection approaches taken so far include cryptography and Role ... (e.g. Microsoft Word, Adobe Framemaker ... Socket and Java Cryptography

590 L – Project Proposal – Sravanthi Karumanchi, Shalini Pradhan, Galina Walters

Project Proposal

590 L – Distributed Component Architecture

Medical Data Analysis

Team Members:Sravanthi Karumanchi

Shalini PradhanGalina Walters

1


1. Introduction

In Today’s computerized environment, as the speed of business and services increases, the requirement for interchange of data without human intervention and with data security becomes a high priority. This imposes tremendous pressures not only on individuals or individual companies, but also across entire aggregations or associations that spans multiple participating companies. Important factors in sharing personalized or business data, such as Patient Information within the Health Care Industry, in both intra-company processes and distributed application interactions between participating companies is the security of information and the use of agreed upon data definition standards. Personalized data that is customizable for human viewing as well as for interpretation by multiple applications is not only desired, it is mandatory to win in the new e-environment. For data to be truly useful in a distributed and heterogeneous system, it must be accessible from different sources and have the ability to be distributed to a variety of targets.

These requirements led to the birth of XML (Extensible Markup Language). XML reduces the obstacles to sharing data among diverse applications and databases by providing a structured data document standard which businesses and service providers can use to share information from heterogeneous sources. This document standard is simple enough for anyone to use elegantly, yet is powerful enough to represent any heterogeneous data. Database and object environment vendors have already committed to supporting XML as one way of outputting data, particularly for publication purposes or interoperability with other software. XML technologies reveal structure in the data that is not organized in relational databases and opens opportunities for database techniques that can exploit the revealed structure.

Today’s dominant DBMSs are broad, mature products that will be hard to displace; they provide efficient update and retrieval of huge amounts of data, highly tuned transaction processing, recovery and integrity, support complex queries with good performance and explicit semantics. Therefore, for applications involving regularly structured data, XML tools do not replace such DBMSs but rather provide XML versions of appropriate views of the data. Sometimes they are created on the fly, in response to user queries, while for other applications the XML may be created in advance. At the same time XML provides support for semi-structured databases offering a hierarchical model, with path operations and irregular structure, or a graph-structured data model with sequence structure.

Security and integrity of information is another continuing problem, mentioned above, common across all industries that rely on and use data stored in computer systems. This problem will only become larger in the future with the increasing automation and integration of divergent systems. Managing large networked and distributed systems with the additional complexity of security administration is costly and prone to error. This is often due to administrators specifying access control for each user individually. Reducing this extreme complexity and high cost of security administration in large networked applications is a very important area for research and development. Creating a standard for identification of an individual and limiting access based on that individual’s membership in a group allows for improved performance and control of access to the system.

As Information Management applies to Patient Information within the Health Care Industry, ensuring the security and integrity of health care records is of prime importance. Problems arise

2


specifically with patient record access and are associated with how to limit access for different types of users to various types of data. Research on this topic is of great value in determining the best standards for development of software implementations and is the subject of my research paper.

Information can be protected from unauthorized access using both Discretionary Access Controls (DAC) and Mandatory Access Controls (MAC), which are the two basic types of access control mechanisms. The creator of the information decides who can access that information with DAC. Because of this, DAC is not applicable for Health Care Records. MAC, however, puts the access decisions in the control of the administrators of the system that stores and handles the information. These decisions are set up as rules, set by administrators, and all those that create, access, and maintain information must follow them. However, this version of MAC is inflexible, making it insufficient for industrial use and inadequate for the Health Care Industry.

The National Institute of Standards and Technology (NIST) has developed Role-Based Access Control (RBAC), a version of MAC, to meet the needs of private industry. Each individual is associated with one or more roles, and each role defines a specific set of operations that the individual acting in that role may perform. When a user is acting in a particular role, he/she accesses information according to the operations assigned to the role. Roles can be defined as specific with detailed rules, or very broad. Individuals may choose between the multiple roles they have been assigned to in accessing information. It remains to be seen if RBAC actually meets all the requirements and needs of the Health Care Industry, but it is generally accepted that it is more closely suited to Health Care that other authentication systems. Several variations include improvements over the NIST version of RBAC but still there are questions open as to which variation is the best for the Health Care Industry.

2. Project Goal and Objectives

2.1. GoalsThere has been a vast advancement in Medical facilities in past years. Hospitals have been technically most up to date. With the enormous amount of data that is generated in hospitals that is very sensitive in many senses the concept of access control is more required here than anywhere else. Not only this amount of research data available to the researchers is of utmost important to the research that is being conducted worldwide. In the era, where all the information is distributed it has become essential to develop a middleware that scales across various databases. Therefore, this has led to a middleware systems that can talk with multiple databases simultaneously and at the same time gives the proper access control to the users accessing it. The representation of the output in an understandable format cannot be understated. XML provides a good tool for this.

2.2. Specific Objectives Developing a configurable database connection Allowing users to be transparent of the database selection by the middleware Generating formatted results by XML in HTML Allowing users to select multiple database columns and get the output required Designating specific roles to various groups of users Allowing researcher to query for research data of various patients by making patients

personal data transparent to him Giving properly formatted output to the researcher Assigning different access levels for different kinds of users (Doctors and Researchers)

3


Allowing data to be called by user interfaces or automated data movement processes Returning an error if more than a single patient match specified criteria Handles common problems such as:

Missing identifiers Invalid SSNs Duplicate identifiers Transposed numbers in DOB Middle/First Name transposed Last name changes due to marriage. (All other attributes match – Generate Exception

Report: e-mail to user)

2.3. SignificanceA well-maintained medical record also allows other health care providers to quickly read and understand past and current patient health concerns. The medical record is a legal document, which records events and decisions and may provide significant evidence in lawsuits, hearings or inquests when the patient care provided by a physician is in question. Medical records are fundamental components of external reviews, such as those for quality improvement purposes or investigative or inquiries. Regardless of the type of assessment or investigation, a good or bad medical record may have a significant positive or negative effect on the outcome of the process.

3. Project Background

3.1. Work Done by OthersToday in medical database systems medical images are important part of the patient record, making today’s medical records multimedia in nature. As any other private information, the medical images have to be protected and have access provided only to certain people with authority for certain pieces of information. Protection approaches taken so far include cryptography and Role-Based Access Control (RBAC) but it is not enough. Cryptology can only solve authentication and secrecy aspects, and RBAC can provide access control based on certain roles assigned to people according to their need to access specific information. Medical image database systems include content-dependent, context-dependent, and time-dependent constraints that demand the application of a set of requirements for protection, which cannot be implemented using the previously listed approaches. To provide the necessary level of protection and access control to multimedia medical data, the extended Role-based access control model containing the Role-Permission relationship phase is introduced [1]. The updated model provides the advantages of role-based access control using the notion of roles as well as adding flexibility based on the time the image was created. This puts validity limitations on a policy.

A physician asking for access from a non-trusted domain might be blocked through the use of Semantic content of the image, for example, when an image such as a melanoma (with semantic context), should not be available for access. Locations where open access to any images should be allowed for a physician might be from the emergency room. The relationship between the patient whose image is to be accessed and the user, who tries to access the image, might be checked to insure the user is the patient’s PCP (primary care physician). In the model introduced, the content-based constraints deal with the presence or absence of a referenced object in a particular location.

The main components of the extended RBAC model are Users, Roles, Permissions, User-Role (U-R) relationship and Role-Permission (R-P) relationship. There are two extensions to the extended model.

4


The first extension is a notion of user attributes that can be presented as following:

{user_id, user_name, domain, location},

Where user_id is the user identifier, user_name is the user name, domain is the department where the user works, and location is a dynamic attribute and the place where the user is trying to access information from.

The second extension is Role-Permission relationship that is 5-tuple:

{identifier, s: r, {action}, t: target, constraints(s, ,t) },

Where identifier is the permission identifier, s is subject to which the permission is applied such as user, r is role which can be assigned to certain subject, action is the operation that can be taken by role, t is object on which actions are to be performed, target is the object type and constraints(s, t) set applicability limitations on the permission. Constraints are applied to and must be followed by s and t [1].

In order for the holder of the permission to use those permissions, the Role-Permission relationship must be satisfied. That relationship is a decision rule specifying what those constraints are. So according to access control restrictions, the basic algorithm of the model is to verify user access using role constraints. For example, a user u, trying to access image i using a privilege p under a certain role r, is authorized to do so under the rule enforced by the role, or the user is not authorized.

A different solution for a selective interaction with a medical database, such as access to detailed information on particular patients healthcare encounters, based on Role-Based Access Control is implemented as Integrated Electronic Health Record (I-EHR) supported by the Patient Clinical Data Directory (PCDD) system [2]. PCDD is a middleware implemented in CORBA and providing I-EHR services based on role-based authorization access to distributed and heterogeneous segments of patient’s clinical information. The information about clinical objects is stored in the directory and connected with PCDD using LDAP (Lightweight Directory Access Protocol). Two levels of security support the implementation; HYGEIAnet Virtual Network (VPN) to provide restrictions on virtual servers and directories, and encryption and authentication of communications to secure insecure channels based on a regional certification authority. The role and authority of users and services (applications) are certified within the regional healthcare network by the certification authority. Access control is achieved by means of user profile information (PCDD server communicates with a Healthcare Resource Directory (HRD) via a dedicated CORBA-based IDL interface). In this context, any patient is able to have complete access to all of his or her own personal information. A physician has access to all information that has been provided by him, as well as to his/ her referral data. In addition, patients are able to grant and restrict access to their personal information. In critical situations, such as in emergency healthcare episodes, the physicians, or defined actors (user groups and roles) have the right to access any patient's medical record. These emergency accesses, however, are logged. Accordingly, the logged information is later reviewed so it is possible for the actor to afterward defend the access made. This creates a trade-off between open access emphasizing auditing, that is, "who accesses what type of information at what time," and the enforcement of very tight security constraints.

5


The way medical records managed in this project are formulated in an access control policy. This policy includes all aspects of access control and security described as access control rules. Based on the above aspects a Rule-Editor module is designed and developed within the LDAP context for use by the PCDD administrator. With this module, the administrator adds and deletes rules, using current requirements such as national healthcare legislation (rulings on keeping and sharing clinical data) and the healthcare organization’s own policies. Access to specific segments of patient clinical information is controlled, either allowing or denying access to patient’s medical encounters. The main operators of an access rule to be used are: 1. The Access {Allowed, Denied} operator.2. The User_Group {Physician, Patient/ Citizen} operator.3. The Clinical_Encounter {distributed_healthcare_unit_information_system} operator. This entire control strategy is implemented using the LDAP framework. The component defining the rule-editor is an application, implemented to operate over a normal Web browser in Perl CGI scripts.

In this paper, the Patient Clinical Data Directory (PCDD) service is the core component for an implementation of the I-EHR. With PCDD, medical encounters from distributed clinical information systems that operate in respective healthcare units on the Island of Crete are integrated with heterogeneous patients' records. This system enhances PCDD operations, using a key-feature that makes it more reliable for the healthcare community. This key feature is a specially tailored and developed rule-editor for administrating the access to medical data, and is based on pre-specified security policies, users' roles, and privileges. The encounter-level of patients' history is used for the location of access-control.By letting healthcare actors to view parts of the medical encounter, such a lab test results, data access control can be implemented in future releases.

The solutions introduced in this section are all based on RBAC with some extensions or modifications. The following approach is based as well on RBAC emphasizing relationships between entities such as the user, the object to be accessed, and the subject of the information contained within the object [3]. The offered model studies Object Management Group’s (OMG) Resource Access Decision facility (RAD) and how relationships can be supported in role based access decisions. By using the RAD in conjunction with RBAC and separating

the access decision logic from application logic, the Role Based Access Control model and mechanism have proven to be useful and effective. Decisions must include other factors however. There are many common examples where access, using things in addition to roles, must be used in order to obtain a result of an authorization decision. They are attributes, object attributes, user relationships to other entities, time of day, location of user, etc. In Barkley’s paper [3], two different types of relationships are introduced: the relationship as an entity and a dynamic relationship.

In the first case, the relationship is used to define an entity and capture information that belongs to it, in the second case, information is changing frequently and must be constantly updated. For example, consider the relationship between physician and a patient: “attending-physician”. The individual physician entity is identified and maintained in most healthcare systems, using such things as name, address, and specialty. There is a many-to-one relationship between both attending-physician and patient, and this may be highly dynamic, or constantly changing. If the relationship is created where a role is a data attribute of the user, such as only an “attending-physician-to-John” role, this approach can result in the following: The attending-physician relationship is redundantly stored in two locations.

6


The role database has to be updated by administrator every time the “attending –physician” relationship is changed for a user.

The large active role sets are developed when the user is a doctor.

The alternative approach would be to include relationship information in the access decision. Permissions for a user in the physician role would be determined based on the physician role, the individual patient, and attending-physician relationship between the user in the physician role and the individual patient. A central authority, in this case, such as a security administrator, may not maintain the relationships, but instead be managed by other components of the system. For example, the registration component of the healthcare information system may manage the attending-physician relationship.

The RAD facility is one approach for including relationship information in role based access decisions. With RAD, a component external to the application handles the authorization logic services. Thus, the authorization logic is encapsulated and hidden, separate from the main access logic. Below is a simplified schema of interactions showing the application client, an application service, and an instance of the RAD. Numbers identify the order of steps taken:

An application obtains an access to a RAD service and that service enforces decisions to perform application-level access control. Between the decision service and the application, Interfaces are implemented to allow independent deployments of the distinct systems. As result RAD allows dynamically changing relationships to be included in role based access decisions by providing the capability for: The separation of access control logic from application logic. The representation of relationship information as dynamic attributes whose values are set as a

result of normal processing by applications. The combination of access decisions derived from a relationship access control model

separate from the RBAC model.

We want to make this project even more interesting by retrieving data using XML. It has been found that XML makes accessing the databases easier. XML-Enabled Databases are databases (usually relational) that contain extensions (either model- or template-driven) for transferring data between XML documents and themselves. XML-Enabled Databases are generally designed to store and retrieve data-centric documents. This is because data is transferred to and from user-defined tables, rather than tables specifically designed to model XML documents. However, many of them can store document-centric documents in a single column and use text-processing extensions for queries. XML documents fall into two broad categories: data-centric and

7


document-centric. Data-centric documents are those where XML is used as a data transport. They include sales orders, patient records, and scientific data. Their physical structure -- the order of sibling elements, whether data is stored in attributes or PCDATA-only elements, whether entities are used -- is often unimportant. A special case of data-centric documents is dynamic Web pages, such as online catalogs and address lists, which are constructed from known, regular sets of data. Document-centric documents are those in which XML is used for its SGML-like capabilities, such as in user's manuals, static Web pages, and marketing brochures. They are characterized by irregular structure and mixed content and their physical structure is important. To store and retrieve the data in data-centric documents, you will need a database that is tuned for data storage, such as a relational or object-oriented database, and some sort of data transfer software. This may be built in to the database or might be third-party middleware. Depending on your needs, you may need Web publishing abilities as well.

The paper listed in [6] gives an overview that describes a way that the XML document can be stored as XML columns or decomposed into multiple DB2 tables and columns. This paper also talks about a way in which XML document can be obtained from existing DB2 data. They talk about a way to generate an XML document from SQL queries against DB2 or any ODBC compliant database using Net.data. They have given us examples about using XML to generate data and thus provide a better way to show to the users. They also discuss another way to generate XML document with automated tags by using stored procedures, dxxGenXML() and dxxRetrieveXML(), provided by the XML extender. For establishing the above mapping of DTD against relational tables or queries using DAD.

The next paper, as illustrated in [7] describes XML based firewalls. IP firewalls and site access tools play a vital role in enterprise security and content management. Thus the concept of firewalls is very very important. Site management solutions, VPNs, encryption, and packet firewalls were developed to relieve application programs from the burden of handling security management issues. Current web-based application server architectures are too complex, inflexible, and monolithic. Even though they present powerful solutions toward building web applications such as EJBs, security managers, and configuration tools, they can lose developers in a maze of options. Agent-based approaches within web application servers help separate some of these concerns by modularizing orthogonal concerns, but agent-based systems resemble the blackboard processing model which has proved non-scalable in many industrial strength applications. The content firewall model applies high-level rules to generate XML transformations dynamically. Non-programmers could configure these rules so that information assurance policies can be quickly expressed, implemented, and audited outside the core business logic of an application server. Using a layered architecture, the performance of a content firewall can be optimized by pipelining the transformations, by caching back-end data requests and responses, and pre-generating transformation templates. It seems logical that one of the next steps in the development of a semantic web is the evolution of firewall technologies to address semantic concerns. IP-based firewall protections and intrusion detection systems are essential to security, but inadequately address the needs of B2B applications in a net-centric world. By separating out orthogonal layers of concern through XML filtering, a content firewall helps to improve the scalability and evolution of network computing. This paper discusses a very key issue, which is security. Since these are web-based applications, security is a key issue. Firewalls are used to act as filters. They described a process to design content firewalls to pre-process requests and post-process responses at a semantic level using a series of intelligent XML transformations. They apply high-level rules to generate and apply XML transformations dynamically. These rules can be easily configured so that information assurance policies can be

8


quickly expressed, implemented, and audited outside the core business logic of a web or application server. It can be configured as a front-end or as a back-end. Having security issue is a very key point when we think of database access. This is because unauthorized users can access very important or critical data and also may modify the data.

The paper by Dare Obasanjo [8] talks about a language XML querying: XPath and Xquery. Xquery is an attempt to provide a query language that provides the same breadth of functionality and underlying formalism as SQL does for relational databases. It is a functional language where each query is an expression. This paper talks about data centric model, document-centric model and hybrid model. Data centric model is where data is stored in a relational database or similar repository. In data centric model, XML is used as storage or interchange format for data that is structured, appears in a regular order and is processed by a machine than read by a human. In the recent years human intervention is strictly avoided. The data is stored or transferred as XML is typically incidental since it could be stored or transferred in a number of other formats which may or may not be better suited for task depending on data and how it is used. They have illustrated this concept with examples. In Document-centric model, Content management systems are typically the tool of choice when considering storing, updating and retrieving various XML documents in a shared repository. A content management system typically consists of a repository that stores a variety of XML documents, an editor and an engine that provides one or more of the following features like version, revision and access control, ability to reuse documents in different formats, collaboration, web publishing facilities, support for a variety of text editors (e.g. Microsoft Word, Adobe Framemaker, etc), indexing and search capabilities. Content management systems have been primarily of benefit for workflow management in corporate environments where information sharing is vital and as a way to manage the creation of web content in a modular fashion allowing web developers and content creators to perform their tasks with less interdependence than exists in a traditional web-authoring environment. In Hybrid model situations where both documentric-centric and data-centric models of XML usage will occur, the best data storage choice is usually a native XML database. What actually constitutes a native XML database has been a topic of some debate in various for a which has been compounded by the blurred lines that many see between XML-enabled databases, XML query engines, XML servers and native XML databases.

The paper that talks about Oracle8i [9], which is XML, enabled to handle the current needs of the market. Oracle8i is capable of storing structured XML data as object relational data, and unstructured XML document as intermedia text data. Oracle8i also provides the ability to automatically extract object-relational data as XML. Efficient querying of XML data is facilitated using SQL. Oracle8i also provides the ability to access XML documents using the DOM API. Since we intend to use one of the database as Oracle this paper gives a good example.

The paper illustrated in [10] talks about SQL language extension (the XML constructor) to specify the construction of XML documents from relational data. By extending SQL in this manner, applications can reuse the existing infrastructure and APIs for SQL to extract XML documents from relational sources. This paper was devoted to exploring efficient mechanisms for publishing relational data as XML documents, independent of the actual language used to specify this mapping. Towards this end, they characterized the solution space based on the main differences between XML documents and relational tables, namely tags and nested structure. They then explored various alternatives in this space, paying special attention to the amount of processing that can be done inside the relational engine. They showed some experimental results. These showing moving all processing inside the relational engine can provide a significant performance benefit. This is because the high cost of binding out tuples to host variables is

9


eliminated. The method that they used is efficient and is a robust way to retrieve the relational data needed to construct an XML document. In the unordered outer union strategy, the tagger uses a main memory hash table to assemble the XML objects, which requires the XML view fit in main memory. In CLOB De-correlated queries, the relational engine constructs the XML result, which is also effective when the XML view fits in the main memory.

3.2. Relationship of our project with the current research

Security and integrity of information is a continuing problem across all industries that rely on and use data stored in computer systems. This problem will only become larger in the future with the increasing automation and integration of divergent systems. Managing large networked and distributed systems with the additional complexity of security administration is costly and prone to error. This is often due to administrators specifying access control for each user individually. Reducing this extreme complexity and high cost of security administration in large networked applications is a very important area for research and development. Creating a standard for identification of an individual and limiting access based on that individual’s membership in a group allows for improved performance and control of access to the system. As Information Management applies to Patient Information within the Health Care Industry, ensuring the security and integrity of health care records is of prime importance. Problems arise specifically with patient record access and are associated with how to limit access for different types of users to various types of data. Security is a key issue when we talk about accessing databases as we should not allow access about patients to the entire world. This project works on this issue and also displaying data in XML format. This is a key issue as the information displayed to the users must be fast and also must be very readable. XML makes database access a fast process. One more issue that we look at in this project is to be able to access data from heterogeneous databases as the platform of these databases could be different i.e., one database could be in SQL and other could be in Microsoft Access. There is a lot of work and research being done in accessing data of the patients and also keep it secure and also the relationships between XML and databases.

10


4. General Plan of Work

4.1. Domain Analysis

Use Case DiagramWe have chosen to use Use Case diagrams and statements to document the system requirements for the Medical Data Analysis project. We have chosen to use a system context diagram to describe our project

Medical Data Analysis System Context Diagram (Class Diagram)

The human user interacts with the system by means of a standard I/O device such as the keyboard and Monitor found on the CPU. The characteristics of these standard I/O devices are of no interest because they are handled by the OS and therefore depicted as the <<external user>> in the diagram

11


4.2. Design of Activities to be Undertaken

This section discusses what activities need to be undertaken to do Medical Data Analysis Project.

Develop UML Class Model

We will attempt to map persistent objects to the tables through development of a class model. Thus we will identify classes, associated objects, attributes, operations, and associations. We will also be able to identify hierarchies (composition, aggregation, inheritance) and possible constraints.

Develop Dynamic Model/Object Interaction Model

We will build the sequence diagram and create Object Interaction Models. Thus we will be able to document which objects invoke the operations of other objects (documents the direction in which one object sends a message to the other object). We will identify all interfaces (abstract classes) and implementation classes.

Program Application Server

To familiarize the team and build skills on EJB implementation each team member will program an application server (JBOSS), compile the Java files, make the deployment descriptor, deploy the EJB, and run an application.

Heterogeneous Databases

This project includes implementation with different kinds of databases. The doctor, nurse or a scientist can access data from multiple databases. So we plan to work in such a way that the databases are from different platforms.

Retrieving data in XML

We intend to retrieve data in XML formats so that it is easily viewable by the users.

Access Control

We intend to adapt a filter to make sure that a doctor gets to see all records of his patients but the scientist does not get to see the details that don’t concern his research, which include social security number or name of the patient. That is the data is retrieved according to the user roles specified.

4.3. Description of methods and procedures

This section lists all the main procedures that are going to be included in the project implementation in order to archive our goals.

12


Procedure 1. User Identification. When user enters his/her user name and ID, the system verifies the entered data with information stored in the system’s user information database. If user is not valid, ‘not authorized’ message is going to be displayed. Possible implementation: HTML Servlet Session Bean Entity Bean database. Procedure 2. Retrieval of list of operations allowed for the user according to mapping between his/her ID and roles allowed.The user information database contains two tables. One consists of user’s name, his/her ID, and roles assigned to this user. Second table includes set of all roles allowed by the system and list of operations assigned for each role. The set of operations allowed for this particular user is retrieved.

Procedure 3. Retrieval of data from the medical databases according to the user’s query.Selected by user, query is sent to the medical database and full information is being retrieved.Possible implementation: HTML Servlet Session Bean Entity Bean database

Procedure 4. Filtering retrieved data according to the limitations and requirements assigned to the user by his/her role.The data obtained from the database is filtered according to the role of the user. Possible implementation: database Entity Bean Session Bean (Filter).

Procedure 5. Converting data into XML format.The filtered data is converted into XML format.Possible implementation: Session Bean (Filter and XML Converter).

Procedure 6. Representing data to the user though GUI interface.The data in XML format is sent to the HTML/JSP page for display.Possible implementation: Session Bean Servlet JSP.

13


4.4. Technology and Tools

JAVA2 Standard Edition 1.3.1_01 and 1.4 BETA 2

The current JAVA2 Standard Edition is 1.3.1_01, but we want to be flexible in the near future and want to build our software with the state-of-the-art Java platform, which is available at the end of our project. This is probably J2SE 1.4. This ensures that we keep track to the evolution of the Java platform. The BETA Version 1.4 builds upon Java technology's cross-platform support and robust security model with new features and functionality, enhanced performance and scalability, and improved reliability and serviceability. Version 1.4 advances rich client application development and provides the foundation for standards-based, interoperable Web services. In addition to new features, version 1.4 is fully compatible with previous J2SE software releases and enhances the connectivity via XML, CORBA, IPv6, and JDBC 3.0 technology. New security features include Java Secure Socket and Java Cryptography extensions, Java Authentication and Authorization Service, Kerberos support, a Certificate Path API, high-performance Java 2DTM graphics, new scalable I/O, and Java virtual machine improvements.

JAVA2 Enterprise Edition 1.3 and 2.0

The current Enterprise version is 1.3 and all application vendors support this specification. Parts of the new specifications 2.0 are now available and can help to increase our outcome. The J2EE platform is designed to provide server-side and client-side support for developing enterprise, multitier applications. Such applications are typically configured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and backend enterprise information systems providing data management. The J2EE platform specifies technologies to support multitier enterprise applications. These technologies fall into three categories: component, service, and communication. The component technologies are those used by developers to create the essential parts of the enterprise application, namely the user interface and the business logic. Since most enterprise applications require access to existing enterprise information systems, the J2EE platform supports APIs that provide access to database, transaction, naming and directory, and messaging services. Finally, the J2EE platform provides technologies that enable communication between clients and servers and between collaborating objects hosted by different servers. In addition to JavaBeans components, which are part of the J2SE platform, the J2EE platform supports the following types of components: applets, application clients, Enterprise Java Beans components, and Web components, which are important for our project. Applets and application clients run on a client

14


platform and EJB and Web components run on a server platform (which is in our case JBOSS). Java containers provide components with services such as life naming, cycle management, security (Authentication and Authorisation, which are very important in the hospital), deployment, and threading. Communication technologies provide mechanisms for communication between clients and servers and between collaborating objects hosted by different servers: Internet protocols, Remote method invocation protocols, Object Management Group (OMG) protocols, Messaging technologies (Java Message Service (JMS), Java Mail) and Data formats (HTML3.2, XML, Image files, JAR files).

JBOSS 2.4.1

J2EE provides a range of server choices. We will use JBOSS 2.4 because it is free, available, and open-source. An independent study shows, that the JBOSS 2.2 has good performance and sufficient scalability for our project. Because we do not have to use JBOSS specific features, the EJB-jar files can easily be transferred to another Application server.

MS SQLServer & MS Access 2000

These are the databases that we will consider for the development purposes. The data would be stored across these two databases. For the JDBC-Connection the free available Sun JDBC-ODBC Bridge or FreeTDS Type 4 driver can be used, but this is not recommended for serious J2EE development or deployment. For our small project this does not cause a problem, but should be kept in mind for future development. A lot is known about these two databases developed by Microsoft.

Microsoft XML 3.0

We need a Markup Language that can format and present the output in a proper format. XML stands for EXtensible Markup Language. It is a markup language much like HTML. XML was designed to describe data. The tags are not predefined in XML. You must define your own tags. XML uses a DTD (Document Type Definition) to describe the data. XML with a DTD is designed to be self-descriptive. XML was designed to carry data. XML is not a replacement for HTML HTML is about displaying information, XML is about describing information.http://java.sun.com/j2se/1.3/relnotes.htmlhttp://java.sun.com/j2se/1.4http://java.sun.com/j2ee/blueprintshttp://www.javaside.com/us/jspChart.shtmlhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmtutxmltutorial.asp

4.5. Time table for project completion

(See attached Page)

15

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmtutxmltutorial.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmtutxmltutorial.asp

http://www.javaside.com/us/jspChart.shtml

http://java.sun.com/j2ee/blueprints

http://java.sun.com/j2se/1.4

http://java.sun.com/j2se/1.3/relnotes.html


Bibliography

[1] Tzelepi, Sofia K., Koukopoulos, Dimitrios K. and Pangalos, George, “A flexible Content and Context-based Access Control Model for Multimedia Medical Image Database Systems ”, Informatics Laboratory, Faculty of technology, Aristotelian University, Thessaloniki, Greece, Computer Techonology Instityte and Patras University, Patras, Greece,http://www1.acm.org/sigs/sigmm/MM2001/ep/tzelepi/, 2001.

[2] Potamias, G., Tsiknakis, M., Katehakis, D., Moustakis, V., and Orphanoudakis, S., “Role-Based Access to Patients Clinical Data: The InterCare Approach in the Rgion of Crete “, Center of Medical Informatics and Health Telematics Applications , Institute of computer Science, Foundation for Research and Technology, Crete, Greece, Department of Computer Science, University of Crete, Heraklion, Crete, Greece, Dept. of Production Engineering and Management, Technical University of Crete, Chania, Greece, http://www.ics.forth.gr/ICS/acti/cmi_hta/publications/papers/2000/mie2000/mie2000.html, 2000.

[3] Barkley, J., Beznosov, K., and Uppal, J., “Supporting Relationship in Access Control Using Role Based Access Conrol”, National institute of Standards and Technology, Baptist Health Systems of South Florida, Florida International University, http://www.cs.fiu.edu/~beznosov/doc/rbac-1999-1-paper.pdf, 1999.

[4] NISTIR 5820, “Distributed Communication Methods and Role-Based Access Control for Use in Health Care Applications”, http://hissa.nist.gov/rbac/poole/ir5820/nistir5820.htm.

[5] Sandhu, Ravi R., “Role-Based Access Control Models”, IEEE Computer, Volume 29, Number 2, February 1996, pages 38-47, http://citeseer.nj.nec.com/cache/papers/cs/15046/http:zSzzSzwww.list.gmu.eduzSzjournalszSz computerzSzpdf_verzSzi94rbac.pdf/sandhu96rolebased.pdf.

[6] Cheng, J. M., Xu, J., Feb. 2000. "XML and DB2". In: IEEE ICDE. San Diego, CA.http://www.computer.org/proceedings/icde/0506/05060569abs.htm

[7] Intelligent XML Content Firewalls – John R. Callahan Sphere Software Corporation.http://www.sphere.com/docs/Content_Firewalls.pdf

[8] An Exploration of XML in Database Management Systems by Dare Obasanjo. A general overview of XML and databases, with product-specific discussions about SQL Server, Oracles, DB2, Tamino, dbXML, and others. Also discusses XPath and XQuery.http://www.25hoursaday.com/StoringAndQueryingXML.html [9] Oracle8i- The XML enabled data management system – Sandeepan Banerjee, Vishu Krishnamurthy, Ravi Murthy, Muralidhar Krishnaprasadhttp://www.computer.org/proceedings/icde/0506/05060561abs.htm [10] J. Shanmugasundaram, E. Shekita, R. Barr, M. Carey, B. Lindsay, H. Pirahesh, B. Reinwald, "Efficiently Publishing Relational Data as XML Documents"http://citeseer.nj.nec.com/shanmugasundaram00efficiently.html

16

http://www.sphere.com/docs/Content_Firewalls.pdf

http://www.computer.org/proceedings/icde/0506/05060569abs.htm

http://citeseer.nj.nec.com/cache/papers/cs/15046/http:zSzzSzwww.list.gmu.eduzSzjournalszSz

http://hissa.nist.gov/rbac/poole/ir5820/nistir5820.htm

http://www.cs.fiu.edu/~beznosov/doc/rbac-1999-1-paper.pdf

http://www.ics.forth.gr/ICS/acti/cmi_hta/publications/papers/2000/mie2000/mie2000.html

http://www1.acm.org/sigs/sigmm/MM2001/ep/tzelepi/