Zib-PainCharacteristics #414
Conversation
| <patternCodeableConcept> | ||
| <coding> | ||
| <system value="http://snomed.info/sct" /> | ||
| <code value="310951000146102" /> |
There was a problem hiding this comment.
QA faalt nog op deze code omdat deze nog niet in een release zit. Wel al in de Daily Build, dus komt ""vanzelf"" goed.
| <comment value="PainType" /> | ||
| </mapping> | ||
| </element> | ||
| <element id="Observation.component:painEpisodeDuration"> |
There was a problem hiding this comment.
Ik mis TimeOfOnset in het profiel, maar los daarvan heb ik mijn twijfels of dat op Observation.effectiveDateTime moet komen en PainEpisodeDuration op een .component. .effictiveDateTime gaat over het moment waarop de waarneming gold, maar dat is niet helemaal hetzelfde als wanneer het begon. Tegelijkertijd hebben we een duur die ook iets met .effective te maken zou moeten hebben. Het lijkt eerlijk gezegd op zib TimeInterval met een start en een duur.
Misschien biedt .effectiveTiming hier nog een aanknopingspunt, dan zou je (met een repeat van 1) Timing.event, Timing.repeat.period en Timing.repeat.periodUnit kunnen inzetten. Maar ook hier is het onduidelijk of Timing.event in dat geval als startpunt beschouwd mag worden.
Andere optie is om misschien zib TimeInterval hier in te zetten. Dat zou wel afgestemd moeten worden met het zibcentrum.
There was a problem hiding this comment.
We hebben idd drie tijd gerelateerde elementen:
- PainEpisodeDuration
- TimeOfOnset
- PainCharacteristicsDateTime --> zou dit op
.issuedkunnen?
Voor 1&2 denk ik .effectiveDateTime of .timing.event een goed genoege benadering zijn. Maar je zou ook nog kunnen denken aan .effectivePeriod.start dan heb je wel heel expliciet het start moment. Dan zou je ofwel nog de de .effectivePeriod.end kunnen vullen en die van elkaar af trekken om de PainEpisodeDuration te berekenen. Of inderdaad gebruik maken de zib TimeInterval, dat geeft een extensie om de duur netjes in kwijt te kunnen.
Voordel van Timing is dat je geen last heb van het Period datatype als je geen .end hebt én dat je er beide concepten in kwijt kan. Nadeel is dat Timing wat complexer is en dit bijv bij $LastN operaties super moeilijk te implementeren is.
Misschien inderdaad eens horen bij het zib centrum of hier niet een TimeInterval ingezet had moeten worden?
There was a problem hiding this comment.
Als je kijkt naar de zib, dan staat daar een voorbeeld met een BeginTijdPijn van 11-08-2020 een PijnAanvalDuur van 1 uur. Ik snap die usecase wel en dat lijkt me niet te vertegenwoordigen met een Period. Zib Tijdsinterval lijkt daarvoor ook minder geschikt, maar dat is mss. nog de moeite van het navragen waard. Timing met event en duration lijkt op zich wel goed te passen, maar het is misschien gek dat je een .repeat-container van 1x hebt.
Misschien dat je "tussen 11 en 18 augustus" logischerwijs wel met een Period zou kunnen duiden, maar ik denk dat Timing daar evengoed geschikt voor is. Voor queries en operations etc. is dat idd. mogelijk lastiger, maar ik denk dat het ondoenlijk is om een onderscheid te maken tussen de ene en de andere situatie.
There was a problem hiding this comment.
We hebben idd drie tijd gerelateerde elementen:
1. PainEpisodeDuration 2. TimeOfOnset 3. PainCharacteristicsDateTime --> zou dit op `.issued` kunnen?
Ik denk niet dat .issued hiervoor geschikt is, dit is echt een instant en wordt bovendien overschreven als de waarneming nog wijzigt.
There was a problem hiding this comment.
Eens dat .issued niet geschikt is... dat hebben we waarschijnlijk de vorige keer ook al vastgesteld.
Ik heb een vraag gesteld voor het zib centrum over de relatie met TijdsInterval: https://nictiz.atlassian.net/servicedesk/customer/portal/4/NSM-1804
Beide opties zijn volgens mij levensvatbar, gebruik van TimeInterval of de Timing.
There was a problem hiding this comment.
Er is een antwoord gekomen: https://nictiz.atlassian.net/browse/ZIB-2635 - gebruik TimeInterval valt daar geloof ik me af.
Dit dus uitwerken middels het Timing datatype?
There was a problem hiding this comment.
Als ik de uitleg lees, dan denk ik eigenlijk dat PainEpisodeDuration juist wél op een .component thuishoort -- het hoort bij de uitslag van de "meting". Voor TimeOfOnset geldt dan eigenlijk hetzelfde. PainCharacteristicDateTime zou dan op .effective komen denk ik. Dus je kan iets krijgen als "Op 25 april (PainCharacteristicDateTime, .effective) was het zo dat de patiënt vanaf januari (TimeOfOnset, .component) last van peunscheuten heeft die telkens een uur aanhouden (PainEpisodeduration, .component).
There was a problem hiding this comment.
... alhoewel ... als je wel continue pijn hebt vanaf januari, dan zou je misschien weer .effectivePeriod.start verwachten zonder .effecitvePeriod.end
There was a problem hiding this comment.
Of misschien toch niet. De definitiecode is "276435006/Bevinding betreffende pijn en/of sensatie" (geen observable entity). De .effective gaat dan niet over de pijn zelf maar over de bevinding.
No description provided.