Monthly Archives: March 2013

ESB, Featured, Interoperability, NHS Policy, Open Source

SPINE 2 – A Game Changer for NHS IT

3 Comments

I attended a presentation of SPINE2 from CfH at Intellect today. I think it’s the first thing from CfH to really excite me (at least in a positive way) since they were established. While I’m reminded of  “The Second Coming of the Great Prophet Zarquon”, who fans of Douglas Adams will remember only managed to get this in just before the end of the universe.

I have been hearing reliable rumours for some time about skunkworks activity within in CfH to try and re-implement SPINE (at least as used, rather than as specified) using open source components and an agile development methodology, but today was the first official confirmation of this. It would seem that the initial skunkworks proved the concept and has been thrown away, a great example of the value of a “fail-fast” philosophy, and that this has been followed by a second phase of the project which appears to be close to delivering a production version of SPINE2. I’m reliable informed that the initial skunkworks involved just a handful of people within CfH with a cost of under £250k. The next phase of the project has been support by some external development resource procured under G-Cloud from BJSS (www.bjss.co.uk) and while I don’t know how much this cost I think it pretty clear that it will have been only a tiny fraction of what it must have cost to get SPINE1 to the same stage.

If we are to believe what the SPINE2 Team told us– And I’m inclined to do so, because they spoke with obvious conviction and it tallies with other intelligence – this project is going to be a game changer for NHS IT. It will create lots of new opportunities for those in supplier community who can embrace new ways of working, has a much better chance of delivering what the NHS needs while providing a nasty surprise for those on both the customer and supplier side of the fence who have built empires and companies on bloated ways of working.

There are two key features of this project which I find very encouraging and I think are the basis of its’ likely success. The first is extensive use of proven open source components and the second the adoption of agile technologies. These together drive down development cost and risk and provide a much more responsive and flexible approach than traditional waterfall methods (for a light-hearted view of this see http://handihealth.org/handi-out-of-hours/ ) Add to this the use the project has made of G-Cloud to simplify the procurement of external resource and you have a much more responsive approach all round.

The team made some interesting comments. The first that they would be able to provide a copy of SPINE2 on a DVD that would allow suppliers to have their own test environment that they could run on a laptop, this will be a great help to developers. The second was that they had the capability to open up code and new interfaces which could potential provide a much easier route for third parties to interface to SPINE. This step would not be welcomed by some suppliers who businesses are built on their knowledge of and access to existing interfaces and the CfH team made it clear that no decision had be made to do this. However, while there have been previous promises from other parts of CfH that they would not do anything to undermine the business models of those who had invested heavily in interfacing to SPINE1, I don’t believe that it is the business of NHS to protect outdated ways of working and hope that a decision to open up SPINE2 to the maximum extent possible is taken. I for one would like to see the source code of SPINE 2 freely available on GitHub https://github.com/ and when I asked if this was a possibility I got a positive answer.

The slides of the presentations will be available to Intellect members shortly and I will include a link to these here as soon as I have it. I will also explore if these can be made publicly available.

This project could provide a new model for deliver NHS IT and deserves further development. My initial reaction is that I would like to see more of the work outsourced to the private and third sector, as I don’t think a return to in-house development on a wide scale is a great idea, but I think this project provides a great basis for a move to a more responsive, better value approaches built on an open and agile philosophy.

Finally, I’m encouraged because I think this approach fits with other ideas I’ve been promoting around GPSoC and the potential role for an ESB (which is fundamentally what is at the core of SPINE) See here for my blog “An ESB for GPSoC Phase 2 ?”

 

Apps, EHR, Featured, GP Computing, GPSoC, Interoperability, NHS Policy, Open Source, Standards

An ESB for GPSoC Phase 2 ?

2 Comments

A key feature of the proposed new GPSoC contract is the opening up of interfaces of the principal GP systems to subsidiary system suppliers (this can include pretty much any product or app that might be offered in the primary care market.) The plan is to address the interfacing issue into two phases which will start broadly in parallel, but deliver over different timeframes.

Phase 1 is intended to be available from day 1 on the new GPSoC contracts and will simply place a contractual obligation on principal suppliers to make available broadly those interfaces they currently make available at their discretion (although some principal suppliers will have a little work to do to meet the minimum requirements.)

Phase 2 aims to make available a standard interface across all systems and while it will probably do this in an incremental fashion is not expect to deliver anything until at least 18 months into the new contracts.

This approach seems very wise to me, as I suspect 18 months is an optimistic  view of how long it will take to get to even a first version of a standard interface. Opening up what’s available now, particularly with some enhancement to the weaker systems, will be great stimulus to the market.

Work on the approach in phase 1 is going well, looks like it will substantially address the concerns raised in my last blog on this subject and enjoy broad support from both principal and subsidiary system suppliers and I don’t plan to say anything more about this here. What I want to do in the rest of the blog to look towards phase 2.

Point-to-point connections between principal and subsidiary system suppliers and accreditation on a similar per interface basis provides a viable option in the short-term but becomes increasing difficult as the number of subsidiary systems increases and becomes unsustainable when we look to moving the scope beyond GP systems. At this point we will need some form of intermediary bus such that all systems have only to conform and be accredited to the standards supported by the bus. It seems to me that while we might not absolutely need this in the immediate GPSoC context developing this as part of phase 2 would lay excellent foundations for the future.

I’m not a technical architect but it seem to me that it would be possible to use Enterprise Service Bus (ESB) technology to provide such a service (I would propose one of the existing health aware Open source ESBs) at it simplest the ESB would simply pass through interface requests looking no different to a third party supplier than an interaction directly with the principal systems. However, an ESB could do much more than this and its’ interposition would have many benefits:

  •  It could  off-load many functions from the principal supplier to make their lives easier requiring these functions to be implemented just once in the ESB rather than in each principal system e.g. authentication, identity management, access control, consent management IG, load balancing (to name a few.)
  •  It could protect principal suppliers from badly behaved applications and help in the arbitration of interface malfunctions (avoiding confrontation between principal and subsidiary system suppliers.)
  • It could  provide a transaction accounting platform that could support innovative business models (such as pay for use models) driving usage, better value and  more desirable and functional systems. The accounting platform could also provide a mechanism for charging the responsible party for compute resource consumed by interface users.
  • It could provide transformations and mappings between different technical and clinical content standards used in systems (making like easier for all participants) and facilitate incremental progress toward common standards.
  • It would provide infrastructure for interoperability beyond the scope of primary care.
  • Provide an access point for developers to other NHS systems (eg SPINE, EPS, C&B, Customer Service Platform) building on the good work done with the NHS Interoperability Toolkit ITK.

I plan to explore these ideas with the GPSoC Team and through my work with HANDI and Intellect and would welcomes others views.

More Information

More information about GPSoC and copies of many of the draft documents are available from the GPSoC web site.

What is an ESB?

There are a number of open source ESB with healthcare specific functionality that could be candidates for such a service:

Mirth

Mule

Apache ServiceMix

More information about ITK is available at their web site

There is also relevant material on the HANDI and OpenGPSoC websites

 

 

 

Featured, Privacy and Consent

Preserving Trust in the Digital Age

1 Comment

Trust lies at the heart of the relationship between patients and those that care for them.

Meeting the challenges faced by the health care system requires that we make much greater use of digital technology and increasing sophisticated use of information, but in doing so we need to ensure we preserve trust.

Healthcare professionals have the right to expect patients to share with them the information they need to deliver safe, efficient, defensible, economical viable care and to allow them to record this information and share it with others as far as is necessary to achieve these objects.

Healthcare professionals have a duty to record this data but also to ensure it is used appropriately by themselves and others respecting the patients’ expectations of privacy.

Patients’ need to understand the need for data about them to be recorded and shared and that failure to allow this might result in suboptimal care or in extreme cases mean that care can’t be delivered to them.

Patient’s also have an obligation to allow their data to be used in ways which are in the broader public interest (for example to enable medical research or support economic well-being) where this can be done in ways that properly balance the risk to their privacy with the public interest.

In this blog I suggest some principles that might be applied do balance these rights and responsibilities and preserve trust in the digital age.

Respect the patient wishes and beliefs

Respect the patient’s real or imagined concerns with regard to their privacy, while explaining clearly to them the benefit of sharing to them and the greater good as well the risks of not sharing.

Acknowledge that the risks from a privacy breach vary dramatically depending on an individual’s circumstances, for some even a usually trivial disclosure can be life-threatening

Except in exception circumstances respect the patient’s wishes not to share data even in this decision is unwise and may mean that aspects of care cannot be provided.

Try always to work on the basis of informed consent, even in the case of de-identified data. Understand the emerging approaches that can make the collection and management of consent practical when previously it was not (e.g. www.miconsent.org). Relying on implied consent (with an opt-out option) or the use of legal gateways to avoid the need for consent may sometimes be necessary but such approaches should be used sparingly particularly where there is a material re-identification risk and take all reasonable steps to inform patients that this has been done and their rights to object or opt-out as well of the benefits of not doing so.

Apply the “Least Principle”

Seek to collect the least amount of data and hold it for the least time required to achieve your objective.

Avoid collecting data for which you have no clear need just because it “might come in useful”. Be particularly aware of those data which while not obvious identifying data have great utility to those seeking to re-identify de-identified data (e.g. dates of encounters).

Consider careful before creating large repositories of patient data. These can become what the Information Commissioner once described as a “Toxic Liability” However, the value of such repositories can be considerable. If build with patient consent and regard to privacy, they have an important role to share.

Acknowledge the risks

Acknowledge that there is a residual risk of inappropriate disclosure either by accident or malice and work to minimise it.

Acknowledge the risks of not sharing data which can offer be greater than those of inappropriate sharing. Good information governance is about maximising the benefits from data sharing not blocking it.

Acknowledge that the boundary between identifiable and non-identifiable data is a grey one. In all but the most limited or highly aggregated dataset there is a residual risk that those with motivation and opportunity can re-identify some of the individuals in the dataset. Manage to ensure that those with the motivation do not have the opportunity.

Be aware that for many dataset re-identification is easier than is generally understood and with rich dataset becomes a trivial task. Take active steps to understand and reduce the re-identification risk and carefully protect those dataset where the re-identification risk is material.

Actively manage privacy

Understand that the effective management of privacy requires a mixture of technical measures, governance rules and culture backed by audit to identify potential risks and actual breaches with robust action against those who through either a lack of care or maliciously fail to respect patient privacy.

Be aware of and apply all practical Privacy Enhancing Technologies

Take steps to keep up-to-date with both privacy enhancing technologies (PETs) and those approaches and technologies that might be used by those seeking to breach privacy.

In particular seek to understand approaches to anonymisation and pseudonymisation methods of blind record linkage (which allow record linkage without the exposure of identifiable data and the role that cryptography can play in protecting privacy.

 

NHS Policy, Privacy and Consent, Ramblings

Another own Goal from NHS Commissioning Board

1 Comment

It seems to me that the NHS Commission Board is about to score another own goal with it plans to seek section 251 approval to share identifiable patient data without consent reported in the Health Service Journal ( Warning: some of this article may be behind a paywall)

I want my identifiable health data shared so that it’s available to all of those who can use it to directly deliver better care to me – But I want to be in control

I am happy for my data to be shared for a wide range of secondary purposes that will help the NHS operate more efficiently, advance healthcare research, create economic opportunities for the UK healthcare industry, be used in any other way that contributes to the greater good or that someone is willing to make worth my while – But I want to be in control.

I want to told who my data will be shared with and have the right to restrict or extend the sharing as I chose  – even if this is not in my best interests.

I want my privacy to be protected and in particular I don’t want identifiable data or easily re identifiable rich datasets shared when the use of privacy enhancing technologies or more limited datasets make this unnecessary. If this is a little onerous for those who want to use my data – tough. However, if identifiable data is really needed and I consider the purpose noble I’ll probably consent – But I insist on being asked. I’ll lie and withhold information if I think it will be misused.

Trust lies at the heart of the relationship between patients, health and care professionals and their informal care networks. Using digital technologies and data differently is an essential part of what we have to do to have any hope of meeting the challenges that health and care faces. We have to work out how we preserve trust in the digital age and it is not helpful or necessary for the NHS Commissioning Board to attempt to remove patients from the decision about how their data is used or to ignore the existence of privacy enhancing technology that would enable them to achieve what they want to achieve without playing fast and loose with patient trust. I don’t understand how this sits in the context of a patient centered NHS or with the Government’s mantra “No decision about me without me”

My concern is that this is going to trigger a backlash that will result in challenges in the UK and European courts, patient asserting their right to opt out (section 251 does not trump active dissent), whereas most of us would be happy to share if we were asked, and most of all that this will destroy the trust that sits at the heart of the doctor patient relationship.

The issues exposed by Prof. Brian Jarman indicate just how important it is to make data about what happens in the NHS open and transparent to public  scrutiny.  Brian’s work shows us that Government and NHS can’t be trusted to hear or act on what the data tells us any more than they can be trusted to respect patient’s privacy.

We can do what needs to be done without the cavalier exposure of identifiable or trivially re-identifiable datasets. We have technology to manage blind record linkage so that identifiable data does not have to leave the control of the patient’s own care team.  Those working in the field have developed tools and processes that allow us to manage privacy risks in ways that reduce these without undermining the value of the data. While others are developing approaches that will make it easier to collect and manage patient consent.

I don’t want to see the progress we are making with open data, transparency and digital health care derailed by an avoidable backlash. let me be clear I’m with what the likes of Tim Kelsey are trying to do but they do need to take care.

For more information look at the exemplar work of:

openpseudonymiser.org

Sapior

THIN

MiConsent

For a broad review of the issues and more on Privacy Enhancing Technologies see Fair Shares for All from the Primary Care Group of the British Computer Society

Preserving Trust in Digital Healthcare will be the subject of the joint #CCIO #NHSSM Tweet Chat 8-9 pm, on Wednesday (20 March)

 

 

Featured, GP Computing, GPSoC, Interoperability, Standards

GPSoC – We need independent accreditation of subsidiary products interfaces

7 Comments

I attended the second joint Intellect and DH workshop today to look at the plans for the GP Systems of Choice (GPSoC) procurement. These plans are at an advanced stage and the GPSoC Team told us they were hopeful of getting the necessary approvals in about a month to allow them to start the formal procurement process with a view to awarding contracts in November this year.

The GPSoC Team have done a great job, responding encouragingly to feedback from stakeholders, leaving us with just a few important things to work on:

  • Suppliers need to understand the importance of GPSoC not just for the supply of GP systems but for anyone who wants to sell apps, software and related service into GPs and CCGs (Woodcote Consulting has services that can help)
  • The GPSoC Team needs to ensure that GPSoC is accessible to current and future SMEs and micro-enterprises – Their suggestion of a G-Cloud like approach is on the right track.
  • All interested parties MUST review the draft documents presented at the workshop (now available on the GPSoC web site) and feed comments in directly to the GPSoC team or via Intellect.
  • We need to radically change the proposed accreditation process for subsidiary products to remove it from the hands of Principal System suppliers and place it in the hands of a trusted third party (this is the main focus of this blog and is discussed in more detail below.)

This is the second round of GPSoC and the proposals will, at their core, provide continuing funding for the GP systems that practices are already using. Although the arrangements are designed to encourage new entrants it seems pretty unlikely that anyone other than the four remaining existing incumbents will bid to provide full GP system functionality. Nonetheless the proposed new GPSoC arrangements will open up the market and encourage and enable Subsidiary suppliers who want to offer products and services to work alongside the Principal Systems.

Central to this is a requirement that GPSoC will place on Principal System suppliers to open up interfaces for use by Subsidiary systems. Initially this will build on the APIs which the Principal System suppliers current make available to a number of partners on a discretionary basis and in time will move towards standard interfaces across all systems. Most importantly the new arrangements will make the provision of open interfaces a contractual requirement removing the Principal System supplier’s discretion which, historically, some have used quite blatantly to obstruct potential competitors.

There is plenty of information about GPSoC on the GPSoC web site and I urge anyone with an interest in this area to review the draft documents and feed in comment to the GPSoC Team or via Intellect. If you want to sell IT, apps, software, analytics and related services in to the GP market it is going to be vital that you understand GPSoC and probably that you enter the procurement in at least one of the three proposed lots and it’s important you feed in your views to help ensure GPSoC will work for you.

My view is that the key challenge for GPSoC will be to make the proposed contractual commitment on Principal System suppliers to provide open interfaces a genuine reality on the ground. There are some unavoidable conflicts of interest between Principal and Subsidiary system suppliers and too many opportunities in the current proposals for the former to hinder a truly open and competitive market.

I think the only area where there are significant flaws in the GPSoC proposals are those related to the accreditation of  the interface between subsidiary products and principal systems, which I think are both too onerous (at least in some areas) and which give the Principal suppliers an inappropriately central role in accrediting what could potentially be competitors products creating an untenable conflict of interest.

I want to see this change and made the proposal at the meeting that the accreditation of subsidiary products interface with principal systems should be by an independent third party not the DH and certainly not the Principal System suppliers as is currently proposed. This proposal drew broad support and seems to me the way to proceed.

There are going to be many subsidiary products seeking accreditation and many of the suppliers of these will want support including technical advice and access to test environments before entering formal accreditation process. While it is almost certainly the case that the greatest expertise about their APIs currently rest with the Principal System suppliers they are for a number of reasons not the right people to carry out accreditation of subsidiary products:

  • It’s not their core business and even with goodwill they are unlikely to dedicate their best people and adequate priority to servicing third parties, particularly given the other pressure their technical resources will face
  • There are unavoidable conflicts of interest when accrediting competing products and even if Principal System suppliers avoid the temptation to act in their own interests they will never be free of the suspicion that they have – Indeed there are risks of inadequate rigour in the accreditation process as they seek to avoid accusations of anti-competitive behaviour
  • Subsidiary system suppliers will want to engage with a test environment well ahead of entering the formal accreditation process and in many cases will wish to do this under commercial confidentiality to avoid alerting competitors to their plans. I can’t imagine that Principal System suppliers will be able to create Chinese Walls in which others would have confidence nor are they likely to have the enthusiasm for providing the wider range of support services required beyond the core accreditation function.

It seem to me that to establish this facility, perhaps under the auspices of an organisation that already enjoys the trust of stakeholders, would not be particularly difficult. Doing so would require that the cooperation of Principal System suppliers is contractually secured, requiring them to provide copies of their system to create the test and accreditation platforms needed as well as documentation and assistance in training the staff of the new service, they would also need to be placed under an obligation to deal with ongoing technical queries from the third party to agreed service levels and to work with them to ensure the test environment’s interfaces were accurate replicas of their production environments.

Principal System suppliers will have legitimate concerns that subsidiary products accredited by the third party will operate correctly when transferred to their production environments and that they have the resources in place to meet the demands subsidiary products place on their systems and it will therefore be necessary to give Principal System suppliers some visibility of the accreditation pipeline and for the Subsidiary System suppliers to work with them and the third party to manage the transition to go-live.

Funding of the third party should also not be a problem with the simple reallocation of the funds identified for Principal System suppliers to carry out accreditation transferred to fund the core accreditation function of the third party, while the cost of optional services such as pre-accreditation support and access to test environments could reasonable be met by Subsidiary System suppliers.

There is detail work to be done but it seems to me this proposed approach has much merit. It:

  • Addresses the concerns of Subsidiary System suppliers that, for whatever reason, Principal System suppliers won’t provide a responsive and efficient accreditation service.
  • Frees Principal System suppliers of the burden of running the accreditation process and of any suspicion that they might abuse their position.
  • Provides a platform on which additional services and support can be more easily and appropriately made available to Subsidiary System suppliers to encourage innovation.
  • Protects the commercial confidentiality of Subsidiary System suppliers in the pre-accreditation phase.
  • Provides the foundations on which further intermediary services might be developed supporting a move towards common interface standards.

I’d welcome views from others about my proposal and would be delighted to talk to anyone who wants to know how Woodcote Consulting can help them make the most of GPSoC.