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…