gekaskr - Fotolia
I used to be a mobile healthcare app developer. That was nearly 20 years ago, before software for mobile devices were known as apps. In reality, the computer hardware we were building software for was barely mobile by today's standards, and not really that rugged. A good bump could knock the device's hard disk drive (yes, there was a hard disk drive in the tablet) out of commission, crack the black and white video graphics array resolution screen, or otherwise leave you with a $5,000 paperweight.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
At the time, I was working on my Master of Science degree (studying epidemiology and informatics), and my thesis project was to develop an electronic medical record for use by paramedics and emergency medical technicians in ambulances. Looking back, developing mobile software for emergency medical services (EMS) was a tall order, especially given the mobile hardware available and the tools we used to develop the software. However, there wasn't much like it on the market, there was a demand for such a system, and the project generated a lot of interest due to its novelty at the time.
Mobile devices and software development
Our mobile device of choice in 1996 was a tablet that weighed in at a hefty 3.5 pounds; its overall dimensions were not unlike today's devices (7.3 inches by 11 inches) although at 1.5 inches thick, it would take quite a stack of today's ultra-thin devices to match that. The chip was an AMD Am486 DX4 running at 100 MHz, and Windows 95 was the operating system. Of course, there were scarcely more than a handful of mobile devices at the time from which to choose, and the tablet performed very well for its intended purpose.
For developing the software, I selected Visual Basic because at the time, it provided me with the best tool set for rapid prototyping. I could spend more time designing, building and testing. It would take less time mired in troubleshooting than a more complex code base used by other development platforms of the day. Since my goal was to build the software, deploy it to a local EMS, analyze the collected data and graduate, I traded complex code for expediency in getting the project completed.
During the software development phase, I spent the better part of nine months riding along with ambulance crews every day, testing every aspect of the software, and going home each night to work on revisions for the next day. The EMS crews, professional as they were, were not really impressed with being test subjects. Every day that the tablet we used was not "accidently" run over by an ambulance was a victory. Eventually most of the team came around in support of the project. I am convinced this is because I worked closely with the crews, listened to their feedback and accommodated their ideas the best I could.
I completed the software, got the data I needed, wrote and defended my thesis and then graduated. The university even saw fit to commercialize the software, which was a fairly novel process back then and perhaps the topic of a future article.
Being a software developer in the early days of tablet computers -- before mobile technology attained the ubiquity of today -- taught me several very important points about mobile healthcare app development that still are relevant today:
Know what the users want. Like every software development project, building for mobile use should begin with a solid understanding of the project requirements and a clear articulation of the business or clinical problem(s) that can best be addressed by a mobile app. For example, is the app needed for supplemental data collection (for quality improvement projects), clinical charting or information delivery (as required for evidence-based medicine)? By understanding the requirements, developers will have a better chance of including all the necessary functions and information that will make the app a useful asset.
Integrate into workflows. The very nature of mobile applications means they will be used when users are on the move. The need for quick access and entry of information is high, and convenience is critical. All apps that are intended to be used in the course of a clinical or business workflow must ensure that the application design accommodates that workflow, and not the other way around. Process and workflow considerations can mean the difference between successful development or another add to the slag-pile of apps that didn't meet expectations.
Keep usability a top priority. App design must strike a balance between both function and form. An app may provide all necessary functionality, but if it looks and feels like a desktop application, it will not fly with users. A successful app will take advantage of features that users expect in mobile devices and will make it so all data access and entry is efficient and intuitive. If my kids can find their favorite shows on my tablet's movie app faster than I can, users of healthcare apps will demand access to what they need just as quickly.
Test and validate to ensure quality. An app may have all the desired features and functions, but if it does not work reliably, it won't be used. Rigorous quality assurance testing helps ensure that the interface is suitable for where and how it will be used, that the app doesn't inexplicably and/or frequently crash, and most importantly, that the app is easy to use and acceptable in every way to the end users. A slick looking app may attract attention, but much of that will be negative if the app isn't fully tested, validated and optimized before its release.
Ensure security and privacy. Back when I was developing the EMS software, one of the main concerns was what would happen if the device is lost or stolen. This meant we needed to ensure that patients' private health information remained secure during such an event. In these cases, security and privacy must trump convenience, especially in today's connected devices that may present a major network security risk and potential regulatory enforcement should they be compromised.
Practice continuous improvement. There is an old computer programming joke: "The nice thing about developing software is never having to say you're done." Today, this statement is less a witticism and more a statement of necessity. Once an organization or development company has committed to building and supporting a healthcare app, that commitment is long term. There is a need to keep up to date with changing workflows, data requirements, user feedback/comments/suggestions, and security risks. For all these reasons, apps become stale -- perhaps even dangerous -- very quickly, which is not acceptable in a healthcare environment.
Although the hardware and software of mobile apps has changed dramatically over the last twenty years, the promise of mobile devices has not. Mobile devices and apps have potential to integrate seamlessly into businesses and clinical processes, provide information and allow for data capture anywhere and anytime. It is up to the developers of these apps to build well-designed, well-integrated and easy-to-use apps that meet the needs of people and the enterprises in which they work.
About the author:
Trevor Strome, M.S., PMP, leads the development of informatics and analytics tools that enable evidence-informed decision-making by clinicians and healthcare leaders. His experience spans public, private and startup-phase organizations. A popular speaker, author and blogger, Strome is the founder of HealthcareAnalytics.info, and his book, Healthcare Analytics for Quality and Performance Improvement, was recently published by John Wiley & Sons Inc.
Proper promotion can make or break an application
How gaming apps are used to educate patients
Learn how healthcare apps are organized by medical device classes