Country Selector: Nederland
Zoals ook te lezen in het artikel van Ingo, is het basisplatform van Ascom zeer open en uitbreidbaar door gebruik te maken van onder andere integraties. Dit kan op verschillende manieren of lagen binnen een compleet ’ecosysteem’. Het 4-lagen model van ons portfolio beschrijft op een organisatorisch niveau hoe integraties tot stand kunnen komen. Deze vier lagen zijn echter ook te plotten op een aantal technische “routes” of standaarden, welke gebruikt worden voor zowel de interne communicatie als voor integraties met derden.
Jeroen Veelenturf, Solutions Architect
Hieronder staan deze 6 routes benoemd en nader toegelicht:
Unite als transparant carrier
Er bestaan tal van integraties met onder meer verpleegoproepsystemen van derden, brandmeldinstallaties en gebouwbeheersystemen die al bij u aanwezig zijn. Uit deze systemen moeten berichten naar een eindgebruiker verstuurd worden. Via de Unite als transparant carrier route wordt de ‘toewijzing’ (naar wie moet welke oproep gestuurd worden?) bepaald door het bronsysteem en geeft Ascom deze berichten simpelweg door.
Digistat
Digistat is binnen het Ascom-portfolio het slimme koppelvlak voor medische apparatuur. Niet alleen worden alarmen ’ingekoppeld’ maar bij deze alarmen wordt ook de relevante context meegestuurd (huidige vitale waarde, ingestelde alarmgrens). Daarnaast kunnen vanuit Digistat ook andere voor de klant relevante systemen (PDMS, EPD) gevuld worden met de data uit medische apparatuur. Dit is een mooi voorbeeld waarbij er niet alleen inkomende data wordt geïntegreerd, maar er ook een uitgaande integratie is. Door de manier waarop het platform is opgebouwd, kan binnen een zeer korte doorlooptijd een nieuwe ‘driver’ worden ontwikkeld welke klasse IIb is gecertificeerd zodat uw specifieke apparaat ook geïntegreerd kan worden.
Unite als middleware
Naast dat Unite berichten een op een kan ‘doorgeven’ aan een specifieke handset of systeem van derden, bevat Unite ook een logica-laag. Hierin kan context aan een alarm of notificatie kan worden toegevoegd (denk aan de naam van de patiënt/cliënt of werknemer) en kan ook worden bepaald naar welke (zorg)medewerker (op naam óf functie) het bericht moet worden gestuurd. Deze toewijzing is dynamisch in te richten, waarbij zowel het inkomende als uitgaande systeem een Ascom eigen systeem kan zijn, maar ook een systeem van derden zoals een ander verpleegoproepsysteem. Op deze manier is de juiste informatie altijd op het juiste moment bij de juiste (zorg)medewerker.
Unite SmartSense
Binnen Unite SmartSense zijn er meerdere integraties gemaakt waarbij verschillende systemen input kunnen geven om tot een ‘status’ van bewoners te komen. Denk aan sensoren in de kamer, slimme camera’s of een bedmat, waarbij ook niet Ascom-sensoren gebruikt kunnen worden. Aan de hand van het ingestelde profiel leiden deze statussen wel of niet tot notificaties, waarbij ook deze notificaties weer binnen het Ascom systeem kunnen blijven of naar een ander, zelf gekozen en aangeschaft systeem, ontsloten kunnen worden.
teleCARE IP
Binnen de verpleegoproepsystemen van Ascom kunnen verschillende alarmbronnen worden ingekoppeld. Denk aan medische apparatuur op de NIMA, maar ook kin- en blaasbellen. Daarnaast kunnen andere systemen op de ‘uitgaande’ kant geïntegreerd worden zodat dwaaldetectie (door gebruik te maken contactinterfaces op deursturing en toegangscontrole) wordt gerealiseerd.
Unite Admin/Unite Platform Server
Tot slot zijn er binnen Unite Admin verschillende ‘management’ integraties mogelijk. Denk aan een Active Directory of IAM-systeem. Voor een deel zijn deze integraties gebaseerd op standaarden (LDAP, HL7), maar ook kan gebruik worden gemaakt van API’s. Deze API’s kunnen gebruikt worden om input te geven aan het systeem (bijv. aanmaken en beheer van gebruikers), maar ook om informatie op te halen. Denk aan de huidige toewijzing: welke verpleegkundige is verantwoordelijk voor welke patiënt of welke alarmen zijn op dit moment actief zijn.
Zoals gezegd zijn deze zes technische routes te plotten op de vier lagen die Ingo heeft beschreven:
Deze zes routes gebruikt Ascom een groot scala aan ‘technieken’ om te integreren, waarbij ESPA, HL7, OAP, JSON, API’s, LDAP, SNMP en contactinterfaces slechts enkele voorbeelden zijn. Dit alles maakt dat, verdeeld over de zes technische routes en vier lagen, we meer dan 350 integraties hebben met andere leveranciers.
Wat de opbouw van het ‘ecosysteem’ bijzonder maakt, is dat de zes technische routes/integratiepatronen niet alleen voor inkomende integraties van toepassing zijn. Er zijn tal van leveranciers die met ‘alles’ kunnen koppelen. De beperking zit echter vaak in het feit dat dit met name inkomende berichten betreft; er kan door de leverancier wel een stekker gemaakt worden, maar alle stekkers worden nog steeds door één leverancier geleverd. Op deze manier loop je alsnog het risico, zoals Egied heeft beschreven, om in een ‘vendor lock-in’ te geraken. Doordat er binnen de Ascom-oplossing zowel inkomend als uitgaand verschillende opties zijn om te integreren, is er een zeer ruime keuzevrijheid. Dankzij de open standaarden zijn deze , zowel nu als in de toekomst ook goed te onderhouden. Dit is hoe Ascom met een open platform meewerkt aan een ‘best of breed’ oplossing, waar u mee bent geholpen.
Naast al deze integraties heeft Ascom meerdere eigen apps die op verschillende typen handsets ondersteund worden, naast (web)applicaties die op een PC gebruikt worden. Ook worden meer dan 20 apps van andere leveranciers formeel ondersteund op de handsets van Ascom.
Tot slot heeft Ascom met meer dan 30 leveranciers een interoperabiliteit verificatie als het gaat om telefonie, DECT en WiFi. Deze interoperabiliteit wordt continu door R&D geverifieerd/getest zodat deze altijd up–to-date zijn.
Dit alles maakt dat Ascom verschillende technieken en opties heeft om samen met u tot een totaaloplossing te komen. U heeft de vrijheid om functionaliteiten te beleggen bij leveranciers waar u vertrouwen in heeft zodat het werkproces zo optimaal mogelijk ondersteund wordt.