Shared Health Records

In contexts of multiple disparate, heterogeneous and isolated clinical systems, data integration is a must. Without it, problems like data fragmentation, inaccessibility and inconsistency could affect clinical decisions, and could potentially harm the patient's health. Part of providing better care quality efficiently, relies on how the patient's data is managed and accessed. There can't be integrated care without integrated clinical information.

Atomik is an ideal tool for aggregating and centralizing clinical information that needs to be shared between different clinicians, specialties, teams, departments, and hospitals. Even in some contexts data should be shared with the patient through a Personal Health Record or a Patient Portal.

The usual process for aggregating patient data that resides on different isolated silos, following the openEHR model, includes these steps:

  1. Analyze which information should be shared between your systems, start small, focus on the basics: general encounters, vital signs, allergies and other diagnosis, family history, immunizations, etc.
  2. Model that information using openEHR. Check the openEHR basics guide. This will serve as a canonical model that will standardize the information from your different systems.
  3. Transform your data sources into canonical model instances. We have tools to help you on that process. Also a middleware like Mirth Connect (open source) can help you on the transformation task. Of course, from CaboLabs we can help with this process.
  4. Commit send your instances to the Atomik to be persisted as part of each patient's EHR. Repeat until your current data is committed. This is like a batch process to load historical data. Now the data is ready for querying!
  5. Query the data from any external system, even from systems that are not part of the data sources! Create some basic queries over your data, like get all the vital signs from an EHR. That can be done easily using the Query Builder from the Web Console. The result of each query will be consistent, openEHR compliant, and you can choose between JSON and XML formats to get your data for processing (yes you can do things like evaluating rules for clinical decision support), analysis, or just nice visualizations. If you don't want to query, you can get full clinical documents by their id in XML or JSON.
  6. Integrate this solution in your environment to synchronize data regularly, so you get current data when your systems and apps execute the queries. The first commit round is the heavy loading, now it's time to receive data online instead of a batch process.

Open a world of possibilities

Following those steps you don't just load data into another database, you standardized and integrated data from heterogeneous, and maybe inconsistent / incompatible clinical systems, into a single standardized, vendor-neutral, Clinical Data Repository.

This opens a whole world of new possibilities! Sharing clinical data between your systems is the first step, but you can add more apps that use queries to access existing data to create more services to clinicians and patients, explore data visualizations, integrate this data into clinical decision support tools, and more. Your imagination is the limit.

Also, following the same steps you can scale your integration in terms of the information that is being shared, sharing more information and creating new queries over data. With that you can offer new services and continuously improve your app ecosystem. Keep this mantra in mind: Better apps for clinicians, better access to meaningful clinical information, better care for patients.