Provider Connectivity

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 site to site vpn 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 vendor platform software checkpoint gaia r80 10+ cisco meraki mx series 15 12+ (webui) cisco systems, inc asa 5500 series asa 9 7+ vti cisco systems, inc csrv ami ios 12 4+ fortinet fortigate 40+ series fortios 6 4 4+ (gui) juniper networks, inc j series routers junos 9 5+ juniper networks, inc srx routers junos 11 0+ mikrotik routeros 6 44 3 palo alto networks pa series panos 7 0+ sonicwall nsa, tz os 6 5 sophos sophos firewall v19+ strongswan ubuntu 16 04 strongswan 5 5 1+ yamaha rtx routers rev 10 01 16+ see the latest list https //docs aws amazon com/vpn/latest/s2svpn/your cgw\ html#example configuration files from aws 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 tunnel options aws https //docs aws amazon com/vpn/latest/s2svpn/vpntunnels html https //docs aws amazon com/vpn/latest/s2svpn/vpntunnels html 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 public internet 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 community network 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) dedicated connection founda can support an integration with a provider organization through a dedicated connection, such as aws directconnect https //aws amazon com/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 mllp 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 https 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 https with mtls 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 { "columns" \[ { "id" "1", "name" "data exchange direction", "items" \[ { "id" "5vdwmvol0caioikp4ja5a", "content" "incoming", "justadded" false }, { "id" "0wvg04n6thwjrvbuuexg8", "content" "outgoing", "justadded" false }, { "id" "skhgblr3fcjmkwx wjnv5", "content" "bidirectional", "justadded" false } ] }, { "id" "2", "name" "network type", "items" \[ { "id" "l3pbtb3p6yrevr0 lohom", "content" "site to site vpn", "justadded" false }, { "id" "vbl f7fb dz1vnczwxaa8", "content" "public internet", "justadded" false }, { "id" "jfkvy2vhaqs 9mbo12v5", "content" "shared community network", "justadded" false }, { "id" "m vcit8kxdv juznggyvk", "content" "dedicated connection", "justadded" false } ] }, { "id" "3", "name" "communication protocols", "items" \[ { "id" "auqxki6lutafh4blpyuf8", "content" "mllp", "justadded" false }, { "id" "mjhdggpzdsonbxv0cx1z5", "content" "https", "justadded" false }, { "id" "mvu9ddkbj82dskarhycot", "content" "https with mtls", "justadded" false } ] } ] } 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 docid\ t6y412gfyekpqxpj7xefc ) 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