Korte toelichting op de workflow
Inhoud
Info |
---|
Deze workflow beschrijft de stappen en de samenwerking binnen de Koppeltaal community met betrekking tot de doorontwikkeling van de Koppeltaal-standaard. |
Note |
---|
Deze worflow beschrijft niet de stappen en de samenwerking die betrekking hebben op doorontwikkeling van de Koppeltaal-voorziening. De Koppeltaal voorziening wordt vanuit het gezichtspunt van de Koppeltaal-standaard gezien als één van de vele applicaties die gebruikmaken van de Koppeltaal-standaard. |
Table of Contents | ||
---|---|---|
|
Wat is de Koppeltaal-standaard
Wat ontwikkelen we door?
De Koppeltaal-standaard bevat technische specificaties - gebaseerd op use cases uit de community - die voorziening-, en applicatieleveranciers in staat stelt om Koppeltaal functionaliteit in te bouwen in voorziening en applicaties.
De Koppeltaal standaard bestaat uit een combinatie van documentatie, een referentie-implementatie, en testscripts (zie figuur) De documentatie bestaat uit beschreven use cases, architectuur, standaard specificaties, en een developerguide. De referentie-implementatie bevat werkende code als voorbeeld voor software ontwikkelaars.
Alles wat we ontwerpen voor de standaard bouwen we ook zo snel mogelijk en toetsen we vervolgens in de referentie implementatie. Dit doen we om te voorkomen dat we eerst iets heel uitgebreid gaan documenteren wat later misschien niet blijkt te werken. We ontwerpen steeds net voldoende en net op tijd op papier om voldoende kaders en richting te geven aan de bouw. Een laatste belangrijk onderdeel van de standaard zijn de testscripts. Alles wat we bouwen en beschrijven moeten we kunnen toetsen en testen. Pas wanneer de driehoek van documentatie, referentie-implementatie, en testscipts overeenkomt geven we en versie van de standaard vrij voor oplevering.
Drawio | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Snel naar:
Testscrips (nog niet publiek toegankelijk)
Note |
---|
Voor ontwikkelen tegen de referentie implementatie zijn testsuites beschikbaar. Deze maken géén onderdeel uit van de Koppeltaal-standaard en worden gezien als losse diensten. |
De doorontwikkel-workflow samengevat
De doorontwikkel-workflow start vanuit gebruik & beheer en volgt steeds drie processen van achtereenvolgens afspreken, wijzigen, en implementeren om weer te eindigen in gebruik & beheer. Elke stap triggert een volgende stap en tussen iedere stap vindt informatie overdracht plaats. Aan iedere overdracht zijn kwaliteitseisen verbonden. De flow is geen eenrichtingsverkeer. Als bijvoorbeeld een behoefte niet duidelijk genoeg is uitgewerkt om er een goede afspraak over te kunnen maken dan gaat de behoefte een stapje terug. Dat kan een stapje terug naar het vorige proces betekenen maar ook een stapje terug binnen het proces. Het uitwerken van alle mogelijke uitzonderingen en feedback loops zou resulteren in een onleesbare en daardoor onbruikbare workflow.
Drawio | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Gebruik & Beheer
Het directe gebruik van de Koppeltaal-standaard vindt plaats bij de partijen die deze gebruiken om aanpassingen door te voeren in hun applicatie of technische voorziening.
Het eindgebruik van de Koppeltaal-standaard vindt plaats binnen de Koppeltaal domeinen van aangesloten zorgaanbieders. Applicaties en technische voorziening leveren daar gezamenlijk de noodzakelijke Koppeltaal functionaliteit conform de Koppeltaal-standaard, waardoor zorgverlener en patiënt/cliënt in staat zijn om gebruik te maken van geïntegreerde eHealth binnen het hybride zorgproces. Vanuit (eind)gebruik maar ook beheer ontstaan wensen voor verbetering van de Koppeltaal standaard.
Afspreken
Binnen het proces afspreken bekijken we welke verbeteringen (aanpassingen of uitbreidingen) in aanmerking komen voor doorontwikkeling. Tijdens dit proces maken we de behoeften specifiek en stellen we de oplossingsrichting vast. Wanneer er overeenstemming is over de juistheid daarvan maken we daar afspraken over en leggen die vast. Zodra er overeenstemming is over gemaakte afspraken volgt overdracht naar het wijzigingsproces middels één of meerdere wijzigingsverzoeken.
Wijzigen
In de stap wijzigen wordt de nieuwe versie van de Koppeltaal-standaard specificatie gemaakt. De standaard moet daarbij flexibel genoeg zijn voor implementatie op meerdere technologische platformen en in lijn blijven met internationale standaarden. Na wijzigen volgt de overdracht naar publiceren.
Implementeren
In de stap implementeren wordt de nieuwe versie van de Koppeltaal-standaard beschikbaar gesteld aan de gebruikers ervan en daarmee ook de ondersteuning bij het gebruik ervan.
Uitgewerkte processen
Child pages (Children Display) |
---|
Achtergrondinformatie
Wat is een workflow
We werken de opbouw van deze deze doorontwikkel-workflow uit in proces (wat moet er gedaan worden), procedure (wie spelen daar een rol), en werkinstructie (welke middelen zijn daarvoor nodig). De combinatie van de processen afspreken, wijzigen, en publiceren vormen een gestandaardiseerd samenhangend geheel van te doorlopen stappen. Dit geheel is wat we de workflow noemen.
Waarom deze workflow
De workflow heeft als doel om de doorontwikkeling (verbetering) van de Koppeltaal-standaard te ondersteunen.
Het uitschrijven van alle basisstappen binnen een workflow maakt deze voorspelbaar en controleerbaar.
Het uitschrijven van alle taken en verantwoordelijkheden maakt de rol van betrokkenen binnen de workflow duidelijk.
De combinatie van punten 2 en 3 maakt van het procesmodel een belangrijk communicatiemiddel waarmee belanghebbenden geïnformeerd kunnen worden over de manier van samenwerken bij het doorontwikkelen van de standaard.
De combinatie van punten 2 en 3 maakt van het procesmodel een belangrijk middel om dialoog te voeren over de juiste invulling van de processen, bemensing, en inzet van middelen.
Het volgen van de uitgeschreven workflow leidt niet alleen tot een gecontroleerde doorontwikkeling maar vooral ook tot een gewenste doorontwikkeling.
Wat is deze workflow niet
Deze workflow is niet bedoeld om voor te schrijven hoe bepaalde vakinhoudelijke handelingen plaats moeten vinden. We schrijven niet voor hoe de IT-architecten architectuur moeten ontwikkelen, hoe een tester moet testen, hoe een ontwikkelaar moet ontwikkelen, etc. Het invullen van al deze vakinhoudelijke best-practices is aan het vakgebied zelf. Wat wel belangrijk is om te weten is hoe al deze vakgebieden samen kunnen werken en wat men daarbij van elkaar nodig heeft.
Deze workflow beschrijft ook niet het inbouwen van de Koppeltaal-standaard in informatiesystemen zoals Koppeltaal-voorziening en applicaties. Vanuit deze worfklfow vallen die activiteiten onder “Het gebruik van de Koppeltaal-standaard”. (zie Koppeltaal keten van handelingen)
Continue verbetering
Een vast wederkerend onderdeel van deze workflow is een evaluatie van de workflow zelf waarin we bekijken waar we kunnen verbeteren. Wanneer jij als lezer echter ergens een verbeterkans ziet of vragen in het algemeen hebt neem dan even contact op via koppeltaal.nl.
Koppeltaal keten van handelingen
Een oplevering van een volgende productieversie van de Koppeltaal-standaard leidt tot een keten van handelingen die plaats moeten vinden om de standaard in alle systemen geïmplementeerd te krijgen. Onderstaande afbeelding illustreert hoe deze keten er uit kan zien bij een nieuwe productieversie met impact op zowel de Koppeltaal-voorziening als de applicaties.
Drawio | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|