Atomik is a Clinical and Demographic Data Storage solution based on the openEHR specifications.
Atomik is the third generation of our efforts to implement openEHR compliant systems. Our first full stack implementation was back in 2010. Then we created openEHR-gen framework [1][2], a system based on openEHR archetypes that was a very generic EMR generator. Basically, all user interfaces were generated automatically on the fly from archetypes, user data was validated automatically against archetype constraints, data was stored automatically in a generic repository, and query/retrieved also based on archetypes.
In 2013 we released EHRServer, the first open source implementation of an openEHR Clinical Data Repository. We used that mainly for training courses, to show our students how an openER repository works. EHRServer evolved and it's been activelly used by the openEHR community. EHRServer is also offered in SaaS.
Then in 2018 we started a redesign/refactoring of EHRServer, which was named EHRServerNG. This is Atomik. With Atomik we changed, improved, extended and added new features on EHRServer, but the foundation is the same.
For Atomik we also changed the business model, trying to focus on startups and small-medium size companies and organizations developing systems in the healthcare domain.
At CaboLabs we have been working with Health Care Information Systems for the last 18 years, designing, assessing, auditing and integrating them. One very common flaw we saw on many very promising projects was the low impact of these apps and systems, due the lack of integration with other systems. Isolated apps don't add value, period.
We have been involved in some of those projects, watching how hundreds of man hours were invested on apps destined to fail, due one small thing: health care is by definition integrated. Our customers and partners were thinking on solving one problem for patients / clinicians / organizations, without considering external elements that were key for making these projects succeed, and indeed those failed terribly, or where not even launched.
Knowing this, we should consider that any app we build for health care, will need to send data to other apps, receive data from other apps, or both, in order to solve a real problem or add value to the patient, to the clinician, or to the managers, or to the researches, etc. Whichever is our customer or user.
A clear example is the vast amount of apps related to physical activity tracking, alone those don't add much value, but imagine integrating that information with data from a weight loss plan set up by a dietitian in the EHR of the patient, or mixing exercise data with chronic disease and risk factors data to evaluate how the patients are currently doing in order to improve their quality of life and life expectancy. This are real goals, that us as patients would like to see implemented in our health providers. For us and for our family and friends. This can't be done without integrating data.
What we are trying to do here is to enable that from scratch. Standardizing each data point to facilitate mapping to other data models. Focusing on designing powerful and expressive APIs to enable data accessibility. Integrating systems using well known international standards. Also providing consultancy, coaching and training to your team, to make the most out of our platform.
The way we provide this is via micro-services that solve one specific problem forming a platform of building blocks that will allow your next project to be prepared for integrating with other systems, and avoid reinventing the wheel. Good solutions are out there, let's (re)use them! We think Atomik is one of those.
We love to hear from you, let us know how we can be of help.