HDN Standaard documentatie

Taxonomie

In de taxonomie is de gemeenschappelijke HDN-taal vastgelegd. Deze taal wordt gedeeld over alle HDN-berichtsoorten. In de taxonomie leggen we naast de begrippen en de beschrijving hiervan ook vast of het persoonsgegevens zijn, welke bovenliggende entiteiten erbij horen en, in het geval van waardelijsten, alle mogelijke opties en hun beschrijvingen. De gegevens zijn geversioneerd. Alle begrippen worden gedeeld over alle berichten van de HDN Standaard.

De overige onderdelen kunnen pas nieuwe begrippen introduceren als deze in de taxonomie zijn vastgelegd

Berichtschema’s

Via HDN verstuurde berichten moeten voldoen aan de opgestelde berichtschema’s. Dit worden ook wel HDN-berichtschema’s genoemd. Deze zijn in XSD’s vastgelegd.

Binnen de HDN Standaard zijn er per berichtsoort (bv. offerteaanvraag (AX) , LevenAanvraag (LX) ) meerdere typen schema’s beschikbaar:

• Er is een Basisschema waarin alle velden en entiteiten die in de taxonomie voor het berichtsoort beschikbaar zijn, zijn opgenomen. Een basisschema dient als ‘kapstok’ voor de andere typen schema’s. Het basisschema zelf kan daarom niet gebruikt worden voor het versturen van berichten.

• Er is een berichtschema van organisatie HDN waarin de minimumset van velden en entiteiten zijn opgenomen, die in elk berichtschema moeten zijn opgenomen. Op basis van dit berichtschema kunnen berichten verstuurd worden.

• Er zijn organisatiespecifieke berichtschema’s (niet bij elk berichtsoort). Een aanbieder kan een eigen berichtschema samenstellen waarin velden en entiteiten staan die de aanbieder wenst te ontvangen. Dit berichtschema bevat altijd de set aan velden van het organisatie HDN berichtschema, aangevuld met andere velden uit het Basisschema. Het is ook mogelijk in dit berichtschema verplichtingen op velden toe te voegen. Op basis van deze berichtschema’s kunnen berichten verstuurd worden.

Controleregels

Naast berichtschema’s die in XSD’s zijn vastgelegd is er de mogelijkheid extra regels toe te voegen waarin conditionele verplichtingen zijn vastgelegd. Deze regels worden in HDN-specifieke controle XML vastgelegd. In een regel kan worden afgedwongen dat een veld verplicht is indien een ander veld gevuld is met een bepaalde waarde.

De controleregels zijn van toepassing op alle typen berichtschema’s:

• Voor controleregels in basisschema’s geldt dat deze de basisset zijn en ook automatisch in de andere berichtschema’s overgenomen zijn.

• Het berichtschema van organisatie HDN bevat alleen de controleregels van de velden die uit de basisset zijn overgenomen. Er zijn geen nieuwe controleregels toegevoegd.

• De organisatiespecifieke berichtschema’s bevatten altijd de controleregels uit de basisschema’s voor de velden die zijn overgenomen. Daarnaast kunnen er extra regels worden toegevoegd door een organisatie.

Ketenafspraken

Een ketenafspraak is een vastlegging van het gebruik van de HDN Standaard die niet middels berichtschema’s en controleregels kan worden afgedwongen. Ketenafspraken bevatten vaak instructies hoe om te gaan met een combinatie van berichten (bijvoorbeeld statusmeldingen) of hoe bepaalde regelingen moeten worden aangevraagd. Ook biedt het instructies hoe aanbieders hun organisatiespecifieke berichtschema’s moeten inrichten.

Processen

Om de implementatie van de HDN Standaard overzichtelijker te maken, zijn er voor de domeinen die de HDN Standaard ondersteunt procesbeschrijvingen gemaakt.

Certificering

Middels certificering controleert HDN of de HDN Standaard goed wordt nageleefd. Er zijn twee typen certificering:

• Certificeringsvorm A: Deze vorm is bedoeld voor nieuwe partijen die voor het eerst aansluiten op HDN, of partijen die met een nieuw pakket gebruik gaan maken van HDN en partijen die hun software grootschalig hebben aangepast. Bij deze certificering wordt het berichtenverkeer tussen de partij en HDN gesimuleerd, waarbij HDN controles uitvoert op zowel de technische als de functionele werking.

• Certificeringsvorm B is de certificering op basis van data. Deze wordt voor bestaande gebruikers uitgevoerd in het kader van de jaarlijkse certificering. Voor nieuwe gebruikers wordt deze drie maanden na de livegang uitgevoerd als sluitstuk van de definitieve certificering (bij livegang wordt een tijdelijke certificering op basis van Certificeringsvorm A afgegeven).