Registratie van de softwarepakketten 2019 - Voorstelling aan de softwareproducenten voor de huisartsen - ehealth.fgov.be
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Registratie van de softwarepakketten 2019
[Voorstelling aan de softwareproducenten
voor de huisartsen]
Frank.Robben@ksz-bcss.fgov.be
https://www.ehealth.fgov.be
Plan
• 0. Inleiding (5’)
– 0.1 Doel van de presentatie
– 0.2 Herhaling over de registratie
• 1. Waarom nieuwe criteria (5’)
• 2. Hoe : WG en werkzaamheden (5’)
• 3. Wat : (30’)
– 3.1 Verschillen in 2019 :
• 3.1.1 Thema's,
• 3.1.2 Herzien registratieprocessen
• 3.1.3 Communicatie & coördinatie
• 3.1.4 Planning
– 3.2 Praktijkpremies, testmodaliteiten & kosten
– 3.3 Te testen sleutelcriteria
• 4. Focus op de nieuwigheden (30’)
• 5. QA (30’)
2
0.1 Doel van de presentatie
• Status van de registratie
– inhoud
– planning
• Release Version 1.0 van de criteria
& Kick-off Q&A
3
0.2 Herhaling over de registratie
• Waarom:
– ervoor zorgen dat de voorgestelde softwarepakketten beveiligd zijn en aan de
functionele en kwalitatieve behoeften voldoen van de professionals in de
gezondheidssector en van de overheid
– ervoor zorgen dat ze afgestemd zijn op de strategische en operationele
doelstellingen van de Roadmap eGezondheid
• Rol van het eHealth-platform:
– vastleggen van de registratiecriteria
– praktische coördinatie van de registratie (regisseur)
– rol “notaris” en communicatie
40.2 Art 3 p3 – 21/8 ehealth wet
50.2 Scope en geldigheid van de 2019 registratie
• Functionele scope
– gedefinieerd als het “basispakket”: criteria testen + documentatie
– het eHealth-platform bepaalt de criteria en zorgt voor de documentatie ervan
en verricht de testen
• Modulaire scope
– focus op de technische testen van de diensten, bv. MyCarenet door het NIC
• Geldigheid
– basispakket: tot de volgende versie van de criteria (standaard 3 jaar)
• verwachte flexibiliteit: de nieuwe onderwerpen moeten in acht worden genomen, ofwel
volgens de wettelijke voorschriften, ofwel binnen de 12 maanden (na goedkeuring binnen
medicomut)
– modules : vast te leggen door elke module (default ~3 jaar)
61. Waarom nieuwe criteria
• Tot ~2015
– op basis van functionele criteria en focus ligt voornamelijk op de
administratieve vereenvoudiging
– de laatste testsessie vond plaats in 2013/2014 op basis van de criteria
2012/2013
• In 2019
– focus op data interoperabiliteit
– aanpassing van de criteria noodzakelijk voor de toekomstige uitdagingen /
Roadmap 3.0
beslissing om het debat te openen, afstand te nemen en
opstarten van een werkgroep
72. Samenstelling van de WG
• Deskundigen op het werkveld (coördinatie door eHealth-platform)
– Benjamin Fauquert
– Herwig Van Pottelbergh
– Jos Devlies
– eenmalige samenwerkingen met de academische wereld: Nicolas Delvaux en
Etienne De Clercq
– validatie door RIZIV, NIC, Hub/Kluizen, FOD Program Manager
82. Aanpak van de WG
Diagnose van de situatie op basis van de ervaring van de WG
• Huidige vaststellingen en beperkingen:
– geen eenduidige en doeltreffende terminologie
• talrijke “verschillende” concepten (soms synoniemen)
• ontbrekende en slecht gedefinieerde concepten
– gebrek aan standaardisatie
– de registratie in sommige EMD >>3.1.1. Resultaten van de werkzaamheden van de WG
• Een set aan criteria GP die in 8 thema’s zijn opgedeeld
– 00. Generieke criteria: toe te passen voor alle functionaliteiten
– 01. Structurering en inhoud van het EMD: standaardstructurering en inhoud
• 1a : Medische / administratieve data
• 1b : Gegevens met betrekking tot gezondheid
– 02. Gegevensbronnen (verwijzing, codering en gegevenstabellen)
– 03. Gegevensinvoer & Visualisatie
– 04. Statistische verslagen
– 05. Interne (administratieve en medische) kenmerken
– 06. Externe interacties met het EMD
– 07. Contractuele aspecten
• Deze criteria zullen als basis dienen voor het bepalen van de volgende
doelgroepen, bv. verpleegkundigen
103.1.2. Herzien registratieproces
• Alle softwarepakketten moeten de registratie doorlopen voor het jaar
2019 (old & new: iedereen op gelijke voet)
• Alle criteria “2019”* moeten OK zijn (einde van de interpretatie van de
resultaten)
• In de praktijk
– “basispakket”
• th 0 5 & 7 goedgekeurd en getest door eHealth-platform
• registratie « On Demand » cf. slide « Testmodaliteiten »
– “modules”
• mini-labs of Approval Assessment georganiseerd door de instellingen die
verantwoordelijk zijn voor de diensten (eHealth-platform, NIC, kluizen, RECIP-e, enz.)
• coördinatie op het niveau van het eHealth-platform: publicatie van een kalender,
optimalisering/hergroepering (indien mogelijk) van de verschillende testen
*cf documentatie
113.1.3. Communicatie & coördinatie
– Naar de zorgverleners
• website eGezondheid
– https://www.ehealth.fgov.be/nl/egezondheid/beroepsbeoefenaars-in-de-
gezondheidszorg/registratie-van-de-softwarepakketten/algemene-
voorstelling
• lijst van de geregistreerde softwarepakketten* (functionaliteiten en
modules)
– Naar de softwareproducenten
• website eHealth-platform
– https://www.ehealth.fgov.be/ehealthplatform/nl/service-
registratie-van-de-softwarepakketten
• publicatie van de criteria en van de documentatie (vanaf 14/3)
• coördinatie op het niveau van het eHealth-platform:
– publicatie van de verschillende minilabs op de eHealth-platform
portal
– linken naar de technische documentatie van de eHealth-
diensten maar ook linken naar de documentatie van de partners
sites (NIC, Kluizen, etc.)
• publicatie van de datums en inschrijvingsmodaliteiten voor de minilabs
(05/2019)
*Bijwerking voorzien in 05/2019
123.1.4. Planning 2019/2020
GP
• Publication des critères pour Q&A le 14/3
• Présentation en Médicomut 18/3
• Présentation au comité de gestion 9/4
• Finalisation et publication d’une version frozen* des critères incluant les réponses aux questions et
modalités d’enregistrement 19/4
• Début des enregistrements pour le socle de base 1/5
• Planning pour les modules en 05/2019
Infirmiers
• Début du groupe de travail 13/2
• Publication estimée : Q3 2019
Dentistes
• Début du groupe de travail : Q3 2019
• Publication estimée : Q4 2019 / Q1 2020
*les Q&A vont continuer à évoluer 133.2. Primes de pratique
• Enregistrement par l’eHealth-platform (socle de base et modulaire) est
toujours un prérequis pour l’obtention des primes de pratiques
– publication de la liste des logiciels agréés sur le site INAMI basée sur les
résultats des enregistrements et l’acceptation par la Commission nationale
médico-mutualiste
– INAMI : explication primes de pratique
• Primes 2019 :
– enregistrement (set de critères minimum 2019) avant le 31/12/2019
143.2. Modalités de test « socle de base » (1/2)
• Inscription
– inscriptions en ligne
– un calendrier des plages possibles sera publié
– validation de la date de test après réception du paiement
– délais de 6 semaines maximum entre l’inscription et les tests
• Tests / Documentation
– tous les critères sont à documenter ou à tester (cf. documentation des critères)
• 2019 = scope 2019 / 2020 = scope 2020
• T = Tester / D = Documenter
• N = nouveau (par rapport 2013) / PN = partiellement nouveau
– un même scénario de test peut englober plusieurs critères
– focus des tests sur certains critères clefs (anciens et nouveaux)
note: scope étendu si nouveau logiciel (pas encore enregistré)
– la documentation doit être envoyée minimum 2 semaines avant les tests
153.2. Modalités de test « socle de base » (2/2)
• Pratiquement
– les tests sont effectués en principe dans les locaux définis par la Plate-forme
eHealth
– une session de test dure maximum 4 heures
• début à 10 AM , installation possible à partir de 9 AM
– retest possible (délais selon disponibilités)
• Résultats
– rapport détaillé disponible après un mois
• pass/fail statut par critère
– publication des résultats sur le site eSanté une semaine après disponibilité des
rapports
163.2 Kosten
• Prijs voor een eerste testsessie bedraagt € 3000,- excl. BTW
• Bij een hertest bedraagt de prijs max. € 2500,- excl BTW (prijs hangt af van
welke criteria opnieuw getest moeten worden)
173.3. Critères clefs 2013 – A retester / documenter en 2019
• Une série* de critères fondamentaux déjà présents en 2013 font parties
du scope de l’enregistrement 2019 car les software ont évolué (détecter
les régressions)
– Single Sign On + Register Once Use Everywhere + Incomplete date management
– Kmehr compatibility & mise à jour obligatoire des tables de reference
– eID pour identifier un patient (2019 = par défaut)
– disponibilité de modèles de saisie par défaut incl. paramètres et mesure
– gestion des trajets de soins (liés à des indications)
– support de la Prévention Primaire
– possibilité de faire des recherches combinées multicritère (ET/OU) sur les données de
santé, les service et les actes.
– gestion des SumEHR et PMF + création de dossiers à partir de ceux-ci
– édition des documents avant exportation (une modification doit être répercutée dans le
dossier)
*La liste présentée ici est non exhaustive, la liste exhaustives se trouve dans la documentation
183.3. Critères clefs 2019 (Nouveaux) à tester (1/3)
• DMI Structuré* : approfondissement
– focus sur la mise en place d’un modèle fonctionnel : Health Elements,
Contacts, etc. (ce n’est pas un modèle de DB obligatoire mais bien fonctionnel)
– support de listes standards de Health Elements et attributs et structuration de
ceux-ci (ex: “Parent” health element)
– standardisation et extension des données medico administrative, assurabilité,
autorisations, etc.
• Evolutivité des données cliniques (renommer/transformer, liens parents) +
versioning des éléments*
• Visualisation
– composition standard proposées par défaut et customisable par l’utilisateur
– visualisation graphique d’éléments (mesures, events, etc.)
• Màj automatique des référentiels & gestion des versions de ceux-ci
* Traité plus loin en détail
193.3. Critères clefs 2019 (Nouveaux) à tester (2/3)
• Compatibilité avec les nouveaux standards d’échange de données: HL7 , FIHR, etc.
• Lecture et intégration de données externes intra & interprofessionnel ex : avis,
résultats, rapport
• SumEHR V2* + improved population (attribute “Relevant”) + confidentialité
• Médication
– Améliorer l'identification de la médication
– introduction des concepts : ligne de médication, historique de la prescription,
posologie et traitement
– synchronisation du schéma de médication
• SSO & Intégration avec :
– BELRAI (incl. intégration des rapports en retour)
– CEBAM
– Autres: MyHandicap, Euthaconsult, UPPAD
• Disponibilité d’un set minimum de données localement (soft dans le cloud)*
• Export PMF V2
* Traités plus loin en détail 203.3. Critères clefs 2019 (3/3)
• Dernières versions des services eHealth (avec tests spécifiques) ex. Bis
Creation, BCP, eHealthbox, Certificate Manager
• Dernières versions des services CIN (avec tests spécifiques), focus sur
eAttest V2, Mediprima Tar. & Fact, Member Data
• Dernières versions des services et fonctionnalités Hubs & coffres forts
(avec tests spécifiques) avec focus sur le schéma de médication,
SumEHRV2, Statut documents Hub, notes journal, liens thérapeutiques
• Dernière version de Recip-e (V4)
– Incl. SAM V2
213.3. Critères clefs 2020
• Possibilité de gérer plusieurs codes (MultiCoding) pour une même donnée
ex: attribut pour une pathologie
• Gestion des demandes de laboratoire (visualisation et integration)
• Mise en place de références croisées pour les ordres et prescriptions
• Intégration de l’aide à la décision (EBMPracticeNet)
• Gestion de dates d’expirations* pour les éléments de soins & routines de
nettoyage (pour les reporting) basées sur ceux-ci
• Rapports supportants le suivi des primes INAMI
• Implémentation/Intégration de MultiMediatt , Orgadon, HealthData (API)
• Mise en place d’alertes et gestion de celles-ci*
* Traités plus loin en détail
22SPOC Soft eHealth-platform
Stéphane Houpresse
Stephane.houpresse@ehealth.fgov.be
234. Focus sur les nouveautés par le GT
• 4.1. Structuration du DMI
• 4.2. SumEHR V2
• 4.3. Minimum offline set of data
• 4.4. Data Cleaning - Alerting
244.1.The Electronic Health Record
The EHR evolved meanwhile from that “store and retrieval” approach into
“an application that stores, retrieves, exchanges and shares patient related
data”.
• The EHR could be time-oriented (contacts journal), source-oriented (labo
journal, measure journal...) or problem- oriented (problem list and ideally
episode of care).
• The goal of EHR structure proposed is to combine the 3 possibilities.
• We strongly insist on the problem oriented approach which has proven its
efficiency to ensure continuity of care at the patient level particularly in a
context of chronic diseases and to ensure exchangeable SumEHR of good
quality.
– ask to register and manage correctly the problems
254.1. Pertinence des SumEHR
Actuel Désiré
• Problèmes actifs et antécédents • Problèmes
– vides – actifs
– non relevants – relevants
– Extrait du journal – à jour
– Extrait de l’anamnèse
– incomplet Fonction d’enregistrement unifiée
Fonctions de mise à jour
• Difficile à importer dans les Penser au destinataire:
logiciels techniquement et cliniquement
Un seul concept de problème
264.1. Le modèle conceptuel utilisé
• Utilisation d'un modèle conceptuel générique, avec un set limité de
concepts de base.
• Composition
– 7 concepts de base
– liste prédéfinie d’attributs
– utilisation si possible de références existantes: codage pour faciliter
l’interopérabilité des données (y compris les doublons au sein du même
dossier)
274.1. Le modèle conceptuel utilisé
HealtElement
284.1. Le concept de problème
(business process)
• Incertitude
– symptome diagnostic
• fatigue anemie, mononucleose, cancer ?
– symptome allergie
• rash ibuprofen allergy ? Amoxicillin allergy ?
– signe facteur de risque
• tension élevée hypertension ?
– signe diagnostic
• syndrome obstructif asthme ? COPD ?
• Temporalité
– actif passif
– passif actif
– continuité des soins : reprendre et enrichir les problèmes existants
• Nécessité de mise à jour du problème en fonction de l’évolution clinique
294.1. Le concept de problème
Problème =
Facteurs de • symptome
Antécédents
risque
• ou signe
• ou diagnostic
• ou facteur de risque
• ou allergie
Problèmes
Allergies
actif
304.1. Le concept de problème
synthèse = vue chronique Consultation = vue aigue
Contact
Facteurs de
Antécédents
risque
• Subjectif
• Objectif
• Appréciation
Problèmes
actif
Allergies
• Planification
314.1. Un concept de problème unifié
Appréciation / Problème
• Libellé*
• Code*
• Type* (facteur de risque, allergie,
intolérance)
• Rémanence* (actif/passif)
• Relevance* (oui/non)
• Confidentialité
• Texte libre
• Quand ?
• pendant le contact
• à la publication du SumEHR
324.2 SumEHR V2
• SumEHR Doelstelling
- gezondheidsfoto van de patiënt
• de belangrijkste elementen uit het dossier
- doelstelling continuïteit van de zorg
• niet geplande zorg: wachtposten, spoed
• geplande zorg: achtergrond bij verwijzing
• Huidige Problemen
- SumEHR = ondermaats
• lege SumEHRs
• overvolle chaotische SumEHRs
• onvolledige SumEHRs
• Oorzaken
- Kwaliteit van de registratie duidelijke keuze voor HealthElement/Lifecycle
- EMD: gebonden: verschillende concepten: zorgelement, evaluatie, probleem,
diagnose, episode
- SumEHR V1 is onvolledig: diagnostische/therapeutische antecedenten -
wilsbeschikkingen
344.2 SumEHR V1 V2
354.2. SumEHR V1 V2
364.2 DNR Code
• DNR 0 Geen therapiebeperking
• DNR 1 Geen reanimatie
• DNR 2 Geen reanimatie en geen uitbreiding therapie
• DNR 3 Geen reanimatie en afbouw therapie
374.2 Hospitalisatie
• Hospitalisatie 0 Geen beperkingen
• Hospitalisatie 1 Geen hospitalisatie
• Hospitalisatie 2 Hospitalisatie enkel in specifieke
omstandigheden
384.2 Volledigheid dossier
Bepaalde gegevens zijn op vraag van de patiënt niet opgenomen in de
Sumehr
394.2 Sumehr Criteria
• Vanuit een sumehr een nieuw dossier opbouwen
• Statistieken: aantal sumehrs tellen voor praktijkpremie : unieke sumehrs
voor 1 patient/jaar
• Confidentialiteit = > 4: geen export naar sumehr
• Confidentialiteitstabel:
– 0 Geen aspecten van confidentialiteit (Demografische gegevens bijv.)
– 1 Verantwoordelijke derden, tutor, ouders, instelling (Dossierelementen ikv concrete
zorgverlening)
– 2 Gegevens in het kader van verwerven of behouden van (sociale) rechten
– 3 Elke zorgverstrekker met therapeutische relatie (DEFAULT)
– 4 Elk lid van een interprofessioneel zorgteam
– 5 Elk lid in groepspraktijk
– 6 De houder van het GMD
– 7 De auteur zelf
404.3 Minimum offline set of data
• Dit geldt voor EMD die in de Cloud werken
• Minimaal moet er lokaal voldoende aanwezig zijn om te kunnen verder
werken zo offline om een of andere reden :
– visualisatie Sumehr & Signalementskaart
– beperkte data opslag
414.4. Data cleaning - Alerting
• Data Cleaning = Up-to-date houden van de gegevens (manueel maar ook
geautomatiseerd) (LATER 2020)
– medicatie - HE - therapeutische procedures
– Life Cycle verplicht attribuut aanpassing terminologie: Active/ History/ Archive
– attributen : Expiry date & Status after expiry
– aanbod ACHG : geautomatiseerde cleaning op basis van ICPC2
• Alerting (LATER 2020)
– alert = message to the user (reminder or warning)
– opstart bij registratie of openen file
• vaccinaties
• preventieve procedures
• bv. allergie bij voorschrift
• gradatie:
– 1 beperkte impact
– 2 matige impact
– 3 belangrijke impact steeds alert + mogelijkheid tot commentaar
42Vous pouvez aussi lire
