The eHealth Infrastructure provides a seamless integration with a range of national available services; among these are the central video endpoint provided by MedCom. Clients of the eHealth Infrastructure are able to interact with the video endpoint using the designated FHIR Appointment ehealth-videoappointment and its associated RESTful methods (create, read, update).
...
(The steps 1, 2 and 3 are steps that are needed regardless of what interaction is done - see more regarding security on Security )
Clients interact with the eHealth Infrastructure by requesting access using the Authorization Service
Client is redirected to its IdP and access is granted
Client interacts with the infrastructure. In this particular scenario a video appointment is created/updated/read.
The microservice responsible for wrapping the VDX endpoint as a FHIR endpoint is invoked.
In order for step 4 to be successful a mutual trust is established between the microservice in the eHealth Infrastructure and the VDX endpoint. This is done by having exchanged SSL certificates during time of installation of the eHealth Infrastructure. As the VDX endpoint provides its own STS service as well as the actual REST interface, trust is established to both endpoints.
Whenever a client manipulates (anything but read operations) a videoappointment video appointment in the eHealth Infrastructure the microservice responsible for wrapping the VDX endpoint is invoked and communicates with the VDX endpoint. As such, it is transparent of the clients of the eHealth Infrastructure that they communcate communicate with the actual VDX endpoint. This also means that the eHealth Infrastructure acts as a cache for the VDX endpoint which in turn means that the security model for accessing video appointments is governed by the rules listed on Token Based Security (the ruleset for accessing video appointments follows the same rules as for regular appointments).
The video meeting itself is hosted and served by the VDX service and not the eHealth Infrastructure