When deciding about adopting a clinical data storage solution, you need to think about the next 10-20 years in advance: technology will change several times, organizations will change software providers, new and better solutions will be available on the market, and your main asset will be information, not technology.

Cost is another area to consider, that includes software licenses, support, maintenance, but also data migrations between different solutions that will be adopted in the next 20 years. Most solutions have high data migration costs because they rely on custom and proprietary data models that are tightly coupled with the technology, which will change for sure. So current approaches are not made to last, are made to keep softare companies busy, and it's your organization the one that pays the bills.

With Atomik, your clinical data will never be stored in proprietary data models ever again, avoiding vendor lock-in and high costs of data migration. Atomik relies on the openEHR standard for that, so independently of the implementation technology, your data will be always accessible, compliant with a standard data model, enabling straight forward, fast and low cost data migrations between technical implementations.

A key point on the Atomik standard-based design is the ability of storing any kind of data structure without changing the source code or the database schema. Internally the most popular relational DBMSs are supported:

• MySQL
• PostgreSQL
• H2 Database
• Oracle
• SQLServer

One of the most sofisticated features in Atomik is the ability of using SNOMED-CT expressions embedded into openEHR data queries, as sematic filters to avoid missing data in the query results. So, if your EMR apps use SNOMED-CT to store coded information in the EHR, you can use SNOMED-CT expressions to get data that matches that expression.

Consider the following example: if the data stored corresponds to a SNOMED-CT coded diagnosis, and a set of patients have codes for different types of diabetes (there are about 400 different codes for diabetes in SNOMED-CT), a simple SNOMED-CT expression could be used to get "all the patients if ANY type of diabetes": << 73211009 |diabetes mellitus|

All the queries can be created from the Administrative Web Console, using the Atomik's Query Builder component, and queries are based on openEHR models, not on the technical structure of the underlying database, adding a high level semantic clinical layer on top of the technical implementation. Our goal is to allow Clinical Administrators to create their own queries, without writing a line of code.

There are many scenarios in which the Atomik will help to build a functional prototype or MVP fast, adapting it to your scpecific requirements without writing a line of code for the clinical data management backend.

For instance, if your company/organization wants to build apps for health care, that will be used on multiple platforms (mobile iOS / Android, web, desktop, etc.), there is a need for a consistent data management backend that can help to manage the clinical data independently from the application used to record the data.

Atomik is the perfect complement to allow your ideas come to life. Instead of worrying about the clinical data management, how data will be stored, or how it will be shared between platforms and devices, or learning how to implement the openEHR standard. Just delegate that to the Atomik, use it as a backend service, and focus on delivering features to your customers and end users. Either way, they won't see the effort you invested on building a backend, an will focus on what they see and how your apps can be used.

We created a Toolkit to help you design, test and validate your clinical data models, that will help you build your backend with Atomik, storing and quering clinical data in not time.

We also provide a set of client libraries, in different technologies, to help you integrating your apps with the Atomik the REST API, including:

• Javascript
• PHP
• Java / Groovy

Most health information systems manage clinical and demographic information on the same system, and even store both types of information on the same physical database. There are some reasons why this might not be a good idea, and, technically speaking, not the best software architectural design. The two main reason why having a physical separation of clinical and demographic data are: Security and Enabling Data Reuse.

Security

In the last couple of years, a lot of data breaches and security incidents occurred in the health care domain. Just Google "Health Data Breach" and you will find some results. Think of what would happen if clinical information was stolen, but it didn't contain any demographic data. No names, no addresses, no phone numbers, no SSNs, no document numbers, nothing, just plain clinical data. It would be worthless for the stealers, while privacy and confidentiality is intact. This is one advantage of having only anonymous clinical information.

Enabling Data Reuse

The primary use of clinical information is health care. There is a wide range of uses for this kind of information beyond health care. This is called "secondary uses". The differences between primary and secondary uses are well defined by the ISO 18308 standard. Between secondary data uses we can find:

• Education
• Research
• Decision Support
• Management
• Policy-Making
• Statistical Analysis

None of these secondary uses need to identify individuals. So, granting access to the "Clinical Repository" for people or systems to enable the secondary uses won't put privacy and confidentiality at risk if all the clinical information is anonymous. This is a core concept of the EHRServer design but is nothing new: this requirement is part of the openEHR specifications.

Our licensing model adapts to your specific needs: from flat rate subscription, to tiered by number of users.

Contact us at: info@cabolabs.com to know which license is better for you.

We provide several APIs:

1. Internal data management API
2. Synchronication API allows you to sync two Atomik servers
3. Official openEHR data management API
4. Status API

Using any of the APIs allows you to have complete control of the data that comes in and goes out Atomik, and simplifies integration with any other app or system you need to interact with clinical information.

The sync API allows to have backup servers always syncrhonized with your main server, allowing also high-availability.

The status API allows to track the current status of the server, enabling basic server monitoring, which is important when you manage several servers. On a multi-server environment we provide a Control Center tool that allows external monitoring.