Category Archives: Social Media

HANDI – The Healthcare App Network for Development and Innovation

Most of you will know of my involvement with HANDI and new not-for-profit organisation intended to support and encourage the development of health and care apps to transform health and care. www.handihealth.org which I would urge you all to support.

People keep asking “are apps things that run on mobile phones?” and keep talking about “mHealth” as the coming thing.

Well, yes apps run on mobile phones and ubiquitous connectivity changes the world, but there is an underlying “app” paradigm that’s more important so forget the “m” and concentrate on the paradigm.

While it is true that the “app” paradigm comes from the mobile world, the mobility of apps is not the primary thing that makes them a powerful, disruptive technology, rather it is their other characteristics, and these can apply irrespective of the device an app is running on and the modality of its current connection.

My vision for an app is that it is an agile, lightweight and intrinsically connected thing, running on whatever device, from phone to 80 inch digital TV, that happens to be right for the user at any moment, adjusting itself to the form factor of the device it’s currently running on, using mobile connectivity when it’s mobile with a seamless handover of app and data as the user moves from device to device.

Apps are easy to build; at their most powerful when designed do a few things well; are easy to distribute, install and use; and with care can be orchestrated to work together.

Apps are easy to build because they make substantial use of pre-built components in a well defined development framework and can make use of third party data and services, available to them in the cloud, allowing the developer to concentrate on the unique not the generic features of their app.

App stores make it cheap and easy for developers to promote and distribute their app and for users to find and install it

Finally, if they have an appropriate platform, open APIs and a few standards Apps can be orchestrated to work together to meet the broader needs of an individual user.

Together, these thing drive cost down, quality up and enable new ways of working.

Already this new paradigm has produced a flurry of free or low-cost apps in health and care and enabled people who previously could not have got their idea to market to do so. But, this is only the beginning. If we can work together to make it even easier and cheaper to build health and care apps and if we can encourage the development/adoption of open APIs, open platforms and open standards to facilitate the orchestration of apps to support the processes of health and care, we will improve well-being and transform the way health and care are delivered .

This is what HANDI is about. Join us.

Cutting off your Nose to Spite Your Face

I’m increasingly using social networking and online collaboration tools for projects in my working life and more and more of my clients are using social networks to promote their interests with their customers, service users and the broader community. Without these tools my efficiency would plummet and my clients ability efficiently pursue their objectives would be much undermined

However, I’m still finding that many behind corporate or NHS firewalls can’t get access to these tools and are thus denied the transformational benefits of making proper use of them. Even though others including many more enlightened  NHS organisations are demonstrating how they can be used efficiently.

Organisations who think they are going to improve corporate productivity by taking a “sledge hammer” approach to Internet abuse and corporate security are dinosaurs and will go the same way, only hopefully a lot quicker.

Sites and services commonly blocked include Facebook, Google Docs, Dropbox, LinkedIn, YouTube, Mikogo, Skype, G+ The list just goes on and on.

The problem is further compounded by overzealous email filtering. Don’t the IT droids understand that there are legitimate business communications in Health and Care dealing with paedophilia, child abuse and rape or that “Dyke”can also be a surname?

Sure there are legitimate concerns with regard to staff making improper use of their employers time and resources and the security of corporate networks, but we don’t try and stop doctors and nursing abusing medicines by saying they can’t have any access to them and in any case where staff are poorly managed and motivated they don’t need technology to help them squander their employers  resources.

I also amazed how people put up with these restrictions, particular in large poorly managed organisations where the IT function is remote, difficult and unresponsive and people feel it is just too much trouble to argue their case and live with the inefficiency or just work round it using their smart phones.

Organisation have to understand  that survival will increasingly dependent on having a workforce who know about and understand how they can use web 2.0 tools like social networks, crowd sourcing and cloud based collaboration. Cutting of their access to such things in the workplace is surely cutting of your nose to spite your face and an abrogation of managements responsibility to ensure staff are trained and  motivated to use these tools appropriately. IT departments also have to step up to their responsibilities to protect corporate security and resources in way that don’t interfere with the business and realise that they can’t get away with blunt sledge hammer approaches.

Finally,  those face with in appropriate block on access, should tell their employers to get their act together. But, don’t blame me if you get fired.

Lessons from GP Computing

UK GP computing leads the way globally in the application of clinical computing at the point-of-care and for many years was the only example of the widespread implementation of clinical computing at the couch-face.

It is interesting to examine why GP computing was, and still is, much more successful than clinical computing elsewhere in the NHS and what lessons, if any, are transferable from general practice’s experience to other care settings.

To carry out this examination requires an understanding of the history of GP computing. In writing this I am struck by the parallels with a the story of the development of the London Underground, told in a book read on holiday “Subterranean Railway” by Christian Wolmar. This tells of a success built on innovation, mainly unsuccessful commercial opportunism, limited (but occasionally enlightened) state involvement (importantly not in the innovative phase), luck, and fierce competition between suppliers (attenuated by self-interested cooperation). Why I was reading a book on the London Underground while on holiday in Kefalonia is a question I will leave readers and my family to ponder.
GP computing in the UK can trace it roots back to early research-funded experiments in the 1960’s but only started to get a significant foothold at the end of the 1970’s when microprocessor based computers made multi-user systems running operating systems like OS9, BOS, Xenix and Mumps affordable to innovative practices (interestingly it was these machines rather than the early PCs, which appeared at the same time, that powered the first generation of systems).

These systems were developed by GPs themselves (or those very close to general practice) and were focussed on automating processes that were currently onerous and which looked like easy targets for computerisation – notably, patient age-sex registers and the production of repeat prescriptions. These tasks were also attractive targets because their automation brought financial benefit (substantial cost savings around repeat prescriptions and revenue opportunities and cost savings around age-sex registers). There were few grand plans systems were built quickly and deployed quickly, most were flaky, but the small band of enthusiast soon discovered what worked and what didn’t. Some big companies entered the fray (DEC, IBM, Centrefile (a part of Nat West Bank)) but it was the gifted amateurs who were close to the requirements that built the successful systems and all today’s market leaders grew from small innovative start-ups (all but one of them from systems that first appeared in the early 1980’s).

This gives us the first few lessons which I think are transferable and still hold good:
Development of systems has to be user-centric with end-users and other domain experts involved throughout the whole system life-cycle, not just in the requirements gathering stage.

Rapid prototyping and agile development work best, particularly when extending IT in to new areas or using it in new ways when we don’t really now what the true requirements are and what’s going to work best.

Users will put up with and engage with a flaky system that does something that is actually valuable to them. If user responses to a new system are dominated by complaints about quality and usability it probably means they do really value the functions it is designed to perform.

The market grew slowing in the beginning and in early 1980 Government intervened with the disastrous Micro’s for GP’s scheme which killed off many of the embryonic commercial suppliers and nearly destroyed the market, but this had two positive effects. Firstly, it resulted in the availability of prescription forms on continuous sprocketed stationary (making it much easier to print prescriptions, although confusion over standards meant these new forms were produced for many years at a non-standard width!) Secondly, it led to the formation of the General Practice Computer Suppliers Association (now subsumed in the Intellect Health Care Group) which demonstrated that suppliers could work together in the public interest (as well as their own) and formed an effective working relationship with officials from the DHSS which helped avoid future inappropriate Government actions.

Some more lesson here.

It is often simple things – (like the provision of prescriptions forms and changes in regulation to allow their use) that can enable new technology to deliver more efficient business processes.

The interests of suppliers, with a long-term commitment to a market, are much more closely aligned with each others and the interests of customers than is often understood. Suppliers, customers and regulators can and should work together and such cooperation will tend to drive out suppliers seeking to gain short-term advantage at the expense of their customers.

There is scope for multiple interpretations of standards (even something as apparently simply as the standard widths of paper) effective standards implementation require earlier testing to prove interoperability – With today’s complex standards IHE provides an exemplar of how this can be done with their Connectathons www.ihe.net

By the mid 1980 about 5% of GP practices having some sort of GP system, but while a few pioneers had screens in their consulting rooms most of these systems were used primarily in the back office. It was at this time that a number of people recognised the potential commercial value of anonymised data from GP systems and two companies, mine, AAH Meditel (now subsumed in iSoft/CSC and VAMP (now INPS/Cegedim)) launched schemes which offer sophisticated multi-user systems to practices at no cost in return for anonymised data. These schemes (like some of the early investments in the London Underground) were eventually commercially unsuccessful (I lost £13 million of investors money and VAMP must have lost a similar amount) but between us we left a legacy of over 2000 computerised practices who chose to keep their systems As well as this direct effect the “Free Schemes” demonstrated the benefits of computerisation and over this period many other practices computerised outside of the “Free Schemes” and the Government introduced a direct reimbursement scheme for the cost of GP systems (deliberately designed to undermine the business models of the “Free Schemes” of which they disapproved). By the time the free schemes ended in 1990 GP computerisation had exceeded 50%.

The widespread implementation of GP computing made possible various developments in General Practice which would not have been possible if the practicality of GP computing had not been demonstrated. These included the data driven 1990 GP contract, GP fundholding and early developments in EDI between GP practices, Health Authorities and hospital laboratories. I remain particularly proud of the work my company did in EDI We had established an electronic network with daily communication with nearly a 1000 practices (by far the earliest such network of any size). We used this network to collect data (VAMP used disks in the post), but also opened it up to allow early experiments with EDI. Sadly we lost the network with the “Free Scheme” and failed to commercially exploit our early lead in EDI.

So some further lessons:

Young and foolish entrepreneurs should be encouraged to deploy innovative solutions, as the investment will benefit healthcare independently of their commercial success. It is worth noting that we would not have either the London Underground or the Internet if numerous hopefuls had not lost their shirts in the process of building them.

Benefits don’t flow from IT but from the changes in ways of working it makes possible. IT can both catalyse and enable changes in business process and culture. The quality and efficiency of general practice today has been much enhanced by the changes GP IT has enabled to happen over the past 30 years.

Today, virtually all GPs use a computer in the consultation, the majority of practices are paper-light (they don’t routinely refer to paper records) although they have to scan much incoming paper to achieve this and most mid-carer GPs have never known general practice without a computer.

As well as the lesson that flow from the history there are other factors that enabled GP computing to be successful which relate more to the nature of general practice and which don’t apply in many other care settings these include.

The scale and complexity of general practice. General practices are not simply organisations and there is considerable variation between their ways of working and thus their IT requirements, but compared to an acute hospital or large community service they are relatively homogenous, quite small (typically 10 – 20 people) and it is reasonable practical for a single person to have an intimate understanding of all they do. Replicating this level of understanding in larger organisation is close to impossible and while more formal methods of requirement gathering can help the answer probably lies in avoiding the problem by avoiding “lowest common denominator” monolithic enterprise-wide systems and instead focusing on multiple “best of breed” systems able to interoperate to provide not just enterprise but community wide operation.

The nature of GP Encounters. Most GP encounters occur in an office environment where size and portability of equipment are not an issue and are off a nature where infection control is not a major concern. Technological advances are now close to removing the problems of using systems on the move or in difficult environments. We already have equipment in form factors to suit mobile use, with ubiquitous wireless LAN and WAN a reality in many places. We have devices that can be wiped clean and well developed voice recognition enabling use in most clinical environments, with the short-term prospect of cheaper and even more usable mobile devices, 4G connectivity and new hands-off human-commuter interfaces it will become possible to deploy IT in even the most difficult clinical environments.

UK GPs are “for profit” businesses and until 2004 were the direct customers of GP systems suppliers. This meant that the frontline user was making the purchasing decision, that they demanded a clear return on their investment, were willing to fully commit their part in achieving benefits and the associated ROI and would robustly hold suppliers to account to play their part.(as an ex CEO of a GP supplier I still have the scars!) Creating the same relationship with larger health providers is not possible. However, it is possible to achieve some of the features of this relationship by ensuring that frontline staff takes a leading role in procurement decisions (not just participate in the procurement), that personal and organisational incentives are aligned with benefit realisation (which must themselves be aligned with real business drivers.) i.e. pretty much the opposite to what happen in the NPfIT where system suppliers were disconnected from frontline users by the imposition of a process obsessed and dysfunctional “communication” channel via the LSPs and the BabyFITs (the local arms of the NPfIT.)

The Independent GP Systems User Groups have be a critical factor in the success of GP Computing. I think the first to form was the Abies User Group (now subsumed into iSUG), but all of the major systems spawned user groups. These groups performed two important set of functions. Firstly, to establish robust communication between the suppliers and their customers, both challenging and supporting their suppliers to ensure end-users interest and priorities were given due weight. Secondly, to provide an infrastructure to enable ideas and practical experience to be shared between users. The User Group national conferences attract many hundreds of delegates and many of the group have vibrant local branches. The User Groups also pioneered the use of what we would now call “Social Media” with bulletin boards and mailing lists operational by the end of the 1980’s where users could share experiences and get solutions to problems and development of these early services still provide vital support and resource for end users today.

Competition GP computing in England and Wales was a fiercely competitive environment with many suppliers competing for GPs business with around 30 – 50 serious players in the market at its peak (there are some much higher figures for the number of suppliers quoted but these are mistaken). Goverment intervention with the “Micros for GPs Scheme” in the 1980s and the NPfIT in the 2000s damaged the market and reduced competition, but thanks to the robust response of suppliers and their GP users the market while now more mature (with just 5 suppliers) remains competitive and it is critical that changes which will flow from the end of the NPfIT and GPSoC Contracts done further undermine competition in the market (I will expand on this in a future blog).

In summary, much of the success of UK GP computing can be put down to luck with the right technology being in the right place at the right time for the early pioneers to pick it up and run with it. In the complex world of health informatics GP computing was a relatively easy and fertile place to start. Some of the factors that made UK GP computing a success where unique to that environment, but in most cases they are generalisable at least to some extent and we would do well to consider how the lesson from this success can be applied elsewhere.

In Summary

Record summaries can play an important role in the facilitation of clinical communication, but only with careful thought, which is often lacking, as illustrated by the sad tale of the English Summary Care Record (SCR) and the happier tale of the Scottish Emergency Care Summary.

The first thing to understand about a “summary record” is that the term is a meaningless. There are potentially a practically infinite number of summaries that could be created from an entire record, but for a summary to be useful it has to be for a clear purpose understood both by those creating and those using the summary. Scotland got this right with a clear purpose “Emergency Care” now be successfully extended for another clear purpose as the “Palliative Care Summary”. While the English SCR is basically also an emergency care summary it has been touted as suitable for a whole range of purposes including many for which it not fit (“when you only tool is a hammer all your problems look like nails”) and while this is not the only reason for its’ lack of progress this lack of clarity of purposes remains a key problem for the SCR.

What then is a record summary and how can we describe the various types of summary that might be useful?

First, let’s consider the difference between and integrated a standalone summary. The distinguishing feature of an integrated summary is that the rest of the record from which it is drawn is immediately available. i.e. you can “drill down” into the summary and see the detailed information that underpins it. Today, such drill down facilities are usually only available when the record and summary are part of the same system, but this not need be the case and in the future it will become increasingly common to be able to drilldown to data held in other systems. With a standalone summary the user only has easy access to the information held in the summary and it thus has to contain all the information that might be needed to support its purpose. Clearly a different approach is required in the design of a standalone summary compared to an integrated one. The summary view in a GP system is an integrated summary while the SCR and ECS are standalone summaries.

I also find it useful to think of summaries as being either horizontal or vertical and while this is sometimes an oversimplification I find it useful. A horizontal summary is one that is wide but shallow it contains top-level information from many parts of the record. The SCR, the ECS, and the summary view in a GP system are all horizontal summaries. A vertical summary is narrow but deep containing most or all of the information from a few parts of the record. A medication summary would be an example of a pure vertical summary. A more complex example would be a disease specific summary, say a diabetic shared care record. This is a summary of the record containing detailed information relating to diabetic care (and thus vertical) but would also have summary information from other parts of the record (and thus have some horizontal components) the Scottish Palliative Care Summary is another example of complex summary.

My view is that to be really useful summaries should be statefull i.e. that they should reflect the current state of the patient. With a simple summary like a medication summary it may be possible to maintain statefullness automatically, but in more complex summaries a degree of human intervention is usually required to maintain statefullness and this is well described by Ian McNicholl in his blog http://bit.ly/dT3d8u where he talks about the maintenance of a “meta-narrative”. Some summaries are stateless and just represent a journal of all activity within the scope of the summary. The Spine Personal Spine Information Service (PCIS) and the abandoned London Shared Record were such stateless records, just a spike onto which a range of clinical correspondence had been placed. Such summaries have some value but to understand the current state of the patient the user has to read back through the record and risks missing significant information buried at the bottom of the pile. Such summaries have the advantage that they can be automatically created drawing on a large range of sources, but in my view unless supplemented by an appropriate statefull summary are of limited value. Some proposal for the SCR would combine the statless PSIS with the GP maintained statefull SCR as it is today.

One of the key uses I see for a summary is the sharing of information and the management of a care plan and care pathways over the Hawking Horizon http://bit.ly/jAoFWV (a patient is often on many pathways but there should only ever be a single integrated care plan) Ideally such a summary should operate under shared governance and be the result of considered publication in to the shared space by all of the actors involved in the care plan (including the patient and members of their informal care networks) systems should facilitate the creation of such summaries automatically updating those parts that can safely be automatically maintained, but will require active maintenance by the human actors involved. The systems managing the summary should provide mechanism for reconciling information coming from multiple sources and resolving differences of views (some analogies exist with the Wikipedia approach which allows the resolution of differences on a discussion page behind each article) but should be able to represent dissonance where resolution can’t be achieved.

Summaries are often implemented as read-only and this approach certainly simplifies the technical and governance issues associated with keeping a summary in sync with its source systems, but it might be desirable to allow information to be edited or entered into the summary with mechanisms to update source systems but any mechanism should not pollute source records with information they don’t need, want or consider of adequate quality.

Summaries could usefully supplement and integrate with the stateless status feed proposed for Fredbook http://bit.ly/lfq3f3 and form part of the rich online environment in which patients, informal care networks and healthcare professional come together.

Medication Repository Anyone?

I was writing this piece when I read Ian McNicoll’s stimulating blog piece “EastendEHRs? – Dr Leggs’ Diary”   Ian talks about community medication records, very much the theme of this piece.

It seems to me that a shared medication record is the single most useful thing that could be provided in any health community and that while such a service is not without it challenges it is eminently doable.

I also feel that working through what such a service would look like and how it might be delivered could help us clarify our understanding about a number of technical, clinical and governance issues that would have general applicability with regard to the sharing of other parts of records or record summaries.

In my mind a medication repository is a logical construct, that might be physically instantiated in many ways to provide a single authoritative source with regard to medication information for a particular patient I envisage that all applications that need to read or write medication data would operate against the repository, or a locally maintained cache of it, rather than managing their own medication record.

Ideally, the repository should contain details of all medication from all care setting including patients self-medication, but a useful start could be made with a more limited scope (say just GP, outpatient, community and hospital discharge medication.)

There are many potential architectures for a medication repository. I am not necessarily suggesting a single medication repository for a health community (although this might be the most practical solution), there could be many (in the extreme, one for each individual) and they don’t have to have exclusive geographical scope (patients would be free to choose from all available service providers) the important things are that there is a single authoritative source under shared governance, a means of discovering where this is for a particular patient and that all repositories support a common API so that any application can easily work with multiple repositories.

Building appropriate governance arrangements around medication repositories is perhaps the most significant challenge, but also a particularly interesting one that will allow us to explore approaches in a constrained (and therefore manageable) scope that we can later apply to other aspects of the record.

Governance arrangements need to ensure that all those with rights to the information in the repository can be confident that their rights will be respected and protected for all time even in the event of the failure of a particular repository provider – I envisage some form of information escrow to achieve both of these things.

Governance arrangements also need to ensure that the provenance of information is secured, handle the allocation and transfer of clinical responsibility associated with information held in the repository. and the ongoing responsibility for management of a patients medication (changing cancelling adding medication.)

These governance issues illustrate the inseparability of the information and clinical governance issues, an inseparability which I believe applies much more broadly and is something not properly recognised in the implementation of existing systems.

Moving this idea forward requires some proof of concept work, which in turn requires someone willing to build an operate and experimental repository and a couple of application providers willing to work with it – ANY VOLUNTEERS.

Exploring Social Media in Healthcare

On the 15th and 16th of April the BCS Primary Care Group will be running a Special Interest Group meeting to look at the role of social media in healthcare

PHCSG has been running SIGs (known as CLICSIG for reasons almost lost in history) at the rate of 4-6 per year for 30 years and this format has proved a very effective one for allowing us to explore an issue of current interest in-depth.

The meetings operate under the Chatham House Rule and are restricted to BCS members and sometimes invite guests who can bring special expertise. Typically 15 -25 members meet on Friday evening for informal discussion over dinner with a more formal session on the Saturday. Outputs are written up and inform future BCS work and policy and are usually published through a suitable channel.

Our next meeting is being facilitated by Ian Herbert and myself. We want to explore how social media might be used in healthcare. We are also interested how the PHCSG might use social media for its own purposes, both because we believe this would directly beneficial and also because we hope such use will help us better understand how social media can be applied more generally. At the meeting I will be exploring the ideas in my recent blog “Dr Finlay’s Facebook” and other group members will be contributing their ideas. Given that social media is a young person game we are planning to invite some of the younger generation to join us.

If you are a PHCSG member you might like to attend details from jill@phcsg.org if you are not you can join, or if you think you could bring special expertise and would like to attend as a non-member get in touch with me.  There is no charge for the event but those attending pay their share of room hire for the event and their own accommodation and subsistence.

We hope to present the outputs of this work at the PHCSG Conference on 10/11 May www.primaryhealthinfo.org

Dr Finlay’s Facebook?

The marvellous phrase comes from the Demos publication “the talking cure why conversation is the future of healthcare”  by Jack Stilgoe and Faizal Farook http://bit.ly/e0GUAD They use it to describe the changing relationship between internet enable patients and doctors. I have stolen it as shorthand for a new online environment that I think we need to create that harnesses social networks to manage virtual and physical care and link formal and informal care networks. This is certainly not a Facebook application and I probably need to find another name.

My ideas on what I mean are still developing, but what I’m trying to describe is something that combines some of the features we see in social networking tools like Facebook and Linkedin with facilities that might be provided by a patient portal providing access to knowledge and services and tools to allow patients to create their own records and access and contribute to the records about them held by others.

This environment also need to integrate physical and virtual care managing the handovers between the two, with facilities for secure consultations between patients, their informal care networks and the Health Care Professionals providing formal care. The environment also needs to support a privacy and governance model that allows patients to share and protect their information as they wish for both primary (their direct care) and secondary purposes (uses not essential for their direct care such as medical research).

This environment needs to be open and controlled by nobody while allowing patients to control how their information and healthcare are managed. It needs to provide a technical platform that can facilitate the exchange of information and access to services and support the creation and deployment of a myriad of applications and devices to support health, wellbeing and care.

We see many developments that might form part of this environment the www.connectingforhealth.nhs.uk/systemsandservices/spine , www.google.com/health , www.healthvault.com , www.emisaccess.co.uk , www.patientslikeme.com , www.patient.co.uk But still have some way to go. Do others share this vision? How can we take it forward.