Handleiding Wiki documentatie

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.

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 Visio voorbeeld/template uitgewerkt. Vervolgens maak je op deze manier de afmetingen van je Visio diagram zo efficiënt mogelijk.

Opbouw Wiki pagina’s

De Wiki pagina’s voor de verschillende informatiestandaarden zijn qua opbouw gelijk aan elkaar. Weliswaar kan de wijze waarop de pagina’s per informatiestandaard al dan niet gevuld zijn per informatiestandaard verschillen. Zo kan bij een informatiestandaard sprake zijn van meerdere kaders en uitgangspunten in tegenstelling tot een andere informatiestandaard, kan het zijn dat optionele hoofdstukken al dan niet gevuld zijn en is het mogelijk dat een informatiestandaard uit één of meerdere use cases bestaat. De Wiki pagina’s bestaan generiek uit onderstaande hoofdstukken, waarbij middels “...” is aangegeven dat informatiestandaard specifiek aanvullingen mogelijk zijn. Met ”(optioneel)” is aangegeven dat deze hoofdstukken niet voor alle informatiestandaarden gevuld hoeven te zijn.

1. Inleiding

1.1 Algemeen

1.2 Doelgroep

1.3 Kaders & Uitgangspunten

1.3.1 Richtlijn

1.3.2 Infrastructuur

1.3.3 ...

1.4 Kwalificatie

2. Use case(s)

2.1 Use case X

2.1.1 Procesbeschrijving

2.1.2 Bedrijfsrollen

2.1.3 Systemen & Systeemrollen

2.1.4 Transacties & Transactiegroepen

2.2 ...

3. Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)

4. Verantwoordelijkheden voor informatie (optioneel)

5. Afschermen van gegevens (optioneel)

6. Infrastructuur (optioneel)

7. ...

8. Referenties

9. Paginahistorie

Klik 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.

Pagina onderdelen van Wiki pagina’s

Onderstaande subhoofdstukken geven een korte beschrijving van alle pagina onderdelen waaruit een Wiki pagina is opgebouwd.

Inleiding

De inleiding van een Wiki pagina geeft een informatiestandaard specifieke beschrijving, zonder in te zoomen op de concrete use cases die onderdeel zijn van de informatiestandaard. De beschrijving is opgesplitst in verschillende subhoofdstukken, waaronder Algemeen, Doelgroep, Kaders & Uitgangspunten en Infrastructuur.

Inleiding->Algemeen

Een algemene toelichting op de Wiki pagina waarin wordt aangegeven dat de pagina een functioneel ontwerp voor een bepaalde informatiestandaard is. Tevens wordt de context waarin de pagina door de lezer geplaatst moet worden nader toegelicht.

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;
• Vertegenwoordigers van zorgverleners.

Indien sprake is van een doelgroep per use case, wordt deze hier aangegeven.

Inleiding->Kaders & Uitgangspunten

De kaders en uitgangspunten van de Wiki pagina waarbij de beschrijving is opgesplitst in verschillende subhoofdstukken, waaronder Richtlijn, Infrastructuur en Kwalificatie.

Inleiding->Kaders & Uitgangspunten->Richtlijn

Een beschrijving van, incl. referentie naar, de richtlijn die als uitgangspunt voor de informatiestandaard gebruikt is.

Inleiding->Kaders & Uitgangspunten->Infrastructuur

Een tekstuele toelichting waarin kan worden aangegeven dat de informatiestandaard infrastructuur onafhankelijk is. Infrastructuur specifieke informatie is opgenomen in een ander hoofdstuk.

Inleiding->Kwalificatie

Indien sprake is van een kwalificatiemogelijkheid bij Nictiz voor de informatiestandaard, wordt hier een referentie opgenomen naar de pagina waar meer informatie is terug te vinden over kwalificaties.

Use cases

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

In dit hoofdstuk wordt een beschrijving gegeven van één (van de) use case(s) waarvan voor deze informatiestandaard sprake is. De Use case X wordt vervangen door de naam van de use case. De beschrijving is opgesplitst in verschillende subhoofdstukken, namelijk: Procesbeschrijving, Bedrijfsrollen, Systemen & Systeemrollen en Transacties & Transactiegroepen.

Use cases->Use case X->Procesbeschrijving

Een beschrijving van het zorgproces waar de use case betrekking op heeft. De zaken die reeds beschreven zijn, bijv. in de richtlijnen die als uitgangspunt zijn gebruikt, worden niet in zijn geheel herhaald in de procesbeschrijving. Hier worden alleen zaken beschreven die benodigd zijn om het scenario in ART-DECOR (behorende bij deze use case) in context te plaatsen. Eventueel kan hier zowel de huidige als toekomstige situatie beschreven worden.

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.

Use cases->Use case X->Systemen & Systeemrollen

Een opsomming van de informatiesystemen die door de bedrijfsrollen gebruikt worden. De systemen worden benoemd naar hun functionele aard. Vervolgens wordt per informatiesysteem opgesomd welke systeemrollen dit systeem vervuld. Een systeemrol is een functie die het systeem vervuld en wordt in ART-DECOR als “actor” gevuld als onderdeel van een transactie (zie ook volgend hoofdstuk). De naamgeving van de systeemrol is afhankelijk van het type transactie (push/pull) waarbij een systeemrol betrokken is.

Een systeem kan één of meerdere van de volgende systeemrollen vervullen:

• Sturend Systeem;
• Ontvangend Systeem;
• Raadplegend Systeem;
• Beschikbaarstellend Systeem.

De generieke transacties waarmee deze systeemrollen gegevens uitwisselen zijn:

• Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;
• Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;
• Raadplegend Systeem vraagt gegevens op bij een Beschikbaarstellend 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). 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: Acute Zorg Proces – Spoedbericht Sturend 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.

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

Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, een verzameling van transacties (bijvoorbeeld een vraag- en antwoordbericht) vormt een zogeheten transactiegroep.

De naam van de transactie wordt bepaald aan de hand van het soort transactie, waarbij binnen een transactiegroep sprake is van:

• Sturen en Ontvangen;
• Raadplegen en Beschikbaarstellen.

Het soort transactie wordt gevolgd door het soort bericht dat wordt uitgewisseld, bijv. Spoedbericht. Zo ontstaat bijvoorbeeld Sturen Spoedbericht.

De naam van de transactiegroep wordt bepaald door het soort bericht dat wordt uitgewisseld (bijv. Spoedbericht) gevolgd door een indicator voor het type transactie hoofdletters, tussen haakjes ((PUSH), (PULL)).

• Sturen en Ontvangen -> PUSH.
• Raadplegen en Beschikbaarstellen -> PULL.

Zo ontstaat bijvoorbeeld Spoedbericht PUSH.

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 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.

Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)

Een beschrijving van de aanwijzingen/eisen voor functionaliteit van systemen zoals die tijdens de ontwikkeling van een informatiestandaard geïdentificeerd worden en waaraan de systemen dan ook moeten voldoen.

Verantwoordelijkheden voor informatie (optioneel)

Een uiteenzetting van de verantwoordelijkheden voor informatie die in het kader van de informatiestandaard wordt overgedragen. In dit hoofdstuk kan inzichtelijk gemaakt worden welke bedrijfsrol wanneer de inhouds- en beheerverantwoordelijkheid heeft voor geleverde medische informatie binnen het proces.

Afschermen van gegevens (optioneel)

Indien in het kader van de informatiestandaard afspraken zijn gemaakt omtrent het afschermen van gegevens, kunnen deze afspraken in dit hoofdstuk beschreven worden.

Infrastructuur (optioneel)

Mocht voor de informatiestandaard sprake zijn van een specifieke infrastructuur waarop de informatie die in de informatiestandaard is gespecificeerd wordt uitgewisseld, kan in dit hoofdstuk de infrastructuur kort worden benoemd en een referentie opgenomen worden naar aanvullende documentatie bij de aanbieder van de infrastructuur in kwestie.

Referenties

Een overzicht met referenties waar naar verwezen wordt in het functioneel ontwerp.

Paginahistorie

De pagina historie behorende bij de Wiki pagina. De paginahistorie wordt bijgehouden wanneer bijv. errata verwerkt zijn in de reeds gepubliceerde Wiki pagina. Bij het uitbrengen van een nieuwe versie van de informatiestandaard, zal een nieuwe Wiki pagina (incl. bijbehorend versienummer) worden gepubliceerd. Daarbij wordt deze tabel dan aangevuld met een omschrijving van de doorgevoerde wijzigingen.