Some time ago, an interesting request came along on the openEHR forum: would developers and CTOs of EHR's share their honest perspective on the implementation of openEHR ? What were the expectations, what problems did they encounter?Our architect, board member of openEHR Netherlands and vice chairman of the Specification Committee of openEHR International Sebastian Iancu was happy to share his experiences on the forum. In addition, we realised that these questions are probably posed at more organisations - so we asked the questions to Sebastian again. His answers, with Sebastian's characteristic honesty and focus on technology that serves care, are shared with you in this article.
What were your expectations when you implemented openEHR?
"When we founded CODE24 in 2011, we started implementing the openEHR specifications from the ground up. We made the decision to do this based on 2-3 years of experience from previous projects where we used the openEHR technology.
Our expectation was that openEHR would help us create a clean and scalable backend based on international standards, so we could develop quickly, integrate with other systems and have the ability to (re)use medical knowledge (captured in commonly developed information models, archetypes)."
Did your expectations also come true?
"Yes, initially it was a big investment to implement all the specifications, but in the end it worked out and still serves its purpose and has allowed us to grow into what CODE24 is today.
It has also helped us to be more agile and quickly adopt new technologies (such as FHIR), or to participate in national projects such as MedMij - something we had not anticipated in 2011.
We did also expect that more vendors would understand the openEHR vision for health data and patient-centric systems and that they would join in and start deploying the specifications. While this has improved over the years, from just a few implementations and vendors to the larger community it is today, it is a slow process. It's not as far along as we thought it would be 12 years ago."
What problems did you anticipate?
"Implementing a complex standard like openEHR takes a certain amount of dedication (focus) and experience. This is really something you have to build, and that requires time and patience. We knew this in advance.
On a technical level, we knew it would be complex to build a query engine that would be sufficiently scalable and that also supports the two-level modeling of openEHR. Eventually we came up with an architecture and several indexing and query optimisations that could help us with this problem.
We also expected issues around how quickly openEHR would be embraced - you need other parties to "speak" openEHR for better interoperability - but fortunately this continues to improve, especially recently."
What unexpected problems did you run into?
"We have encountered several unexpected problems over the years, but we have always found solutions - often from the openEHR specifications and technology. We also contributed to the specifications ourselves, sharing our experiences and findings with the community so that it could be included in new releases.
Some of the main unexpected problems were related to integrating and using non-medical concepts into medical applications. Consider demographic data or administrative resources, sources or physical items (for a resource planner) or information related to social care.
Other problems had to do with national standards or regulations we had to comply with, which did not mesh well with international standards. Think about information models and techniques, certain aspects of the care process, et cetera."
How is the performance?
"The openEHR specifications prescribe neither a specific physical or technical infrastructure nor a specific implementation design. Therefore, performance is subjective - it depends on the vendor's solution and their technology stack.
What we did learn over the years is that performance is highly dependent on infrastructure, use cases, work-load and application layer efficiency, or functional requirements implemented (in)efficiently. In general, from our experience, performance is good - we always see opportunities to optimize it even further. We also actually never hear any complaints about performance from our end users."
Does the openEHR standard give you enough freedom?
"We are very happy with the freedom we now have. With the openEHR archetypes and templates, we have all the freedom and flexibility we need, and with the openEHR Reference Model we have a solid 'technical layer' that we can use freely.
On the other hand, complying with the standard and with internationally published archetypes sometimes limits this freedom somewhat. But in the end, we think this serves a good purpose, which is interoperability."
Want to know more?
Is your organisation considering using openEHR in your software and do you still have questions? Don't hesitate to contact us - or ask your question on the openEHR forum!