The digital transformation of public safety and emergency medical services is gaining momentum. But what should one pay attention to when designing IT systems?
Hi there - I'm back! Since nearly 6 months, I have not posted any new articles on Entanglement and I think I had a valid reason for it: I was really damn busy.
In those last few months, I have had the chance to launch and work on several exciting projects, which, in their core, all share one common goal: make use of technology to speed up and improve the delivery of medical services to patients. In this article, I will not go into any of the projects' specifics, but will do so in future posts. Stay tuned!
Digital Transformation in Public Safety
I guess that many IT professionals that are working in public safety or for emergency medical services would share my impression that we are in the middle of a digital transformation of the sector. This implies that the role of IT systems does not only increase in day-to-day operations, but even often influences key processes, such as dispatch protocols or deployment plans. Quite similar to the ongoing trend in the private sector, IT therefore increasingly plays a strategic role. My team(s) and I are, to use figurative language, right in the middle of this storm.
I strongly believe that a digital transformation of the sector will not only help the patients, but will also prove to make the life of the involved personnel easier. In my experience, however, there are several potential mistakes that one can make when designing IT systems for such highly-specific environments, which are all too often the result of good intentions.
In this article, I want to share the experiences that I have made, but want to do it the other way round. Instead of listing you potential pitfalls, I will outline 5 key principles that one should keep in mind when designing IT systems for public safety. Let's get started!
Principle #1: Design End-to-end
Even in public safety and emergency medical services agencies, we have silos. Obviously, silos may exist between different branches of public safety, such as the police forces or ambulance services. Potentially even worse, however, are organisational silos within the same value chain. The dispatch centre, for instance, may have requirements to a new system that do not match or, even worse, contradict the needs of the personnel "out in the field". If this discrepancy is not resolved by taking an end-to-end perspective, problems in operations may arise in the future.
Let me give you an example: mission control systems are often the domain of the dispatch centre. Typically,mission details are conveyed to field personnel in the case of an alarm or when certain mission parameters have changed. Whereas the way in which those details are recorded can be, for the most part, defined from an operator's perspective, one should pay close attention to which details are transferred to field personnel at which points in time. Failure to define and evaluate those requirements with the latter (take ambulance crews or first responders, for instance) may result in unnecessary or even misleading information to be passed on at, in the worst case, exactly the wrong time.
Exemplary depiction of an operations centre
How to do it better? When looking to build or procure a system, design or evaluate it end-to-end. This means that, when building your product backlog, try to first understand the use cases and processes that your system plays a role in. Then, identify the stakeholders impacted by those processes and define your requirements (Epics, User Stories, etc.) together with them. In my experience, all of the participants will be willing to strike comprises once they get to see the big picture.
Principle #2: Keep IT Simple
When building a system or any product in general, we very quickly move towards discussing special use cases and implement or adapt features to handle them. The resulting systems are often complex in nature and have decreased usability for features that are used much more frequently. The figure of speech "jack of all trades, but master of none" is probably quite fitting here. On top of that, well-intended automation and/or business logic frequently turns out to be a showstopper rather than being useful. Especially in public safety scenarios, flexibility at all times is crucial.
The approach to avoiding these pitfalls is two-fold:
First of all, when launching a new system, think of what its bare minimum feature set could be. Everything that goes beyond this might be of use, but you should first find out whether it really is. The best approach here is to release this bare feature set, a so-called minimum viable product, to your stakeholders. Then, based on feedback from operations, one should together with the users decide what meaningful next development steps might be.
When building any particular feature that includes business logic, make sure that you either "start off dumb" or, in case you need really need some logic, to go for an implementation that could be changed in a configurative manner during operations. Why? Operational procedures could and should change with new insights, and we would not want an IT system to be standing in the way here.
Care for an example for this principle? When organising personnel out in the field that needs to group at certain meeting points, things can quickly get complicated: if there is more than one meeting point in a mission, then how do we assign a person to a specific meeting point? And how should we do that on the small screen of a mobile device? One should, instead of going for a complicated solution, try to use a simple one first: why not use a free-text field to convey the information? In case this proves to be too "low-tech" in the field, one can, at all times, upgrade the solution to a more complex - but hopefully better suited - one.
Principle #3: Unambiguous and Transparent Mission State
Digitalisation and digital transformation has one key benefit: using IT systems to govern processes in public safety makes those processes transparent. This means that, for instance, an IT system could transparently show whether an alarm was delivered to every member within a team in the field and, if not, make this information visible to the other team members. This enhances situational awareness and allows for a faster reaction to changing conditions within a mission.
Transparency comes with a price though: when showing information, you need to make sure that it can be unambiguously interpreted and is the same for every stakeholder involved. Use symbols instead of speech or text, for instance, and make sure that your operations centre does not have different sources of information in their mission control system than the people out in the field.
The Android Team Awareness Kit is a good example of a cross-device IT system for situational awareness [1]
Principle #4: Consider Ergonomics
Do not be mistaken: a software project is rarely "just" a software project. Your software may be used by different stakeholders on varying devices. Adding to that, they might use your software on a smartphone in one context and on a tablet in another context. Of course, your users themselves have varying characteristics (such as role, age or gender) that you also need to take into consideration. As you can imagine, there are a plethora of options.
This is exactly the reason why you should always conduct field test as early as possible, since out in the field, things tend to usually be different than you have imagined. A software is never used in lab conditions, but needs to be evaluated in the precise environement that it will be later used in.
Let me give you an example: when sending alarms to smartphone devices, make sure that those alarms can overrule the mute button, especially the one on iPhone devices. Otherwise, in the worst case, you might need to use duct tape or glue :).
Principle #5: Measure to Improve
The last principle I mention here, but probably one of the most important: you need to be able to observe how your users interact with the system and how it performs in general, starting from day one.
This entails that, in your design, you already consider which metrics will be collected and, if required, even conceptualise user interaction accordingly. From a technical perspective, make sure that you can get easy access to that data, use it in descriptive statistics and even view it in real-time. Only like this, you can obtain the insights to improve your system over time and adapt to changing operating conditions.
Screenshot of in-flight cellular network measurements conducted using the "Network Cell Info" for an alarm application [2]
Wrap-up
When writing this article, some additional principles came to my mind, which I, however, eventually decided to omit, aiming to not overly complicate matters. Actually, to me, there is one key guiding principle of any digital transformation that especially applies to public safety applications: technology should follow humans' needs and make it easier to satisfy them, not the other way round. What do you think about that? Please comment below!
Image Sources
[1] FieldMapper, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons
[2] Image taken from the author's archive
Comments