Lessons from PowerPoint for patient-controlled records

The story of the struggle of PowerPoint’s founders (free PDF) is fascinating to read. As with many stories of extraordinary technology success the beginning was hard, and failure was the obvious end. For three Christmases in a row the founders only went home in December after they had set up plans for bankruptcy in January.

But the founders made a number of excellent product design decisions, different to everyone else in the industry. As we update the PKB roadmap and I reflect on the state of the market, two aspects of the PowerPoint story jump out at me.

First, they chose a unique horizontal integration approach which drove their feature choices. This choice was not obvious to the industry at the time. This diagram – from the founders’ meticulous notes at the time – explains it well. (Note that although Microsoft currently owns PowerPoint and Excel, the start-up Forethought built PowerPoint after Microsoft had launched Excel, and Microsoft only bought Forethought after PowerPoint had launched.)


PowerPoint accepted charts, drawings, spreadsheets and other data types from other products. PowerPoint’s creators understood that those other products would have much more depth in creating their data types, and that users would prefer those products over any shallow set of features PowerPoint may have. Instead PowerPoint’s power would be to assemble, arrange and output these as slides.

At PKB we make a similar choice in the patient-controlled product category we created. The principle of horizontal integration may be clear, but the practice is a constant process of interpretation in our work with customers and users. We deliberately choose to leave out the institutional workflow of clinicians’ electronic medical records systems, much of which is focused on documenting activity for receiving payments.


Instead we accept data from all sources through our programming interfaces and web user interface. This creates a single shared record that is real-time, complete and accurate.

image2So we focus our workflow on this shared record in three ways.

  1. Making this single shared record available to everyone everywhere. We started this with a website for patients and professionals to manually add and see data. Now every data point is available for reading and writing using our programming interfaces. Wherever possible we use standards, starting with HL7 version 2 and now adding FHIR APIs). The patient controls access, and we started with a simple model of each patient giving each professional access to everything in the patient’s record. We then allowed the patient to delegate control to others. Then we created privacy labels to make the control granular enough to cope with complex situations but simple enough for a new user to understand without reading a manual.
  2. Care plans visible and editable by everyone everywhere. Without PKB’s single shared record, each clinical team looking after a patient still creates their own care plan in their internal medical records system. A few institutional records systems allow the patient to view the care plan, none of them allows other institutions’ users to do so, and none of them can cope with edits and corrections from users outside the institution. PKB allows everyone to work together while seeing all the data so PKB is the only system that can provide a shared care plan. Expanding care planning functionality is a significant part of our focus for 2018.
  3. Correcting and curating the data. For now most users’ urgent needs are to see data in the first place. But as they see the combined data for the first time, they finally see the conflicting notes. Institutional medical records are written like blogs: a series of notes of what each person did. These notes are too long and too difficult to understand in the too short a time with the patient so the professional usually starts to take notes anew. The patient experiences this as being asked the same questions by different doctors. PKB’s shared medical record allows a wiki approach: a consensus of current understanding of the patient’s situation, with everyone correcting and curating as they gain understanding. PKB’s product challenge is to have the right medico-legal audit trail for these improvements to the record while making the consensus quickly clear. The timeline view we are designing now is a step along the way for this consensus.


The second interesting learning for me about the history of PowerPoint is that they had unique data driving design decisions. Bob Gaskins, the inventor of PowerPoint, had a massive collection of print-outs of slide shows. He collected these from his travels to country, customer and supplier offices as part of his work at large companies. He kept the collection because of his childhood interest in presentations: his father owned a company that sold presentation supplies, and Bob had access to the data on exactly how many slides were created every year in the USA.

The real users’ slides allowed Bob’s team to understand exactly what users were commonly trying to achieve, and what they cared about enough to spend time and money on. PowerPoint 1.0 thus had exactly what most users needed, and nothing else. Only with PowerPoint 3.0 did the team add features for slides which had never been used before, like animations.

We now have a similar opportunity as we have patients with PKB records in every county in the UK.


Real-world clinical usage allows us to make counter-intuitive decisions. For example with the timeline view a common assumption was that combining online messages with face-to-face encounters and appointments would cause clutter. Studying the data about our patients showed the reverse, i.e. the real risk was a sparse timeline with too much white space. As we combine data from our different customers into the same record for each patient, we continue to gain insights. If you are interested in discussing these further, do contact us.

Leave a Reply