DSQ Case Study

1 855 vues

Publié le

Présentation du projet DSQ et de son architecture d'entreprise

Publié dans : Business, Santé & Médecine
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 855
Sur SlideShare
0
Issues des intégrations
0
Intégrations
15
Actions
Partages
0
Téléchargements
56
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

DSQ Case Study

  1. 1. GRAdE Grand Réseau des Architectes d’Entreprise L’architecture d’entreprise à travers le projet d’informatisation du dossier de santé du Québec (DSQ)
  2. 2. Le projet DSQ
  3. 3. Faits intéressants Plusieurs appels d’offres lancés entre 2005 et 2006 Deux fournisseurs principaux ( DMR et Xwave) en partenariat avec la RAMQ (et LGS/IBM) Budget total de 562 millions de dollars Plus de 20 projets font partis du programme DSQ Pour être payé le Québec doit: Respecter l’architecture de référence (Blueprint) d’ISC S’assurer que la solution est utilisés par les intervenants de la santé au Québec (adhésion)
  4. 4. DSQ : comment faire ? En partageant l’information de multiples systèmes Soins à domicile Clinique Services d’urgence Centre de soins Pharmacie communautaires VUE INTÉGRÉE Clients/patients Clinique Laboratoire spécialisée Urgence de l’ Centre de hôpital diagnostic
  5. 5. Emplacement des données cliniques électroniques aujourd’ hui : nombre de systèmes à intégrer Soins à domicile Clinique Services d’urgence Centre de soins Pharmacie communautaires Environ 40 000 systèmes au Canada Clients/patients Clinique Laboratoire spécialisée Urgence de l’ Centre de hôpital diagnostic
  6. 6. Alimenter le domaine laboratoire
  7. 7. Alimenter le domaine laboratoire
  8. 8. Consulter le sommaire clinique PROVINCIAL Services et Données de Registre PROVINCIAL Registre Registre Registre Usager Intervenant ODS/LDS Registres Registre Services PSR Répertoire Consentement (LCA) Imagerie Diagnostique Répertoire Services et Données DSE DSQ Médicament Immunisation Communautaire Institutionnel Domaines SUPRARÉGIONAL Gestion des Autres Laboratoire demandes Données de services Cliniques SUPRARÉGIONAL Imagerie Imagerie Diagnostique Diagnostique Domaines
  9. 9. Consulter le sommaire clinique PROVINCIAL Registres Répertoire DSQ Domaines SUPRARÉGIONAL Domaines
  10. 10. Consulter le sommaire clinique PROVINCIAL Registres Répertoire DSQ Domaines SUPRARÉGIONAL Domaines
  11. 11. Enjeux et défis Plus de 20 projets/solutions à gérer et intégrer au sein du même programme Redditions de comptes à Inforoute Santé Canada (ISC) Travailler en transparence avec le vérificateur général du gouvernement S’assurer de l’adhésion des intervenants de santé au Québec Comment s’assurer que les différents composants de solutions sont conformes aux exigences d’affaires et la vision stratégique ? Comment s’assurer que les fournisseurs de solution sont conformes à l’architecture de référence d’ISC ? Comment s’assurer que les essais couvre l’ensemble des exigences du programme ? Comment faire face aux changements de la vision stratégique ?
  12. 12. TOGAF peut vous aider
  13. 13. Phase A: Vision d’architecture
  14. 14. Phase A: Vision d’architecture S’assurer que l’initiative a le support et l’ appuie nécessaire de la direction Identifier les exigences et les contraintes de l’initiative Présenter une vision d’architecture qui répond à ces exigences et contraintes Cette phase sert essentiellement à vendre l’ initiative auprès de la direction de l’ entreprise Définir un état des lieux sur l’architecture existante Identifier les « points de vues » sur l’ architecture
  15. 15. Phase A: Vision d’architecture DSQ – Architecture niveau 1 Cette vision nous permet d’avoir une architecture cible intégré en ligne avec les besoins d’affaire et la vision stratégique
  16. 16. Phase C: Architecture d’information
  17. 17. Phase C: Architecture d’information Définir l’architecture cible de données ou d’information Définir l’architecture applicative cible DSQ: Permet d’établir la cible et d’assurer l’ arrimage avec le modèle d’information du ministère de la santé
  18. 18. Phase G: Gouvernance
  19. 19. Phase G: Gouvernance Formuler une recommandation pour chaque projet Établir un cadre de gouvernance efficace et robuste Utilisation de COBIT Établir un cadre de contrat afin de gouverner le processus de réalisation de déploiement S’assurer de la conformité des projets avec l’architecture définie précédemment
  20. 20. Phase G: Gouvernance DSQ: Permet d’assurer que la solution développé par les fournisseurs est en ligne avec l’architecture cible et donc avec les besoins d’affaires Permet d’assurer une meilleure gestion de changement ainsi qu’une gestion de la portée plus efficace Permet de s’assurer que les fournisseurs livrent ce qu’ils doivent livrés Assurer la mise en place d’un processus décisionnel efficace !
  21. 21. Gestion des exigences
  22. 22. Gestion des exigences Définir un processus où les exigences de l’ architecture d’entreprise sont identifiées, stockées et correctement alignées avec les différentes phases de l’ADM Assurer une traçabilité efficace entre les exigences et les différents artefacts provenant des phases de l’ADM Méthodologie de gestion des exigences: Volere template
  23. 23. Gestion des exigences 1 Besoins d’affaire Caractéristiques 2 de solution Exigences 3 de solution
  24. 24. Concept - Différents niveaux d’exigences Niv. 1 - Besoins d’affaires (Needs) Exprimés sous forme de Buts ou Objectifs à atteindre … Exprimés de façon mesurable, S.M.A.R.T. Niv. 2 - Caractéristiques de solution (Features) Éléments de solution, capacités organisationnelles, fonctionnelles ou non-fonctionnelles, qualités, conditions, contraintes, règles, critères, … qui doivent permet de rencontrer les besoin d’affaires (i.e. exigences du niv. 1) Niv. 3 - Exigence de solution (Use Cases & Supplementary Specifications) Processus, cas d’utilisation ou exigences supplémentaires (fonctionnelles ou non-fonctionnelles) qui définit le comportement attendu et les critères d’acceptation de la solution logicielle
  25. 25. Qualités d’une exigence de type « Objectif » SMART Spécifique : L’objectif concerne des personnes, des conditions générales etc. concrètement désignées ; les limites du domaine de l’objectif sont fixées par avance. (Specific, Significant, Stretching, Simple) Mesurable : Doit pouvoir être observable et mesurable, il est possible de définir les qualités et, le cas échéant, les quantités indiquant l'atteinte d'un objectif ; et des indicateurs peuvent en être déduits. (Measurable, Meaningful, Motivational, Manageable) Adapté : S’agit-il du « bon » objectif ? Les mesures prévues correspondent-elles à un besoin ? (Achievable, Agreed, Attainable, Assignable, Appropriate, Actionable) Réalisable : Les perspectives d’atteindre l’objectif sont suffisamment bonnes dans le contexte donné (ressources, temps, compétences) ; aucun facteur externe et incontrôlable n’empêche d’ atteindre l’objectif. (Relevant, Realistic, Results-oriented, Resourced, Rewarding) Temporellement définie : Doit avoir une cible temporelle identifiée, un cadre temporel est fixée par avance
  26. 26. L’architecture d’entreprise au DSQ - Sommaire Vision d’architecture – Phase A Cette vision nous permet d’avoir une architecture cible intégré en ligne avec les besoins d’affaire et la vision stratégique (Niveau 1) Architecture d’information - Phase C Permet d’établir la cible et d’assurer l’arrimage avec le modèle d’information du ministère de la santé La phase A et C nous permettra d’assoir une architecture cible intégré qui nous servira pour la conformité Gouvernance - Phase G Permet d’assurer que la solution développé par les fournisseurs est en ligne avec l’architecture cible et donc avec les besoins d’affaires Permet d’assurer une meilleure gestion de changement ainsi qu’une gestion de la portée plus efficace
  27. 27. Merci !

×