Clients

every application provider that is looking to interact with (clinical) systems in the provider organization's infrastructure is represented by a client on the founda platform think of this client as your application's "client profile", defining exactly what data access you need before any application can access any data, these clients have to be authorized by the healthcare provider the application is looking to interact with a client on the founda health platform has a name and description describing the application the provider organizations will see this when you are requesting authorization so they know who is the requesting party a set of oauth2 0 client credentials client id unique identifier for the client client secret secret only known to the application provider owning this client a set of action scopes the action scopes define which (fhir) data resources and interactions this client requires in order to deliver its value imagine that your company is offering a patient portal platform with an application for appointment scheduling you would be represented on the founda platform as an application provider your application for appointment scheduling needs access to patient data, practitioner data, and schedule and appointment data to synchronize the doctor's scheduling between an ehr and your application on the founda platform you create a dedicated client the beauty of this client is that you can reuse it for all healthcare providers that you would like to integrate your appointment scheduling application with now, let's say your company is expanding the patient portal platform's services to include remote monitoring to keep data access well organized and secure, you can create an additional client specifically for this new functionality creating distinct clients for different functionalities offers a clear advantage it ensures a separation of data access requirements, which is especially handy when different functionalities are offered to different healthcare providers each client profile is independently authorized, guaranteeing that only the necessary data is exchanged with healthcare organizations this approach not only enhances data security but also minimizes unnecessary data transfer summarized a client may link 1 to 1 to an application provider's application, as shown in the above diagram for application 1 represented by client 1 however, a founda health platform client may also be used to represent a group of applications from the same application provider see client 2 in the above diagram how a client represents an application provider's application(s) is up to the application provider to decide test and production clients a client can be either of type "test" or of type "production" when a test client is created, access to a sandbox provider organization will automatically be granted this requires no further approval from a provider organization when a production client is created, the request for this client defines the (fhir) scopes that the application provider requires a production client must always be authorized by a provider organization, accepting the requested (fhir) scopes, before the application is allowed to interact with that healthcare provider client authorization before any application provider's client can access any data at the healthcare provider, the client has to be authorized only after a provider organization has explicitly approved an authorization request the client can access the requested data objects and use the action scopes it defined client interactions after the client is authorized by the provider organization, the application can interact with founda's healthapi in order to interact with the healthapi, the authorized client has to receive an access token from the identity and access management service how to receive an access token? check out the oauth2 0 tutorial!