Anwendbar für Medizin

[Felbion]

Hallo,

vielleicht ist der Betreff etwas irreführend.

Also ganz konkret geht es darum, dass wir planen, den Papierverbrauch in unserem Institut zu reduzieren und ein Gedanke war, dafür auch E-Ink-Geräte zu verwenden. Da das PocketBook eine Opensource Softwarelösung bietet, starten wir hier einen ersten Versuch.

Kurz zum Arbeitsablauf:
Ein digital übertragenes Diktat wird getippt, dann ausgedruckt, dann Korrektur gelsen. Da dabei eine große Menge an medizinischen Fachausdrücken anfällt, wird das eine ums andere Mal etwas korrigiert, erneut getippt und wieder ausgedruckt. Ein Befund hat dabei zwischen meist zwischen 2 und 6 Seiten.

Der Papieraufwand ist also schon ziemlich groß.

Um Diesen zu reduzieren also die Idee:
diktieren -> schreiben -> per WLan auf den Reader des Arztes, der ggf. unterschreibt oder korrigiert -> je nach dem wird der Befund dann (bestenfalls elektronisch unterschrieben) ausgedruckt oder erneut getippt und landet wieder bei Arzt.

Lässt sich so ein Workflow mit dem PB umsetzten?
Gibt es eine Geräteabhänge Push-Funktion (mehrere Ärzte, jeder mit eigenem Gerät)?
Da sich die Ärzte auch mal gegenseitig helfen, gibt es eine Möglichkeit, die Befunde von einem Gerät auf das nächste zu schicken?
Gibt es die Möglichkeit, mit eine qualifizierten Signatur zu unterschreiben?

Danke erstmal für eure Mühe und Antworten

Felbion

[Forkosigan]

Originally Posted by Felbion

Hallo,

vielleicht ist der Betreff etwas irreführend.

Also ganz konkret geht es darum, dass wir planen, den Papierverbrauch in unserem Institut zu reduzieren und ein Gedanke war, dafür auch E-Ink-Geräte zu verwenden. Da das PocketBook eine Opensource Softwarelösung bietet, starten wir hier einen ersten Versuch.

Kurz zum Arbeitsablauf:
Ein digital übertragenes Diktat wird getippt, dann ausgedruckt, dann Korrektur gelsen. Da dabei eine große Menge an medizinischen Fachausdrücken anfällt, wird das eine ums andere Mal etwas korrigiert, erneut getippt und wieder ausgedruckt. Ein Befund hat dabei zwischen meist zwischen 2 und 6 Seiten.

Der Papieraufwand ist also schon ziemlich groß.

Um Diesen zu reduzieren also die Idee:
diktieren -> schreiben -> per WLan auf den Reader des Arztes, der ggf. unterschreibt oder korrigiert -> je nach dem wird der Befund dann (bestenfalls elektronisch unterschrieben) ausgedruckt oder erneut getippt und landet wieder bei Arzt.

Lässt sich so ein Workflow mit dem PB umsetzten?
Gibt es eine Geräteabhänge Push-Funktion (mehrere Ärzte, jeder mit eigenem Gerät)?
Da sich die Ärzte auch mal gegenseitig helfen, gibt es eine Möglichkeit, die Befunde von einem Gerät auf das nächste zu schicken?
Gibt es die Möglichkeit, mit eine qualifizierten Signatur zu unterschreiben?

Danke erstmal für eure Mühe und Antworten

Felbion

Theoretisch alles mit 603/903 möglich, braucht aber Arbeit von Programmierer, um es zu realisieren.

Also, bei 50 Geräten lohnt es sich nicht, bei 500 ist wahrscheinlich möglich. Aber erst am Anfang 2011, zurzeit sind die Programmierer stark überlastet.

[Felbion]

Originally Posted by Forkosigan

Theoretisch alles mit 603/903 möglich, braucht aber Arbeit von Programmierer, um es zu realisieren.

Also, bei 50 Geräten lohnt es sich nicht, bei 500 ist wahrscheinlich möglich. Aber erst am Anfang 2011, zurzeit sind die Programmierer stark überlastet.

Hallo,

das ganze muss dabei natürlich als Pilotprojekt verstanden werden.
Sollte das alles Laufen, wäre eine Ausweitung auf das rechtliche Klinikpersonal möglich, bsp. zur Verwaltung von elektronischen Patientenakten.

Eine andere Frage:
Das PB wird als OpenSource beworben.
Da das Klinikum eine eigene EDV-Abteilung hat, sind auch folgende Fragen interessant:
Wie open ist denn die Source?
Ist es möglich, spezielle API´s anzusprechen? Sind diese dokumentiert?
Ist es möglich Eingriffe in der Firmware vorzunehmen? (Der Root-Zugang ist wohl noch nicht möglich?)
Ist es möglich, beispielsweise mit Java oder C eigene Programme / Apps zu schreiben?

Danke

[reader42]

Originally Posted by Felbion

Hallo,
Wie open ist denn die Source?
Ist es möglich, spezielle API´s anzusprechen? Sind diese dokumentiert?
Ist es möglich Eingriffe in der Firmware vorzunehmen? (Der Root-Zugang ist wohl noch nicht möglich?)
Ist es möglich, beispielsweise mit Java oder C eigene Programme / Apps zu schreiben?

Leider nicht sehr open Den Quellcode gibt es leider nur vom Kernel und FB-Reader weil die schon open source waren.
Ansonsten gibt es hier ein SDK für Windows und Linux. (Die englische Seite verweißt leider schon seit Monaten auf eine veraltete Version.) Leider ist die einzige Dokumentation ein spärlich kommentiertes Header-file der API und ein Beispiel, das nur Teile der der API nutzt. Hier wurde der Versuch gestartet ein bisschen Doku zu sammeln, leider fehlt mir gerade die Zeit das weiter zu machen, sonst hat sich leider noch niemand gefunden. Die API ist in C, es können also Programme in C/C++ geschrieben werden.
Angeblich soll mit den neuen Modellen da noch mehr kommen, was hat aber noch niemand verraten.

[Felbion]

Das ist natürlich sehr schade!
Dann wäre man ja für solche exotischen Sonderwünsche auf den Anbieter angewiesen...??!!
Was ja dann dem OS-Gedanken zuwider läuft.

Gibt es hierfür evtl. Alternativen?
Andere Geräte mit OS-BS habe ich noch nicht gefunden.
Weiß hier vielleicht jemand mehr?
Androidgeräte mit E-Ink gibt es auch keine brauchbaren, oder?
Obwohl Google ja nicht gerade für Datenschutz steht und Patientendaten damit zu verarbeiten.... ein kleines bammeliges Gefühl....

Aber ich bin auf Vorschläge gespannt!

[Bratzzo]

Hi,

Originally Posted by Felbion

Um Diesen zu reduzieren also die Idee:
diktieren -> schreiben -> per WLan auf den Reader des Arztes, der ggf. unterschreibt oder korrigiert -> je nach dem wird der Befund dann (bestenfalls elektronisch unterschrieben) ausgedruckt oder erneut getippt und landet wieder bei Arzt.

warum der ganze Aufwand?

Ich gehe mal davon aus, dass der Schreiber des Textes und der Lektor einen PC haben.
Wäre es da nicht viel einfacher, das Diktat als (Word) Datei auf einem Server zu speichern? Dort kann der Lektor die Datei öffnen, bearbeiten und wieder abspeichern.

Zur Not kann man auch noch den Umweg über Mail nehmen.



Bratzzo

[reader42]

Originally Posted by Felbion

Das ist natürlich sehr schade!
Dann wäre man ja für solche exotischen Sonderwünsche auf den Anbieter angewiesen...??!!

Man kann schon selbst Programme schreiben, das ganze ist gerade nur etwas schwierig, weil die Dokumentation nicht so toll ist.

[Felbion]

Originally Posted by Bratzzo

Hi,

warum der ganze Aufwand?

Nun das ganze wird sehr wohl am PC getippt.
Da sich aber das ganze nicht nur um ein paar Briefe dreht, sondern da durchaus 20 - 60 Befunde (je nach Umfang) pro Arzt und Tag auflaufen und die eigentlich nicht so gern Tippen und schon gar nicht am Bildschirm die ganzen Texte lesen wird dieser Zirkus betrieben.
Das nächste ist, dass die Befunde in einer Art Datenbank verarbeitet werden und z.T. auch elektronisch weiter versandt werden und "nur" zum Lesen, Unterschreiben und Archivieren ausgedruckt werden (das hat auch rechtliche Gründe, deswegen die qualifizierte Signatur).

Die Ärzte sitzen teilweise stundenlang am Mikroskop und brauchen dann zum konzentriert Lesen eben doch etwas Augen schonendes wie Toner auf Papier oder evtl. e-Ink.

Das ganze System läuft so ganz gut, nur der Papierverbrauch ist enorm. Das bedeutet, das System an sich sollte möglichst so beibehalten werden (was der Bauer nicht kennt, frisst er nicht) nur mit weniger Papierverbrauch.

Da das bisher noch keiner umgesetzt hat/anbietet, kam mir eben die Idee ein Quelloffenes dahingehend anzupassen. Und ich schaue mich nach derartigen Möglichkeiten um. Sammle Vorschläge etc.

Originally Posted by reader42

Man kann schon selbst Programme schreiben, das ganze ist gerade nur etwas schwierig, weil die Dokumentation nicht so toll ist.

Ist absehbar, dass das besser wird?
Wenn die EDV´ler sich durch Quellcode ohne Doku arbeiten müssen, werden die wahnsinnig, genauso bei un- bis schlecht dokumentierten API´s.

So kann ich damit keinen Hund hinter dem Ofen vorlocken...

Danke für euer Interesse, hoffe dass evtl auch positive Vorschläge kommen

[RumpelStielz]

Die Korrekturanweisung auf Papier ist in puncto Effizienz nicht zu schlagen (ich weiß, wovon ich spreche). Wenn die Korrekteure/innen nicht am PC direkt auf der zu korrigierenden Datei arbeiten, sind IT-gestützte Lösungen immer langsamer, umständlicher, unhandlicher und schlechter zu benutzen als Papier und Stift.

Versuche zunächst, den Prozeß in seiner Gesamtheit und bis in die Details geistig zu durchdringen und erst dann befasse Dich mit Überlegungen, wie man ihn verbessern kann. Der Weg, ausgehend von verfügbarer Technik nach damit optimierbaren Prozessen Ausschau zu halten, ist ein Irrweg.

Aber falls doch: Es gibt seit geraumer Zeit eine Apparatur, mit der man aus Altpapier Toilettenpapier herstellen kann (geisterte in den letzten Monaten durchs Netz). Das senkt zwar nicht den Papierverbrauch, könnte jedoch die Prozesse verschlanken (die Ausdrucke müssen doch sicherlich kontrolliert vernichtet werden?)

Und eins noch, junger Freund: Jeder mögliche Geldgeber wird begeistert sein zu erfahren, daß Du ihn als hinter dem Ofen hervorzulockenden Hund bezeichnest...

[Felbion]

Es ist ziemlich interessant, wie hier geantwortet wird.

In einem Forum für mobile Lesegeräte wird mir vorgeschlagen, die Texte einfach am PC-Bildschirm zu lesen...

Dann wird mir unterstellt, Prozesse, die ich verbessern will, nicht komplett zu durchschauen...

Dass das Gekritzel auf den Befunden so wertvoll ist, weiß ich selbst. Jedes mal wenn ich es entziffern muss...
Deshalb kam ja auch das 903 in Betracht, das ja datsch-skrien hat

Mal abgesehen davon, dass ich vielleicht doch in der Lage bin meine Arbeit in Gänze zu erfassen, wollte ich hier mein Alter übrigens nicht weiter diskutieren.

Und dass ich dann den Geldgeber nicht zwingend mit diesem Forum bekannt mache (was den ja auch nicht die Bohne interessiert), sondern die Infos entsprechend aufarbeite, dürfte selbstverständlich sein. Oder wie macht Ihr so was?

Naja, bisher kam ja leider nicht so viel rum, evtl. kommt ja noch mehr Substanz, aber trotzdem danke schon mal für eure Mühe.

[beachwanderer]

Was erwartest Du von der Forennutzung? - Hier soll jeder Fragen stellen dürfen und hier kann jeder Anworten geben. Innerhalb der Forenregeln.

On Topic:

Weißt Du, welche Funktion ich bei meinem enTourage eDGe (vgl zum Gerät z.B. hier und hier) schätzen gelernt habe? Die Möglichkeit, auf dem eInk-Touchscreen mit Hervorhebungen und Anmerkungen versehene PDF aus dem Reader heraus per eMail zu versenden. Sehr praktisch.

Gruß

beachwanderer

[RumpelStielz]

Originally Posted by Felbion

Deshalb kam ja auch das 903 in Betracht, das ja datsch-skrien hat

Verschaffe Dir Zugriff auf ein entsprechendes Lesegerät oder eine adäquate Versuchsanordnung und versuche, damit handschriftlich Korrekturen so zu erfassen, wie sie im Alltag vorkommen. Bedenke dabei optische und physikalische Auflösung. Wenn das schneller und einfacher geht als auf Papier, denke über den nächsten Schritt nach.

Identifiziere den Kernprozess und beginne mit diesem anstatt mit den Unterstützungsprozessen. Darin besteht die geistige Durchdringung.

Originally Posted by Felbion

Und dass ich dann den Geldgeber nicht zwingend mit diesem Forum bekannt mache (was den ja auch nicht die Bohne interessiert), sondern die Infos entsprechend aufarbeite, dürfte selbstverständlich sein. Oder wie macht Ihr so was?

Es betrifft Deine Geisteshaltung, unanbhängig davon, ob dein Geldgeber mitliest oder nicht. Wenn Du anderen gegenüber keinen Respekt zeigst, wie sollte jemand Dich respektieren?

[Felbion]

Hallo,

ich denke das ist das falsche Forum um über It- und/oder Corporate-Governance, Projektmanagement und Prozessoptimierung zu diskutieren. In meiner Frage ging es nicht darum, wie sinnvoll eine solche Änderung im Prozess-Ablauf des Institutes ist oder wie wir am besten unsere Arbeit erledigen und auch nicht darum, welche Ziele ich damit verfolge.
Es ging auch nicht darum, wie ich wem was wie verkaufe/vermittle oder wem ich Respekt entgegen bringe und wieviel.

Mal davon ausgehend, da du andere unbekannterweise als "junger Freund" betitelst, selbst sehr betagt bist... ach lassen wir das...

Ich wollte nur wissen, ob es möglich ist, selbst Programme zu entwickeln und wie offen die Quellen wirklich sind, bevor ich mir irgend etwas anschaffe/anschaffen lasse.

Leider ist das wohl nicht sonderlich weit gediehen, was mich also dazu zwingt, noch etwas zu warten...
Gibt es OpenSource-Alternativen zu PocketBook mit ähnlicher Ausstattung?

[derSeher]

Ich schätze das hängt weniger mit dem Forum, als eher mit dem "Existenzgrund" von Readern wie den Pocketbooks zusammen: Bücher lesen.

Ich schrieb es in einem anderen Zusammenhang schon einmal: ich glaube nicht, das Pocketbook sich bewusst ist, was sie mit 302, 603 und 903 für Perlen im Angebot haben... (das 302/603 würde sich bsp. mit Mic-In hervorragend für Interviews, oder Protokollgerät eignen, andere Anwendungen möglich)

Was deinen Prozess angeht, gibt es sicher Möglichkeiten den Papierverbrauch durch Verwendung von eReadern einzuschränken. So wie ich das verstanden habe, geht es aber auch um die Einarbeitung von Korrekturen bei den Abtippern... Dort weis ich aus eigener Erfahrung - nichts geht über den korrigierten Text neben dem Bildschirm/Tastatur, um am Bildschirm die Korrekturen einzuarbeiten...

Jedoch könnte ein 903 schon eine grosse Abhilfe im Papierverbrauch darstellen...
Es gäbe aber noch eine Möglichkeit; Spracherkennung:

Der Ablauf skizziert sich mir momentan wie folgt:
- Arzt macht Notizen auf herkömmlicher Akte
- Arzt diktiert die Akte/Notiz auf Band (od. digitales Diktiergerät)
- Assistentin/MPA tippt das Band ab
- Arzt bekommt (auf Papierform) die erste Version
- korrigiert diese
- retourniert die Korrekturversion zur A/MPA
- diese arbeitet Korrekturen ab, reicht Version 2 dem Arzt
- dieser korrigiert erneut/segnet ab...


Ich würde (basierend auf obiger Prozessskizzierung), wenn ihr auf ePaper umsteigen wollt, gleich noch nen Schritt machen:
Spracherkennungssoftware kostet nicht mehr die Welt, und kann - also bekannteste Programme zumindest - auf mehrere Anwender (und vor allem: Fachchinesisch, Profi-Programme bringen sogar vorgelernte Branchendictionäre mit) trainiert werden (auch gängige Abkürzungen als "ausgeschrieben" ersetzt)...

Der Ablauf könnte dann so aussehen:
- Arzt notiert in Akte
- " diktiert die Notizen in's Dictaphone/ev. (je nach vorhandener Infrastruktur od. Präferenz des Arztes) direkt in die Spracherkennungs-Soft
(- Dictaphone-Version wird über Spracherkennungssoft gestülpt -> Audio-Out des Dictaphone an Mic-In & Play-Taste *)
- Spracherkennungssoft "schreibt" das ganze in ein Dokument (Makro "Diktat Ende" oder "Abschluss", oder was bei euch als Ende genommen wird, löst "Datei speichern unter" (BN/Timestamp) aus)
- Dokument wird auf eReader-Device übertragen
- Arzt liest korrektur, fügt diese ein, durch Absegnen (hier müsste dann tatsächlich Aufwand betrieben werden, bez. "einfaches Senden der Datei" -> Fork, Mth: wird es bei x03 einen Dateimanager geben?) wird die Datei zu Assistent/MPA geschickt, welche die Korrekturen des Arztes (verm. via Notizfunktion angezeigt) in das Original einarbeitet...
- Arzt bekommt dann die ausgedruckte Version (ich nehm an, aus rechtlichen Gründen werdet ihr mind. eine Hardcopy benötigen) oder die korrigierte Fassung wieder auf den Reader, unterschreibt, und retourniert
- archivieren...

Es wäre ein Pilotversuch wert, bsp. 5 Ärzte für den Anfang (als überschaubare Gruppe), den Test optimieren etc, im Prinzip bräuchte man dafür nur
- eine Lösung für den Filetransfer (für das korrigierte Dokument, also orig. Datei & Korrekturnotizen)
- Spracheingabesoftware
- vorerst nur Programme für Dateitransfer auf das, und von dem PB **
- freiwillige Tester
- natürlich 903er (wg. der Ausstattung)

.o(wenn natürlich mit den Wacom-Displays auch irgendwann eine Schrifterkennung folgt, würde sich das korrigieren ja gleich direkt im Dokument realisieren lassen - ODT machts möglich

* konnte ich neulich bei meinem Hausdoc sehen, da ist jetzt ein Junger dort, der macht das genau so; ev. gibt es eine Möglichkeit, das Spracherkennungsprogramme Audiodateien direkt (ohne 1:1 abspielen) verarbeiten können, was dann für den Einsatz digitaler Geräte sprechen würde -> Files überspielt, verarbeitet, feddich

Edit:
** VORERST: weil die Notizfunktion vom PB (so wie für die neuen Geräte beschriebenen "in Dokument-Notizen") übernommen wird; ein Dateimanager, Fork, Mth & Co (auch die, die für PB Software schreiben), ist überfällig: es gibt keine Möglichkeit, vom PB auf ein Share zuzugreifen, und Dateien zu ziehen, oder raufzuladen (ohne sich über den Browser zu mühen, und auch da nur "einfach" downloaden möglich)

[Felbion]

Originally Posted by derSeher

Ich schätze das hängt weniger mit dem Forum, als eher mit dem "Existenzgrund" von Readern wie den Pocketbooks zusammen: Bücher lesen.

Oder einfach: lesen.

Ich schrieb es in einem anderen Zusammenhang schon einmal: ich glaube nicht, das Pocketbook sich bewusst ist, was sie mit 302, 603 und 903 für Perlen im Angebot haben... (das 302/603 würde sich bsp. mit Mic-In hervorragend für Interviews, oder Protokollgerät eignen, andere Anwendungen möglich)

Das sehe ich Hardware-technisch auch so, aber wenn die Firmware nicht entsprechend anpassbar ist, leider nicht nutzbar.

Was deinen Prozess angeht, gibt es sicher Möglichkeiten den Papierverbrauch durch Verwendung von eReadern einzuschränken. So wie ich das verstanden habe, geht es aber auch um die Einarbeitung von Korrekturen bei den Abtippern... Dort weis ich aus eigener Erfahrung - nichts geht über den korrigierten Text neben dem Bildschirm/Tastatur, um am Bildschirm die Korrekturen einzuarbeiten...

Jedoch könnte ein 903 schon eine grosse Abhilfe im Papierverbrauch darstellen...
Es gäbe aber noch eine Möglichkeit; Spracherkennung:

Der Ablauf skizziert sich mir momentan wie folgt:
- Arzt macht Notizen auf herkömmlicher Akte
- Arzt diktiert die Akte/Notiz auf Band (od. digitales Diktiergerät)
- Assistentin/MPA tippt das Band ab
- Arzt bekommt (auf Papierform) die erste Version
- korrigiert diese
- retourniert die Korrekturversion zur A/MPA
- diese arbeitet Korrekturen ab, reicht Version 2 dem Arzt
- dieser korrigiert erneut/segnet ab...


Ich würde (basierend auf obiger Prozessskizzierung), wenn ihr auf ePaper umsteigen wollt, gleich noch nen Schritt machen:
Spracherkennungssoftware kostet nicht mehr die Welt, und kann - also bekannteste Programme zumindest - auf mehrere Anwender (und vor allem: Fachchinesisch, Profi-Programme bringen sogar vorgelernte Branchendictionäre mit) trainiert werden (auch gängige Abkürzungen als "ausgeschrieben" ersetzt)...

Der Ablauf könnte dann so aussehen:
- Arzt notiert in Akte
- " diktiert die Notizen in's Dictaphone/ev. (je nach vorhandener Infrastruktur od. Präferenz des Arztes) direkt in die Spracherkennungs-Soft
(- Dictaphone-Version wird über Spracherkennungssoft gestülpt -> Audio-Out des Dictaphone an Mic-In & Play-Taste *)
- Spracherkennungssoft "schreibt" das ganze in ein Dokument (Makro "Diktat Ende" oder "Abschluss", oder was bei euch als Ende genommen wird, löst "Datei speichern unter" (BN/Timestamp) aus)
- Dokument wird auf eReader-Device übertragen
- Arzt liest korrektur, fügt diese ein, durch Absegnen (hier müsste dann tatsächlich Aufwand betrieben werden, bez. "einfaches Senden der Datei" -> Fork, Mth: wird es bei x03 einen Dateimanager geben?) wird die Datei zu Assistent/MPA geschickt, welche die Korrekturen des Arztes (verm. via Notizfunktion angezeigt) in das Original einarbeitet...
- Arzt bekommt dann die ausgedruckte Version (ich nehm an, aus rechtlichen Gründen werdet ihr mind. eine Hardcopy benötigen) oder die korrigierte Fassung wieder auf den Reader, unterschreibt, und retourniert
- archivieren...

Es wäre ein Pilotversuch wert, bsp. 5 Ärzte für den Anfang (als überschaubare Gruppe), den Test optimieren etc, im Prinzip bräuchte man dafür nur
- eine Lösung für den Filetransfer (für das korrigierte Dokument, also orig. Datei & Korrekturnotizen)
- Spracheingabesoftware
- freiwillige Tester
- natürlich 903er (wg. der Ausstattung)

.o(wenn natürlich mit den Wacon-Displays auch irgendwann eine Schrifterkennung folgt, würde sich das korrigieren ja gleich direkt im Dokument realisieren lassen - ODT machts möglich

* konnte ich neulich bei meinem Hausdoc sehen, da ist jetzt ein Junger dort, der macht das genau so; ev. gibt es eine Möglichkeit, das Spracherkennungsprogramme Audiodateien direkt (ohne 1:1 abspielen) verarbeiten können, was dann für den Einsatz digitaler Geräte sprechen würde -> Files überspielt, verarbeitet, feddich

Ja genau solche Optimierungen sollen möglich sein, aber wie bereits erwähnt, wenn zwar die Hardware prinzipiell alles kann, aber die Software das alles nicht mitmacht, braucht man gar nicht versuchen jemand davon überzeugen zu wollen.

Deshalb ist ja für mich interessant, ob es Möglichkeiten gibt, selbst Software zu erstellen/verändern oder (bevor mir jemand rät ich soll erstmal Programmieren lernen) dies in Auftrag zu geben.
Ist dies Möglich?
Gibt es (oder wird es geben) deutsch- oder englischsprachige Dokumentationen zu den APIs und deren Verwendung oder bestenfalls für ein OpenSource-Gerät die Software an sich?

Das mit der ukrainischen Seite zum SDK ist zwar nur suboptimal aber ein Anfang! Das werde ich mir mal ziehen und gucken ob ich damit klar kommen und wie weit das bereits entwickelt ist.