For any integration with an Application Provider, the Provider Organization needs to be connected to the Founda Platform. Founda offers multiple options for establishing secure connectivity between Provider Organization systems (e.g. EHR) and our platform. A connection with the Founda platform is defined through a combination of the Data Exchange Direction, a Communication Protocol and a Network Type. Below we explain the options for each of these categories.
Data Exchange Direction
Data exchange between the Founda platform and a Provider Organization's EHR can flow two ways. This depends on the use case that the integration is solving. We define the directions from the perspective of the Provider Organization.
Incoming: incoming calls to the Provider Organization's data sources on the Provider Organization's network, coming from the Founda Platform. For example: calls to the Provider's internal FHIR endpoints or queries to the Provider's HL7v2 interfaces.
Outgoing: events and synchronous calls initiated by the Provider, going to the Founda Platform. For example: outgoing HL7v2 messages or FHIR requests to Founda's FHIR endpoints.
Bidirectional: both incoming and outgoing data exchange is required. For example: an outgoing HL7v2 message from the Provider triggers an incoming query to one of the Provider's HL7v2 interfaces.
Network Type
An integration between Founda's Platform and a Provider Organization's network can make use of one or multiple connectivity methods.
We support a secure connection between the healthcare organization and Founda's cloud infrastructure through a Site-to-Site VPN connection.
We can support VPN connections with the following list of customer devices*.
Founda uses two tunnels for high availability in a Site-to-Site VPN configuration. This way, if one tunnel experiences a disruption or failure, the second tunnel can seamlessly take over. We strongly advise Provider Organization's that are integrating with our platform to support two tunnels.
In order to establish the VPN connection there is information that Founda requires from the hospital:
Field
Description
Type
Required
Traffic direction
Which direction does the traffic need to flow from hospital's perspective?
Incoming, Outgoing, Bidirectional
Yes
Hospital CIDRs
What CIDRs are communicating with Founda? This can be more than one CIDR.
List of CIDRs
Yes
Public gateway IP
The public IP address of the hospital's gateway which terminates the VPN at your side.
IP address
Yes
Source IP
IP address of the source system sending traffic to Founda
IP address
Yes, if the traffic direction is outgoing.
Destination endpoint*
IP address and port of the destination system Founda should send traffic to.
IP address and port
Yes, if the traffic type is incoming.
*If your destination endpoint/IP odes not fall under one of the following categories, we cannot have your source and destination IP to be the same: 10.0.0.0/8 (RFC1918), 100.64.0.0/10 (RFC 6598), 172.16.0.0/12 (RFC 1918), 192.168.0.0/16 (RFC 1918)
After Founda has initialized the VPN, Founda will share the following information that the hospital requires to finalize the set-up:
Field
Description
Type
Founda CIDR
The CIDR Founda has reserved for the hospital (in case of overlap with your internal network Founda can change this).
CIDR
Founda Gateway IP
The IP address of Founda's gateway which terminates the VPN at Founda's side.
IP address
Founda DNS server
The DNS server Founda exposes for the hospital to query (this way the hospital can resolve a domain name like connector.<hospital name>.founda).
IP address
Endpoint of the connector
The endpoint of the connector, supporting IP types: 10.0.0.0/8 (RFC 1918), 100.64.0.0/10 (RFC 6598), 172.16.0.0/12 (RFC 1918), 192.168.0.0/16 (RFC 1918)
Hostname and port
Founda supports connectivity utilizing the public internet to connect to the platform. This connectivity method is not allowed with all communication protocols, for example unencrypted protocols (like MLLP) cannot be used with the Public Internet.
Founda does allow the public internet for HTTPS and HTTPS with mTLS.
For every integration and desired connectivity we will validate if the combination is secure enough.
In case of incoming traffic to the hospital:
The hospital has to allow network traffic coming from Founda. This generally involves configuring your firewall or network security infrastructure to permit incoming traffic from the Founda IP, which we can provide on request.
In case of outgoing traffic from the hospital:
Founda will provide the endpoint for the hospital to connect with. The hospital should set-up the right configurations to allow outgoing traffic to Founda's endpoint, for example in the firewall or the proxy.
The connectivity between a hospital and the Founda Platform can be enabled by so-called Community Networks. These are collaborative network infrastructures, generally shared among multiple healthcare entities, that provide a shared environment for secure and standardized data exchange.
In case the Provider Organization wants to make use of a Community Network, Founda needs to configure access to our internal gateway for these providers. Next to that, the Provider Organization has to be part of the Community.
Current supported community networks are:
Netherlands
KPN E-Zorg
United Kingdom
NHS England - Health and Social Care Network (HSCN)
Founda can support an integration with a Provider Organization through a dedicated connection, such as AWS DirectConnect. Dedicated connections are provided on a per-case basis and require additional scoping. Setting up a dedicated connection comes with additional costs.
Communication Protocol
Founda supports multiple communication protocols for Provider Organizations to integrate with the platform. Below the most-common ones are listed with a technical specification. Depending on the specific requirements of the integration and the level of security needed for the data exchange you can choose between MLLP and HTTPS. Founda's support is not limited to these protocols, we can accommodate diverse integration needs based on the specific project requirements and scope.
Founda supports MLLP as a communication protocol over a TCP connection. MLLP is commonly employed for integrating healthcare systems where the exchange of HL7v2 messages is required.
For the MLLP protocol there is information that Founda requires from the hospital:
Field
Description
Type
Required
Traffic direction
Which direction does the traffic need to flow from hospital's perspective?
Incoming, Outgoing, Bidirectional
Yes
MLLP source IP
The IP address of the source system that will be sending messages to Founda.
IP address
Yes, if the traffic direction is outgoing.
MLLP destination endpoint
The host and port of the server that will be receiving messages from Founda
Endpoint and port
Yes, if the traffic direction is incoming.
Founda will be providing the following information:
Field
Description
Type
Required
MLLP destination address
Founda's destination address that the hospital can send messages to.
connector.<hospital name>.founda
Yes, if the traffic direction is outgoing
MLLP destination port
Founda's destination port number that the hospital can send messages to.
Port
Yes, if the traffic direction is outgoing
Founda supports HTTPS as a communication protocol over a computer network. HTTPS is commonly employed for data transmission in web-based applications or API interactions.
Specifications:
All Founda's public endpoints are signed using a public Certificate Authority (CA). In the case that the hospital is managing their own trusted CAs, additional configurations might be necessary.
The minimum supported version of the TLS protocol for secure communication with Founda's services is TLS 1.2. We highly encourage and advise the use of TLS 1.3 for enhanced security.
In case of HTTPS over a Site-to-Site VPN connection, the following considerations apply:
To ensure secure internal communications, a private CA is required to issue and manage certificates for HTTPS over VPN. Who will manage the private CA is part of the project scoping.
This method of integration requires involvement of the Founda Infrastructure team.
If required, Founda also supports HTTPS with mTLS. Depending on the nature of the communication it is determined whether Founda or the hospital acts as the server side.
The server side determines which clients are allowed to connect and thus is responsible for managing the Certificate Authority - signing the client certificates.
Founda expects the CA to accept a Certificate Signing Request which it can sign.
Summarizing
Data Exchange Direction
Incoming
Outgoing
Bidirectional
Network Type
Site-to-site VPN
Public Internet
Shared Community Network
Dedicated Connection
Communication Protocols
MLLP
HTTPS
HTTPS with mTLS
A Practical Example
Below you'll find an example to summarize the different connectivity options and how the different data flows can use a combination of different network connectivity and communication protocols.
Use case
Your hospital is going to use and integrate an application for filling in online questionnaires. This application is notified each time a patient is scheduled for surgery using an HL7 message that is actively "pushed" to the Founda Health Platform (see the Subscription Service). This way the application can determine that a questionnaire has to be send. Once the patient has filled in the questionnaire, the questionnaire is send back to the EHR as a PDF file.
Data flow
When a patient is scheduled for a surgery this generates an HL7v2 message of type ADT^A05. These messages are outgoing from the hospital's HL7v2 interface to the Founda Platform.
Your hospital also has a FHIR API with a DocumentReference endpoint. Founda sends the pdf files as a FHIR DocumentReference to the hospital's FHIR API. This is an incoming call.
Connectivity
For the HL7v2 ADT^A05 the hospital will connect with Founda's HL7v2 connector for the hospital's EHR. The hospital will send the HL7v2 payload according the MLLP protocol over a VPN connection.
For the FHIR API the hospital is sending a FHIR-based JSON payload over HTTPS. Since HTTPS is already secure in itself, this connection uses the public internet.
