Introduction

This documentation will help you understand what is Atomik, how can Atomik fit into your product/solution/platform/system/app, the concepts, standards and methodologies in which Atomik is based on, how it works, how to integrate it and how to manage it and the information it stores.

If you need more help, email us at info@cabolabs.com

Quick Overview

Atomik is a generic repository component you can use as part of your software architecture to implement your persistnce layer or part of it.

Atomik was designed to be used by software companies working in the healthcare and wellness domain.

It's focused on clinical and demographic information, it's not designed to manage, for instance, financial, accounting or stock information. That is why Atomik is a Clinical Data Repository (CDR) and a Demographic Data Repository (DDR).

The main goal of Atomik is to be flexible, maintainable, standardized, and allow you to focus on the problem you want to solve for your clients, where you really can add value. With Atomik you can avoid unnecessary modifications to the code and database structure (schema) with each new data requirement from your clients. Atomik works in a way it separates data from the software, so changes to the data structures don't affect the software component. For that we leverage the openEHR specifications which allow to create such separation, and the deeper you get involved in using Atomik and learning about openEHR, the more you will value this approach, especially because it helps avoid touching your all your software layer (persistence, system logic, user interface, services/APIs) when you need little changes in the information structures. This approach reduces the need for huge development cycles, testing and QA, while increases formality on the information management side, allowing your company to comply with new requirements as they come instead of having huge backlogs and delays on deliveries.

Atomik has a user interface that allow server managers to manage the data and data definitions in the server, and access logs of all the changes done to the data, including data versioning. The user interfaces in Atomik is called Web Console, and there is a specific area in this documentation about it.

Atomik has several APIs, the main one being the openEHR-compliant API. Other APIs are: Admin, Sync/Cluster, Monitoring. The APIs are the interface layer you will use to integrate Atomik into your product/platform. We will release OpenAPI specifications for your clients, that you can use as reference, but also to test the API in a live demo system.

Internally Atomik has a data management component that is in charge of processing the API calls, with two main responsibilities: audit log of everything that happens at the API level, and, data versioning, since in openEHR all data that is modified doesn't overwrite the current data, but a new version of the data is created while the old one is still in the server for auditing purposes. This is a basic requirement for any clinical system, and Atomik provides it out of the box so you don't need to build your own.

Finally, Atomik's persistence layer is based on Hibernate, a very popular framework in the Java stack. The key point of using Hibernate is to have an abstraction layer between the system and the specific database. So by using Hibernate, Atomik can use any relational database that has a connector for Java. In non technical words: you can change the database to be used by Atomik. That is a great plus if you think some hospitals already have licenses for certain databases, if they start using Atomik, they can also use their current database brand as the data storage for Atomik.

How to read the documentation

For a quick read of all the elements you need to know as an Atomik user, we recommend these sections of the documentation:

  1. openEHR basics will give you the foundation concepts you need to know to manage standardized data and their models.
  2. Web Console gives you an overview of all the things you can see and do from Atomik's user interface.
  3. Managing data models helps you with the definition and configuration of the openEHR models needed to store, validate and retrieve data to/from Atomik.
  4. Storing data shows you how data is stored in Atomik and how the data is processed to grant quality, conformance and accessibility.
  5. Querying and retrieving data describes how data can be accessed in different ways once stored in Atomik.

The last three items on that list are also related to how to integrate your system/app with Atomik, and using it as a CDR and/or DDR.