Auteur: Bert Verhees zaterdag 16 februari 2002 Plan van Aanpak DOSIS-GP ------------------------ DOSIS-GP is een project dat als doel heeft om via discussie en prototyping te komen tot een definitie van wat een goed GP-systeem zou kunnen zijn. Het is niet de doelstelling om tot een werkend systeem te komen. Het geheel zal vermoedelijk onder LGPL worden gelicenseerd. Omdat het een open-source project is, is het licenseringsmodel echter maar beperkt controleerbaar. Iemand kan source-code in het project stoppen en deze source-code onder GPL of anderszins te licenseren. Er is geen weg om dit te voorkomen. Eventueel kan er een werkend systeem uitkomen: anderen kunnen de source-code gebruiken om tot een werkend systeem te komen. Die anderen kunnen behoren tot de industrie, maar in feite kan ieder individu of iedere organisatie dit doen. Het hangt van de licensering van de verschillende modules af hoe dat afgeleide producten gelicenseerd mogen/moeten worden. Documentatie zal in het Engels en in het Nederlands worden geschreven. De prototypen werken met database-string tables die het eenvoudig mogelijk maken om de prototypen meertalig uit te voeren. Internationale inbreng is niet een doel, maar zal ook niet worden verhinderd. De prototypen zullen in de eerste instantie op de Nederlandse situatie zijn georienteerd, maar iedereen die hier wat aan heeft, ongeacht land of locatie kan meedoen of de producten gebruiken. De aanpak valt grofweg uiteen in drie delen: ============================================ Hoe teken je een cirkel? Je begint ergens en tekent de cirkel. De onderstaande taken zijn niet persé in chronologische volgorde weergegeven maar kunnen los van elkaar of als interactie op elkaar op ieder moment plaatsvinden. Beschrijving Processen ---------------------- Dit is vooral een taak voor niet-technici, maar meer voor gebruikers. Er zal worden getracht ongeveer dertig huisartsen te verzamelen die proberen het prototype vooral conceptueel vorm te geven. Leidraden hierbij zijn de processen die goed geautomatiseerd kunnen worden, een veel voorkomend voorbeeld is de anamnese. Eventueel zou de patient betrokken kunnen worden bij een anamnese-interface. Een idee is bijvoorbeeld dat de patient een belangrijk deel van de anamnese thuis zou kunnen doen voordat hij de dokter bezoekt. Dus naast de dertig huisartsen zullen ook nog een groep patienten moeten worden verzameld. De boven beschreven personen zullen via direct-mailings worden benaderd om mee te doen. Functionele Vereisten --------------------- De beschreven processen zullen leiden tot functionele vereisten, dit onder meer zijn vertalingen naar interfaces, datamodellen, communicatie-modellen, etc. Bouw ---- Interfaces, databases, middleware, of aansluiting daar naartoe. Ondersteuning van de aanpak =========================== Webforums --------- A la Slashdot http://slashdot.org, zullen er discussie-forums komen waarin geregistreerde gebruikers hun zegje kunnen doen. De gebruikers kunnen ratings krijgen, die via icoontjes kunnen worden afgebeeld, en waarop kan worden geselecteerd. Ratings kunnen worden verkregen door of gebleken deskundigheid of positie. Zo zal er een rating huisarts bestaan, of een rating voor een IT-specialisme, of een rating patient. Mensen die zich registreren worden indien mogelijk gecheckt, in elk geval een e-mail-check. Wil echter iemand een dokter-rating krijgen dan zal via een BIG-check worden gekeken of die persoon echt huisarts is. Men kan zo er voor zorg dragen dat de lezers van de discussies zich kunnen beperken tot de discussies binnen de voor hun interessante ratings, en kan ruis worden weggefilterd. De software die dit allemaal voor ons doet is open source uitgebracht en heet "Slash", deze is down te loaden via de website http://slashcode.org Ontwikkelomgeving ----------------- Er zal een linux server, Debian (Woody) worden ingericht waarop verschillende ontwikkelomgevingen naast elkaar kunnen staan. Een kleine groep technici zal schrijfrecht hebben op het CVS-repository. Mensen kunnen verzoeken ook schrijfrecht te krijgen, indien zij en wij denken dat ze een positieve bijdrage zullen leveren aan het project. Het staat iedereen vrij om het CVS-repository te lezen, het is immers open source. En is iemand ontevreden over het handelen van het core-team, dan kan hij of zij dat ter discussie stellen in de webforums, of de source-code gebruiken om zelf een project door te starten. Deze mogelijkheden zullen ervoor zorgen dat het core-team verstandig en wijs met deelnemers en deelnemers in spe zal omgaan. Bij slecht beleid zit je voordat je het weet met een of meerdere afsplitsingen, en kan het zijn dat je de focus van het publiek verliest. Deze democratische concurrentie zorgt voor een wijs beleid en goede kwaliteit. Het is een veel beproefd concept. De verschillende ontwikkel-omgevingen kunnen bestaan uit PHP, Perl, Zope (Python), Java, en hoewel niet benoemd, ook C of C++, Pascal. Eiffel, Lisp, etc.. De bedoeling is wel dat het een web-enabled applicatie wordt, en dat de verchillende modules op een of andere manier zinvol met elkaar moeten kunnen interacteren. Verder zijn er richtlijnen wat betreft de interfaces, deze zullen verplicht hun strings uit een database moeten halen, zodat het eenvoudig is in meerdere talen te publiceren. Er zit (dus) ook een database bij de ontwikkel-omgeving. De voorkeur gaat uit naar MySQL, maar eigenlijk is het geen probleem om ook andere database-engines in te schakelen, bijvoorbeeld PostgreSQL. Voorwaarde is dat alle tools open-source tools zijn, hoewel we daar weer in de knoei komen met Java.