Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

2018-03-12 Thread Tony Shannon 
ok thanks Tom
T

On 12 March 2018 at 13:46, Thomas Beale  wrote:

> Tony,
> this post was very useful; I've referenced it and copied bits of it to the 
> wiki
> page
> 
> .
>
> - thomas
>
> On 18/02/2018 18:34, Tony Shannon wrote:
>
> Hi all,
>
> This might be a useful time to briefly explain why we are supporting 3
> open source components in our "showcase" stack
>
> EtherCIS - open source implementation of openEHR Clinical Data Repository
> http://ethercis.org/
> QewdJS - nodeJS based middleware for varied purposes - inc microservices
> between UI & CDR
> PulseTile- frontend UX/UI framework for healthcare
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Team, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

2018-03-12 Thread Thomas Beale 

Tony,

this post was very useful; I've referenced it and copied bits of it to 
the wiki page 
.


- thomas

On 18/02/2018 18:34, Tony Shannon wrote:

Hi all,

This might be a useful time to briefly explain why we are supporting 3 
open source components in our "showcase" stack


EtherCIS - open source implementation of openEHR Clinical Data 
Repository http://ethercis.org/
QewdJS - nodeJS based middleware for varied purposes - inc 
microservices between UI & CDR

PulseTile- frontend UX/UI framework for healthcare



--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

2018-02-18 Thread Tony Shannon 
Hi all,

This might be a useful time to briefly explain why we are supporting 3 open
source components in our "showcase" stack

EtherCIS - open source implementation of openEHR Clinical Data Repository
http://ethercis.org/
QewdJS - nodeJS based middleware for varied purposes - inc microservices
between UI & CDR
PulseTile- frontend UX/UI framework for healthcare


A few comments;
Point 1
We know that structured data in an EHR is essential for lots of reasons,
inc querying, CDS, workflow etc etc. We also know that most folk who craft
their application UI based on their data models end up with an UX
application that is horrible & tedious to use at the frontend. (My
emergency physician background was witness to that in many many
applications.
I also recall leading work by Helma Van Der Linden about the challenges in
automatically mapping from openEHR to the UI in a decent to use fashion..
non trivial was my recollection of our discussion.

So our approach has been a very deliberately clinically driven, user
centred design approach, which has then driven the openEHR templates that
underpin, but the UX is #1 in importance to frontline clinicians, not the
data models.
(Still , all the key data is our stack created/updated/persisted in
EtherCIS (& Marand) CDR using a RESTful JSON API. )


Point 2
We know that many folk are doing/ do direct mapping from data models to UI
eg we could have chosen to feed the UI framework with openEHR JSON API
directly
We also know that then raises somewhat of a data migration challenge if
you're sitting on any legacy non openEHR data (which most folk are), hence
we use a middleware element (QEWDjs) which handles the mapping from both
openEHR & non openEHR sources into the same UI JSON.
We explain the rationale for that in this article, where we describe 5 step
wise levels of integration between non openEHR & openEHR systems, that our
UX framework accomodates
http://ripple.foundation/2016/02/integrated-care-digital-records-maturity-model/
This key openEHR Jumper technology in QEWD handles the mapping between
openEHR/ non openEHR (eg FHIR) and UI side JSON with a simple JSON2JSON
mapping tool. as per this video.
https://www.youtube.com/watch?v=iaGGGgJdWvM=3=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv

(Some of you feel this middleware layer is an unnecessary element in an
openEHR environment & I can understand that perspective. All I can tell you
is that such a layer is essential in any environment we're working in where
folk have existing data & exploring a move towards openEHR)


Point 3
So the UX framework has then been designed to be pretty simple and generic
and reusable for lots of uses.
In particular it aims to support "business/clinical analytics", "multi
patient cohort views" and "single patient that I need to look after who is
right in front of me views" , as in my experience these are the key
processes we need to support.
This framework is documented here http://docs.pulsetile.com/
and a video cast here gives an overview here
https://www.youtube.com/watch?v=jpfIZ_HWr3w=2=PLNxHSK29ViKLrrhdPTqbYr6XGTya4uGBv

and for better/worse we have supported in both Angular & React frameworks
for now, with a core set of widgets "Tiles" and a plugin approach to extra
Tiles.
see here https://github.com/PulseTile
I wont get into the large & evolving range of choice in frontend
frameworks, but if you are trying to keep track of them take a look here
https://github.com/gothinkster/realworld
We've heard mention of microservices in a recent thread, not to mention the
possibility of https://micro-frontends.org/


Lastly a final UI side JSfiddle, to explain direction of travel here
https://jsfiddle.net/tshannon/hgypL94d/

Imagine an open source stack..
#openEHR CDR pre populated with top 10/20/50 templates for common use +
#middleware with related openEHR_2_UI mapping (or other eg FHIR API) via
JSON2JSON mappings (some will argue unnecessary, I refer back to point 2)
#UI framework with top 10/20/50 UI widgets ("Tiles") with the ability to
add your own template. JSON2JSON mapping & UI widget)
.. thats probably the best way to summarise where we are heading with this
in 2018


Perhaps to finish, even if your working from openEHR 2 UI directly, please
remember the busy clinician at the frontline who has to contend & work with
the UI (not the data model).. lets aim to get tools out there that ease
their load..

Hope that's of interest/ helps

Tony



Dr. Tony Shannon
Director, Ripple Foundation   ripple.foundation
tony.shannon@ripple.foundation
+44.789.988.5068 (UK)
+353.89.457.6011 (Ireland)











On 18 February 2018 at 15:55, Thomas Beale  wrote:

>
> On 18/02/2018 11:16, Erik Sundvall wrote:
>
>
> When designing this, perhaps some (2-5) existing currently popular GUI
> frameworks could be initial targets for output from the process, and the
> selection could be updated over time. Perhaps for example
> https://angular.io/ and https://reactjs.org/ are two starting candidates
>