Practicalities
Wow, 2 weeks rolls round quickly! Welcome back to our “how to build a healthcare IT solution”. In this week’s tutorial we are going to discuss some of the practicalities to think about when building your solution.
How will it be used – environment and compatibility
This should come from your user stories. How will your users engage with your product – native app? mobile web? desktop web? Do you require push notifications as a function? Do you want an offline mode? If yes to these two questions then you will probably have to build a native app to go through the Apple App Store or Google Play store. If you don’t need push notifications but just want excellent accessibility on your mobile device then current reactive web builds will allow you to do this within mobile web browsers. You get the appearance of an app both in terms of product functionality and also on your device Home Screen but without having to go through the additional process of building an actual App. Take a look at these two screen shots from CEMBooks V2. On the top is the picture from the mobile web app, on the bottom is the view from the native app. Clearly very similar and with the similar functionality.
Building apps in the 2 different environments of Android and iOS also requires an additional time and cost. The two environments have different detailing, iconography and text, so although similar it’s not an identical replication. You will need developer accounts for both systems and devices to test both systems on.
In terms of desktop the biggest issue around compatibility (at least in the NHS) is Windows Internet Explorer. This is still very much present within the NHS despite Microsoft withdrawing support and replacing it with Microsoft Edge. It is unlikely that a newly built web app will run on IE and nor should it with the associated security risks unsupported software exposes. This issue should be noted within your hazard log (see future blogs). Compatibility should be tested with the common browsers in use – Chrome, Safari, Edge. You should ensure you have access to all these systems for testing purposes.
Servers
It’s worth considering where your product will be hosted. There are a number of server providers, some bigger some smaller, with Microsoft Azure and AWS web probably the 2 biggest and most well recognised providers. It’s important for solutions which may be deployed into the NHS that the servers are UK based. You should check the up times guaranteed and how this is assured e.g. mirrored servers.
Depending on the data type and how much information you will be storing, will impact on the costs so this needs to be considered – are you looking for a fixed price package or one that will scale with expansion of use of your product. Have a look round at the various suppliers and discuss with your dev team if you are not building the product directly.
Security
Security will need to be considered and will probably be another blog in it’s own right. Practical points to consider at this stage for spec design around onboarding are: What password systems you use – password strength requirements etc, how many attempts before blocking, how information is transmitted between the app and the user – this should be encrypted. How are users invited into the system – domain specific user names, verification before granting access, invite only, open access, use of single sign on systems or a single identity login. Much of this will depend on the type of data that will be hosted in your system. It’s not just about differentiating between patient identifiable and non patient data, you need to consider what maybe commercially sensitive to the organisation or individuals. You should consider how you will comply with GDPR regulations regarding administrator access and personal user data. You should be clear as to who the data belongs to – who is the controller, and who is the processor. Again I will consider some of the issues around this in a separate blog.
You will also require an SSL certificate (this provides the padlock security symbol and https nomeclature you see on sites with secure logins) – again there are a number of providers but these often take time to buy and install as they need to confirm certain details about your business or organisation.
Email accounts and providers will be required if the site is going to communicate with users. For instance account activation or renewals or replies to enquiries. It’s often worthwhile ensuring that you have control over the no-reply@, admin@, enquiries@ for your specific domain name. Whichever service you use for your company email should allow you to register these, but you will require an actual service for your site such as www.sendinblue.com at a basic level to provide automated email functions. These can be free but may limit the number of emails that can be sent in a day. If you plan to onboard large numbers of users together this needs to be taken into consideration.
So loads to think about there! You don’t necessarily need complete answers to these questions, but you do need to write these questions down (note the theme throughout these blogs 😉 ) and work out what your approach might be and consider what impact on your budget might be especially for server costs and additional emails services and your SSL certificate.
All this will add to your product spec document which is what we’ll be looking at in the next blog.
As usual, please add any feedback or comments below or on the Twitter feed and let me know if there are any points that you’d like me to try and expand on or go into more detail in a future blog.
Thanks
SN