MedMij:Vsuperdraft Beheerproces

Uit informatiestandaarden
Ga naar: navigatie, zoeken

Inleiding

Algemeen

Een goed beheer van de standaard is minstens zo belangrijk als de ontwikkeling zelf. Een goed ingericht beheerproces biedt voor alle betrokkenen transparantie op welke wijze aanpassingen in de standaard bewerkstelligd kunnen worden. Op deze wijze wordt blijvend draagvlak gecreëerd, en zullen aanpassingen in de standaard probleemloos verlopen.

Doelgroep

Dit document is bedoeld voor allen (bestuurders, beleidsmakers, zorgprofessionals van de organisaties, informatiearchitecten, leveranciers, et cetera) die betrokken zijn bij of geïnteresseerd zijn in het beheer van de MedMij informatiestandaarden.

Doel en beoogde geldigheid in de tijd van de beheer afspraken

De toegelaten MedMij informatiestandaarden zijn in twee groepen in te delen:

  • Door MedMij ontwikkelde standaarden: MedMij-eigen standaarden
  • Extern beheerde standaarden waar MedMij-specifieke onderdelen aan toegevoegd zijn (zoals FHIR-resources, use cases, et cetera)

Het beheer is daarmee onder te verdelen:

  • MedMij is beheerder van de MedMij-eigen standaarden
  • MedMij is beheerder van de MedMij-specifieke onderdelen die aan extern beheerde standaarden zijn toegevoegd.
  • MedMij is geen beheerder van de extern beheerde standaarden. Het beheer daarvan wordt uitgevoerd door de verantwoordelijke beheerorganisatie en volgens de beheercyclus van deze eigen beheerorganisatie.

Er zal een zorgvuldig evenwicht moeten worden gevonden in de afspraken over het proces van beheer tussen stabiliteit en status quo enerzijds en slagvaardigheid en innovatie anderzijds.

Om die reden wordt op deze pagina beoogd om de detail afspraken te beschrijven, waarmee in ieder geval een eerste jaar (van Q1 2019 t/m Q1 2020) van beheer wordt ingericht. Uiterlijk QX XXXX, maar eerder indien daar aanleiding voor is, zal een evaluatie worden gehouden van deze afspraken, met als doel de afspraken bij te stellen, indien nodig.

Scope

De focus van deze pagina ligt op het beheer van de MedMij informatiestandaarden. Het ontwikkelproces van informatiestandaarden in het algemeen wordt buiten beschouwing gelaten. Meer informatie daarover is te vinden in Informatiestandaarden in de zorg.

Welke rol vervult Nictiz bij het beheer van de MedMij informatiestandaarden?

In het beheerproces vervult Nictiz de rol van één of meerdere actoren. Daarnaast zijn verschillende partijen betrokken bij het beheer. Zij dragen gezamenlijk zorg voor het beheer van de MedMij informatiestandaarden, en hebben in het beheerproces bepaalde verantwoordelijkheden en taken.

Nictiz gebruikt een generiek model als basis voor het inrichten van het beheer van standaarden en dus ook voor het beheer van MedMij informatiestandaarden. Daar waar mogelijk is in dit document gebruik gemaakt van reeds bestaande standaarden en normen op gebied van beheer, zoals de NEN 7522, en van reeds bestaande beheerafspraken.

Uitgangspunten rondom beheer MedMij Informatiestandaarden

Algemeen

MedMij Informatiestandaarden maken zoveel mogelijk gebruik van bestaande concepten, zoals zibs (zorginformatiebouwstenen) en FHIR profielen. Daarmee kunnen MedMij informatiestandaarden afhankelijk zijn van wijzigingen in deze onderliggende bronnen. Er is een relatie tussen meerdere beheerprocessen.

Centrale plek systeemrolcode

Om de relatie tussen die beheerprocessen te duiden, moet de positie van systeemrol nader toegelicht worden. Onderstaande figuur geeft een schematische weergave van die positie. De informatiestandaard bestaat uit een of meer transacties met voor elk van de transacties een aanduiding van de bijbehorende systeemrollen. Deze systeemrollen hebben een systeemrolcode. Deze identificeert 1 versie van 1 systeemrol. Een versie van een systeemrol wordt geïdentificeerd door 1 systeemrolcode. Deze metagegevens spelen een centrale rol in de definitie van de gegevensdiensten binnen het MedMij afsprakenstelsel.

MedMij items met versie.png

Als onderliggende bronnen wijzigen, moet ingeschat worden of de systeemrol ook aangepast dient te worden. Uitgangspunt is dat indien een FHIR profiel wijzigt, dit gelijk wordt doorgevoerd voor alle informatiestandaarden die dat FHIR profiel gebruiken. Bijvoorbeeld: Lab profiel wordt ook gebruikt binnen use case BgZ en Huisartsgegevens.

De versie van een MedMij informatiestandaard kan uit meerdere systeemrollen bestaan waarvan de versienummers verschillen. Bijvoorbeeld als alleen ‘sturen zelfmetingen van vitale functies’ is gewijzigd, maar het versienummer van systeemrollen raadplegen en beschikbaarstellen niet verandert. 

Zorginformatiebouwstenen

Zibs beschrijven een bepaald concept op informatie-niveau. Een informatiestandaard (IS) voor overdracht, beschrijft alle relevante informatieonderdelen, zoals afspraken over het zorgproces, de gegevensset (‘overdrachtsgegevens’) en afspraken hoe de technische implementatie (in de ’Applicaties’-laag) plaats moet vinden.

Omdat een IS en een zib verschillende ‘dingen’ zijn, zullen de processen van beheer van de zibs en van IS-en moeten verschillen. Maar omdat een gegevensset uit een IS in het algemeen deels is opgebouwd uit zibs en daar gebruik van maakt, is er een relatie tussen de 2 beheerprocessen. Indien een wijziging aan een onderliggende zib niet noodzakelijk is voor de MedMij use case, hoeft deze wijziging niet te worden meegenomen binnen MedMij afsprakenstelsel. Dan verwijst de MedMij informatiestandaard naar een oudere versie van de zib. De (spel)regels hoe om te gaan met ensembles van zibs en gegevenssets (van Informatiestandaarden) is nog onderhevig aan discussie. Zoals ook in de inleiding verwoord, is dit document bedoeld om een set initiële afspraken voor het beheer van de MedMij informatiestandaarden te beschrijven, die geëvalueerd en indien nodig, bijgesteld gaan worden. Met relevante partijen zullen deze spelregels dan ook worden besproken en eventueel bijgesteld op basis van ervaringen.

Beheersproces

Algemeen

Het proces van beheer van de MedMij informatiestandaarden richt zich op het wijzigen van de (semantische) inhoud van de informatiestandaarden aan veranderende eisen. Het beschrijven, beoordelen en al dan niet doorvoeren van deze wijzigingen zijn onderdelen van dit beheerproces.

Er wordt onderscheid gemaakt in het beheersproces naar MedMij VolwassenheidsNiveau. Voor standaarden met volwassenheidsniveau 6 dient het formele proces gevolgd te worden. Veel informatiestandaarden voor gegevensuitwisseling tussen personen en zorgaanbieders moeten echter nog ontwikkeld worden. Deze standaarden zijn innovatief en kunnen niet direct op een hoog volwassenheidsniveau functioneren. Dergelijke innovatie moet wel mogelijk zijn in MedMij. Voor informatiestandaarden met MedMij Volwassenheidsniveau 5 en lager kan daarom afgeweken worden van jaarlijkse release als uitgangspunt. Daarmee kan snel geacteerd worden op bevindingen tijdens test- en kwalificatietrajecten. Dat kunnen ook bevindingen zijn die niet blokkerend van aard zijn. De definitie van blokkerende bevindingen wordt hieronder beschreven.

Nadere toelichting ten aanzien van MedMij VolwassenheidNiveaus vindt u in het document Coördinatie standaarden.

Blokkerende bevindingen (blocking issues)

De innovatieve MedMij-standaarden zijn nog niet in praktijk beproefd. Het kan dus voorkomen dat in de praktijk issues optreden die blokkerend zijn en die snel hersteld moeten worden. Het streven is om het aantal releases tot een minimum te beperken, en tussentijdse releases te voorkomen. Bij het beoordelen van bevindingen wordt bepaald of deze blokkerend zijn. Daarbij wordt gebruik gemaakt van de onderstaande definitie.

Definitie van een blokkerende bevinding
Een bevinding is ‘blokkerend’ indien zonder het oplossen van deze bevinding:
  1. De specificatie strijdig is met vigerende wet- en regelgeving.
  2. De interoperabiliteit in het geding is, bijvoorbeeld omdat verplichte data-elementen niet correct uitgewisseld kunnen worden.
  3. De patiëntveiligheid bij het gebruik van de informatie in het geding kan komen.

Oplossing van een blokkerende bevinding leidt tot een nieuwe versie van de standaard, waarbij herkwalificatie nodig kan zijn.

Actoren

De basis voor het algemene proces van beheer van standaarden (en dus ook van MedMij informatiestandaarden) is de norm NEN 7522. De norm NEN7522 is op zijn beurt gebaseerd op een aantal ISO-standaarden, waaronder ISO/IEC 2382-4 en ISO/IEC 11179-1. In het proces van beheer kent NEN7522 ‘actoren’. Volgens NEN7522 (paragraaf 2.1 ‘Definities’) is een actor een ‘handelend persoon of instantie’. Dat kan een rechtspersoon zijn.

De te onderscheiden actoren (ook wel ‘rollen genoemd’) volgens NEN7522 zijn:

  • Gebruiker
  • Houder
  • Financier
  • Autorisator
  • Expert
  • Functioneel Beheerder
  • Technisch Beheerder
  • Distributeur

NEN7522 is niet duidelijk of elke actor een rechtspersoon moet zijn. Voor het beheer van de MedMij informatiestandaarden is het voorstel om bij voorkeur de actoren ‘financier’ en ‘houder’ een rechtspersoon te laten zijn.

Beheerproces van MedMij informatiestandaarden

Het wijzigen van de MedMij informatiestandaarden vanaf MedMij VolwassenheidsNiveau 6 doorloopt het onderstaande beheerproces. Het doel van dit proces is het gecontroleerd doorvoeren van wijzigingen. Onderstaande figuur toont het beheerproces waarin de mogelijke statussen en de processtappen van een wijzigingsverzoek zijn opgenomen. Dit proces is een aangepaste versie van het algemene proces van beheer van standaarden, zie het rapport Beheer van standaarden in de zorg’.


Processtatussen weergave 75 procent.png


Intake (in behandeling nemen)

Toelichting van de belangrijkste subprocesstappen:

  • Controleren volledigheid: De Functioneel beheerder registreert en beoordeelt een wijzigingsverzoek van een Indiener. Daarbij beoordeelt de Functioneel beheerder o.a. de volledigheid van het wijzigingsverzoek. Indien nodig vraagt de Functioneel beheerder de indiener om aanvullende informatie te leveren.
  • Inschatten urgentie en classificatie: De Functioneel beheerder bepaalt welke expert(s) betrokken worden bij dit wijzigingsverzoek. De Functioneel beheerder betrekt deze expert(s) als eerste, indien nodig, bij het bepalen van de classificatie ofwel de zogenaamde ‘zwaarte rubriek wijzigingsvoorstel’, zie onderstaande tabel en verder.
Classificatie Beschrijving
Patch Eén of meer verholpen storingen.
Mineur Kleine wijziging(en). Bijvoorbeeld:
  • Toevoegen van een extra gegevenselement in een bestaande informatiebouwsteen
  • Toevoegen van ondersteuning voor buitenlandse postcodes in adressen
Majeur Grote wijziging(en). Bijvoorbeeld:
  • Toevoegen of verwijderen van nieuwe (zorg)informatiebouwstenen (een heel nieuw of grondig gewijzigd blok van informatie).
  • In behandeling nemen: Na het controleren van de volledigheid en de classificatie neemt de Functioneel beheerder het wijzigingsverzoek in behandeling. De Indiener krijgt een terugkoppeling van de Functioneel beheerder.

Analyse

Toelichting bij de belangrijkste subprocesstappen:

  • Analyseren verzoek: De Functioneel beheerder analyseert het wijzigingsverzoek. Eventueel stemt Functioneel beheerder af met de indiener.
  • Bepalen expert(s): De Functioneel beheerder bepaalt welke expert(s) betrokken gaan worden bij dit wijzigingsverzoek, zie verder voor uitleg.
  • Bepalen oplossing(en): De Functioneel beheerder bepaalt, met inbreng van de experts, de oplossing of oplossingsrichtingen bij dit wijzigingsverzoek. Optioneel kan de Functioneel beheerder hierbij tevens afstemmen met relevante partijen, die niet een expert-rol hebben, zoals (EPD-)leveranciers.
  • Check impact oplossing(en): De Functioneel beheerder voert een analyse uit van de impact van het wijzigingsverzoek t.b.v. de verdere besluitvorming. Optioneel kan de Functioneel beheerder hierbij tevens afstemmen met relevante partijen, die niet een expert-rol hebben, zoals (EPD-)leveranciers.

Bepaal voorstel

Toelichting bij de belangrijkste subprocesstappen:

  • Formuleer voorstel verzoek: De Functioneel beheerder formuleert een voorstel, in afstemming met en met inbreng van de expertise van verschillende experts. Het voorstel aan het eind van deze processtap kan zijn:

Voorstel tot realisatie, met uitwerking

Voorstel tot uitstel naar de toekomst

Voorstel tot afwijzing

  • Bereik overeenstemming: De Functioneel beheerder zorg voor overeenstemming met de betrokken experts ten aanzien van het geformuleerde voorstel.

N.B. In deze stap wordt een belangrijke mate van autonomie voor het voorstel toegekend aan de Functioneel beheerder. Er is tegelijkertijd echter ook een zekere borging aanwezig door de (verplichte) afstemming met experts. De Autorisator (zie verder) toetst dit procesmatig: het onvoldoende afstemmen van de functioneel beheerder met experts tijdens de stappen ‘Analyseren/In Analyse’ en ‘Bepaal voorstel’ kan voor de Autorisator reden zijn tot afwijzing van het voorstel.

Realisatie

In deze processtap voert de Technische beheerder, in opdracht van de Functioneel beheerder, het wijzigingsvoorstel door in de MedMij informatiestandaard.

Consultatie

Toelichting bij de belangrijkste subprocesstappen:

  • Bundelen voorstellen: De Functioneel beheerder bundelt een aantal wijzigingsvoorstellen, die logischerwijs bij elkaar horen.
  • Aankondigen open consultatie: De Functioneel beheerder kondigt de open consultatieronde minimaal 15 werkdagen van tevoren aan.
  • Uitvoeren open consultatie: De Functioneel beheerder voert de open consultatieronde uit, volgens de daarvoor afgesproken regels: zie beneden. Deelnemers aan de open consultatie hebben zich van tevoren gemeld. Zie daarvoor bijlage 1 ‘Invulling beheerafspraken’.
  • Verwerken input: De Functioneel beheerder verwerkt de gemaakte opmerkingen tijdens de open consultatieronde. Daarbij zijn er 2 mogelijkheden voor verdere verwerking:
  1. De gemaakte opmerkingen in de open consultatie zijn beperkt.
  2. De gemaakte opmerkingen in de open consultatie zijn substantieel. In dit geval zet de Functioneel beheerder het wijzigingsvoorstel terug naar ‘in intake’ (zie procesflow).


Voor de ‘open consultatie’ ronde zal vooralsnog worden gewerkt met de volgende regels:

  • Geïnteresseerde deelnemers aan de open consultatie kunnen zich aanmelden door een mail te sturen naar de functioneel beheerder (zie bijlage 1).
  • Deelnemers aan de open consultatieronde kunnen beschikken over een account in het tool, (BITS/JIRA), dat gebruikt wordt voor de procesafhandeling van wijzigingsvoorstellen.
  • Elke open consultatieronde wordt 15 werkdagen van tevoren aangekondigd.
  • De Functioneel beheerder kan actief partijen uitnodigen voor een open consultatieronde, indien het onderwerp (wijzigingsvoorstel) daarom vraagt.
  • Tijdens de open consultatieronde kunnen geïnteresseerden binnen de aangegeven termijn (zie verder) 1 van de volgende mogelijkheden kenbaar maken (per wijzigingsvoorstel) :
  1. Eens met het voorstel
  2. Eens met het voorstel, maar relatief kleine aanvulling/wijziging ter overweging mee te nemen in definitief voorstel
  3. Niet eens met voorstel
  • Bij tegenstrijdige uitkomsten uit de open consultatieronde besluit de functioneel beheerder of het wijzigingsvoorstel wordt teruggenomen in de intake stap, of dat het voorstel wordt voorgelegd aan de autorisatieraad.
  • De duur van een open consultatieronde is vooralsnog niet afhankelijk van de zwaarte rubriek (classificatie) van het wijzigingsvoorstel:
Zwaarte rubriek wijzigingsvoorstel Duur consultatieronde
A – geen wijziging n.v.t.
B – Patch 6 weken
C – Mineur  6 weken
D – Majeur 6 weken

Bovenstaande regels kunnen, op basis van praktijkervaringen en input van geïnteresseerden (zoals leveranciers) nog verder worden aangescherpt en gewijzigd, om een werkbare en slagvaardige situatie te krijgen.

Autorisatie

Toelichting bij de belangrijkste subprocesstappen:

  • Klaarzetten autorisatie: De Functioneel beheerder bundelt maximaal 1 keer in de 3 maanden de voorstellen, die uit de proces ‘Klaarzetten consultatie/In consultatie’ zijn gekomen (inclusief de afgewezen voorstellen) en legt deze voor ter besluitvorming aan de Autorisator.
  • Procesmatige beoordeling: De Autorisator doet vooral een procesmatige beoordeling: zijn de procestappen zodanig doorlopen dat relevante partijen betrokken en/of geconsulteerd zijn en zijn de regels (zie beschrijving van de processtappen) gevolgd?
  • Besluitvorming: De Autorisator heeft de volgende besluitmogelijkheden per voorstel:
  1. Voorstel akkoord: dan wordt verder gegaan met (pre-)publicatie stap
  2. Voorstel niet akkoord (gebaseerd op een procesmatig oordeel): voorstel gaat terug naar ‘in intake’ en het proces wordt opnieuw uitgevoerd.

De Gebruiker, die het wijzigingsvoorstel heeft ingediend, krijgt een terugkoppeling van het besluit van de Autorisator.

De besluitvorming door de Autorisator vindt plaats bij meerderheid van stemmen, indien van toepassing.

Pre-publicatie MedMij-standaarden

In het pre-publicatieproces publiceert de Distributeur een nieuwe versie van de MedMij-standaarden. Bij de publicatie wordt een overzicht beschikbaar gesteld waarin de doorgevoerde aanpassingen zijn opgenomen.

Publicatie / Release

In het publicatieproces MedMij-standaarden publiceert de Distributeur een nieuwe volledige verzameling van de MedMij-standaarden. Bij de publicatie wordt een overzicht beschikbaar gesteld waarin de doorgevoerde aanpassingen zijn opgenomen.