eRAD PACS Kiszolgáló
eRAD PACS Kiszolgáló
Két további oszlop érhető el az Egyéb listák oldalon, amelyek megjelenítik a szűrővel meghatározott műveletek számát (¬# műveletek) és a lista létrehozásának vagy utolsó módosításának dátumát és időpontját (Utolsó módosítás dátuma). Egy adott művelettípus szűréséhez hívja elő a környezetfüggő menüt a szűrő területén, és válassza ki a Művelettípusokat a művelettípus szűrőelemének megjelenítéséhez. Válassza ki a listáról a megfelelő művelettípust, és alkalmazza azt.
Webszolgáltatási kliensalkalmazások használhatják a monitor parancsot rendszerfigyelési metrikák, például a feladatsorban lévő feladatok számának lekérdezésére.
A webes nézegető egy mini panelt támogat. A funkció alapértelmezés szerint ki van kapcsolva. A bekapcsolásához válassza ki a mini panel eszközt a beállítások panelen. Engedélyezés esetén a sorozat nézet el van rejtve, a képterület üres képkockákká válik, és a vizsgálat sorozatai vízszintesen egy sorban a kockaterület tetején vagy függőlegesen a kockaterület bal oldalán jelennek meg. A mini panel egy vizsgálat fejlécet tartalmaz, amely a vizsgálat azonosítási adatait tartalmazza, melyeket az egyes sorozatok követnek. Ha több vizsgálat is létezik a webes nézegető munkamenetében, azok egymás után következnek a mini panelen. A felhasználók a mini panelről egy képkockába húzhatják a sorozatot.
A webszolgáltatások könyvtára tartalmaz egy parancsot, amely lehetővé teszi egy melléklet feltöltését egy meglévő vizsgálathoz. A részletekért lásd az eRAD PACS Web Services Programozói kézikönyvet. A támogatott fájltípusok közé a JPG, BMP, TIF és PNG tartozik. A rendszer ugyanúgy reagál, mintha a fájlt a grafikus felhasználói felület alapú feltöltő eszközzel töltötték volna fel.
Az importdevices.sh import eszköz két további opcióval bővült. A frissítési opció, -u, felülírja a meglévő eszközbejegyzéseket az adatfájlban levő adatokkal. A duplikált AE opció, -a, elnyomja a duplikált AE cím figyelmeztetését és importálja az eszközt. Vegye figyelembe, hogy a duplikált bejegyzést a rendszergazdának manuálisan kell megoldania az import befejezése után.
Az Egyéb listák oldalon található listaméret oszlopot a lekérdezés minősítő nem tudta ellenőrizni, és ennek eredményeként költséges lekérdezéseket okozott. A rossz lekérdezések kiküszöbölése érdekében az oszlop eltávolításra került. A szűrőnek megfelelő vizsgálatok számának megjelenítése érdekében bontsa ki a szűrő sorát a lista részleteinek megtekintéséhez. Vegye figyelembe, hogy ha a lekérdezés nem felel meg a minősítő kritériumainak, és a felhasználónak nincs Korlátozott lekérdezési jogosultsága, az Elemszám mező N/A-t mutat a lista mérete helyett.
A webszolgáltatások törlési értesítési üzenete tartalmazza a betegazonosítót és a teljesítési azonosítót. A részletekért lásd az eRAD PACS Web Services Programozói kézikönyvet.
Az adminisztrátorok értesítést kapnak gyenge jelszó hashsel rendelkező felhasználói fiókok esetén. Az érintett fiókok használható listájához adja hozzá a Gyenge Jelszó oszlopot a felhasználói fiókok oldalhoz, és szűrje a valós bejegyzéseket.
Az adminisztrátorok relatív prioritásokat rendelhetnek a feladatokhoz, amelyeket akkor hoznak létre, amikor adatokat szereznek be adott (regisztrált) DICOM eszközökből. A DICOM eszköz konfigurációs oldala tartalmaz egy Feladat relatív prioritás beállítást a bejövő és kimenő feladatokhoz. Az adatok beszerzésekor a keletkező feladatok bejövő prioritást kapnak. Manuális és művelet által kezdeményezett továbbítások a kimenő prioritást alkalmazzák. Vegye figyelembe, hogy az automatikus továbbítások a bejövő eszköz prioritását alkalmazzák a továbbítási feladatra, nem pedig a kimenő eszköz prioritását.
A szolgáltatások monitor script futása közben történő leállítása esetén előforduló elakadt zárolások elkerülése érdekében a monitor script egy zároló fájlt keres, és ha jelen van, ellenőrzi, hogy a folyamat, amely zárolta, még mindig fut-e. Ha nem fut, a monitor folyamata törli a zárolást és folytatja a végrehajtást.
Az RIS-hez a technikus nézet oldaláról újraküldött leletek és kiegészítések a létrehozás sorrendjében kerülnek felsorolásra. Ha az elküldés egy objektumnál sikertelen és újrapróbálkozásra kerül, a leletek rendellenes sorrendben érkezhetnek. Az eszköz kimenő üzeneteinek konfigurációs oldalán létezik egy Leletek együttes küldése lehetőség. Kiválasztás esetén az összes leletkomponens egyetlen értesítési üzenetben kerül küldésre. A részletekért lásd az új AllReportsNotification értesítési üzenetet az eRAD PACS Web Services Programozói kézikönyvben.
Amikor nem léteznek modalitásspecifikus objektumok, a rendszer minden másodlagos képrögzítési objektumot, az egyképes és többképes objektumokat is beleértve, figyelembe vesz a minimális SOP példány kiválasztásánál.
Amikor a rendszer SQL tranzakció visszagörgetési kivételt észlel, az eseményt naplózza, a próbálkozások száma 20-ra emelkedik, és az alvási idő véletlenszerűvé válik az ütközések elkerülése érdekében.
FRISSÍTÉSI ÉRTESÍTÉS: A frissítések érintik a meglévő adatokat. A részleteket lásd lent.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: Bizonyos módosítások felülvizsgálatot igényelnek ezen build eltávolítása esetén.
Egy vizsgálatlekérdezési kérelem válaszüzenetei tartalmaznak egy mezőt, amely jelzi, hogy a vizsgálat egyetlen kapcsolódáson vagy több kapcsolódáson található-e. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: Eltávolítás esetén ha a Továbbítás szerepkör hozzárendelése konfigurálva van, azt manuálisan kell eltávolítani.
Bevezetésre került egy Továbbítás szerepkör. A Továbbítás szerepkörrel rendelkező kiszolgáló felel minden továbbítási feladatért a kérelem forrásától függetlenül, a kézi továbbításokat, az automatikus továbbításokat, a továbbítási műveleteket, az eszközök automatikus továbbításait stb. is beleértve, a DICOM lekérési kérelemre adott válaszként kezdeményezett továbbítások kivételével. Csak egy farmkiszolgáló rendelhető a Továbbítás szerepkörhöz. Alapértelmezés szerint a szerepkör az Alkalmazásszerverhez van rendelve.
Az Adminok leállíthatják egy farm regisztrációját vagy átviteli kiszolgálóját az Admin/Eszközök/Farm oldalon. Egy kiszolgáló határozatlan ideig vagy meghatározott időtartamra leállítható. A leállított szerverek aktívak maradnak, de a terheléselosztó nem irányít rájuk forgalmat.
Egy nézegető kliens utasíthatja a kiszolgálót arra, hogy a teljes felbontású képek helyett alacsony felbontású, kezdeti minőségű képeket küldjön vissza a QA token használatával a nyitott parancsban. A részleteket a nézegető felületének fejlesztői kézikönyvében találja. A munkamenet opcionálisan úgy is konfigurálható, hogy mindig az eredeti minőségű képet adja vissza, ha a SESSIONLSY mezőt a munkamenet táblában „1”-re állítják.
Egy új webszolgáltatás-parancs, a Get PS Object áll rendelkezésre, amely az eRAD PACS prezentációs állapot adatokat DICOM-konformitási objektumokká alakítja és letölti őket. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben. Emellett egy convPS elnevezésű parancssori eszköz is elérhető ugyanazon átalakítás elvégzéséhez.
A fennmaradó közvetlen SQL lekérdezések átalakításra kerültek a SmartPreparedStatement használatára, ezek a lekérdezések pedig újrafelhasználásra lettek optimalizálva.
A rendszergazdának lehetősége van a személynévszűrő beállítására. A funkció a mezőcímke konfigurációs oldalán konfigurálható. Az alapértelmezett személynévszűrőt a Személynévszűrő használata beállítás határozza meg az Admin/Szerverbeállítások/Adatformátumok oldalon. Alapértelmezés szerint Egyszerű, ami egy kétértékű (keresztnév + vezetéknév) nevet jelent. Amikor a beállítás Nincs, a nevek szabad szöveges mezők. A Teljes érték az ötmezős DICOM-kompatibilis névformátumot használja. A névformátum-beállítások külön-külön hozzárendelhetők az egyes névmezőkhöz a Címke testreszabása konfigurációs oldalról.
RENDSZERKÖVETELMÉNYEK: A optimalizáció alkalmazásához átvételi módban az origin szervernek 7.2 medley-102 vagy újabb verziót kell futtatnia.
Ez az a féregjárat-alapú megoldás, amely szükséges egy vizsgálat helyének keresésekor a több kapcsolódási ponton történő felesleges keresések kiküszöböléséhez. Elnyomja a vizsgálat- és kéréslétrehozási üzeneteket a tárolókezelő szintjén, és adatok átvitelekor a kapcsolódási helyet belefoglalja a féregjárat üzenetbe, így a Replica kiszolgálónak nem kell az összes kapcsolódási helyet átkutatnia.
Minden jegyzet egyetlen zárolási mechanizmus révén volt kezelve, annak ellenére, hogy a jegyzetek egyetlen vizsgálathoz tartoznak. A betegdossziéban található jegyzetek hozzáadásában, törlésében és visszakeresésében fellépő késedelmek megszüntetése érdekében minden vizsgálat saját jegyzetzárolási mechanizmust kezel.
Amikor egy tároló Hitelesítő módban fut. a koszos és hibás (azaz több hubos) vizsgálatok nem tisztíthatók meg automatikusan. Ezek a vizsgálatok koszosként vannak jelölve, így manuálisan azonosíthatók és megtisztíthatók, majd az eredeti vizsgálati mappa visszakerül a hívóhoz.
A vizsgálat tisztító eszköz hatékonysága javult azáltal, hogy a meglévő feladatok szűrése a vizsgálat UID-jának használatával történik az összes feladat kapcsolódó elemeinek ellenőrzése helyett.
A beépített alapértelmezett beállítás a törlések terjesztésére a több hub tisztító eszköz használatakor megváltozott, hogy a dotcom kiszolgálókra menjen, de ne az archívumokba. A Propagálja a törlést a forrás hubról beállítás a Kiszolgáló beállítások/Több hub tisztítás oldalon módosítható.
Az info.log és error.log fájlok naplórotációs ideje 30 napra változott. A LogRotateDays beállítás a ~/var/conf/self.rec fájlban konfigurálható. Vegye figyelembe, hogy a naplókat tartalmazó „week” (hét) nevű almappa változatlan marad, még akkor is, ha a rotációs idő nem hét nap.
A felhasználók törölhetnek sorozatokat a dotcomon keresztül, és lehetővé tehetik ezek újraküldését a kiszolgálóra (azaz használhatják az „azonnali törlés” funkciót), ha a Kiszolgáló beállítások/Vizsgálatműveletek oldalon a Törlés mód beállítás Azonnal törlésre van állítva.
A callback hook funkció helyreállításra került. A beállítások a Kiszolgáló beállítások/Callback Hook-ok regisztálása oldalon érhetők el. Az adminisztrátorok meghatározhatnak egy URL-t, amelyet egy megfelelő vizsgálati naplóesemény esetén hívni kell.
Egy új dotcom szerver példányosításakor használja a ~/var/conf/actionConvert.conf fájlt az IP-címek meghatározásához azon szerverek esetében, amelyek műveleteit át kell másolni. Ez lehetővé teszi, hogy az exportált felhasználók megtartsák a konfigurált műveleteiket az import után. A konfigurációs fájlban nem felsorolt IP-k és azonosítók megőrzik eredeti serverid-értéküket és letiltásra kerülnek.
A felhasználók törölhetnek egy kiválasztott képet a dotcomon keresztül, és újraküldhetik a szerverre (azaz használhatják az „azonnali törlés” funkciót), ha bejelölik az „Azonnali” négyzetet a megerősítő panelen, amely a kép Technikus nézet oldalról való törlésekor jelenik meg.
A rendszermemória erőforrásbeállítása törölve a Dcreg feladatokból, és hozzáadva az MCS prepareObject feladatokhoz és a többképes ultrahangos objektumokhoz.
Egy új munkalista eszköz érhető el, amely elindítja a folyamaton belüli webes nézegetőt. Ez az eszköz csak akkor érhető el, ha a webes nézegető csomag telepítve van a szerveren. Ez a funkció kizárólag tesztelési célokra szolgál, és kiürítésre kerül a webes nézegető tesztelésének befejezésével.
További naplózási funkciók kerültek hozzáadásra a blob létrehozásával kapcsolatos részletek rögzítéséhez.
A PDF fájlokként tárolt mellékletek bemutatása, különösen a betegdossziéban, sikertelen lehetett, mert a szoftver elvárta, hogy a fájl kiterjesztése megegyezzen a kódoldal URL-jével. Egy servlet hozzáadásra került a PDF-fájlok megfelelő támogatásához.
A technikus nézet oldala frissült, hogy a web kliens SDK-t használja, amely a keretadatokat streaming protokollok segítségével továbbítja, nem pedig HTTP protokollokkal.
Ha kulcsképek léteznek egy vizsgálatban, a részletek szerepelnek a GetStudyDataResponseMsg jelentés ReportData részében, egy leképezett kulcsképet visszaadó URL-t is beleértve. A részletes leírást az eRAD PACS Web Services Programozói kézikönyv tartalmazza.
A kulcsképek határozatlan ideig a feldolgozott tárolóban kerülnek tárolásra, hogy ne kelljen a teljes vizsgálatot újramelegíteni, ha egy kliensalkalmazás kérelmezi őket, vagy megjeleníti egy leletben.
A monitor oldal frissült, hogy fogadja az adatokat a kiszolgálótól, és megrajzolja a grafikont/diagramot a böngészőben. Egy grafikon/diagram létrehozásakor egy folyamatjelző sáv jelenik meg az adatterület tetején.
Amikor a lelet oldal elindításra kerül a nézegető vagy a böngésző oldal számára, a kiszolgáló összegyűjti és elküldi a leletsablonok listáját, nem pedig az összes sablonfájlt. A teljes leletsablon igény szerint letöltődik a lelet oldalának betöltésekor.
A listák letöltése, a munkalista táblázatból, a fiókok táblázatából, a napló táblázatból stb. származókat is beleértve, aszinkron módon készülnek el, és értesítik a felhasználót, amikor az adatok letöltésre készen állnak. A letöltés gombot tartalmazó állapotpanel a munkamenet menü mellett jelenik meg.
A nézegető minden életben tartó üzenetben elküldi a verziószámát a kiszolgáló felé. A kiszolgáló összehasonlítja a felhasználó által beállított nézegető verzióval, és értesíti a nézegetőt, ha eltérést észlel.
A felhasználó profilbeállítási oldalán felsorolt nézegető verziók verziószám szerint vannak rendezve, így a nézegető azonosíthatja a legújabb buildet.
A média exportálás állapotpanelje megjeleníti az egyes exportálási munkákhoz tartozó beteg- és vizsgálati azonosítókat.
A több hub kiszolgálón található vizsgálatok javítására szolgáló Vizsgálat tisztító eszköz mostantól elérhető a rendszergazdai jogosultsággal rendelkező felhasználók számára.
A webes nézegető kezeli a memóriahasználatát, hogy megakadályozza a szükségesnél nagyobb memóriafogyasztást vagy a rendelkezésre álló memória kimerítését. Amikor a betöltött adatok mennyisége meghaladja a maximális értéket (512MB), a rendszer elkezdi felszabadítani a memóriát. A rendszer szükség esetén újra letölti az érintett képeket.
A webes nézegető rögzített ütemben frissíti a képeket, de bizonyos környezetekben, különösen a CITRIX-ben, ha a feldolgozást a CPU végezte, nem pedig a GPU, ez felesleges tevékenységgel terhelheti a CPU-t. Ez úgy lett módosítva, hogy a képek csak akkor frissüljenek, amikor animáció vagy egéresemény történik.
Egy vizsgálat felmelegítésére irányuló felhasználói kérelmeket a művelet naplófájlja (és az adatbázis) rögzíti. Ezenkívül a felmelegítési naplóbejegyzések elérhetők a megfigyelő eszközök számára, és megjeleníthetők a rendszerfigyelő oldalon (ha az tartalmaz regisztrációs kiszolgálókat).
Amikor a felhasználók iframe és script adatokat tartalmazó szöveget illesztenek be, a rendszer félreértelmezheti. Ez az információ eltávolításra kerül a lelet panelbe illesztett adatokból.
Az intracom keretrendszer frissítésre került, hogy a feladat kontextusát is magába foglalja a hívások során, így amikor a célkiszolgáló a hívó kiszolgáló, a feladatot össze lehet csoportosítani a kapcsolódó feladatokkal.
Ha az adatbázis nem válaszol, az újrapróbálkozási sorból származó feladatok elárvult állapotba kerülhetnek, és soha nem fejeződnek be. Ezek a feladatszálak most már alvó állapotba kerülnek, hogy újraindíthatók legyenek az adatbázis szolgáltatás helyreállítása után.
Amikor egy felhasználó ismételten ugyanazokból az adatokból álló továbbítási kérelmet küld, a kérelmek egyetlen feladattá vonódnak össze és csak egyszer kerülnek végrehajtásra.
Kiegészítő naplózási lehetőségek kerültek bevezetésre a főzési és újramelegítési tevékenységek nyomon követésére, az aktív vizsgálati objektumok kiürítését is beleértve.
Amikor egy DICOM C-FIND kérés sorozatszintű attribútumokat tartalmaz egy vizsgálatszintű keresés során vagy képszintű attribútumokat egy vizsgálat- vagy sorozatszintű keresés során, ahogyan azt a Lekérdezési szint attribútum meghatározza, a kiszolgáló ezeket figyelmen kívül hagyja, ahelyett hogy érvénytelen C-FIND kérést jelentene.
A fennmaradó közvetlen SQL lekérdezések átalakításra kerültek a SmartPreparedStatement használatára, ezek a lekérdezések pedig újrafelhasználásra lettek optimalizálva.
Az összes kiszolgáló egy kiszolgálófarmban egyetlen licencre hivatkozik, amely az alkalmazáskiszolgálón van elhelyezve. Ha egy kiszolgáló nem fér hozzá az alkalmazáskiszolgálóhoz, vagy ha nincs kifejezetten meghatározott alkalmazáskiszolgáló, a szoftver nem fog működni. További licencelési hibák és figyelmeztetések a licencgenerálási kézikönyvben találhatók.
Amikor a gyorsítótár tárhelye törölhető, van egy konfigurációs opció, az isClearableMove, amely lehetővé teszi az adatok áthelyezésének engedélyezését és letiltását. Amikor „hamis” (alapértelmezett), az áthelyezések nem történnek meg a checkOverload során. Az adatok ehelyett törlődnek. Részletek a tárkezelő kézikönyvében találhatók.
A herelo és herelod által használt tömörítés megváltozott, hogy a platform openjpeg példányát használja.
A lemezfigyelő eszközök képesek felügyelni az összes meghajtó és partíció használatát, amelyeken a rendszer adatai találhatók. A monitorozás grafikus felhasználói felügyeletének opcióit a kapcsolódás címkéje határozza meg.
A szükségtelen többletterhelés elkerülése érdekében a helyi, megbízható csatolások kezeléséhez használja a nyers tárkezelőt a fejlett tárkezelő (StudyRepositoryWrapper) helyett. Nyers mód használatakor egy futásidő figyelmeztetés kerül naplózásra.
A kötőjel karakter elfogadásra került támogatott karakterként a felhasználói, csoport, LDAP és dokumentumtípus azonosítók számára.
A qst.sh sorállapot eszköz tartalmaz egy opciót, a running parancsot, amely megjeleníti a futó feladatok adatait.
A befejezett kérések megnyithatók a munkalistából a fő és webes nézegetőkben.
Egy független memóriaerőforrás áll rendelkezésre a memóriaigényes feladatok egyidejű számának korlátozására, az ObjectForward, Dcreg és DcCompressDataTask feladatokat is beleértve. Ez a „BT” betűkkel kezdődő objektumokra vonatkozik. A beállítás a component/taskd/resources.cfg fájlban található System.MEM. Az alapértelmezett érték három.
Az ImportStudies webszolgáltatás egy Origin kiszolgálóról fogadott adatok regisztrálására szolgál. A szolgáltatás létrehozza a vizsgálatok és leletek rekordnyilvántartásait, létrehozza az objektum- vagy metaadatbázis-rekordokat, frissíti a hivatkozásszámlálókat, indexeli a tároló helyét az adatbázisban, és naplózza a tevékenységet.
A manuális lekérési kérelmek és a lekérési művelet konfigurációs oldala tartalmaz egy lehetőséget a rendszer helyi másolatok ellenőrzésének felülírására. A beállítás alapértelmezés szerint ki van kapcsolva. Kiválasztás esetén az egész vizsgálat lekérésre kerül, felülírva a helyi fájlokat, ha jelen vannak.
Az átvitel naplózása továbbfejlesztésre került, hogy tartalmazza az egy szál érintett kapcsolatának/munkamenetének létrehozásához használt információkat. Az átvitel naplózási szintje emellett konfigurálható. A LogLevel naplózási szint az átviteli kiszolgáló konfigurációs fájljában van meghatározva, ~/var/conf/streamserver.conf.
Az exportált eszközadatok importálhatók azonos vagy későbbi verziókat futtató rendszerek által.
Az Origin kiszolgáló értesíti a Replica kiszolgálót a koszos vizsgálatokról, például a több hub kiszolgálón létező hibás vizsgálatokról, hogy a Replica megfelelően azonosíthassa és nyugtázhassa azokat.
A monitor oldalon megjelenített feladatsor méretinformáció különválasztja a kritikus feladatokat (azokat, amelyek prioritása kisebb vagy egyenlő 200-zal) a nem kritikus feladatoktól. Az új mező címkék: Feladatsor kritikus (újrapróbálkozás, ütemezett) és Feladatsor meghiúsult kritikus.
A diagnosztikai szoftver frissítéseinek részeként egy felsorolt mező értékének nem megfelelő jelölése megváltozott: a piros, áthúzott szöveget narancssárga, szaggatott vonallal aláhúzott szöveg váltotta fel.
A feladatkezelési naplóbejegyzések áthelyezésre kerültek az információs naplóból a var/log/javataskd.log taskd naplófájlba.
A monitor oldal közvetlen hozzáférési URL-je megszűntetésre került. A monitor oldal elérése a grafikus felhasználói felület Admin/Kiszolgáló információ/Monitor menüpontjából.
A Feladatok oldal tartalmazza az egyes sorokhoz tartozó feladatok összesített számát, és zárójelben megjeleníti azok számát, amelyek kritikus prioritási értéket kaptak (azaz 200 vagy annál kisebb).
A rehearStudies.sh vizsgálat felmelegítési szkript egy -c opciót tartalmaz, amely lehetővé teszi a hideg vizsgálatok bevonását a felmelegítési műveletbe.
A rendszergazdák számított mezőket hozhatnak létre a felhasználói fiók oldalon történő használatra.
Egy beépített számított mező érhető el a felhasználói fiók táblázatban az utolsó rendszerhozzáférés dátumának és időpontjának megjelenítéséhez. A mező neve Utoljára megtekintett.
A felfüggesztett feladatok újraütemezésére szolgáló szkript, a rescheduleSuspendedTasksDbase.sh, már figyelembe veszi a feldolgozatlan feladatfájlokat és a feldolgozatlan adatbázis feladatokat a felfüggesztett feladatok visszaállítása során.
A kortalanítás folyamat vizsgálatra történő alkalmazása esetén a rendszer előkészíti azt a használatra azzal, hogy létrehozza a szükséges gyorsítótárat és feldolgozott adatokat.
Egy adatbázis index került hozzáadásra a USERID mezőhöz, mivel a mező számos adatbázis-lekérdezésben szerepel.
Az egyetlen mappába sem tartozó vizsgálatok kiszűrése különleges eset. A mappa mező indexét nem szabad más esetekben használni, mert nagyon kevés vizsgálat tartozik mappákhoz.
A taskd Java VM számára elérhető memória konfigurálható. A paraméter TASKDJAVA_MAXMEMORY a ~/var/conf/taskdjava.cfg fájlban. Az alapértelmezett érték 3GB.
A felhasználói és csoport-hozzáférési listák számos adatbázis-lekérdezésben szerepelnek (egy kérelem végrehajtása előtti engedélyek keresésekor), de ritkán változnak. A hozzáférési lista és az összetett lista allistáinak tartalma mostantól öt másodpercig gyorsítótárazva van, így gyors hozzáférést biztosítva minimális vagy semmilyen hatással az adatbázisra.
A 3. szintű tárhely kevés teljesítménykövetelményt támaszt, ezért lassú lehet. Az átviteli kiszolgáló a 3. szintű tárolón keresztül érte el az adatokat (pl. metaadatok, jelentések) egy streaming kérelem indításakor. Ez a hozzáférés késleltette az adat streaming indítását. A rendszer már ellenőrzi, hogy létezik-e ez az adat a gyorsítótárban, amely általában gyors tárhely, mielőtt hozzáférne a 3. szintű eszközön.
A felhasználó hideg vagy befagyasztott vizsgálat megnyitására irányuló kérésből eredő újramelegítési kérelmek az újramelegítési (feldolgozási) sor elejére kerülnek, és az összes rendelkezésre álló farmkiszolgálót igénybe veszik.
A frissített kódaláíró tanúsítványoktárolása a szerveren történik, és kérésre elérhetővé válik a nézegető számára.
A sorban álló feladat utolsó módosításának idejét a feladatadatbázis nyomon követi, és elérhető a rendszerkomponensek számára.
A checkoverload futtatásakor ellenőrzött erőforrásfájlok száma az info.log fájlban szerepel.
Teljesítménymérce felállításához a túlterhelés-ellenőrzési folyamat minden 1000 hashelt mappa után időbélyeggel ellátott bejegyzést hoz létre az info.log fájlban.
A teljesítmény növelése érdekében végzett fejlesztések közé tartozik az adatbázis-kapcsolat és az előkészített állítások újrafelhasználása, egy nagyobb puffer használata pufferelt írással, valamint értékelési naplóbejegyzések hozzáadása.
Az új adatbázis-kapcsolatok létrehozásával járó felesleges terhelés elkerülése érdekében a meglévő adatbáziskapcsolat továbbításra kerül a tárkezelőhöz, storestate.rec fájlok létrehozásakor a meta tárolóhelyen.
Az Origin kiszolgálóról importált vizsgálatok több szálon kerülnek feldolgozásra. A szálak számát a NumThreads határozza meg a ~/shared/var/wormhole/import.cfg fájlban. Az alapértelmezett beállítás négy szál Origin (hub) kiszolgálónként. Egy konfigurálható beállítás is rendelkezésre áll a közös adatbázis-kapcsolat használatára, a UseCommonConnection. Az alapértelmezett érték igaz.
Egy rendellenesség a boost könyvtárban (Rocky-n való futtatás esetén) nem jelentett kivételt, amikor a szoftver nem tudta elérni a meta könyvtárat, ami tomcat összeomlásokat eredményezett. Ehelyett a rendszerkönyvtár megfelelő hívása kerül alkalmazásra.
A Replica kiszolgáló tájékoztatást kap arról, hogy az adatok hol találhatók (az Origin kiszolgáló által), ezért nem kell megkísérelnie az adattároló helyének felderítését.
Adatátvétel módban az automatikus javítást az Origin kiszolgáló végzi. A késői javítási cron feladat letiltásra került egy Replica szerveren.
Teljes újraindexelésre csak akkor kerül sor egy befagyasztott vizsgálatnál, ha a vizsgálat- és az objektumtáblázat, valamint az adatkönyvtárban található fájlok nincsenek szinkronban. Más esetekben, például új objektumok érkezésekor újrafeldolgzás kerül végrehajtásra.
A teljesítmény optimalizálása érdekében az adatok adatfájlból (blob) adatbázisba történő betöltése egyetlen kérésben kerül végrehajtásra egy előkészített utasítás segítségével.
Miniatűr képek kérésekor (azaz kockakérelmek fogadásakor) egy hideg vagy befagyasztott vizsgálathoz, az újramelegítés automatikusan elindul. A kérelem blokkolva lesz mindaddig, amíg az újramelegítés be nem fejeződik és a képek elérhetővé nem válnak. Ha a főzés tovább tart, mint a kérelem időtúllépése, vagy ha a blob a kérelem kiadásának időpontjában nem teljes, nem kerülnek visszaadásra képek.
A getStreamServer() webszolgáltatási parancs áll rendelkezésre annak meghatározására, hogy melyik átviteli kiszolgálóhoz kell csatlakoznia egy kliens alkalmazásnak a képadatok letöltéséhez. A részletekért lásd az eRAD PACS Web Services Programozói kézikönyvet.
Az átviteli kiszolgáló, ~/var/log/streaminfo.log naplója tartalmazza az átviteli és fogadási metrikákat, amelyeket a monitorozó eszközök használnak a streaming statisztikák nyomon követésére.
A felügyeleti eszközök az alkalmazáskiszolgáló Admin/Kiszolgáló információk oldalán érhetők el azok számára, akik rendelkeznek Admin vagy Támogatás jogosultságokkal.
Támogatás került hozzáadásra az Origin és Replica módokhoz. Egy Origin kiszolgáló megosztja az adatok/DICOM-tároló(k) állapotát egy Replica szerverrel saját értesítések használatával, formális kommunikációs mechanizmusok (például DICOM továbbítások) helyett. Értesítések érhetők el a vizsgálat tárhelyének megosztására, az objektumok létrehozásának és törlésének jelzésére, valamint az adattároló tevékenységének közvetítésére. Támogatást tartalmaz új Origin és Replica eszköztípusokhoz. Az eszköz Ping parancsának használata annak ellenőrzésére, hogy az Origin vagy a Replica eszköz elérhető-e, és be van-e állítva a kiszolgáló felismerésére. Az Origin mód engedélyezéséhez állítsa be az Origin attribútumot a ~/var/conf/self.rec fájlban, majd indítsa újra a medsrv alkalmazást. A Replica mód engedélyezéséhez állítsa be a Replica attribútumot a ~/var/conf/self.rec fájlban, majd indítsa újra a medsrv szolgáltatást.
Tárolókezelő támogatás hozzáadva az Origin és Replica módokhoz, ahol az alapvető tárolókezelő értesíti a Replica alapvető tárolókezelőjét a változtatások esetén.
Támogatás hozzáadva a DICOM továbbítási kérelmekhez, amelyeket bármilyen tevékenység indít az Origin eszközön, a felhasználó vagy a rendszer által végrehajtott megszerzést, szerkesztést vagy törlést is beleértve, hogy értesítést küldjön a megosztott DICOM tárolóról, amelyen az adatok találhatók, a Replica eszközre ahelyett, hogy DICOM továbbítást kezdeményezne. Ezenkívül egy Origin eszköz képes elfogadni és feldolgozni a Replica eszköz által küldött szerkesztési és törlési frissítéseket. A legtöbb esetben az Origin eszköz végzi el a műveletet, majd értesíti a Replica eszközt, hogy alkalmazza ugyanazt a változtatást.
A felügyeleti eszközök magukban foglalják a gyorsítótár, az adatok, a feldolgozott és egyéb tárolókezelési tevékenységek (mozgatások, törlések) megjelenítését.
A monitoring eszközök tartalmazzák a használt MySQL kapcsolatok százalékos arányának megjelenítését.
A reheatStudies.sh szkript már nem jelenti az elavult illesztőprogram-osztályok figyelmeztetéseit.
Bizonyos fejlesztések történtek a farm érvényesítőn, a megosztott adattárolók csatolását, valamint az adattár gyökerének ellenőrzését is beleértve; a gyorsítótár, az adatok, a metaadatok, az ideiglenes adatok, a feldolgozott adatok, a felhasználói és megosztott mappák ellenőrzése csak a vonatkozó farmkiszolgálókon történik; a hibaüzenetek az alkalmazáskiszolgáló rc.log fájljában kerülnek jelentésre; az adattároló megosztása nem kerül ellenőrzésre a Replica módban futó kiszolgálókon; a megosztott mappa hibaüzenetei pedig ezt a részletet jelzik, ahelyett hogy általános leírást használnának.
FRISSÍTÉSI ÉRTESÍTÉS: A meglévő Utófeldolgozási műveletek, ha vannak ilyenek, letiltásra kerülnek az action.jsp futásakor. Mivel az előletöltés megszűnt, az utófeldolgozási művelet szükségtelenné vált. Ez is megszűnt. Egy új, Vizsgálat előkészítése érhető el egy vizsgálat újrafeldolgozásához. A vonatkozó műveleti beállítások elérhetők a Vizsgálat előkészítése konfigurációs oldalon, amely az Egyéb listák táblázatból érhető el. A művelet futásakor, a részletek az információs naplóban kerülnek rögzítésre.
Amikor az adatbázis nem érhető el, a rendszer nem feltételezi, hogy a kapcsolódás elérhetetlen, és nem kezd el halott mappákat létrehozni.
A főzött állapot akkor érvényes, amikor az összes objektum, amelyet bármelyik regisztrációs szerveren szereztek meg, feldolgozásra került. Amikor egyetlen regisztrációs kiszolgáló befejezi a feldolgozást, és észleli, hogy egy másik regisztrációs kiszolgálónak feldolgozatlan objektumai vannak, a vizsgálat feldolgozási állapota Részlegesre állítódik.
A tárolókezelő a meglévő adatbázis-hozzáférési lehetőségeket használja, hogy elkerülje új kapcsolatok létrehozását és bezárását az adatbázishoz minden alkalommal, amikor a túlterhelés-ellenőrző funkció ellenőrzi a tárolókezelő koszos állapotát.
Egy Origin vagy Replica eszköz meghatározásakor a Szolgáltatás felhasználó beállítás megadása kötelező.
Egy token használható annak jelzésére, hogy a hitelesítő adatok ellenőrzésre kerültek a konkrét vizsgálatokhoz való hozzáférés érdekében. A webszolgáltatások kliensei a StudyQuery parancs segítségével igényelhetik ezeket a kulcsokat. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
A webszolgáltatások felülete tartalmaz egy StudyQuery parancsot, amely támogatja az összetett lekérdezéseket, lehetővé téve egy VAGY viszonyt az oszlopmezők között és egy ÉS viszonyt az oszlopok között. Válassza ki például az összes vizsgálatot X betegazonosítóval, és Y vizsgálati dátummal. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
A webszolgáltatások felületén található egy StudyQuery parancs, amely lehetővé teszi egy vizsgálat és annak előzményeinek visszaadását, a hozzáférési korlátozásnak nem megfelelő elemeket is beleértve. Az előzmények egyedileg azonosíthatók az eredményekben kódolt csoportokban. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
A webszolgáltatások felülete vissza tudja adni a vizsgálat helyét az adattárolóban. A StudyQuery parancs tartalmazhat egy opciót a tároló helyének visszaadására. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
Amikor a webes nézegető kérésére képeket kap egy feldolgozatlan vizsgálathoz, azokat azonnal generálja egy feldolgozási esemény kezdeményezésével. Amint a képek elérhetővé válnak, azok a webes nézegetőbe kerülnek és megjelennek.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: Eltávolítás esetén az objektumtáblázat ezen funkció által kiürített bejegyzéseit előzetesen újra kell tölteni a touch script-ek manuális meghívásával. Az objektumtáblázat végtelen növekedésének és nagymennyiségű fel nem használt adat tárolásának megelőzése érdekében a rendszer kiüríti a legkevésbé használt rekordokat. Amikor objektumadatokra van szükség, a rendszer a vizsgálat metaadataiból (azaz a blobból) állítja vissza azokat menet közben. Az adatok objektumtáblázatban maradó időszakát az ObjectCacheTimeout határozza meg a ~/var/conf/self.rec fájlban. Az alapértelmezett érték 10 nap. A lejárt adatok ellenőrzése és ürítése egy óránként futó cron feladatból történik. A szkript neve CleanupObjectTable. Szükség esetén kézzel is elindítható a parancssorból.
Ez az alapvető funkciókat ellátó osztály lehetővé teszi a törölt vizsgálatok biztonságos eltávolítását a rendszerből a GUI-n keresztül. Eltávolítja a szerverfarmról egy vizsgálat minden maradványát, a tároló erőforrásokat, az adatbázis rekordokat, a feladatfájlokat, a referenciaként szolgáló számlálókat, a zárakat és az ideiglenes fájlokat is beleértve.
Kifejlesztésre és telepítésre került egy JavaScript SDK, amely lehetővé teszi a webes kliensek (böngészők) számára, hogy letöltsék és megjelenítsék a cw3 és cw4 képfájlokat. Az eszköztár részletei az eRAD PACS Web Client Image Library kézikönyvben találhatók.
A Vizsgálat tisztítás oldal tartalmazza a törölt állapotban lévő vizsgálati rekordok listáját és egy eszközt azok eltávolítására. A kibővített sor listázza a kapcsolódó tanulmányokat. Naplóbejegyzések érhetők el minden egyes vizsgálatról, amely eltávolításra került ebből a grafikus felhasználói felület funkcióból.
A beépített MySQL kapcsolati korlát 150-ről 600-ra emelkedett. Ezenkívül a kapcsolati pool mérete 32-re nőtt. A későbbi módosításokért lásd a HPS-445-öt.
A nézegető konfigurációs beállításainak címkéi a másolás beállításainak oldalán a nézegető által használt testreszabott forráscímkéket használják, így a címkék következetesek a nézegető és a weboldal között.
A web kliens SDK az epserver build folyamat részeként kerül lefordításra és csomagolásra.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: A 2048 karakternél hosszabb szűrők, amelyek ezen változtatás telepítése után jönnek létre, le lesznek rövidítve a változtatás eltávolítása esetén, ami nem kívánt eredményekhez vezethet. Korábbi verziókban a munkalisták és más listaoldalak szűrőit fájlokban tárolták, lehetővé téve a szűrőparaméterek korlátlan hosszúságát. A szűrők adatbázisba történő áthelyezése óta szűrőhossz-korlátozás van érvényben. Ez a hossz 32K-ra nőtt. Hosszabb szűrők mentési kísérlete a grafikus felhasználói felületről figyelmeztetést eredményez. A hosszabb szűrők importálásának kísérletei frissítés során csonkolást és érvénytelen eredményeket okoztak.
Ugyanazon vizsgálat több képobjektumának elérésekor a tárolócsomagoló hatékony kezelésére tervezett tárolócsomag a gyorsítótár-kezelő elérése előtt jelentős többletterheléssel (zárolás, adatbázis-hozzáférés stb.) volt terhelve. Ez a gyorsítótár-kezelés csomagoló elé helyezésével oldódott meg.
Néhány felhasználói preferencia beállítása, a munkalista lekérdezési idejét és a webes nézegető dinamikus súgócímkéit is beleértve, nem került átváltásra a jelenlegi értékekre, a rendszer V7 verzióról való frissítésekor. Észlelés esetén ezek a beállítások mostantól automatikusan a rendszer alapértelmezett értékére konvertálódnak és mentésre kerülnek. Naplóbejegyzések jelzik, hogy a rendszer elvégezte ezeket a módosításokat.
További teljesítménymetrikák kerültek hozzáadásra a rendszer teljesítményének elemzéséhez a vizsgálatok újrafeldolgozásakor.
Amikor több szál egyszerre dolgozza fel ugyanazt az objektumot, egy versenyfeltétel negatívan befolyásolhatja a teljesítményt, mert a gyorsítótár zárolása globális szinten történt, amikor azt lokalizálni lehetett (kellett) volna.
Bizonyos fejlesztések kerültek alkalmazásra az újrafeldolgozási szkripten, beleértve a jobb befejezéskezelést, a környezeti változók használatát, amikor elérhetőek, a gyorsítótár tisztítását az újrafeldolgozási folyamat megkezdése előtt, valamint a relatív prioritási hozzárendelések alkalmazását.
A ~/component/tools/validateFarm.sh szkript elérhető az összes farmkiszolgáló állapotának és konfigurációjának ellenőrzésére. Ezt a szkriptet az alkalmazásszerveren kell futtatni. Az eszköz Admin jogosultsággal rendelkező felhasználók számára elérhető a grafikus felhasználói felületen (Admin/Eszközök/Farm oldal). A kimenet felsorolja az észlelt hibákat, félrekonfigurálást és érvénytelen állapotokat. A kimenet eltér, amikor a medsrv (különösen a hypervisor szolgáltatás) minden szerveren fut, és amikor nem. Lásd a Jira kiadást, amely esetén a rendszer az ellenőrzéseket az aktuális futási állapot alapján végzi.
Eszközspecifikus kimenő kényszerítési szabályok állnak rendelkezésre a sorozatok és objektumok szűrésére az objektumok regisztrált DICOM eszközökre történő továbbításakor. A funkció a FOLYAMAT vezérlő változót használja annak jelzésére, hogy mikor álljon le egy adott objektum feldolgozása. Amikor a változó NULL() értéket vesz fel, az érintett objektumra vonatkozó (továbbítási) kérés leáll. A kihagyott objektumok azonosítása az oper_info és az oper_error naplóbejegyzésekben történik. A kimenő kényszerítési szabályok a PbR objektumok lágy szerkesztéseinek módosításai után kerülnek alkalmazásra az objektumokon. A grafikus felhasználói felületen keresztül hozzáférhető konfigurációs panelek elérhetők az Eszközök oldalain. A minden eszközre vonatkozó előzetes és utólagos kimenő szabályok az Admin/Eszközök oldalon konfigurálhatók. Eszközspecifikus kimenő szabályok konfigurálhatók egy eszköz Szerkesztés oldalán. Ezek a kényszerítési szabályok nem vonatkoznak a DICOM Retrieve (C-MOVE) kérésre válaszul kezdeményezett továbbításokra. A FOLYAMAT vezérlő változó használatával és a kényszerítési szabályok meghatározásával kapcsolatos utasításokhoz lásd az eRAD PACS adatkényszerítési kézikönyvet.
A ~/cases/reheatStudies.sh szkript minden olyan vizsgálat újrafeldolgozására (újramelegítésére) elérhető, amelyek gyorsítótárazott adatfájljainak ReceivedDateTime időbélyege egy meghatározott dátum és időpont előtt van. A kimenet felsorolja az összes vizsgálatot a gyorsítótár adattárolójában, és jelzi, hogy azok feldolgozásra vagy kihagyásra kerültek-e.
További ellenőrzések kerültek hozzáadásra annak biztosítására, hogy a V7 felhasználói fiókok V9 felhasználói fiókokká legyenek alakítva. Ez a funkció lehetővé teszi az átalakítási folyamat alkalmazását a már konvertált fiókokra is, ha az szükséges. Távolítsa el a felhasználói fiókot az adatbázisból, és a fiók fájljai újra feldolgozásra kerülnek, amikor a felhasználó ismét bejelentkezik.
A hdclient eszköz új argumentummal rendelkezik, -s, amely számítógép által olvasható formátumban hoz létre kimenetet.
Ahhoz, hogy a nézegető hitelesítse a felhasználó munkamenetét, az átviteli kiszolgáló átadja neki a munkamenet azonosítóját.
Bármely a konfigurálható időtartamon belül tárolt tanulmány kiüríthetőnek számít az ütemezett (éjszakai) gyorsítótár-tisztítási gyakorlat végrehajtásakor. Alapértelmezés szerint a konfigurálható tartomány a meghatározott időtartomány 5%-a. Az eszköz 0%-ra történő konfigurálása a kiürítési időtartomány szigorú betartását eredményezi, így visszafelé kompatibilis a korábbi verziókkal. A beállítás neve deleteOld, és a ~/repositorypart.cfg fájlban található a kapcsolódási pont gyökérkönyvtárában.
FRISSÍTÉSI ÉRTESÍTÉS: Ez a fejlesztés egy megosztott könyvtárat hoz létre két alkönyvtárral, ha az telepítés előtt még nem lett létrehozva. Egy kiszolgálófarmban ezeket a könyvtárakat meg kell osztani a farm összes kiszolgálója között, kivéve az adatbázis- és a terheléselosztó kiszolgálókat a medsrv indítása előtt. A szerverfarmon belüli fájlmegosztás céljából az egyes szervereken létre kell hozni egy megosztott /home/medsrv/shared könyvtárat, kivéve az adatbázis- és a terheléselosztó szervereket. A könyvtárnak két alkönyvtárral kell rendelkeznie: ~/tmp és ~/var. Az új könyvtár létrehozásának részletei az eRAD PACS Gyártási kézikönyvének Megosztott tárolási követelmények részében találhatók.
FRISSÍTÉSI ÉRTESÍTÉS: Az összes gyorsítótárazott adatot újra fel kell dolgozni további információk adatfájlokba (blobokba) illesztéséhez.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: Az újrafeldolgozott gyorsítótárfájlok további adatokat tartalmaznak, amelyek nem kompatibilisek a szoftver régebbi verzióival.
A leképezési paraméterek minden kliens számára a képadatokkal együtt a szerver gyorsítótár fájljaiban (blobokban) vannak tárolva. A meglévő gyorsítótár-adatokat újra fel kell dolgozni ezen hiányzó részletek hozzáadásához. Ez az új fájlformátum a .ei4 fájlkiterjesztéssel van jelölve.
FRISSÍTÉSI ÉRTESÍTÉS: A szükségtelen helyszámítások elkerülése érdekében ezt az új beállítást manuálisan kell létrehozni, és „igaz”-ra kell állítani minden olyan adattároló esetében, amelynek gyökere és első kapcsolódása egyetlen fájlrendszer. Ha egy adattároló gyökere és első kapcsolódása egyetlen fájlrendszer, a rendszer szükségtelenül kiszámítja az adattár méretét minden éjjel, amikor helyet szabadít fel. Ennek elkerülése érdekében a repositorypart.cfg fájlban található forceDedicated konfigurációs beállítás érhető el. Amikor „igaz” értékre van állítva, a helyellenőrző szkript kihagyja a társított adattároló méretének kiszámítását.
FRISSÍTÉSI ÉRTESÍTÉS: Ez a funkció egy új tárolót vezet be ~/data/tempmeta.repository néven, amely a törölt jelzők és kapcsolódó fájlok tárolására szolgál. (Az érintett fájlokhoz lásd a Jira kiadást.) A medsrv indítása során jön létre. A tárolót meg kell osztani az összes farmkiszolgáló között.
VISSZAFORDÍTHATÓSÁGI ÉRTESÍTÉS: A tempmeta tárolóban található adatok nem ismertek a korábbi verziók által, ami érvénytelen adatállapotokat eredményezhet lefelé váltás esetén.
A v9 kiszolgálófarmon a vizsgálatok törlésének támogatása teljesült, többek között a törlés és a törölt állapothoz való hozzáférést több regisztrációs kiszolgálón keresztül, a részleges törlések támogatását az alkalmazáskiszolgálón, a tárolóeszközök végleges törlési kérelmeit (azonnali törlési kérelmek), valamint a külső eszközökről érkező PbR objektumok törlését is beleértve.
Elérhető egy konfigurációs lehetőség, amellyel letiltható a futási idő számítása a sikeres feladatok naplóbejegyzéseiben. Amikor az INFOLOG_SECONDS létezik a ~/var/conf/taskd.conf fájlban, a futási idők elnyomásra kerülnek, ha a feladat a meghatározott másodpercek számán belül sikeresen befejeződik. A sikertelen vagy újrapróbált feladatok futási ideje be van vonva a bejegyzésekbe, a konfigurációs beállítástól függetlenül.
A csoport és a rendszer alapértelmezett beállításai a grafikus felhasználói felületről (GUI) konfigurálhatók. A konfigurációs oldal az Admin/Kiszolgáló beállítások/Web kiszolgáló oldal Preferenciák szakaszából érhető el. Válassza ki a forrásfiókot, majd határozzon meg egy vagy több célfiókot. Rendelje hozzá a beállításokat a beállítások területének jelölő négyzeteivel. Kizárólag a kipipált beállításokat másolja át a cél fiók(ok)ba. Konkrét beállításokra kereshet keresőmezőben. (A terület kinyílik.) Az Átváltás összefoglalóra funkcióval áttekinthetők a végrehajtani kívánt módosítások. A módosítások jóváhagyásához nyomja meg a Jóváhagy gombot. Amikor elkészült, majd a módosítások életbe léptek, zárja be a panelt a jobb alsó sarokban lévő Mégse gombbal.
Amikor bizonyos rendszerkonfigurációs beállítások érvénytelen értéket tartalmaznak, az alapértelmezett érték kerül alkalmazásra, egy üzenet kerül naplózásra a naplófájlban (naponta legfeljebb egyszer), az adminisztrátor értesítést kap a GUI üzenetküldő eszközön keresztül, és ha az indítás során merül fel, figyelmeztetés kerül írásra a standard kimenetre (stdout).
Mivel egy kiszolgáló tudja, mely tárolók helyiek, a szoftver kezelheti a megosztási beállításokat számukra. A helyi tárolók azonosítására és azok nem megosztottként való konfigurálására való felkészítéshez, az összes tároló alapértelmezett megosztott beállítása igazra van állítva, ezáltal kiküszöbölve az egyes tárolók manuális konfigurálásának szükségességét.
PrepareStudy() webes szolgáltatás parancs elérhetősége vizsgálat PACS rendszeren való feldolgozásához és gyorsítótárba való másolásához. A részleteket lásd az eRAD PACS Web Services Programozói kézikönyvben.
FRISSÍTÉSI ÉRTESÍTÉS: Az import és export eszközök eszkölistázási opciójának kimenete megváltozott. Az import és export eszköz eszközlistázási opciója, -l, mentést készít az eszköz konfigurált DICOM-szolgáltatásairól. Az eszközimportáló eszköz támogat egy új parancssori opciót (-s) a munkafolyamat-indítókkal (autortv, autofwd stb.) konfigurált eszközök listázásához. A felhasználói fiók importáló eszköz támogat egy új parancssori opciót (-a) az engedélyezett műveletekkel rendelkező fiókok listázásához.
A munkamenet kivételek szerverhiba naplóbejegyzései tartalmazzák az ok magyarázatot és a réteg követési adatokat.
A Java kóddal kezdeményezett adatbázis hívások szálspecifikus (thread-local) adatbázis kapcsolatokkal támogatják az újrapróbálkozásokat.
A gwav4 tömörítésre egy ideiglenes javítást alkalmaztunk, ezáltal a frekvenciasávok bejárásait öt sávra korlátozzuk, így hasonlóvá téve a gwav3-hoz, amelyen nem jelentkezik az adat túlcsordulás állapot. Megjegyezzük, hogy az érintett vizsgálatokat (tehát, amelyeknél túlcsordulás jelentkezett) újra fel kell dolgozni.
A terheléselosztó kirendelheti a stream szervert.
A websocket port elérhetőségének vizsgálatához egy új eszköz, ~/component/dcviewer/bin/websockcli, áll rendelkezésre. Az eszközt egy teljes körűen minősített websocket URI segítségével kell meghívni.
A webkiszolgáló (alkalmazás) Feladatok (Tasks) oldalán a szerver farm összes szerverének feladata megjelenik. Alapértelmezés szerint az oldalt megjelenítő kiszolgáló feladatai jelennek meg. Más kiszolgálók feladatai összecsukva jelennek meg, és a kiszolgáló szekciójának felső sorára kattintva nyithatóak meg. A független adatszűrés támogatott.
A globális rc start parancs kiadásakor az stdout-on nem jött létre kimenet, így nehezen látható, hogy mi milyen feltételeket indított el, ha egyáltalán léteznek feltételek. Az eszköz most már megjeleníti a globális indításban szereplő minden szerver kimenetét. A kimenetet szerverenként csoportosítja.
Több munkalista sor kötegelt kiválasztásakor a vizsgálat felosztása, a beolvasás, a mellékletek feltöltése és a technológus nézet eszközei mind le vannak tiltva. Az összes munkalista sor kötegelt kiválasztásakor, valamint a kérések és vizsgálatok kombinációjának kiválasztásakor mindhárom megnyitott eszköz is le van tiltva.
A webszolgáltatások (web services) felhasználói felület támogatja a vizsgálat gyorsítótár állapotának a lekérdezését. Az Állapot előkészítése (CPST) (Preparing Status) mező elérhető a GetStudyData (Vizsgálati adatok megjelenítése) és a Lekérdezés (Query) válaszokban. A részletes leírást az EP Web Services Programozói kézikönyv tartalmazza.
A jelszó-visszaállítási oldalon a jelszómező olyan korlátot szabott, amely más oldalakon nem létezett. Minden oldal lehetővé teszi a korlátlan hosszúságú jelszavak hozzárendelését.
A vizsgálat szerkesztési oldalon található kiválasztási listák elemei tartalmazzák a meglévő vizsgálati rekordokban tárolt értékeket, valamint a mező konfigurációja által meghatározott listaértékeket, ha a mező (a Címkék testreszabása oldalon szerkeszthető) beállításaiban a Kiválasztás korlátozása listaértékekre jelölőnégyzet be van jelölve, és a Szigorú számozás nincs.
A konfigurált proxy szerver alapértelmezés szerint transzparens proxy módot használ.
RENDSZERKÖVETELMÉNYEK: A funkció használatához 9.0.4 vagy magasabb verziószámú nézegető (viewer) szükséges.
Ha egy blob tartalma megváltozik a globális gyorsítótárban, akkor a megtekintő a neki elküldött értesítés alapján eldönti, hogy betöltse-e a képadatot vagy sem.
A blobfájlok kezelésére szolgáló ~/component/imutils/bin/bin/blobtest nevű eszköz a parancssorból használható. A parancs a felhasználási adatok --help argumentumával indítható el.
Mentéskor a nézegető egy ellenőrzőösszeget ad a profilhoz, a szerver pedig kiszámít egy ellenőrzőösszeget és az elmentett profil felülírása előtt ellenőrzi, hogy az megegyezik-e a benyújtott ellenőrzőösszeggel. Ha a nézegető validálás céljából ellenőrzőösszeget kér a szervertől, akkor a szerver elküldi a kiszámított ellenőrzőösszeget.
FRISSÍTÉSI ÉRTESÍTÉS: Az ideiglenes DICOM tároló mappát áthelyeztük a raktár gyökérbe. Az alkalmazásszerver által indított regisztrációs folyamat átirányítódik az intracom szolgáltatást alkalmazó regisztrációs szerverre. A funkció kiterjed az ideiglenes DICOM tárolómappa módosítására. Ha a DICOM-tárolót csatlakoztatási pontok nélkül konfigurálják, a DICOM-fájlok a DICOM-tároló ~/data/dicom.repository/tmp gyökérmappájába kerülnek (a ~/data/tmp helyett). Ez összhangba hozza a folyamatot a több csatolási ponttal rendelkező adattárak kezelésével, és az alkalmazáskiszolgáló által létrehozott adatokat elérhetővé teszi a regisztrációs kiszolgáló(k)ról.
A feleslegesen naplózott hibaüzenetek elkerülése érdekében a jit képfeldolgozás (ideiglenesen) le van tiltva, amennyiben az technikus nézet oldalra feldolgozatlan vizsgálatot töltenek be.
A felhasználók értesítéséhez arról, hogy az általuk megjeleníteni próbált vizsgálat feldolgozatlan, a szervernek a feldolgozás állapotán kívül az ütemezett feldolgozási feladatok állapotát is ellenőriznie kell. Az állapotra vonatkozó adatok lekérdezése után a szerver elküldi az információt a hívó félnek, hogy a felhasználó értesítést kapjon a futásidőben történő (just-in-time) feldolgozási feladat által okozott késedelemről. Egy kiegészítő felület segítségével a megjelenítő figyelemmel tudja kísérni a feldolgozási feladatok számát, így a befejezéskor jelenteni tudja az állapotot.
A rendszergazdák visszaállíthatják egy felhasználó vagy csoport nézegető profilját a rendelkezésre álló biztonsági mentésekből a felhasználói és csoportfiókok oldal Nézői profil kezelése eszközön elérhető Profilmentések oldal segítségével. A rendszergazda létrehozhat biztonsági mentéseket, illetve törölheti és helyreállíthatja a rendszer és a felhasználó által létrehozott biztonsági mentéseket.
Egy interfész keretrendszer (komponens) került hozzáadásra, amely parancsokat és feladatokat ad át egy olyan szerepkört betöltő kiszolgálónak, amelyet ő maga nem lát el, vagy amely a terhelést több, ugyanazt a szerepet betöltő kiszolgáló között osztja el. A komponens az intracom elnevezést kapta. A 4651-es portot használja, amely az INTRACOM_SERVICE_PORT paraméterrel írható át az ~/etc/virthosts.sh-ban. Elindítja az intracom szolgáltatást, amely fogadja és kiszolgálja a szerver farm más kiszolgálóitól érkező gRPC-kérelmeket. Ez a szolgáltatás jelenleg az alkalmazás- és regisztrációs kiszolgálókon indul.
A (bejövő) kényszerítési szabály parancskönyvtár kontrollváltozókkal bővült. A kontrollváltozók egy És-jellel (@) kezdődnek és nagybetűket alkalmaznak. Egyetlen kontrollváltozó került bevezetésre: @PROCESS. Ha a kontrollváltozóhoz rendelt szabály NULLA értékű, (tárolás, továbbítás, stb.) a feldolgozás leáll. Ezt egy naplóbejegyzés rögzíti. Minden más eredmény esetén a feldolgozás folytatódik. Megjegyzés: a kontrollváltozókat jelenleg csak a pb-scp ismeri fel. A részletekért az eRAD PACS Data Coercion kézikönyv tartalmazza.
Az eszköz automatikus továbbküldés beállítása arra utasítja a rendszert, hogy a harmadik fél eszközeiről szerzett összes objektumot küldje el neki, kivéve azokat az objektumokat, amelyeket az eszköz maga továbbított. Az objektumok frissítéseit szintén elküldi (tehát a "frissítések folyamatos küldése” (keep sending updates) beállításra vonatkozó objektumokat). A korlátozás az, hogy a rendszer által egy vizsgálathoz generált új adatok, amelyek a beállított eszközről származnak, nem küldi el az eszköznek. Egy olyan funkciót vezettünk be, amely arra utasítja a rendszert, hogy automatikusan továbbítson mindent, amit korábban is elküldött, plusz minden, a rendszerben létrehozott objektumot. Ily módon a felhasználó által létrehozott és a vizsgálathoz hozzáadott prezentációs állapotok és másodlagos képrögzítési objektumok elküldésre kerülnek arra az eszközre, amelyről a vizsgálat származik, ezáltal mindkét rendszeren minden pillanatban ugyanaz az objektumgyűjtemény található. A beállítás az eszközszerkesztő oldal DICOM-szolgáltatások/beállítások részében található Szinkronizálás (Sync) feliratú jelölőnégyzetben érhető el.
A stream szerver komponens úgy lett módosítva, hogy a többi medsrv komponenstől függetlenül fusson. A stream szerver eszközökhöz a streaming munkameneteket körkörösen (round-robin) osztják ki. Ennek eredményeként egy adott munkamenet-azonosítóhoz ugyanaz a stream szerver kerül bemutatásra, így a nézegető adott esetben újra felhasználhatja a meglévő kapcsolatokat.
Az adatnyelés külön szerepkört kapott, és az alapszintű keretrendszer részeként regisztrációs szerver elnevezéssel szerepel.
Az adatfeldolgozás, az iop-ok minimalizálása érdekében tett alapszintű erőfeszítés részeként, átdolgozásra került az adatok egyetlen fájlban, blobként történő tárolása révén.
Az adatok gyorsítótárazása az iop-ok minimalizálása érdekében tett alapszintű tevékenység részeként átdolgozásra került a gyorsítótár adatok kevesebb fájlban, blobként történő tárolása révén.
Az adatbázis átdolgozására annak az alapszintű erőfeszítésnek a részeként került sor, hogy megszüntessük a hatástalan és használaton kívüli mezőket, új adatokat tároljunk, például a tanulmányok feldolgozott állapotát és tárolóhelyét, valamint támogassuk az elavult objektumtáblában létező objektuminformációkat.
Az általános refaktorálás részeként az SQL-szerverhez való kapcsolatok fennmaradnak. A keretrendszer az előkészített utasításokat újrafelhasználás céljából gyorsítótárazza.
Ez a tárkezelő új középső rétegének alkalmazása a tárolókban lévő metaadatok állapotának nyomon követésére és a több tárolóban lévő adatok létezésének kezelésére.
A telepített Poco verziószáma 1.11.2.
Ha egy hálózati tárolóeszköz nem érhető el, a hozzáférési kérelmek időtúllépés miatt lejárnak, és az eszköz offline állapotba kerül, hogy a későbbi kérelmek befejeződhessenek. Offline állapotban az eszközhöz intézett hozzáférési kérelmeket a rendszer figyelmen kívül hagyja. A rendszer öt percre visszalép, és minden egyes időszak után ellenőrzi az eszközt, amíg az újra online nem lesz.
Az elavult komponensek, pl. applet, pref, ct és pcre eltávolításra kerültek a kódbázisból. Néhány medsrv komponenst elavulttá tettünk a platform komponens javára, beleértve a curl, boost és openssl komponenseket.
Az adatbázis testreszabásához használt Címkék testreszabása (Customize Labels) oldalt frissítettük GWT-re, így kinézete és megjelenése hasonló más weboldalakéhoz. Minden meglévő funkció megmarad, beleértve a legtöbb adatbázis-mező egyedi beállításainak konfigurálását, valamint a számított mezők létrehozásának és módosításának lehetőségét. Néhány kisebb különbség a kapcsolódó funkció változásai miatt van, nem pedig a GWT frissítése miatt. A részletekért lásd a felhasználói súgó oldalakat.
A felsorolásos listaként definiált munkalisták oszlopai tartalmazhatnak olyan értékeket, amelyek nem szerepelnek a konfigurált értéklistában. A szűrőpanelen rendelkezésre áll egy szabad szöveges mező, így ezeket az értékeket keresési feltételként lehet megadni.
Az olyan többértékű mezők, mint például a Modalitás (Modality), lehetővé teszik a több értékre történő szűrést. A felhasználók behúzzák az értéket a szűrőpanelbe. Az egyes értékek fordított törtjel karakterekkel vannak elválasztva.
A vizsgálat folyamatállapotának nyomon követésére létrehoztunk egy PROCSTAT nevű vizsgálati mezőt. Az állapotok a következők: <empty> (állapot ismeretlen), frozen (DICOM-objektumok léteznek, de nincsenek feldolgozva és gyorsítótárazva), cold (feldolgozott, de a gyorsítótárból eltávolított vagy elavult adatok), cooking (részben feldolgozott) és cooked (teljesen feldolgozott és gyorsítótárba helyezett). Az érték megjeleníthető a munkalistán.
A ~/component/tools/checkWeakPasswords.sh parancssori eszközzel azonosíthatóak és frissíthetőek a gyenge jelszóhash-eket használó felhasználói fiókok. Az eszköz egy naponta egyszer lefutó ütemezett (cron) feladathoz van hozzárendelve, és ha fiókokat talál, akkor egy értesítési üzenetet küld a rendszergazdai fiókoknak.
Egyes listaoldalak, köztük az Egyéb lista oldal, frissítésre kerültek, hogy a munkalistához és az egyéb oldalakhoz hasonlóan megjegyzik az alkalmazott szűrőket és a rendezési sorrendet, így az oldalra való visszatéréskor az alapértelmezett oldal újratöltése helyett a korábbi tartalom jelenik meg.
A név-, dátum- és időformátumok konfigurálásakor a rendszer olyan rendellenességeket keres, mint például egy adott mezőelem duplikációja, és elutasítja a kérelmet.
A kiszolgáló támogatja a megtekintő kéréseit a felhasználói profil mentésére és törlésére, a mentett felhasználói profilok listájának visszaküldésére, valamint a felhasználói profil visszaállítására.
A felhasználói fiókok biztonsági mentési fájlból való importálásakor a rendszer ellenőrzi a jelszó hasheket és eltávolítja a gyenge jelszavakat. Ezeknek a felhasználóknak a bejelentkezéskor vissza kell állítaniuk a jelszavukat. Az érintett fiókok az importálási naplófájlban szerepelnek.
A Feladatok (Tasks) oldalon egyes feladatoknál, különösen a az Alfeladatok (Sub-jobs) oldalon lévő rendszerfeladatoknál hiányoztak a leírások, vagy általános leírás jelent meg. Ezek a feladatok mostantól reprezentatív leírást jelenítenek meg a Feladatok oldal táblázatában.
Létrejött egy terheléselosztó (haproxy) komponens, amely a rendszer inicializálásakor elindítja a terheléselosztót. A terheléselosztó komponens akkor indul el, ha a kiszolgáló terheléselosztóként van konfigurálva a ~/etc/balancer.role-ban. Az alapértelmezett konfigurációs beállítások a ~/component/haproxy/config/ komponens könyvtárban találhatók. A beállítások felülírhatók a haproxy.cfg.template és a syslog.conf.template másolatainak testreszabásával a ~/var/haproxy/ állományban. A haproxy konfigurációs fájl (haproxy.cfg) a sablonból jön létre az indítás során. A proxy naplófájlok a ~/var/log/haproxy.log fájlban vannak tárolva és hetente cserélődnek.
Az erőforrások zárolása egyetlen szerverre vonatkozott, de most, hogy az erőforrásokhoz egyszerre több szerver is hozzáférhet (pl. több stream szerverről), a zárolást több szerverre is ki kellett terjeszteni.
Azok a szerverek, amelyeken nem fut apache, például stream szerver, adatbázis szerver és a terheléselosztó szerver, nem támogatják a GUI-alapú licenszelést. A licenszelési kézikönyvben további utasítások találhatók a licenckérő fájl összegyűjtésére és a licencfájl parancssorból történő telepítésére vonatkozóan.
FRISSÍTÉSI ÉRTESÍTÉS: A helyi (gyors) tárolót használó szervereket a frissítés előtt konfigurálni kell. A stream szerver a távoli (lassú) adattárból a helyi (gyors) adattárba helyezi át a blob adatokat. Ha a rendszert nem konfigurálták helyi gyorsítótárral (~/var/localcache.repository), akkor léteznie kell egy a távoli tárolóhelyre (~/var/cache.repository) és a rendszer nem próbálja meg áthelyezni az adatokat.
A hozzáadott webszolgáltatások parancsok lekérdezik az MCS-szervertől a munka elhelyezkedését a sorban (QueuePosition()), valamint a munka hosszát (QueueLength()). A részletekért lásd az eRAD PACS Web Services Programmer's Manual című kézikönyvet.
A Log4j a 2.18.0 verzióra frissült. A Groovy szkript a 3.0.12-es verzióra frissült. A ~/var/conf helyen létezik egy egyedi, log4j2-custom.xml elnevezésű log4j konfigurációs fájl, amely felülírja a rendszer konfigurációs fájljának kiválasztott beállításait. A testreszabási utasításokat a ~/component/classes.com/erad/pacs/log4j2-custom.xml sablonfájlban találja.
A Megváltozott állapot (Changed State) beállítás vissza lett állítva a Szerverbeállítások (Server Settings) oldalon.
Egy parancssori java eszközzel a hyper+ k szerver farm szerverei manuálisan elindíthatóak és leállíthatóak a megfelelő sorrendben az egyes szerverek szerepkör-konfigurációja által meghatározottak szerint. A lehetőségek között szerepel a szerver farm elindítása, a szerver farm leállítása és a szerver csoportok listázása. A használat részletei és az indítási sorrend függőségei a Jira kiadásban találhatók.
A webes alkalmazások egy szerverről letölthetik a ~/var/quality/qc.html minőségellenőrzési eredményfájlt, feltéve, hogy a kérés minősített forrásból érkezik, azaz létezik egy érvényes eRAD PACS felhasználói munkamenet azonosító, és a fiók rendszergazda vagy támogatási jogokkal rendelkezik. A parancs: cases/showQuality.jsp.
A ProcSt nevű munkalista oszlop a tanulmány adatainak feldolgozott (teljesen feldolgozott) állapotát mutatja, ami azt jelenti, hogy a tanulmány adatai elérhetőek a streameléshez. A munkajegyzékben található Reheat Study (Vizsgálat felmelegítése) eszköz segítségével manuálisan indítható el egy feldolgozott vizsgálat streamingeléshez.
A szerver farmon belüli szolgáltatás regisztrálásához használt szolgáltatási szerepkör funkciót különválasztották, és mostantól minden egyes kiszolgálón hyperdirector szolgáltatásként fut. Ez a szerver ki van kapcsolva, ha minden szolgáltatás egyetlen szerveren fut.
Minden tárolóraktárat egyetlen szerver kezel. A helyi gyorsítótárakat a megfelelő streaming és regisztrációs szerverek kezelik. A globális tárolókat, beleértve a globális gyorsítótárat, az adat-, a feldolgozott és a meta-tárolókat, az alkalmazásszerver kezeli.
Egy hyper+ szerver farmon a műveletek csak az alkalmazásszerveren futnak.
Minden időzített feladat (cron job) úgy lett konfigurálva, hogy a kiszolgáló szerepkörének megfelelően szervereken fusson. Az időzített feladatok teljes listáját és a szervereket, amelyeken futnak, a Jira kiadás tartalmazza. A crontab -l paranccsal az rc start befejezése után megkaphatja az egyes kiszolgálókhoz regisztrált összes időzített feladat (cron job) listáját.
Támogatás hozzáadva, amely lehetővé teszi a nézegető számára, hogy a webszerver helyett a streaming csatornákon keresztül töltse le a herpa adatokat.
A rendszer ellenőrzi a futó vizsgálat-regisztrálási vagy újrafeldolgozási feladatokat, amikor elindítja a vizsgálati adatok előkészítési folyamatát. Ha ilyeneket talál, akkor az ismételt feldolgozási feladatok elkerülése érdekében az előkészítési feladatot elhalasztja.
A hyper+ szerver farm több szervere által megosztott tárolók az adatbázis-kiszolgáló által kezelt globális zárolási mechanizmust alkalmaznak. Az isShared beállítását lásd a tárkezelő (repository handler) kézikönyvében.
RENDSZERKÖVETELMÉNYEK: A funkció használatához 9.0.2 verziószámú nézegető (viewer) szükséges.
A streaming technológia támogatja a gwav 4-es verzióját, ami jobb kezdeti minőséget tesz lehetővé a kisebb miniatűr képekből. A nézegető továbbra is elfogadja a gwav3 és gwav1 formátumot, ha a szerver felajánlja.
A rendszer minden összetevője, beleértve a nézői streaminget, a webes nézegetőt, az technikus nézetet stb., támogatja az egységes tömörített gyorsítótár adatformátumot (cw3). A más formátumú adatok létrehozása megszűnt.
A tárkezelő hívásait egy olyan középső réteg váltotta fel, amely nyomon követi a metaadatok állapotát, és ennek megfelelően kezeli az adatokat, jelenti az adatok helyét, mappákat hoz létre, adatokat helyez át, jelezi ha a mappák elérhetetlenek stb. A tárkezelő piszkos fájlok kezelésére és feloldására szolgáló mechanizmusa változatlan marad. A pontos részleteket a Tárkezelő frissített kézikönyve tartalmazza.
Az adatbázis teljesítménykritikus hívásait egy absztrakciós rétegbe burkoltuk, így az adatbázis nincs közvetlenül kitéve a medsrv-nek. Amellett, hogy közös interfészt biztosít, lehetővé teszi az alkalmazás számára, hogy tartós kapcsolatokat tartson fenn az adatbázissal.
A kiszolgálókhoz konkrét szerepköröket lehet rendelni, például stream szervert, regisztrációs szervert, adatbázis szervert, alkalmazás szervert és webszervert. A beállítás a ~/etc/.role állományban kerül meghatározásra. Ha nincs meghatározott szerepkör definiálva, akkor az összes szolgáltatás teljesül.
A közös stream server kódja nem tudott nyers fájlokat generálni, amikor arra kifejezett kérést kapott. Bár ez a v9 esetében nem releváns (mivel a stream szervere nem használ nyers fájlokat), a V9 által is használt közös kódbázisban módosult.
A Java frissült a java-17-openjdk-17.0.3.0.0.7 verzióra. A rendszer a platform Java verzióját használja.
Az Apache frissült a httpd-2.4.37-es verzióra. A Tomcat a 9.0.63-as verzióra frissült. A rendszer a Tomcat egyéni buildjét, de a platform Apache-ját használja.
VISSZAFORDÍTHATÓSÁGGAL KAPCSOLATOS ÉRTESÍTÉS: A frissítés után az adatbázis módosul, és már nem kompatibilis az előző verzióval.
A MySQL a 8.0.26-os verzióra frissült. A rendszer a MySQL platform verzióját használja.
A DCMTK könyvtár a 3.6.7-es verzióra frissült.
A GWT a 2.9.0 verzióra frissült.
Az openssl az 1.1.1k verzióra frissült. A rendszer a platform Openssl verzióját használja.
A több tárolón létező vizsgálatok (ami akkor lehetséges, ha egy tárat az adatok frissítésekor valamikor nem csatolták be) nem törölhetők a felhasználói felületen vagy a rendszeren keresztül. Erről a felhasználók a felülvizsgálat törlése (delete review) oldalon kapnak értesítést és a naplófájlokba bejegyzések kerülnek.
A 9.0 verzió UDI-értéke 0086699400025590-re frissült. Ez az érték jelenik meg a megfelelő szoftverazonosító oldalakon.
A Részlegesen elérhetetlen (Partially Inaccessible) oszlop jelzi, ha a tanulmány az adattár több tárolóhelyén is tárolva van. Ez az oszlop alapértelmezés szerint el van rejtve. Adja hozzá az elrendezéshez a Mezők szerkesztése (Edit Fields) eszközzel.
A több csatolási ponton található tanulmány továbbítása hibát eredményez. Ha a GUI-ból kezdeményezik, akkor a felhasználó értesítést kap. Ha továbbítási műveletből kezdeményezik, akkor a kérés teljesítését a művelet újbóli lefutásakor (öt perc múlva) újra megkísérli a rendszer.
A több csatolási ponton található tanulmány szerkesztése hibát eredményez. Ha a GUI-ból kezdeményezik, akkor a felhasználó értesítést kap. Ha szerkesztési műveletből kezdeményezik, akkor a kérés teljesítését a művelet újbóli lefutásakor (öt perc múlva) újra megkísérli a rendszer.
A több csatolási ponton is megtalálható vizsgálathoz kapcsolódó lelet vagy az azokhoz fűződő megjegyzések szerkesztése nem támogatott. Az állapot fennállása esetén a lelet hozzáadása/szerkesztése gomb és a megjegyzés hozzáadása/szerkesztése gomb le van tiltva a betegmappában.
A 9-es verzióban kivont vagy már nem használt Java servlet funkciókat eltávolítottuk a kódbázisból.
Az időzítés alapján a gyermekkiszolgálóról érkező automatikus korrekciós üzenet megelőzheti az első objektum regisztrációs üzenetet, így a harmadik fél eszközei azt hihetik, hogy a vizsgálat létezik, mielőtt az ténylegesen létrejött volna. Az automatikus korrekciós üzenetek mindaddig felfüggesztésre kerülnek, amíg a hub-kiszolgáló nem regisztrál legalább egy objektumot.
A webszolgáltatások eszközei konfigurálhatók úgy, hogy a vizsgálat adatainak szerkesztésekor kapjanak rendelésfrissítési értesítést. Az eseményindító akkor aktiválódik, ha a webszolgáltatási eszköz szerkesztési lapjának Megrendelési üzenetindítók (Order Message Triggers) szakaszában a Vizsgálat frissítés (Study Update) beállítás be van jelölve. A Frissítés (Update) értesítést küld új objektum felvételére, bármilyen szerkesztésről vagy objektum újrafelvételéről. Az Újraindexelő (Reindex) értesítést küld, ha a vizsgálatot a rendszergazda vagy a rendszer újraindexeli.
Az értesítő üzenet szövegezése miszerint a tárkezelőnek törölnie kellett az adatokat, noha a küszöbértéket nem lépte át, módosult ezáltal pontosabban tükrözi a probléma okát.
A nem megfelelő időzóna eltolási értéket tartalmazó objektumok figyelmen kívül hagyják a hibás adatokat, és az objektumban rögzített időértékeket mutatják be.
A CW3 képek letöltését a technikus nézetbe és a webes megjelenítőbe az ügyfélnek kell kezelnie. A böngésző túlterhelésének elkerülése érdekében legfeljebb négy képet lehet egyszerre letölteni.
A naplóbejegyzések a Naplók oldalon és az oper_info naplóban, amelyek a Prefecth művelet kivételével a műveletből eredő események részleteit tartalmazzák, azonosítják a vizsgálatnak megfelelő munkalista-szűrőt.
A szerver licencét több esemény és adat alapján ellenőrzik. Ha ezek közül a rendszer valamelyiket észleli, de nem elégséges a licenc érvénytelenítéséhez, akkor üzenetben értesítést küld a rendszergazdáknak. A rendszergazdák az eRAD ügyfélszolgálatához fordulhatnak a részletekért és a licenc kivételének elkerülésére szolgáló lehetőségekért.
Az alapértelmezett médiakészítő motor alapértelmezés szerint a helyi MCS. Ez az új telepítésekre és frissítésekre vonatkozik.
Ha az adatbázissal létrejött kapcsolat megszakad, a szoftver átlátható módon újracsatlakozik és újrapróbálkozik a függőben lévő művelettel.
Néhány, a 9-es verzió előtt opcionális funkció már nem opcionális. Ezek alapértelmezés szerint fixen be vannak állítva. A funkciók beállításait eltávolítottuk a felhasználói felületről.
A kezdeti regisztráció létrehozza a tömörített képfájlokat a helyi gyorsítótárban, mielőtt hozzáadná őket a BLOB-hoz. Ehhez egy helyi gyorsítótár-tárhely létrehozása szükséges (~/var/localcacache.repository).
A DICOM-adatokat a feldolgozott adatoktól elkülönített (meta) tárolóhelyen tárolják.
A tárkezelő támogat egy visszahívási felületet, amely a helymeghatározási funkció (locate) használata nélkül biztosítja az erőforrások helyének nyomon követését.
A webszolgáltatások Továbbítás (Forward) parancsa támogatja az egyes sorozatok és objektumok továbbítását ugyanabból a tanulmányból egy meghatározott célpontra. A részletekért lásd a webszerverek kézikönyvét.
A szerverbeállítások kezelésének javítása érdekében alkalmazott szerkezeti változások.
A lelet sablonok szerepelnek a felhasználói exportálási és importálási eszközökben.
A tárkezelő automatikusan konszolidálja a több partíció között megosztott vizsgálatokat, még akkor is, ha a teljes limit küszöbértéket túllépték, kivéve, ha a fizikai limitet túllépték. A fizikai korlátot a hardFullLimit konfigurációs beállítás határozza meg. A beépített alapértelmezett érték 99,9%. Ez a respository.cfg állományban felülbírálható.
A sötét téma használatakor az egyes jogosultság mezők háttérszíne módosult, hogy a beállításjelző jobban látható legyen.
A dotcom információk összegyűjtésére szolgáló parancssori eszköz lehetőséget nyújt egy hibakód visszaküldésére, ha a művelet hibával vagy figyelmeztetéssel találkozik.
A frissített repo.jsp és a validate.jsp szkriptek dinamikusan egy rendszermunkamenetet generálnak az automatizálási eszközökben való használathoz.
A felhasználói fiókok importálásához és a felhasználók konverziójához (a frissítés során) tartozó naplóbejegyzések a következő külön naplófájlokba vannak összevonva: ~/var/log/UserExport, ~/var/log/UserImport és ~/var/log/UserConversion.
Egy általános leletsablon-típus került hozzáadásra, amely támogatja a Dcstudy mezők hozzáadását egy lelet nézethez vagy lelet szerkesztő sablonhoz. A részleteket lásd az eRAD Layout XML Customization (eRAD Elrendezés XML testreszabás) kézikönyvben.
A warnMoveTime alapértelmezett értéke öt órára változott az adattárak esetében. Az összes többi adattár esetében az alapértelmezett érték továbbra is két nap.
Az eltávolított vizsgálati fájlok támogatják az új weboldal feltöltéséhez szükséges vizsgálati adatokat az ilyen fájlok felülvizsgálatához és törléséhez. A Vizsgálat tisztítás (Study Cleanup) oldal a Támogatás (Support) jogokkal rendelkező felhasználók számára érhető el a Rendszergazda (Admin) menüből. Az oldal alapértelmezés szerint üres. A kritériumok megadásával egy legfeljebb 5000 törölt tanulmányt tartalmazó lista jeleníthető meg. Az eszközök megegyeznek a Munkalista (Worklist) oldalon található eszközökkel. A gyermek szervereken lévő tanulmányok törlésekor a törlést a gyermek szervereken kezdje, majd a szülői szervereken folytassa. A tisztítási kérelmek és eredmények a forever naplóban kerülnek naplózásra.
Miután a felhasználó frissítette a nézegető beállításait, a meglévő profilfájl mentésre kerül biztonsági mentésként, így szükség esetén később visszaállítható. Ezek a biztonsági másolatfájlok az egész dotcomban elterjedtek.
Az „Aktuális tartalomra alkalmazni” (Apply to Current Content beállítás) beállítás minden műveletnél alapértelmezett esetben „nem”-re módosult. A meglévő műveleteket ez nem érinti, amíg azok engedélyezve maradnak. Letiltás, majd újra-engedélyezés után a rendszer az új alapértelmezett beállítást fogja használni, kivéve, ha azt a beállítás során manuálisan nem bírálják felül.
Az eRAD PACS v9.0 kezdő kódbázisát az eRAD PACS 8. verzió medsrv build 49, asroot 8.0.1 és 7.9.0 platform alkotja. Módosítások végrehajtása a címkézés (eRAD PACS v9.0) és a csomagolás (RPM-ek stb.) figyelembe vételével.