ISO 22600-2:2014

NORME ISO
INTERNATIONALE 22600-2
Première édition
2014-10-01
Informatique de santé — Gestion de
privilèges et contrôle d’accès —
Partie 2:
Modèles formels
Health informatics — Privilege management and access control —
Part 2: Formal models
Numéro de référence
©
ISO 2014
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2014
Droits de reproduction réservés. Sauf indication contraire, 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, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au 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
Publié en Suisse
ii © ISO 2014 – Tous droits réservés

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 . 6
5 Paradigme de composante . 6
6 Modèles génériques . 8
6.1 Cadre . 8
6.2 Modèle de domaine . 9
6.3 Modèle de document .11
6.4 Modèle de politique .11
6.5 Modèle de rôle .15
6.6 Modèle d’autorisation — Rôle et attribution des privilèges .15
6.7 Modèle de contrôle .16
6.8 Modèle de délégation .17
6.9 Modèle de contrôle d’accès .19
Annexe A (informative) Rôles fonctionnels et structurels .21
Bibliographie .26
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 (IEC) en ce qui concerne
la normalisation électrotechnique.
Les procédures employées pour l’élaboration du présent document et celles destinées à son suivi sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient de noter les différents critères d’approbation
nécessaires aux différents types de documents ISO. Le présent document a été rédigé conformément aux
règles rédactionnelles des Directives ISO/IEC, Partie 2 (voir www.iso.org/directives).
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. Les détails relatifs à tous
droits de propriété identifiés au cours de l’élaboration du document figureront en Introduction et/ou
dans la liste ISO des déclarations de brevets reçues (voir www.iso.org/patents).
Tout nom commercial utilisé dans le présent document est une information donnée à des fins de
commodité pour l’utilisateur et ne bénéficie d’aucun appui particulier.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à l’évaluation
de la conformité, aussi bien que pour des informations au sujet de l’adhésion de l’ISO aux principes de
l’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos —
Informations supplémentaires
Le comité chargé de l’élaboration du présent document est l’ISO/TC 215, Informatique de santé.
Cette première édition de l’ISO 22600-2 annule et remplace l’ISO/TS 22600-2:2006, qui a fait l’objet
d’une révision technique.
L’ISO 22600, présentée sous le titre général Informatique de santé — Gestion de privilèges et contrôle
d´accès, comprend les parties suivantes:
— Partie 1: Vue d’ensemble et gestion des politiques
— Partie 2: Modèles formels
— Partie 3: Mises en œuvre
iv © ISO 2014 – Tous droits réservés

Introduction
L’architecture répartie des systèmes d’informations de soins partagés prenant en charge l’architecture
orientée services (SOA) s’appuie de plus en plus sur des réseaux d’entreprise et des réseaux privés
virtuels. Afin de relever le défi de l’interopérabilité, le recours à des interfaces utilisateur, outils et
protocoles normalisés qui garantissent l’indépendance d’une plateforme s’est généralisé, tout comme le
nombre de systèmes d’informations réellement ouverts a rapidement augmenté au cours des dernières
années.
À l’heure actuelle, il est très fréquent que des hôpitaux aient recours à plusieurs fournisseurs qui leur
installent des applications qui ne sont pas en mesure de communiquer une authentification et une
autorisation, puisque chaque application a sa propre manière de gérer ces fonctions. Aboutir à un
scénario intégré demanderait d’investir beaucoup d’argent, de temps et d’efforts pour faire correspondre
dynamiquement des utilisateurs et des environnements organisationnels changeants, avant même
de démarrer une communication et une coopération. Les ressources requises pour le développement
et la maintenance des fonctions de sécurité augmentent de façon exponentielle, parallèlement au
nombre d’applications, à l’évolution toujours plus complexe des organisations vers un niveau régional,
national, voire international et à la flexibilité des utilisateurs jouant des rôles multiples, parfois même
simultanément.
La situation s’avère même encore plus compliquée lorsqu’il s’agit de communications
inter-organisationnelles qui, comme leur nom le laisse entendre, excèdent les limites d’un domaine
de politique de sécurité. D’un centre de soins à un autre ou d’un pays à un autre, les règles régissant
les privilèges et leur gestion peuvent différer pour des types d’utilisateurs similaires, aussi bien pour
l’exécution de fonctions particulières que pour l’accès aux informations. Les différences de politiques
entre ces domaines doivent être comblées automatiquement ou via des accords de politique définissant
des ensembles de règles à respecter par les parties concernées, pour assurer l’interopérabilité.
Améliorer la qualité des soins grâce aux technologies de l’information (TI) sans pour autant violer la vie
privée du patient constitue un autre défi à relever. Afin que les médecins puissent disposer d’informations
pertinentes sur leurs patients, il est nécessaire de mettre en place un dossier informatisé de soins de
santé, permettant de garder une trace de toutes les activités associées à un patient donné, quels que
soient le lieu où ces activités ont été menées et la personne qui les a effectuées ou documentées. Dans
ce contexte, il est nécessaire de disposer d’un modèle général ou d’un accord spécifique passé entre les
parties pour pouvoir gérer les privilèges et le contrôle d’accès aux informations incluant le patient ou
son représentant.
Outre la diversité des rôles et responsabilités qui caractérise tout type de grande organisation, il est
important de prendre également en considération les questions éthiques et légales qui se posent dans le
cadre d’un scénario de soins de santé, en raison de la sensibilité des informations gérées, liées à la santé
de la personne, et de leur impact personnel et social.
Même si la gestion des privilèges et le contrôle d’accès requièrent d’ores et déjà la mise en œuvre de
solutions perfectionnées, ce besoin se fera davantage ressentir dans les prochaines années. Cela est dû à
l’augmentation du nombre d’informations échangées entre systèmes afin de répondre aux exigences des
prestataires de services de santé à différents niveaux de soins, qui veulent pouvoir accéder à toujours
plus d’informations sur le patient afin de garantir la qualité et l’efficacité des diagnostics et traitements
délivrés aux patients, même si cela implique des risques accrus en termes de sécurité et de respect de
la vie privée.
La présente Norme internationale constitue une avancée technologique telle que certains établissements
techniques et organisationnels peuvent juger son application infaisable dans l’état actuel des choses.
Par conséquent, afin de satisfaire au principe de base qui consiste à entreprendre la meilleure action
possible, il est très important que les différentes parties impliquées rédigent au moins un accord de
politique explicitant la volonté d’évoluer dans le sens de la présente Norme internationale si des mises à
jour/mises à niveau sont prévues. Le niveau de formalisation et de granularité des politiques et les objets
auxquels ces politiques sont liées définissent la maturité de la solution par rapport à la spécification
présentée.
L’accord de politique doit également mentionner les différences qui ont été identifiées entre les
systèmes de sécurité ainsi que les solutions retenues pour pallier ces différences. Par exemple, le service
d’authentification et les privilèges d’un demandeur au niveau du site de réponse doivent être gérés
conformément à la politique déclarée dans l’accord. Pour cette raison, le demandeur d’informations et de
services ainsi que le fournisseur d’informations et de services d’une part, et les informations et services
demandés et fournis d’autre part, doivent être regroupés et classés selon un nombre limité de concepts
afin de pouvoir spécifier un nombre limité de catégories de solutions. Il est alors possible, sur la base de
cette classification, de mettre en œuvre des mécanismes d’ayants droits, de sensibilité des cibles ainsi
que de spécification et de gestion des politiques. Une fois l’accord de politique signé par la totalité des
parties impliquées, la communication et l’échange d’informations peuvent débuter en s’appuyant sur
les systèmes existants, si les parties en acceptent les risques. En cas de risques inacceptables devant
être éliminés avant de débuter l’échange d’informations, ces risques doivent également être enregistrés
dans l’accord de politique tout comme le plan d’actions explicitant la façon de supprimer ces risques.
L’accord de politique doit également inclure les échéances d’application du plan d’actions et ses moyens
de financement.
La documentation du processus de négociation est très importante et fournit la plateforme de l’accord
de politique.
La gestion des privilèges et le contrôle d’accès couvrent les services de sécurité et de respect de la
vie privée nécessaires à la communication et à la coopération, c’est-à-dire l’utilisation répartie des
informations de santé. Cela couvre également les aspects de sécurité et les normes professionnelles
ainsi que les questions légales et éthiques. La présente Norme internationale constitue une introduction
aux principes de gestion des privilèges et de contrôle d’accès et spécifie les services nécessaires à ces
activités. Les protocoles cryptographiques ne sont pas couverts par la présente Norme internationale.
La présente Norme internationale en trois parties comporte des références à des normes existantes
relatives à l’architecture et à la sécurité de même qu’à des spécifications dans le domaine des soins de
santé, comme des spécifications ISO, CEN, ASTM, OMG, W3C, etc., et est conforme à d’autres normes
pertinentes existantes ou sinon identifie les améliorations ou les modifications ou encore le besoin
d’élaborer de nouvelles normes. Elle se subdivise ainsi:
— ISO 22600-1: Décrit les scénarios et les paramètres cruciaux de l’échange d’informations d’un
domaine de politique à un autre. Elle donne également des exemples des méthodes de documentation
nécessaires pouvant servir de base à l’établissement d’un accord de politique.
— ISO 22600-2: Décrit et explique de manière plus détaillée les architectures et les modèles sous-
jacents de la gestion des privilèges et du contrôle d’accès nécessaires à la sécurisation du partage de
données incluant la représentation formelle des politiques.
— ISO 22600-3: Donne des exemples détaillés de spécifications pouvant être mises en œuvre pour
les services de sécurité et les services d’infrastructure d’applications dans différents langages de
spécification.
Elle prend en compte la mise en relation des politiques. Elle est fondée sur un modèle conceptuel dans
lequel des serveurs d’autorisation locaux et des services d’annuaires et de répertoires de politiques
trans-domaines peuvent faciliter le contrôle d’accès dans diverses applications (composants logiciels). Le
répertoire de politiques fournit des informations sur les règles d’accès à diverses fonctions d’application
sur la base des rôles et d’autres attributs. Le service d’annuaire permet une identification de l’utilisateur
individuel. L’accès sera accordé ou non sur la base des quatre aspects suivants:
— l’identification authentifiée des acteurs principaux (c’est-à-dire utilisateurs humains et objets qui
ont besoin de fonctionner avec leurs propres droits);
— les règles d’accès à un objet d’information particulier, notamment le but de l’utilisation;
— les règles applicables aux attributs d’autorisation associés à l’acteur principal, fournies par le
gestionnaire d’autorisation;
— les fonctions de l’application spécifique.
vi © ISO 2014 – Tous droits réservés

La présente Norme internationale prend en charge une collaboration entre plusieurs gestionnaires
d’autorisation qui peuvent fonctionner au-delà de limites organisationnelles et de politique.
La présente Norme internationale est en relation étroite avec d’autres documents élaborés par le comité
technique ISO/TC 215, tels que l’ISO 17090 (toutes les parties), l’ISO 22857, l’ISO 21091 et l’ISO 21298.
Les personnes qui liront la présente Norme internationale devront également lire toutes les normes
associées.
NORME INTERNATIONALE ISO 22600-2:2014(F)
Informatique de santé — Gestion de privilèges et contrôle
d’accès —
Partie 2:
Modèles formels
1 Domaine d’application
La présente Norme internationale, subdivisée en plusieurs parties, définit les principes de gestion des
privilèges et de contrôle d’accès aux données et/ou aux fonctions et spécifie les services nécessaires à
ces activités.
Elle se concentre sur la communication et l’utilisation des informations de santé distribuées au-delà des
limites d’un domaine de politique. Cela inclut le partage d’informations de santé entre professionnels
de santé non affiliés, établissements de santé, sociétés d’assurance-maladie, patients, membres du
personnel et partenaires commerciaux, par des individus tout comme par des systèmes d’application
utilisés dans un contexte local, voire régional ou même national.
Elle spécifie les concepts nécessaires pour chaque composante et est destinée à faciliter leur mise en
œuvre technique. Elle ne spécifiera pas l’utilisation de ces concepts pour des cheminements de processus
cliniques particuliers.
La présente partie de l’ISO 22600 constitue une introduction au paradigme sous-jacent de modèles
formels de haut niveau pour les composantes architecturales. Elle est basée sur l’ISO/IEC 10746 (toutes
les parties) et introduit le modèle de domaine, le modèle de document, le modèle de politique, le modèle
de rôle, le modèle d’autorisation, le modèle de délégation, le modèle de contrôle et le modèle de contrôle
d’accès.
Les spécifications sont fournies via les métalangages UML (Unified Modelling Language) et XML
(Extensible Markup Language). Des diagrammes supplémentaires sont utilisés pour expliquer les
principes. Les attributs utilisés ont été référencés par rapport au modèle d’informations de référence
HL7 (voir ISO 21731:2006) et aux définitions des types de données HL7.
Le modèle de rôle a été introduit sommairement en faisant référence à l’ISO 21298.
2 Références normatives
Les documents suivants, en totalité ou en partie, sont référencés de manière normative dans le présent
document et sont indispensables pour son application. 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).
1)
ISO 21298:— , Informatique de santé — Rôles fonctionnels et structurels
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
1) À publier.
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
[SOURCE: ISO/IEC 2382-8:1998]
3.2
imputabilité
propriété qui garantit que les actions d’une entité ne peuvent être imputées qu’à cette entité
[SOURCE: ISO 7498-2:1989]
3.3
autorité d’attribut
AA
autorité qui assigne des privilèges par l’émission de certificats d’attribut
[SOURCE: ISO/IEC 9594-8:2008]
3.4
certificat d’attribut
structure de données, ayant été signée électroniquement par une autorité de gestion d’attribut qui lie
certaines valeurs d’attribut à une identification de son détenteur
[SOURCE: ISO/IEC 9594-8:2008]
3.5
authentification
moyen pour une entité d’assurer la légitimité d’une identité revendiquée par l’association sécurisée d’un
identifiant et de son authentifiant
Note 1 à l’article: Voir aussi authentification de l’origine des données et authentification de l’entité homologue.
[SOURCE: ISO/IEC 15944-5:2008, 3.5]
3.6
autorité
entité responsable de l’octroi des certificats
Note 1 à l’article: Deux types d’autorité sont définis dans la présente partie de l’ISO 22600, à savoir l’autorité de
certification qui octroie des certificats de clé publique et l’autorité de gestion d’attribut qui octroie des certificats
d’attribut.
3.7
autorisation
attribution de privilèges comprenant la délivrance de privilèges afin d’avoir accès à des données et
fonctions
[SOURCE: ISO 7498-2:1989, modifiée]
3.8
disponibilité
propriété d’être accessible et utilisable sur demande par une entité autorisée
[SOURCE: ISO 7498-2:1989]
2 © ISO 2014 – Tous droits réservés

3.9
validation de certificat
processus garantissant qu’un certificat était valide à un instant donné, incluant éventuellement la
construction et le traitement d’un chemin de certification, et garantissant que tous les certificats de ce
chemin étaient valides à un instant donné, c’est-à-dire qu’ils n’avaient pas expiré ou qu’ils n’avaient pas
été révoqués
3.10
autorité de certification
CA
émetteur de certificat; autorité de confiance déclarée compétente par une ou plusieurs parties
utilisatrices en matière de création, de délivrance et de gestion de certificats
Note 1 à l’article: L’autorité de certification peut éventuellement créer les clés de parties utilisatrices. L’autorité de
certification émet les certificats en signant les données de certificat à l’aide de sa clé de signature privée.
Note 2 à l’article: La notion d’autorité incluse dans le terme «autorité de certification» n’implique en rien une
autorisation gouvernementale, mais véhicule simplement une notion de confiance. Le terme «émetteur de
certificat» est peut-être moins ambigu, mais le terme «autorité de certification» est très largement employé.
[SOURCE: ISO/IEC 9594-8:2008]
3.11
chemin de certification
séquence ordonnée de certificats d’objets dans l’arbre d’informations d’annuaire (ou arbre DIT) qui,
lorsqu’ils sont associés à la clé publique de l’objet initial dans le chemin, peuvent être traités pour obtenir
le certificat de l’objet final dans le chemin
3.12
confidentialité
propriété d’une information qui n’est ni disponible, ni divulguée aux personnes, entités ou processus
non autorisés
[SOURCE: ISO 7498-2:1989]
3.13
justificatif d’identité
preuve émise à des fins de conditions préalables concernant l’habilitation ou l’éligibilité à un rôle
3.14
délégation
transmission d’un privilège détenu par une entité à une autre entité
3.15
chemin de délégation
séquence ordonnée de certificats qui, lorsqu’ils sont associés à une authentification de l’identité d’un
déclarant de privilège, peuvent être traités pour vérifier l’authenticité du privilège que le déclarant
revendique
3.16
variables environnementales
aspects de politique requis pour une prise de décision en matière d’autorisation qui ne sont pas contenus
dans des structures statiques, mais qu’un vérificateur de privilège peut récupérer par l’intermédiaire de
certains moyens locaux (par exemple, instant de la journée, solde comptable actuel)
3.17
identification
exécution de tests permettant à un système de traitement des données de reconnaître des entités
[SOURCE: ISO/IEC 2382-8:1998]
3.18
identifiant
élément d’information utilisé pour déclarer une identité, avant corroboration potentielle par un
authentifiant correspondant
[SOURCE: ENV 13608-1:2000]
3.19
intégrité
propriété assurant que des informations n’ont pas été modifiées de quelque manière que ce soit (de
manière délibérée ou involontaire)
3.20
clé
série de symboles commandant les opérations de chiffrement et de déchiffrement
[SOURCE: ISO 7498-2:1989]
3.21
non-répudiation
service permettant de fournir la preuve de l’intégrité des données et la preuve de leur origine (ces
preuves étant infalsifiables), que toute partie peut vérifier
[SOURCE: ISO 17090-1:2013]
3.22
politique
ensemble d’obligations légales, politiques, organisationnelles, fonctionnelles et techniques applicable à
une communication et à une coopération
3.23
accord de politique
accord écrit par le biais duquel toutes les parties impliquées s’engagent à respecter un ensemble de
politiques préalablement spécifié
3.24
acteur principal
utilisateurs humains et objets qui doivent fonctionner avec leurs propres droits
[SOURCE: Spécification de l’OMG relative aux services de sécurité (OMG Security Services Specification):
2001]
3.25
clé privée
clé qui est utilisée avec un algorithme asymétrique de cryptographie et dont la possession est limitée
(habituellement à une seule entité)
[SOURCE: ISO/IEC 10181-1:1996]
3.26
privilège
capacité assignée par une autorité à une entité selon son attribut
3.27
déclarant de privilège
détenteur d’un privilège qui utilise son certificat d’attribut ou son certificat de clé publique pour déclarer
un privilège
4 © ISO 2014 – Tous droits réservés

3.28
infrastructure de gestion des privilèges
infrastructure PMI
infrastructure pouvant prendre en charge la gestion des privilèges lors de la prise en charge d’un service
d’autorisation cohérent et de la mise en relation avec une infrastructure de clé publique
3.29
politique de privilège
politique qui explicite les conditions applicables aux vérificateurs de privilège lorsqu’ils fournissent à
des déclarants de privilège qualifiés des services sensibles ou mettent en œuvre de tels services en leur
nom
Note 1 à l’article: La politique de privilège se rapporte aux attributs associés aux services ainsi qu’aux attributs
associés aux déclarants de privilège.
3.30
vérificateur de privilège
entité vérifiant des certificats par rapport à une politique de privilège
3.31
clé publique
clé qui est utilisée avec un algorithme asymétrique de cryptographie et qui peut être rendue publique
[SOURCE: ISO/IEC 10181-1:1996]
3.32
certificat de clé publique
certificat PKC
certificat qui lie une identité à une clé publique
[SOURCE: ISO/IEC 9594-8:2008]
Note 1 à l’article: L’identité peut être utilisée pour appuyer des prises de décision de contrôle d’accès fondé sur
l’identité après que le client a apporté la preuve qu’il a accès à la clé privée qui correspond à la clé publique contenue
dans le certificat PKC (voir RFC 2459).
3.33
rôle
ensemble de compétences et/ou de performances associées à une tâche
3.34
certificat d’attribution de rôle
certificat qui contient l’attribut de rôle, assignant un ou plusieurs rôles au détenteur du certificat
3.35
certificat de rôle
certificat qui, au lieu d’attribuer des privilèges directement à des individus, les attribue à un rôle
Note 1 à l’article: Les individus affectés à ce rôle, grâce à un certificat d’attribut ou à un certificat de clé publique
avec une extension d’attributs d’annuaire de sujet contenant cette affectation, reçoivent indirectement les
privilèges contenus dans le certificat de rôle.
3.36
certificat de spécification de rôle
certificat qui contient l’attribution de privilèges à un rôle
3.37
sensibilité
caractéristique d’une ressource de valeur ou d’importance
3.38
sécurité
combinaison de propriétés de sécurité (telles que disponibilité, confidentialité, intégrité et imputabilité)
[SOURCE: ENV 13608-1:2000]
3.39
politique de sécurité
plan ou programme d’action adopté pour assurer la sécurité informatique
[SOURCE: ISO/IEC 2382-8:1998]
Note 1 à l’article: L’ensemble de règles dictées par l’autorité de sécurité régissant l’utilisation et la mise à disposition
des services et installations de sécurité constitue sa politique de sécurité.
3.40
service de sécurité
service, fourni par une couche de systèmes ouverts, garantissant une sécurité des systèmes et du
transfert de données
[SOURCE: ISO 7498-2:1989]
3.41
source d’autorité
SOA (Source Of Authority)
autorité d’attribut reconnue par un vérificateur de privilège d’une ressource particulière comme étant
la plus haute autorité pour attribuer un ensemble de privilèges
3.42
cible
ressource à laquelle un ayant droit accède
Note 1 à l’article: Sa sensibilité est modélisée dans la présente partie de l’ISO 22600 comme un recueil d’attributs,
qui sont représentés soit sous la forme d’attributs ASN.1, soit sous la forme d’éléments XML.
3.43
confiance
circonstance existant entre deux entités et dont une entité estime que l’autre entité agira exactement
comme la première entité l’entend
Note 1 à l’article: Cette confiance ne s’applique qu’à certaines fonctions particulières. Le rôle clé en termes de
confiance dans ce cadre est de décrire la relation existant entre une entité d’authentification et une autorité. Une
entité doit être certaine qu’elle peut faire confiance à une autorité pour ne créer que des certificats valides et
fiables.
4 Abréviations
AA Attribute Authority (autorité d’attribut)
PKC Public Key Certificate (certificat de clé publique)
UML Unified Modelling Language (langage de modélisation unifié)
XML Extensible Markup Language (langage de balisage extensible)
5 Paradigme de composante
La structure permettant d’atteindre une architecture de système d’informations de santé à l’épreuve du
temps est fondée sur le modèle générique de composantes développé au milieu des années 90 (par exemple,
6 © ISO 2014 – Tous droits réservés

Références [1], [2] et [3]). Les bases de cette architecture sont un modèle d’informations de référence
(également appelé modèle RIM) et des termes de vocabulaire approuvés permettant l’interopérabilité.
En faisant référence à ce modèle RIM et à ces termes de vocabulaire, des modèles de contrainte propres à
un domaine, représentant les concepts de connaissance propres à ce domaine, seront spécifiés en tenant
compte des connaissances structurelles et fonctionnelles. Les composantes correspondantes doivent
être établies en prenant en considération tous les différents points de vue du modèle de référence pour
le traitement réparti ouvert (ou modèle RM-ODP) présenté dans l’ISO/IEC 10746-1, à savoir le point
de vue entreprise, le point de vue information, le point de vue traitement, le point de vue ingénierie et
le point de vue technologie. Un point de vue concentre toute l’attention sur un seul aspect, en faisant
abstraction de tous les autres. Les différents concepts de domaine et la représentation de leur point de
vue ne relève pas de la responsabilité des programmeurs, mais de celle des experts du domaine. Pour
cette raison, ils utiliseront des moyens d’expression appropriés tels qu’une représentation graphique
spécifique (par exemple, des diagrammes UML) ou un texte structuré en langage XML.
Les composantes peuvent être regroupées de manière à former un niveau de composition supérieur.
Contrairement à la définition ISO des notions de primitive et de composition, au moins quatre niveaux
de composition/décomposition ont été définis dans le modèle de composante générique (Figure 1).
Figure 1 — Modèle de composante générique
Le regroupement est effectué selon les connaissances associées au contenu ou au processus par
logique/algorithmes/opérations ou par règles/flux de tâches/procédures/relations. Ainsi, le
regroupement des blocs de construction appelés «modèles de contrainte» est contrôlé grâce aux
mécanismes susmentionnés ou grâce au comportement de l’acteur principal de communication ou de
coopération. La spécification est fournie dans son intégralité au niveau méta. Les différents termes de
vocabulaire ainsi que l’environnement d’outils et la fonctionnalité sont harmonisés par des métalangages
[4]
comme le langage XMI (XML Metadata Interchange).
6 Modèles génériques
6.1 Cadre
La gestion des privilèges et le processus d’autorisation peuvent être basés sur les rôles joués par des
acteurs individuels ou des groupes d’acteurs. Les acteurs interagissant avec les composantes du système
sont appelés «acteurs principaux». Il peut s’agir d’un utilisateur humain, d’un système, d’un dispositif,
d’une application, d’une composante voire même d’un objet.
De manière à obtenir la structure et la fonctionnalité décrites ci-dessus, un certain nombre de modèles,
mécanismes, processus, objets, etc., sont nécessaires et doivent être pris en compte.
En ce qui concerne la gestion des privilèges et la gestion du contrôle d’accès, deux types de classes
fondamentaux doivent être considérés:
— les entités:
— documents;
— acteurs principaux;
— politiques;
— rôles;
— les actes:
— gestion des politiques;
— gestion des acteurs principaux;
— gestion des privilèges;
— authentification;
— autorisation;
— gestion du contrôle d’accès
— audit.
Les modèles suivants seront étudiés plus en détail:
— modèle de domaine;
— modèle de document;
— modèle de formulaire de politique;
— modèle de rôle;
— modèle d’autorisation;
— modèle de contrôle;
— modèle de délégation;
— modèle de contrôle d’accès.
8 © ISO 2014 – Tous droits réservés

Toutes les spécifications élaborées dans ce cadre seront toujours ouvertes, indépendantes de la
plateforme, portables et évolutives. Par conséquent, les modèles fournis sont décrits au niveau méta-
modèle et au niveau modèle, le niveau instance n’étant pas pris en compte. Pour pouvoir exprimer les
systèmes d’une telle manière, on utilise des langages et métalangages spécifiques comme UML et XML,
avec des passerelles pour passer d’un vocabulaire à un autre.
Cette spécification est définie à l’aide de structures de construction UML, de spécifications UML, de
profils UML et de tous les différents diagrammes. Concernant le langage XML, plusieurs applications
dans le cadre de l’ensemble normalisé en langage XML seront utilisées.
Tous les modèles utilisés établissent des types particuliers de contrainte formant des modèles de
contrainte. Cela concerne tous les services ou vues concevables sur les systèmes. Un modèle est une
représentation partielle de la réalité selon des concepts particuliers. Les langages à utiliser pour les
modèles graphiques sont le langage UML et le langage MOF (Meta-Object Facility). Le langage des
modèles verbaux ou textuels est l’ensemble standard XML.
Il est attendu que de nombreux documents seront exprimés en langage XML. La structure d’un tel
document est définie dans une définition de type de document (DTD) ou dans une instance de schéma
XML. Une politique sur les privilèges peut agir directement sur les éléments XML (par exemple, en
comparant des attributs d’un certificat d’autorisation à des éléments du document).
6.2 Modèle de domaine
Afin de pouvoir continuer à gérer et à faire fonctionner des systèmes (complexes) d’informations qui
prennent en charge les soins partagés, les composantes du système associées à l’acteur principal sont
regroupées en domaines, selon leurs propriétés organisationnelles, logiques et techniques communes.
Selon la définition du groupe de gestion d’objet (OMG), ce regroupement pourrait être effectué
pour des politiques communes (domaines de politique), des environnements communs (domaines
d’environnement) ou une technologie commune (domaines de technologie). Une interopérabilité interne
à un domaine quelle qu’elle soit est appelée communication et coopération intra-domaine, alors qu’une
interopérabilité entre plusieurs domaines est appelée communication et coopération inter-domaine. Par
exemple, une communication pourrait être effectuée entre plusieurs services d’un hôpital de manière
interne au domaine hôpital (communication intra-domaine), mais de manière externe au domaine vers
un service particulier (communication inter-domaine). En ce qui concerne les exigences de sécurité, les
domaines de politique de sécurité sont d’un grand intérêt.
Un domaine est caractérisé par un identifiant de domaine, un nom de domaine, une autorité de domaine
et un qualificatif de domaine. La définition de type de données fournie ressemble à celle de la version 3
[5]
d’HL7.
Tableau 1 — Attributs de domaine de politique de sécurité
Attribut Type Remarques
domain_identifier SET Ensemble d’identifiants d’objets ISO (ObjectI-
dentifier)
domain_name BAG Ensemble de noms d’entités (EntityName)
domain_authority_ID OID Identifiant d’objet ISO (ObjectIdentifier)
domain_authority_ ST Chaîne de caractères (String)
name
domain_qualifier CS Valeur simple codée (CodedSimpleValue)
La classe de domaine de politique de sécurité hérite non seulement des attributs de la classe de domaine,
mais aussi des attributs Identifiant de politique et Nom de politique.
Une politique décrit le cadre légal y compris les règles et règlements, le cadre organisationnel et
administratif, les fonctionnalités, les revendications et objectifs, les acteurs principaux impliqués, les
accords, les droits, les obligations et les pénalités définies ainsi que la solution technique mise en œuvre
pour la collecte, l’enregistrement, le traitement et la communication des données dans les systèmes
d’informations. Pour décrire les politiques, des méthodes telles que des modèles de formulaire de
politique ou une modélisation formelle de politique peuvent être déployées.
Dans la présente partie de l’ISO 22600, les domaines sont spécifiés d’une manière générale et leur
définition en pratique peut être souple. Un domaine peut être constitué de sous-domaines (lesquels
hériteront des politiques du domaine parent et pourront les spécialiser). Le plus petit domaine
possible peut être un lieu de travail individuel, ou une composante particulière au sein d’un système
d’informations. Il est possible d’accroître la portée des domaines grâce à des super-domaines, obtenus
en reliant un ensemble de domaines distincts et en formant ainsi un domaine commun à portée accrue
pour la communication et la coopération.
Cette coopération entre domaines exige de définir un ensemble commun de politiques applicable à tous
les domaines intervenant dans le processus de collaboration. Cette définition doit être obtenue à partir
de toutes les politiques pertinentes propres à chaque domaine, pour l’ensemble des domaines concernés.
Ces politiques communes sont obtenues (après négociation) par l’intermédiaire d’un processus connu
sous le nom de mise en relation de politiques (voir Figure 2). Les politiques ayant éventuellement
fait l’objet d’un accord doivent être documentées et signées par toutes les autorités du domaine (voir
l’ISO 22600-1, Annexe A). Dans l’idéal, la mise en œuvre de ce processus dans son intégralité aboutira
à une représentation électronique et à une négociation, permettant une collaboration électronique en
temps réel au sein d’un cadre admis (ayant fait l’objet d’un accord préalable) et réglementé. La négociation
ou la vérification de politique aura alors lieu au niveau de toutes les interactions entre services.
Figure 2 — Mise en relation de politiques
Cette collaboration introduira le besoin de composantes entre les acteurs principaux. Les concepts de
logiciel intermédiaire sont de plus en plus utilisés dans les nouveaux (derniers) systèmes d’informations
de soins de santé. Les composantes de logiciel intermédiaire peuvent assurer l’interopérabilité par
appel direct (services de communication de logiciel intermédiaire) ou par appel en chaîne (incluant
des services d’application de logiciel intermédiaire). Dans ce dernier cas, l’appel est caractérisé par des
modèles différents de délégation (voir paragraphe 6.8).
Une telle architecture peut être représentée par des chaînes de domaines différents, comme illustré à
la Figure 3.
10 © ISO 2014 – Tous droits réservés

Figure 3 — Concept de domaine avec services de logiciel intermédiaire
Du point de vue sécurité, il est globalement estimé qu’un domaine assurant une communication intra-
domaine selon sa propre politique n’a besoin d’une protection qu’au niveau de ses limites avec les domaines
externes ayant des politiques particulières (voire même avec le domaine sans politique que constitue
Internet). Cette protection est mise en œuvre grâce par exemple à des pare-feux, des serveurs proxy, etc.
Il est par conséquent souvent considéré qu’un domaine est fermé par rapport à l’environnement externe.
Il est supposé à tort que le domaine interne est sécurisé en négligeant souvent les menaces et attaques
internes, qui représentent pourtant la majorité des attaques de sécurité.
En ce qui concerne les exigences et conditions particulières relatives aux soins de santé, le modèle
de sécurité sous-jacent doit prendre en compte la totalité des services et mécanismes de sécurité qui
peuvent être accomplis par des micro-domaines sécurisés.
6.3 Modèle de document
Les processus, les entités, les rôles, etc., doivent être documentés, pour obtenir un objet d’informations
donné qui doit être signé de façon à exprimer de manière démontrable les relations particulières existant
entre les entités et les processus. La combinaison des processus et des relations conduit à de multiples
signatures (par exemple, en cas de délégation).
La présente partie de l’ISO 22600 utilise la syntaxe de message cryptographique pour prendre en
charge les multiples signatures d’un document. Chaque signature est placée de manière informatisée
sur le contenu du document et éventuellement sur un ensemble d’attributs signés propre à la signature
donnée. Ces attributs peuvent inclure des horodatages, l’objet de la signature et d’autres informations.
6.4 Modèle de politique
Une politique de sécurité est un ensemble de règles légales, éthiques, sociales, organisationnelles,
psychologiques, fonctionnelles et techniques destiné à garantir la fiabilité des systèmes d’informations
de santé. Une politique sert à formuler le concept d’exigences et de conditions nécessaire à la création,
la collecte, la mémorisation, le traitement, la divulgation, la rétention, la transmission et l’utilisation
d’informations sensibles. Une politique peut être exprimée:
— de manière textuelle sans structure,
— de manière structurée en utilisant des schémas ou des modèles, ou
— par modélisation formelle.
Pour des raisons d’interopérabilité, une politique doit être formulée et codée de manière à ce qu’elle
puisse être correctement interprétée et mise en pratique. Par conséquent, les politiques doivent être
limitées dans leur syntaxe, sémantique, vocabulaire et l’application des documents de politique, aussi
appelés déclarations de politique ou accords de politique (accords entre les partenaires impliqués).
Afin de pouvoir se référer avec certitude à une politique donnée, l’instance de politique doit être
dénommée et identifiée de manière univoque grâce à un identifiant de politique unique. Cette même
règle s’applique à tous les éléments de polit
...