Think you need an IDCR? Think again…

The letters IDCR are currently used in the NHS in England as an abbreviation for Integrated Digital Care Records, part of the latest push to transform health and care in England in the 21st Century towards more holistic, integrated, patient-centred care,  supported by the right healthcare IT.

The abbreviation IDCR is the latest in a line of health IT abbreviations or keywords to symbolise the information technology that healthcare needs/wants/requires. Those include EPR (Electronic Patient Record), EHR (Electronic Health Record), portal, SCR (Summary Care Record), CDR (Clinical Data Repository), patient registries, etc, etc. Though such terms and abbreviations might suggest that the health IT “buyer” has a range of technical products from which to choose, it is increasingly understood that any of these tools are simply technical artefacts amidst a sea of change.

That 21st century healthcare change that is upon us is a “complex change challenge” made up of people, process, information and technology. We also know that to make such complex change happen we need a mix of clinicians, managers and technical team to work together, for the greater good, for the patient.

Involved in such change over the last years, I’ve seen many related change efforts and am aware of the significant challenge in aligning clinical, managerial and technical language and purpose effectively towards these noble goals. There is often an inherent tension between the clinical/business change desired and the technical tools on offer. Ideally a well informed clinically led team will have a deep understanding of the process they want to improve and access to/control of a technical tool that meets that clinical/business need.  More often these multidisciplinary teams are convened towards a common health improvement goal, yet a little/lot unclear on how the IT will get them there. In many cases this desire for change ends up as a clinical and business push ends up tied to a likely technical product. The current push in the NHS around Integration Pioneers and Vanguards and Integrated Digital Care Records is a case in point.

Clinicians who join these explorations and discussions often struggle initially for a reference point. They may cite the health IT system that they themselves know and/or love/hate, it may be a clinical guideline (or related proforma) that they have a particular interest in having supported in this new world, or a particular clinical report that they want/need to support here and now. They use these as reference points as these are the healthcare information and knowledge artefacts that they know.

In bringing clinicians together around a healthcare improvement/IT project (e.g. EPR, IDCR, Registry etc etc) to gauge their “clinical requirements”,  then analysing those requirements to generate a related system design etc, significant clinical time and real intellectual effort is required by all those involved.  If the aim of these efforts is about patient centred healthcare improvement, the focus of these efforts could/should involve a look at clinical guidelines, forms, reports etc to inform the approach. Yet if one teases apart just one clinical guideline, one discovers the rich tapestry of information and knowledge embedded within. Splitting a single guideline apart in technical terms into the clinical content, workflow and clinical/business rules involved helps explain how and why traditional approaches to programme and project management struggle at scale in this field. The lengthy, detailed documentation that can result from such efforts to elicit “requirements” does little to contain the challenge here. Indeed such an approach to procurement and the related documentation can become a key part of the change challenge… and so a key gap between clinical need and technical direction can begin to emerge..

Is there an alternative approach to this “complex change challenge”? We think so.

Firstly we emphasise the word complex, to reinforce that this change challenge is about managing complexity, more akin to curating an ecosystem than crafting a machine. We offer the following tips based on our experience of these challenges at scale and with some reference to the helpful Gov.uk Government Digital Service standard.

Tip #1

Q: How to quickly scope a clinical change project with health IT?
A: Put the user in charge of these (clinically led) proceedings, with the support of an agile design team.
Follow the principles of User Centred Design and Agile Development with early “wireframes”/”mock-ups”/prototypes.   The tools involved might be as simple as a sketch on paper, a PowerPoint slide or an online mockup tool (e.g. Lumzy.com). Either way this allows the clinical teams to express their needs and wants in terms of usability.. perhaps the most critical factor in health IT adoption. If their ambitions are big and dreamy, so be it, it’s a vision to aim towards. Of equal value, these visual designs help management and technical colleagues discuss and establish what is “do-able” within the time and budget available. Such prototypes are perhaps the simplest and most effective way for clinicians, managers and technical folk to communicate the scope of the change involved. A picture tells a thousand words.

Tip #2

Q: Where to focus the early effort in a major healthcare improvement project with health IT?
A: Focus the diversity of the clinical community involved around its common interest in core/generic clinical content.
One of the main challenges in bringing a multidisciplinary team together is the difference in culture, language and agendas in the room. Such discussions are full of rabbit holes for the unwary. (Try agreeing a consensus definition in such a room on terms like “Care Plan” or “Care Pathway” if you want to while away some time). Aim your focus on getting the clinicians in the room to find their common ground.. the needs they both/all share. These common needs are invariably linked to the core generic processes in health and care, although this is often poorly understood by those in the room. On a related note, focus firstly on the shared clinical content that is required, but not the workflow or rules involved.  While consensus on clinical content can be gathered more easily (via openEHR archetyping for example), clinical workflow and clinical rules are generally less amenable to early consensus.

Tip #3

Q: Who should own this requirements & design process? The healthcare customer or IT supplier?
A: The healthcare customer, aka the clinical lead and core clinical team involved, supported by “in house” project management and technical architecture expertise.
In our experience there is a compelling case that the process of requirements analysis and the related design authority should be overseen/owned by the healthcare “customer”. This should ensure that these key aspects are guided by the clinical need, not by the supplier want.
We would go further to suggest that you aim to ensure the key clinical requirements captured in this process are opened up and widely shared. That could/should include both the visual mock-ups (e.g. JPGs etc) and clinical content specifications (e.g. openEHR archetyping helps again here) –  so that you have captured and kept these in a vendor neutral format for supplier engagement purposes, while other clinical colleagues can learn from, reuse and recycle this same material.
The natural extension of this thinking is to suggest an Alpha “Discovery” phase to bring early health IT requirements to life in an open source reference implementation. The potential benefits here are at least three fold, its serves as (1) method of engaging the healthcare change project team with proof of what can/cannot be easily done (2) a means of bridging the significant gap between local frontline health change agents and national health IT standards setters (3) a means towards a “bi-modal” health IT strategy – keeping your future options open/avoiding vendor lock in

Experience in Leeds has highlighted these 3 key tips in a real life setting while illustrating the nature of such change. What began life as the Leeds Clinical Portal project morphed over time into the Leeds Teaching Hospitals EPR platform (named Patient Pathway Manager +). That in time became the platform that has served/is serving the Leeds Care Record, an Electronic Health Record for the people of Leeds. That journey from portal to EPR to EHR was not about swapping technical artefacts in and out, it was about change in a complex environment. Change that was clinically led, user centred in design, agile and evolutionary in development. That journey continues today in the ethos.

So if you think you are in the market for an IDCR… think again.

Insight into a Person Held Record

Starting with the Public

Below is a news article from Joined Up Leeds, something we are very proud to be collaborating on. For anyone considering undertaking Person Held Record (PHR), whether developing or looking to implement, this should be of real use.

Joined Up Leeds

Background

Leeds has a vision to be the best city for health and wellbeing and to be a global leader for health innovation. Using and sharing information about citizens underpins this ambition yet there is often hesitancy around sharing information, even when this may lead to improved health outcomes and reduced health inequalities. Involving citizens in the discussion from the beginning is crucial.

Joined Up Leeds was developed as a two week period of conversations taking place across the city. Citizens discussed how their health and wellbeing data could and should be shared, the benefits of sharing, the concerns they have, and how information could be used for the benefit of people in Leeds. This report summarises the initial main findings.

Joined Up Leeds researches the desires for a Person Held Record

Leeds is also a leading city for data, with many different initiatives driving the way health and care information can be used for the benefits of people. The development of Person Held Record forms part of the city’s strategic direction, enabling people to better manage and plan their health and wellbeing.

The leaders in the city were keen to find out whether Leeds residents want a Person Held Record.  Leeds Informatics Board, in conjunction with Ripple, commissioned Brainbox Research, an independent research agency based in Leeds, to encourage people in the city to talk about having a Personal Health Record.  Questions were asked around how they would use it and how it might affect their health. Four themes evolved from the engagement with the eight focus groups:

  • Making it work for me – how a Person Held Record could encourage individuals to actively engage with it.
  • I control my information – individuals want to decide what to share and who to share it with.
  • How to reassure me – discussed concerns and extent to which the record would provide unique value or replicate services that are already in existence.
  • Potential impact – to increase the amount of control individuals feel over their own health and wellbeing.

The full report is available here to DOWNLOAD

 

What NextRipple_landscape_lo_14B4EB5

The results will be shared nationally and will be used by Ripple, a clinically led technical team hosted by Leeds City Council, to build an open source Person Held Record demonstrator that will be further tested by a small group of people in the city.  The Person Held Record demonstrator will initially be designed to include the “core information” that people highlighted, for example, NHS number, allergies, blood group.

Ripple Foundation

Ripple Foundation is also helping the adoption of an open integrated digital care record platform that is built for the future.  Open source refers to something that can be modified and shared because its design is publicly accessible, therefore the work done in Leeds can be adopted and then adapted for other areas across the country and beyond.  An integrated digital care platform allows health and social care workers involved in a person’s care access to the most up to date care information about that individual, no matter which digital system their organisation uses. The flexible nature of the open approach and technology can meet a wide range of other related needs, from small health and care departments up to regional care records.

Ripple Foundation is committed to working with others and wants to want to change health and social care for the better with the inclusive approach to learning, sharing outcomes and experience with a blend of open source technologies.   If you would like to learn more about Joined Up Leeds and the work that Ripple Foundation is undertaking, please email on info@ripple.foundation or tweet on @RippleOSI

Integrated Care & Digital Records – A Maturity Model

For everyone who is working to move healthcare into the 21st Century …. we are all on a change journey, made up of people + process + technology elements… which is particularly challenging when we aim towards integrated care. In the past I’ve looked in particular at the key patterns we see across technical elements required, explaining the key current options in fairly simple A/B/C terms.

Most people are not starting from a blank technical slate, rather their patch is often littered with (A) Myriad of Siloes. Some have already gone on a (B)est of Breed 1.0 Journey and others have gone down/are facing towards the (C)orporate/Conglomerate choice of proprietary monolithic technology systems.

Beyond these current constraints, the market is slowly but steadily shifting towards “Healthcare Best of Breed 2.0, the open platform that will transform 21st Century Healthcare”.  That platform can be described as made up of  5 key elements ;

1) Usability

2) Integration

3) Clinical Kernel

4) Community & Code

5) Leadership & Governance

I’d like to explain the approach that we suggest can support the effective union of these elements (1) clean and simple user interface design, (2) integration with existing/other systems and the path to the (3) clinical kernel oriented platform approach.

As part of our work towards this open platform push the key aspects of our chosen PulseTile UX/UI framework   – this framework follow key patterns in clinical process and information management, from business/clinical intelligence to multi-patient view to single patient view – all focused around a few key UI patterns.

ClinUiPpattern

Clinical UI Patterns- from ClinUiP.wordpress.com

We introduce our user interface with its north, south, east and west panels. We offer this open sourced UX/UI framework not as a perfect solution but one we find to be good enough for most/all the challenges we throw at it .. while we look forward to others offering improved alternatives.

Within this framework we can offer an approach that is akin to a bridge.. both to access to a wide range of existing/other systems as well as access to the open platform of the future. To emphasise, the essence of the approach here is to enable access to both legacy data in its varied formats and to more future proof architectural elements (e.g. openEHR for structured data and VNA for unstructured data) in a single User Interface framework. (See screenshots 3 & 4 below to illustrate this further).

We explain this framework along a stepwise progression or maturing of healthcare integration, towards integrated digital care records that are centred around the patient.


Level 0             No Sharing

We start the baseline here, with no patient information sharing between healthcare providers as for many  people sharing of data between systems is a real problem. It is worth noting that the challenges of interoperability in healthcare are increasingly acknowledged as a real barrier to improved healthcare.


Level 1             Sharing Via HTML (Presentation Only)

Maturity Model Level 1

 

This first level of integrated care within an Integrated Digital Care Record (IDCR) is a very simple level of access to data in today’s information age. Here the user is logged into the patient’s record and hoping to see information from more than 1 healthcare organisation. (for example,  professional based in Primary Care/GP, wanting access to patient information from the hospital… and/or vice versa).

Here we show the usual patient record, with the patient banner and a “tab” allows us to display data incoming from an outside source. The tab view access is analogous to accessing a regular website today, where the website provider chooses what information they want to share and how they want to present it. With this level of information sharing we accept whatever view we can from the information provider who shares it ( example selected here a Primary Care  organisation). This ability to view data from external systems is one of the key drivers behind the clinical portal market we see in healthcare today.

Of course access to such data is a breakthrough for many of us, though further processing of that data for purposes such as decision support, clinical/business intelligence etc is not possible. So it is a first, albeit limited step, better than no data, but certainly not adequate to support truly integrated care ( for example cross organisational pathways support etc).


Level 2             Sharing via Structured Data + Presentation Transformation

Maturity Model Level 2

 

This next level involves the sharing of structured data. For some time messaging between systems has been at the frontier of healthcare integration -referral messages for example Primary Care to Hospital and/or discharge messages  – Hospitals back to Primary Care) etc.

Data Messages  – in data formats such as HL7v2, XML, JSON etc –  allow for the “transformation” of that data so it can be presented in a variety of ways, especially to align with the receiving system. Here our centre pane displays the source/provenance of that incoming data (e.g. GP, Hospital) etc and we may apply stylesheet or other technology to align the data, so that it can be viewed under common record headings, for example Medications.

This data may be incoming as the result of a “push” mechanism (eg triggered messaging from an external system”) , or a “pull” mechanism (calling out to another system and getting that information back over an Application Programming Interface (API)). Again we see these as key features in the health integration engine and clinical portal market.

Note that at this level we explain that we are presenting this data momentarily “on the fly” i.e. without persisting the information in a local Clinical Data Repository.


Level 3             Sharing of Data + Presentation + Persistence

Maturity Model Level 3

To the end user this next level may look identical but under the hood there are further changes.

The data sharing is made available either as a result of the pull mechanism/API call mentioned earlier, or the result of a “push” mechanism whereby the originating system sends the information as an update to some form of trigger to the integrated digital care record.

The significant additional step here is that the data is now persisted in a local Clinical Data Repository (aka Integrated Digital Care Record Repository). The key issue here is the data model/standard and ownership. The vast majority of the CDR market is based on proprietary data models, so further access to/analysis or exchange of that data is dependent on the vendor involved.


Level 4             Sharing of Data + Present + Persist + Model

Maturity Model Level 4

After some time, if tackling decision support/business intelligence within an IDCR setting, the issue of data/information models invariably comes up. For these more sophisticated purposes though we may be digesting similar data from multiple source systems, we need to agree on a common data model to run computerised rules over the data.

Whether we want to support clinical decision support/business intelligence over patient information that is distributed (aka federated) or centralised, a common information model is key. All our experience in this field points to the openEHR specification, methodology and tooling as world leading in this area .

 

Clinical information modelling effort may be at “design time” rather than “run time” but it gives us a common semantic target which is necessary if we ever want to run local Clinical Decision Support over the combined data/information… be that distributed or centralised.  

Here our information modelling work on medications highlights that Medications for example:

Name – Aspirin

Numeric dose – 300g

Unit dose – mg

Frequency – once a day


Level 5             Sharing of Data + Present + Persist + Model + Reconcile

Maturity Model Level 5

The fifth step on this journey, is a reconciliation step whereby, after discussion between the people involved and a process is agreed, a decision to reconcile towards one entry may be possible.

For example -Aspirin prescription from both the GP and the Hospital having been modelled we note that they are representing the same medication, so a decision is made to reconcile this to one medication instance.

In reaching this point we draw attention to the fact that a patient-centred view of medication information has required the sharing of information from multiple organisational sources, the modelling of that information and the reconciliation of duplicate information. It should be noted that such an endpoint requires not only a solid information and technical architecture to make this possible, but requires people and process to collaborate beyond traditional boundaries…. in the patient’s best interest.  

 


An IDCR Maturity Model

We include a summary slide to explain the steps along this integration journey/IDCR maturity model.

Maturity Model Table

It is worth noting that the Ripple showcase stack (inc PulseTile UI framework) has been designed to cater for and support this journey (all IDCR Maturity Model Levels 0-5) towards integrated care.

  • The PulseTile UI/UX framework supports a simple yet effective approach to Usability, which encourages the user to explore existing information about the patient before new data is added.
  • The QEWD framework handles integration “out of the box” and does so in a way that caters for unstructured/structured data, from data that is available “on the fly” to data that is persisted locally.
  • In doing so it introduces clinical information that is modelled to the openEHR standard, the clinical kernel that is the firm foundation of the “21st Century Open Platform that will transform Healthcare“ and is supported by the EtherCIS Clinical Data Repository.

An IDCR Maturity Model in practice…

We now include a couple of screenshots to illustrate this model in practice

ScreenShot 1
Leeds Care Record Single Patient View
IDCR Maturity Level 1: 
Tabbed View- Primary Care – Information Sharing (View Only)  

LCR_SinglePatientView_Tab_level1

ScreenShot 2
PPM+ Single Patient View
IDCR Maturity Level 3:  Sharing of Data (from PAS) + Presentation + Persistence

ppmSinglePatientView_Level3


Screenshot 3
Ripple Foundation Showcase Stack Single Patient View
IDCR Maturity Level 2 – Sharing via Structured Data + Presentation Transformation

Screenshot 3

Screenshot 4
Ripple Foundation Showcase Stack Single Patient View
IDCR Maturity Level 4 – Sharing of Data + Present + Persist + Model

Screenshot 4

Please note in Screenshots 3 and 4, the Ripple showcase stack allows us to blend the IDCR maturity model in one approach.

With access to Level 2 existing/legacy data (e.g. Problem/Diagnosis: Hypertension – from VistA service shown in example) which in this case is read-only,

…while also allowing access to the Level 4 robust information models (e.g. Problem/Diagnosis: Lactose Intolerance – from openEHR service in example here) which we make editable.

Adding new data via the Create Button, launches a new modal which enters data against the Level 4 approach (i.e. openEHR service)


Acknowledgements

The model explained here is based on a simple yet effective model to information sharing that evolved during work on the Leeds Care Record. Thanks to Geoff Hall, for his help and support on the User Interface framework and to Richard Pugmire on the maturity model that underpins this approach.

We believe the principles here are widely applicable across healthcare which is why we are openly sharing this for wider discussion/learning.

Dr Tony Shannon

Director, Ripple Foundation

 

Opening up Healthcare IT – the right medicine

Much has been written about the impact that open source approaches to information and technology are having across the whole of society.  A new chapter, some of which is still being written, is emerging and challenging the way that individuals, communities, organisations and governments interact with each other.

Open data is enabling us to see the world in new ways as untapped patterns and systems emerge and these can be extremely powerful. In healthcare, the recent creation of Open Prescribing by Ben Goldacre and Anna Powell-Smith at the EBM Data Lab is a superb example of how using open data, anonymised GP prescribing data routinely published by NHS England, can be used to create a tool which could have a huge impact on prescribing patterns and spend.

Primary care prescribing spend totaled over £8 billion in 2013/2014.  Open Prescribing cost £50,000 to develop and yet, just a quick look round the site uncovers the huge potential for efficiency savings and better decision making.  The telling thing is that this data has been published for years, but it just took an innovative vision to collating, rendering and presenting the information to provide a real insight into prescribing decisions across England (this makes it sound easy but it was clearly somewhat more complex). Those behind Open Prescribing are hoping that the site will be used not only by commissioners and providers but also by individual patients, wishing to understand their own practice prescribing patterns in comparison with others.  Open data is enabling a change of the prescribing dynamic.

Here at the Ripple Programme we too want to change the dynamic of health and social care through the adoption of open source principles and methodologies.  These are allowing us to develop a range of templates, standards, APIs and user interfaces which are deliberately adaptable for use across any health and social care ecosystem.  And open source means that, unlike closed vendor dependent systems, there are no licence cost implications, no vendor tie in through lengthy contracts.

Ripple was initially established to support NHS Integration Pioneers in the development of their integrated digital care record programmes and we have deliberately taken a community approach, encouraging other pioneers to contribute to and shape our offers.

Open source is dependent upon sharing, it only flourishes because people are wanting to share their ideas and can see the value that expanding learning and ideas brings and for Ripple this is very important.  The programme is reliant on like minded developers, organisations and individuals who are able to see the mutual benefit of disrupting the healthcare IT market.  Iteration and improvement of the Ripple offers will not happen without this reciprocity.  The aim is for the organisations and localities who adopt the Ripple offer to be able to contribute to a mutually improved product – for their learning gained during implementation to feed straight back into the development so that future adoptees can also benefit.

Therefore, in a similar way to Open Prescribing, we are anticipating that a relatively small outlay to develop and invest in an integrated digital care record will unlock huge efficiency and resource savings across whole communities.

Why Open Source – a clinician’s view

As clinicians, we share a common purpose: to heal, to alleviate suffering and to comfort. In the 21st century, the explosion of knowledge has increased our armoury to achieve our aims. We share our discoveries freely and subject them to peer review, publish them in journals, print and online. We acknowledge one another’s contribution, build on it and share it back to the wider community. We rarely license or commercialise the way we work. That is the community and values that I grew up in as a doctor.

Then Health IT happened. I discovered a whole new world of license fees, non-disclosure agreements, patents and intellectual property. As a clinician in the NHS, this was all foreign to me. Something didn’t feel quite right about not being able to easily and freely share my new digital way of working with my colleagues.

I recognise that there is intellectual property in the development of software. Everyone who has ever used a well crafted smartphone app can attest to that. However, the issue that I have with software related to Health IT is that any software really has no value unless it is properly configured and designed alongside clinicians and frontline healthcare workers.

For example, clinical input is required for defining and designing data models, data sets, outcome indicators, clinical decision support logic, user interface elements and patient pathways. I want to be able to share this with my colleagues regardless of the IT system that they use. Currently, this is technically very difficult even if the vendor does not actively prevent us from doing so.

So at the moment, sharing of IT best practice is limited to organisations using the same system. Indeed many large vendors use this as a selling point. ‘Buy our system and become more like these internationally famous hospitals.’, they say. ‘You can use the things they built, see how they work! Join the club!’.

The clinical community does not work that way. We collaborate across organisations, across international borders and definitely across IT systems! We need a technological approach that supports this. This is why I’m so excited about Ripple. In using openEHR, Ripple supports a vendor and technology neutral way of defining health IT information models, the DNA of any electronic health record.

This is the same approach that we want to take with OpenCancer. We want to define the data models required to support cancer care and research in openEHR. Based on this, we also want to provide decision support based on openEHR. Continuing the theme of using open standards, we will also like to support exchange of patient pathways using open notation languages such as BPMN.

Clinicians and the community in which we work in immediately relate to the values of sharing and collaboration. It is time we used Health IT approaches that align with our values. Ripple, together with similarly minded organisations like the openEHR foundation, openEyes foundation, open mHealth are showing us the way. OpenCancer will inevitably join the fold.

These are exciting times!

 

Dr Wai Keong Wong, UCLH, London, November 2015

We want Open Source to spread by Dylan Roberts

The article below was published on the Local Digital website on 23 September 2015

Ripple provides integration support

The article below was published by DigitalHealth.net on 18 September 2015.

Healthcare Driven by Open Source Software

We want to encourage debate and discussion about Open Source and will repost and attribute articles whenever we can.  We would also like to encourage guest bloggers and commentators.   The article below has been co written by Source Code Control Limited and Protecode.

Our thanks go to Martin Callinan for bringing it to our attention.

 


From relieving people of repetitive tasks, to building everything around us that shapes our lifestyle, and on to transformation of volumes of data into new insights and perspectives, software has become the new feedstock for the human evolution. All facets of life are touched by software, and healthcarei s no exemption.

The Complex Web of Health Industry

The health and social care industry is a highly fragmented and complex industry with medical practitioners, nurses, health professionals, hospitals, clinics, government and non-government agencies all providing health services.
The spectrum of health care providers range from individual clinicians such as General Practitioners (also known as GP or doctor) to large monolithic entities such as the National Health Service in the UK which is the third largest employer in the world today.

Health and social care providers offer a complex and diverse range of facilities and services. By the nature of these services the healthcare industry is driven by large and varied amounts of data which in turn require varied and complex IT systems to manage this data. Generally, these systems come under the umbrella term of eHealth. While there is no consensus on the exact definition of eHealth two example definitions are:

“…the cost-effective and secure use of information and communication technologies in support of the health and health-related fields including healthcare, health surveillance and health education, knowledge and research.” The World Health Organization (WHO)

“…the use of modern information and communication technologies to meet needs of citizens, patients,
healthcare professionals, healthcare providers, as well as policy makers.” The European Commission

Whatever way people choose to define eHealth it generally encompasses:

 

  • Electronic Health Records (EHR)
  • Electronic Medical Records (EMR)
  • Telehealth and telemedicine
  • Health IT systems
  • Consumer health IT data
  • Virtual healthcare
  • Mobile Health (mHealth)
  • Big data systems used in digital health

eHealth Software Complexity

Software complexity is increasing with no end in sight as today’s code becomes the foundation for tomorrow’s more complex functionality. Historically, healthcare organisations have created platforms to manage these solutions fairly autonomously, both within individual organisations and industry wide. Quite often these systems were procured at significant expense from software vendors who lock them into solutions that restrict innovation, stifle diversity and have little ability to be re-used.

In the past, developing all software internally was a point of pride for many organizations. Today, the complexity of modern software, coupled with the pressures to release applications and products on tight deadlines, has made delivering projects that rely exclusively on internal code development almost impossible. Increasingly, organizations are turning to commercial third party code, code brought in from outsourcers and contractors, and open source software (OSS) to accelerate development and reduce costs.

If this approach is compared to other industries such as the automotive industry where in the early days of car manufacturing car models were largely custom made. In more recent times, automotive manufacturers have developed “platforms”, commonly re-used across companies and continents. This gives them the ability to re-use existing components and enables greater flexibility – a new model is no longer a completely new design and as a result costs are significantly reduced.

The same approach is now being applied to eHealth systems and with the emergence of Open Source Software there is a shift to adopt Open Systems, Open Platforms and Open Data. These solutions are developed efficiently without licence restriction where the code can be shared and re-used across the public and private healthcare industry.

Code4Health

A great example of this repurposing is an initiative launched recently by NHS England called Code4Health.

Code4Health is a resource used by healthcare professionals and providers of services to deliver better patient outcomes. It provides a platform for clinicians to come together with IT suppliers to identify and experiment with the systems in their Trusts and develop new functionality and products or solutions that they can potentially deploy.

“Our ambition for Code4Health is to educate clinical and administrative staff to develop their interest in digital technology and stimulate a desire to engage more closely in the design, development and delivery of systems and apps”.

Code4Health are currently piloting ‘App In a Day’ where individual clinicians are being trained and encouraged to play an active role in the development of apps or even develop their own apps using LiveCode.

Over time, the goal of the NHS is to:

  • Create a market of viable Open Source solutions
  • Provide evidence of the value of Open Source software to the wider Health and Social Care Community
  • Ensure by default all code created in the NHS is shared as part of a library of assets for re-use
  • Ensure a level playing field for Open Source commodity and infrastructure services
  • Achieve a self-sustaining eco-system of communities

Managing Open Source and Other Third Party Content

Clearly there are huge benefits to be gained from this approach but it is not without its risks. Along with the advantages realized by using third party code, there are a few challenges that can arise. Governing the quality, security, licensing and intellectual property (IP) ownership attributes are imperative in avoiding risks and potential downstream costs of using third party software. Last year Community Health Systems Inc. lost data related to 5.4 million patients which could end up costing the health system between $75 and $150 million. This data breach leveraged the bug Heartbleed to access VPH log-in credentials.

The process of managing third party content in a code base can be time-consuming and resource intensive, and an understanding of the effort associated with this exercise is the first step in optimizing the process and mitigating the costs. This highlights a need for a governance program to underpin Open Source initiatives. Indeed the NHS have created a custodian model for Code4Health and will have “code custodians” to manage the risks of OSS and make the adoption of OSS based solutions easier for less technically proficient trusts.

A study of common practices deployed at software organizations, concerning adoption of open source and other third party software components, has revealed a pattern consisting of a number of necessary as well as some discretionary steps. Originally coined as Open Source Software Adoption Process (OSSAP), this process is equally applicable to any third party software that is deployed and used in a project within any organization. Eight steps are identified in a structured open source adoption process.

  1. Establishing a software policy, identifying acceptable attributes of a third party software, and highlighting remedial actions that should be taken in case of a violation of the policy. Typically, an “open source committee” consisting of legal, technology, security and business stakeholders are responsible for establishing and communicating the policy.
  2. An optional software package pre-approval workflow process that allows technology teams to request open source and other external packages to be approved for use on a certain project under certain use-case scenarios. The package-preapproval process would allow the “software clearing house” in an organization to open and assess the requests and grant or deny permission depending on how well the requested package aligns with the policies established in step 1.
  3. Establishing a baseline, or taking stock of the existing code in the organization. This is a necessary step in all but the simplest cases and is performed using automated tools creating a detailed view of the code that is already present in the software organization. This will produce a resulting map of proprietary, commercial or open source components and their licensing, security, quality and supplier attributes. Furthermore, the results obtained at the conclusion of this step are compared against the established policies and components and can be blacklisted/whitelisted as a result for future projects.
  4. Assessment of all code delivered to the project by contractors and outsourcing suppliers against the policies using automated tools, and extending the software inventory map that was established during the baselining process of step 3.
  5. Regular scanning and examination of the project code library. This can be done by scripting an automated policy-based scanner to review the complete library for any changes at regular intervals, for example, every weekend, and highlighting content that violates a policy component.
  6. Optional real-time assessment of code as it is checked into the organization’s Source Control Management (SCM) system against the policies, and taking appropriate action if a violation is detected. This step ensures that the project repository contains only acceptable code.
  7. An optional real-time automated scanner residing on the developer’s workstation. Similar to a virus checker, the content that is downloaded from the web, brought in through, for example from a USB memory card or simply assembled on the developer’s workstation is continually scanned against the project policies. Any violations against the policy can be highlighted to the developer (and the developer only), allowing for either quick remedy at the source or a comment to be inserted against the offending code (e.g. “will be used for testing only”).
  8. Final build assessment, usually through an automated process tied into the build (for example
    Jenkins) process.

The purpose of steps 2-7 is that all the code that could potentially end up in a project is logged and approved in that it satisfies the project IP, security and exportability policies. By the time the final application is built at step 8, there will be no surprises if steps 2-7 are diligently followed.

Conclusion

There is a significant opportunity to advance the caliber of healthcare by applying intelligent software solutions to electronic health records, delivery of consumer health information, and the provision of mobile and virtual health services. Leveraging open source software and drawing on the associated groups accelerates the identification and development of healthcare applications, creates a level playing field for all ecosystem communities, and allows the sharing and re-use of efforts across a wide range of healthcare domains and geographies. The distributed and crowd-based nature of the open source development can be managed by applying a structured open source software adoption process that will ensure quality, security and legal compliance to the re-use obligations inherent in any open source code.

Download this article as a PDF

 

List Of Additional Resources

Open Source Software Adoption Process (OSSAP) | Best practices that enable organizations to effectively leverage open source software in their projects.
Infographic, Measuring Open Source Management ROI | As open source adoption becomes mainstream, open source compliance management is maturing. Organizations are moving away from manual code audits to real time, automated open source scanning tools.
Ensuring Responsible Open Source Use with Software Audits | This paper explains how organizations can responsibly adopt and manage open source software in order to remain innovative and competitive.

 

Change story number 3: Story of Now

The word ‘opportunity’ is defined as ‘a time or set of circumstances that makes it possible to do something’ which help to introduce our story of now.

As one of 25 Integration Pioneers, we have been given the opportunity to blaze the trail for change and new ways of working to support Health and Social care. With our successful bid to NHS England’s Integrated Digital Care Fund (IDCF), as mentioned in  our earlier story (the story of us), we have been given the opportunity to work with and support Integration Pioneers and the wider community on their own journeys towards integrated digital care records.

Across health and social care organisations, the top priority is to provide the very best care for people, to improve their care outcomes and ultimately to improve the lives people lead. We recognise that to do so we need to support the practitioners working across health and social care by giving them better information and better tools in order for them to provide the very best care.

Integrated digital care records therefore play an important role in the drive towards improving care. They bring together information from various care settings to provide a more joined up view of a person’s care. Without, there is a disconnect in care journeys as the information doesn’t flow between care settings, causing delays, inefficiencies and potentially impacting the care provided. With this technology change begins as people and process evolve to truly deliver integrated and thereby improved care.

The 25 Integration Pioneers on this journey recognise the need for integrated digital care records, as an important part in this change equation, allowing staff to work smarter to provide improved sustainable care in their respective cities and regions.  Each are at different stages on this road, some just starting out and some well on their way.

There are two common patterns appearing in the early work we have undertaken with Integration Pioneers in this area;

  1. the disconnect between the pressing need for change and the maturity and capability of care systems to meet these demands
  2. as pioneers, we are each doing our own thing, ploughing our own unique path and potentially encountering the same problems, when actually we all have the same core need – we need to work together

An open, collaborative and joined up approach is needed in the journey towards integrated digital care records. As Integration Pioneers an open approach allows us to act together, tackling the problems and learning once and sharing with all so everyone can benefit.

We have begun the Ripple community effort to support this approach. Key to that community effort, our experience has shown that there are six core components needed to support the delivery of an integrated digital care record system, explained here along two key themes outlined below:

Foundations

Open Requirements – Working with Integration Pioneers, we will identify the common requirements and capabilities needed for an integrated care record, along with their associated benefits. The identified aspects will be shared with all Integration Pioneers to save time and effort and to provide a consistent strategic direction to the community.

Open Governance – we will work with Integration Pioneers to standardise the governance arrangements for the sharing of information across care settings. At the moment this is seen as a real barrier to progress. Working with Integration Pioneers and with the support of NHS England we will provide standard governance templates and guidance to ensure the right arrangements are available and shared across the Pioneers and this emerging community across England.

Open Citizen – we will work with other Integration Pioneers on citizen engagement in sharing care information. It is essential to build trust as well as talking about care records openly, communicating widely and clearly. Working with Integration Pioneers and their respective communities, we will provide the common information and core tools  needed to support engagement in and communication of care record initiatives. In addition to this we will undertaken citizen engagement with the Integration Pioneers around the needs and requirements of a personal health record (citizen access to an integrated care record) and other key healthcare apps as a demonstration of this community effort in action.

Open source platform

Open Viewer – based on the Open Requirements identified by pioneers we will develop and deliver regular enhancements for an open source viewer for the community to use. As ease of use is critical at the front line of care, we will be working towards an Open Source care record viewer that makes the navigation around care records intuitive.

Open Integration –  In between the viewing and the storage aspects of any platform is an important element of bringing information together from the various systems Pioneers currently work with. To meet this need, we will be providing an Open Source Integration Engine which will be connected to those core systems that emerge from the Integration Pioneer analysis delivered by a series of related Open Application Programme Interfaces (Open APIs) to the community.

Open Architecture – Our learning to date has shown that many clinical groups require similar elements of clinical content, although they use them in slightly different ways to meet their own local need.  The current market offers a huge number of applications to accommodate this however these are very difficult to integrate. To move away from this approach and into the 21st century we need a more adaptive, modular, building block approach that allows the community to collaborate. Working with the pioneers we will provide a collaborative forum to develop these key building blocks, in line with international best practice, known as openEHR. With this in mind, we are working towards an open source storage mechanism to support this approach.

 

Why open source?

We believe Open Source and Open Standards are key to innovation and an alternative to traditional ways of purchasing systems from software suppliers.  Open source is owned by the Integration Pioneers and related community, though it can be reused by others across the health and care community.

We see the key features of an open source approach to Healthcare IT as;

  • Unconstrained Innovation – Ideas and ambitions can be shared by collaborators who work in different ways, in different organisations, different communities and different skills and experiences, including those not directly employed in healthcare IT
  • Transparent credibility – Allowing immediate detailed scrutiny immediately boosts credibility within the community
  • Decentralized control – amendments and improvement come from the community, bottom up

Based upon the findings from the initial survey issued we are now formulating programme plan around these six strands, aiming to deliver a release to the community every two months for the first 12 months of the programme. All the deliverables will be made available in the public domain under a recognised open licence.

Now is the opportunity to deliver a real change to care in the 21st century, to remove the barriers to progressing and to give the practitioners the tools they need to deliver more joined up care.

Ripple has begun, the community effort has started.

Hands up if you’re in!


 

Change story number 2: Story of Us

Integration Pioneers in the 21st Century

There is a widely held view that 21st century care is under pressure, in a state of near-crisis in many places (ref #NHSwinter) where the burden of disease and the limitations of current health and social care systems are becoming ever more apparent.  We know that at the frontline, staff are already working under immense pressure, in unsustainable ways and that change is needed. We must find ways to “work smarter, not harder”.  So we must also find ways to improve the quality, safety, timeliness and cost effectiveness of 21st century care.

Of course,  the change that 21st century care needs will require strong leadership and changes in the way staff work at the coalface, and one question that presents itself is around the role of technology and specifically information technology.

Health and care commentators are, for the most part, all agreed that Information Technology is a key driver for change, while many are also aware that its great potential remains untapped. The gap between the hope and the reality of the promise of improving care via effective IT remains one of the key challenges facing us today.

In exploring this challenge, there is a view that the health and care IT market is not as good as it could be, lacking leadership and a mixed bag of technologies on offer with vendor lock-in a real issue.

Quite often it is still too hard to;

  • share citizen and patient information between providers and across city and district boundaries
  • adapt care pathways in a way that combines Lean thinking with a flexible information system
  • support the audit of care and research which for the most part is done by duplicating effort with cumbersome “back-room” processes.

It would be hard to contest the fact that the current state of the health IT market is holding us all back from the advances that 21st Century health and social care demands.

So is there an alternative path?

Leeds is one of 25 integration pioneers chosen to lead the way on the integration of health and social care through; new ways of working for staff, process redesign and integrated digital care records. Many are at early stages for this work but all with the same focus to improve care and work smarter.

Leeds, as part of an effort to positively disrupt the market, has ploughed its own pioneering path in this field via a mix of open source and open standards to underpin the Leeds PPM+ platform which now powers the Leeds Care Record. Great progress continues to be made on both fronts and positive feedback from both users and citizens alike is emerging, but Leeds believes it would benefit by contributing to and working with a broader community.

Recognising this need for change, to collaborate and to support integration pioneers, Leeds City Council on behalf of the city and with the support of the integration pioneers submitted a successful bid for the second phase of NHS England’s Integrated Digital Care Technology Fund. With the clinical leadership of Dr Tony Shannon, we are now reaching out to work with those 24 other integration pioneers who want to be part of Ripple community which is focussed along 6 open strands:

  1. Open Requirements
  2. Open Governance
  3. Open Citizen
  4. Open Viewer
  5. Open Integration
  6. Open Architecture

We hope that in sharing our challenges, our learning and our efforts, we can kickstart a real health and social care community effort. We are keen to collaborate with all others who recognise this story and share this vision, who choose to take this path together.