TSC; Voorstel versiebeleid en ballots

• Return to the HL7 Netherlands page

• meeting: TSC
• 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 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

29-1-2009 13:35

Naar aanleiding van het onderwerp op de vergadering van 28 01 2009, bij deze de herzending van het eerder verstuurde voorstel van 11 12 2008:

Ik zag dat Helen dezelfde gedachte had. Gelijktijdig eenmaal per jaar (of zoveel vaker als we nodig achten) was ook waar ik aan dacht. Vooral een gedundelde zip ipv alle gidsen los downloaden zal enorm helpen.

Ik denk dat de TSC over het releasebeleid een uitspraak over moet doen. Voorstel:

 Vooralsnog eenmaal per jaar in november (voorafgaand aan congres)

 Leden ballots zouden van september tot oktober kunnen lopen

 Alle gidsen in de update krijgen dezelfde versie en datum, ook als ze niet wijzigen

Voorstel 2009 01, 2010 01, etc. waarbij 01 staat voor het releasenummer binnen het jaar

Als we meer dan 1 update zouden uitbrengen binnen een jaar dan wordt het bijv. 2009 02. Alleen de TSC kan de urgentie van een tweede release beoordelen

 Alle gidsen moeten, zoals nu ook al zo is, releasenotes 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 2

  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)"

 Aankondiging met releasenotes door secretariaat bij beschikbaarstelling 

 Je zou hoofdstuk 1 kunnen bijwerken met de aankondiging van dit beleid.

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.

Ik denk dat dit de voorspelbaarheid en daarmee aanzien van Stg. HL7 zal vergroten.

Alexander Henket

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.