My journey with openEHR started in 2006. For me the standard was a panacea for Health Information Systems (HIS). It's approach to standardizing the architecture and information model for *any* kind of HIS, and at the same time providing a level of flexibility and long-term maintainability that I didn't see in projects designed under the usual methodologies for software development and design patterns, was something that caught my attention.
At that time I knew I wanted to build tools for clinicians to improve the quality of care, but I wanted to build better systems than the current ones. The specifications look great, and I learn a lot from them. But developing compliant software is completely different beast, and soon I realized that one of the main challenges of implementing the openEHR specs in software is that there is no predefined way of developing the data storage. And we all know that data storage is a core part of any HIS. If fact this challenge is so big that it is considered a barrier for openEHR implementation.
In 2009 I focused all my attention on the data storage design and implementation. So I tried different technologies and tools, and some proposed techniques from the openEHR community. First I tried pure approaches like using only a relational or documental database, then I realized pure approaches might not suit all the contexts and requirements, and I wanted a generic solution. Then hybrid approaches came into play and seemed the best solution after evaluating some alternatives. Tried JSON and XML databases, tried relational and relational + XML. And tried static and dynamic schemas (for relational this would be generating new tables each time a new clinical document definition is added to the system). Between 2009 and 2011 we ended up with a relational database solution with a static schema and worked very well for a proof of concept project I did to finish my Computer Engineering degree.
In 2012 I started to maintain that project, called EHRGen, but I wasn't happy with the solution and analyzed how to improve it, not only the schema itself (how to make it simpler and more flexible), but I wanted to improve the querying capabilities. The main objective was to allow querying without writing SQL code, and enable to create expressive queries to retrieve specific data in a standardized format. So I started specifying my initial requirements, trying different schemas and prototyping storage and retrieval of openEHR compliant data. When I found an approach that worked, I created the EHRServer project.
The EHRServer was a project that allowed to show how openEHR clinical data repositories work. The repo is based on the openEHR information model, but it's contents are defined and constrained by knowledge artifacts called archetypes and templates. Basically archetypes represent individual concepts like Blood Pressure, Heart Rate, Diagnosis, Medication Prescription, etc., and templates represent full clinical documents using archetypes. Those artifacts specify data structures, constraints, terminology, semantic definitions (concept, purpose, use, misuse, etc.). An openEHR data repository should allow to store and retrieve any data set that is defined in archetypes and templates, so adding new clinical documents to a system should not affect the database in any way. This is where the power of openEHR is perceived: the data model is standard and can be extended infinitely.
The EHRServer evolved, it's source code was opened to the community, and I use it in my courses (https://cabolabs.com/en/training) to explain how openEHR works in the real world. In 2015 I put the EHRServer on the cloud on an OpenShift server, and it was used for testing, evaluation, researching and training. It has more than 300 registered users. The EHRServer evolved, many features were added since the initial proof of concept project, and it became an open source product.
Now in 2017, the EHRServer is a robust solution, it is secure, and easy to integrate with mobile, web or desktop apps. So we decided to launch it in the Software as a Service (SaaS) modality. So we created https://cloudehrserver.com. Right now we are looking for companies that want to join us on this endeavor, want to invest on the service and want to grow with use, so we created the Beta Partners Program (https://cloudehrserver.com/beta_partners_program). The Beta Partners will receive training, early access to new versions and documentation, premium support, access to demos and Q&A sessions, and receive discounts on our online courses.
The next steps will be to make a solid base of Beta Partners and help them with their projects using the Cloud EHRServer, expand the infrastructure, and keep improving the EHRServer and the Cloud service, while we develop other useful services around the EHRServer.
Please join us and share this with your colleagues. We need all the help we can get!