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.
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