| 20040054736 | Object architecture for integration of email and instant messaging (IM) | March, 2004 | Daniell et al. |
| 20030120750 | Device based detection of user preferences in a home networking environment | June, 2003 | Gaxiola et al. |
| 20070250587 | Method for allowing exchange of permissible information between users in a hosting website | October, 2007 | Roberts |
| 20090243852 | Remote Location Monitoring | October, 2009 | Haupt et al. |
| 20100095377 | DETECTION OF SUSPICIOUS TRAFFIC PATTERNS IN ELECTRONIC COMMUNICATIONS | April, 2010 | Krywaniuk |
| 20070233790 | Determining failed delivery of email messages using email notifications | October, 2007 | Agarwal et al. |
| 20080177854 | CONSOLE REDIRECTION AMONG LINKED COMPUTERS | July, 2008 | Khanna et al. |
| 20100064021 | MESSAGE DISPLAY DEVICE AND METHOD | March, 2010 | Kida et al. |
| 20030115311 | Enterprise network infrastructure for mobile users | June, 2003 | Johnston-watt et al. |
| 20050144236 | Identifying a device to a network | June, 2005 | Ying et al. |
| 20060242269 | Hybrid Distribution Method for Playable Media | October, 2006 | Gross |
This application claims the benefit of European Application No. 03104558.6 filed Dec. 5, 2003.
The present invention relates to a method for extracting secure information from a set of secret data, according to selection criteria.
The application U.S. 2002/0166052 by Garg et al describes a System and Method for caching in connection with authorization in a computer system. This system describes a solution to the performance problem that arises when dynamic authorization policies are used.
The application U.S. 2002/0095432 by Shimomura et al describes a document management system wherein access controlling information is added a document prior to registration in a document management system. At the time of the registration, this additional information is used to set the access control information. When the document is subsequently requested, this access control information is used to determine the access rights.
In a medical environment, access control to patient data is an important aspect. In addition, the detailed privacy requirements are complex, dependent on region and customer and can change over time.
Therefore, an expressive security subsystem is required in order to implement medical applications in an economical way.
The above-mentioned aspects are realised by a method having the specific features set out in claim 1 and by a system having the specific features set out in claim 10. Specific features for preferred embodiments of the invention are set out in the dependent claims.
The method for accessing may be seen as being equivalent to a method for access control of confidential data. Security rules are also referred to as authorisation rules. According to the invention, a set of patients may be selected, based upon selection criteria. However, this set of patients may contain a subset, to which the operator must not have access. This subset may then be removed from the set by the security or authorisation rules.
Preferably, all these operations are done on a computer system, which may comprise one or more servers and/or one or more clients. The method according to the current invention may also be performed via web access. The user works at his workstation and may have access to patient data in one or more databases, accessible via a LAN or WAN network or via the internet.
Selection criteria, secure information, secret data and/or security rules may be stored in a computer memory RAM or ROM, on hard disk, a compact disk or any other suitable medium for e.g. electronically storing information. The steps of the method according to the invention may be performed all by one computer, or some steps may be performed by a server and other steps may be performed by a client, separate from a server.
An example of a selection criterion is “all patients who visited this department today”. Another example is “all patients treated by physician X”.
After or by application of the method according to the current invention, the secure information is usually displayed on a computer screen for the user. Alternatively, the secure information may be sent to a printer or sent by e-mail or via a web-link to the general practitioner of the patient. This secure information may be presented in a template, which is suitable for all patients of a specific hospital department.
Secret data comprise data related to the patient. Some of these data are highly confidential, and must be disclosed to just one person or a limited group of persons only, sometimes even with the exclusion of the patient himself, e.g. in case of a lethal diagnosis, which is for less than 100% correct.
The security rules are in principle rules that define which operations may be done on which data by which person. Operations or “access” include creating, selecting, extracting, deleting, modifying, updating and viewing. This list is not exhaustive.
Actions can be added by the applications programmer or the Information Technology Department in the hospital. Such actions are, for example: printing, scanning, e-mailing, access via the web, internet or intranet, listening to a human or machine spoken report, entering a spoken report, etc. The data may be single data elements, such as birth date, sex, name, and one report. These data may also be arranged in a set, e.g. administrative data, medical data, nursing data and psychosocial and family data. Each set may comprise is several sub-groups, in which single data elements are arranged. The person who has a certain type of access to data, may be a physician, a nurse, administrative staff, etc. For each specific user, e.g. physician or nurse, the system could define whether that physician has access to a specific single data element, a specific set, or a specific sub-group. Preferably however, users may be arranged in groups, e.g. “the physicians of the radiology department” or “the nurses of the maternity department”, or a specific user may even be indicated “by reference”, e.g. “the head of the radiology department”. This arrangement has the advantage that specific names of users may be entered in the group, and if the composition of the group is changed, it is sufficient to change the names within that group, to keep the security system consistent. The “group” may be seen as an attribute of the user. E.g. a specific physician may be considered as the head of the radiology department, a member of the cardiology staff, and a nurse of the intensive care department. It is even possible that specific patients, e.g. very important persons or persons employed by the hospital or department, need a specific security treatment, such that for example only the head of the department, or one single physician of the hospital has access to the data of that specific patient.
In a preferred embodiment, the computer system first applies the selection criteria on the secret data e.g. in the usually huge database, and once this selection is made, usually resulting in a restricted set of data, the security rules are applied on the selected information to limit the access of the user, or operator of the method according to the invention, to what he is really allowed to.
Overruling may be done in life critical situations of a patient. In such case, the operator or user of the system may have access to all or almost all data of the hospital database system or even to (almost) all database systems, which may be distributed all over the hospital or even over hospitals within a group of co-operating hospitals. However, if the user overrules the security or authorisation rules, it may be important to keep track of this fact, and to store why the rules had to be overruled by which specific person or user or operator of the system. This may be done by logging of this overruling operation. Logging may even be done for all operations, or access modes, or for a selection of “critical” accesses.
Preferably, an operator has the right to set and to change the security or authorisation rules for individual users, user groups, individual patients, patient groups, specific operations or access modes or sets of access modes. A patient group may be created by entering the patients in a group, or by assigning to each or some patients an attribute, which appoints that patient to belong to that specific group.
Advantages and embodiments of the present invention will become apparent from the following description and drawing.
FIG. 1 shows a system for implementation of a method according to the invention, i.e. an authorisation architecture.
While the present invention will hereinafter be described in connection with preferred embodiments thereof, it will be understood that it is not intended to limit the invention to those embodiments. According to the invention, authorisation or security rules are preferably based on the affiliation of an authorised person to specific personal information, wherein the person is preferably a patient. In a preferred embodiment, an “affiliation” relates to the following concepts:
In a medical environment, the personal information may relate to a patient, whereas an authorised person may be:
For a medical environment, we will refer to personal information as patient information. The patient information may comprise:
Patient information may also been classified in the following classes:
An information element is the smallest piece of independent information. Examples of independent information are:
Some elements may have a time relation. The blood pressure, the body temperature, the length and weight of the patient, past diseases or surgical events, vaccinations are parameters that may need an associated time or time period, with an accuracy of e.g. one month up to one second.
In principle each piece of personal information, referred to as information element, has to be affiliated to each specific authorised person, before that authorised person can access that information element. Not only the information element as such may be confidential information. Also the relation to other information elements may be confidential. For example, the information that a patient, having a specific type of pneumonia, is located in a specific hospital department, may be confidential. The relation between this type of pneumonia and a unique identifier of the patient may be more confidential than the previous information.
In order to increase the efficiency of an authorisation or security system according to the current invention, patients may be arranged in groups referring to a specific hospital department or hospital service, e.g. the patients hospitalised in the maternity department in the Erasmus hospital in Antwerp Belgium.
Also authorised persons may be grouped according to their common authorisations. For example, all physicians associated to the maternity department may be grouped in the group “maternity physicians”.
The affiliation between a specific patient at the maternity department with a specific physician at this department, may then be derived from a more general combination of:
The authorisation rules are thus preferably based on the affiliation.
A system according to the current invention may have the following properties.
Security rules are preferably specified at the conceptual level, rather than at the database level. Objects or “business” objects may e.g. be: physician, transfer, service request, report. A rule being specified at conceptual level, uses the “object” to define what is allowed and what is not allowed. A specification at database level would mean that the user has access to specific columns within the database, and has no access to other specific columns in the database. If a database or a database model has the object “report”, but that report has not the attribute “validated”, or other attributes, then the system may only state that a specific user has access to reports, and another specific user has no access to reports. In a system, where the object “report” has the attribute “validated”, the system can allow access for a specific user to “all reports” and for another specific user to “validated reports” only. Another typical attribute for a report is the “creation date”. Also this attribute may be used as a selection criterion or as an authorisation criterion. For example, a nurse could get access only to the reports created at the current day. Employees of the radiology department may be denied access to radiology reports that are older than 1 week. It is advantageous to specify the authorisation or security rules in terms of attributes. This gives a more flexible system than that where a user can be denied access to a specific column or table in the patient database only for all records in that table. For example, compare the system that supports rules such as
The system having the capability of Rule B only, is more restrictive, has less capabilities, than the system having the option of defining Rule A. The option of Rule A may be made possible by the fact that the rules may have access to attributes, such as the attribute “Report.department” and “Nurse.department” or the cognition of “MY_DEPARTMENT”, for testing:
The value of “MY_DEPARTMENT” may depend on the person or user or operator who logged in, in the system. For example, during logging in, into the computer system, the user may specify his identification, his password, the department for which he logs in, thereby e.g. defining “MY_DEPARTMENT” and the role the user has in that department, e.g. “nurse”, “physician”, “head of the department”, etc.
The secret data may contain information about objects. An object corresponds to an object or person in reality, and may contain information about its state, referred to as attributes.
Examples of objects are: a patient, a physician, a hospital, a department, a report, and an appointment. Attributes for the object “patient” may be: sex, name, birth day. Relations may exist between objects. For example, the object “patient” may have a relation to his “physician”.
The relation between the object that needs access control and the user or group or facility subjects may be explicitly specified. Security rules can be added using attributes of the object and any relationships it has with other objects. Example: the object “report” may have an attribute “validated” which may be “true” or “false”.
A specific rule may check this attribute for this object as follows:
Security rules can be specified per instance, e.g. individual protection for a single report instead of restrictions that apply to all reports.
The security rules may be overruled in life critical situations. In this case all operations are preferably logged to provide an audit trail. The following items may be logged:
Security may be specified as a set of “access control rules”, also referred to as “security rules” or “rules”. A rule specifies whether a certain logical action can be executed on a certain object.
The system may provide a set of predefined of actions, such as:
Application developers can define additional actions when needed.
An Object Query Language (“OQL”) may be used to specify to which subset of objects a rule gives access control. OQL is a query language that allows queries to be expressed in terms of the high-level conceptual object model. These queries can be targeted to very specific situations by using predefined variables such as:
Additional predefined variables can be defined. Rules can be overridden depending on the user, the role the current user is in, the department of the user and the workstation on which the action is requested. In addition, rules may have a priority for defining their precedence.
According to a preferred embodiment, rules are stored in a database and can be changed by an administrator, e.g. by using Qmanager, a product developed and distributed by Quadrat Medical Software N.V. in Belgium. Preferably Qmanager uses a specific component, ECompas, developed by Quadrat Medical Software N.V. in Belgium, to ensure correct application of authorisation rules.
An example of the rule:
A rule, such as a security rule or an authorisation rule that specifies an OQL may very often be related to an object.
In the above example, as the target object is the patient, the rule may be abbreviated as below, since “patient.” is implicit.
OQL: “MyPhysician is ME_AS_DOCTOR”
An embodiment of an Authorisation Architecture is presented in FIG. 1. The authorisation subsystem 10 retrieves the authorisation rules from the database 20 and uses the OQL parser 30 to process them. The authorisation subsystem 10 uses various levels of caching to improve performance. It provides an API (not shown) to query which actions are allowed on a certain object in the current context, i.e. user, department etc.
Applications 60, not based on ECompas 40, 50, can directly use the authorisation subsystem 10, without ECompas 40, 50. Authorisation checks are implemented by inserting calls to the authorisation subsystem 10 at appropriate places in the code. These applications 60 also have to provide the correct values for MY_AFFILIATION etc. In emergency cases, applications 60 can override the access restrictions but they have to implement all audit logging themselves.
Applications 50 developed on top of the ECompas platform 40 can also insert these checks explicitly but can rely on the business object layer 40 for the majority of authorisation cases, e.g. select, create, update, delete actions.
When an application 50 performs an action on an object or a “business” object, the corresponding OQL rules 30 are evaluated to check the whether the action is allowed or not in the current user context. If not, the operation is aborted and an exception is thrown.
When an ECompas application 50 performs a query, e.g. written in OQL, the results are returned as a list of objects. After retrieval of this list, ECompas 50 checks each element of the list for access control. Only the objects to which access is granted are included. The other objects are omitted and as such not visible to the application 50, and are thus not accessible to the user.
ECompas also provides an XML view of an object graph. Objects for which there is no “select” access will have no detail information or attributes exported to this XML document. These attributes are tagged with a security message that explains that access is denied.
Overriding access control coupled with automatic logging to an audit trail for critical situations is also possible.
Having described in detail preferred embodiments of the current invention, it will now be apparent to those skilled in the art that numerous modifications can be made therein without departing from the scope of the invention as defined in the appending claims.