What's New

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

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

The process – user stories

In lesson one we discussed the process for getting your idea on paper and trying to describe the problem your solution solves.  With Lesson 2 we move on to the process of building user stories that describe how individuals will use the product.

The key starting point for what you are about to build doesn’t necessarily start with you.  It starts with your end users.  It is the what and the how of using the product.  

In lesson one we discussed the requirement to think about the “need”  and what problem the app solves. You now need to think about the people it solves this for and how they will interact with it.

Start by creating profiles of the different users who will use the app. What is their job, what will they use the app for, how will they use the app, what specific problem or pain point will the app solve for them.  It may be useful to send out surveys at this point or to bring your users together to form a user group to help brainstorm ideas.  If you already have a prototype, have they used it, do they have any feedback.  What do they think of your idea and the way it will work for them. 

It’s a great way to get the information that will be useful later when writing your spec as you can envisage the individuals using the product and what they will be trying to get done with each function.  It may also allow you to prioritise features that need to be included on your MVP and which features could go on the backlog.

Write all these user profiles and user stories down.  This is what will give you the key outline to what you’re trying to achieve.  Think big picture at this point.  We’re still on the “what’ not the ‘how’ at this stage.

Here’s an example of some of the user stories we collected for CEMBooks V2

Junior doctor – “my patient has a PE that needs thrombolysing – how do I do that, who do I need to tell and where do I need to refer them, there’s bits of information all over the place, is this laminate in date?”

Nurse in charge – “I’m down 2 nurses, on a background of a heavy hour of attendances. How serious is that at this time of day / night, how do I record this, do I need to let someone know, who, and how do I contact them, and what should I expect them to do?”

Consultant: “I remember a discussion about a patient like this in an email trail a few months ago with a pan specialty agreement, where is that?”

To explore the first user story in more detail we need;

Resources; – a repository of guidelines with “How to treat PE” that is easy to find and quickly give advice, as opposed to a regional A-Z of PE. This should be up to date and have a clear author/reference.  We should be able to point to advice about where and how to refer the patient to and this should be easily searchable.

Phone book – should provide the phone and contact information for all of the teams referred to in the guideline.  You should be able to call or message these directly from your phone through the product.

This outlines a specific use case for our App.  Yours will have similar – start to write them down and work them through to this level.

Once completed, start to go through these and prioritise them 

1/ core functions

2/ nice to have

3/ if money was no object…

At this point it’s worth considering what other systems are out there and do any of these do those individual use cases really well – it’s worth knowing what is out there and how you will create a differentiation between your product and the competition but also if something is being done well, there’s no point reinventing the wheel 

This brings you to a point where you should have a list of key functions that your product will perform. 

The next stage will be to describe in much more detail the ‘how’ underlying each function.  How will it work, what steps are involved in the workflow for each function and where each function will take the user.

And that is the point we’ll leave it at today. Head back in two weeks, where we consider building a functional specification from your user stories.

As usual we welcome any comments about these tutorials – more info, more examples, too long, too short, too boring whatever you have to say please drop a comment in the section below or on our Twitter feed and we’ll get back to you.

Thanks

SN

So, you want to build an App. To solve a problem, to make your life easier or to perhaps make some money. How hard can it be? But what are the first steps to take, what do I need, what software do I need and how do I go about it??

To start with, as always, a disclaimer.  There is always more than one way to get something done.  The same is true with web and app design.  I don’t intend to give you the definitive way, or the only way, simply a way. The CEMBooks way that we used when we decided that we needed to build on CEMBooks V1 to produce CEMBooks V2.

At the time I was new to the company and as such hadn’t been involved with the development of V1, my colleagues who’d built V1 had some idea but the make up of the company had changed and the scale of what we now wanted to build was different.  The key processes remained the same however.

Before you begin, you need to be pragmatic.  Do you have all the skills yourself to complete the project or are you going to need help. You maybe able to develop the use cases but can’t go any further at which point you need a team to build your product and turn it into reality.  In which case you need funding and it’s important you think about that at an early stage.  Do you plan on self funding it? if yes, that’s fine, you only have to answer to yourself in terms of project costs.  If not, how do you propose to fund it? Research grants and funding, bank loans, innovation awards? Can you design and code your way to a functioning prototype or are you going to be applying for funding based on an idea??

As much as your idea might be the best idea ever and you may hear that having the idea gets you 90% of the way there, in reality you won’t get anywhere without the practical skills or funding to make your idea a reality.

Therefore the key starting point is to explain your idea. Tell stories. Develop the dream. Explain how your idea will make a difference and who it makes a difference to.

Explain the why behind your idea – usually it will be to solve a problem so….

1/ describe the problem 

2/ describe the scale of the problem (your market)

3/ what is the current process 

4/ why does that create a problem

5/ What is the impact of that problem

6/ who does it affect – (your user group)

7/ do they see it as a problem in the same way you do

8/ do they suggest any other ideas to use alongside yours

What is out there already as a solution? Describe the pros and cons of the current situation and solution.  If this is a new market you may need to convince others that the problem you can see is one that affects them too. Are there solutions available that partially solve the solution. Can you work with that supplier to make it better rather than starting from scratch?

Start writing – however you want to progress your idea one of the key steps is to begin to commit it to paper.  It starts to become real, it becomes something that can be discussed, reviewed and improved and it will become the backbone of your project proposal. 

At that point your need to ask yourself some more questions:

Can you code

Can you draw and design

Do you know about User interface design (UX)

Do you know about the differences between App’s and reactive mobile web design

If you do, then that’s brilliant you can start building as your time allows.  If not then you should consider how your proposal will allow you to pitch your idea to obtain funding to find a team who can build your idea. Remember though that it’s your idea and you want to retain any Intellectual Property that may be available.  At this point you may not know how much your project will cost – we’ll come to this when we build the product spec in a later lesson – but it’s the right time to think about where your funding will come from and what is available so this may limit your spec in just how adventurous you can be.

So hopefully there is plenty to be getting started with there. I would emphasise the importance of getting started and committing something to paper.  In the same way as this blog it’s’ the first steps on a new adventure.

See you again in 2 weeks.