Ripple Foundation’s showcase stack encompassing three open source elements – front end UX/UI framework, middleware and backend/data repository.  Each component harnesses the power of open source and aims to demonstrate open standards in action to show that there is a different way to provide technology to our care professionals and patients.

Ripple Foundation was established in 2016 to support the adoption of an open health and care platform internationally.  As part of its mission, the team has supported the development of a leading edge UX/UI framework which they’ve recently launched called PulseTile. The clinically led team has also been reviewing complementary products and components that meet the increasing demands of the modern day health and care system.  They are proud to support and promote the incredible versatility of both the middleware – JSON API oriented QewdJS framework led by Rob Tweed of MGateway Ltd, plus the openEHR compliant backend of EtherCIS led by Christian Chevalley of ADOC Software Development.   

Dr Tony Shannon, Director of Ripple Foundation said, “We are promoting Ripple Foundation’s showcase stack to demonstrate how health IT can be done in the complex and highly pressurised health and care system.  For years care professionals have had to put up with inadequate, antiquated clinical systems and we believe this showcase stack shows what can be applied to any health and care setting to help provide a better solution for both the clinical requirements but also the business needs of health and care technology.  Information and data that you can access, store and exchange securely is an option if you adopt an open source, open standards underpinned by open architecture approach.

“I’m calling out to the health and care community to take a look at our showcase stack and have a play with what’s now openly available to reuse.  At Ripple Foundation we are here to support you and can answer any questions you may have and help to move health IT into the 21st Century.  

Tony continued, “We are also appealing for an open digital platform challenge fund that we have called #1percentfund.  Diverting 1% of available healthcare IT funds to an open digital challenge fund we believe could improve the care of 99% of the population by stimulating and supporting both the creation and adoption of an open digital ecosystem internationally.  We hope this Open Platform Challenge Fund could help any interested clinical and technical leaders out there to implement a different approach to issues we are facing.”

It is clear that Health IT is not good enough to support 21st Century care, Ripple Foundation believe their showcase stack components, used separately or in combination will help to meet the needs of clinical systems that are easy to use but also communicate and interoperate using open source and open standards.

The showcase stack can be explored from the Ripple Foundation website, including full “showcase stack” documentation.

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)

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

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

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

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

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.

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](http://frectal.com/2014/06/30/21stc-healthcare-open-platform)“ 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 4
Ripple Foundation Showcase Stack Single Patient View
IDCR Maturity Level 4 – Sharing of Data + Present + Persist + Model

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