Page tree
Skip to end of metadata
Go to start of metadata

Conventions and restrictions


The process to determine that presented identity information (associated with a particular entity) is sufficient to recognize the entity in a particular domain of applicability is called identification.

Examples:

  • There are three men in a room (domain of applicability) two doctors: Elisabeth and Daniela Altenberg and a patient, Daniela Altenberg. The identities: doctor Doctor Altenberg, Daniela Altenberg are not sufficient to recognize the entity doctor Daniela Altenberg (and the identification based on every of these incomplete identities fails).

  • Another example of identification: for a large amount of unordered papers, the identification of presented identity information “document in a large manila envelope” means to search the papers and the result of identification will be positive if there was just one such document, otherwise the identification fails.


Identity Management responsabilities


Identity Management in general relates to the issuance, administration, and use of identities of entities known in a particular domain of applicability, which is in this case the eHealth DSI environment (together with national eHealth).  The eHealth DSI environment is a set of National Contact Points communicating by means of public networks.  NCPs are interfaces or proxies between national eHealth domains.  These national eHealth domains are not under direct control of eHealth DSI.

Patient data and identities of patients, HPs, HCPOs are placed in registries, repositories or databases in national domains and most of data processing takes place there.  Therefore it must be distinguished between processes running in the intrinsic eHealth DSI environment and the processes running partially or totally outside the intrinsic eHealth DSI environment within the national domains.


The intrinsic eHealth DSI identity confirming and forwarding covers the following points

  • Management of selected identity datasets and/or identifiers
    • of single persons (HP, patient)
    • of a group of persons (legal entity of healthcare providers, e.g. HCPO)
    • of single documents (patient consent)
  • Management of outgoing requests for validation of provided identities within the “Circle of Trust”
  • Management of incoming requests and responses to such requests
  • A secure, trustworthy, and reliable acknowledgement and vouching for the correctness of information provided by the national infrastructure and the HPs


National authorities and institutions from national domains will provide:

  • The accurate management of identities lifecycle, from the creation of identifiers of entities until they terminate,
  • The accurate management of identity assurance, authentication of the identity information, and the assessment of the required level of risk assurance for collecting and using identity information (named “trust level” in the following descriptions),
  • The accurate management of identity information at the level of the relevant identity authorities and
  • The accurate management of local systems and/or services which support the “Circle of Trust” (NCP)

eHealth DSI and authorities/participants from national domains will together provide identification and authentication services.


Entity


Persons (physical or legal), technical devices, systems, documents, data, etc. are called entities. From a functional point of view, entities can be separated into active entities (actors) and passive entities (actors).

Actors can perform various activities in the eHealth DSI. This document concentrates on activities directly referring to access control of patient’s health data and does not deal with activities concerning the technical systems operations (like national authorities, national NCPs, local systems, etc.). They are out of scope of eHealth DSI and this document.


Active eHealth entities


Examples for active eHealth DSI entities are patients, HPs, health data administrators, NCPs and computer systems as part of the eHealth DSI environment. Some entities can be either passive or active depending on the actual situation. This document deals primarily with eHealth DSI active entities (actors).

Formally, a role is a special attribute that cannot be used for identification/authentication, but specifies the activities permitted or allowed to an entity in a domain of applicability.

A role in eHealth DSI implies that an entity has or gets a collection of privileges to access or use resources available in the eHealth DSI environment.


Medical roles in eHealth DSI and in the countries


Please refer to the business requirement: [01.02. Authorize Health Professional (HP) according to assigned roles and profiles] for an exhaustive list of the authorized medical roles.


Identity


An entity can be characterized by its special features (physical appearance, properties, states, status) called attributes. A set of entity attributes is called identity. A complex entity like a person can have a very large set of attributes. For practical reasons, only particular attributes in collaboration are used as identities. An entity can have various identities. Since an identity contains only some of the attributes of an entity, it is not universal. When an entity is linked with a specific domain of applicability, this identity can be identified within that specific domain of applicability, but it may not be sufficient for identifying the entity outside of that specific domain of applicability.

The most important entities of eHealth DSI system are human beings (patients, HPs, administrators, etc). In a family, every member can be characterized by his appearance, voice, etc. In a small collective like a class, the pupils can be distinguished by their surnames. If there are two pupils with the same surname, the given name can be added to their identities. To identify a person in a large population, other attributes like the date and place of birth, address, etc. must be used to the identity.


The information contained in an identity is called identity information.

Example: Daniela Altenberg, born 29.12.1979 in Vienna, Austria, father Gottfried Altenberg (*6.6.1953), mother Elisabeth Altenberg (*6.3.1956, maiden name Eugenie) address of residence Vienna, Castle of Schönbrunn, No 1.)

Identity is an abstract notion and usually the identity of an entity can be represented by an identifier. The identifier is a non-empty set of identity information that uniquely characterises an entity in a specific domain of applicability. Typical attributes which will be combined to identifiers, are the following personal data:

  • Surname

  • Given Name

  • Date of birth (YYYYMMDD)

  • Gender

  • Country of origin

  • Unique Identifier (if available)

  • Other identifiers (e.g.: driver license number, passport no, etc.)


There are many non-human entities in the eHealth DSI. The most important of them are documents in electronic form, which are of course always linked to a human entity.

The validity of identifiers may be limited by date (e.g. number of a passport) or changed by other reasons (e.g. changed name after marriage). So therefore, in many cases a history of all valid values for identity information – including the former ones – is necessary.


Authentication of actors


Identification provides an answer, whether the provided identity information is sufficient to determine the entity or not, but it does not deal with the validity of identity.

Authentication is the process of establishing an acceptable level of assurance that a claimed identity of an entity is genuine. The authentication of a human identity is usually based on one of the following attributes of the entity. However, at least two of them are necessary to obtain a high level of authentication and at least one attribute should be secret:

  • Biometric characteristics such as retina pattern, fingerprints, iris pattern, voice, face image, handwriting, etc.,

  • ID card, passport, authentication token, certificate, cryptographic keys,

  • Secret data such as passwords or PIN-Codes.

The entity attributes used for entity identity authentication must be linked in a trustworthy way to the entity. This is a task of an identity authority - an entity that can make authoritative assertions on the validity of one or more attribute values in an identity. Identity authority examples:

  • State institution issuing passports, which can then be used for authentication to prove that the person with a specific name or national identification number is really a resident of a particular country, and probably even the person holding the passport.

  • Issuer of ID cards, service cards, membership certificates (ITIC, ISIC, etc.) - these institutions use the results of other identity authorities for identity management in a specific domain of applicability.

  • University. Issuing a diploma, it confirms that the graduate has successfully accomplished a university study and gains a Master of Science title.

Within the eHealth DSI environment existing identity authorities can be used within identification and authentication processes.


Authorisation


Authorisation is a part of access management and the outcome is an attribute (role). In general, authorisation is a process to assign the proper rights to an identified entity (person, system or process) to do or to use something. In eHealth DSI environment, authorisation provides access control decision information for some access control mechanisms, controlling access to a patient’s health data and other sensitive data. The access to patient’s data in eHealth DSI is governed by eHealth DSI access control policy, based on the need-to-know principle. Active entities (actors) of eHealth DSI are categorised with respect to their tasks and positions in eHealth DSI environment and standardized sets of privileges are assigned to each role (category). Most activities require as a necessary prerequisite successful authentication of both participating parties and methods of authentication were described in previous parts of this chapter. Having assigned roles to entities, successful authentication enables to link an entity with a role (attribute) and thus in many cases it serves as an authorisation.

Since the “need-to-know” principle is one of the cornerstones of eHealth DSI, an actor is only able to access the eHealth DSI services and resources that are required for the completion of his duties. To enforce this, a temporarily approved set of privileges (determining the services or sources an actor can use) is allocated to the authenticated actor. This process is called authorisation.


List of actors in eHDSI


The following table summarizes the relevant activities of actors belonging to eHealth DSI roles (assuming the basic scenario HP from Country B needs patients health documents from patients home Country A).

Actor

Action

Necessary preconditions

Other directly involved actors

HP B

Requests services from

Country A

Successful identification, authentication and authorization of HP in Country B

Successful identification and authentication of the patient by Country A

National Infrastructure B, NCP B

NCP A

Patient

Requests check and provision of audit log concerning the accesses to his health data

Successful authorization of HP and authentication of the patient at PoC

NCP A, Health data

administrator

NCP B

Requests services from

Country A

Successful identification and authorization of NCP A

Authentication of the patient

NCP A

NCP A

Responds to service requests of NCP B

Successful identification and authentication of NCP B

Authentication of the patient

Authorisation of HP/HCPO

NCP B

Identity authority managing the databases of patients, HPs, HCPOs

HCPO or other external service provider

Provides required information to NCP

Mutual successful authentication of both parties

NCP A

HCPO or other external service provider

Health data administrators

Administrate systems processing data and provide some services (e.g. excerption of audit logs)

Successful identification of health data administrators

Authentication of health data administrators

Assigning the role of health data administrators

NCP or HCPO

Table 1: eHealth DSI actors and responsabilities


eHealth DSI is based on distributed systems and many functions will be executed by actors within national domains. The eHealth DSI role management depends strongly on cooperation with national authorities, operators of local systems.


NCP


NCPs occupy the highest position in eHealth DSI and there is no eHealth DSI entity authorised to assign an entity the role of a NCP. The management of the NCP role must follow the following schema1:

  1. eHealth DSI defines the initial requirements for NCPs

  2. NCPs of countries participating in eHealth DSI will be founding NCPs of eHealth DSI

  3. Founding NCPs review the initial requirements, set the criteria for NCP and introduce control mechanisms (e.g. security audit); the cooperation among NCPs must conform to general multilateral agreement (least security and interoperability inevitable requirements) and more advanced bilateral agreements.

  4. Enrolment of a new NCP into eHealth DSI must be based on candidate NCP accreditation by existing NCPs and signing multilateral agreement.

  5. Since every NCP must prepare, approve and implement security policy compliant with eHealth DSI security policy, every NCP will regularly (and if it would be necessary) undergo a security audit. The results of security audit are the necessary conditions for retaining the status of NCP.

  6. Since the security problems of one NCP can jeopardize the others, the cooperation with a problematic NCP can be interrupted (on bilateral basis) or the activities that insecure NCP in eHealth DSI can be suspended.

The secure communication among NCPs (identification, authentication and encryption/decryption) can be supported by PKI.

1 The schema describes one possible technical solution and does not deal with legal, political, economic and procedural aspects.


HCPO


In every country involved in eHealth DSI a national authority or a group of regional authorities must exist, able to define/manage HCPOs from its domain, participating in eHealth DSI. NCP will communicate with the respective national authority to keep the actual list of HCPO. eHealth DSI would define the minimal set of information necessary for unambiguous identification of HCPO.

HP


HPs identities will be managed in national domains. A national authority will maintain the list of all HPs in its domain and provide it to its national NCP. HCPO will provide NCP the roles assigned to its HP (if necessary). eHealth DSI would define the minimal set of information necessary for unambiguous identification of HP.


Patients


Each use case accessing the patient data, such as the Patient Summary and ePrescription/eDispensation use cases, requires the minimal set of necessary information for identification of a patient.


Health data administrator


A health data administrator is primarily responsible for running systems which exchange health data on NCP. The second responsibility covers the support of patients whenever they want an extract of audit log data.

Health data administrators are working for or in behalf of national authorities and from an eHealth DSI point of view the standard professional and security requirements fully suffice for this role.


Identification and authentication of other eHealth DSI entities


Patient health data is created, stored and processed (totally or mainly) apart from the eHealth DSI environment in various systems of national (e-Health) domains. The sources of medical and other necessary information (e.g. the list of patient, HPs, etc.) in national domains are called repositories or databases. The national domains of country will be connected to the eHealth DSI system by National contact points (NCPs), which will serve as interfaces (gates or proxies). (See Figure 1) Since all eHealth DSI communication among HPs from different countries will run through NCPs, every NCP must be able to prove his identity and to validate the identity of his partner (another NCP), before engaging data exchange and sending the required data.

Figure 2: The eHealth DSI system global topology


Successful authentication of eHealth DSI entities means that eHealth DSI actors (patients, HPs) can rely on documents they are receiving and can also trust the identities of other eHealth DSI partners, human and non human alike (e.g. NCP, HCPO).


Authenticity and Integrity of documents


Other important kind of nonhuman entities (objects) within eHealth DSI which ought to be distinguished are documents. The authenticity (genuineness) of a document is guaranteed by its issuer/producer (e.g. Hospital Information Systems (HIS), CIS (Clinical Information Systems), who uses various protective measures to minimize the probability of forgery or modification (like digital signatures).

Many important eHealth DSI documents will exist only in electronic form. Authentication of such documents means the verification of the document’s origin (who created the document and/or who sent this document).

The responsibility for technical issues for the authenticity of an eHealth DSI document and the responsibilities for administrative and technical issues for the integrity of the documents, belong to [Security Services Specification].

The authenticity of technical devices is important for the security of eHealth DSI system, but it is out of scope of this document and ought to be analyzed together with other security topics/issues of eHealth DSI.


Health data transfer


The eHealth DSI services include the transfer of sets of agreed data, particularly, a patient summary, that includes also a medication summary and data related to the ePrescription (prescription and dispensation). Most of the data included in those sets correspond to health data and therefore these documents are referred to as health data.

Utilising eHealth DSI services to access health data is contingent on successful identification and authentication of the health care professional, the identification of the patient, the fact that the eHealth DSI system “knows” the appropriate documents and the requestor is assigned to a role which is authorised to gain access to eHealth DSI. 

Figure 1: The flow of health data


  • No labels