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

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. Le projet DSQ

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. 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. 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. Alimenter le domaine laboratoire

7. Alimenter le domaine laboratoire

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. Consulter le sommaire clinique
PROVINCIAL
Registres
Répertoire
DSQ
Domaines
SUPRARÉGIONAL
Domaines

10. Consulter le sommaire clinique
PROVINCIAL
Registres
Répertoire
DSQ
Domaines
SUPRARÉGIONAL
Domaines

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. TOGAF peut vous aider

13. Phase A: Vision d’architecture

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. 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. Phase C: Architecture d’information

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. Phase G: Gouvernance

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. 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. Gestion des exigences

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. Gestion des exigences
1 Besoins d’affaire
Caractéristiques
2 de solution
Exigences
3 de solution

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. 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. 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. Merci !