Releases

Archief

Voor een overzicht van de afgelopen releases zie Archief.

Releasebeleid

• 1. HDN Standaard Releasebeleid algemeen

• 2. Procedure Major release

• 3. Procedure minor release (organisatiespecifieke berichtschema’s)

• 4. Procedure minor release (generieke berichtschema’s)

• 5. Spoedprocedure

• 6. Procedure wijzigingsverzoeken

• 7. Procedure ondersteuning projecten, PoC’s en pilots (innovaties)

• 8. Versienummering berichtschema’s

• 9. Toelichting berichttypen

HDN hanteert een releasebeleid dat uit meerdere onderwerpen bestaat. Dit releasebeleid is met de werkgroepen overeengekomen en bestaat uit de volgende onderdelen:

1. HDN Standaard Releasebeleid algemeen

Om het risico op productieverstoringen voor alle ketenpartijen zoveel mogelijk te beperken, heeft HDN een releasebeleid vastgesteld. Dit beleid schrijft de manier voor waarop wijzigingen in berichtschema’s worden doorgevoerd en in gebruik worden genomen.

De verschillende soorten berichttypen zijn beschreven in Bijlage 1. In dit hoofdstuk wordt onderscheid gemaakt tussen releasevormen en berichttypen.

1.1 Releasevormen

Major releases:

• Bevatten aanpassingen die niet compatibel zijn met voorgaande berichtschema’s.

• Worden door alle leden en gebruikers gelijktijdig in gebruik genomen.

• De tijdslijnen voor major releases zijn beschreven in hoofdstuk 2.

Major december releases:

• Bevatten noodzakelijke aanpassingen voortgekomen uit de Trhk en NHG-voorwaarden en -normen.

• Bevatten aanpassingen die niet compatibel zijn met voorgaande berichtschema’s.

• Worden door alle leden en gebruikers gelijktijdig in gebruik genomen.

• De tijdslijnen worden vastgesteld in samenspraak met de betreffende werkgroep.

Minor releases:

• Bevatten aanpassingen die wel compatibel zijn met voorgaande berichtschema’s.

• Kunnen door organisaties op een zelf gekozen moment, in overleg met HDN, in gebruik worden genomen.

Spoedreleases:

• Bevatten aanpassingen die bugs (fouten) in berichtschema’s herstellen.

• Worden in overleg met HDN zo snel mogelijk uitgerold op de productieomgeving.

1.2 Berichttypen en berichtschema’s

• Het releasebeleid kan verschillen per berichttype.

• Voor brondataberichttypen gelden specifieke scenario’s, omdat deze schema’s vaak uitsluitend systeem-naar-systeemcommunicatie betreffen, en geen handmatig in te vullen attributen bevatten.

1.3 HDN basis- en organisatiespecifieke berichtschema’s

• Voor zowel basisberichtschema’s als organisatiespecifieke berichtschema’s geldt in de kern hetzelfde releasebeleid.

• Het onderscheid tussen major en minor releases is gebaseerd op de vraag of de wijziging compatibel is met eerdere berichtschema’s.

Het HDN-releasebeleid is als volgt vastgesteld

• Major releases vinden in het weekend plaats, in de nacht van vrijdag op zaterdag (00.30 uur). Deze major releases vinden één keer per jaar plaats. Deze releases worden ruim van tevoren gepland en gecommuniceerd.

• Major december releases vinden op de laatste donderdag voor de kerstvakantie plaats, in de nacht van woensdag op donderdag (00:30 uur).

• Minor releases vinden doordeweeks plaats en kunnen gedurende het jaar op elke donderdag worden uitgerold. De ingangsdatum van een nieuwe minor versie ligt altijd op een donderdag, in de nacht van woensdag op donderdag (00.30 uur).

• Spoedreleases kunnen op elke dag plaatsvinden en worden in de nacht om 00:30 uur uitgerold.

2. Procedure Major release

De jaarlijkse major release vormt het vaste moment waarop HDN een release doorvoert voor alle berichtschema’s. Deze is jaarlijks in Mei.

In het kader van wet- en regelgeving, de toepassing van aangepaste NHG V&N-richtlijnen of andere essentiële wijzigingen kan het echter noodzakelijk zijn om in december een major release uit te voeren. Het besluit tot een dergelijke release wordt genomen in overleg met de betrokken werkgroepen, waarbij tevens de bijbehorende tijdslijnen worden vastgesteld.

Uitzonderingen bronberichtschema’s

Voor bronberichtschema’s kan, indien noodzakelijk, een uitzondering worden gemaakt. Wanneer een dataleverancier een wijziging doorvoert op een ander moment dan het door HDN vastgestelde standaardreleasemoment, wordt in afstemming met de werkgroep Brondata een aangepast releasemoment overeengekomen. Dit geldt met name voor releases met directe impact, bijvoorbeeld:

• wanneer informatie niet langer beschikbaar is;

• wanneer sprake is van een ingrijpende wijziging, zoals de introductie van een nieuw taxatierapport dat essentieel is voor de continuïteit van de gedigitaliseerde processen.

Scopebepaling

• Termijn: ongeveer zes maanden vóór de ingangsdatum van de major release.

• Werkwijze: de inhoud van de release wordt vastgesteld in overleg met leden en gebruikers, op basis van:

  • input uit HDN Meet-ups, werkgroepen en andere bijeenkomsten;

  • ingediende wijzigingsverzoeken;

  • noodzakelijke aanpassingen om het datamodel schoon en beheersbaar te houden.

• Prioritering: onderwerpen worden in samenspraak met de werkgroepen geselecteerd en geprioriteerd.

• Publicatie: specificaties worden zoveel mogelijk uitgewerkt en in concept gepubliceerd via http://HDN.nl.

Consultatieperiode

• Termijn: eerste of tweede week januari voor een periode van circa vijf weken.

• Doel: alle stakeholders kunnen input leveren op de conceptspecificaties.

• Activiteiten: naar behoefte organiseert HDN informatiesessies waarin onderwerpen worden toegelicht.

• Resultaat: de definitieve specificaties worden vastgesteld, eventueel met aanpassingen ten opzichte van de conceptversie, in afstemming met de werkgroep.

Testperiode HDN

• Start: twee weken vóór publicatie van de definitieve specificaties.

• Uitvoering: HDN bouwt de nieuwe basisberichtschema’s en HDN-organisatieberichtschema’s.

• Kwaliteitscontrole: HDN voert regressietests uit en controleert de schema’s op inconsistenties.

Definitieve specificaties & publicatie basis-berichtschema’s

• Termijn: uiterlijk 14 weken vóór de ingangsdatum van de major release.

• Communicatie: alle partijen ontvangen de definitieve specificaties per onderwerp, inclusief aanleiding en ketenafspraken.

• Publicatie: de nieuwe basisberichtschema’s van berichttypen met een organisatiespecifieke variant (o.a. OfferteAanvraag en LevenAanvraag) worden gepubliceerd via de HDN Schemabeheertool.

• Gebruik: aanbieders kunnen hiermee hun organisatiespecifieke berichtschema’s opbouwen.

Publicatie HDN-berichtschema’s

• Termijn: uiterlijk 8 weken vóór de ingangsdatum van de major release.

• Publicatie: HDN publiceert de nieuwe berichtschema’s zonder organisatiespecifieke variant (zoals DocumentAanvraag, StatusMeldingen, InformatieAanvraagBericht) via de HDN Schemabeheertool.

Organisatiespecifiek berichtschema ter review

• Termijn: uiterlijk 8 weken vóór de ingangsdatum van de major release.

• Verplichting: aanbieders leveren hun versie van de berichtschema’s ter review aan bij HDN.

• Review: HDN beoordeeld ieder nieuw berichtschema op technische werking en op naleving van de geldende ketenafspraken.

Publicatie organisatiespecifieke berichtschema’s & distributie naar testomgeving

• Termijn: uiterlijk 6 weken vóór de ingangsdatum van de major release.

• Publicatie: HDN publiceert de organisatiespecifieke berichtschema’s van de aanbieders via de HDN Schemabeheertool.

• Distributie: alle berichtschema’s worden gedistribueerd naar de testomgeving.

Freezeperiode

• Start: 4 weken vóór de ingangsdatum van de nieuwe berichtschema’s.

• Beperking: in deze periode mogen geen nieuwe berichtschema’s meer live gaan.

• Doel: hiermee wordt geborgd dat alle ketenpartijen voldoende tijd hebben om de nieuwe release voor te bereiden, het testen af te ronden en eventuele implementaties stabiel te voltooien.

Ingangsdatum

Op de vastgestelde ingangsdatum gaat de major release live, inclusief de nieuwe basisberichtschema’s en de organisatiespecifieke berichtschema’s.

3. Procedure minor release (organisatiespecifieke berichtschema’s)

Naast de major releases kunnen aanbieders hun organisatiespecifieke berichtschema’s aanpassen, bijvoorbeeld naar aanleiding van de introductie van nieuwe producten en/of de optimalisatie van ketenprocessen. Deze aanpassingen kunnen tussentijds als minor release op het HDN-platform worden doorgevoerd. Hiervoor dient steeds een nieuwe versie van het organisatiespecifieke berichtschema te worden gepubliceerd. Voorafgaand aan publicatie vindt er een review door HDN plaats.

Procedure en tijdslijnen

De procedure voor de publicatie van een minor release van een organisatiespecifiek berichtschema verloopt als volgt:

1. Voorbereiding door de organisatie

   • De organisatie test het berichtschema voorafgaand aan de indiening zelf op inconsistenties en tegenstrijdige regels.

2. Indiening bij HDN

   • Het berichtschema wordt minimaal drie weken vóór de ingangsdatum ter review aangeboden aan HDN.

   • Voor de review geldt dat het schema minimaal één week vóór de geplande publicatiedatum bij HDN moet zijn aangeleverd.

3. Review door HDN

   • HDN beoordeelt ieder nieuw berichtschema op technische werking en op naleving van de geldende ketenafspraken.

4. Publicatie en distributie

   • Het berichtschema wordt op de geplande publicatiedatum gepubliceerd en gelijktijdig beschikbaar gesteld in de testomgeving voor de gehele markt.

   • Belangrijk: het berichtschema kan na publicatie (status goedgekeurd in HDN Schemabeheertool) niet worden teruggezet indien een test faalt. In dat geval dient een nieuw berichtschema te worden opgesteld en opnieuw ter review te worden aangeboden.

5. Ingangsdatum

   • Tussen de publicatiedatum en de ingangsdatum geldt een minimale termijn van twee weken.

   • De ingangsdatum van een minor release is in beginsel altijd een donderdag. Alleen in uitzonderingsgevallen kan hiervan worden afgeweken, mits alle betrokken ketenpartijen hiermee expliciet instemmen en dit minimaal vier weken vooraf is gecommuniceerd.

6. Productieverstoringen

   • Indien een productie verstorende situatie optreedt, wordt de spoedprocedure toegepast (zie hoofdstuk 5).

4. Procedure minor release (generieke berichtschema’s)

Voor de generieke berichtschema’s geldt dat er ook minor releases kunnen plaatsvinden. Deze releases kunnen noodzakelijk zijn naar aanleiding van:

• de toevoeging van een nieuwe organisatiespecifieke waarde in waardelijsten

• uitbreiding van (organisatie)specifieke velden, of

• het corrigeren van fouten (bugs) in bijvoorbeeld regels of veldomschrijvingen.

Dergelijke aanpassingen worden tussentijds als minor release doorgevoerd. Deze releases zijn in beginsel altijd backwards compatible. Het verwijderen van waarden en/of velden wordt in principe niet gedaan, omdat dit ertoe kan leiden dat de release niet langer backwards compatible is.

Procedure en tijdslijnen

1. Indienen wijzigingsverzoek

   • Het wijzigingsverzoek wordt bij HDN ingediend.

     • uitbreiding organisatiespecifieke waardelijst,

     • uitbreiding (organisatie)specifiek veld,

     • uitbreiding optioneel generiek veld,

     • bugfix.

2. Beoordeling door HDN

   • HDN beoordeelt of de wijziging in aanmerking komt voor een minor release.

3. Uitwerking wijziging

   • Uitbreiding van velden: Er wordt een wijzigingsvoorstel opgesteld en besproken met de werkgroep.

   • Correctie van een bug: de werkgroep wordt geïnformeerd.

   • Uitbreiding van een organisatiespecifieke waardelijst: de werkgroep wordt in dit geval niet geïnformeerd of geconsulteerd.

4. Publicatie en distributie

   • Na afronding van bovenstaande stappen wordt het aangepaste berichtschema op donderdag gepubliceerd en beschikbaar gesteld in de testomgeving.

   • Voor uitbreidingen van (organisatie)specifieke velden, optioneel generieke velden of bug fixes worden release notes opgesteld en gepubliceerd.

5. Ingangsdatum

   • Minimaal twee weken na publicatiedatum is de livegang van een berichtschema. Berichtschema’s worden de dinsdag voor livegang automatisch gedistribueerd naar de productieomgeving.

5. Spoedprocedure

In uitzonderlijke situaties kan het voorkomen dat een onjuist berichtschema in de productieomgeving wordt geplaatst. Dit kan zich uiten in onder meer tegenstrijdige condities of het ten onrechte verplicht stellen van een element, waardoor adviseurs geen aanvraag kunnen indienen, of dit slechts met grote moeite kunnen doen. Op zo’n moment wordt kan de spoedprocedure worden ingezet.

Procedure en tijdslijnen

1. Signalering van de fout

   • Een partij binnen de keten constateert dat een onjuist berichtschema in productie is opgenomen, met als gevolg dat een aanbieder geen of slechts beperkt aanvragen kan ontvangen.

   • Deze partij meldt het probleem direct bij HDN.

2. Beoordeling door HDN

   • HDN beoordeelt de melding en stelt vast of sprake is van een productieverstorend berichtschema.

   • Daarbij wordt zorgvuldig afgewogen of het probleem het gevolg is van een reeds langer bestaande onjuiste regel of van een nieuwe regel/verplichting die daadwerkelijk verstorend werkt in de keten.

3. Afstemming productiedatum

   • Indien sprake is van een productieverstorende situatie, stemt HDN in overleg met de betreffende aanbieder een productiedatum af. In de meeste gevallen betreft dit de eerstvolgende werkdag.

4. Opstellen en publiceren nieuw berichtschema

   • De aanbieder stelt een nieuw berichtschema op.

   • HDN voert hierop een review uit en publiceert de aangepaste versie.

5. Communicatie

   • HDN informeert de betrokken partijen per e-mail (rollen 1, 2, 3 en 5) over de spoedrelease.

6. Procedure wijzigingsverzoeken

De HDN Standaard is voortdurend aan wijzigingen onderhevig. Om wijzigingsverzoeken op een eenduidige wijze te behandelen, is onderstaande procedure vastgesteld.

1. Indienen wijzigingsverzoek

• Een wijzigingsverzoek wordt via de servicedesk bij HDN ingediend.

• Daarbij dienen enkele standaardvragen beantwoord te worden.

1.1 Business value
Het verzoek moet een duidelijke functionele waarde onderbouwen aan de hand van de volgende vragen:

• Reden van de wijziging

• Doel van de wijziging

• Beoogde oplossing

Dit resulteert in een aanleiding, situatieschets en (functionele) onderbouwing van de wijziging.

1.2 Mogelijke oplossingen
Het verzoek moet mogelijke oplossingsrichtingen benoemen, inclusief voorkeuren:

• Functioneel: beschrijving van de oplossing voor de gehele keten (van adviseur/consument tot en met aanbieder en vice versa).

• Technisch: beoordeling van uitvoerbaarheid en inschatting van het tijdsbeslag.

• Output: wijze van opvragen van informatie en inschatting van de waarde van de output.

De functionele oplossing wordt afgestemd met de verantwoordelijke werkgroep.

1.3 Impact
Analyse van de impact op de keten, bestaande uit adviespakketten, distributiepartijen, aanbieders, bronnen en HDN. Hierbij wordt de verhouding tussen impact, investering en toegevoegde waarde beoordeeld.

1.4 Besluitopties
Mogelijke uitkomsten zijn:

• wel/niet implementeren,

• direct inzetten,

• uitsterfbeleid.

1.5 Specificaties
Het verzoek dient een beschrijving te bevatten van:

• de procesinrichting en beoogde werking binnen de keten,

• de inrichting in de HDN Standaard (generiek met/zonder verplichting, met/zonder conditionele verplichting, of maatschappij-specifiek),

• verwijzingen naar het betreffende schema.

1.6 Extra check
Elke wijziging dient te worden getoetst op AVG-compliance.

2. Analyse wijzigingsverzoek & vaststelling aanpak

• HDN analyseert de businesswaarde en technische impact en stelt een eerste oplossingsvoorstel op, inclusief een voorstel voor de releaseprioriteit.

• Elk wijzigingsverzoek wordt, inclusief oplossingsvoorstel, voorgelegd aan de betreffende werkgroep.

• Indien meer tijd nodig is voor analyse, kan een gefaseerd oplossingsvoorstel worden opgesteld.

Werkwijze:

• Standaard worden wijzigingsverzoeken op de backlog opgenomen en één keer per jaar geprioriteerd door de betreffende werkgroep. Afhankelijk van het voorstel kan het voorkomen dat een wijziging eerder wordt besproken.

• Verzoeken met korte doorlooptijd worden via Confluence en per e-mail aan de werkgroep voorgelegd. Hiervoor geldt een reactietermijn die afhankelijk van het voorstel wordt meegestuurd.; geen reactie betekent akkoord. Indien meer tijd nodig is, dient dit gemotiveerd te worden met inhoudelijke redenen.

• Verzoeken die onder embargo moeten worden behandeld, worden door HDN afzonderlijk beoordeeld. Hierbij geldt dat een voorziening op termijn generiek kan worden ingericht.

De definitieve aanpak en planning worden vastgesteld in overleg met de werkgroep.

3. Implementatie & uitrol

• De wijziging wordt geïmplementeerd conform de overeengekomen aanpak.

• De uitrol vindt plaats volgens de vastgestelde planning en wordt geborgd binnen de keten.

7. Procedure ondersteuning projecten, PoC’s en pilots (innovaties)

HDN hanteert een beleid voor de ondersteuning van projecten, Proof of Concepts (PoC’s) en pilots (innovaties), in verhouding tot het reguliere beheer van berichtschema’s binnen de HDN Standaard. Dit beleid is opgesteld om zo flexibel mogelijk innovaties te kunnen ondersteunen, terwijl tegelijkertijd de uniformiteit en consistentie van de HDN Standaard wordt gewaarborgd.

1. Uitgangspunten

Bij de inrichting van innovaties gelden de volgende uitgangspunten:

• Elke wijziging wordt, ongeacht de gekozen methodiek, zoveel mogelijk conform de HDN Standaardprincipes ingericht.

• Bij tijdelijke inrichtingen waarin één partij een veld wil gebruiken, faciliteert HDN dit. Bij deze inrichting wordt de betrokken werkgroep altijd geconsulteerd.

• Bij organisatiespecifieke of generieke inrichtingen wordt de werkgroep geconsulteerd. Waar mogelijk wordt gekozen voor een zo generiek mogelijke inrichting.

• Een volledig generieke inrichting wordt gekozen wanneer een initiatief de pilot- of projectfase voorbij is en marktbreed wordt uitgerold. Per initiatief wordt bepaald wanneer dit het geval is.

2. Drie inrichtingsmethodieken

Afhankelijk van het type innovatie, de verwachte duurzaamheid van het initiatief en de benodigde aanpassingen, onderscheidt HDN drie methodieken:

2.1 Tijdelijke inrichting

• Gebruik van vrije tekstvelden en/of organisatiespecifieke attributen.

• Wijziging wordt begeleid door het project, in overleg met deelnemende partijen en een vertegenwoordiger van HDN Standaard.

• Eventueel uit te breiden met organisatiespecifieke regels.

2.2 Organisatiespecifieke inrichting

• Structurele inrichting met een organisatiespecifieke entiteit of veld.

• Wijziging wordt begeleid door HDN Standaard, in overleg met de werkgroep.

• Er gelden generieke (keten)afspraken over de inrichting.

• Eventueel uit te breiden met organisatiespecifieke regels.

2.3 Generieke inrichting

• Structurele inrichting met een generieke entiteit, veld, waardenlijst en/of boolean.

• Wijziging wordt begeleid door HDN Standaard, in overleg met de werkgroep.

• Er gelden generieke (keten)afspraken over de inrichting.

• Uitsluiting van generieke elementen door aanbieders kan via organisatiespecifieke condities, zoals:

  • een entiteit met voorkomens = 0,

  • een boolean die alleen waar of onwaar mag zijn,

  • een waardelijst die alleen specifieke waarden gebruikt.

3. Werkafspraken

Voor de inrichting binnen de HDN Standaard gelden de volgende werkafspraken:

1. Wanneer één partij een veld wil gebruiken, is dit voldoende reden om het veld in het Basisberichtschema te behouden.

   • Bij nieuwe velden moet altijd een motivatie worden aangeleverd.

   • De werkgroep wordt hierover geïnformeerd.

2. Nieuwe velden in Basisberichtschema’s worden altijd ter kennisgeving aan de werkgroep medegedeeld.

3. Wanneer in projecten keuzes worden gemaakt die de structuur van Basisberichtschema’s op termijn kunnen beïnvloeden, kan de werkgroep worden geconsulteerd.

4. Bij een structurele inrichting wordt de werkgroep altijd geconsulteerd.

8. Versienummering berichtschema’s

Elk berichtschema heeft een versienummer. Dit nummer maakt inzichtelijk op welk Basisberichtschema het betreffende berichtschema is gebaseerd. De versienummering is voor zowel generieke als organisatiespecifieke berichtschema’s op dezelfde wijze opgebouwd en bestaat uit vier posities:

Jaar.Major.Minor.Organisatie

De procedure voor het moment waarop releases worden uitgerold, is beschreven in het hoofdstuk HDN Releasebeleid Algemeen.

Opbouw van het versienummer

1. Jaar

   • Komt overeen met de laatst uitgegeven jaarlijkse release.

2. Major

   • Wordt verhoogd wanneer gedurende het jaar een major release wordt uitgegeven.

   • Bij verhoging van Jaar wordt dit getal weer op 0 gezet.

3. Minor

   • Wordt verhoogd wanneer gedurende een major release een minor release plaatsvindt.

   • Bij verhoging van Major of Jaar wordt dit getal weer op 0 gezet.

4. Organisatie

   • Dit getal wordt gebruikt voor (organisatie)specifieke berichtschema’s (zoals OfferteAanvraag, of LevenAanvraag), maar ook voor generieke HDN schema’s (zoals DocumentAanvraag of StatusMelding)

   • Start altijd bij 1 en wordt per berichtschema oplopend bijgehouden binnen een major release.

   • Voor Basis-berichtschema’s is dit getal altijd 0.

   • Voorbeeld:

     • 23.2.0.1 → eerste (organisatie)specifieke versie binnen major release 23.2.

     • 23.2.x.2, 23.2.x.3 → volgende versies binnen dezelfde major release, onafhankelijk van de minor releases.

Toepassing en afspraken

• Uitbreidingen van de Basisberichtschema’s die verplicht door de keten moeten worden overgenomen, worden altijd zichtbaar gemaakt door het verhogen van het Jaar of de Major.

• Of een wijziging als major release of major december release wordt doorgevoerd, wordt bepaald in samenspraak met de betreffende HDN Standaard werkgroepen.

• Ketenafspraak: attributen die verwijderd moeten worden, worden uitsluitend verwijderd bij een major release, tenzij een uitzondering noodzakelijk is.

• Verwijdering van elementen vindt altijd in overleg plaats met de betreffende werkgroepen.

9. Toelichting berichttypen

Binnen de HDN Standaard worden verschillende soorten berichttypen onderscheiden. Ter verduidelijking zijn deze hieronder beschreven.

1. Basisberichtschema

Het basisberichtschema vormt de meest uitgebreide variant van een berichtschema binnen zijn categorie. Dit schema bevat alle beschikbare elementen waaruit een organisatie kan putten bij het opstellen van een eigen organisatiespecifiek berichtschema.

2. Organisatiespecifieke berichtschema

Een organisatiespecifieke berichtschema is altijd gebaseerd op het basisberichtschema. Het wordt ingericht naar de specifieke behoeften van de organisatie die het gebruikt, bijvoorbeeld om eigen productvoorwaarden of procesafspraken te ondersteunen.

3. Organisatiespecifieke berichtschema HDN

Ook HDN zelf wordt beschouwd als een organisatie en beschikt derhalve over een eigen organisatiespecifieke berichtschema. Indien er voor een bepaald berichttype geen organisatiespecifiek berichtschema van een andere organisatie beschikbaar is, wordt altijd teruggevallen op het HDN-berichtschema.