BE1020029A3 - Een integratie methode ter bevordering van het zorgproces van een zorgnemer. - Google Patents

Abstract

Een methode ter bevordering van het zorgproces van een zorgnemer, omvattende een omgevingsmodel voorzien van: (1) een geheel van software componenten; (2) middelen om verschillende applicaties, die gebruik kunnen maken van verschillende technologieën, te integreren en synchroniseren, (3) middelen om verschillende applicaties te kunnen aanpassen of aansturen, (4) middelen om wisselwerking tussen de verschillende applicaties tot stand te brengen en waarbij de wisselwerking context-afhankelijk is, en waarbij het geheel van software commponenten uitbreidbaar is door aan de applicaties verschillende uitbreidingspakketten toe te voegen.

Description

EEN INTEGRATIE METHODE TER BEVORDERING VAN HET ZORGPROCES VAN EEN ZORGNEMER

Technisch gebied van de uitvinding

Onderhavige uitvinding betreft een systeem en een integratie methode ter bevordering van het zorgproces van een zorgnemer.

Stand van de techniek

Onvoldoende beschikbaarheid van informatie is de grootste oorzaak van medische fouten. In Engeland en Wales alleen sterven er jaarlijks 1.200 mensen als een gevolg van fouten in de medicatie, dit is bijna een derde van het aantal doden op de weg en de kosten lopen gemakkelijk op tot 500 miljoen pond per jaar. Indien men bijvoorbeeld een applicatie die elektronische voorschriften levert zou kunnen gebruiken, dan zouden désastreuse reacties op fout geschreven medicamenten kunnen vermeden alsook menslevens gered worden. Ook kosten ten gevolge van verlies van noodzakelijke documenten door de patiënt kan ook leiden tot hoge kosten, die vermeden kunnen worden door elektronische archivering van alle data & documenten.

Momenteel worden er verschillende applicaties gebruikt die elk hun gedetailleerde elektronische gegevens bewaren, meestal in een eigen database, gaande van uitgevoerde chirurgische ingrepen tot de administratie en de follow-up van de patiënten. Hoewel er al verschillende applicaties op de markt zijn die één bepaald onderdeel van het zorgproces van een zorgnemer in kaart brengen, is er nog geen methode om de verschillende applicaties die ontwikkeld werden in uiteenlopende technologieën, te integreren en deze elektronisch met elkaar te linken. Het zorgproces van een patiënt zou ook gegarandeerd moeten worden, wanneer de patiënt het ziekenhuis verlaat. Dit kan bijvoorbeeld door de gegevens die buiten het ziekenhuis worden gecreëerd bij te houden en te integreren in het elektronische dossier van de patiënt, die dan ook in het ziekenhuis kan worden geraadpleegd.

Samenvatting van de uitvinding

Het is een doel van de uitvinding om een systeem en een methode te voorzien die verschillende bestaande applicaties kan integreren ter bevordering van het zorgproces van een zorgnemer. Verder is een doel van de uitvinding de noodzakelijke informatie te voorzien om het zorgproces van zorgnemer te optimaliseren.

Hiertoe wordt, volgens een eerste aspect van de uitvinding, een computersysteem voorzien ter bevordering van het zorgproces van een zorgnemer omvattend: - een omgevingsmodel voorzien van een geheel van software componenten die verschillende applicaties kunnen aanpassen of aansturen, - middelen om de verschillende applicaties, die gebruik kunnen maken van verschillende technologieën, te integreren en synchroniseren, - middelen om wisselwerking tussen de verschillende applicaties tot stand te brengen en waarbij de wisselwerking context-afhankelijk is, en waarbij het geheel van software componenten uitbreidbaar is door aan de applicaties verschillende uitbreidingspakketten toe te voegen.

Voorkeurdragende uitvoeringsvormen van de uitvinding worden weergegeven in de aangehechte afhankelijke octrooiconclusies. Het systeem, een geïntegreerd medisch werkstation kan er voor zorgen dat alle betrokkenen bij het zorgproces rond de zorgnemer de noodzakelijke informatie kunnen bekomen om dat zorgproces te optimaliseren. Op lange termijn wil dit zeggen dat de patiënt en huisarts beperkte toegang tot de patiëntgegevens krijgen of er tussen ziekenhuizen onderling gegevensuitwisseling mogelijk is (doorverwijzing, ...). Een voordelig gevolg hiervan is dat ook de thuiszorg geïntegreerd kan worden en dat de zorgnemer opgevolgd kan worden over zijn volledige levensloop. Bovendien wordt het volledige zorgtraject van de zorgnemer ondersteund. Omdat in de toekomst een van de belangrijke doelstellingen van het ziekenhuis er zal uit bestaan om de zorgnemer zo lang mogelijk uit het ziekenhuis te houden, zal het geïntegreerde medisch werkstation er mee voor zorgen dat ook buiten het ziekenhuis het zorgproces van de zorgnemers ondersteund kan worden. Het geïntegreerde medisch werkstation zal ervoor zorgen dat een zorgverstrekker van het ziekenhuis zich kan aanmelden en op basis van werklijsten een patiënt kan selecteren en bovendien zal de zorgverstrekker voor de gekozen zorgnemer een bepaalde deelapplicatie kunnen opstarten omvat in het medisch werkstation.

Hiertoe wordt, volgens een tweede aspect van de uitvinding een computer gebaseerde integratie methode voorzien ter bevordering van het zorgproces van een zorgnemer, omvattende een omgevingsmodel voorzien van een geheel van software componenten en omvattende volgende stappen: - integreren en synchroniseren door verschillende applicaties, die gebruik kunnen maken van verschillende technologieën, - aansturen of aanpassen en aansturen van verschillende applicaties, - tot stand brengen van een wisselwerking tussen de verschillende applicaties en waarbij de wisselwerking context-afhankelijk is, en waarbij het geheel van software componenten uitbreidbaar is door aan de applicaties verschillende uitbreidingspakketten toe te voegen.

Korte beschrijving van de figuren

Fig. 1 toont schematisch de context, wanneer de integratie van verschillende applicaties visueel is voorgesteld volgens bepaalde uitvoeringsvormen van de uitvinding.

Fig. 2 toont schematisch de concepten van het Addin omgevingsmodel en een manier waarop deze aangewend kan worden volgens een uitvoeringsvorm van de uitvinding.

Fig. 3 toont schematisch de integratie van verschillende applicaties door gebruik te maken van de integratie methode volgens bepaalde uitvoeringsvormen van de uitvinding.

In de figuren verwijzen gelijke referentienummers naar gelijke of analoge elementen.

Uitvoeringsvormen

De huidige uitvinding zal beschreven worden aan de hand van bepaalde uitvoeringsvormen en met referentie naar bepaalde figuren. De uitvinding is echter hiertoe niet beperkt, maar ze is enkel beperkt door de beschermingsomvang van de conclusies. De figuren zijn slechts schematisch en niet beperkend. In de figuren kunnen de afmetingen van sommige elementen uitvergroot en niet op schaal getekend zijn voor illustratieve doeleinden. De afmetingen en relatieve afmetingen komen niet noodzakelijk overeen met de actuele afmetingen van fysische uitvoeringsvormen.

Verder worden de termen eerste, tweede, derde en gelijkaardige termen enkel gebruikt om onderscheid te maken tussen verschillende gelijke elementen en beschrijven deze termen niet noodzakelijk een bepaalde sequentie, noch in tijd, noch in ruimte, rangorde, volgorde of op eender welke andere wijze. Het is duidelijk dat de termen onderling verwisselbaar zijn onder geschikte omstandigheden en dat de uitvoeringsvormen van de uitvinding hierin beschreven in een andere sequentie dan hierin beschreven of geïllustreerd kunnen functioneren.

Het dient opgemerkt dat de termen “bevatten” en “omvatten” niet opgevat moeten worden als zijnde beperkt tot de stappen, elementen, stukken, onderdelen of gelijkaardige die daarna vernoemd worden. Deze term sluit geen verdere stappen, elementen, stukken, onderdelen of gelijkaardige uit. Het duidt de aanwezigheid van stappen, elementen, stukken, onderdelen of gelijkaardige aan, maar sluit de aanwezigheid van één of meerdere stappen, elementen, stukken, onderdelen of gelijkaardige, of groepen van stappen, elementen, stukken, onderdelen of gelijkaardige niet uit. Dus de omvang van de uitdrukking “een inrichting bevattende A en B” is niet beperkt tot een inrichting die enkel uit A en B bestaat. Het betekent dat in het licht van de huidige uitvinding, de voor de uitvinding relevante componenten of elementen van de inrichting A en B zijn.

Een referentie naar “één” of “een” uitvoeringsvorm betekent dat specifieke kenmerken, eigenschappen of structuren beschreven in relatie tot die uitvoeringsvorm minstens geïntegreerd zijn in minstens één uitvoeringsvorm volgens de uitvinding. Daarom verwijzen referenties naar “in een uitvoeringsvorm” of “in één uitvoeringsvorm” in verschillende delen van de beschrijving niet noodzakelijkerwijze naar dezelfde uitvoeringsvorm, al kunnen zij wel naar dezelfde uitvoeringsvorm verwijzen. Verder kunnen de specifieke kenmerken, eigenschappen of structuren gecombineerd worden in één of meer uitvoeringsvormen, zoals duidelijk is voor de vakman.

Op gelijkaardige wijze moet begrepen worden dat in de beschrijving van de als voorbeeld gestelde uitvoeringsvormen, verschillende kenmerken van de uitvinding soms gegroepeerd staan in één uitvoeringsvorm, figuur of deel van de beschrijving met als doel het voorzien van een duidelijke beschrijving teneinde de verschillende kenmerken van de uitvinding duidelijk te maken. Deze voorstellingswijze betekent echter niet dat de uitvinding meer kenmerken zou bevatten dan die welke zijn geformuleerd in de conclusies. In plaats daarvan, zoals blijkt uit de hierna volgende conclusies, ligt de vindingrijkheid van de uitvinding in minder dan alle kenmerken van één enkele voorgaande uitvoeringsvorm zoals beschreven. Dus zijn de conclusies volgend op de beschrijving bij deze expliciet geïntegreerd in de gedetailleerde beschrijving van de uitvinding, waarbij elk van de conclusies op zich een afzonderlijke uitvoeringsvorm van de uitvinding vormt.

Verder, hoewel sommige uitvoeringsvormen hierin beschreven bepaalde kenmerken bevatten en andere niet, worden combinaties van kenmerken van de verschillende uitvoeringsvormen bedoeld als zijnde binnen de omvang van de uitvinding, zoals kan worden verstaan door de vakman.

In bijgaande beschrijving worden talrijke details beschreven en weergegeven. Het is echter duidelijk dat de uitvinding kan uitgevoerd worden zonder deze specifieke details. In andere gevallen worden reeds bekende methodes, structuren, elementen en dergelijke niet getoond om de beschrijving niet nodeloos onduidelijk te maken in het licht van de uitvinding.

De uitvinding zal nu worden beschreven aan de hand van een gedetailleerde beschrijving van verschillende uitvoeringsvormen van de uitvinding. Het is duidelijk dat andere uitvoeringsvormen geconfigureerd kunnen worden volgens de kennis van de vakman zonder af te wijken van de technische bijdrage van de uitvinding. De uitvinding wordt enkel beperkt door de bewoording van de aangehechte conclusies.

Het systeem en de integratie methode volgens een uitvoeringsvorm van de uitvinding omvat een omgevingsmodel dat een platform aanbiedt dat toelaat om applicaties die binnen een ziekenhuis draaien te integreren in een overkoepelende omgeving die een aantal gemeenschappelijke factoren van deze deelapplicaties overneemt. In een voorkeurdragende vorm van de uitvinding gebeurt deze integratie ook op visueel vlak. Een bijkomend voordeel is ook dat het ziekenhuis door het gebruikerscomfort van het geïntegreerd medische werkstation meer elektronisch zal werken zodat papierloos werken mogelijk wordt.

Het systeem en de integratie methode volgens een uitvoeringsvorm van de uitvinding is gebaseerd op het “best of breed” principe, waarbij verschillende applicaties van verschillende leveranciers geïntegreerd worden. Volgens deze “best of breed” principe, waar vroeger bedrijfssoftware steeds op maat werd ontwikkeld voor ieder bedrijf (wat zeer kostbaar is en niet nodig omdat de bedrijfsprocessen in veel bedrijven sterk op elkaar leken), worden er softwarepakketten gemaakt als pakketten die zich richten op een specifieke bedrijfsfunctie, zoals de boekhouding of de verkoopadministratie. Maar nog steeds zijn er tal van bedrijfsprocessen zo uniek dat een softwarepakket het aflegt tegen het maatwerk waar het bedrijf al jaren mee werkt. Door bestaande applicaties met bewezen waarde te integreren zal men een vernieuwde kracht geven aan de applicaties. Of men kan een nieuwe strategie voor een ziekenhuis opzetten door bijvoorbeeld stap voor stap de applicaties uit te breiden en te integreren met een methode volgens een uitvoeringsvorm van de uitvinding.

Dit biedt ook een aantal voordelen voor de eindgebruiker en applicatiebeheerders. Herhaalde handelingen in losstaande deelapplicaties worden verminderd, bijvoorbeeld applicaties openen en sluiten, paswoord ingeven, aanmelden, selectie van patiënt of verantwoordelijke arts, etc. Het tijdsverlies en eventuele fouten door het werken met verschillende losstaande deelapplicaties kunnen hierdoor ook vermeden worden. De gebruiker kan zich tevens een totaalbeeld vormen van de toestand van de patiënt. Verschillende gebruikers zoals artsen, verpleegkundigen, apothekers, enz. hebben zo toegang tot alleen voor hen zichtbare informatie.

Omdat er maar enkel één platform is die verschillende applicaties aanstuurt is er uniformiteit in de presentatie en navigatie. Dit biedt tevens een gecentraliseerd en uniform beheer voor de toegang, lay-out, etc. Bovendien kunnen de applicaties met elkaar samenwerken. Vanuit applicatie A kan men bijvoorbeeld onmiddellijk een scherm oproepen in applicatie B. Bovendien worden niet alle bestaande applicaties herschreven om in een omgevingsmodel volgens een uitvoeringsvorm van de uitvinding te passen. Toch is het mogelijk dat een inspanning noodzakelijk is om de koppeling te leggen.

Een omgevingsmodel volgens een uitvoeringsvorm van de uitvinding kan zoals vermeld verschillende applicaties integreren en bovendien kunnen deze applicaties al dan niet gebouwd zijn in verschillende software architecturen, en met verschillende technologieën. Een voorbeeld van deze technologieën zijn .Net applicaties metWinForms, .Net applicaties met WPF, ActiveX applicaties, Web applicaties, MFC applicaties, Windows applicaties met een native Window Handle, .Net 1.0, 1.1, 2.0, 3.x, 4.0 applicaties, Service Oriented applicaties, en Client-Server applicaties.

In een andere uitvoeringsvorm van de uitvinding kan het omgevingsmodel deelapplicaties, die gelijktijdig in gebruik zijn, maximaal van elkaar isoleren. Harde onderlinge referenties tussen deelapplicaties worden niet als vereiste voorop gesteld, een deelapplicatie zal enkel refereren naar het integratie-aspect van het omgevingsmodel. Deelapplicaties weten niet van elkaar dat ze gelijktijdig in het omgevingsmodel draaien, ook niet als ze trachten met elkaar samen te werken.

In een andere uitvoeringsvorm van de uitvinding is het omgevingsmodel code invariant. De kern van een alleenstaande deelapplicatie, indien gebouwd volgens een goed architecturaal gelaagd model, kan worden behouden blijven en mag bij voorkeur dus geen implementatie aspecten door het omgevingsmodel opgelegd krijgen.

In een andere uitvoeringsvorm van de uitvinding is het omgevingsmodel configuratie invariant. Eventuele configuratiebestanden die bij de deelapplicatie horen, kunnen ongewijzigd hergebruikt worden en mogen niet conflicteren met configuraties van andere deelapplicaties.

Het omgevingsmodel voorziet volgens een uitvoeringsvorm van de uitvinding dat de deelapplicaties gebruik kunnen maken van de bibliotheken van externe leveranciers indien ze die nodig hebben. Wanneer meerdere deelapplicaties eenzelfde bibliotheek gebruiken in een andere versie, zal dit geen conflicten geven of wanneer meerdere deelapplicaties eenzelfde bibliotheek gebruiken met dezelfde versie, en deze bibliotheek bevat statische gegevens, zal dit geen conflicten geven.

Het omgevingsmodel is bij voorkeur stabiel, indien een deelapplicatie onstabiel wordt of zichzelf ophangt zal het omgevingsmodel niet doen falen of hangen.

Het omgevingsmodel voorziet verder, volgens een uitvoeringsvorm van de uitvinding, middelen ter navigatie. Deelapplicaties kunnen schermen of taken van elkaar kunnen oproepen zonder directe onderlinge referenties.

Het omgevingsmodel is bij voorkeur performant, het omgevingsmodel en een deelapplicatie zijn in staat gegevens met elkaar uit te wisselen zonder storende vertragingen voor de eindgebruiker.

Het omgevingsmodel is volgens een uitvoeringsvorm van de uitvinding uitbreidbaar. Een nieuwe deelapplicatie kan worden toegevoegd zonder dat dit een nieuwe installatie van het omgevingsmodel vereist.

Het omgevingsmodel is bij voorkeur compatibel. Een nieuwe versie van het omgevingsmodel is in staat om te werken met oude versies van een deelapplicatie. Een nieuwe versie van een deelapplicatie kan op zijn beurt ook werken in een oude versie het omgevingsmodel.

In een voorkeurdragende vorm van de uitvinding, wordt het omgevingsmodel gebouwd in Microsoft Windows .Net technologie. Dit is voordelig omdat de meeste ziekenhuisapplicaties Windows applicaties zijn en omdat zoals hierboven vermeld ondersteunt een .Net platform een hybride verzameling van technologieën. Als basis integratie technologie kan gebruik worden gemaakt van het ‘Managed Addin Framework’ (MAF) dat beschikbaar is sinds .Net 3.5. Dit laat toe om een applicatie, de ‘host’, uit te breiden met een aantal plugins of ‘addins’. Elke addin voldoet bij voorkeur aan een specificatie vastgelegd in een ‘addin contract’, dit is een beschrijving van functies en velden in een aantal interfaces die aan een aantal klassen in de addin opgelegd worden. De inhoud van het addin contract omvat bij voorkeur de functionaliteiten die het omgevingsmodel volgens bepaalde uitvoeringsvormen van de uitvinding aanbiedt aan de Addins, en dus bepaalt ze hiermee de normen waaraan een addin bij voorkeur voldoet. Concreet gaat het hier bijvoorbeeld om een aantal interfaces in C# 2.0 die door klassen in de Addin geïmplementeerd kunnen worden.

Bovendien laat het addin contract tevens toe dat de host en de addin met elkaar communiceren in twee richtingen. De host biedt dus een aantal functionaliteiten aan ten behoeve van de addin, De addin kan tevens een aantal functionaliteiten ondersteunen om zo te kunnen draaien binnen de host. In een ziekenhuisomgeving kan bijvoorbeeld de host een view ‘medicatie therapie’ opvragen, bij een medicatie addin, wanneer de gebruiker dit menu-item opent op het computerscherm. De medicatie addin zal vervolgens bij de host opvragen welke patiënt momenteel geselecteerd is om de juiste therapie in te laden. De communicatie tussen host en addin gebeurt bij voorkeur via de ‘Addin pipeline’. Dit is een communicatiekanaal met een aantal sequentiële stages die de concrete implementaties van host, addin en communicatietransport loskoppelen. De host en addin communiceren bij voorkeur dus niet rechtstreeks in de transport-taal, maar hebben een logisch beeld van elkaar via een adapter (bijvoorbeeld een host-zijde adapter of een addin-zijde adapter). Deze adapter zet bij voorkeur alles om in een specifieke transport-taal. De host en addin hebben bij voorkeur geen directe referentie naar elkaar, enkel naar het addin contract en naar de adapters. Bij voorkeur kunnen meerdere versies van het addin contract naast elkaar gebruikt worden door toevoeging van extra adapters. Om bijvoorbeeld een nieuwe addin in een oude host te laten draaien kan een adapter toegevoegd worden aan de zijde van addin, die het nieuwe beeld omzet in het oude beeld. Hierdoor wordt compatibiliteit van het omgevingsmodel gegarandeerd.

Het addin contract omvat volgens uitvoeringsvormen van de uitvinding een aantal operaties die overeenkomen met de meest voorkomende acties wanneer een gebruiker werkt met een alleenstaande ziekenhuis applicatie. Bijvoorbeeld het starten en afsluiten van een applicatie, het aanmelden en afmelden van een gebruiker, een scherm openen en sluiten, een scherm zichtbaar en onzichtbaar maken, een (andere) patiënt of opname kiezen of voor een andere verantwoordelijke arts, afdeling... werken. Hierdoor kan men de migratie van een applicatie voorzien, door het mappen van de beschikbare functies in het addin contract op al bestaande methodes in de applicatie. Deze mapping kan gebeuren in een adapter die het addin contract kan implementeren, en onderliggend de bestaande applicatie aanstuurt. In sommige gevallen moet er toch bijkomend geprogrammeerd worden in de kern van de applicatie, afhankelijk van de architecturale gelaagdheid van de applicatie en volledigheid van de levenscyclus.

Bij het laden van een addin, wordt ervoor gezorgd dat deze gestart wordt in een eigen domein, de zogenaamde ‘Appdomain’. Dit is een concept in .Net dat een aantal modules groepeert en afschermt, alsof ze in een eigen proces gestart werden. In het omgevingsmodel volgens uitvoeringsvormen van de uitvinding worden alle modules van de addin geïsoleerd in een eigen Appdomain. Binnen een proces kunnen hierdoor meerdere Appdomain-en opgestart worden, en het afsluiten van een Appdomain zorgt voor het volledig opkuisen van de resources die erin gealloceerd werden. Hierdoor is de integratie van applicaties die gebruik maken van verschillen technologieën mogelijk: in elk Appdomain kan men een andere versie van .Net te gebruiken, zo kan men bv. een .Net 1.1 Addin draaien naast een .Net 3.5 Addin, terwijl ze onderling incompatibele API’s gebruiken. Bovendien kan men door de Addins in een eigen Appdomain af te zonderen, de configuratiebestanden van elkaar isoleren. Hierdoor kunnen meerdere Addins gelijknamige configuratie secties gebruiken zonder met elkaar te conflicteren. Evenmin kan bij voorkeur de bestaande code om configuraties uit te lezen aangepast worden. Nog een bijkomend voordeel van de afzondering van de Addin in zijn Appdomain is dat alle modules standaard geladen worden binnen het domein, en dus niet gedeeld wordt over de domeinen heen. Verschillende Addins worden daardoor niet verplicht om dezelfde versie van een bibliotheek te gebruiken.

Bij het aanmelden van een gebruiker, kan er volgens een uitvoeringsvorm van de uitvinding in het omgevingsmodel worden nagegaan of er geautoriseerde Addins beschikbaar zijn op de computer die het omgevingsmodel omvat. Het systeem voert dan een aantal folder scans uit op configureerbare locaties. Wanneer een folder een geautoriseerde addin bevat, wordt deze beschikbaar gemaakt in het omgevingsmodel. Hierdoor zal met uitbreidingen van het omgevingsmodel gemakkelijk kunnen uitvoeren, bijvoorbeeld na installatie van een nieuwe Addin zal het omgevingsmodel enkel herstart worden om deze beschikbaar te maken voor de geautoriseerde gebruikers.

Zoals hierboven vermeld gebeurt de integratie van de applicaties in een voorkeurdragende vorm van de uitvinding ook op visueel vlak. Voor een visuele integratie worden bij voorkeur visuele elementen uit een addin getoond in (een deel van) het venster voorzien in het omgevingsmodel. Deze visuele elementen worden bij voorkeur doorgegeven via het communicatiekanaal tussen de host en Addin. Standaard ondersteunt deze technologie enkel Windows Presentation Foundation (WPF) elementen. WPF werd geïntroduceerd met het .NET framework en is een alternatief voor Windows Forms. Gebruikersomgevingen die zijn opgebouwd met WPF zijn resolutieonafhankelijk doordat ze gebaseerd zijn op vectorafbeeldingen. Naast 3D-afbeeldingen en controle-elementen biedt WPF ook ondersteuning voor 3D-objecten, video, spraak en opgemaakte documenten. Al deze elementen kunnen ook worden opgebouwd door Direct 3D, een onderdeel van DirectX. WPF kan echter ook volledig softwarematig werken indien er geen ondersteunde hardware beschikbaar is. Een voordeel van WPF is dat ze vele mogelijkheden biedt op het gebied van lay-out.

Naast WPF omvat het omgevingsmodel volgens een uitvoeringsvorm van de uitvinding verder een aantal adapters om de integratie mogelijkheden uit te breiden. Bijvoorbeeld een adapter voor WinForms componenten, een webclient wrapper voor web applicaties en ActiveX componenten. Ook voor MFC schermen kan voor het omgevingsmodel een ActiveX wrapper geschreven worden in de deelapplicatie zelf, of men kan met een WPF wrapper van een native venster werken. Voor de integratie van web applicaties kan er bij voorkeur een generieke Addin, de ‘web addin’ gebruiker worden, zodat web applicaties via configuratie (dus zonder extra programmering) kunnen worden ingeplugd. Ze kunnen via eveneens configureerbare HTTP parameters een aantal systeem- en context variabelen doorkrijgen van de omgevingsmodel volgens een aantal uitvoeringsvormen van de uitvinding.

Het omgevingsmodel omvat volgens uitvoeringsvormen van de uitvinding verder een context die schematisch wordt voorgesteld in Fig. 1. Deze context kan bijvoorbeeld volgende informatie bevatten: welke gebruiker aangemeld is in het omgevingsmodel, voor welke arts en afdeling werkt de gebruiker en/of welke patiënt er is geselecteerd (indien van toepassing). De context kan worden beheerd door het omgevingsmodel en laat een addin toe op elk moment de inhoud van de context op te vragen en een context wijziging aan te vragen. Context wijzigingen gaan pas door na validatie door het omgevingsmodel, die controleert o.a. of alle Addins klaar zijn voor de context wijziging.

Bij voorkeur stelt een Addin één of meerdere pagina’s ter beschikking van de eindgebruiker. Door configuratie komen deze pagina’s terecht in het gebruikersmenu. Het openen en sluiten van pagina’s kan op vraag van de gebruiker, of op vraag van een (andere) deelapplicatie. In elk geval gebeurt dit volledig onder controle van het omgevingsmodel. Zo kan het omgevingsmodel een Addin opstarten die nog niet actief is, wanneer voor het eerst een pagina geopend wordt, en kan het omgevingsmodel een Addin weer afsluiten wanneer de laatste pagina van deze Addin dicht gaat.

Zoals hierboven vermeld omvat het omgevingsmodel middelen ter navigatie volgens een uitvoeringsvorm van de uitvinding. Het addin contract voorziet in een tekstgebaseerd adres formaat (als een web url) als middel ter navigatie naar een bepaalde pagina, of naar een specifieke positie in een pagina. Navigeren naar een pagina kan wanneer de unieke addin naam en pagina naam gekend zijn, bv via "mw: \\addinname\pagename’’, en vereist geen specifieke ondersteuning in de aangesproken addin. Positioneren binnen een pagina is mogelijk. Bovendien kunnen de Addins voorzien zijn om een navigatie aan te vragen naar een andere context (bv. op basis van patiëntnummer) of een andere pagina, zonder dat de Addins informatie nodig hebben over de implementatie details van deze pagina (zoals op welke technologie de pagina steunt). Bovendien kennen de Addins en de hosts elkaar bij voorkeur enkel via het addin contract. Als een voordelig gevolg hiervan weten de Addins van elkaar niet, welke andere Addins gelijktijdig actief zijn. Figuur 2 toont ter illustratie, schematisch de besproken concepten van het Addin framework en de manier waarop deze aangewend worden.

Als een voordelig gevolg van het systeem en de integratie methode volgens bepaalde uitvoeringsvormen van de uitvinding, kan men een workflow bekomen worden van enerzijds de gebruiker en anderzijds de patiënt, over alle afdelingen en specialismen heen van het ziekenhuis, hierdoor zal men “patiënt centrale zorg” kunnen aanbieden en verder ondersteunen. Dit wordt tevens schematisch geïllustreerd in Figuur 3. Men kan ook klinische paden onderbrengen en de eindgebruiker van het medisch station het gevoel geven te werken met “zijn/haar” persoonlijke applicaties. Dit kan gerealiseerd worden door een eindgebruiker specifieke workflow op te zetten, waarbij de eindgebruiker zelf zijn eigen voorkeur kan bepalen.

Bovendien geeft elke deelapplicatie, die onderdeel is van een het omgevingsmodel die alle deelapplicaties integreert, ondersteuning aan het zorgtraject van een patiënt (zowel binnen als buiten het ziekenhuis). Dit wil dus ook zeggen dat zowel ziekenhuis-brede als departementale toepassingen deelapplicaties kunnen zijn. Voorbeelden van deelapplicaties zijn onderzoeksresultaten, alerts, klinische paden, medisch dossier, medicatiebeheer, medisch secretariaat workflow, ordercommunicatie, verpleegdossier, ... Anderzijds is bv een facturatiesysteem geen deelapplicatie. Deze deelapplicaties moeten door het ziekenhuis zelf toegevoegd kunnen worden, zonder tussenkomst van het geïntegreerd medische werkstation (op voorwaarde dat de nodige technische voorwaarden zijn ingevuld door de deelapplicatie).

Het is vanzelfsprekend dat bovendien ook integratie mogelijk is van de verschillende uitvoeringsvormen van het omgevingsmodel met gekende services van het eHealth-platform, bijvoorbeeld timestamping (elektronische voorschriften), regionale HUB’s, eBirth met een geïntegreerd gebruikers- en toegangsbeheer.

Zoals vermeld, kan volgens uitvoeringsvormen van de uitvinding het omgevingsmodel visueel worden voorgesteld. De visualisatie is voorzien van middelen om de presentatie van gegevens uit allerhande ingeplugde applicaties in één view te tonen en dit voor beide contexten. Vanuit deze presentatie kan men naar de onderliggende applicatie gaan om meer details te zien, bijvoorbeeld alerts. Vanuit verschillende applicaties kan informatie worden opgehaald en getoond ten behoeve van de besluitvorming en de generatie en afhandeling van verschillende taken. Bovendien is visuele integratie vanuit de workflow met doorgeven van parameters mogelijk. Dit gebeurt bijvoorbeeld door het openen van het protocolscherm uit een applicatie vanuit paden met op voorhand gedefinieerde parameters zoals protocol-id., startdatum, ...

Samenvattend biedt het omgevingsmodel volgens bepaalde uitvoeringsvormen van de uitvinding verschillende voordelen, één ervan is het eenduidig presenteren en benaderen van bestaande informatie over het zorgproces door middel van: (1) Het bevorderen van de uniformering van verschillende informatie en informatiebronnen en het bieden van een continue zorgverlening door bijvoorbeeld een zorgnemer op te volgen doorheen zijn/haar volledige levensloop. Bovendien kunnen verschillende personen door het geïntegreerd medisch werkstation toegang verleend krijgen tot de informatie binnen het ziekenhuis (intramuraal), tot de informatie van eerstelijnszorgverstrekkers die zich niet in het ziekenhuis bevinden (extramuraal) of tot informatie bekomen vanuit telemonitoring of thuiszorg in het algemeen. Tevens zal het geïntegreerde medische werkstation gegevensuitwisseling tussen ziekenhuizen of eerstelijnszorgverstrekkers mogelijk maken. Ook informatie-uitwisseling van het ziekenhuis naar de huisartsen en uiteindelijk naar de zorgnemer zelf is mogelijk. Ook informatie-uitwisseling in de andere richting is mogelijk, namelijk vanuit de huisartsen, thuisverpleging, apotheek of zorgnemer naar het ziekenhuis is mogelijk door het geïntegreerde medisch werkstation. Voor dit laatste, kan in een uitvoeringsvorm van de uitvinding ook rekening worden gehouden met de wettelijke en ethische regels hierrond.

Als een gevolg van de integratie, kan men een geïntegreerd patiëntendossier bekomen die alle applicaties kan delen die het patiëntendossier bevat en die bovendien geïntegreerd en gesynchroniseerd kunnen worden. Bovendien zijn fouten in context (twee patiënten) onmogelijk. Navigatie door een werklijst is mogelijk en kan zorgen voor synchronisatie van alle toepassingen.

Het omgevingsmodel kan volgens uitvoeringsvormen van de uitvinding verder nog middelen ter identificatie en logon omvatten, bijvoorbeeld e-ID, Single Sign-On (SSO), privacy-mechanismen, toestemmingen, etc. waarbij de identificatie doorgegeven wordt aan de deelapplicaties, zodat met SSO gewerkt kan worden. Single sign-on (SSO) is een eigenschap van controle op de toegang van meerdere verwante, maar onafhankelijke software systemen. Met deze eigenschap kan een gebruiker die zich in een keer aanmeldt en toegang krijgt tot alle systemen zonder gevraagd te worden om opnieuw in te loggen bij elk van de systemen. Single sign-off is de omgekeerde eigenschap waarbij een enkele actie van de ondertekening de toegang tot meerdere software systemen beëindigt. Hierbij moet ook een snelle user-switch beschikbaar zijn, zodat al dan niet zonder verlies van context het mogelijk is om van gebruiker te wisselen (en dat dit doorgeduwd wordt naar de deelapplicaties). De snelle-user switch laat ook toe om een break-out mogelijkheid toe te laten zonder de huidige sessie te moeten verlaten. De SSO kan gebeuren via Windows authentication en session token of via e-ID.

Het omgevingsmodel omvat volgens bepaalde uitvoeringsvormen van de uitvinding een unieke drievoudige contextwerking: gebruiker, werklijsten, patiënt. Men kan of werken in gebruikerscontext, ofwel werken in patiëntcontext (patiënt gecentreerd), of men kan navigeren via ingebouwde patiënten lijsten. Het omgevingsmodel kan ook menu’s omvatten die opgesplitst zijn in drie subniveaus, namelijk gebruiker, patiënt en administrator. De menu’s kunnen ook configureerbaar zijn, ze kunnen bijvoorbeeld aangepast worden aan het ziekenhuis, zorgverstrekkers en de applicaties die beschikbaar/toegankelijk zijn (toestemmingen). Bovendien kunnen de menu’s ook aangepast worden aan de context waarin men werkt (gebruiker, patiënt).

In een uitvoeringsvorm van de uitvinding is het omgevingsmodel verder voorzien van middelen om uit een groep van patiënten te kunnen selecteren en opzoeken door de gebruiker. Hiervoor zijn er dynamische werklijsten voorzien. Een dynamische werklijst wordt opgebouwd op basis van een beperkte lijst van patiënt-attributen. Het is de bedoeling zoveel mogelijk patiënt-lijsten te ondersteunen, maar met de beperking dat de definitie van een patiënt-lijst afhangt van attributen die opzoekbaar zijn door het omgevingsmodel. Bovendien is er een mogelijkheid voor de gebruiker om zich in te schrijven voor bepaalde patiënten, bijvoorbeeld zijn patiënten die hij onderzoekt, routing, navigatie, etc. Ook standaardlijsten zullen integreerbaar zijn. Het opzoeken in deze lijsten kan bijvoorbeeld op naam (fonetisch en/of exact), op opnamenummer, op patiënt-nummer, op geboortedatum, etc. Vanuit de selectie van de patiënt of het zoekresultaat is het heel eenvoudig een specifieke deelapplicatie op te starten met als referentie de gekozen patiënt. Dit kan als basis gebruikt worden voor het dashboard functie bijvoorbeeld.

De visualisatie van het omgevingsmodel kan bijvoorbeeld het eerste scherm zijn dat een gebruiker te zien krijgt en volgens een uitvoeringsvorm van de uitvinding zal het de visualisatie een duidelijk zicht kunnen geven aan de gebruiker betreffende zijn taken voor die dag, de informatie waarover hij moet beschikken en toelaten onmiddellijk meer detail op te vragen voor de respectievelijke taak of informatie. Deze functie laat toe het medisch werkstation naast Patiënt-Centrisch ook Gebruikers-Centrisch te ontwikkelen. De visualisatie van het omgevingsmodel kan in twee stappen werken: (1) Het geeft een globaal zicht over de patiënten heen (ook bijvoorbeeld de gekozen patiënt-lijst van de user, bv ‘zijn patiënten’), waarbij de nadruk ligt op punten die belangrijk zijn binnen het huidig takenpakket van de gebruiker (alert-functie), en (2) de visualisatie geeft een zicht op de gekozen patiënt, waarbij de nadruk opnieuw ligt op punten die belangrijk zijn binnen het takenpakket van de gebruiker. De visualisatie laat toe om snel in te zoomen op relevante informatie van de patiënt en in te spelen op snel wijzigende toestanden. Het dashboard kan ook een zicht leveren op de patiënt-agenda (geplande onderzoeken, aangevraagde maaltijden,...).

Hoewel de uitvinding beschreven is met verwijzing naar specifieke uitvoeringsvormen, zal het voor de vakman duidelijk zijn dat verschillende wijzigingen en aanpassingen in vorm en detail mogelijk zijn zonder af te wijken van de beschermingsomvang van de conclusies voor de huidige uitvinding.

Claims (10)

1. Een computer gebaseerd integratie systeem ter bevordering van het zorgproces van een zorgnemer, omvattend een omgevingsmodel voorzien van: - een geheel van software componenten; - middelen om verschillende applicaties, die gebruik kunnen maken van verschillende technologieën, te integreren en synchroniseren, - middelen om verschillende applicaties te kunnen aanpassen of aansturen - middelen om wisselwerking tussen de verschillende applicaties tot stand te brengen en waarbij de wisselwerking context-afhankelijk is, en waarbij het geheel van software componenten uitbreidbaar is door aan de applicaties verschillende uitbreidingspakketten toe te voegen.

2. Het integratie systeem zoals in conclusie 1 waarbij de verschillende applicaties vanuit een driedimensionale context bekeken kunnen worden.

3. Het integratie systeem volgens één van de voorgaande conclusies waarbij in het systeem van een geïntegreerd medisch werkstation een eindgebruiker-specifieke workflow kan worden aangemaakt.

4. Het integratie systeem volgens één van de voorgaande conclusies waarbij de middelen om de verschillende applicaties te integreren visueel kunnen worden voorgesteld.

5. Het integratie systeem volgens conclusie 4, waarbij de visualisatie onafhankelijk van het omgevingsmodel kan gewijzigd worden.

6. Het integratie system volgens één van de voorgaande conclusies waarbij in het systeem een geïntegreerde medisch werkstation intramuraal of extramuraal kan gebruikt worden.

7. Het integratie system volgens één van de voorgaande conclusies waarbij in het systeem de verschillende applicaties van een geïntegreerd medisch werkstation geselecteerd kunnen worden met behoud van de context.

8. Het integratie systeem volgens één van de voorgaande conclusies waarbij in het systeem een geïntegreerd medisch werkstation een identificatie en inlog middelen omvat waarbij de identificatie data doorgegeven wordt aan de verschillende applicaties.

9. Het integratie systeem volgens één van de voorgaande conclusies waarbij in het systeem de verschillende applicaties van een geïntegreerd medisch werkstation voorzien kunnen zijn van deelapplicaties.

10. Een computer gebaseerde integratie methode ter bevordering van het zorgproces van een zorgnemer, omvattende een omgevingsmodel voorzien van een geheel van software componenten en omvattende volgende stappen: - integreren en synchroniseren door verschillende applicaties, die gebruik kunnen maken van verschillende technologieën, - aansturen of aanpassen en aansturen van verschillende applicaties, - tot stand brengen van een wisselwerking tussen de verschillende applicaties en waarbij de wisselwerking context-afhankelijk is, en waarbij het geheel van software componenten uitbreidbaar is door aan de applicaties verschillende uitbreidingspakketten toe te voegen.