Přeskočit na obsah

Debian-Med/Tille/Příklady systémů pro správu ordinace

Z Wikiverzity

Příklady systémů pro správu ordinace

[editovat]

GnuMed

[editovat]

Cílem GnuMed je stát se uceleným a robustním balíkem Open Source /*14*/ softvéru pro bezpapírovou lékařskou ordinaci. Je postaven na profesionálně postavené koncepci klient-server /*15*/. Je tvořen množstvím modulů, které jej činí velmi přizpůsobivým k různým oblastem nasazení. Tato flexibilita jej umožňuje používat lékaři různých zemí, v nichž jsou zavedeny rozličné systémy lékařské péče.

Jakožto databázového serveru vyžívá GnuMed služeb PostgreSQL, který je známým skálopevně robustním databázovým serverem a tudíž je tím správným nástrojem pro takovýto druh aplikací. V současné době je uživatelské rozhraní napsáno v Pythonu, ale v principu je možné užít i rozhraní webového serveru.

Bezpečnost dat má nejvyšší prioritu. Navíc, služba GNotary umožňuje lékařům prokázat integritu jejich dat.

Žel, GnuMed v tuto chvíli ještě není připraven pro použití v lékařské praxi. Jeho silný vývoj reálně slibuje první beta-versi pro testování. K disposici jsou již rovněž neoficiální balíky GnuMed.

Torch (dříve znám jako FreePM)

[editovat]

Torch (dříve známý jakožto FreePM) je systém řízený formuláři. Prostřednictvím flexibilního open-source softvéru, který používá, nabízí lékařům jednoduše použitelné a jednoduše modifikovatelné řešení správy lékařských záznamů. Systém sestává z řady formulářů, vytvářejících součásti lékařského záznamu o pacientovi. Praktický lékař si může přizpůsobit tyto formuláře tak, aby co nejlépe padly k jeho individuálnímu pracovnímu prostředí.

Torch poskytuje prostřednictvím webových služeb profesionálně podporovanou platformu, takže celý systém je obhospodařovanán více než jednou firmou, i když se jedná o kompletně open-source záležitost.

Torch je open-sourceovou aplikací pro správu ordinace a elektronických lékařských záznamů. Je to projekt založený na webovém aplikačním serveru Zope. Zope má svou vlastní transakční objektově orientovanou databázi. Autoři dávají přednost objektově orientované databázi před relační databází. Torch je jediným projektem, který známe, který nepoužívá žádnou relační databázi založenou na SQL.

Torch má pouze webové klienty, což odporuje rychlému používání bez myši.

Nicméně, Torch se již může prokázat referencemi svého nasazení a je produktivně využíván. Jeho autoři vítají integraci Torchu do Debian-Med.

Res Medicinae

[editovat]

Res Medicinae se stává rozsáhlým softvérovým řešením pro použití ve zdravotnictví. Kombinuje intuitivní snadnost použití s přednostmi, které má CYBOP Framework. Užívá nejnovější technologie, které se drží obecných standardů zdravotnického softvéru a stává se tak otevřeným pro mnoho dalších zdravotnických systémů. Je to další slibný projekt k výstavbě systému komplexní správy ordinace. Jeho návrh je modulárně objektový a již nám představuje pár zajímavých vlastností.

Res Medicinae je pokusem překonat vysoké ceny v říši medicínských informčních systémů a poskytnout svobodný, stabilní, bezpečný, na platformě nezávislý a rozsáhlý systém svým uživatelům.

Res Medicinae je a zůstane svobodným v každém slova smyslu. Jeho přispěvatele baví spolupracovat, komunikovat spolu prostřednictvím e-mailových konferencí a jsou nadšeni myšlenkou sdílet své znalosti s lidmi žijícími na "chudší straně" světa.

Co se týče distribuce Res Medicinae prostřednictvím Debianu, určité potíže by mohl působit fakt, že je to napsáno v Javě, protože javovské aplikace často spoléhají na vlastnosti non-free /*16*/ implementací javovských virtuálních strojů; v našem případě to vypadá, že Res Medicinae využívá non-free Swing toolkit /*17*/.

I když se jedná o slibný projekt, má ještě daleko k praktickému nasazení.

Tk Family Practice

[editovat]

Tk Family Practice je klinický zdravotnický informační systém vhodný pro ordinaci rodinného lékaře k ukládání klinických informací o pacientech, nejen informací o platbách. Jako programového prostředí využívá Tcl/Tk. Tato volba jej činí přenositelným, avšak pravděpodobně těžko použitelným v rozsáhlejších projektech, kterých by se mělo účastnit mnoho programátorů.

Jako databázový stroj původně užíval vlastoručně vyrobenou XML databázi. Mezitím byl dodatečně začleněn kompletní, leč zastaralý /*18*/ PostgreSQL server (ve své zdrojové i binární formě). Takové rozhodnutí pak budí otázky ohledně aktualizace, údržby a bezpečnosti. Zdá se, že kromě lokálního Tk rozhraní je podporováno i webové uživatelské rozhraní.

Problémem tohoto systému je celkem náročná obsluha, neboť jeho uživatelské rozhraní je lehce matoucí. Navíc zde máme určité těžkosti ještě předtím, než může být program stažen: Webová stránka Offizielle Website obsahuje množství naprosto odtažitých soukromých informací. Na stránce není uvedeno žádné licenční ujednání a jste nuceni vyplnit webový formulář, abyste obdrželi odkaz na stahovací stránku SourceForge. Archiv má 75 MByte a obsahuje zdroje a předkompilované binárky více než jen jiných freesoftvérových projektů. Krátce řečeno, s ohledem na bezpečnost, údržbu a provádění aktualizací je tento projekt nepřijtelný.

Jestliže jeho autor nezajistí jasný a jednoduchý přístup k upstreamovým zdrojům, je velmi malá šance, že by tento program mohl být distribuován v Debianu.

OIO — Open Infrastructure for Outcomes

[editovat]

OIO je sdílená a svobodná infrastruktura, která podporuje shromažďování odborných znalostí, nástroje pro hodnocení, výcvik, zajištění kvality a nástroje pro hlášky jako způsob snížení nákladů při provádění výsledných hodnocení.

Byla zde implementována alternativní metoda obhospodařování pacientských a výzkumných dat. Kromě předdefinovaných formulářů je každému uživateli umožněno definovat si svoje vlastní a specifikovat, jakým způsobem můžou být navázány na ty již existující.

Jako databázový backend využívá PostgreSQL, což se jeví jako odpovídající volba pro daný záměr. K databázový backendu je možno přistupovat prostřednictvím aplikačního serveru Zope, který vytváří webové rozhraní. Je to svým způsobem užitečné, nicméně rychlý přístup pomocí klávesnice by byl rovněž příjemnou vlastností u každého typu správy ordinace.

Další systémy pro správu ordinace

[editovat]

FreeMed je systém správy ordinace napsaný v PHP, používající databázový backend MySQL. MySQL zde není moc vhodný, neboť mu chybí transakce — alespoň v té versi, která byla použita po tu dobu, co projekt FreeMed žije. Vývoj FreeMedu se na dlouhou dobu zastavil, ale nedávno byl opět probuzen k životu.

Jako frontend je zde k disposici pouze webové rozhraní se všemi nedostatky tak, jak bylo zmíněno již výše. Na druhé straně je to ale celkem šikovný frontend, který by mohl být zajímavý jako přídatné rozhraní k jiným solidním databázovým backendům, např. k databázi GnuMed, která poskytuje rozhraní, které je pro tento účel dostatečně flexibilní.

Jedná se o kompletní klinickou a administrační aplikaci pro provozovatele psychiatrických léčeben, i když je toto programové vybavení určené k tomu, aby vyšlo vstříc celému ústředí CMHC (Community Mental Health Care Center) anebo provozovatelům soukromé praxe (ať již klinickým sociálním pracovníkům či psychiatrům), pracujícím v oblasti behavioralního zdravotnictví. Technická podpora je volná prostřednictvím e-mailových diskusních skupin. Podpůrné smlouvy jsou k disposici u katolických zdravotních center sv. Vincenta v New Yorku.

Jako databázový backend je zde použit PostgreSQL a webové rozhraní je vytvořeno v Perlu. V uvedené specifické oblasti (tj. psychiatrie atp.) je tento systém již reálně nasazen a nyní je nutno ještě ověřit, jak je možné jej adaptovat pro obecnější případ. ... a další ...

Mohli bychom uvést ještě hrstku dalších programů, které se pokouší pokrýt tu samou oblast.

Na co je nám tolik svobodných programů pro správu pacientských dat?

[editovat]

Vypadá to hrozně, že tu máme tolik programů pro správu pacientských dat s více či méně shodnými cíli. I když by mohlo mít smysl rozlišovat mezi samostatnou ordinací všeobecného lékaře a správou celé nemocnice, ve skutečnosti nemá smysl psát rozličné kusy svobodného softvéru k pokrytí přesně toho samého účelu.

Avšak tato různorodost má své důvody:

Za prvé jsou to jednosuše důvody historické. Kdosi musel čelit situaci, že jeho (či její) proprietární systém nevyhovuje jeho očekáváním a tak nastartoval projekt, přičemž k tomu použil takové nástroje, jaké mu jeho dovednosti a znalosti dovolily. Naneštěstí se různí vývojáři jen velmi málo mezi sebou domlouvali.

Navíc probíhala počáteční fáze víceméně v tichosti a projekty byly relativně obskurní. Tím pádem o sobě lidé s podobnými úmysly nevěděli.

V důsledku takových rozdílných technických rozhodnutí a rozdílných návrhů není skutečně snadné spolu tak rozdílné projekty spolu propojit v jejich současném stavu.