ISO/TS 21298:2008
(Main)Health informatics — Functional and structural roles
Health informatics — Functional and structural roles
ISO/TS 21298:2008 defines a model for expressing functional and structural roles and populates it with a basic set of roles for international use in health applications. Roles are generally assigned to entities that are actors. This will focus on roles of persons (e.g. the roles of health professionals) and their roles in the context of the provision of care (e.g. subject of care). Roles addressed in ISO/TS 21298:2008 are not restricted to privilege management purposes, though privilege management and access control is one of the applications of this Technical Specification. ISO/TS 21298:2008 does not address specifications related to permissions. This Technical Specification treats the role and the permission as separate constructs. Further details regarding the relationship with permissions, policy and access control are provided in ISO/TS 22600-1.
Informatique de santé — Rôles fonctionnels et structurels
L'ISO/TS 21298:2008 définit un modèle permettant de décrire les rôles fonctionnels et structurels et le peuple avec une base de rôles pour une utilisation internationale dans les applications de santé. Les rôles sont en général attribués à des entités qui sont des acteurs. Cette spécification mettra l'accent sur le rôle des personnes (par exemple le rôle des professionnels de la santé) ainsi que sur leurs rôles dans le contexte de l'administration de soins (par exemple sujet de soins). Les rôles abordés dans L'ISO/TS 21298:2008 ne se limitent pas à la gestion des privilèges, même si la gestion des privilèges et le contrôle d'accès constituent l'une des applications de la présente Spécification technique. Celle-ci ne traite pas des spécifications liées aux permissions. La présente Spécification technique considère le rôle et la permission comme des éléments distincts. Des détails supplémentaires concernant la relation avec les permissions, la politique et le contrôle d'accès sont fournis dans l'ISO/TS 22600-1.
General Information
Relations
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 21298
First edition
2008-12-01
Health informatics — Functional and
structural roles
Informatique de santé — Rôles fonctionnel et structurel
Reference number
ISO/TS 21298:2008(E)
©
ISO 2008
---------------------- Page: 1 ----------------------
ISO/TS 21298:2008(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2008
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2008 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 21298:2008(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Abbreviations.4
5 Modelling roles in an architectural context .4
5.1 Roles within the generic component model.4
5.2 Roles and policy aspects.5
5.3 Roles in privilege management .6
5.4 Structural roles .7
5.5 Functional roles.12
6 Formally modelling roles.14
6.1 Roles within the generic component model.14
6.2 Developing the role model.14
6.3 Relationships between structural and functional roles .17
7 Use cases for the use of structural and functional roles in an interregional or
international context .17
Annex A (informative) ISCO-08 Sample mapping.19
Annex B (informative) Sample certificate profile for regulated healthcare professional .26
Bibliography.28
© ISO 2008 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 21298:2008(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 21298 was prepared by Technical Committee ISO/TC 215, Health informatics.
iv © ISO 2008 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 21298:2008(E)
Introduction
This Technical Specification contains a specification for encoding information related to roles for health
professionals and consumers. At least four areas have been identified where a model for encoding role
information is needed.
a) Privilege management and access control: role-based access control is not possible without an
effective means of recording role information for healthcare actors.
b) Directory services: structural roles are usefully recorded within directories of health care providers
(see, for example, ISO/TS 21091).
c) Audit trails: functional roles are usefully recorded within audit trails for health information applications.
[9], [10]
d) Public key infrastructure (PKI): The three-part International Standard ISO 17090 allows for the
encoding of healthcare roles in certificate extensions, but no structured vocabulary for such roles is
specified. This Technical Specification identifies such a coded vocabulary.
In addition to these security related applications there are several other possible applications of this Technical
Specification, such as:
e) Search and retrieval: finding and identifying the right professional for a health service.
f) Administration: billing of health care services.
g) Messaging: directing healthcare related messages by means of a specific role.
This Technical Specification is complemetary to other relevant standards that also describe and define roles
for the purpose of access control. Backward compatibility with ANSI INCITS and HL7 RBAC is provided
through simplification by combining the policy and role into a single construct. This Technical Specification
extends the model through the separation of the role and policy. This separation allows for a richer and more
flexible capability to instantiate business rules across multiple domains and jurisdictions.
© ISO 2008 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL SPECIFICATION ISO/TS 21298:2008(E)
Health informatics — Functional and structural roles
1 Scope
This Technical Specification defines a model for expressing functional and structural roles and populates it
with a basic set of roles for international use in health applications. Roles are generally assigned to entities
that are actors. This will focus on roles of persons (e.g. the roles of health professionals) and their roles in the
context of the provision of care (e.g. subject of care).
Roles can be structural (e.g. licensed general practitioner, non-licensed transcriptionist) or functional (e.g. a
provider who is a member of a therapeutic team, an attending physician, etc). Structural roles are relatively
static, often lasting for many years. They deal with relationships between entities expressed at a level of
complex concepts. Functional roles are bound to the realization of actions and are highly dynamic. They are
normally expressed at a decomposed level of fine-grained concepts.
Roles addressed in this Technical Specification are not restricted to privilege management purposes, though
privilege management is one of the applications of this Technical Specification as well as access control. This
Technical Specification does not address specifications related to permissions. This Technical Specification
treats the role and the permission as separate constructs. Further details regarding the relationship with
permissions, policy and access control are provided in ISO/TS 22600-1.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 17090-2, Health informatics — Public key infrastructure — Part 2: Certificate profile
ISO/HL7 21731, Health informatics — HL7 version 3 — Reference information model — Release 1
ISO 22600-1, Health informatics — Privilege management and access control — Part 1: Overview and policy
management
International Labour Organization: International Standard Classification of Occupations 2008 (ISCO-08)
3 Terms and definitions
For the purposes of this document the following terms and definitions apply.
3.1
access control
means of ensuring that the resources of a data processing system can be accessed only by authorized
entities in authorized ways
[ISO/IEC 2382-8, definition 08.04]
© ISO 2008 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/TS 21298:2008(E)
3.2
attribute authority
AA
authority that assigns privileges by issuing attribute certificates
NOTE Adapted from X.509.
3.3
attribute certificate
data structure, digitally signed by an attribute authority, which binds some attribute values with identification
about its holder
NOTE Adapted from X.509.
3.4
authority
entity that is responsible for the issuance of certificates
NOTE Two types are distinguished in this Technical Specification: certification authority which issues public-key
certificates and attribute authority which issues attribute certificates.
3.5
authorization
granting of rights, which includes the granting of access based on access rights
[ISO 7498-2, definition 3.3.10]
3.6
delegation
conveyance of privilege from one entity that holds such privilege, to another entity
3.7
delegation path
ordered sequence of certificates which, together with authentication of a privilege asserter's identity, can be
processed to verify the authenticity of a privilege asserter's privilege
3.8
entity
any concrete or abstract thing of interest
[ISO/IEC 10746-2, definition 6.1]
NOTE While in general the word entity can be used to refer to anything, in the context of modelling it is reserved to
refer to things in the universe of discourse being modelled.
3.9
identification
performance of tests to enable a data processing system to recognise entities
[ISO/IEC 2382-8, definition 08.04.12 (as identitiy authentication, identity validation)]
3.10
non-regulated health professional
person employed by a healthcare organization, but who is not a health professional
[ISO/IEC 17090-1, definition 3.1.5]
EXAMPLES Receptionist or secretary who organizes appointments, or a business manager who is responsible for
validating patient health insurance.
2 © ISO 2008 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/TS 21298:2008(E)
NOTE The fact that the employee is not authorized by a body independent of the employer in his professional
capacity does not, of course, imply that the employee is not professional in conducting his services.
3.11
policy
set of legal, political, organizational, functional and technical obligations for communication and cooperation
3.12
policy agreement
written agreement in which all involved parties commit themselves to a specified set of policies
3.13
principal
actor able to realize specific scenarios (user, organization, system, device, application, component, object)
3.14
privilege
capacity assigned to an entity by an authority according to the entity's attribute
NOTE Per OASIS Extensible Access Control Markup Language (XACML) V2.0, privilege, permissions, authorization,
entitlement and rights are replaced by the term “rule”.
3.15
regulated health professional
person who is authorized by a nationally recognized body to be qualified to perform certain health services
[ISO/IEC 17090-1, definition 3.1.8]
EXAMPLES Physicians, registered nurses and pharmacists.
NOTE 1 The types of registering or accrediting bodies differ in different countries and for different professions.
Nationally recognised bodies include local or regional governmental agencies, independent professional associations and
other formally and nationally recognised organizations. They may be exclusive or non-exclusive in their territory.
NOTE 2 A nationally recognized body in this definition does not imply one nationally controlled system of professional
registration but, in order to facilitate international communication, it would be preferable for one nationwide directory of
recognised health professional registration bodies to exist.
3.16
role
set of competences and/or performances that are associated with a task
3.17
role assignment certificate
certificate that contains the role attribute, assigning one or more roles to the certificate holder
3.18
role certificate
certificate that assigns privileges to a role rather than directly to individuals
NOTE Individuals assigned to that role, through an attribute certificate or public-key certificate with a subject directory
attributes extension containing that assignment, are indirectly assigned the privileges contained in the role certificate.
3.19
role specification certificate
certificate that contains the assignment of privileges to a role
© ISO 2008 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/TS 21298:2008(E)
4 Abbreviations
AA Attribute Authority
XML eXtensible Markup Language
ILO International Labour Organization
PKI Public Key Infrastructure
PMI Privilege Management Infrastructure
UML Unified Modelling Language
5 Modelling roles in an architectural context
5.1 Roles within the generic component model
For embedding components meeting functional requirements and services needed in a system, the
components of that system have to be managed in its architectural context. Therefore, requirements analysis,
design, and deployment of those components shall be developed and managed based on a reference
architecture following a unified process.
With the generic component model, such reference architecture in conformance with essential standards for
distributed, component-based, service-oriented and semantically interoperable information systems has been
developed in the mid-nineties (see, e.g. References [1], [2], [3]) and used in the context of several ISO/TC 215
and CEN/TC 251 specifications. The model specifies a component-based and service oriented architecture for
any domain. While this Technical Specification goes beyond security and privacy issues, functional and
structural roles are also used to manage privileges and access control. In this restricted context, functional
and structural roles have been specified and modelled in ISO/TS 22600-2. This Technical Specification
extends scope, services, and deployment of functional and structural roles, nevertheless being based on the
architectural approach for semantically interoperable eHealth/pHealth (personal health) information systems.
A system architecture defines the system's components, their functions and interrelationships. A system
architecture is modelled in three dimensions:
⎯ components for meeting specific domains' requirements;
⎯ the decomposition and, after detailing the underlying concepts, the composition of those components
following corresponding aggregation concepts/rule (e.g. component collaboration, workflow, algorithm);
granularity levels are at least business concepts, relations networks, basic services/functions and basic
concepts;
[8]
⎯ the different views on that component according to ISO 10746-2 from the enterprise view (business
case, use case, requirements) through the information view and the computational view representing the
platform independent logic of the system/component as well as the engineering view and technology view
both dealing with platform-specific implementation aspects.
Figure 1 presents the generic component model providing the aforementioned reference architecture.
4 © ISO 2008 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/TS 21298:2008(E)
Domain n
Domain 2
Domain 1
Business concepts Component view
Relations network
Basic services/ functions
Basic concepts
Figure 1 — Generic component model
The development of components, their concept representation and their aggregation are based on constraint
modelling. Concepts and rules can be represented using meta-languages such as UML and UML derivates or
the XML languages set.
5.2 Roles and policy aspects
Roles are components reflecting specific aspects of a system. They have to be managed according to all
dimensions of the GCM. As policies are properties and functions in another system/component dimension,
policies have to be embedded in the component specification through corresponding constraints. Interrelated
classes and associations can be simplistically modelled by component attributes and operational constraints.
This is done, for example, in some simplistic RBAC specifications, ignoring the policy-driven correct approach.
Associating, for example, a functional role class with the related policy class defining context and other
constraints to access target objects, the resulting component can summarise those constraints in a permission
bound to this role and expressed as permission attribute.
For managing relationships between the entities, structural (organizational) and functional roles can be
defined. Roles might be assigned to any entity as an actor in a communication or cooperation interrelationship
(e.g. person, organization, system, device, application, component, etc.). Because entities are actors in use
cases, roles have a relationship to actors and therefore to actions. Functional and structural roles are
associated with and defined by policies.
A policy may describe the legal framework including rules and regulations, the organizational and
administrative framework, functionalities, claims and objectives, the entities involved, agreements, rights,
duties, and penalties defined as well as the technological solution implemented for collecting, recording,
processing and communicating data in information systems.
Policies can be specified and implemented in different ways, including:
⎯ in a policy agreement as specified in ISO/TS 22600-1;
⎯ as an attribute;
⎯ as an implicit policy as part of another component;
⎯ as a separate policy element to be combined with another component or used directly;
⎯ as a rule policy combined with another policy;
⎯ as structured expressions (e.g. using XACML).
© ISO 2008 – All rights reserved 5
Enterprise view
Component
decomposition
Information view
Computational view
Engineering view
Technology view
---------------------- Page: 10 ----------------------
ISO/TS 21298:2008(E)
A policy may be applied as a set of rules describing the design and operation of a system. Health information
systems such as the Electronic Health Record (EHR), for instance, should have a patient policy, enterprise
policy, policies defined by laws and regulations, and one policy per structural role as well as one policy per
functional role. Further details regarding policy specification and the relationship to privilege management and
access control are provided in ISO/TS 22600-1.
Roles can be instantiated through numerous mechanisms, including directory entries, database variables and
certificates, among others. Role assignment certificates may be attribute certificates or public-key certificates.
Specific privileges are assigned to a role rather than to an individual through role specification certificates. The
indirect assignment enables the privileges assigned to a role to be updated, without impacting the certificates
that assign roles to individuals. Role specification certificates must be attribute certificates, and not public-key
certificates. If role specification certificates are not used, the assignment of privileges to a role may be done
through other means (e.g. may be locally configured at a privilege verifier).
The following are all possible:
a) any number of roles can be defined by any attribute authority;
b) the role itself and the members of a role can be defined and administered separately, by different attribute
authorities;
c) a privilege may be delegated;
d) roles may be assigned any suitable lifetime.
Further discussion regarding assignment of multiplicity of structural and functional roles is addressed in the
discussion of structural and functional roles below. Further details regarding the expression of roles through
digital certificates are provided in ISO 17090-2. Further details regarding the representation of roles as a
directory entry are provided in ISO/TS 21091.
Functional and structural roles are associated with and defined by policies.
Health information systems such as the Electronic Health Record (EHR), for instance, should have a patient
policy, an enterprise policy, policies defined by laws and regulations, and one policy per structural role as well
as one policy per functional role. Further details regarding policy specification and the relationship to privilege
management and access control are provided in ISO/TS 22600-1.
5.3 Roles in privilege management
Privileges can be assigned to an individual by a role assignment, or directly. A role can be expressed in public
key certificates, attribute certificates or in a directory entry as described in ISO 17090-2 and ISO/TS 21091. If
the role assignment certificate is a public-key certificate, the role attribute is contained in the
subjectDirectoryAttributes extension. In the latter case, any additional privileges contained in the public-key
certificate are privileges that are directly assigned to the certificate subject, not privileges assigned to the role.
If the role assignment certificate is an attribute certificate, the role attribute is contained in the attributes
component of the attribute certificate.
Thus, a privilege asserter may present a role assignment certificate to the privilege verifier demonstrating only
that the privilege asserter has a particular role (e.g., “manager”, or “purchaser”). The privilege verifier may
know a priori, or may have to discover by some other means, the privileges associated with the asserted role
in order to make a pass/fail authorization decision. The role specification certificate can be used for this
purpose.
A privilege verifier must have an understanding of the privileges specified for the role. The assignment of
those privileges to the role may be done within the PMI in a role specification certificate or outside the PMI
(e.g. locally configured). If the role privileges are asserted in a role specification certificate, mechanisms for
linking that certificate with the relevant role assignment certificate for the privilege asserter are provided in this
Technical Specification. A role specification certificate cannot be delegated to any other entity. The issuer of
the role assignment certificate may be independent of the issuer of the role specification certificate and these
6 © ISO 2008 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/TS 21298:2008(E)
may be administered (expired, revoked and so on) entirely separately. The same certificate (attribute
certificate or public-key certificate) can be a role assignment certificate as well as contain assignment of other
privileges directly to the same individual. However, a role specification certificate must be a separate
certificate.
NOTE The use of roles within an authorization framework can increase the complexity of path processing, because
such functionality essentially defines another delegation path to be followed. The delegation path for the role assignment
certificate may involve different AAs and may be independent of the AA that issued the role specification certificate.
5.4 Structural roles
5.4.1 General
In general, two types of role can be distinguished: structural roles and functional roles. Structural roles reflect
the structural/organizational aspects of relationships between entities (e.g. person-person or
person-organization relationships, as happening in employment context, organizational hierarchies,
responsibilities, etc.). They facilitate certain services within the generic structure-function relationship. Many
structural roles may be assigned to a single entity reflecting the same entities' relationship to several other
entities and/or different context constraints (e.g. structural roles of a person as head physician, director of a
healthcare establishment, specialized ophthalmologist, etc.).
Where structural roles reflect human or organizational categories, the structural roles may represent
prerequisites, feasibilities or competences for actors to interact within their particular functional role. Concepts
and functions bound to a structural role are dependent on the underlying policy. Therefore, structural roles
differ from policy domain to policy domain within and across organizational boundaries, and especially
between different jurisdictions and countries.
Structural roles persist with the persistence of the relationship between those entities and the related policies
despite whether the assigned responsibilities and functions are performed or not.
As structural roles comprise rather complex business processes, structural roles usually relate to higher levels
of complexity in the generic component model (Figure 1).
5.4.2 Structural roles of healthcare professions from the ILO
In order to facilitate international interoperability, the following structural roles shall be used where there are
more than one set of functional roles useful for authorization and access rights. The International Standard
Classification of Occupations 2008 (ISCO-08) shall be used where more specific structural roles known to the
communicating parties are unavailable. The vocabulary identification for this list of coded values shall be
referenced by the following OID.
Vocabulary identification: ISO (1) standard (0) functional and structural roles (21298) structural role
vocabulary (1).
This structural role is reflected in the CodedData of the hcRole attribute as described in ISO 17090-2. An
example is provided in Annex B to further clarify this usage.
This structural role may be used for international interoperability for the coding system indicated in the
HCProfessional object class, HcProfession attribute as described by ISO/TS 21091.
This structural role may be used for recording the internationally recognised role of the individual involved in
health related transactions in associate
...
SPÉCIFICATION ISO/TS
TECHNIQUE 21298
Première édition
2008-12-01
Informatique de santé — Rôles
fonctionnels et structurels
Health informatics — Functional and structural roles
Numéro de référence
ISO/TS 21298:2008(F)
©
ISO 2008
---------------------- Page: 1 ----------------------
ISO/TS 21298:2008(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2008
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Version française parue en 2009
Publié en Suisse
ii © ISO 2008 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/TS 21298:2008(F)
Sommaire Page
Avant-propos .iv
Introduction.v
1 Domaine d'application .1
2 Références normatives.1
3 Termes et définitions .1
4 Abréviations.4
5 Rôles de modélisation dans un contexte architectural.4
5.1 Rôles au sein du modèle de composant générique (GCM).4
5.2 Rôles et aspects relatifs à la politique .5
5.3 Rôles au sein de la gestion des privilèges .6
5.4 Rôles structurels .7
5.5 Rôles fonctionnels .13
6 Modélisation formelle des rôles.14
6.1 Rôles au sein du modèle de composant générique .14
6.2 Développement du modèle de rôle.15
6.3 Relations entre rôles structurels et rôles fonctionnels.18
7 Cas d'utilisation des rôles structurels et des rôles fonctionnels dans un contexte
interrégional ou international.19
Annexe A (informative) Échantillon de mise en correspondance CITP-08 .20
Annexe B (informative) Échantillon de profil des certificats pour professionnels de la santé
agréés .28
Bibliographie.30
© ISO 2008 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/TS 21298:2008(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
Dans d'autres circonstances, en particulier lorsqu'il existe une demande urgente du marché, un comité
technique peut décider de publier d'autres types de documents:
⎯ une Spécification publiquement disponible ISO (ISO/PAS) représente un accord entre les experts dans
un groupe de travail ISO et est acceptée pour publication si elle est approuvée par plus de 50 % des
membres votants du comité dont relève le groupe de travail;
⎯ une Spécification technique ISO (ISO/TS) représente un accord entre les membres d'un comité technique
et est acceptée pour publication si elle est approuvée par 2/3 des membres votants du comité.
Une ISO/PAS ou ISO/TS fait l'objet d'un examen après trois ans afin de décider si elle est confirmée pour trois
nouvelles années, révisée pour devenir une Norme internationale, ou annulée. Lorsqu'une ISO/PAS ou
ISO/TS a été confirmée, elle fait l'objet d'un nouvel examen après trois ans qui décidera soit de sa
transformation en Norme internationale soit de son annulation.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO/TS 21298 a été élaborée par le comité technique ISO/TC 215, Informatique de santé.
iv © ISO 2008 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO/TS 21298:2008(F)
Introduction
La présente Spécification technique contient une spécification de codage des informations liées aux rôles des
professionnels et des consommateurs de santé. Quatre domaines au moins ont été identifiés pour lesquels un
modèle de codage des informations relatives aux rôles est nécessaire.
a) Gestion des privilèges et contrôle d'accès: le contrôle d'accès en fonction du rôle n'est pas possible
sans la mise en place d'un moyen efficace destiné à enregistrer les informations de rôle des acteurs de
santé.
b) Services d'annuaire: les rôles structurels sont utilement enregistrés au sein d'annuaires des prestataires
de santé (voir, par exemple, l'ISO/TS 21091).
c) Traçabilité: les rôles fonctionnels sont utilement enregistrés dans une démarche de traçabilité pour des
applications de gestion des informations de santé.
[9][10]
d) Infrastructure de gestion de clés (IGC): L'ISO 17090 (en trois parties) permet le codage des rôles
de santé dans des extensions de certificat, mais aucun vocabulaire structuré relatif à ces rôles n'est
spécifié. La présente Spécification technique identifie ce vocabulaire codé.
Outre ces applications liées à la sécurité, il existe plusieurs autres applications possibles de la présente
Spécification technique, telles que:
e) Fonction de recherche: trouver et identifier le bon professionnel pour un service de santé donné.
f) Administration: facturer les services de santé.
g) Messagerie: router les messages relatifs à la santé au moyen d'un rôle spécifique.
La présente Spécification technique sert de complément à d'autres normes applicables qui décrivent et
définissent aussi les rôles pour les besoins du contrôle d'accès. La compatibilité ascendante avec
l'ANSI INCITS et l'HL7 RBAC est assurée grâce à une simplification obtenue en combinant la politique et le
rôle dans un seul et même élément La présente Spécification technique élargit le modèle en distinguant le
rôle et la politique. Cette distinction permet d'instancier de manière plus riche et plus souple les règles de
gestion dans de multiples domaines et juridictions.
© ISO 2008 – Tous droits réservés v
---------------------- Page: 5 ----------------------
SPÉCIFICATION TECHNIQUE ISO/TS 21298:2008(F)
Informatique de santé — Rôles fonctionnels et structurels
1 Domaine d'application
La présente Spécification technique définit un modèle permettant de décrire les rôles fonctionnels et
structurels et le peuple avec une base de rôles pour une utilisation internationale dans les applications de
santé. Les rôles sont en général attribués à des entités qui sont des acteurs. Cette spécification mettra
l'accent sur le rôle des personnes (par exemple le rôle des professionnels de la santé) ainsi que sur leurs
rôles dans le contexte de l'administration de soins (par exemple sujet de soins).
Les rôles peuvent être structurels (par exemple médecin généraliste agréé, transcripteur médical non agréé)
ou fonctionnels (par exemple prestataire membre d'une équipe thérapeutique, médecin traitant, etc.). Les
rôles structurels sont relativement statiques, souvent valables pendant de nombreuses années. Ils traitent des
relations entre les entités exprimées à un niveau de concepts complexes. Les rôles fonctionnels sont liés à la
réalisation d'actions et sont très dynamiques. Ils sont généralement exprimés à un niveau détaillé de concepts
élémentaires.
Les rôles abordés dans la présente Spécification technique ne se limitent pas à la gestion des privilèges,
même si la gestion des privilèges et le contrôle d'accès constituent l'une des applications de la présente
Spécification technique. Celle-ci ne traite pas des spécifications liées aux permissions. La présente
Spécification technique considère le rôle et la permission comme des éléments distincts. Des détails
supplémentaires concernant la relation avec les permissions, la politique et le contrôle d'accès sont fournis
dans l'ISO/TS 22600-1.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 17090-2, Informatique de santé — Infrastructure de clé publique — Partie 2: Profil de certificat
ISO/HL7 21731, Informatique de santé — HL7 version 3 — Modèle d'information de référence — Version 1
ISO 22600-1, Informatique de santé — Gestion de privilèges et contrôle d'accès — Partie 1: Vue d'ensemble
et gestion des politiques
Organisation internationale du travail: Classification internationale type des professions 2008 (CITP-08)
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1
contrôle d'accès
ensemble des moyens garantissant que seules les entités autorisées peuvent accéder aux ressources d'un
système informatique, et seulement d'une manière autorisée
[ISO/CEI 2382-8, définition 08.04.01]
© ISO 2008 – Tous droits réservés 1
---------------------- Page: 6 ----------------------
ISO/TS 21298:2008(F)
3.2
autorité d'attribut
AA
autorité qui attribue les privilèges en délivrant des certificats d'attribut
NOTE Adapté du document X.509.
3.3
certificat d'attribut
structure de données, signée numériquement par une autorité d'attribut, qui combine les valeurs d'attribut à
l'identification de son détenteur
NOTE Adapté du document X.509.
3.4
autorité
entité qui est responsable de l'émission de certificats
NOTE Elles sont classées en deux catégories dans la présente Spécification technique: l'autorité de certification qui
émet des certificats de clés publiques et l'autorité d'attribut qui émet des certificats d'attribut.
3.5
autorisation
attribution de droits, comprenant la permission d'accès sur la base de droits d'accès
[ISO 7498-2, définition 3.3.10]
3.6
délégation
transfert de privilège d'une entité détenant ce privilège à une autre entité
3.7
chemin de délégation
séquence ordonnée de certificats qui peuvent, conjointement à l'authentification de l'identité d'un déclarant de
privilège, être traités pour vérifier l'authenticité d'un privilège de ce déclarant
3.8
entité
tout élément concret ou abstrait, qui présente un intérêt
[ISO/CEI 10746-2, définition 6.1]
NOTE Alors que d'une manière générale le terme entité peut être utilisé pour faire référence à toute chose, son
utilisation dans le contexte de la modélisation est réservée aux éléments modélisant l'univers du discours.
3.9
identification
exécution de tests permettant à un système informatique de reconnaître des entités
[ISO/CEI 2382-8, définition 08.04.12 (comme validation d'identité)]
3.10
professionnel de santé non agréé
personne employée par un organisme de santé, mais qui n'est pas un professionnel de la santé
[ISO/CEI 17090-1, définition 3.1.5]
EXEMPLES Assistante médicale ou secrétaire qui gère les rendez-vous, ou directeur responsable de la validation de
l'assurance maladie des patients.
2 © ISO 2008 – Tous droits réservés
---------------------- Page: 7 ----------------------
ISO/TS 21298:2008(F)
NOTE Le fait que l'employé ne soit pas agréé par un organisme indépendant de l'employeur dans sa capacité
professionnelle ne signifie évidemment pas que l'employé manque de professionnalisme dans sa démarche de prestation
de services.
3.11
politique
ensemble d'obligations légales, politiques, organisationnelles, fonctionnelles et techniques pour la
communication et la coopération
3.12
accord de politique
accord écrit dans lequel toutes les parties concernées s'engagent à respecter un ensemble spécifié de
politiques
3.13
principal
acteur capable d'effectuer des scénarios spécifiques (utilisateur, organisation, système, dispositif, application,
composant, objet)
3.14
privilège
capacité attribuée par une autorité à une entité en rapport avec l'attribut de cette entité
NOTE OASIS XACML (Extensible Access Control Markup Language) V2.0 remplace les notions de privilège,
permissions, autorisation, avantage et droits par le terme «règle».
3.15
professionnel de santé agréé
personne habilitée par un organisme reconnu au niveau national à effectuer certains services de santé
[ISO/CEI 17090-1, définition 3.1.8]
EXEMPLES Médecins, infirmières diplômées et pharmaciens.
NOTE 1 Les types d'organisme d'enregistrement ou d'accréditation varient selon les pays et selon les professions. Les
organismes nationaux reconnus comprennent les agences locales ou régionales, les associations professionnelles
indépendantes et d'autres organisations formellement reconnues au niveau national. Ils peuvent être exclusifs ou non
dans leur territoire.
NOTE 2 Selon cette définition, un organisme national reconnu n'implique pas un système unique d'enregistrement
professionnel piloté au niveau national; toutefois, afin de faciliter les échanges internationaux, il serait préférable qu'il
existe à l'échelon national un annuaire d'organismes reconnus d'enregistrement des professionnels de la santé.
3.16
rôle
ensemble de compétences et/ou de performances associées à une tâche
3.17
certificat d'attribution de rôle
certificat contenant l'attribut de rôle, attribuant un ou plusieurs rôles au détenteur du certificat
3.18
certificat de rôle
certificat qui attribue des privilèges à un rôle plutôt que directement à des individus
NOTE Les individus désignés pour ce rôle, grâce à un certificat d'attribut ou à un certificat de clés publiques avec
une extension d'attributs d'annuaire contenant cette attribution, se voient indirectement attribuer les privilèges contenus
dans le certificat de rôle.
© ISO 2008 – Tous droits réservés 3
---------------------- Page: 8 ----------------------
ISO/TS 21298:2008(F)
3.19
certificat de spécification de rôle
certificat contenant l'attribution de privilèges à un rôle
4 Abréviations
AA Autorité d'Attribut
XML eXtensible Markup Language (langage de balisage extensible)
OIT Organisation Internationale du Travail
IGC Infrastructure de Gestion de Clés
IGP Infrastructure de Gestion des Privilèges
UML Unified Modelling Language (langage de modélisation unifié)
5 Rôles de modélisation dans un contexte architectural
5.1 Rôles au sein du modèle de composant générique (GCM)
Les composants de système satisfaisant aux exigences fonctionnelles et aux services requis dans un
système doivent être gérés dans leur contexte architectural. Par conséquent, l'analyse, la conception et le
déploiement des exigences de ces composants doivent être développés et gérés sur la base d'une
architecture de référence suivant un processus unifié.
Avec le modèle générique de composant, une telle architecture de référence conforme aux normes
essentielles relatives aux systèmes d'information répartis, fondés sur les composants, orientés services et
sémantiquement interopérables a été développée au milieu des années 90 (par exemple Références [1], [2],
[3]) et utilisée dans le cadre de plusieurs spécifications ISO/TC 215 et CEN/TC 251. Ce modèle spécifie pour
tout domaine une architecture fondée sur les composants et orientée services. La présente Spécification
technique ne se limite pas aux questions de sécurité et de respect de la vie privée; les rôles fonctionnels et
structurels sont également utilisés pour gérer les privilèges et les contrôles d'accès. Dans ce contexte
restreint, les rôles fonctionnels et structurels ont été spécifiés et modélisés dans l'ISO/TS 22600-2. La
présente Spécification technique étend le domaine d'application, les services et le déploiement des rôles
fonctionnels et structurels, mais repose néanmoins sur l'approche architecturale pour les systèmes
d'information sémantiquement interopérables eSanté/iSanté (santé individuelle).
Une architecture de système définit les composants systèmes, leurs fonctions et leurs interactions. Une
architecture de système est modélisée en trois dimensions:
⎯ les composants permettant de satisfaire aux exigences des domaines spécifiques;
⎯ la décomposition et, après avoir détaillé les concepts sous-jacents, la composition de ces composants
d'après les règles/concepts d'agrégation correspondants (par exemple collaboration des composants,
workflow, algorithme); les niveaux de granularité sont au moins les concepts métier, les réseaux de
relations, les services/fonctions de base et les concepts de base;
[8]
⎯ les différentes vues concernant ce composant selon l'ISO 10746-2 , la vue entreprise (cas métier, cas
d'utilisation, exigences), la vue information et la vue traitement qui représentent la logique indépendante
de la plate-forme du système/composant, ainsi que la vue ingénierie et la vue technologie qui concernent
les aspects de mise en œuvre spécifiques à la plate-forme.
La Figure 1 présente le modèle de composant générique qui fournit l'architecture de référence mentionnée
précédemment.
4 © ISO 2008 – Tous droits réservés
---------------------- Page: 9 ----------------------
ISO/TS 21298:2008(F)
Domaine n
Domaine 2
Domaine 1
Vue du composant
Concepts métier
Réseau de relations
Services/fonctions de base
Concepts de base
Figure 1 — Modèle de composant générique
Le développement des composants, la représentation de leur concept et leur agrégation sont fondés sur la
modélisation des contraintes. Les concepts et les règles peuvent être représentés à l'aide de métalangages
tels que UML et ses dérivés ou l'ensemble des langages XML.
5.2 Rôles et aspects relatifs à la politique
Les rôles sont les composants qui reflètent les aspects spécifiques d'un système. Ils doivent être gérés selon
toutes les dimensions du GCM. Les politiques sont des propriétés et des fonctions dans une autre dimension
du système/composant, et elles doivent être intégrées dans la spécification du composant à travers les
contraintes correspondantes. Les classes interdépendantes et les associations peuvent être modélisées de
manière simple par les attributs du composant et les contraintes opérationnelles. Cela peut être réalisé par les
spécifications d'un simple RBAC qui ignorent la bonne approche par la politique. En associant, par exemple,
une classe de rôle fonctionnel à la classe de politique correspondante qui définit le contexte et les autres
contraintes d'accès aux objets cibles, le composant résultant peut résumer ces contraintes par une
autorisation donnée à ce rôle et exprimée sous la forme d'un attribut d'autorisation.
Pour gérer les relations entre les entités, il est possible de définir les rôles structurels (organisationnels) et
fonctionnels. Les rôles peuvent être attribués à toute entité en tant qu'acteur dans une interaction de
communication ou de coopération (il s'agit par exemple d'une personne, d'une organisation, d'un système,
d'un dispositif, d'une application, d'un composant, etc.). Parce que les entités sont des acteurs engagés dans
des «cas d'utilisation», les rôles concernent les acteurs, et par conséquent les actions. Les rôles fonctionnels
et structurels sont associés aux politiques et définis par celles-ci.
Une politique peut décrire le cadre juridique, y compris les règles et réglementations, le cadre organisationnel
et administratif, les fonctionnalités, les revendications et objectifs, les entités concernées, les accords, les
droits, les devoirs et les sanctions définies, ainsi que la solution technologique mise en œuvre pour collecter,
enregistrer, traiter et communiquer les données au sein des systèmes d'information.
Les politiques peuvent être spécifiées et mises en oeuvre de différentes manières, notamment
⎯ dans un accord de politique tel que spécifié dans l'ISO/TS 22600-1,
⎯ en tant qu'attribut,
⎯ en tant que politique implicite faisant partie d'un autre composant,
© ISO 2008 – Tous droits réservés 5
Domaine
Vue entreprise
Décomposition
du composant
Vue d’information
Vue de traitement
Vue d’ingéniérie
Vue technologie
---------------------- Page: 10 ----------------------
ISO/TS 21298:2008(F)
⎯ en tant qu'élément de politique distinct, à combiner avec un autre composant ou à utiliser directement,
⎯ en tant que politique de règles combinée à une autre politique,
⎯ en tant qu'expressions structurées (par exemple en utilisant XACML).
Une politique peut être appliquée comme un ensemble de règles qui décrit la conception et le fonctionnement
d'un système. Il convient que les systèmes d'information de santé tels que le Dossier de Santé Informatisé
(DSI), par exemple, respectent une politique du patient, une politique d'entreprise, des politiques définies par
des lois et réglementations, ainsi qu'une politique par rôle structurel et une politique par rôle fonctionnel. Des
détails supplémentaires concernant la spécification de la politique et sa relation avec la gestion des privilèges
et le contrôle d'accès sont fournis dans l'ISO/TS 22600-1.
Les rôles peuvent être instanciés grâce à de nombreux mécanismes, notamment les entrées d'annuaire, les
variables dans les bases de données et les certificats. Les certificats d'attribution de rôle peuvent être des
certificats d'attribut ou des certificats de clés publiques. Les privilèges spécifiques sont attribués à un rôle
plutôt qu'à un individu grâce à des certificats de spécification de rôle. L'attribution indirecte permet aux
privilèges attribués à un rôle d'être mis à jour, sans affecter les certificats attribuant ces rôles à des individus.
Les certificats de spécification de rôle doivent être des certificats d'attribut, et non des certificats de clés
publiques. Si les certificats de spécification de rôle ne sont pas utilisés, l'attribution des privilèges à un rôle
peut être effectuée grâce à d'autres moyens (elle peut, par exemple, être configurée localement à un
vérificateur de privilège).
Toutes les solutions suivantes sont possibles:
a) une autorité d'attribut peut définir un nombre quelconque de rôles;
b) le rôle lui-même et les attributaires d'un rôle peuvent être définis et gérés séparément par différentes
autorités d'attribut;
c) un privilège peut être délégué;
d) les rôles peuvent être attribués quelle que soit la durée de validité appropriée.
Des informations supplémentaires concernant l'attribution des différents rôles structurels et fonctionnels sont
abordées ci-dessous. Des détails supplémentaires concernant l'expression des rôles grâce à des certificats
numériques sont fournis dans l'ISO 17090-2. Des détails supplémentaires concernant la représentation des
rôles en tant qu'entrées d'annuaire sont fournis dans l'ISO/TS 21091.
Les rôles fonctionnels et structurels sont associés aux politiques et définis par celles-ci.
Il convient que les systèmes d'information de santé tels que le Dossier de Santé Informatisé (DSI), par
exemple, disposent d'une politique du patient, d'une politique d'entreprise, de politiques définies par des lois
et réglementations, ainsi que d'une politique par rôle structurel et d'une politique par rôle fonctionnel. Des
détails supplémentaires concernant la spécification de la politique et la relation avec la gestion des privilèges
et le contrôle d'accès sont fournis dans l'ISO/TS 22600-1.
5.3 Rôles au sein de la gestion des privilèges
Les privilèges peuvent être attribués à un individu grâce à une attribution de rôle ou de manière directe. Un
rôle peut être exprimé dans des certificats de clés publiques, des certificats d'attribut ou une entrée d'annuaire,
tel que décrit dans l'ISO 17090-2 et l'ISO/TS 21091. Si le certificat d'attribution de rôle est un certificat de clés
publiques, l'attribut de rôle est contenu dans l'extension subjectDirectoryAttributes. Dans ce cas, tous les
privilèges supplémentaires contenus dans le certificat de clés publiques sont des privilèges qui sont
directement attribués à un sujet de certificat, et non des privilèges attribués à un rôle. Si le certificat
d'attribution de rôle est un certificat d'attribut, l'attribut de rôle est contenu dans le composant attribut du
certificat d'attribut.
6 © ISO 2008 – Tous droits réservés
---------------------- Page: 11 ----------------------
ISO/TS 21298:2008(F)
Ainsi, le déclarant de privilège peut présenter au vérificateur de privilèges un certificat d'attribution de rôle,
démontrant seulement que le déclarant de privilège a un rôle particulier (par exemple «responsable» ou
«acheteur»). Le vérificateur de privilèges peut connaître a priori, ou peut avoir à rechercher par d'autres
moyens, les privilèges associés au rôle déclaré afin de prendre une décision d'autorisation ou de
non-autorisation. Le certificat de spécification de rôle peut être utilisé à cette fin.
Un vérificateur de privilèges doit connaître les privilèges spécifiés pour le rôle. L'attribution au rôle de ces
privilèges peut être effectuée dans le cadre de l'IGP dans un certificat de spécification de rôle ou en dehors
de l'IGP (elle peut par exemple être configurée localement). Si les privilèges de rôle sont présentés dans un
certificat de spécification de rôle, les mécanismes mis en oeuvre pour relier ce certificat au certificat
d'attribution de rôle du déclarant de privilège sont fournis dans la présente Spécification technique. Un
certificat de spécification de rôle ne peut être délégué à une autre entité. L'émetteur de ce certificat
d'attribution de rôle peut être indépendant de l'émetteur du certificat de spécification de rôle; les certificats
peuvent être gérés (périmés, révoqués, etc.) de manière complètement distincte. Un même certificat (certificat
d'attribut ou certificat de clés publiques) peut être un certificat d'attribution de rôle et peut également contenir
l'attribution d'autres privilèges directement au même individu. Cependant, un certificat de spécification de rôle
doit être un certificat distinct.
NOTE L'utilisation de rôl
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.