View Full Version : Anwendbar für Medizin


Felbion
10-14-2010, 03:23 AM
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
10-14-2010, 06:21 AM
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
10-14-2010, 06:41 AM
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
10-14-2010, 01:25 PM
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 (http://pocketbook-free.sourceforge.net/sdk.shtml) 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 (http://sourceforge.net/apps/mediawiki/pocketbook-free/index.php?title=Main_Page) 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
10-14-2010, 01:56 PM
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
10-14-2010, 02:01 PM
Hi,


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
10-14-2010, 03:29 PM
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
10-14-2010, 05:18 PM
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.

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
10-15-2010, 01:57 AM
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
10-15-2010, 05:53 AM
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... :thumbsup:

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

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

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.:xmas:

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? :blink:

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
10-15-2010, 06:25 AM
:offtopic:

;)
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 (http://www.entourageedge.com/devices/entourage-edge.html)und hier (http://wiki.mobileread.com/wiki/EnTourage_eDGe)) 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
10-15-2010, 06:38 AM
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.

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
10-15-2010, 07:02 AM
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
10-15-2010, 09:37 AM
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
10-15-2010, 09:50 AM
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.
:thanks:

derSeher
10-15-2010, 10:00 AM
Das sehe ich Hardware-technisch auch so, aber wenn die Firmware nicht entsprechend anpassbar ist, leider nicht nutzbar.

Leider... Aber geben wir PB eine Chance, relativ junges Unternehmen, konzentrierte sich auf neue Geräte...

Aber PB darf tatsächlich den Trumpf "Open Source" nicht verspielen: auch wenn ein SDK für den CS-Teil da ist; je mehr damit was machen können, desto besser für PB... :)


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?

Gibt genug die nach ner ordentlichen Doku schreien, ich würd meinen: sobald die da ist, dürfte es genug interessierte Programmierer geben... (würde im Prinzip ja auch die PB-Entwickler entlasten, die Community würde sekundieren)

mtravellerh
10-15-2010, 01:59 PM
Oder einfach: lesen.



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



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.
:thanks:

Ja, dürfte möglich sein, die von Dir erwähnten Änderungen auszuführen. Frage bleibt, ob das sich lohnt (wäre etwa ab 500 Stück überlegenswert)

mtravellerh
10-15-2010, 02:10 PM
Leider... Aber geben wir PB eine Chance, relativ junges Unternehmen, konzentrierte sich auf neue Geräte...

Aber PB darf tatsächlich den Trumpf "Open Source" nicht verspielen: auch wenn ein SDK für den CS-Teil da ist; je mehr damit was machen können, desto besser für PB... :)



Gibt genug die nach ner ordentlichen Doku schreien, ich würd meinen: sobald die da ist, dürfte es genug interessierte Programmierer geben... (würde im Prinzip ja auch die PB-Entwickler entlasten, die Community würde sekundieren)

ja, hat auch hohe Priorität, dafür ist aber leider derzeit überhaupt niemand verfügbar.

derSeher
10-15-2010, 03:24 PM
ja, hat auch hohe Priorität, dafür ist aber leider derzeit überhaupt niemand verfügbar.

Nun, philosophisch betrachtet würde sich mir die Frage stellen "was ist wichtiger - ein weiteres Android-Tablet, oder erstklassige (& grossformatige) eBook-Reader mit OpenSource und Community, die fleissig für das PB entwickelt?"

;)

Mir ist schon klar, dass das IQ eine eBook-Welt in bunten Farben eröffnet - aber im Prinzip ist es "nichts weiter" als ein Android-Tablet mit Bookland-Anschluss...

Felbion stellt ein paar berechtigte Punkte in den Raum; gerade mit den 90x eröffnet sich PB einen Markt (also - theoretisch zumindest), der sehr sehr viel Potential bietet da von praktisch jedem Hersteller bisher ignoriert wurde... Für die Schule entwickelt, könnte sich das Teil mit den richtigen Software-Erweiterungen bald zu einem Überrenner mausern - wenn die Software stimmt...

mtravellerh
10-15-2010, 04:36 PM
Felbion stellt ein paar berechtigte Punkte in den Raum; gerade mit den 90x eröffnet sich PB einen Markt (also - theoretisch zumindest), der sehr sehr viel Potential bietet da von praktisch jedem Hersteller bisher ignoriert wurde... Für die Schule entwickelt, könnte sich das Teil mit den richtigen Software-Erweiterungen bald zu einem Überrenner mausern - wenn die Software stimmt...

Wir sind uns dieses Potenzials bewusst und planen auch in die Richtung. Aber bitte gebt uns doch die Zeit, diesen Markt nachhaltig zu entwickeln.

Felbion
10-15-2010, 05:29 PM
Wir sind uns dieses Potenzials bewusst und planen auch in die Richtung. Aber bitte gebt uns doch die Zeit, diesen Markt nachhaltig zu entwickeln.

Klar bleibt euch diese Zeit!

Die Frage ist nur, wenn auf Fragen wie: "Wie open ist euer OpenSource?" nur irgendwer antwortet und nicht die dafür Zuständigen, bestenfalls mit einer konkreten Antwort, dann leibt das Ganze unter "ferner liefen" und "nicht durchdacht" bei den Verantwortlichen hängen.

Eine einfache Antwort wie beispielsweise: "Nach der Einführung am 15.11.2010 wird mit Hochdruck an der *Doku gearbeitet, die bis zum 15.01.2011 fertig ist." wirkt da bereits Wunder!!!einelfzwölfusw.

Als Testkunden biete ich mich gerne an, auch als Test-Programmierer und wenn da jemand (da bin ich nach den Antworten hier im Forum etwas sensibel geworden) Fragen hat gerne direkt an mich!

Aber um den Markt hier zu durchdringen, und das ist meiner Meinung nach für Erfolg zwingend erforderlich, bietet sich hier die Zusammenarbeit mit fremden Instituten und EDV-Abteilungen an. Dann lässt sich auch leichter eine Konkurrenz zu Amazon aufbauen, wenn nämlich deren Reader für solche Einsatzgebiete zu "closed" ist.

Viel Erfolg dabei!:bulb2:

Billi
10-16-2010, 03:03 AM
Hallo Felbion,

möglicherweise willst Du ja das Rad neu erfinden? Wenn ich mich richtig erinnere, gibt es das alles im Bereich der Tablet-PCs bereits seit einigen Jahren. Ich meine jetzt nicht das iPad, sondern "die guten alten Geräte" wie HP TC1100 oder Fujitsu5112. Die Firma Motion hat beispielsweise direkt ein "C5 Medical Tablet" herausgebracht. Vielleicht hilft es Dir weiter, wenn Du die Anzeigenseiten von medizinischen Fachzeitschriften durchforstest?

Felbion
10-16-2010, 11:31 AM
Hi,
danke für die Info. In der Tat kannte ich das c5 nicht.

Aber nach dem ich mir das angesehen habe, ist dies weder ein eInk Gerät noch beherrscht es genau diesen Arbeitsprozess schon von vorne herein.
Auf dem Gerät läuft ein Win. Die entsprechenden Programme müssen auch dort selbst implementiert werden. OK, die Win APIs sind zwar schon teilweise dokumentiert, der Aufwand bleibt aber ähnlich hoch. Und es ist kein eInk, also zum Lesen vieler Texte weniger geeignet. Bilder sollen keine verarbeitet werden, also ist ein Farbschirm nicht notwendig.

Vielleicht hätte ich meine Frage von der Anwendung unabhängig stellen sollen?

Billi
10-16-2010, 01:28 PM
Ja, ich weiß, dass dies kein e-ink-Gerät ist, ich wollte bloß allgemein auf die Tablets mit Wacom-Bildschirm aufmerksam machen, die einige deiner Punkte sehr gut erfüllen (Open Source Software mgl, Versenden von Dateien zum und vom Gerät, Korrekturen auf dem Gerät, sehr gute Notizfunktion..., der einzige Nachteil ist eigentlich ihre Batterieleistung).

Aber wenn eInk ein Muss ist:
- Zur Notizenfunktion der neuen Pocketbooks können wir Dir leider noch nichts sagen.
- Der Sony 650 bietet wohl eine sehr gute Notizfunktion, aber wollt Ihr die Texte von einem 15cm-Gerät abtippen?
- Du könntest Dir genauer die Fähigkeiten des Kindle anschauen. Er kann wohl - mittels Tastatur, nicht per Stift - Notizen erstellen, also Text korrigieren, außerdem hat er eine Synchronisationsfunktion zwischen Gerät und PC.
- Open Source gibt es bislang nur OpenInkpot, unterstützt werden damit nur Hanlin V3 und Hanvon N510/6

frostschutz
10-16-2010, 01:31 PM
Der Thread erinnert mich an diese Geschichte hier:

http://thedailywtf.com/Articles/Lock-and-Key-.aspx

Wenn es um Korrektur geht ist es verdammt schwer, dem guten alten Papier + Rotstift mit Technologie beizukommen. Das schafft am ehesten noch die Tastatur.

eInk Geräte als Hardwareplattform halte ich für vollkommen ungeeignet. Die Displays sind so stark auf statische Inhalte hin ausgelegt daß jede ansatzweise interaktive Anwendung da Probleme bekommt, und gerade für Notizen und Gekrakel müsste man eine viel höhere Auflösung haben... das wird auch auf Tablets schwierig.

mtravellerh
10-16-2010, 03:03 PM
eInk Geräte als Hardwareplattform halte ich für vollkommen ungeeignet. Die Displays sind so stark auf statische Inhalte hin ausgelegt daß jede ansatzweise interaktive Anwendung da Probleme bekommt, und gerade für Notizen und Gekrakel müsste man eine viel höhere Auflösung haben... das wird auch auf Tablets schwierig.

Das halte ich für ein absolutes Vorurteil

kbaerwald
10-17-2010, 04:35 AM
Ich habe jahrelang in diesem Umfeld (Labor etc.) gearbeitet. Man möge auch bei eInk Technologien berücksichtigen:

Performance der Geräte im Laboralltag: Schnelligkeit , Stift- oder Touchbedienung im Arbeitsalltag geeignet (ist keine einfache Arztpraxis sondern ein Institut)
Wie schaut es mit der Validierbarkeit aus? Da Unterschriften erforderlich sind muss auch die Einbindung der eReader validiert werde, evtl sogar muss der Hersteller eine QK nachweisen
Ist der eReader im Laborbereich belastbar? Ich habe letztens einen eReader beim Regenguss geschrottet.
Die eReader Technologie steht erst am Anfang, ich glaube Du musst daher auch zu einiger Pioniertätigkeit bereit sein.

EDIT: RumpelStiez hat Dich zwar etwas angegröbelt, aber das von ihm zitierte Grundprinzip stimmt. Ich würde mir einen grundsätzlichen Kriterienkatalog für den Einsatz von Technologien für das Projekt bilden und dann die Technologie "aussuchen".

Vermutlich habt ihr das aber schon in die Wege geleitet. Lasst Euch doch einmal von PocketBook ein Exemplar zuschicken und schaut, ob die Basiskriterien eingehalten werden. Dazu muss noch keine spezifische Funktion implementiert sein.

Nur ein Vorschlag
Klaus