Het Erasmus MC ziet de patiënt mondiger worden en heeft besloten de kansen van informatie technologie in te zetten om de patiënt meer te betrekken bij het zorgproces. In deze scriptie wordt ingegaan op een architectuur voor het over de grenzen van de organisatie heen delen en verzamelen van patiënt informatie om zo beter geïnformeerd te zijn en de patiënt beter van dienst te kunnen zijn. Veel ziekenhuizen kiezen daarbij voor een oplossing die alleen voor hen werkt, Erasmus MC daarentegen ziet gelijk kansen om ook tussen zorgverleners data uit te kunnen wisselen. In deze context is voor een patiëntenportal / zorgverlenerportaal framework aanpak gekozen waarbij diverse reeds bestaande (commerciële) softwarediensten kunnen worden. In deze context is het doel van dit onderzoek een architectuur voor het integreren van autonome diensten op een regionaal patiëntenportal te ontwerpen. Het ontwerp gaat volgens een Design Science proces waarbij via een ontwikkel – evaluatie cycle het ontwerp wordt verfijnd, rekening houdend met omgevingsfactoren en literatuur. Onder omgevingsfactoren vallen ook een groot aantal interviews en reviewsessies met betrokkenen en experts. Het integreren van online autonome software diensten is meestal een dure aangelegenheid wanneer achteraf twee of meer systemen aan elkaar gekoppeld moeten worden. Door een generieke oplossing te formuleren en deze te communiceren aan de betrokken partijen is dit te voorkomen. Deze generieke oplossing, de architectuur, moet niet alleen op papier een logisch verhaal zijn maar moet ook rekening houden met de complexe en veranderende omgeving waarin het zich begeeft. De architectuur overstijgt de verantwoordelijkheid van één partij en moet rekening houden met vele belangen zoals, voorkeuren, politiek, contracten, bestaande software, technology push en standaarden adoptie. Vanuit dit opzicht wordt architectuur vanuit een socio-technisch perspectief benaderd. De architectuur bestaat uit de volgende technologische componenten. Het patiëntenportal / zorgverlenerportaal framework vormt het basis applicatieplatform waarop autonome softwarediensten kunnen worden geplaatst. Deze diensten kunnen applicatielogica aanbieden en data gebruiken. Bij het gebruik van data is een referentie naar een zorginformatiemodel mogelijk. Dit framework kan weer worden ingeladen in bestaande Ziekenhuis Informatie Systemen. Naast het identificeren van de technologische componenten is een architectuur van de informatie uitwisseling uitgewerkt. Dit begint met 1-richting verkeer: het presenteren van een kern dossier in de regio. Door gebruik te maken van een beperkte set informatie op basis van de CCR (Continuity of Care Record) en deze te koppelen aan bestaande informatie elementen (zoals de ontslagbrief en de medicijnkaart) ontstaat een set afspraken over welke informatie op welke wijze gedeeld kan worden in de regio. Uit politiek oogpunt kan in de regio Rijnmond beter worden gesproken over de CCD (Continuity of Care Document), een als HL7 verpakt CCR, in verband met een eerdere afwijzing van de CCR in de regio. Zodra zorginformatie wordt gedeeld met andere zorgverleners en deze hebben geen vast samenwerkingsverband is het belangrijk dat er afspraken zijn over wat de vastgelegde informatie (zoals een bloeddrukmeting) exact betekent. Dit kan bereikt worden door een centrale zorginformatiemodellendatabase op te nemen als onderdeel van de architectuur zodat er altijd een referentie is naar de context van de informatie. Zorginformatiemodellen kunnen gemodelleerd zijn met behulp van OpenEHR (in de vorm templates met referenties naar archetypen) of met behulp van HL7 (in de vorm van een templates met referenties naar het RIM) en zijn opgebouwd volgens richtlijnen van de beroepsgroep (bv. NHG standaarden). Voor 2-richting verkeer is een typische vragenlijst een goed voorbeeld zoals bleek uit een review van de betrokken artsen. Vragenlijsten of formulieren zijn de basis van informatievergaring. Hierbij voegt een patiënt informatie toe aan zijn dossier. Ook hier is een referentie naar een zorginformatiemodel van belang wanneer de data ook transmuraal waarde wil houden. Voor intern gebruik is dit niet noodzakelijk. Om autonome diensten (kan zowel 1-richting, 2-richting, of synchrone dienst zijn) te kunnen laden in de portal is onderzocht welke technieken hiervoor geschikt zouden kunnen zijn. Deze technieken vallen onder de noemer “remote interactie”. Dit is een set technieken die nog maar mondjesmaat in de business worden gebruikt maar wel veel mogelijkheden bieden in deze web 2.0 setting. Er zijn een tweetal technieken geselecteerd die voldoen aan de eisen: WSRPv2 en AJAX via proxy. Om een dergelijke remote interactie echter mogelijk te maken is het nodig afspraken te maken over: authenticatie, autorisatie, consent en patiënt context. Dit zijn generieke services die elke dienst moet implementeren wil het binnen de portal geladen kunnen worden. Hiervoor stellen we voor een Health API te ontwikkelen die deze services definieert. De ontwikkelde generieke architectuur is getest door het doorlopen van een typische case. Deze laat zien dat de architectuur geschikt is, maar wel additionele services toegevoegd moeten worden voor de projectarchitectuur welke implementeerbaar is. We bevelen aan om de architectuur breder te toetsen, indien nodig te verbeteren en te implementeren. Architectuur kan in een socio-technisch kader gezien worden. Het ontwikkelen van een architectuur is arbeidsintensief doordat vele stakeholders betrokken zijn. Implementatie kan eerst middels een prototype gaan om daarmee draagvlak te creëren en de stakeholders er bij te betrekken. Acceptatie is een proces dat tijd en inspanning nodig heeft. Inleven in de incentives tot participatie en blokkeermacht. Dit is cruciaal omdat dit een valkuil kan zijn welke succes in de weg staat. Met een geschikte architectuur kan Erasmus MC 2 problemen tegelijk oplossen: transmurale communicatie opzetten en vereenvoudiging van de interne complexe IT.