Our platform enables organisations to rapidly respond to evolving clinical practice, ensures appropriate governance oversight, with instant distribution to staff at the patient bedside.
This overview has been created to assure potential customers that the systems and data hosted by Clinibee are designed and managed to the highest standards, underpinned by the best technical and procedural security controls
Our platform has been built from the ground up with security and the protection of your data in mind. We have designed each component of our platform using industry standard best practice, with a cloud hosting provider dedicated to protecting your assets.
Hosting
Microsoft Azure, ISO 27001 certified
Location
Data hosted in UK
Personal Data
Not transferred or processed outside of EEA. GDPR compliant
Data Protection
ICO Registered. NHS Data Protection Toolkit standards met
Encryption
256-bit SSL for all data, transfers and communications
Physical Security
Extensive layers of physical protection for all digital assets
Disaster Recovery
2x UK Data Centres with instant failover
Backups
Point in time - 50x per day for 28 days. Long term retention - weekly backups maintained for 10 years
Audits
Real-time auditing of hosting assets
Remote Access
Protected by firewall controls
Privacy Policy
Available here
Terms of Service
Available here
Clinibee is hosted on Microsoft Azure, in 2 data centres within the UK. Microsoft designs, builds, and operates data centres in a way that strictly controls physical access to the areas where our data is stored.
Microsoft understands the importance of protecting our data, and is committed to helping secure the data centres that contain it. They have an entire division devoted to designing, building, and operating the physical facilities supporting Azure. This team is invested in maintaining state-of-the-art physical security.
Microsoft takes a layered approach to physical security, to reduce the risk of unauthorised users gaining physical access to data and the data centre resources. Data centres managed by Microsoft have extensive layers of protection: access approval at the facility’s perimeter, at the building’s perimeter, inside the building, and on the datacentre floor. Layers of physical security are:
Access request and approval. People must request access prior to arriving at the data centre. They’re required to provide a valid business justification for their visit, such as compliance or auditing purposes. All requests are approved on a need-to-access basis by Microsoft employees. A need-to-access basis helps keep the number of individuals needed to complete a task in the data centres to the bare minimum. After Microsoft grants permission, an individual only has access to the discrete area of the data centre required, based on the approved business justification. Permissions are limited to a certain period of time, and then expire.
Facility’s perimeter. When people arrive at a data centre, they're required to go through a well-defined access point. Typically, tall fences made of steel and concrete encompass every inch of the perimeter. There are cameras around the data centres, with a security team monitoring their videos at all times.
Building entrance. The data centre entrance is staffed with professional security officers who have undergone rigorous training and background checks. These security officers also routinely patrol the data centre, and monitor the videos of cameras inside the data centre at all times.
Inside the building. After a person enters the building, they must pass two-factor authentication with biometrics to continue moving through the data centre. If their identity is validated, they can enter only the portion of the data centre that they have approved access to. They can stay there only for the duration of the time approved.
Data centre floor. A person is only allowed onto the floor that they're approved to enter. They are required to pass a full body metal detection screening. To reduce the risk of unauthorized data entering or leaving the data centre without our knowledge, only approved devices can make their way into the data centre floor. Additionally, video cameras monitor the front and back of every server rack. When they exit the data centre floor, they again must pass through full body metal detection screening. To leave the data centre, they're required to pass through an additional security scan. Microsoft requires visitors to surrender badges upon departure from any Microsoft facility.
Periodically, they conduct physical security reviews of the facilities, to ensure the data centres properly address Azure security requirements. The data centre hosting provider personnel do not provide Azure service management. Personnel can't sign in to Azure systems and don't have physical access to the Azure collocation room and cages.
Only named Clinibee individuals have access to process data on the Clinibee production platform. Any additional named individuals would require appropriate data protection training.
Only Clinibee-named individuals are allowed access to the information asset. All external parties access the information asset via the Clinibee user interface, where there are account-based user management tools. All remote access to Clinibee servers is protected by our firewall controls. We also only allow named individuals to perform this duty. A register of people is maintained and available on request.
Clinibee maintains a strong digital wall and gatehouse to surround and protect its critical data assets. The cornerstone of this defensive approach is the firewall and associated security devices. All communication with our key data stores must pass through our firewall protections, including communication between application and database servers.
All this communication is conducted using 256-bit SSL encryption. We have full visibility and control over what traffic goes where within the platform. Our security approach is regularly internally audited and we will be considering external audits as the service expands.
Clinibee has native apps for both iOS and Android. The apps are designed for use by customer staff. All data, transfers and communications with the platform are performed using 256 bit SSL encryption. The mobile apps are designed for the consumption and reading of content on the Clinibee platform.
No changes can be made to application data via the mobile apps. Users are able to download and install these apps (at no cost) on their mobile devices. Security related information is not stored on the device. No files are stored by the apps. There is a secure user cache stored temporarily on the device to enable convenient access to the platform. All non-essential information is retrieved from the platform when needed. No passwords are stored on the device.
Lastly, users must agree to our Privacy Policy and Terms of Service before using any part of the Clinibee platform, including the native mobile apps.
Clinibee has 3 levels of audit built into the system
Server audit. All activity on our servers is monitored in real time with an audit trail maintained.
Application audit. All content created, edited or deleted is audited within the application and stored within our application database. This is surfaced to users via the user interface (where necessary). When content is modified we keep a full version history of the changes and maintain these within our application database. We also keep a record of all searches and reads users perform and maintain a log of this.
User activity audit. Every user interaction with the application is audited and kept in a separate user activity audit trail. The audit tracks this activity across web, iOS and Android apps and consolidates it into one audit.
Only named Clinibee employees are permitted to access our system from the backend. All other access is via the web, iOS or Android user interfaces. Clinibee runs on the information security principle of “least privilege” (or “least authority”), which states that each user must only be able to access the information or resources necessary to their job.
Each account has a series of Libraries that users request access to. The Library administrators grant access to the follower. The access levels that can be allocated to an individual are hierarchical. The lowest access is Follower (can view published content only). The majority of users will be followers. Users can also be invited to be part of the publishing team for a library.
There is a hierarchy of access levels that determines what a user can/cannot do to the content within the library. Accounts also have Review Teams, that also have a team of users with varying access levels.
Our Business Continuity Plan (BCP) has been designed to prepare us to cope with the effects of an emergency. It will provide the basis for a relatively quick and painless return to “business as usual” regardless of the cause. The plan is designed to enable us to:
Respond to a disruptive incident
Maintain delivery of critical services during an incident
Return to business as usual following an incident
The services we have identified as most important for our business to continue to operate are available on request The list maybe used as a checklist to ensure that critical tasks are completed on time. All timeframes are based on the avoidance of lasting damage to our customers. Responsibility for each critical function within this plan rests with Clinibee staff.
Service-interrupting events can happen at any time. Clinibee makes sure that if catastrophe hits, the impact on our customers is minimal.
We target an uptime of 99% availability and have the infrastructure in place to ensure that is met. For redundancy we have setup primary and disaster recovery data centres 200km apart. Both are in the UK. For failover, we have primary and secondary data centres with real time data synchronisation for instant failover. To ensure we are able to fully restore Clinibee we have a robust backup routine.
Our Business Impact Analysis (BIA) has set Clinibee to be a Mission Critical application for our customers. We define mission critical as:
“There will be significant, but not existential, harm to employee productivity, organizational reputation, and potentially revenue if these second-tier systems or data are unavailable or compromised.”
We have determined that Clinibee is set up with a disaster recovery pattern (DR Pattern) of Warm.
This means that under most DR scenarios, the system can continue as normal (e.g. outage at one data centre). However, there are some disaster recovery scenarios where the system will require some downtime to enable a recovery to take place.
RTO (Recovery Time Objective). Access to content on the platform is mission-critical and needed by staff on a daily basis. We have set this to 4 hours.
RPO (Recovery Point Objective). Content on the platform is not updated at the frequency of other systems like an electronic health record. Therefore the RPO can be set accordingly. We have set this to 12 hours.
Clinibee is a platform designed as a series of distinct components, all hosted in a single secure environment.
Our design principles are to design for security, interoperability and simplicity of use.
Our platform enables organisations to rapidly respond to evolving clinical practice, ensures appropriate governance oversight, with instant distribution to staff at the patient bedside.
All the component parts of the Clinibee platform, except our native apps, are securely hosted on Microsoft Azure. Our iOS app is available from the Apple AppStore, with the Android app available from the Google PlayStore.The core components that make up the Clinibee platform are based on Microsoft technologies.
We use SQL server & Blob storage for our data, C# .NET Core 3.1 for our core API application server, and a Content Delivery Network for our web application.All this is underpinned by 256-bit SSL encryption for all data, transfers and communications. This applies both over the web and between components within the hosting environment.Below is a diagram explaining the components that make up our platform.
.png)
We host our application and user data in two data centres in the UK. Our primary data centre is located in the south of the UK. This is replicated, in real time, with our secondary data centre located in the west of the UK. This gives us both data redundancy and disaster recovery failover.
The application and user data is backed up 50x times a day for 28 days. This gives us point in time restoration (PITR) capability. We also perform weekly backups, which are stored for 10 years for long term retention (LTR).All communication and data transfers between these two data centres is 256-bit encrypted.
At the core of our technology stack is a Restful C# .NET Core 3.1 API. Platform access to both application and user data is controlled via this API. In fact our web, iOS and Android apps all use the same API methods to send and receive data from the platform.
The API consists of a set of data models, repository layer (for data access), service layer (for business logic), view models and a set of secured HTTPS controller methods. All communication with the API performed using JSON objects. We have designed the architecture of the API in this way to ensure a clear separation of concerns. This will enable us to scale the platform over time, whilst maintaining clarity over the code base and the ability to test individual components easily.
The Restful API is fully documented and ready for secure integration with your enterprise systems. Documentation available on request.Again, all communication and data transfers with the API are done using 256-bit encryption.
Our web application is designed using an Angular Single Page Application (SPA). This allows us to utilise modern web application design principles, whilst maintaining accessibility for older browsers. The web application utilises the Clinibee API for authentication and subsequent access to application data.
This is done using encrypted HTTPS Requests and Responses containing JSON payloads to interact with the platform. Each time a request is made, it is authenticated and checked, before a response is returned. All changes in security access are reflected immediately.
Our iOS application is designed using a Flutter generated native application. Flutter is a framework that allows iOS & Android apps to share the majority of their code base. This allows us to ensure a consistency of experience across both iOS & Android apps and reduce the time it takes to develop for both platforms.Users download the iOS app from the Apple AppStore, free of charge.The iOS application utilises the Clinibee API for authentication and subsequent access to application data. This is done using encrypted HTTPS Requests and Responses containing JSON payloads to interact with the platform. Each time a request is made, it is authenticated and checked, before a response is returned. All changes in security access are reflected immediately.
Our Android application is designed using a Flutter generated native application. Flutter is a framework that allows iOS & Android apps to share the majority of their code base. This allows us to ensure a consistency of experience across both iOS & Android apps and reduce the time it takes to develop for both platforms.
Users download the Android app from the Google PlayStore, free of charge.The Android application utilises the Clinibee API for authentication and subsequent access to application data.
This is done using encrypted HTTPS Requests and Responses containing JSON payloads to interact with the platform. Each time a request is made, it is authenticated and checked, before a response is returned. All changes in security access are reflected immediately.
Book a demonstration with us at time that suits you
Book a Demo
