Over oneisen en nonwensen

En nog een column in Computable, ‘Over oneisen en nonwensen‘.

Posted in ICT | Comments Off on Over oneisen en nonwensen

Maak een einde aan het aanbestedingsdrama

Nieuwe column van mij in Computable, ‘Maak een einde aan het aanbestedingsdrama‘.

Posted in ICT, innovatie, Uncategorized | Comments Off on Maak een einde aan het aanbestedingsdrama

Presentatie MIC 2011

Mijn presentatie “De Elektronische handtekening in de Zorg” van MIC 2011 staat online.

Posted in ICT, Uncategorized, zorg | Comments Off on Presentatie MIC 2011

Informatie-uitwisseling in de zorg: hoe nu verder?

Deze column is eerder verschenen in ICT Zorg Magazine, Jaargang 12, nr. 4, augustus 2011.

De toekomst van informatie-uitwisseling in de zorg is onduidelijk. In maart heeft de Eerste Kamer het landelijke Elektronisch Patiëntendossier (landelijk EPD) verworpen, ten faveure van ontwikkeling van onderop. Een politieke spagaat van jewelste: het parlement wil van bovenaf opleggen dat informatie-uitwisseling in de zorg bottom-up georganiseerd moet worden. Daarnaast is een toename te zien van initiatieven die de ketenzorg willen verbeteren. Te verwachten is met de toenemende specialisatie van ziekenhuizen dat dit alleen maar zal toenemen.

Daarnaast het aantal patiëntportalen dat de patiënt inzage in het medisch dossier bieden, toe. Maar in juni maakte Google, toch niet voor een kleintje vervaard, bekend het eigen patiëntportaal, Google Health, te beëindigen: wegens gebrek aan succes. Hebben patiëntendossiers dan wel een toekomst? Als het Google niet lukt, wie lukt het dan wel? Voorlopig ontbreken de voorwaarden voor succes nog. Continue reading

Posted in EPD, ICT, innovatie, zorg | Comments Off on Informatie-uitwisseling in de zorg: hoe nu verder?

Presentations & Courses

I’ve made a nice overview of available presentations and course modules. All slides available online! Take a look and contact me for tailor-made in-house courses.

Posted in Uncategorized | Comments Off on Presentations & Courses

“Luister niet naar de gebruiker”

(Oorspronkelijk verschenen in Computable 30-5-2011: Luister niet naar de gebruiker)

Regelmatig hoor je het weer. Automatiseerders zijn techneuten. Ze kijken niet wat de gebruiker wil. Ze komen met technische oplossingen waar niemand om vraagt, en daarom mislukken al die projecten. Om een IT project tot een succes te maken, moet je niet van de techniek uitgaan, maar eerst eens gaan vragen wat de gebruiker nu eigenlijk wil.

Het oude, vertrouwde model. We gaan de gebruiker vragen wat die wil, en schrijven dat heel precies op, in User Requirements, of Eisen en Wensen of zoiets. Dan laten we daar een partij informatie-analisten op los, die dat informatie-analyseren, en zo nog een paar stappen verder komen we met een functioneel ontwerp, en dat laten we ondertekenen door de gebruiker met diens eigen bloed, zwerend op al wat voorhanden is, dat dit toch écht (maar dan ook écht) is wat hij of zij wil. En dat bouwen we dan (wat altijd veel en veel duurder is dan verwacht, en veel en veel langer duurt, want waar in dit verhaal komt nu voor wat de techniek wel kan en niet kan, en wat makkelijk gemaakt kan worden en wat niet). Continue reading

Posted in ICT, innovatie | Comments Off on “Luister niet naar de gebruiker”

Het EPD, standaarden en marktwerking

Nu de Eerste Kamer naar verwachting de Wet op het EPD afwijst, is het de vraag hoe het verder moet. De Eerste Kamer ziet liever eerst uitwisseling van medische gegevens in de regio, en tegelijkertijd een rol voor de overheid bij het opstellen van standaarden en normen en het houden van toezicht. Beter het EPD eerst op te bouwen van onderop – en tegelijkertijd vragen om sturing van de overheid. Het lijkt een tegenstelling. En deels is het dat ook.

Is het niet beter wanneer de overheid zich even terugtrekt uit de sturende rol? Wanneer lokale initiatieven de kans krijgen te bloeien – of te mislukken,  zonder last van die vervelende pottenkijkers van de ministerie? Echt innovatie ontstaat zelden vanuit regulering en de moloch van de ambtenarij. Is het niet beter eerst te zien wat werkt, en later als overheid te proberen die succesvolle initiatieven verder te verbreiden? Laat de markt haar werk doen – het zou VVD-minister Schippers en VVD-opponente Dupuis als liberalen uit het hart gegrepen moeten zijn.

Of toch niet? Continue reading

Posted in EPD, ICT, zorg | Comments Off on Het EPD, standaarden en marktwerking

EPD: De weg vooruit

De Eerste Kamer heeft de Wet op het EPD gekraakt. Dinsdag aanstaande volgt de stemming: zonder veel twijfel zal de wet het niet halen. Unaniem (of nagenoeg: het CDA weet het nog niet zeker) willen de senatoren géén Landelijk Schakelpunt en voorlopig alleen uitwisseling in de regio. De privacy is met een landelijke toegang onvoldoende geregeld, aldus de Kamer.

Het zorgveld likt de wonden. Er is jaren geïnvesteerd, niet alleen de vaker genoemde 300 miljoen overheidsgeld, ook veel inzet en werk bij talloze ICT-leveranciers en zorginstellingen lijkt weggegooid. Er wordt volop getwitterd “terug naar het stenen tijdperk”.

Of niet? Is er leven voor het EPD na de stemming? Continue reading

Posted in EPD, ICT, zorg | Comments Off on EPD: De weg vooruit

InfoQ article: Nobody Needs Reliable Messaging

There’s a new article by me on InfoQ: Nobody Needs Reliable Messaging

Posted in interoperability, webservices | Comments Off on InfoQ article: Nobody Needs Reliable Messaging

Semantics and behavior

Larry Masinter believes there is a risk in making ‘the “meaning” of [a] language depend on operational behavior‘.

In discussions like this there should be a sharp distinction between natural and computer languages. Larry says meaning ‘depends on what the speaker intends and how the listener will interpret the utterance’ – that’s a valid viewpoint for natural languages, but for markup (html, xml etc.) or programming languages it’s really stretching definitions. There is no speaker, and no direct intentions – unless software has intentions. For markup document instances, there are usually three indirect intentions: those of the language designer, the software builder and the end-user producing the instance. I’m not sure an approach based on intentions is workable for computer languages at all – whose intention does the document reflect? How do we know the intentions of end-user, software builder and language designer do not conflict? How do we know their intentions at all?

Besides, semantics in this way can be described in prose or first order logic. I don’t think first order logic is appropriate for most language design (it’s not human readable, only logician-readable), and prose may be fine but is often inexact. I spoke at length at Balisage 2008 on this issue, and discussed it with David Orchard and others, and I believe an operational approach is often appropriate for computer languages. Why? It certainly is problematic for natural language semantics. There may be an utterance, and a meaning, without any behavior – I can say ‘North Korea tested an A-bomb’, and that has a meaning, even if no-one exhibits any behavior whatsoever after my words. For computer languages, it’s different. It’s possible to describe operational behavior as testable conditions – if I send a system test message A, it should do X. And that makes operational semantics a nearly perfect fit for computer languages – the semantics can be tested with a test suite. That’s enough. No need for real-time behavior after receiving each message.

Larry writes: ‘…standards organizations are in the business of defining languages … and not in … telling organizations and participants … how they are supposed to behave’. That’s far too lenient. If I render text marked <b> as italic, and <i> as bold, I’m not following your spec. Period. If I implement a language specification, and claim conformance, I’m not free to do as I choose. This is even more true in other contexts – business, healthcare, insurance. There organizations exchanging documents sign contracts, and are legally bound to do certain things upon receiving documents – paying after ordering, for instance. Larry’s free-for-all approach to language definitions does not apply to the real world. It’s only true that behavior should not be constrained any further than necessary – but without behavioral consequences, document exchange is meaningless indeed.

Posted in interoperability, semantics, xml | 1 Comment