We all have been there. We have all been at work and thought of an app idea that could improve a clinical outcome or make the work run smoother. So how do you go about it? The problem is that if you ask any clinician, chances are that they will have some form of app idea that they could run with. The problem is executing it. I kinda feel a bit like a broken record saying this but I’ve decided to type this up on my blog because I still get clinicians contacting me with this arrangement. It usually goes like this:
“I have an idea for an app for situation X. I cannot code but with your coding skills and my clinical knowledge of the idea we can make this work.”
The problem is that the idea is most probably the easiest part and they have underestimated the scale of the operation. If you’ve never coded an online platform to store and share data let me tell you, it presents loads of unique problems for each situation, constant improvement, debugging, updating and maintenance. Just being an ideas guy means that you are not going to contribute to most of the work or problems. Not to mention being an ideas guy is very easy. If you haven’t read this already check out my post about my friend who was hiring for an NHS position and half the applicants put down that they were “involved” in developing an app[link]. People state that having clinical experience gives them an edge. I completely agree it’s an edge, not a substitute. Stating it was a substitute would be greatly undervaluing the skill and technical ability to solve problems with code and hardware. However, it doesn’t mean that because you can’t code you’re not useful. Here are some areas that you can read up on in order to become a highly valued member of the team:
If you have an app that’s going to share information with other apps and communicate, you need a way of distributing data. Usually, this is done in the form of a server. This will typically store data in a database, and your apps will send and receive data from it. You can hire a server but if you want more control you will have to lay down some serious money, know a lot about hardware, and maintain security. Even if you hire a server you will still have to code the data structures and build a backend platform that will package the data and serve it to the front end web page, or to the app via an API REST framework. This can be done in a range of languages but usually python, PHP, ruby in a framework like Django, Flask, Rails etc. This means that the developer will have to be competent in the language, and then the framework for that language for the server. They will constantly be updating the backend, making it faster, managing data processing and requests and more. For more information on servers click here [link]. Getting a good deal on a server whilst satisfying the project needs is a good win. Whilst coders are working on technical problems continue trying to get the best deal you can and look around. If you find a better deal then you can go back to the back end developer and talk about the possibilities of switching.
This is usually an SQL type of database. Some will let you make multiple requests at the same time others won’t. There are a few different SQL databases out there. Once your data is on one changing to another can be a hassle. Here you have to consider a backup policy. You can do this by exporting the data into a CSV or even Excel file (considering it’s not too big). Developers usually get caught up in their own problems and general management goes out of the window. As a result, a bad update can lose data or corrupt it. A very smart talented developer can lose sight of the bigger picture whilst they are pulling their hair out over a particular problem or algorithm. Developing written documents for developers to adhere to will not only reduce the risk of this happening but also show to other organizations that you’re professional and that they can trust you with their data. Spending money of some good quality hard drives is worth it. For more general information on databases click here [link].
If it’s a smartphone app you will have to package the data from the server into an API. This reduces the data sent and received as the app already has the user interface compiled and saved on the phone. This is why apps load faster than web pages. This reduces server load. Apart from being a technical hurdle which creates loads of technical solutions, in the long run, API is also a business option. If you strike a deal with another computer system and they give you their API you can pull data from their system and use it for your app. If you have lots of good quality data on your server database you can consider renting out your API to other developers. This is all down to your individual business model. For instance, if your business was advertising doctors’ private practice your value would go up if you gave your API to other developers as you could say to the doctors that their profiles for private practice are going to be displayed across multiple platforms. Having a non-technical understanding of API can help you bridge business partnerships and excel your project. For an introduction on API click here [link]. For more information click here [link].
Now you have the main data structures sorted you have to make the front end usable and nice for users. This is an art in itself. Visual design and usability are key. This is usually coded in HTML with CSS rendering and bringing to life animations. If you can’t code but you don’t want to sit around twiddling your thumbs when the product is in early stages of development I recommend learning HTML and CSS. My partner for myGPevents Shubz is a GP and he had no coding experience when we first met. He learned HTML and took a ton of weight off my shoulders developing the front end. Some people say it’s not proper coding but you are increasing your value in the team and when it gets advanced there’s loads of nuances and intricate problems to solve. It makes or breaks the product, and if you become skilled, you can become an invaluable part of the product development. For a free intro course in HTML click here [link].
IOS and Android
If it’s a smartphone app the problem here is developing for different platforms. IOS will require the app to be coded in swift or objective-C. They have their own frameworks because they are different operating systems. It really depends on what you plan to do. For early trials, I would recommend not bothering with compiled smartphone apps and just stick to web based apps. For more about this click here [link]. However, if you’re planning on using the hardware of the phone then you will have to start early with developing compiled smartphone apps. Most of the time having compiled smartphone apps is usually a good idea when the app is growing and shows promise.