TSC; Voorstel versiebeleid en ballots
- Return to the HL7 Netherlands page
- meeting: HL7 Brainstormmiddag
- Author: Adri Burggraaff en Alexander Henket.
- Status: DRAFT - subject to changes by the authors
Inleiding
Dit voorstel is t.b.v. HL7 NL TSC en gaat over HL7 versie 2 versiebeleied en ballots en hoe we daar mee om gaan en moet leiden tot een besluit in de TSC dat gaat gelden voor alle TC's.
Voorstel
Voorstel releasebeleid HL7v2 implementatiegidsen:
- Tijdlijn voor reguliere publicatie
- jan-apr - Werken aan nieuwe versies
- mei - jun - Ballot en verwerking commentaar (optioneel, na goedkeuring TSC)
- jul - aug - Werken aan nieuwe versies
- sept -okt - Ballot en verwerking commentaar
- nov - Release voorafgaand aan het Standaardisatiecongres
- Ballot
- Alle gidsen met wijzigingen gaan tegelijk in ballot
- De standaardperiode voor ballot is september/oktober, maar indien noodzakelijk wordt geacht door een TC kan mei/juni worden gebruikt voor een eerdere ballot. Dit kan zijn omdat er twee ballotrondes nodig worden geacht, of omdat er eerder een release wenselijk is. De TSC beslist op aangeven van de betreffende TS('s)
- Periode van een maand waarin commentaar gegeven kan worden op wijzigingen
- Versienummer YYYY-r01c, waarbij YYYY-r01 voor het uiteindelijke versienummer staat en c voor "concept"
- Commentaar indienen d.m.v. de HL7 Inc formulieren (zoals we dat ook in 2009 hebben gedaan)
- Aankondiging met releasenotes (van alle gidsen bij elkaar) door secretariaat bij beschikbaarstelling
- Ballotpack als ZIP-bestand, bijv. "HL7v2.4 NL Update 2009-r01c.zip" in de algemene downloadsectie van de website
- Publicatiewijze
- Vooralsnog op de website
- Vooralsnog in Word doc-formaat (dus nog niet docx, echter pdf is te overwegen)
- Alle gidsen krijgen dezelfde versie en datum, ook als ze niet wijzigen
- Versienummer YYYY-01. Bijv. 2009-r01, 2010-r01, etc. waarbij 01 staat voor het releasenummer binnen het jaar. Indien er een spoedpublicatie (zie verder) moet gebeuren dan wordt het laatste deel verhoogd tot bijv. 2010-r02
- Gidsen moeten los downloaden zijn, maar ook als gebundelde ZIP, bijv. "HL7v2.4 NL Update 2009-r01.zip"
- Alle gidsen moeten, zoals nu ook al zo is, het overzicht van de wijzigingen bevatten in de bovenkant van het document. Op dit moment houden we dit integraal, dus niet incrementeel, bij als:
Juli 2006
- wijziging 1
- wijziging 2
Mei 2007
- wijziging 1
- wijziging 2Ik zou daar niets aan willen wijzigen, maar alle kopjes zoals "Mei 2007" vooraf laten gaan door het door ons gekozen versienummer voor de jaarlijkse update, dus bijv. "2007-r01 (mei 2007)"
- Aankondiging met releasenotes (van alle gidsen bij elkaar) door secretariaat bij beschikbaarstelling
- Spoedpublicatie
- Spoedpublicaties zijn alle officiële releases die niet onder de reguliere publicaties vallen, bijv. omdat er nieuwe wet- of regelgeving is, of een echte fout is geconstateerd
- De TSC beslist, al of niet op aangeven van een TC/SIG of een spoedpublicatie gedaan zal worden en of er nog een of andere vorm van ballot op moet worden toegepast
- Publicatie van een spoedpublicatie gebeurt in de vorm van een apart document
- De titel van het document is "Erratum 2009-r02 <beschrijvende tekst>" voor foutherstel en "Addendum 2009-r03 <beschrijvende tekst>" voor toevoegingen
- Er moet nog een sjabloon worden ontwikkeld dit type documenten voor aantal vaste onderdelen zoals de verwijzing naar de release waarop het een erratum vormt etc.
- Verder volgt een spoedpublicatie alle regels voor reguliere publicaties en wordt deze dus ook toegevoegd in het ZIP-bestand
- Overig
- Hoofdstuk 1 bijwerken met ons releasebeleid
Als we dit voor elkaar kunnen krijgen, dan is de tijd in principe ook rijp voor Conformance Statement ID's. Het verzoek kan dan naar TC IM om die vast te leggen. Mijn idee zou daarbij zijn dat niet met terugwerkende kracht te doen, maar vanaf update 2008.
Commentaar/Opmerkingen
Van: Rene Spronk
HL7 NL zou één keer per jaar een nieuwe ZIP uit kunnen brengen met alle laatste versies van de NL implementatiegidsen. Low tech, maar gaat zeker werken..
Alexander Henket wrote:
Het veld dat je bedoelt is MSH|21 Conformance Statement ID.
Gewetensvraag: aangezien alle TC's los van elkaar updates uitbrengen,
welke waarden zou je dan vastleggen voor het geheel? Of zou je het
updateproces van de TC's eerst moeten harmoniseren zodat TC's
gelijktijdig updates als 1 update voor alle gidsen?
Kortom (veld is maar 10 tekens lang):
Zou je NL24 07 11 (Nederlandse implementatierichtlijn versie 2.4, 2007 (november) of zou je NL24 3 5 (Nederlandse implementatierichtlijn versie 2.4, hoofdstuk 3, update 5) willen hebben?
Het veld is herhalend, dus men kan op die wijze ook uitdrukken dat men naast HL7v2.4 Hoofdstuk 3 Update 2007 ook voldoet aan hun eigen ingeperkte versie daarvan.
mvg, Alexander Henket
van René Suggestie nav de discussie:
Voeg profile Id toe (MSH 25 geloof ik), om verschillende releases van de 2.4 aanbevelingen te identificeren. Dus tabelletje toevoegen met codes voor de verschillende releases, opdat men die kan gebruiken om te identificeren welke release men gebruikt. Daar hangt dan wel de voorwaarde aan dat de zender daarmee "plechtig verklaart" aan alle voorwaarde in die release van de aanbevelingen te voldoen.
Groets, René
Commentaar op voorstel versiebeleid en ballots Alexander 11-12-2008 van Adri Burggraaff
1. Release beleid Vooralsnog eenmaal per jaar in november (voorafgaand aan congres) is een goed plan. Maar wat doen we dan met veranderingen afgestemd op een bepaalde situatie of ontwikkelingen (acuut) in de markt. Of essentiële fouten die we hebben ontdekt. Gaan we doorgeven via een soort nieuwsbulletin/flits. Doen we dat dan per email of op de website
2. Leden ballots zouden van september tot oktober kunnen lopen Ik ben het daar niet mee eens, dan kun je net als met internationaal, van die grote pakketten krijgen waar (dan) toch (bijna) niemand naar kijkt. Drie keer per jaar op een vaste periode is m.i. ook geen optie, want dan zou je altijd “iets” moeten hebben. Ik ben van mening dat ballots die wij gewoon (wel afgestemd in de TSC, niet teveel tegelijk) het hele jaar door neer zetten, het voor de leden overzichtelijk blijft, niet teveel inspanning in één keer vergt, en de leden dan ook vaker van ons horen En misschien meer betrokkenheid creëert.
3. Alle gidsen in de update krijgen dezelfde versie en datum, ook als ze niet wijzigen Ik vind dat geen goed idee. Als de datum en versie wijzigen kunnen leden ook gaan denken dat er wel iets is gewijzigd, bovendien zie je dan zelf ook niet snel wanner je een document voor het laatst heb aangepast.
Bovendien onstaat er bij gelijke versie en datum verwarring, een leuk voorbeeld dat ik deze week tegenkwam is TC - H&C (Sorry, no hard feelings). Laatste gepubliceerde release 2.4 op de website, hoofdstuk 7 - update febr. 2006 en voettekst januari 2002 en hoofdstuk 4 - update 2003 met een voettekst januari 2002. M.a.w. updates (of hogere versie en datum) uitbrengen terwijl de gegevens inmiddels 9 jaar oud zijn.
4. Voorstel 2008 01, 2009 01, etc. waarbij 01 staat voor het releasenummer binnen het jaar Kan, is een mogelijke methode, kan ook door leden geïnterpreteerd worden als maandnummer, Voorstel is om dan 2007.1 of 2007:1 te doen.
5. Als we meer dan 1 update zouden uitbrengen binnen een jaar dan wordt het bijv. 2009 02. Ja dat kan, zie onder 4
6. Alleen de TSC kan de urgentie van een tweede release beoordelen Ik zou daar aan toe willen voegen, dat de urgentie in eerste instantie wordt beoordeelt door de betreffende TC en deze adviseert de TSC. Niet ieder TSC lid kan/is in staat de inhoudelijke relevantie te beoordelen.
7. Alle gidsen moeten, zoals nu ook al zo is, releasenotes bevatten in de bovenkant van het document. Op dit moment houden we dit integraal. Ik zou daar niets aan willen wijzigen, maar alle kopjes zoals "Mei 2007" vooraf laten gaan door het door ons gekozen versienummer voor de jaarlijkse update, dus bijv. "2007 01 (mei 2007)" Ben ik het mee eens, zie opmerking onder 4
8. Aankondiging met releasenotes door secretariaat bij beschikbaarstelling Mee eens
9. Je zou hoofdstuk 1 kunnen bijwerken met de aankondiging van dit beleid. Mee eens. Hoofdstuk1 zou sowieso eens aangepast moeten worden door één of beide TSC co-voorzitter(s) is ook van januari 2002 en niet inhoudelijk up to date.
