Release Notes U-DPS 1.0.8.3.

Release notes UDPS
April 2014
UDPS versie 1.0.8.3
De belangrijkste wijzigingen sinds de vorige release worden hieronder in het kort beschreven. Neem
contact op met uw Tieto consultant als u meer informatie nodig heeft.
RFC 97-143: ‘Kopie’ Elektronische Consult Uitslag
Bij de Elektronische Consult Uitslag (ECU) is het nu ook mogelijk om bij een revisie verslag, waarbij de
aanvrager een specialist uit het eigen ziekenhuis is, de beoordelende patholoog uit het oorspronkelijk
laboratorium een Elektronische consult uitslag (kopie) te sturen.
Om dit mogelijk te maken wordt bij de laboratoria, die de ECU functionaliteit in U-DPS hebben laten
installeren, aan het tabblad ‘Kopie’ onder de rubriek ‘Locatie’ een extra rubriek ‘Externe ref.’
toegevoegd. Als deze rubriek is gevuld dan wordt gecontroleerd of bij ‘Code arts’ in betreffend ‘Kopie’
record een bekend LabID t.b.v. ECU is ingevoerd.
Deze ‘kopie’ ECU wordt dan getriggerd door:
Rubriek ‘Soort aanvraag’ = ‘panel’, ‘consult tbv derden’ of ‘revisie tbv derden’ waarbij
o
o
Rubriek ‘Code aanvrager’ op het tabblad ‘Aanvr’ een bekend LabID t.b.v. ECU bevat.
Rubriek ‘Externe ref.’ op het tabblad ‘Aanvr’ gevuld is.
EN/OF
o
o
Rubriek ‘Code arts’ op het tabblad ‘Kopie’ een bekend LabID t.b.v. ECU bevat.
Rubriek ‘Externe ref.’ op het tabblad ‘Kopie’ gevuld is.
Voor iedere combinatie van een ‘Code aanvrager’ of ‘Kopie-code arts’ (beiden een LabID) en een
bijbehorend extern referentienummer (rapportnummer) wordt dan een individuele ECU verzonden aan
desbetreffend laboratorium (LabID).
Bij alle (kopie) ontvangers wordt, conform de voorgaande ECU functionaliteit, bij ontvangt van de
elektronische uitslag (Clinical Document) gecontroleerd op een bestaanbare referentie (rapportnummer
Lab-A) en gelijke geboortedatum.
Ter verduidelijking van de onderliggende probleemstelling zijn onderstaande use cases beschreven.
Use case 1:
Na een eerste onderzoek, aangevraagd door specialist A in ziekenhuis A bij pathologie laboratorium A,
wordt een revisie aangevraagd bij specialist B in ziekenhuis B. Ziekenhuis B vraagt het Pathologie
laboratorium waar zij hun diensten afnemen om een revisie van het eerdere onderzoek. Laboratorium B
vraagt het onderzoeksmateriaal op bij laboratorium A en legt de verslaglegging van dit onderzoek in
haar eigen pathologie systeem (U-DPS) vast onder een nieuw onderzoeknummer (rapportnummer). De
(hoofd)aanvrager is in dit geval de specialist B in ziekenhuis B en niet, zoals bij het uitbesteed
onderzoek/consult, het laboratorium A. De uitslag zal dan ook aan specialist B worden verstrekt zoals dit
in laboratorium B gebruikelijk is via ZIS, EDI of papieren uitslag. Het is gebruikelijk dat bij een externe
revisie het laboratorium B, ter informatie, een uitslag versterkt aan laboratorium A. Laboratorium A kan
op grond van de revisie haar eigen onderzoek aanvullen en zodoende de specialist A in Ziekenhuis A
informeren.
Het verstrekken van een Elektronisch Consult Uitslag (ECU) aan laboratorium A kon in de eerdere
implementatie van de ECU niet gedaan worden omdat de hoofdaanvrager niet het laboratorium A
betreft. Laboratorium A moet in deze use case gezien worden als een ‘Kopie ontvanger”.
Use case 2:
Use case 2 is grotendeels gelijk aan use case1 maar nu wordt onderzoekmateriaal uit twee laboratoria
opgevraagd. Beide laboratoria kunnen dan afzonderlijk een uitslag ontvangen. Er is dan sprake van een
“1 op n relatie”. Om de (kopie) ECU in deze laboratoria aan het oorspronkelijk rapportnummer te
kunnen koppelen moet het betreffend rapportnummer (referentie nummer) 1 op 1 aan die (n) kopie
ontvangers (LabID) gekoppeld worden.
Use case 3:
Use case 3 is een combinatie van usecase 1 (en of 2) en de huidige ECU functionaliteit. Laboratorium A is
hier de hoofdaanvrager maar een of meer (n) laboratoria wensen ook een kopie uitslag te ontvangen op
hun eigen rapportnummer (referentie nummer).
Kern-U-DPS / Systemen X:
Voor gebruikers van Systemen X die gebruik willen maken van de ‘kopie’ functionaliteit is de XML
koppeling voor het aanbieden van rapporten uit Systeem X aan Kern-U-DPS uitgebreid. De ‘kopiecodeaanvrager’ (LabID) met de bijbehorende ‘kopie externe referentie’ moeten door Systeem X, per set
apart, worden aangeleverd. Het Kern-U-DPS zal deze informatie in het Kern-U-DPS als aparte records in
de “Kopie” container opnemen. Systemen X hoeven hierdoor geen kennis te hebben van de ‘container’
functionaliteit zoals deze in (Kern-)U-DPS is geïmplementeerd. Voor verdere details wordt verzocht
contact op te nemen met brightONE.
RFC 25-38: Patiëntnummer toevoegen aan follow-up rapportnummer.
Er is verzocht bij de presentatie van het te onderzoeken (triggerend) follow-up rapportnummer ook het
bijbehorend patiëntennummer te tonen. “Dit maakt het soms makkelijker om vervolgonderzoeken te
vergelijken (in het geval van verhuizingen weet je dan toch dat het om dezelfde patiënt gaat).”
Oplossing: In de presentatie van de lokale resultaten in de Follow-up lijst wordt, indien aanwezig, het
primaire patiëntennummer, en/of patiëntnummer locatie 1 of 2 getoond. De resultaten uit andere
laboratoria bevatten geen patiëntnummer omdat deze niet in de PALGA Zoekvragen Databank (PZVDB)
is vastgelegd.
Kern-U-DPS / Systemen X: de presentatie van follow-up in systemen X is een functionaliteit van deze
systemen zelf. Het eventueel presenteren van het patiëntnummer uit de lokale onderzoeken moet
daarom in en door het systeem zelf ondersteund worden.
RFC 38-43: Keuzelijst ‘Concordant’ uitbreiden.
Er is verzocht om in tabblad ‘Opinie’ de extra functionaliteit minor en major concordant en discordant
toe te voegen.
Oplossing: Het verzoek is toegewezen met de volgende uitvoering.
De keuzelijst bij de rubriek Concordant in het tabblad ‘Opinie’ is uitgebreid met de keuzes:
Nee grote discordantie
Nee kleine discordantie
De keuzes zijn een aanvulling op de bestaande keuzes (ja, nee) en zijn conform de terminologie die in de
PALGA thesaurus wordt gebruikt (i.t.t. minor/major). Er vindt geen automatische vertaling plaats naar,
of controle op de aanwezigheid van, termen in de diagnoseregel(s).
Kern-U-DPS / Systemen X: De uitbreiding wordt ook in de keuzelijst (tabel) van het Kern-U-DPS
opgenomen. Momenteel geven de huidige Systemen X deze rubriek niet door aan Kern-U-DPS omdat
het hier gaat om een rubriek waarvan de inhoud niet aan de landelijke PALGA databanken of derden
wordt doorgezonden.
RFC 66-45: Aanpassen permissiescherm
Er is verzocht om de handling in het ‘Permissie scherm’ rond het toekennen van lees/schrijfrechten in de
zogenaamde [TCSB] layout permissie te verbeteren door:
Het huidige schermdeel rechtsonder veel groter tonen zodat meer overzicht ontstaat
van hetgeen is ingesteld.
De items in het huidige schermdeel rechtsonder op een vaste wijze sorteren.
Oplossing: In overleg met de WerkGroep Dienstverlening is besloten onderstaand, voorstel ter
verbetering uit te voeren.
Als een [TCSB] lay-out permissie wordt gekozen voor bewerking dan wordt middels een nieuwe knop
“Bewerk” een extra venster getoond. Dit venster kan verschoven worden zodat het onderliggend
scherm kan worden ingezien (inclusief het meeverhuizen van de ‘popup’ om de lees/schrijfrechten te
wijzigen). Er kan voor de rubriekenlijst gefilterd worden op tabblad-niveau of op een specifieke tekst
(rubriek titel) gezocht worden. De rubrieken worden alfabetisch gesorteerd.
Kern-U-DPS / Systemen X: het permissiesysteem in U-DPS is U-DPS specifiek en behoeft geen aanpassing
aan Systemen X. Voor Kern-U-DPS gebruikers wordt de grafische gebruikersomgeving(GUI) niet
ondersteund. De aanpassing is daarom niet van toepassing voor Kern-U-DPS.
RFC 97-149: Toevoegen tijdnotatie bij enkele datumrubrieken
Dit betreft een verzamel RFC waarin de RFC’s 21-29, 35-16, 66-37 en 7-16 zijn samengevoegd.
Een aantal laboratoria hebben verzocht om bij een aantal datum rubrieken ook de tijd te noteren. Dit
moet het mogelijk maken de doorlooptijd van onderdelen in kleinere tijdseenheden dan dagen in te
zien. Daarnaast is ook verzocht een rubriek 'datum 1e autorisatie‘ toe te voegen aan het tabblad ‘Inschr‘
om de datum/tijd van de eerste autorisatie te kunnen bewaren en presenteren. Bij al bestaande
onderzoeken is deze rubriek leeg. Bij het de-autoriseren van een bestaand onderzoek wordt door het UDPS de datum 1e autorisatie alsnog (indien uit een eerste versie [A] herleidbaar) ingevuld.
De ‘datum autorisatie’ zal de laatste autorisatie datum blijven presenteren.
Het gaat hierbij om (aangegeven door de leden van de WerkGroep Dienstverlening):
de datum rubrieken bij alle tekstvelden op tabbladen:
o
Klin (klinischegegevens, -vraagstelling)
o
Macro (Macroscopie)
o
MiConc (Microscopie, Conclusie, Epicrise)
o
Opm (Aantekening, Opmerking)
o
Lokaal (lokaal1 - 4)
en de losse datum rubrieken:
o
o
o
o
o
o
o
o
Datum aanvraag
Datum afname
Datum ontvangst
Datum inschrijving
Datum aut.(laatste)
Datum uitslag
Datum 1e uitslag
Datum 1e autorisatie (nieuw toe te toevoegen).
Voor de B-onderzoeken geld dat de datum en tijd, bij de lange tekstrubrieken, alleen worden gevuld bij
aanvullingen in het vrije tekst deel. Bij wijziging van ‘beschermende tekst’, die door de rubrieken in de
tabbladen ‘Cris’ en Kopacb’ wordt gegenereerd, worden de datum en tijdrubrieken niet gevuld.
Omdat datum en tijd opwaarts compatibel (dus ten opzichte van het verleden en de huidige situatie)
moeten blijven wordt, voor de hierboven benoemde rubrieken, in de U-DPS schermen een
extra/separate rubriek ‘Tijd’ toegevoegd.
De huidige landelijke en lokale software verwacht geen tijd in een datumrubriek. Ook complementaire
systemen (LMS, LIMES, MagnaView, PPM) verwachten geen tijd in een datumrubriek.
Voor onderstaande ‘xxxxx’ moet u de corresponderende ‘datum’ databasenamen lezen.
Zo wordt bij ‘datumontvangst’ een rubriek ‘tijdontvangst’ aan de database toegevoegd.
datumxxxxx (2013-02-01)
tijdxxxxx (08:53)
ts_xxxxx (1306704600), gecombineerde pseudorubriek
Om te kunnen rekenen met tijden in een extern programma (bijvoorbeeld Excel) zijn datum en tijd ook
gecombineerd opvraagbaar in één pseudorubriek. Hierbij wordt een zogenaamde ‘unix timestamp’
notatie gebruikt. Dit betreft het aantal seconden dat verstreken is sinds 1-1-1970, 00:00 uur.
LET OP: Het is niet mogelijk om het Vragenscript “u_doorloop” te gebruiken met ‘tijdxxxx’ of ‘ts_xxxxx’.
Het is zeer lastig te bepalen hoe de verstreken tijd buiten een werkdag, weekend of feestdag moet
worden afgetrokken van de totaal verstreken tijd. Bij “u_doorloop” kunt u wel aangeven dat bij het
berekenen van de doorlooptijden wel of geen rekening gehouden moet worden met ‘alleen’ werkdagen
(zie tabblad variabelen, optie ‘AlleenWerkdagen = ja’). In de tabel ‘feestdag’ vindt u de landelijke
feestdagen die u zelf kunt aanvullen met lokale feestdagen of ‘niet werkdagen’.
In de U-DPS dataentry omgeving zijn de bestaande datumcontroles aangepast of aangevuld (datumtest,
tijdtest en datumset vergelijkingen) om ook ‘tijd’ in relatie met andere datum/tijdvelden consistent te
houden.
Door spraak applicaties, complementaire LMS-en, en de PPM wordt geen tijd van het dictaat of mutatie
aangegeven. Het U-DPS zal dan de tijd, waarop de feitelijke mutatie in U-DPS plaatsvindt,
gebruiken/invoeren.
De tijd bij 'datum 1e uitslag' en bij 'datum uitslag' zal gevuld worden door de koppeling- en
printprogrammatuur. Bij verouderde lokale PQL programmatuur wordt dit niet ondersteund. De
tijdnotatie zal dan leeg blijven. Al geruime tijd heeft brightONE de laboratoria verzocht deze PQL
programmatuur te laten vervangen door de huidige Ruby programmatuur.
Kern-U-DPS / Systemen X: Momenteel is er in het Kern-U-DPS nog een gebruiksdoel voor het vastleggen
van de tijd bij genoemde rubrieken. Systemen X hoeven daarom geen aanpassing te doen.
Het Kern-U-DPS zal echter wel worden voorzien van de aanvullende tijd rubrieken om voor de toekomst
te beschikken over de mogelijkheid deze gegevens van Systemen X te ontvangen en vast te leggen. In de
Palga Frontend Controle Module (PFCM) worden bij datum rubrieken geen extra controles uitgevoerd
waarin ‘tijd’ een rol speelt.
RFC 97-149: Retrieval termen in U-DPS
Dit betreft een verzoek van St. PALGA om de zoekpatronen van de Retrievaltermen, zoals afgeleid van
de uitgave “Thesaurus Coderen 2008”, als aanvulling op de ‘Vragen’ functionaliteit te ondersteunen.
De Thesaurus commissie van St. PALGA is de inhoudelijke beheerder van deze Retrievaltermen. Dit biedt
de gebruikers een gemakkelijke manier om op uniforme wijze lokaal deze ‘SNOMED zoekpatronen’ te
gebruiken op de PALGA codes en kan daardoor een ontlasting zijn voor de PALGA onderzoekers ten
aanzien van de Landelijke zoekvragen. De PALGA codes zijn vanaf het jaar 2000 toegevoegd aan de
rapporten in U-DPS. Bij rapporten voorafgaand aan het jaar 2000 ontbreken de PALGA codes veelal en
zal het zoeken met deze Retrievaltermen geen selectie opleveren.
Aan het selectiescherm is nu een keuzelijst met de Retrievaltermen toegevoegd. De Retrievaltermen zijn
te gebruiken als u zoekt op ‘snomeddiag’ (alle snomeddiag regels) of op de afzonderlijke snomediag
regels 1-12.
Tevens zijn aan de keuzelijst toegevoegd:
Punt (.)
Als wildcard dat er ‘iets’ in de rubriek moet staan (omgekeerde van ‘leeg’)
^$
Als wildcard dat de rubriek ‘leeg’ is (omgekeerde van ‘iets’).
Overige aanpassingen
Het (F4) keuze scherm bij ‘Code Aanvrager’ verdween bij sommige gebruikers deels onder de
Windows taakbalk. Nu wordt dit scherm standaard gecentreerd op het scherm
Bij het activeren van een Link, naar een lokaal rapport in de View, wordt nu ook de lay-out van de
nieuwe U-DPS Webpagina’s gebruikt.
Bij de introductie van het nieuwe font bleek dat sommige 3 lettercodes van pathologen, assistenten
etc. niet helemaal getoond werden omdat de letters niet allemaal even groot zijn (proportioneel
font). De 3 lettercodes worden nu wel geheel getoond.
In verband met de nieuwe software voor de Palga Protocol Module is in de View een knop ‘Ververs’
toegevoegd.
Omdat de Protocol gegevens met deze software niet automatisch in het U-DPS worden getoond
moet na het ‘Verzenden’ van een afgerond protocol de sessie in U-DPS ververst worden om de van
het protocol afgeleide gegevens te tonen.

Download Report