Designing by numbers? What have we learned from #WeAreNotWaiting about using APS systems?

Designing by numbers. Can #WeAreNotWaiting influence commercial APS systems?
Designing by numbers. Can #WeAreNotWaiting influence commercial APS systems?

What becomes very apparent when spending time in the #WeAreNotWaiting community is that commercial systems sometimes lack the imagination to understand what it is that users hold dear, and more importantly, in a fair few cases, who the users are.  

As with every medical device that is used by a real, human, person in conjunction with the condition that they have, having the care of the patient at the heart of the system is enormously important. Doing that is often far more complex than many realise.  

Taking a look at closed loops, and immersing yourself in the DIY community for a while, you find that there are multiple different cases for using the systems and more importantly, multiple roles involved.

It’s not simply “Give a black box to someone and leave it to manage how they are doing” as, with the best will in the world, neither the sensing technology, nor the insulin, is up to that just yet. While the machines are rising, they still require human involvement when things aren’t quite going to plan. This is where we start to see the usage requirements appearing. If we look at the basics of using a hybrid closed loop, basing everything off the DIY community, there appear to be four roles:  

  • PWD as user
  • Local caregiver
  • Remote caregiver
  • Advisor

Within each of these is a matrix of when and how loops are used, and these drive the characteristics of functionality that may be needed, for example, lack of internet access and regressive data analysis. All of these items drive much of the functionality that we see in both the DIY community and the commercial reality of some of these systems.

Let’s start with the roles I described earlier, starting with the simplest:  

PWD as user  

This is a person with diabetes managing their own condition with the use of a loop. They need the system attached to them delivering insulin, are the source of the glucose data and are able to provide any inputs needed to advise the system of what they are attempting to do or changes in their environment/activity.  

Ultimately, these latter interactions will be manageable by various sensors, but as it stands at the moment, the data probably isn’t reliable enough to handle managing insulin without careful design of algorithms to manage the significant amount of noise in the system.

Local Caregiver  

This is someone who is in the vicinity of the person with diabetes, generally looking after them and giving them assistance. It could be a parent, teacher, school assistant, family member or nurse, and they will have access to whatever interface is available in order to act in place of the PWD. The level of skill or knowledge they have will depend on the training they have received (and requested).

They are likely to be looking at the data generated by the PWD and observing what they are doing, in order to assist in managing either their diabetes or devices. It’s likely that the drug delivery system will be locally remote from the caregiver.  

Remote Caregiver  

A remote caregiver may not be local to a PWD. They are similar to a local caregiver, except  they need to be able to remotely see what is administered to the pwd, the effects on the pwd and if any intervention is needed, then act on that data and information.  

Advisor  

The advisor is unlikely to be providing care to a PWD. They are generally considered to be a trusted counterparty that can be called upon to provide feedback or who may be asked for advice when the PWD needs a second opinion. They need access to data and tools but are unlikely to by making any interventions in the day to day care of the PWD.  

Each of these roles has a number of consistent requirements and a number that differ. Functionality that is available for the “PWD as Doer” isn’t of much use by the remote caregiver, for example, if they needed to intervene.  

This is where the tools created by those in the WeAreNotWaiting community differ from many commercial offerings.  

For example, integration with NightScout allows a remote caregiver to adjust or schedule various targets of an APS system to better manage care (as long as there is an internet connection). With one of the systems it is possible to allow insulin to be administered using an SMS message. There’s also the opportunity for those who are local to a person to administer either a bolus or enter targets to manipulate insulin delivery without interacting with the person themselves.  

If you are a remote (or local) caregiver and you are using the only commercial APS system, it doesn’t matter whether you want to see what the system is doing without going to it and directly interacting with a two inch screen. The commercial offering simply doesn’t include these capabilities. Fortunately, WeAreNotWaiting hasn’t and provides tools to do view the data, but you still need to go to the device to interact with it and the PWD. Whether the company that has built this device has thought it important is a question I can’t answer, but for many parents, it is.  

Finally, using the data you’ve created as a result of your looping activity can be incredibly useful and we encourage sharing your data with the Open Humans programme to allow research based on real world use of the DIY systems. These tools can be used by individuals and allow easy review of the data to better understand what your system is doing, how it interacts with you and if there’s anything you or it could do better (e.g. better use of temporary targets and timing of insulin).  

Of course, commercial companies want access to this data as well, and by locking access in to a proprietary web app, access can be restricted and monetized, as well as used to further develop product. Whilst this product may assist with T1D management, such as feeding real time glucose, IOB, Carb and activity data to a machine in the cloud that will predict your next low (incidentally, tools that people are also working on in the DIY community), data access to look at any of this yourself is done via a clunky, awkward interface. Whether that’s oversight or more deliberate is anyone’s guess.  

As the sensors get better and insulin action times reduce, the need for interaction will also reduce, but for the foreseeable future, the tools we have to manage T1D result in different people with different roles doing different things. Making it easier for all people that have roles in caring for PWD, not just the PWD themselves would make life easier for a lot of people. That’s why the JDRF is now talking about their Open Protocol initiative and grant system and trying to broaden their reach with the community.  

What we’re highlighting here is that the many thousands of hours that have gone into the development of tools by the community for the community have come from a background of need, and what’s been considered “oversight” by the larger commercial enterprises that have been involved in diabetes care. The growth of digital technology is rapidly enhancing the number of smaller, more agile operations that get involved, but one thing must always remain.

Without the PWD and their carers being at the heart of any system, it will only frustrate, both the user and those who try to impose such a platform on that user.

Be the first to comment

Leave a Reply

Your email address will not be published.


*