Handleiding Wiki documentatie - Bewerkingsoverzicht

Harriet Luttikhuizen: Een tijdelijke issue box toegevoegd, zoals besloten in het IA overleg van 6 juli 2021

2021-07-15T10:03:14Z

Een tijdelijke issue box toegevoegd, zoals besloten in het IA overleg van 6 juli 2021

← Oudere versie		Versie van 15 jul 2021 10:03
Regel 1:		Regel 1:
			{{IssueBox\|De documentatie rondom het functioneel ontwerp wordt op dit moment herzien. Hierdoor is deze handleiding verouderd. De meest recente versie van het functioneel ontwerp is te vinden in het document: Handleiding Functioneel Ontwerp Informatiestandaard Versie 1.0. Dit document is te vinden op de SharePoint van de IA's in de map Best practice & how to documentatie. }}

	Daar waar het specificeren plaatsvindt in ART-DECOR, wordt Wiki gebruikt om een functionele beschrijving te geven van de informatiestandaarden. Op de Wiki pagina wordt, naast het functioneel ontwerp van de informatiestandaard, ook de verbinding gelegd naar o.a. de bijbehorende richtlijnen en zorgstandaarden. Vanuit de Wiki pagina is het mogelijk om door te klikken naar de bijbehorende specificaties in ART-DECOR.		Daar waar het specificeren plaatsvindt in ART-DECOR, wordt Wiki gebruikt om een functionele beschrijving te geven van de informatiestandaarden. Op de Wiki pagina wordt, naast het functioneel ontwerp van de informatiestandaard, ook de verbinding gelegd naar o.a. de bijbehorende richtlijnen en zorgstandaarden. Vanuit de Wiki pagina is het mogelijk om door te klikken naar de bijbehorende specificaties in ART-DECOR.

Camiel Reijnders: Link naar Visio diagrammen template aangepast naar bron op SharePoint (SPOF)

2019-11-20T10:42:46Z

Link naar Visio diagrammen template aangepast naar bron op SharePoint (SPOF)

← Oudere versie		Versie van 20 nov 2019 10:42
Regel 7:		Regel 7:
	* Use Case Diagram: Meer shapes > Software en database > Software > UML-use-case-diagram		* Use Case Diagram: Meer shapes > Software en database > Software > UML-use-case-diagram
	* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram		* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram
	Deze diagrammen zijn als [https://~~informatiestandaarden~~.~~nictiz~~.nl/~~images~~/c/cb/~~Functioneel_Ontwerp_~~-~~_Diagram_Visio_Template~~.~~zip~~ Visio voorbeeld/template] uitgewerkt.		Deze diagrammen zijn als [https://nictiznl.sharepoint.com/sites/Informatie-analisten/Gedeelde%20%20documenten/General/Templates/Functioneel%20Ontwerp%20-%20Diagram%20Template.vstx Visio voorbeeld/template] uitgewerkt.
	Vervolgens maak je op deze manier de [https://nictiznl.sharepoint.com/sites/Informatie-analisten/_layouts/15/Doc.aspx?OR=teams&action=edit&sourcedoc={F60864C0-61FB-4131-9CE2-4700F05C9775} afmetingen] van je Visio diagram zo efficiënt mogelijk.		Vervolgens maak je op deze manier de [https://nictiznl.sharepoint.com/sites/Informatie-analisten/_layouts/15/Doc.aspx?OR=teams&action=edit&sourcedoc={F60864C0-61FB-4131-9CE2-4700F05C9775} afmetingen] van je Visio diagram zo efficiënt mogelijk.

Camiel Reijnders: Toevoeging link naar Sharepoint hoe je van Visio diagram het meest ideale plaatje maakt.

2019-11-20T10:38:53Z

Toevoeging link naar Sharepoint hoe je van Visio diagram het meest ideale plaatje maakt.

← Oudere versie		Versie van 20 nov 2019 10:38
Regel 8:		Regel 8:
	* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram		* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram
	Deze diagrammen zijn als [https://informatiestandaarden.nictiz.nl/images/c/cb/Functioneel_Ontwerp_-_Diagram_Visio_Template.zip Visio voorbeeld/template] uitgewerkt.		Deze diagrammen zijn als [https://informatiestandaarden.nictiz.nl/images/c/cb/Functioneel_Ontwerp_-_Diagram_Visio_Template.zip Visio voorbeeld/template] uitgewerkt.
			Vervolgens maak je op deze manier de [https://nictiznl.sharepoint.com/sites/Informatie-analisten/_layouts/15/Doc.aspx?OR=teams&action=edit&sourcedoc={F60864C0-61FB-4131-9CE2-4700F05C9775} afmetingen] van je Visio diagram zo efficiënt mogelijk.

	=Opbouw Wiki pagina’s=		=Opbouw Wiki pagina’s=

Aisha Sie op 7 mei 2019 om 09:49

2019-05-07T09:49:12Z

← Oudere versie		Versie van 7 mei 2019 09:49
Regel 7:		Regel 7:
	* Use Case Diagram: Meer shapes > Software en database > Software > UML-use-case-diagram		* Use Case Diagram: Meer shapes > Software en database > Software > UML-use-case-diagram
	* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram		* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram
	Deze diagrammen zijn als [https://informatiestandaarden.nictiz.nl/images/d/da/Functioneel_Ontwerp_-~~_Diagram_Template_%28Visio%29~~.zip Visio voorbeeld/template] uitgewerkt.		Deze diagrammen zijn als [https://informatiestandaarden.nictiz.nl/images/c/cb/Functioneel_Ontwerp_-_Diagram_Visio_Template.zip Visio voorbeeld/template] uitgewerkt.

Aisha Sie op 23 apr 2019 om 12:11

2019-04-23T12:11:48Z

← Oudere versie		Versie van 23 apr 2019 12:11
Regel 1:		Regel 1:
	Daar waar het specificeren plaatsvindt in ART-DECOR, wordt Wiki gebruikt om een functionele beschrijving te geven van de informatiestandaarden. Op de Wiki pagina wordt, naast het functioneel ontwerp van de informatiestandaard, ook de verbinding gelegd naar o.a. de bijbehorende richtlijnen en zorgstandaarden. Vanuit de Wiki pagina is het mogelijk om door te klikken naar de bijbehorende specificaties in ART-DECOR.		Daar waar het specificeren plaatsvindt in ART-DECOR, wordt Wiki gebruikt om een functionele beschrijving te geven van de informatiestandaarden. Op de Wiki pagina wordt, naast het functioneel ontwerp van de informatiestandaard, ook de verbinding gelegd naar o.a. de bijbehorende richtlijnen en zorgstandaarden. Vanuit de Wiki pagina is het mogelijk om door te klikken naar de bijbehorende specificaties in ART-DECOR.

			=UML diagrammen=

			Voor de UML diagrammen gebruiken we standaard Visio: er zijn standaard Visio shapes beschikbaar, te vinden onder "Meer shapes". Deze shapes kan je aanvinken om te gebruiken. De volgende UML diagrammen worden gebruikt in onze functioneel ontwerpen:
			* Activity Diagram: Meer shapes > Stroomdiagram > Shapes voor basisstroomdiagrammen (begin/einde en proces blokken) + Shapes voor functiestroomdiagrammen (swimlanes)
			* Use Case Diagram: Meer shapes > Software en database > Software > UML-use-case-diagram
			* Component Diagram: Meer shapes > Software en database > Software > UML-onderdeeldiagram
			Deze diagrammen zijn als [https://informatiestandaarden.nictiz.nl/images/d/da/Functioneel_Ontwerp_-_Diagram_Template_%28Visio%29.zip Visio voorbeeld/template] uitgewerkt.


	=Opbouw Wiki pagina’s=		=Opbouw Wiki pagina’s=
Regel 44:		Regel 53:
	==Inleiding->Doelgroep==		==Inleiding->Doelgroep==

	Een opsomming van de doelgroepen waarvoor de Wiki pagina is opgesteld, veelal zijn dit de volgende personen en organisaties: ~~productmanagers~~, architecten, ontwerpers en testers van XIS-leveranciers, regio-organisaties ~~en vertegenwoordigers~~ van zorgverleners. Indien sprake is van een doelgroep per use case, wordt deze hier aangegeven.		Een opsomming van de doelgroepen waarvoor de Wiki pagina is opgesteld, veelal zijn dit de volgende personen en organisaties:
			* Productmanagers, architecten, ontwerpers en testers van XIS-leveranciers, regio-organisaties;
			* Vertegenwoordigers van zorgverleners.
			Indien sprake is van een doelgroep per use case, wordt deze hier aangegeven.

	==Inleiding->Kaders & Uitgangspunten==		==Inleiding->Kaders & Uitgangspunten==
Regel 62:		Regel 74:

	==Use cases==		==Use cases==
	Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR.		Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR. Wanneer verschillende use cases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces.

	==Use cases->Use case X==		==Use cases->Use case X==
Regel 72:		Regel 84:

	==Use cases->Use case X->Bedrijfsrollen==		==Use cases->Use case X->Bedrijfsrollen==
	Een opsomming van de bedrijfsrollen die bij het proces van deze use case betrokken zijn. Bedrijfsrol is een type “actor” en betreft de functionele rollen die bij het proces betrokken zijn. In dit hoofdstuk worden dan ook geen systeemrollen vermeld, maar de rol die een persoon en/of organisatie(delen) vervuld zoals bijv. een voorschrijver en/of een meldkamer. Op basis van een UML Activity diagram wordt in dit hoofdstuk een overzicht geboden van alle activiteiten die in het proces worden uitgevoerd, opgesplitst naar de verschillende bedrijfsrollen.		Een opsomming van de bedrijfsrollen die bij het proces van deze use case betrokken zijn. Bedrijfsrol is een type “actor” en betreft de functionele rollen die bij het proces betrokken zijn. In dit hoofdstuk worden dan ook geen systeemrollen vermeld, maar de rol die een persoon en/of organisatie(delen) vervuld zoals bijv. een voorschrijver en/of een meldkamer. Op basis van een [[#UML diagrammen\|UML Activity diagram]] wordt in dit hoofdstuk een overzicht geboden van alle activiteiten die in het proces worden uitgevoerd, opgesplitst naar de verschillende bedrijfsrollen.

	==Use cases->Use case X->Systemen & Systeemrollen==		==Use cases->Use case X->Systemen & Systeemrollen==
Regel 84:		Regel 96:
	*Beschikbaarstellend Systeem.		*Beschikbaarstellend Systeem.

	De ~~samenhang tussen~~ deze systeemrollen is:		De generieke transacties waarmee deze systeemrollen gegevens uitwisselen zijn:
	*Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;		*Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;
	*Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;		*Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;
Regel 90:		Regel 102:
	*Beschikbaarstellend Systeem stuurt de gevraagde gegevens naar een Raadplegend Systeem.		*Beschikbaarstellend Systeem stuurt de gevraagde gegevens naar een Raadplegend Systeem.

	De naamgeving van systeemrollen is informatiestandaard overstijgend afgestemd, waarbij is afgesproken dat iedere systeemrol een unieke code [*-] heeft. Deze code is opgebouwd uit twee sub-codes, waarbij de voor het verbindingsstreepje staan voor de eerste/logische letters van de informatiestandaard. Voor de informatiestandaard ''Acute Zorg Proces'' is dit bijv. AZP. De * na het verbindingsstreepje staan voor de eerste/logische letters van het type overdrachtsbericht. Dit zijn drie letters, waarbij de eerste twee letters de eerste/logische letters van de transactienaam zijn (bijv. ''SP'' voor ''Spoedbericht'') en de laatste letter staat voor de generieke systeemrol (bijv. ''S'' voor ''Sturend Systeem''). Zo ontstaat bijvoorbeeld ''AZP-SPS'': <u>A</u>cute <u>Z</u>org <u>P</u>roces – <u>Sp</u>oedbericht <u>S</u>turend Systeem.		De naamgeving van systeemrollen is informatiestandaard overstijgend afgestemd, waarbij is afgesproken dat iedere systeemrol een unieke code [*-] heeft. Deze code is opgebouwd uit twee sub-codes, waarbij de voor het verbindingsstreepje staan voor de eerste/logische letters van de informatiestandaard. Voor de informatiestandaard ''Acute Zorg Proces'' is dit bijv. AZP. De * na het verbindingsstreepje staan voor de eerste/logische letters van het type overdrachtsbericht. Dit zijn drie letters, waarbij de eerste twee letters de eerste/logische letters van de transactienaam zijn (bijv. ''SP'' voor ''Spoedbericht'') en de laatste letter staat voor de generieke systeemrol (bijv. ''S'' voor ''Sturend Systeem''). Tot slot wordt toegevoegd of technische specificaties zijn uitgewerkt in CDA of FHIR door deze aan de systeemrol naam toe te voegen (respectievelijk -CDA of -FHIR). Zo ontstaat bijvoorbeeld ''AZP-SPS-CDA'': <u>A</u>cute <u>Z</u>org <u>P</u>roces – <u>Sp</u>oedbericht <u>S</u>turend Systeem in CDA.

	Per systeem wordt in dit hoofdstuk één UML Component diagram opgenomen, waarin de verschillende systeemrollen worden getoond zodat voor een leverancier van een systeem inzichtelijk is welke systeemrollen zijn/haar systeem bevat in het kader van de desbetreffende use case. Er wordt gekwalificeerd op basis van systeem.		Per systeem wordt in dit hoofdstuk één [[#UML diagrammen\|UML Component diagram]] opgenomen, waarin de verschillende systeemrollen worden getoond zodat voor een leverancier van een systeem inzichtelijk is welke systeemrollen zijn/haar systeem bevat in het kader van de desbetreffende use case. Er wordt gekwalificeerd op basis van systeem.

	In ART-DECOR worden de systeemrollen in detail beschreven; dit blijft in dit hoofdstuk achterwegen, er vindt slechts een verwijzing plaats naar ART-DECOR.		In ART-DECOR worden de systeemrollen in detail beschreven; dit blijft in dit hoofdstuk achterwegen, er vindt slechts een verwijzing plaats naar ART-DECOR. Systeemrollen worden in ART-DECOR als actor opgenomen bij de transacties.

	==Use cases->Use case X->Transacties & Transactiegroepen==		==Use cases->Use case X->Transacties & Transactiegroepen==
Regel 108:		Regel 120:
	*Raadplegen en Beschikbaarstellen -> PULL.		*Raadplegen en Beschikbaarstellen -> PULL.
	Zo ontstaat bijvoorbeeld ''Spoedbericht PUSH''.		Zo ontstaat bijvoorbeeld ''Spoedbericht PUSH''.
	Het betreft de situaties waarbij een indicator eenduidig is bepaald voor het type transactie. In de situaties waarbij geen keuze is gemaakt voor een indicator voor het type transactie (zoals bijv. sommige CDA standaarden die alleen de inhoud en syntax beschrijven maar geen uitspraak doen over het type transactie) bevat de naam van een transactie geen PUSH- of PULL- deel.

	De transacties die tussen de systeemrollen plaatsvinden, incl. bijbehorende berichtspecificaties staan niet in dit functioneel ontwerp (en dus niet op de Wiki pagina) uitgewerkt, er vindt slechts een verwijzing plaats naar ART-DECOR.		De transacties die tussen de systeemrollen plaatsvinden, incl. bijbehorende berichtspecificaties staan niet in dit functioneel ontwerp (en dus niet op de Wiki pagina) uitgewerkt, er vindt slechts een verwijzing plaats naar ART-DECOR.

	ART-DECOR beschrijft bij de scenario’s uit welke gegevenselementen een transactie bestaat en wat de ~~cardinaliteit~~ van deze elementen is. Voor de daadwerkelijke uitwisseling wordt gebruik gemaakt van de HL7-specifieke realisatie van deze “logische” berichten in de vorm van templates.		ART-DECOR beschrijft bij de scenario’s uit welke gegevenselementen een transactie bestaat en wat de kardinaliteit van deze elementen is. Voor de daadwerkelijke uitwisseling wordt gebruik gemaakt van de HL7-specifieke realisatie van deze “logische” berichten in de vorm van templates (CDA: beschikbaar op ART-DECOR) of profielen (FHIR: beschikbaar op Simplifier, waarvoor een apart FHIR Implementation Guide wordt opgesteld als technisch ontwerp).

	Dit hoofdstuk toont een UML Use Case diagram waarin de verschillende bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroepen, zoals eerder op de Wiki pagina beschreven, aan elkaar gelinkt worden. Op deze manier wordt inzichtelijk hoe de functionele specificaties (bedrijfsrollen, activiteiten) uiteindelijk mappen op de technische specificaties (systeemrollen, transacties, transactiegroepen) in ART-DECOR.		Dit hoofdstuk toont een [[#UML diagrammen\|UML Use Case diagram]] waarin de verschillende bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroepen, zoals eerder op de Wiki pagina beschreven, aan elkaar gelinkt worden. Op deze manier wordt inzichtelijk hoe de functionele specificaties (bedrijfsrollen, activiteiten) uiteindelijk mappen op de technische specificaties (systeemrollen, transacties, transactiegroepen) in ART-DECOR.

	==Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)==		==Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)==

Tessa van Stijn: Verduidelijking mbt het gebruik van PUSH / PULL in de naam van een transactie

2017-02-21T17:01:31Z

Verduidelijking mbt het gebruik van PUSH / PULL in de naam van een transactie

← Oudere versie		Versie van 21 feb 2017 17:01
Regel 108:		Regel 108:
	*Raadplegen en Beschikbaarstellen -> PULL.		*Raadplegen en Beschikbaarstellen -> PULL.
	Zo ontstaat bijvoorbeeld ''Spoedbericht PUSH''.		Zo ontstaat bijvoorbeeld ''Spoedbericht PUSH''.
			Het betreft de situaties waarbij een indicator eenduidig is bepaald voor het type transactie. In de situaties waarbij geen keuze is gemaakt voor een indicator voor het type transactie (zoals bijv. sommige CDA standaarden die alleen de inhoud en syntax beschrijven maar geen uitspraak doen over het type transactie) bevat de naam van een transactie geen PUSH- of PULL- deel.

	De transacties die tussen de systeemrollen plaatsvinden, incl. bijbehorende berichtspecificaties staan niet in dit functioneel ontwerp (en dus niet op de Wiki pagina) uitgewerkt, er vindt slechts een verwijzing plaats naar ART-DECOR.		De transacties die tussen de systeemrollen plaatsvinden, incl. bijbehorende berichtspecificaties staan niet in dit functioneel ontwerp (en dus niet op de Wiki pagina) uitgewerkt, er vindt slechts een verwijzing plaats naar ART-DECOR.

Wetering op 14 feb 2017 om 11:25

2017-02-14T11:25:22Z

← Oudere versie		Versie van 14 feb 2017 11:25
Regel 90:		Regel 90:
	*Beschikbaarstellend Systeem stuurt de gevraagde gegevens naar een Raadplegend Systeem.		*Beschikbaarstellend Systeem stuurt de gevraagde gegevens naar een Raadplegend Systeem.

	De naamgeving van systeemrollen is informatiestandaard overstijgend afgestemd, waarbij is afgesproken dat iedere systeemrol een unieke code [*-] heeft. Deze code is opgebouwd uit twee sub-codes, waarbij de voor het verbindingsstreepje staan voor de eerste/logische letters van de informatiestandaard. Voor de informatiestandaard ''Acute Zorg Proces'' is dit bijv. AZP. De * na het verbindingsstreepje staan voor de eerste/logische letters van het type overdrachtsbericht. Dit zijn drie letters, waarbij de eerste twee letters de eerste/logische letters van de ~~rolnaam~~ zijn (bijv. ''SP'' voor ''Spoedbericht'') en de laatste letter staat voor de generieke systeemrol (bijv. ''S'' voor ''Sturend Systeem''). Zo ontstaat bijvoorbeeld ''AZP-SPS'': <u>A</u>cute <u>Z</u>org <u>P</u>roces – <u>Sp</u>oedbericht <u>S</u>turend Systeem.		De naamgeving van systeemrollen is informatiestandaard overstijgend afgestemd, waarbij is afgesproken dat iedere systeemrol een unieke code [*-] heeft. Deze code is opgebouwd uit twee sub-codes, waarbij de voor het verbindingsstreepje staan voor de eerste/logische letters van de informatiestandaard. Voor de informatiestandaard ''Acute Zorg Proces'' is dit bijv. AZP. De * na het verbindingsstreepje staan voor de eerste/logische letters van het type overdrachtsbericht. Dit zijn drie letters, waarbij de eerste twee letters de eerste/logische letters van de transactienaam zijn (bijv. ''SP'' voor ''Spoedbericht'') en de laatste letter staat voor de generieke systeemrol (bijv. ''S'' voor ''Sturend Systeem''). Zo ontstaat bijvoorbeeld ''AZP-SPS'': <u>A</u>cute <u>Z</u>org <u>P</u>roces – <u>Sp</u>oedbericht <u>S</u>turend Systeem.

	Per systeem wordt in dit hoofdstuk één UML Component diagram opgenomen, waarin de verschillende systeemrollen worden getoond zodat voor een leverancier van een systeem inzichtelijk is welke systeemrollen zijn/haar systeem bevat in het kader van de desbetreffende use case. Er wordt gekwalificeerd op basis van systeem.		Per systeem wordt in dit hoofdstuk één UML Component diagram opgenomen, waarin de verschillende systeemrollen worden getoond zodat voor een leverancier van een systeem inzichtelijk is welke systeemrollen zijn/haar systeem bevat in het kader van de desbetreffende use case. Er wordt gekwalificeerd op basis van systeem.

Wetering op 14 feb 2017 om 11:05

2017-02-14T11:05:54Z

← Oudere versie		Versie van 14 feb 2017 11:05
Regel 84:		Regel 84:
	*Beschikbaarstellend Systeem.		*Beschikbaarstellend Systeem.

	De ~~generieke transacties waarmee~~ deze systeemrollen ~~gegevens uitwisselen zijn~~:		De samenhang tussen deze systeemrollen is:
	*Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;		*Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;
	*Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;		*Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;

Schmohl op 16 okt 2015 om 13:56

2015-10-16T13:56:29Z

← Oudere versie		Versie van 16 okt 2015 13:56
Regel 28:		Regel 28:
	:9. [[#Paginahistorie\|Paginahistorie]]		:9. [[#Paginahistorie\|Paginahistorie]]

	Klik [https://informatiestandaarden.nictiz.nl/wiki/Format_Wiki_documentatie hier] voor de pagina waarin dit format is uitgewerkt t.b.v. het opstellen van een nieuwe Wiki pagina.		Klik [https://informatiestandaarden.nictiz.nl/wiki/Format_Wiki_documentatie hier] voor de pagina waarin dit format is uitgewerkt t.b.v. het opstellen van een nieuwe Wiki pagina. Door de brontekst van het format te kopiëren en de tekst in hoofdletters te vervangen door de benodigde informatie, kan een Wiki pagina opgesteld worden.

Schmohl op 16 okt 2015 om 13:39

2015-10-16T13:39:06Z

← Oudere versie		Versie van 16 okt 2015 13:39
Regel 6:		Regel 6:

	:1. [[#Inleiding\|Inleiding]]		:1. [[#Inleiding\|Inleiding]]
	::1.1 Algemeen		::1.1 [[#Inleiding->Algemeen\|Algemeen]]
	::1.2 Doelgroep		::1.2 [[#Inleiding->Doelgroep\|Doelgroep]]
	::1.3 Kaders & Uitgangspunten		::1.3 [[#Inleiding->Kaders & Uitgangspunten\|Kaders & Uitgangspunten]]
	:::1.3.1 Richtlijn		:::1.3.1 [[#Inleiding->Kaders & Uitgangspunten->Richtlijn\|Richtlijn]]
	:::1.3.2 Infrastructuur		:::1.3.2 [[#Inleiding->Kaders & Uitgangspunten->Infrastructuur\|Infrastructuur]]
	:::1.3.3 ...		:::1.3.3 ...
	::1.4 Kwalificatie		::1.4 [[#Inleiding->Kwalificatie\|Kwalificatie]]
	:2. Use case(s)		:2. [[#Use cases\|Use case(s)]]
	::2.1 Use case X		::2.1 [[#Use cases->Use case X\|Use case X]]
	:::2.1.1 Procesbeschrijving		:::2.1.1 [[#Use cases->Use case X->Procesbeschrijving\|Procesbeschrijving]]
	:::2.1.2 Bedrijfsrollen		:::2.1.2 [[#Use cases->Use case X->Bedrijfsrollen\|Bedrijfsrollen]]
	:::2.1.3 Systemen & Systeemrollen		:::2.1.3 [[#Use cases->Use case X->Systemen & Systeemrollen\|Systemen & Systeemrollen]]
	:::2.1.4 Transacties & Transactiegroepen		:::2.1.4 [[#Use cases->Use case X->Transacties & Transactiegroepen\|Transacties & Transactiegroepen]]
	::2.2 ...		::2.2 ...
	:3. Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)		:3. [[#Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)\|Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)]]
	:4. Verantwoordelijkheden voor informatie (optioneel)		:4. [[#Verantwoordelijkheden voor informatie (optioneel)\|Verantwoordelijkheden voor informatie (optioneel)]]
	:5. Afschermen van gegevens (optioneel)		:5. [[#Afschermen van gegevens (optioneel)\|Afschermen van gegevens (optioneel)]]
	:6. Infrastructuur (optioneel)		:6. [[#Infrastructuur (optioneel)\|Infrastructuur (optioneel)]]
	:7. ...		:7. ...
	:8. Referenties		:8. [[#Referenties\|Referenties]]
	:9. Paginahistorie		:9. [[#Paginahistorie\|Paginahistorie]]

	Klik [https://informatiestandaarden.nictiz.nl/wiki/Format_Wiki_documentatie hier] voor de pagina waarin dit format is uitgewerkt t.b.v. het opstellen van een nieuwe Wiki pagina.		Klik [https://informatiestandaarden.nictiz.nl/wiki/Format_Wiki_documentatie hier] voor de pagina waarin dit format is uitgewerkt t.b.v. het opstellen van een nieuwe Wiki pagina.