We like pictures

We know the power of videos

Please check out our youtube playlist.

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 and a migration path from the old proprietary world towards an open platform .. via (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.


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/longitudinal 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 (including healthcare Documents as HTML/CDA etc) 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 (eg FHIR) etc –  allow for the “transformation” of that data so it can be shared and 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 Structured 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 (eg FHIR based API) 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 process to normalise the data towards 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 (aka deduplicate the 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)  


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


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)


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

The NHS has long recognised the importance and value of patient and citizen engagement and there are many networks and systems to enable patients to provide input into service and programme delivery.

What the NHS could do better at is co-ordinating that patient involvement, co-ordinating activity so that patients and citizens are not asked the same or similar things by different health and social care organisations at the same time but through different engagement processes.

Our Open Citizen module attempts to address this co-ordination in respect of communication and engagement activities around Integrated Digital Care Record development.

We have already held an engagement workshop with the NHS England Patient Online group and the findings from this will help to shape how we undertake further events but also how the patient held record element of our OpenEHR (Electronic Health Record) could look and feel.

The sharing of information and learning between integration pioneers is part out our community approach.  As the Ripple Programme is hosted by Leeds City Council and working with the CCGs and the hospital in the City, we would like to take this opportunity to share the work of the Leeds Care Record.

The Leeds Care Record was commissioned by the three clinical commissioning groups in Leeds and developed by the Leeds Teaching Hospitals Trust built on their PPM+ patient information system.  Before, during and after the launch of Leeds Care Record, the project team undertook broad and intensive engagement with both patients and clinical staff and they have agreed that Ripple can adapt and “white label” the communication and engagement material for the integration pioneers (and others) to use.

The resources below have been released under the creative commons licence 4.0 and currently include Ripple branding and graphics that have been created from open source sources (if that isn’t tautology).  It is recognised that organisations and localities may wish to adapt and add their own branding but in essence, they are good to go.

As with all the resources we are developing – both technical and non technical – we would like your feedback.  If you have any documents or case studies that you would like others to be able to re-use or perhaps detail of when you have used the resources available through Ripple, we would like to hear from you.


Ripple has been established on the basis that in the early part of the 21st century, those delivering care are under pressure. That pressure to change and improve services, allied to the increased financial constraints we are living through, means we need to consider collaboration towards a common cause as never before.

We believe that most care providers have more common needs they share, than features they differ on, so to that end we are working towards tackling key common challenges with solutions that can be easily shared.

Ripple is particularly set up to offer a modular approach to the 21st century care delivery based around six key modules that facilitate the setup and delivery of an Integrated Digital Care Record (IDCR);

Three foundation modules Three technical modules for a care record platform
Open Requirements Open Viewer
Open Governance Open Integration
Open Citizen Open Architecture

Our explainer video goes into a bit more detail on these.

As part of the Open Requirements module of the programme, we have wanted to outline those common requirements seen across all those who are pioneering the delivery of 21st century care. In addition we wanted to develop a related template business case to support organisations in their own local IDCR journey.

Here we are releasing this business case template for reuse and review (available within Google Docs (for ease of copying and commenting).

As with all our work, we welcome feedback and suggested improvements as part of the Ripple community approach to tackling common needs.

Please click here to explore this work further;


Special thanks to Dr Michael Bewell of NHS England’s Interoperability team and those organisations that contributed to this analysis.

As we move Health and Social Care into the 21st Century, the need to improve care underpinned by better information sharing is paramount. For many health and social care professionals, efforts around “information sharing” have become a real challenge. Central to this has been the growing confusion about good practice in information governance, particularly when it comes to information sharing.  Our experience is that even the language has become so overly complicated that is has become a barrier to progress in its own right.

We wanted to delve deep into what is at issue here, looking for some patterns to make this area a whole lot simpler, in essence a Plain English guide to Information Sharing. We first published an article on this back in May and through feedback and further collaboration, matured the guide as detailed below.

To explain our Plain English guide to Information Sharing, we wanted to try a Who, Where, What, Why, When and How approach. Please click on the boxes to explore this further.

We have also developed a diagram to explain information sharing in a visual form.  We have made this diagram more relevant by emboldening the terms and phrases it contains where they appear in the explaining text.


Following on from this work we have developed a series of information governance templates and additional material which can be found on our documentation pages.

WHO is involved in the information sharing

  • An individual person who, in times of need seeks help from a health or social care professional.
  • Health and social care professionals  – usually begins with a one-to-one doctor/patient consultation and extends to include care professionals from different services or organisations who form a team responsible for   co-ordinating care and treatment depending on what that patient needs. For example:
    • GP’s and other clinical support staff
    • specialist doctors such as a hospital consultant
    • nurses and midwives
    • physio and other therapists
    • radiology and laboratory staff processing test results
    • pharmacists
    • social care staff

“Who” can also include:

  • staff involved in the management of health and social care services including  administrative staff who book appointments, make sure paper records or other relevant information is available at the point of care, write letters, greet people at clinics, receive telephone calls and other supporting tasks.
  • The academic sector who conduct research studies in pursuit of new or improved remedies and treatment.
  • Public Health England or more local public health services that protect the public from infectious diseases and other hazards to health and also undertake other activities to improve the public’s health and wellbeing.
  • Health screening services offered by NHS England which are designed to detect health problems early.
  • Organisations such as NHS Commissioning Support Units who provide support and information to ensure that Clinical Commissioning Groups and local authorities are able to buy, contract and monitor services effectively.

Whoever is using information about a person, they are bound by laws, contracts and professional codes of conduct to use it responsibly and keep it confidential.

WHY is information shared

  • to support the direct care of the patient (e.g. a patient attending their GP or local Emergency Department, or are being cared for by a team of district nurses or a wider team of various health and social care professionals). This is called the primary use of information.


  • to assess the quality and safety of care being provided or for management purposes, for example to identify growing needs across an area or analyse the cost of services or ways in which they can be improved. This happens after the information has been anonymised. This is the secondary or indirect care use of that information.  The information is also used to inform commissioning decisions – decisions based upon facts and statistics which are used to determine where services need to be delivered and who they need to be delivered to.  This ensures that resources are focussed in the right areas and helps health and social care deliver more efficient and effective services.

WHEN is information shared

  • Information about a person is shared when health and social care professionals need it to provide safe care of the highest quality.
  • By law GPs have to share information with Public Health England when a patient with a “notifiable disease” is identified.  This helps to control the spread of infection and protects the public.
  • Information is also shared when it is necessary to protect a child or vulnerable adult from harm.
  • Information is only shared when it is fair and lawful to do so.  There are legal and ethical rules of confidentiality and privacy which mean that an individual’s rights have to be respected.

HOW is information shared

All health and social care organisations must use personal confidential data within the legal framework. These organisations are responsible for ensuring that they have good information governance practices in place and have trained their staff so that information is appropriately managed and individual’s rights are respected.

These organisations operate with “fair processing” principles. This is where the health and care organisations involved communicate as widely as they reasonably can to tell people that their personal information will be shared between professionals when it is “fair and lawful” to do so.

To support the joining up of services, information needs to be shared more widely to improve care, therefore in the majority of cases, consent to information sharing is simply implied so people can do their jobs as effectively as possible.

Sometimes people have concerns about what information is being shared and who with and and may want to limit or stop it from being shared.

If concerns are raised, patients will be made aware of who to contact to discuss information sharing and how they can opt in or opt out.  Patient choices will be respected and all efforts will be undertaken to respect these wishes. Unless informed otherwise, the general stance is that people are happy for their information to be shared.

Confidential information that can identify a person is not usually shared with others who are not members of the health and care team providing care. De-identified information is used instead. Sometimes, in limited circumstances, it may be necessary to share identifiable information for purposes other than direct care.  In these cases the individual will be asked for their permission to share their personal data.

If a health or social care professional makes a verbal or written request for information sharing (often known as explicit consent) then the person they are asking can either agree to supply that information (which is by far the most common response) or deny the information sharing request (which happens only rarely, but is technically explained as a denial or objection to share information).

Sometimes, if a professional thinks it is in the person’s best interest, they can override asking for permission to access the information,  for example where a patient has impaired mental capacity.  Such action is monitored carefully and is  known as “breaking the glass”.

There are also times when a professional can override a person’s choice to deny a request to share information. This can only be done when the law says information must be shared, such as notification of infectious diseases to Public Health England or when safeguarding issues are identified.

How information will be supplied depends on what information is required, what technology is available in the care settings and how systems are able to integrate.

In fairly simple technical terms information is shared by either a push (e.g. GP letter to the Hospital Diabetic team) or pull mechanism (e.g. Emergency Department seeks your GP summary information in an Emergency), though in practice a mix of approaches is often used.

WHAT type of information is being shared

People cannot be treated or cared for safely if health and social care professionals do not have access to information about them.

Information is always involved when a patient seeks help from a health or social care professional. Now, particularly as care is provided by larger teams spread across organisations and different areas, the need to share information becomes essential.

The amount of personal information that needs to be shared to support care can be a whole care record (e.g. if patients are moving from one GP to another), but more usually it involves relevant information about current care needs contained in a single document, multiple documents or a computer record, which is shared between different parts of the care team.

Some information might be particularly personal sensitive information (e.g. HIV status, sexual health) and may not be suitable to share routinely. Sharing any confidential information is strictly controlled. Any sharing of this type of information is very restricted and only anonymous service providers – those few who are providing care and treatment for that condition –  can see it after permission has been given.

In certain circumstances information may be pseudonymised. This process replaces personal details with a computer generated code so that identity is not apparent to those using the information. Information can also be fully anonymised, where all the identifiable information is removed, leaving information that cannot be linked back to an individual. This is added to other anonymised information to become statistics, which are shared and analysed locally so that organisations can measure how services are being used and how they are performing. This also helps with planning future service delivery.

This anonymised information is also shared with other organisations e.g. the total number of Diabetic patients in a given area is shared with the Department of Health so that funding can be allocated according to need.

WHERE information is shared

By where, we mean the location where the person sees a health or social care professional. For example:

Providers of care

  • Primary care – e.g GPs, practice staff and some community services
  • Community Care – e.g. at home, a community hospital, care home or hospice
  • Secondary Care – e.g. hospital appointment or admission, or Emergency Department
  • Tertiary care  – also known as specialist care and can sometimes be provided in a hospital that is not in your local area
  • Mental health service provider.
  • Some voluntary or community support settings which are also known as the third sector

Commissioners of care

Commissioning is the process of specifying, contracting and monitoring services to meet people’s needs

  • GP led Clinical Commissioning Groups (CCGs) who are responsible for organising and managing local health services
  • Commissioning Support Units (CSUs) who can assist CCGs with their commissioning objectives
  • regional branches of the Health and Social Care Information Centre (HSCIC) who are known as Data Services for Commissioners Regional Offices (DSCRO) who provide operational support to the CGGs
  • Local Authorities who are responsible for social care and Public Health.


Research is the studying and and investigation of information to establish facts and reach new conclusions

  • Research into illnesses such as cancer and dementia mean that information is sometimes shared with the academic sector to explore new treatments and approaches to conditions.

The information sharing model set out in the diagram below maps out the who, what, where, when, how and why of information sharing and looks at the settings and the uses of information in health and social care. To view the diagram in more detail and zoom in and out, simply right hand click anywhere on the graphic.


In summary

The safe, secure and legitimate handling of patient information is at the very core of health and social care.  Access to information at the right time, the right place and with the right health and social care setting means that patients are treated more safely and effectively.  Without information being shared this would not be possible.  It is the responsibility of organisations to handle confidential information according to legislation and to be able to explain to individuals how their information is being used.  These individuals have the right to opt out of sharing their information should they wish to do so.  There are rare occasions, such as the wider public safety or individual safeguarding issues where this opting out can be overridden but at all times and on all occasions, this has to be explained to the individual concerned.

Information sharing is everyone’s business but the information that is shared is not!

We would like to thank the following people for collaborating on this work and we hope this helps towards demystifying information sharing.

Joseph Waller –  Director, XML Solutions

Phil Barrett – Programme Manager, Ripple Foundation

Dr. Tony Shannon –  Director, Ripple Foundation

Deborah Terry –  Information Governance Specialist, Information Governance Solutions

Graham Prestwich – Lay Member- Patient and Public Involvement, NHS Leeds North Clinical Commissioning Group

Sue Watson – Patient Representative


Appendix: Open Source Information Sharing Materials

Ripple-Plain-English-IG-Guide-July-2015 (1)

Ripple Plain English DPC Template (1)
Ripple Plain English ISATemplate v1.0 290715

IDCR Communications toolkit for participating organisations template (1)
IDCR Communications toolkit for participating organisations template (2)

Reference: Information Sharing Mindmap on Coggle.it