Interesting blog post here from Ewan Davis (one of the openGPSoC co-founders) on Open Platforms and what that actually means…
http://www.woodcote-consulting.com/defining-an-open-platform/
Gentle, polite reminder - can this forum be used to publish docs or is it
Just for fitted chatter?
Thanks to Google, I could always use their cloud … (for free!)
Plenty to agree with.
I need to understand more about using openEHR as a persistence layer or more accurately - I’d like to hear comments from SQL guru’s and business intelligence experts on using NoSQL databases for reporting (and the NHS loves reporting).
My gut feeling is openEHR needs to be broken down into sub components (or resources) to these people and that may mean converting to something like FHIR which can sit on top of either SQL or NoSQL storage.
I don’t know what you mean by ‘fitted chatter’ @clive.spindley
The forum is a open place to discuss anything related to Health IT, especially open source and open standards in health IT. You can publish anything you like on here, although I would prefer people to avoid overt advertising.
I am not the forum resident expert on this but I have been trying to get my head around all of this. My understanding is that there are multiple parts to the data infrastructure (or infostructure as Wai Keong likes to call it). Please correct me if I am wrong.
-
The persistence layer. How we store the information, be it a relational database (like SQL) for operational / transactional systems that need to find data quickly, or NoSQL systems for analytics.
-
Above this sits the information modelling layer. This is where we make sense of the data - the meaning and relationships of the data items. Many older or smaller systems don’t have a proper model, and that brings its own problems with expansion and interoperability.
This layer is where openEHR sits, as well as ontologies / terminologies such as SNOMED CT. It can be confusing as there is overlap between many of these different standards, but the simplest analogy I understand it is that the terminology (eg SNOMED CT) acts as the vocabulary, and a constrained data model (eg openehr) acts as the grammar. -
There is then the query layer where we query the data we have stored. Traditionally this is done with tools that are tuned to the persistence layer (layer 1) eg with a sql query. But openehr gives us another option of querying the information modelling layer (which can be very powerful in terms of interop and reuse of applications).
-
Messaging layer. This is how we move data between systems. That is where HL7 and now HL7-FHIR sit.
So there are distinct roles for each of these, but with mission / feature creep, we start to see overlap in functionality of some of these components.
If anyone has a different take on this, please let me know. It is all a learning process.
Navin
Yes HL7v2 and v3 are the messaging layer. FHIR is a different beast, it’s resource API.
The way I look at it (and solely looking an application as an example)
Database Layer (Persistence Layer) : NoSQL, SQL, etc
Business Layer (API Layer, Persistence Layer or the Middle Tier: typically SOAP/REST but here is where FHIR sits.
Presentation/UI Layer: Front end of the application.
Or this diagram - replace the OpenMRS API with FHIR and you get the structure of several UK FHIR implementations (and JQuery with AngularJS).
The beauty of FHIR is you can expose the middle tier to 3rd parties.
This is a really useful dialogue for my understanding.
I can see where you are coming from. But from your initial comment it seemed that you were saying that we should be converting openEHR to FHIR arterfacts, which would then be persisted on a SQL / NoSQL system:
My gut feeling is openEHR needs to be broken down into sub components (or resources) to these people and that may mean converting to something like FHIR which can sit on top of either SQL or NoSQL storage.
The approach I was suggesting was for the openEHR artefacts to be persisted, as we perceive added value to doing this. But these would be aligned to FHIR artefacts (eg http://www.healthintersections.com.au/?p=2169) so that we would have the best of both worlds.
Navin
I was just thinking about that.
FHIR is just an interface but doesn’t dictate how the data is stored. Some systems like some versions of HAPI FHIR Server do persist the data that way but most systems would just map these to existing tables or objects.
Another way FHIR could be used is to allow systems to intercommunicate (so yes, messaging like and I’m probably being pedantic to say FHIR isn’t for messaging).
I’d assume an openEHR would use FHIR to talk to PAS systems which manage Patient Management (F) and Scheduling (F) data.
Also use (F) Document & Lists API’s to communicate with Document Management systems and/or XDS systems.
Etc
I’m wondering if I’ve been reading the blog wrongly. It doesn’t say openEHR would hold the entire set of data for an entire health eco system. The way the pathway thread was going would imply openEHR systems manage/holds Care Provision (F) and parts of Clinical - General (F) (and so would provide FHIR API’s for these resources)
(F) = FHIR Categories for data as per this page http://www.hl7.org/FHIR/resourcelist.html
OK, thanks
On 13 March 2016 at 17:49 "mayfield.g.kev" <discourse-system@openhealthhub.org> wrote:March 13
Plenty to agree with.
I need to understand more about using openEHR as a persistence layer or more accurately - I'd like to hear comments from SQL guru's and business intelligence experts on using NoSQL databases for reporting (and the NHS loves reporting).
My gut feeling is openEHR needs to be broken down into sub components (or resources) to these people and that may mean converting to something like FHIR which can sit on top of either SQL or NoSQL storage.
Visit Topic or reply to this email to respond
To stop receiving notifications for this particular topic, click here. To unsubscribe from these emails, change your user preferences
From what I understand, openEHR’s forte is dealing with patient encounter and phenotypic data - not demographics or scheduling. I believe there are some workarounds for storing these other bits of data, but this is of uncertain benefit, and pragmatically these would likely be stored in other formats.
With the momentum that FHIR is gaining it would be a natural best-fit for openEHR to use FHIR to communicate with these other systems.
Anyway, that is my current understanding of the situation!
Navin
Hi Kevin,
Navin has summarised this nicely. The missing piece in your diagram is that openEHR acts sits above the physical persistence level and in your openMRS diagram, essentially takes the place of the openMRS model and part of the openMRS API. It is a specification that can be implemented in any programming language and using any physical database (SQL or NoSQL). Querying is done via the information model (SPARQL-like) and not directly against the database query engine. There is a standard sevice layer API to which all mature openEHR systems conform that means that one engine (‘Clinical Data Repository’) can be easily switched for another, without re-programming or data transforms.
An openEHR CDR must also be capable of accepting new clinical data models ‘archetypes’ , without any need to re-factor the database, and these must be immediately and fully queryable by querying against the archetype structure, both in the context of their original commit and at the same sort of granular level of a FHIR resource. This make s openEHR a really good fit for FHIR which sits above the openEHR layer, in the same way as you describe FHIR working with openMRS.
Anything that should belong on the ‘patient record’ is the core business of openEHR. There isa demographics server specification but most people tend to use and existing MPI, and I would agree that, at least for simpler use-case, FHIR is a good way to interface with those. Similarly openEHR plays very nicely with IHE-XDS and FHIR may be a good way for that interaction to take place.
Not quite sure what you mean here, Kevin.
openEHR can be (but not necessarily) provided by a NoSQL solution but most of the current implementations are based on SQL solutions.
openEHR data is fully queryable via the Archetype query language, and can be queried at exactly the same levels of granularity as FHIR resources.
I think you may have slightly the wrong idea about how openEHR presistence and querying works.
Do you have ways of building a data warehouse? Which can be queried using simple SQL.
I know you have different ways for accessing the data (and that’s great) but it’s possibly too big of a technology change for many NHS IT depts.
I have similar concerns pushing FHIR down to persistence layers. It’s operational concerns rather than development (as a developer I don’t want to be called in to build most queries).
Its DevOps concerns.
@navin1976 I like your explanation. It’s really clear and helpful. As a full time clinician who has only recently (18 months ago) encountered this weird world of ‘techies’ (and tech in the NHS) I am also trying hard to learn (knowledge, language and culture). Learning by doing whilst working on the OpenOdonto project. Its a steep learning curve. What’s your background?
@beckywassall
Hi Becky,
Thanks so much for your positive feedback.
I am a radiologist by trade. I became regional lead for renal cancer imaging and am also involved in the other urological cancer MDTs. I also used to make pretty noddy Access databases for patient records in the early 2000s.
I am sure that all the clinicians here became involved due to the frustration with their current IT. The lack of any hospital EHR back in the day is what got me first interested. Now it is the lack of interop and the poor flow of information between hospitals, which is significantly affecting patient care and clinician’s morale, especially in the newer models of centralised / distributed care.
We have a fledgling community called OpenCancer (opencancer.net), where we are trying to tackle these issues. But it is very early in the journey!
Navin
@mayfield.g.kev
You are very correct in your assessment re change management.
The words “open source” appear scary for many IT departments. The words “open model” are enigmatic.
I am trying to do just what you suggest in North London - establish a data warehouse based on openEHR in North London, which can play nicely with any existing or future EHRs. This will ideally be persisted with a combination of SQL and NoSQL, depending on the use case.
Navin
Airplanes became much safer and better to fly when people flying them became fundamental to the design and operation
We have much to learn…
Ronnie Monaghan
www.healthlinked.co.uk
Mobile 07834 776423
ronnie.monaghan@healthlinked.co.uk
I was actually discussing this very thing with an aerospace engineer at a party this weekend.
As you can tell, we were the life and soul of the party!
Navin
Hi Navin,
OpenOdonto http://www.openodonto.com/ is also a fledgling community. My involvement was indeed born out of frustration. For our community, having spent some time building our community and working with clinicians to understand their needs better for referrals and chair side…we are at the point that creating data models will be our next ‘thing’. I hope to work with @ian and OpenEHR to do this…just have to balance it with the day job!
I will read your website posts about mindmapping with interest…and maybe get back to you with some more questions 
Thanks
Becky