PulseTile UX

I’ve been exploring the PulseTile demo http://showcase.ripple.foundation/#/charts

Is the angularJS app using openEHR to talk to the server? For example when I look at a specific Allergy I get this back - this isn’t openEHR is it?

{“cause”:“allergy to animal hair”,“causeCode”:“3.00911008E8”,“causeTerminology”:“SNOMED-CT”,“terminologyCode”:“3.00911008E8”,“reaction”:“sneezing”,“author”:“Dr Joyce Smith”,“dateCreated”:1510330665000,“source”:“ethercis”,“sourceId”:“39be9445-9f3c-492d-adff-fd9e472edd7f”,“originalComposition”:"",“originalSource”:""}

Hi Kevin,

This is the Ripple API which maps very closely to the Ripple UI but is mapped under the hood to openEHR. All of the clinical data in Ripple is held in openEHR, either in the Marand Think!Ehr CDR or EtherCis CDR - same API , same data formats, same queries.


You can see the underlying openEHR data and query descriptions here

Thanks, I’ll be using those links again.

Suspect this is highlighting a difference between FHIR and openEHR, the UI is not using openEHR where I would have expected to see FHIR (between an App and a system). The reverse is also true (on the FHIR systems I’ve worked on), FHIR doesn’t tend to be used where openEHR is being used employed.
In other words this FHIR demonstrator http://yellow.testlab.nhs.uk/careconnect-ri/
isn’t FHIR beyond the API, it’s just a SQL database (or system).

In the Ripple stack, the mapping between the PulseTile Ui and the EtherCIS openEHR backend is handled in the node.js-based Qewd middleware layer. It handles forming the AQL queries for getting entries out of the openEHR CDR, and also creates the flat JSON payloads which are used for POSTing to the openEHR CDR.

I’m still learning about it but I’ve invited Rob Tweed, the author of Qewd-Ripple, to this thread to clarify further.

thanks @mayfield.g.kev,

Good question…

To explain what is going on here…
We (in the Ripple Foundation) have crafted/are supporting 3 key open source tools/frameworks

Each of these have been designed/developed and work independently but we’ve also brought them to work seamlessly together as part of our open source “showcase stack”, which is pulled together by a library known as Ripple-QEWD/QEWD-Ripple http://docs-showcase.ripple.foundation/qewd-ripple-explained.html
See recent showcase screencast here

They exist independently as we known healthcare organisations have a variety of needs/wants… while we recommend the stack is used as a whole, we know that several organisations don’t want/need to make that move in one go and/or would just rather use one/two of these tools.

So the background to the PulseTile UI framework you’re looking at is a user centred design/development programme that drove that development.
The PulseTile UI JSON that is uses is driven by the users needs… can be modified of course… is modular anyway, as per our core/plugin tile approach.
We believe there is a need for a robust UX/UI framework in healthcare that can be reused for many purposes, which needs to be able to handle data from a variety of sources (Simple SQL based, FHIR based, openEHR based, etc) … see our IDCR “maturity model” below…

The QEWD framework acts as a middleware/integration layer that we see as a common/universal need in a healthcare stack and it can handle data in/out of the stack as needs be… leveraging technology that wants to move data as JSON, XML, HL7v2, ODBC etc etc…
There are other middleware options of course but in our case QEWD-Ripple is handling the movement of data between PulseTile and EtherCIS in a very lightweight and efficient way, via a simple JSON mapping process.
See the QEWD-Ripple swagger set that the PulseTile UI framework sits on.

As part of this development we are also working to support FHIR in our work and we’ve already done some work on mapping PulseTile JSON to FHIR JSON as you can see here…

Ian is also working on FHIR to openEHR mapping which we are also under development as we speak.

The EtherCIS framework has been chosen as our Clinical Data Repository as we choose to persist our healthcare data to the openEHR standard… we recommend it as a leading vendor & tech neutral approach but of course realise that others will choose other approaches to persistence.

You may be interested in a maturity model we’ve developed which we find helpful in understanding the journey many people are going on towards integrated record… from sharing HTML views (like MIG) to sharing structured data, to persisting that data , to modelling and reconciling etc…

Its just one model, but hope its helpful…

So again to express our approach another way, we see at least 3 flavours of JSON in the mix for many healthcare developments.
UI JSON… so we offer a UI framework like PulseTile independent of the underlying middleware/DB… but based on a User Centred Design that drives great usability
Interchange JSON … as per the INTEROPen push is promoting FHIR, FHIR is one obvious means to get data in/out of our stack to work with any other FHIR oriented system
Persistence JSON, we choose to persist our data to the openEHR standard which means our data persistence is vendor & tech neutral

We see JSON as the lingua franca at each of these 3 levels now
and we believe we can reduce any challenge here down to a JSON mapping one.
Hence the JSON mapping tool we’re using for this stuff…

Hope that helps explain… keep the Q coming…


Thanks. @tony.shannon

The look and feel of pulse is very familiar, I’ve seen something similar at most of the NHS trusts/boards I’ve worked with. Great to see this open sourced.

Thanks very much @mayfield.g.kev

Appreciate that , you are quite right, we’ve aimed to find and reuse a common set of UX patterns that I’ve seen all over health IT applications over my time… & keep them simple, modular etc.
Been waiting a long time for someone else to open source something similar but it didnt happen, so just got on with it.
Hope you find it useful.

You’ll find the latest work that we are doing on QEWD-Ripple also of real interest I think, as working on quick and easy way to set up PulseTile modules, FHIR interfaces and openEHR templates based around clinical headings to start with, the approach being very generalisable.
Let us know when you’re free and would like to show you around.


BTW meant to mention this article, which explains the link between the 3 key processes in healthcare,…
exploring aggregate data
exploring cohort data
exploring single patient data
and how our PulseTIle framework links them together with a few clicks