We’ve been using the Freestyle Libre for just over a year now to help my daughter manage her Type-1 diabetes. I wanted to share a few thoughts about how well it’s been working for us. I had lots of questions at the start, so I wanted to help capture what we’ve learned in case its useful for anyone else.

I’m writing this as a parent, rather than as a person with experience of wearing a sensor or the emotional cost of dealing with diabetes. Do not take anything I write here as medical advice, this is just a summary of our experience with the sensors.

My daughter is now 13. It was her decision to trial the sensor and hers to continue its use.

Cost & Shipping

Firstly, the Libre is not currently available on the NHS. But I believe it’s under review. This means we’re paying for the sensor ourselves. We’re lucky enough to be able to afford that, but not everyone is able to do so.

To use the sensors you need a reader (£57.95) and then sensors. While the sensors are priced at £57.95 each this includes VAT. When completing an order, if you’re buying the sensor for yourself to help you manage your diabetes, or for a family member then you can fill in a disclaimer and the VAT is waived. For our last sensor order we paid £48.29 per sensor. Sensors last a maximum of 14 days (see below) so on average you will be paying around £24 a week.

Shipping is quick and you’ll pay around £5-6 for postage. We buy ours in packs of 5 as that covers around 10 weeks worth of usage and reduces postage costs.

When we first bought the sensors we bought a pack of 10. I wouldn’t advise this as the sensors do have a use-by date, so you can’t just stock up.

Lifetime

Once fitted a sensor lasts 14 days maximum. You can’t choose to wear it for longer: the reader will no longer collect data from a sensor 14 days after its been activated.

While we’ve had a full 14 days from many of the sensors, in some cases they may come off early. They’re pretty secure once fitted, and in the optimum location in the back of the upper arm they are generally out of the way. But we’ve also had a number that haven’t lasted that long. They can be knocked off. We’ve also had to put tape over some sensors that have started to come off the skin.

When travelling we generally take a spare as well as manual blood testing equipment. See below.

Fitting the sensor

Fitting the sensor is straight-forward. The arm is swabbed with an alcohol wipe to clean the skin, then the sensor is pushed into the arm using a single-use applicator that comes with each sensor. They can be fitted in a couple of minutes. After activation using the reader it takes an hour before the first readings are available.

The applicator makes a clunking sound as the sensor is injected into the skin. It’s a bit like using a hole punch. Martha occasionally has some pain and soreness but that passes quickly.

On one occasion I’ve had a sensor fail to attach properly. This was because I tried to apply the sensor too soon after using the alcohol wipe. I’d recommend letting the skin fully dry before application to ensure the sticky pad adheres properly.

You can shower and swim when wearing the sensor.

Travelling with the sensor

Travelling with diabetes isn’t easier. Airports aren’t generally welcoming to people carrying bags of needles and vials of liquid.

Our understanding is that the sensors won’t go through metal detectors, but might be OK for X-Rays. As a minimum you’ll need to inform security if you or a family member is wearing a sensor. As our daughter now also wears an insulin pump, on our last few flights we’ve ended up having to opt out of all scans. This involves some headaches as you might imagine, but staff in the UK and elsewhere have so far been very helpful.

There is probably better advice online. Our experience is relatively limited here.

Removing the sensor

The sensors are fairly easy to peel off and remove, although the glue takes some scrubbing off. There’s no needle in the device, just a hair-thin sensor. The applicators can go in the bin, but we put the sensors in our sharps bin.

Sometimes the skin under the sensor can be a bit inflamed, but we’ve not had any serious side effects or issues.

Taking readings

To collect readings from the sensor you just scan it with the Reader. It works through clothing, so very easy to do.

The sensor collects readings every 15 minutes automatically and stores up to 8 hours of readings. All of the stored readings are automatically downloaded to the Reader whenever you scan it.

If you have an NFC enabled phone then you can collect readings using the LibreLink app. There’s also a LinkUp app to share readings with family members.

How the sensor helps to manage diabetes

The sensor removes the need to do routine finger prick tests. Martha no longer has to take blood glucose readings before meals, we can just scan her sensor and then work out the necessary dose and any correction.

Now that she is also using an insulin pump its really just a matter of scanning and then entering the data into the pump. It will work out any necessary corrections. The combination of the sensor and the pump has made an incredible difference to the routines of managing diabetes. For the better.

However using the Libre doesn’t mean that you can give up finger pricks completely. The sensor has limited accuracy with blood glucose levels below 4 or above 14. Outside of those ranges you must still do a finger prick test to ensure that you have an accurate reading for treating hypo- or hyperglycemia.

Accuracy of the sensor

Our biggest challenge when starting to use the Libre was understanding its differences from routine finger prick tests. This made us very wary about its accuracy initially. I’ll try to explain why.

If you want a detailed review of the Libre’s accuracy, then you can read this scientific paper which summarises a controlled test of the Libre. It helps to demonstrate the accuracy and reliability of the sensors, but may be too detailed for some people.

When you perform a finger prick test you are directly measuring the amount of glucose in your blood. But the Libre isn’t testing your blood glucose. The Libre sensor is testing the fluid between the cells in your skin. That fluid is known as interstitial fluid.

Interstitial fluid, it’s nutrients and oxygen are replenished from your blood stream. This means that you’re only indirectly testing your blood glucose. It takes time for glucose to pass from your blood into the fluid. Roughly speaking a measurement from the sensor is around 5-10 minutes behind your actual blood glucose level. If you’re running low on the sensor, your blood glucose might be even lower. And vice versa.

This explains why you need to finger prick when you’re low or high: you need to be treating your actual levels. On a routine basis, this delay isn’t an issue. It’s only when you’re particularly low or high that you may need to be more vigilant. This also explains why you need to travel with a full set of equipment and not just replacement sensors.

While there are delays, the fact that the Libre is constantly recording means that whenever you scan you’re getting an updated graph of your glucose levels, not just a single reading. The Reader will show you the graph and also give you an ideal if you’re level, rising (or falling) slowly, or rising (or falling) rapidly. That makes a massive amount of difference.

When we started testing the Libre we were doing routine finger pricks as well. The end result was a bit like wearing several watches, each of which is showing a slightly different time. We felt like we wouldn’t be able to trust the sensor because it was so often at odds with the blood glucose readings. The fact that this was also happening at a time when Martha’s levels were particularly erratic didn’t help: with highly variable blood glucose levels, you can feel one step behind.

Once we committed to using the Libre as our means of routine testing, everything was fine. You just need to be aware of the differences. Martha’s HBA1C levels demonstrate that we’re able to efficiently manage her glucose levels.

One additional issue to be aware of is that it takes time for the sensors to bed in. A sensor won’t start reporting readings until after its been on the skin for an hour. But we, and others, have found that it can take some time after that before readings seems reliable. Some sensors seem to work fine straight away, others seem a bit variable.

We’ve not had an issue with a sensor never settling down, they’re normally fine after a few hours. But its often hard to tell: is it the sensor, or just a particularly variable set of glucose levels.

We’ve heard that some people using the Libre install a new sensor 24 hours before the previous one runs out, to allow time for it to settle in. We’ve not found it necessary to do that.

Conclusion

Type 1 diabetes is an incredibly difficult condition to live with. I have nothing but admiration for how well Martha is dealing with it. She is my hero.

The Libre has made a significant difference to her (and our) quality of life. Removing the need for routine use of needles greatly reduces the number of medical interventions we have to make every day. The ability to easily scan to get a reading of glucose levels makes it easier for Martha in all aspects of her daily life. It’s much less obtrusive than finger pricking.

As parents it’s easy for us to check on her levels when she’s sleeping. A quick scan is all it takes. An integrated sensor and pump might be even better, but the smaller size of the Libre sensors make it perfectly adequate for now.

I hope the Libre becomes more widely available on the NHS so that more people can benefit from it. I also hope this article has been useful. We’re very happy to answer any other questions. Leave a comment or drop me an email.

Over the course of my career I’ve done a variety of consulting projects as both an employee and freelancer. I’ve helped found and run a small consulting team. And, through my experience leading engineering teams, some experience of designing products and platforms. I’ve been involved in a few discussions, particularly over the last 12 months or so, around how to generate repeatable products off the back of consulting engagements.

I wanted to jot down a few thoughts here based on my own experience and a bit of background reading. I don’t claim to have any special insight or expertise, but the topic is one that I’ve encountered time and again. And as I’m trying to write things down more frequently, I thought I’d share my perspective in the hope that it may be useful to someone wrestling with the same issues.

Please comment if you disagree with anything. I’m learning too.

What are Products and Services?

Lets start with some definitions.

A service is a a bespoke offering that typically involves a high-level of expertise. In a consulting business you’re usually selling people or a team who have a particular set of skills that are useful to another organisation. While the expertise and skills being offered are common across projects, the delivery is usually highly bespoke and tailored for the needs of the specific client.

The outcomes of an engagement are also likely to be highly bespoke as you’re delivering to a custom specification. Custom software development, specially designed training packages, and research projects are all examples of services.

A product is a packaged solution to a known problem. A product will be designed to meet a particular need and will usually be designed for a specific audience. Products are often, but not always, software. I’m ignoring manufacturing here.

Products can typically be rapidly delivered as they can be installed or delivered via a well-defined process. While a product may be tailored for a specific client they’re usually very well-defined. Product customisation is usually a service in its own right. As is product support.

The Service-Product Spectrum

I think its useful to think about services and products being at opposite ends of a spectrum.

At the service end of the spectrum your offerings are:

• are highly manual, because you’re reliant on expert delivery
• are difficult to scale, because you need to find the people with the skills and expertise which are otherwise in short supply
• have low repeatability, because you’re inevitably dealing with bespoke engagements

At the product end of the spectrum your offerings are:

• highly automated, because you’re delivering a software product or following a well defined delivery process
• scalable, because you need fewer (or at least different) skills to deliver the product
• highly repeatable, because each engagement is well defined, has clear life-cycle, etc.

Products are a distillation of expertise and skills.

Actually, there’s arguably a stage before service. Lets call those “capabilities” to borrow a phrase. These are skills and expertise that you have within your team but which you’ve not yet sold. I think it’s a common mistake to draw up lists of capabilities, rather than services or products.

The best way to test whether your internal capabilities are useful to others is to speak to as many potential customers as possible. And one of the best ways to develop new products is to undertake a number of bespoke engagements with those customers to understand where the opportunities lie for creating a repeatable solution. Many start-ups use consulting engagements as discovery tools.

Why Productise?

There are many obvious reasons why you’d start to productise a service:

• to allow your business to scale. Consulting businesses can only scale with people, product businesses can scale to the web.
• to make your engagements more repeatable, so that you can deliver a consistent quality of output
• to distil learning and expertise in such a way as to support the training and development of junior staff, and grow the team
• to ensure business continuity, so you’re less reliant on individual consultants
• to reduce costs, by allowing more junior staff to contribute to some or all of an engagement. Check-lists, standard processes and internal review stages providing the appropriate quality controls
• to focus on a specific market. Tailoring your service to a specific sector can help target your sales and marketing effort
• to more easily measure impacts. Products solve problems and, when manifested as software, can be instrumented to collect metrics on usage and hopefully impacts.

Because they have a bounded scope, products are easier to optimise to maximise revenue or impacts. Or both.

A Product Check-list

By my definition above, a product will:

1. solve a specific well-defined problem
2. be targeted at a specific customer or audience
3. be deliverable via a well-documented process, which may be partially or completely automated
4. be deliverable within a well-defined time scale
5. be priced according to a tried and tested pricing model

If you can’t meet at least the first three of these criteria then I’d argue that what you have is still a bespoke service. And if you’ve not sold it at all then all you have is a capability or at best an idea.

Products evolve from client engagements.

Approaches to Productisation

Some organisations will be using consulting engagements as a means to identify user needs and/or as a means to fund development of a software product or platform.

But developing a product doesn’t necessarily involve building software, although I think some form of automation is likely to be a component of a more repeatable, productised service.

You might start productising a service simply by documenting your last engagement. The next time you do a similar engagement you can base it on your previous most successful project. As you continue you’re likely to iterate on that process to start to distil it into a check-list or methodology. Ideally the process should start from pre-sales and run through to final delivery.

There’s already lots been written about lean product development, the importance of adding metrics (which can include measure product process). And also about the care you need to take about extrapolating the needs of early adopters to later customers. I already feel like I’m doing stating the obvious here when there’s a wealth of existing product development literature, so we’ll skip over that.

But I’ll also note that there’s (of course!) a lot of overlap between what I’m outlining here and the discovery phase of service design. The difference is really just in how you’re being funded.

I’d argue that taking an iterative approach is important even for freelancers or small consulting firms. Even if your end goal isn’t a software product. It’s how you get better at what you do. Retrospectives, ideally involving the client, are another useful technique to adopt from agile practices.

But productisation also takes effort. You can iterate in small steps to improve, but you need to build in the time to do that. Even a small amount of reflection and improvement will pay dividends later.

I’ve been doing some domain-modelling with an arts organisation recently. The domain model that we’re working on will help underpin a new version of their website.

We gathered some domain experts across the business and ran some workshops to start capturing how they think about their domain, what they do, what the outputs are, etc.

Data modelling isn’t something that most people do. The process of trying to build a model of the world is, to varying degrees, new to them. Just as understanding the nuances of different types of art events and curating exhibitions is new to me.

So there’s been an element of me teaching them about what I do — the geeky stuff — alongside them teaching me about what they do. By coming to more of a shared understanding we can collectively get more from the exercise.

I love that process.

I love learning stuff, particularly in domains that are very different to the one in which I often operate. You don’t often get chance to sit with a bunch of domain experts and hear them discuss what they do at great length.

I also love that light-bulb moment when you can see people suddenly get what you’re teaching them. Its like you can actually see them levelling up in front of your eyes.

(I’ve been trying to rationalise what, on the surface, seems to be too very divergent interests: a love of teaching & a love of coding; whatever the reason, it probably explains why I keep doing different roles).

I then got to thinking about how so many of the events that run these days are largely domain based: domain experts talking to each other. Not people teaching each other new things, maybe in wildly different domains. I guess Ignite events might be closest, but I’ve never been to one. They also seem like they’re highly structured and involve calls to action rather than teaching and knowledge sharing, but I might be wrong.

So what kind of events am I missing? Where can I get my learning fix, or is there scope for a new type of “geek” event?

Earlier today I hit the publish buttons on the blog posts announcing the shutdown of Kasabi and the end of Talis’s semantic web activities. Neither of those were easy to write.

My time at Talis — which will have been four years in September — has been a fantastic experience. I’ve worked with some incredibly talented people on a wide range of projects. The culture and outlook at Talis was like no other company I’ve worked for; it’s a real pleasure to have been part of that. I’ve learnt an massive amount in so many different areas.

I’d argue that Talis more than any other company has worked incredibly hard to promote and support work around the Semantic Web and Linked Data. And I’m really proud of that. Despite increasing — but still slow — adoption, the decision was made that there was only so much more that could be done, and that it was time for Talis to focus elsewhere. Over the next few weeks I’ll be winding up Talis Systems’ activities in that area, and working with existing customers on continuity plans.

This year has been very difficult, on a number of levels. On the whole I’m now glad that I can focus on the future with a fresh outlook.

In the short term I’m considering freelance opportunities. If you’re interested in talking about that, then please get in touch. My profile is on LinkedIn and I’m available for work from 1st August.

Longer term, I want to take some time to think about the kind of work that I enjoy doing. I love building products, particularly those that are heavily data-driven. I want to build something around Open Data. Beyond that I’m not yet sure.

If you have something that you think I could help with, then I’d love to hear from you.