A Szabad Szoftver Intézet újabb segítsége az egészségügynek

Címkék

A Szabad Szoftver Intézet a Stetoscope projekt keretében ismét segít az egészségügynek. Az OJOTE az OEP által 2007 márciusában bevezetett internet TAJ-szám ellenőrző webalkalmazás és szolgáltatás. Mivel április 1-vel (nem tréfa!) kötelező lesz az egészségügyi szolgáltatóknak a TAJ szám alapján a biztosítási jogosultságot ellenőrizni, az SzSzI elkészítette a klins szabad szoftveres változatát. Az Ojoteclient fejlesztői változata kipróbálható itt. A kipróbáláshoz jelszó szükséges. A kliens forráskódja a tesztelés után GPL alatt kerül publikálásra.

Hozzászólások

Ha kiprobalhato ES jelszo szukseges hozza, akkor esetleg elmondhatnad, hogy mi az VAGY javithatnad a cikket, hogy megsem kiprobalhato.

Minden hónapban hírértéket képvisel egy három formból álló helloworld-variáns megjelenése a SzSzI jóvoltából.
Egyébként hol a forrás ha már SZABAD ilyet kérdezni?

Nem a form a lényeg, hanem a mögötte álló technológia, amit az OEP előír.
Sajnos a hírből kimaradt (pedig szerintem beleírtam), hogy a forrás a tesztek után GPL alatt kiadásra kerül.

A dolog komolyságára jellemző, hogy minden egészségügyi intézménymek kell április 1-től a jogosultságot ellenőrizni.
Hidd el a kipróbáláshoz a jelszó nem viccből, vagy a mi kedvtelésünk miatt szükséges.

Egyébként visual basic mintát adtak a megvalósításra. Mi megcsináltuk perlben, jeleneleg a tesztjei folynak.

"(pedig szerintem beleírtam)"

Ha beleírtad, akkor benne lenne. Vagy még azt tudom elképzelni, hogy egy rosszul lezárt html tag miatt "elnyelődött" (volt már ilyenre példa). Ha valami hiányzik belőle, és szeretnéd ha benne lenne, akkor légyszi küldd el a trey () hup ! hu címre.

--
trey @ gépház

Köszönöm, Igyekszünk. Minden kis lépésünk mögött sok munka és sok egyeztetés van. Igazából az a kitűzött célunk, hogy az egészségügyben, ahol csak lehet biztosítsuk a szabad szoftveres alternatívát, nem szeretnénk ha ott lenne egy új ABEV (kötelező használni, és csak win alatt megy, persze nem publikus adatformátumokat használva).

Nem nyalizni akarok, de az OEP az APEHhez képest eddíg remek partner, lehet velük egyeztetni, az APEHel ellentétben adnak érdemi és használható információt. Sajnos nem mindenki rajong az OEPben se a szabad szoftverekért, de legalább nem zárkóznak el előle.

hehe, perlben, gratulalok. szerintem senki ne menjen orvoshoz, ha valtoznak a torvenyek es/vagy bonyolodik az architektura ;]
azt viszont valaki okos (!!!) megmondhatna, hogy minek a ket w3c kep az oldal aljara, magyaran ki a faszt erdekel, hogy valid vagy nemvalid vagy hogy css. de komolyan.

Miért ne lehetne megírni perlben? Ne felejtsd el, hogy a értelmezhetetlen kódolás világbajnokságát pl. Javaban is megnyerték már,
Minden nyelven lehet karbantartható vagy éppen karbantarthatatlan kódot írni.
Talán tudod, talán nem, de tény, hogy a PHP-t példaként tanítják mint kifejezetten rosszul tervezett és implementált nyelvet.

Ez nem jelenti azt, hogy PHP-ben nem lehet jó minőségű kódot írni. (Csak nehezebb, mint hinnéd)

A w3c logókról

Az oldal CSS-el átalakítható, s ami a lényeg szoktatjuk az érintetteket hozzá, hogy lehet (kell is) w3c kompatibilis oldalakat készíteni.

Erről még a Google se hallott: "Your search - site:hu ojote - did not match any documents."

--
hup.user.js

Na és?

Az OJOTE (On-line Jogviszony és TAJ Ellenőrző) rendszer funkcióit, az arra jogosult külső felhasználók szabványos, Web szolgáltatás (WEB SERVICE) felületen keresztül érhetik el.
...
A kliens program a SOAP protokollt kell használja egy, a WSDL állományban definiált funkció meghívására. A SOAP egy egyszerű objektum elérési protokoll, számítógépes hálózaton történő XML alapú üzenet cserére (alapesetben HTTP használatával). A SOAP egy olyan Web szolgáltatás réteget biztosít, amely alapvető üzenet kezelő szolgáltatásokat nyújt a kliens program számára.
...

Na ja, most szívtam vele.

Átraktam egy rosszul encode-olt PHP adatbázist ASCII-ről UTF-8-ra, és vicsorogva vettem tudomásul, hogy a serialize 1) nem rögzít encode paramétert 2) stringek esetén a byte-ok számát rakja le, nem a karakterekét 3) tehát írhattam php-s konvertálót, mert képtelen volt visszaolvasni a torzult méretű ékezetes stringeket. Tragédia nem történt, de azért meglepett.

Lehet attol hogy nem kuld olyan levelet a regisztracional ami ISO-8859-2 kodolasu, de nincs benne sem Content-Type: header (korrekt codepage megadassal termeszetesen) sem "Content-Transfer-Encoding: 8bit"

Tudtommal ilyen esetben a level ASCII kodkeszletu, 7 bites (Eljen az USA nemzeti ontudat)

Javitsatok ki ha rosszul tudom.