Summary
ClinSpark has APIs which can be used by customers. Currently these are scoped for two use cases:
Integration with a customer recruitment website
Programmatic execution and retrieval of reports.
IQVIA can offer suggestions for how to use these APIs, however we cannot support or assist with implementation and ongoing support of customer-specific mechanisms that rely on them.
We expect customers to learn about and test all API invocations with the Swagger client embedded on this documentation site. Once you have successfully invoked the API with this client, you will find that it provides client bindings and command line invocation patterns that will work directly for integrations.
For support requests, we ask similarly that customers first explore and troubleshoot using the Swagger client and include results of testing when reaching out via service desk.
Authentication Schemes
Currently, all versions of ClinSpark support Basic HTTP Authentication via username and password.
ClinSpark versions 23.3 and greater also support Bearer HTTP Authentication. API tokens are generated and managed with ClinSpark user accounts for this purpose. Supporting use of these features are Role Actions that allow users to view and manage tokens.
In version 23.3 and greater, user accounts can be configured to use both Basic Auth and/or Tokens.
As customers upgrade to more recent versions of ClinSpark, they are encouraged to explore using the API Tokens and adopt use for API accounts accordingly. Support for Basic Authentication may be deprecated in a future release of ClinSpark, to be replaced with authentication schemes that meet stronger security standards and best practices.
Permissions
For most use cases, the specific API role action must be assigned to a user account in ClinSpark to use the API. These are typically accounts that facilitate workflows via ClinSpark web services. Integration applications that use specific ‘system’ accounts in ClinSpark must be configured with this role action. An example of how these API permissions apply to Recruitment website integrations can be reviewed in this article: https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3700817953/Recruitment+Website+Integration#Granting-the-Website-Integrators-Appropriate-Access
Other than the assigned role action and intended use, there are no unique properties of accounts used for API invocation. Customers are expected to manage all account credentials. We do strongly suggest customers follow security best practices by assigning highly complex passwords (up to 255 characters) to the accounts and rotating them regularly. More information about ClinSpark user account management can be viewed in this article: User Management
We discourage the practice of customers creating, sharing, and soliciting use of integration user accounts that contain API role actions outside of site organization teams.
Customers are encouraged to create and manage multiple API users if they decide to adhere to a stricter credential management practice. This is our recommendation, so customers can properly process leavers/joiners with their own service account credentials, instead of having a pool of team members using shared credentials for singular service accounts.
Overview
https://vimeo.com/821961555/b7e6fb5359?share=copy