Finale peerreview:

Akkoord met voorstel

Gaan we dat toevoegen.

Is de pijn wellicht weggenomen als we in de definitie iets zeggen dat voor intervallen in de toekomst begin- en eindtijdstip niet altijd bekend hoeven te zijn?

Dat zou zeker helpen ja.

Iets als:

1. Start + Eind

2. Start + Duur

3. Eind + Duur

4. Voor intervallen in de toekomst kan het zijn dat start en/of einddatum niet bekend zijn en alleen duur bekend is.

Former user: Qua cardinaliteiten zie ik geen verschil met wat je over HL7 meldt. Dat je een duur alleen met IVL-TS zou kunnen weergeven vind ik vreemd. Duur is per definitie een PQ, ook in complexe datatypes. Dat je IVL-TS gebruikt voor een interval waarvan de duur wel maar de begintijd nog niet bekend is, lijkt me logisch en de zib verhindert dat ook niet. Maar dan is er wel de intentie om een interval te gebruiken. Maar als je zou willen modelleren dat een dag een duur van 24 uur heeft, is de duur een eigenschap van de dag en is een enkelvoudig PQ element een meer correcte modellering. Daarom zou ik er niet voor zijn om het gebruik van de subzib voor duur alleen te propaganderen. In de usecase die je noemt  lijkt me dat terecht maar zeker niet in het algemeen.

Al met al zie ik niet wat er aan de zib gewijzigd moet worden. Natuurlijk leidt het invullen van alle drie de elementen tot redundantie of tegenstijdigheid maar de bedoeling is vooral om de verschillende mogelijkheden te bieden en niet om foutief gebruik te verhinderen. Het vullen met relevante gegevens blijft te allen tijde de verantwoordelijkheid van de gebruiker. 

Is de pijn wellicht weggenomen als we in de definitie iets zeggen dat voor intervallen in de toekomst begin- en eindtijdstip niet altijd bekend hoeven te zijn?

In medicatieproces is het alléén toepassen van tijdsduur in een gebruiksperiode een valide use case. Je weet niet altijd de startdatum (laat staan de einddatum), maar je weet meestal wel hoe lang een bepaalde kuur gebruikt moet worden op het moment dat dat relevant wordt.

Deze use case past overigens juist heel erg goed op het HL7v3 IVL_TS datatype dat zowel low, width als high kent met geen verplichting op het meegeven van meer dan één van die velden. Er is in HL7v3 ook geen andere manier om een dergelijke tijdsduur mee te geven, dat gaat via de IVL_TS/width.

Verder: al sinds MP 6 (rond 2005) is er de use case om alleen width (tijdsduur) mee te geven voor gebruiksperiode in diezelfde IVL_TS.