Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

OBJET DU DOCUMENT

L’objet de ce document est de présenter l’architecture fonctionnelle issue du travail d’urbanisation mené dans cette étude. Cet exemple d’architecture fonction a plusieurs objectifs. Il s’agit :

L’architecture fonctionnelle proposée dans ce document est centrée sur les fonctions support des processus métier de production de soins. Elle est resituée dans le cadre du SIH global mais les fonctions décrites sont essentiellement celles qui correspondent à un besoin de la production de soins telle qu’elle est envisagée dans l’architecture métier décrite dans l’étude (cf. [2] Exemple d'architecture métier d'un système de prise en charge du patient en unité clinique – SI35MOD).

Les fonctions des blocs périphériques tels que « pilotage, supervision, facturation et contrepartie », « gestion des ressources », « administration de la connaissance », ne sont pas ou peu décrites car en dehors du périmètre de cette étude.

PRINCIPES DE CONSTRUCTION DE L’ARCHITECTURE EXEMPLE

Les principes suivants ont été appliqués pour construire l’architecture fonctionnelle présentée dans ce document :

  • Elle fait abstraction de l’existant :

Cette étude est issue de la réflexion menée en commun par une quinzaine d’établissement de santé, publics et privés, de toute taille (CHU, CH, CLCC, PSPH, etc.). Etant donné la diversité des existants en matière de SIH, la construction de la cible fonctionnelle exemple n’a fait aucune hypothèse en la matière. Cet exemple d’architecture fonctionnelle peut constituer une base de travail pour tout établissement de santé. Pour autant, un travail d’adaptation à l’existant sera systématiquement nécessaire :

Pour construire le SIPS (Système d’information de production de soins) cible, les processus métier comme les besoins fonctionnels ont été définis de manière à répondre aux grands objectifs partagés par l’ensemble des systèmes d’information hospitaliers tels que :

 

  • Partager les informations patient ;
  • Assurer leur cohérence, leur qualité, leur interopérabilité ;
  • Répondre aux objectifs du contrat de bon usage du médicament ;
  • Faciliter la mise en place de la T2A.

 

  • Elle tient compte du niveau de maturité des technologies actuelles :

Cette architecture se veut réaliste compte tenu des possibilités actuelles de la technologie. Elle a, à ce titre, vocation à constituer un élément directeur pour les offres de solutions logicielles.

  • Elle doit permettre l’urbanisation du SIH :
  • L’organisation de l’architecture fonctionnelle proposée (c’est à dire les regroupements fonctionnels) a été guidée par des principes visant à urbaniser le système d’information :
  • L’optimisation des flux d’information (limiter le nombre, la dimension et la criticité des flux d’informations inter-blocs) ;
  • La cohérence métier des blocs fonctionnels constitués (autant que possible, un même bloc fonctionnel est utilisé par des acteurs similaires, dans des situations similaires);
  • La simplification de l’organisation fonctionnelle (limiter le nombre de fonctions).

Exemple : Le fonctionnement de la gestion du plan de soins exploite directement les informations produites par les fonctions de prescription (demande) et de réalisation. Ces fonctions sont donc positionnées dans le même bloc « Production clinique et médico-technique » pour assurer une meilleure maîtrise du flux d’informations (optimisation métier). L’ensemble des fonctions de ce bloc permet de suivre le parcours de soins du patient (cohérence métier).

PRECISIONS

Typologie des fonctions

Afin de faciliter la lecture de cet exemple d’architecture fonctionnelle, une typologie des fonctions a été définie. Toute fonction identifiée dans cette architecture doit correspondre à l’un des types suivant :

  • Création et mise à jour :

Fonctions permettant de créer, de modifier ou de supprimer (suppression logique uniquement) des objets d’information.

  • Consultation :

Fonctions permettant de consulter des informations ;

  • Validation :

Fonctions permettant de modifier le statut de certains objets d’information (Prescriptions, compte-rendu, etc.)

  • Recherche :

Fonctions permettant de rechercher des objets d’informations. Cette recherche peut s’effectuer à partir d’un identifiant ou mettre en oeuvre une recherche associée au renseignement de critères de recherche étendus (questionnaires discriminants, recherche textuelle sur traits, etc.). Les autres types de fonctions pourront généralement être lancés à partir du résultat d’une recherche (consultation, création et mise à jour, etc.) ;

  • Edition :

Fonctions permettant de produire une ou plusieurs informations sur un support physique (impression papier, production d’une carte à puce, etc.) ;

  • Publication :

Fonctions de transmission ou diffusion active d’informations (par envoi d’un message électronique par exemple), par opposition au partage d’information (enregistrement au sein d’un référentiel partagé).

  • Identification :

Fonctions permettant l’identification d’un objet ou d’une personne. L’identification à 2 finalités :

  • Associer à un objet une marque (un identifiant) permettant d'identifier celui ci et uniquement celui ci de façon fiable et univoque dans une collection ;
  • Identifier un objet dans une collection à partir de son identifiant (souvent appelé par extension "index ou clé").

Description d’une fonction

Dans le cadre de la présente étude et pour les besoins des travaux d’urbanisation, la notion de « fonction » est définie ainsi :

« C’est un service instrumentant ou venant en support d’une tâche : Collecte, traitement, restitution ou transmission d’une ou plusieurs informations dans le contexte d’une activité d’un processus. La fonction définit des services attendus en termes de finalité (exemple : s’authentifier, éditer, consulter), non de solutions. Elle pourra être totalement automatisée, partiellement ou pas du tout. »

La fonction est envisagée comme un élément de description (modélisation) de l’architecture fonctionnelle. En ce sens, son objet premier (pour les besoins de l’urbanisation) est de cadrer précisément un besoin fonctionnel. Les fonctions sont donc décrites ici en termes de :

  • Fonctionnalités offertes ;
  • Règles de gestion notables s’il y a lieu.

Les principaux objets d’information (objets métier) utilisés ou produits par une fonction sont également identifiés par ailleurs (se reporter pour cela au Tableau de description des éléments d’un système d’information – SI35MFAP (réf. [5]).

Ce niveau de description est celui qui permet à l’urbaniste de faire les choix adéquats lorsqu’il construit l’architecture cible. Dans un second temps, lors des phases projet, les fonctions devront être décrites plus précisément, et faire l’objet de spécifications fonctionnelles. Il s’agira alors de décrire plus en détail :

  • Les données gérées par la fonction (données utilisées et données produites) ;
  • Les traitements effectués par la fonction ou les règles de gestion de la fonction ;
  • L’ergonomie de la fonction (les principaux écrans par exemple, le type d’interface).
  • Les liens avec les autres fonctions le cas échéant (matrice de service).

Périmètre fonctionnel

Toutes les fonctions ne sont pas décrites dans ce document. Les principales fonctions associées à la production de soins ou les fonctions fortement dépendantes entre elles de par leur utilisation ont fait l’objet d’une description plus détaillée.

Cette ressource vous paraît-elle utile ?

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Architecture fonctionnelle du système de prise en charge du patient (Méthode).

Vous êtes perdu ?

Haut de page

Vous êtes actuellement sur la page consacrée à Architecture fonctionnelle du système de prise en charge du patient (Méthode).

Vous êtes perdu ?