Functional Concepts

 

Koppeltaal Server 

The main functional scope of Koppeltaal Server is to define a standardised model of the functions that may be present within a Domain. The Functional scope is limited to the Patient-Caregiver-RelatePerson relation where the Patient is central.

 

server functional

 Functional Domain Boundaries are represented by Portals (Caregivers, Related Persons, ..) and Interventions (E-Games, ROM, ...)

 

functional scope

Roles

Roles 

 Main roles in scope are: Patient, Caregiver, RelatedPerson, Intervention Provider, System Administrator:

 

Administrator

(system role)

administrator

Caregiver

(functional role)

Patient

(functional role)

Intervention provider

(system role)

Related Person 

(functional role)

 

Applications landscape

Each role has a dedicated set of application that create the complete system landscape of Koppeltaal Server. 

Portals are part of a Domain and they will be configured as such: the scope of a portal is limited to the functional roles (Patients & Related Persons, Caregivers).

System roles can go over domains: System Administrator Manages multiple Domain and an Intervention provider can provide the same intervention in different domains also.

 

Administrator

(system role)

Caregiver Portal

(Caregiver role /

part of a Domain)

Patient & Relatives Portal

(Patient & RelatedPerson /

part of a Domain)

 

Intervention provider

(system role)

 

 Persistence

Possibility to Persist the State within a Domain. 

Koppeltaal offers the possibility to integrate a Persistent Service with the

existing applications.

 

Process flow and Functional API

 

Message retrieval

Message retrieval is an important part of Koppeltaal Server as it decouples the applications completely. One of the main features is the possibility to queue messages for specific destinations and let the End Application take the charge in completing the process. The messages will be available and queued with a status (NEW, CLAIMED, SUCCESS or FAILED) and a scope (patient id).

API for message retrieval is separated in two main concepts:

- get ALL new messages

- search for a message type in the scope of a Patient

 

 

 

Create Or Update Activity Definition

Each intervention must provide an activity definition as part of the Koppeltaal Catalog. This is part of one or multiple domains - an activity can be active or not and can have a default role performer. 

 

 

Create or Update CarePlan

CarePlans gets created and managed mostly by the Caregiver. The main design concepts limit this activity, but they do not forbid it. As such, the CarePlans can get updated by the Interventions also (adding new Sub-Activities or managing the Activity Status direct in the CarePlans). 

A care plan contains the main roles and interventions. 

 

 

 Launch Sequence

Launching an intervention follows a simple authentication process (specs OAuth). The main roles involved in the process are the Caregiver and the Patient or the RelatedPerson. CarePlan availability indicates that there is a intervention assigned to this Patient.  

 

 

For distributed environments that are not part of an authenticated model, Koppeltaal extends the OAuth sequence through a special model: activation tokens. The Activation tokes are received as part of a special Call: Generate Unique Token ID for any CarePlan. The token will link the Patient with a CarePlan and its dependencies. 

Token Refresh - a functional setup for providing additional security on the point-to-point connectivity:tokens are valid only for initial connection and a refresh token will be valid only on a separate timeframe. An expired refresh token needs to be recreated as part of the process.

 

Activity Status Update

Activity status updates are sent from Intervention towards the Portals as informational data.Of course UpdateCarePlan can also be used for this kind of operations.

There are a set of predefined states available that can be used as part of the domain ontological model:

To play the ideal flow the next picture describes the interactions as they get processed in the enterprise. The update is requested by the Patient through the intervention and the Caregiver accepts it and attaches it to the Care Plan. In this way only the owner of the CarePlan will change the contents of the CarePlan itself.

 

Create or Update Activity Result

 

 

Update Activity Result by Additional Subactivities

 

Activity Results can be mixed with Subactivities in order to transport the state of the respective Activity. 

Create Or Update Patient/Caregiver/Related Person

 

 

Persistence API FLOW 

GET Gets any stored items that match the given id or the search arguments.

PUT Updates an existing entry.

POST Stores a new item

DELETE  Deletes any stored items that match the given id or the search arguments.

FULL API Overview

Voor wie is Koppeltaal?

Voor GGZ instellingen

GGZ instellingen zijn de ‘consumenten’ van de koppeltaal. De mogelijkheid om data tussen verschillende applicaties uit te wisselen maakt het mogelijk om interventies ontwikkeld door anderen dan je ‘eigen’ e-health platform leverancier te gebruiken in je behandelingen. Zo kan iedere GGZ instelling een optimale mix van e-health samenstellen voor haar patiënten.

Naast flexibiliteit en maatwerk besparen GGZ instellingen hiermee kosten. In plaats van per interventie een point-to-point integratie te maken wordt hergebruik gemaakt van investeringen in de koppeltaal.

Wil je weten of jouw GGZ instelling al gebruik maakt van koppeltaal? Als je aangesloten bent bij de cooperatie e-lab autisme, trauma, of verslaving dan doe je al mee. Wil je meer weten, Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken..

Voor e-health leveranciers

De 'klanten' van de stichting koppeltaal zijn IT leveranciers die producten of oplossingen aan GGZ instellingen en aan samenwerkingsverbanden van GGZ instellingen leveren. Klanten commiteren zich aan het gebruik van de koppeltaal voor gegevensuitwisseling met hun applicatie waar mogelijk.

Koppeltaal start in verzie 1 met het mogelijk maken van uitwisseling tussen e-health platformleveranciers, zoals Minddistrict en Quli en e-health interventies zoals Kickass, een game voor kinderen met autisme. Andere IT leveranciers, zoals makers van Routine Outcome Measurement Systemen (ROM) en elektronische patienten dossiers (EPD's) hebben ook belangstelling getoond en koppeltaal is met hen in gesprek voor versie 2.

De 'klanten' van koppeltaal hebben een commerciële en/of technische verantwoordelijkheid in hun organisatie. Als je 'klant' van koppeltaal wilt worden, Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. om te informeren naar de mogelijkheden.

Blog highlights
 
 

Contact Koppeltaal
Uw naam
E-mail...
Write your message!

Blijf niet achter. Meld uzelf aan voor onze nieuwsbrief.