Blog

Am Swiss Open Data Hackday dieses Wochenende in Basel haben wir innerhalb von nur zwei Tagen eine interaktive Karte mit allen Krankenkassenprämien der Schweiz entwickelt.

Die interaktive Karte ist online unter: http://healthinsurance.opendata.ch

Ein Audio-Live-Mitschnitt der Schlusspräsentation ist auch verfügbar (http://infam.antville.org/stories/2137823)

Impressionen von "Open Data"-Enthusiasten beim Hacken: http://www.flickr.com/photos/ph64/sets/72157631649312225

Nachdem wir den Prämiendatensatz vom BAG erhalten haben und diesen mittels einem kleinen Tool (SHIP) in eine Datenbank gebracht haben, sind wir nun dabei die Prämiendaten zu visualisieren. Es ist allgemein bekannt, dass die Prämienunterschiede zwischen einzelnen Kantonen sehr gross sind.

Wir möchten die Daten auf einer interaktiven Karte darzustellen, so dass sich regionale Unterschiede einfach erkennen lassen. Für die Karte sollen sich dann dynamische Filter setzen lassen. Interessant könnten hier gewisse "Kovariablen" wie Ärzte- oder Spitaldichte sein. Auch die Entwicklung über Zeit ist sicherlich nicht uninteressant.

Für die interaktive Karten-App bauen wir auf die Applikation "Swiss Train Flows", welche am letzten Swiss Open Data Hackday in Zürich entstanden ist.

Im Team "SHIP" Swiss Open Data Hackday:

• Denis Krienbühl (https://github.com/href)
• Colin Frei (https://github.com/colinfrei)
• Patrick Staehlin (https://github.com/packi)
• Oliver Egger (https://github.com/oliveregger)
• Fabian Reinhard (https://github.com/freinhard)

Last but not least das GitHub Repository: https://github.com/seantis/ship

Stand der Arbeiten

Update FR 28.09.2012 17:30: Kantonsgrenzen auf die Karte zeichnen mit GeoJSON

Update FR 28.09.2012 18:48: Wir werden definitiv ein schönes Farbschema brauchen! Hier ein verdammt schönes Beispiel von http://mbostock.github.com/d3/talk/20111018/choropleth.html

Update FR 28.09.2012 19:24: Ich habe gerade die kleine Python Webapp auf meinem Notebook installiert:

• Die Karte wird geladen
• Die Kantonsgrenzen sehr ordentlich eingezeichnet!

Update FR 28.09.2012 19:46: Wir haben erste Farben! Wow!!

Update FR 28.09.2012 21:02: Wie visualisieren wir die Ärztedichte pro Kanton?

Update SA 29.09.2012 10:15: Tag zwei der Hackdays. Wir haben nun neue Farben mit mehr Bedeutung: rot = über den CH-Durchschnitt / grün = unter dem CH-Durchschnit

Update SA 29.09.2012 10:50: Eine erste Version unserer interaktiven Karten-App ist online: http://ship.seantis.ch

Eine Studie über den Verschreibungsprozess auf einer Station des Universitätsspitals Bern kam zum Schluss, dass Verschreibungsfehler wegen fehlender oder zweideutiger Angaben des Arztes häufig sind [http://www.nzz.ch/aktuell/schweiz/die-handschrift-der-halbgoetter-in-weiss-1.12848707].

Unter folgenden Bedingungen sind Fehler bei der Medikamentenabgabe wahrscheinlicher:

• die Schrift der Verschreibung ist unleserlich
• die Angaben des Arztes sind unvollständig (es fehlen z.B. Informationen zur Dosis eines Medikaments)
• die Verschreibung enthält widersprüchliche Angaben

Aus diesen Gründen empfiehlt es sich, handschriftliche Dokumentationsprozesse durch elektronische Systeme zu ersetzen.

Mit OCQMS entwickeln wir eine modulare webbasierte Software für ein "Clinical Quality Management System". Das System unterstützt den praktizierenden Arzt in seiner täglichen klinischen Arbeit (automatische Generierung von ärztlichen Berichten) und stellt dabei eine strukturierte Ablage der Daten sicher.

Dabei werden nicht nur medikamentöse Verschreibungen, sondern der gesamte Dokumentationsprozess in einem wohlstruktutrierten elektronischen System abgebildet.

OCQMS legt zudem grossen Wert auf eine geeignete Visualisierung der Daten, so dass sich Fehler oder Inkonsistenzen (z.B. bei der Medikation) leichter erkennen lassen.



Die erfassten Daten werden dank Report Generator als Textbausteine bzw. tabellarische Darstellung in den ärztlichen Bericht (Arztbrief) übertragen.

Gefährliche Fehler aufgrund einer unleserlichen Handschrift können so komplett vermieden werden.

Im Rahmen der leidigen Diskussion um den mutmasslichen "Hackerangriff" (http://www.nzz.ch/aktuell/schweiz/bund-liess-comparis-hackerangriff-durchgehen-1.17547910) von Camparis (www.comparis.ch) auf den Prämienrechner des Bundesamts für Gesundheit (www.priminfo.ch) haben wir uns gefragt, wie offen die Prämien-Daten des BAGs verfügbar sind.

Wir haben also beim BAG nachgefragt und erhielten sehr prompt eine Antwort inkl. Link auf den Datensatz mit allen Prämien: http://www.bag.admin.ch/themen/krankenversicherung/01156/02446/index.html?lang=de
Vielen Dank und chapeaux BAG!

Der Datensatz des BAG liegt im Excel-Format vor und ist daher nicht ganz so einfach zu verarbeiten. Wir haben daher noch einmal beim BAG nachgefragt, ob die Daten auch in  "Rohkost" verfügbar sind. Das BAG war wiederum sehr hilfsbereit und hat uns Daten sogleich im CSV-Format zu kommen lassen.

Mit diesem Datensatz war es uns einfach möglich, ein kleines Tool für die Prämiendaten zu entwickeln. SHIP (Swiss Healthcare Insurance Premiums) bietet im jetzigen Stadium folgende Funktionalität:

• Einlesen der Prämiendaten in eine beliebige SQL-Datenbank
• Verständliche Feldnamen
• Einfache Abfragen auf die Datenbank

Das Ziel wäre, für die Datenbank eine öffentliche API zu entwickeln.
Wir sind beim Swiss Open Data Hackday zum Thema Health (http://make.opendata.ch) dabei und hoffen da gemeinsam mit anderen die Arbeiten an der API vorantreiben zu können.
Um den unmittelbaren Nutzen der API zu zeigen, könnte man eine kleine Website mit einem Formular zur Prämienabfrage bauen. Auch wäre es möglich, die über die API gewonnenen Daten zu visualisieren.
Idealerweise würde durch die API ein ganz neuer Möglichkeitsraum geöffnet und es entstünden Applikationen, an die wir selbst nie gedacht hätten.

SHIP - Swiss Healthcare Insurance Premiums auf GitHub: https://github.com/seantis/ship

PDF result of ipython notebook example:
https://github.com/seantis/ship/blob/master/docs/examples.pdf?raw=true

Der Verein OneGov.ch steht exemplarisch für den in der Strategie E-Government des Bundes geforderten Grundsatz «Einmal entwickeln – mehrfach nutzen». Die Mitglieder des Vereins – Kunden und Hersteller – stellen gemeinsam ein durchgängiges E-Government-System zur Verfügung, das dem föderalistischen Prinzip der Eigenständigkeit von Gemeinden und Kantonen Rechnung trägt, eine hohe  Wiederverwendbarkeit garantiert und bedarfsgerecht weiterentwickelt wird. Die kundenorientierten Lösungen sind streng modular aufgebaut und individuell konfigurierbar.
Ein einmal im Auftrag eines Kunden entwickeltes Modul – zum Beispiel ein Veranstaltungskalender, ein Reservationssystem oder eine Auftragsbox – wird von OneGov.ch zertifiziert und lässt sich danach von allen Mitgliedern einsetzen. Die Kunden teilen so den Entwicklungs- und Pflegeaufwand. Und als Nutzergemeinschaft bietet OneGov.ch seinen Kunden weit mehr als bloss ein Produkt.

• Website «eGov Präsenz»: www.wirtschaft.bfh.ch/de/forschung/publikationen/egov_praesenz.html
• Artikel als PDF herunterladen

Four squares in four different colors. Life was good and business grew steadily.

Today (23 August 2012) Microsoft unveiled their new look and their new logo.

[http://blogs.technet.com/b/microsoft_blog/archive/2012/08/23/microsoft-unveils-a-new-look.aspx]

We could live with the four squares but why do they need to use the same colors (just a bit more shiny). From now on, everyone will think that we have stolen from Microsoft: but I swear it is the other way around!

• July 2011: http://web.archive.org/web/20110707002800/http://www.seantis.ch/
• Re-Design September 2010: http://www.seantis.ch/news/seantis.ch-auf-plone-4.0

Have a look at our website back in 2010.

OCQMS includes a full changelog to record all changes made to patient and clinical data. In a medical IT systems it's a key requirement to track who did what and when. It used to be seen as an unpleasant duty and therefore boring stuff required for legal compliance only. Additionally, with current implementations it's not very likely that anyone will use the data recorded in the changelog at any time.

Tracking all the read and write activities on all records of the system will leave you with thousands of log entries in no time. For OCQMS we built a simple activity table to present the information to authorized users.

I must confess that the table looks a bit too technical and you could make it a bit more accessible for humans. But the information is there and it certainly makes sense not only to track the information in some dark technical orbit far away but to actually show it to the user. Everyone can see in real time that all actions (e.g., opening and reading a patients report) are tracked!

But hey: why not making the data more accessible by giving it some "social flavor". The same boring table suddenly looks like this.

You may say that a system for medical data is no Facebook. Right! But since humans are collecting the clinical data it is a "social undertaking". And treating patients requires teamwork and is therefore genuinely social. Physicians talk to their colleagues about patients and their treatment on the hospital floors.

Some concepts from social networks such as Facebook could indeed be helpful:

• profile image: the importance of the profile image seems immature at first sign. But it can make sense because it makes reading data and assigning an author much faster and less prone to error.
• "just now": informations about events in written textual form are better suited for embedding into a chronological context (when did it happen).
• comments: commenting about activities helps to keep track of the loosely structured data resulting from personal communication. Head physicians advise their team members and everyone can see the comments and reply instantly.

So far the clinical activity stream is a concept with some mock-ups only but the implementation shouldn't be that hard.

About a month ago I started introducing puppet to our infrastructure at seantis. After ploughing through Pro Puppet I was able to declare our basic configuration needs, setup the basic infrastructure and deploy two servers in no time.

The experience I made is the basis for this post.

Why Puppet

Before betting on puppet I had a good look at what is out there. Basically, I looked at Puppet and Chef, both ruby based systems for automating configuration. Other options like Salt or Cfengine I dismissed since they seem rather new or old, respectively.

The big difference between Puppet and Chef, as any article will tell you, is the fact that Chef is an extension to Ruby, while Puppet relies on its own declarative configuration language per default.

As I liked the idea of declaring my needs, instead of just writing ruby code, I went for the Puppet road.

(At this point I should probably spend a month with Chef, but who has that kind of time?)

Starting Out

Puppet is easy to like. The initial setup with Vagrant was simple and really helped me working out the kinks of my initial manifests.

Similarly, setting up a Puppetmaster and connecting an agent to it is something you don’t need a PHD for. There’s certainly some amount of reading required to have a basic understanding, but it’s neither brain surgery nor rocket science.

It Gets Complex Fast

Puppet has the concept of modules. Being used to write reusable code I pretty much started using them for any service I could think of. Setup Mysql? Use a module. Define Users? Use a module. And so on.

Unfortunately, this is the point where documentation gets kinda thin. It’s nice if you can set up your a Trac project with two lines of code after you’ve hidden all the nitty gritty in some module. It’s really what I hoped to gain by declaring my configs. No more going crazy on the shell for 10 minutes to set up everything. No more silly mistakes. Set it, forget it.

But then you realize that you coupled your Trac module too closely with the Nginx configuration. So you move some code out. You then realize that for another project to live on the same server you need to completely rethink your approach because you are not flexible enough.

It’s all still okay, mind you. You can test your changes locally, you can do some real life staging and once you update your production machine you can be reasonably sure that nothing unexpected will happen.

That’s of course what a learning curve looks like, but I was still somewhat unprepared for the fast increase in complexity of my configurations.

Puppet Forge to the Rescue?

Whenever a smaller mind like yours truly encounters problems it goes off to wander around open source land. The Puppet Forge and numerous Github projects are waiting to be studied.

Unfortunately, it’s not like shopping for a nice Python module in the Cheeseshop. It is quite hard to find a module that suits your needs. If you find one it is then hard to assess the quality of said module. At least for novices like me.

I mean I did find good modules, like the Mysql module from Puppetlabs (though my Mysql needs are really basic). But I also encountered a number of modules which just didn’t seem like the kind of modules I would want to use on our infrastructure.

For example Puppetlabs’ own Nginx module which has a listen_port parameter in the vhost resource which does nothing. A bug which was fixed in another fork months ago and has since been sitting around waiting to be pulled.

I mean I know that Puppetlabs’ modules are not an official part of puppet, but as someone who is starting out it is still kinda surprising to me that a bug like that wouldn’t be fixed quicker. A module by the people who wrote puppet just seems like a module you would want to trust.

Do Modules Really Work?

At this point I’m starting to wonder just how feasible community modules really are. From the modules I wrote and the modules I looked at I get the feeling that it is very hard to write a good module that supports different, complex use cases.

The fork-jungle that is puppetlabs-nginx suggests that you end up writing your own version of a module quickly. Which of course is a bit of a problem, because it gets very hard to figure out which module to use. So you fork your own. Or write your own. And who wants to do that? There are certainly more interesting things to work on.

Summing Up

I do like Puppet and it certainly helped a lot already. Even if just for the fact that it forced me to really understand all the steps involved in configuring our servers. But Puppet is not yet something that feels completely solid. At least not for complex use cases. At least not to me.

But, I am keen to learn a great deal more about it so my views are surely up for changing. And what do I know, really?

Also visit my personal blog: http://blog.stacktrace.ch

Mutig mutig, alte Tante! Was ich noch nicht ganz verstehe ist die Konvertierung in Binärcode. Müssten es für diese Textlänge nicht viel mehr Zeichen (0,1) sein? Darum bei der per Tweet nachgefragt (https://twitter.com/seantis/status/211755317267152896):

@nzz die binäre Frontseite vom Freitag war grossartig! Welche Konvertierung in Binärcode ist das? Scheinen mir etwas gar wenig Zeichen...
— seantis (@seantis) Juni 10, 2012

Gerade noch einmal selbst darüber nachgedacht. Für jedes Zeichen (Buchstabe, Zahl) werden 8 binäre Stellen gebraucht:

Der NZZ-Schriftzug ist also entsprechend gekürzt:
"01001110 01011010 01011010" heisst "NZZ"

Damit sind alle Artikel sehr stark gekürzt! :-)

Neue Zürcher Zeitung: www.nzz.ch

Learn more about the ideas behind the design of the medications form: http://www.seantis.ch/blog/designing-a-medication-form