Article written by Vincent Keunen, founder of Andaman7. @vincentkeunen
Andaman7 technology series #4 - Liquid data model
This is the fourth article of our series dedicated to the technology of Andaman7. Our goal with this initiative is to contribute to the field of “health IT” by discussing challenges and possible solutions (more details on these challenges in our article #1). To read the previous articles, start with the first one: Andaman7 technology series #1 - Introduction.
The opinions in these series are our own. They are based on our 25 years of experience in the field building large scale EHRs (Electric Health Record) and medical information exchange systems (1). We share them in good faith to help move the needle forward and inspire others. And of course, we also want to promote our own Andaman7 initiative, a project by patients for patients (2). Terms and acronyms are explained in our lexicon (3). We are open to and welcome discussion on these topics. You can find us on LinkedIn, Twitter and Facebook and we can also discuss on other media you would like to invite us to.
Today, let’s talk about Liquid data models.
Medical or health information is complex by nature. Health IT systems need to record numeric values, items from selection lists, short and long texts (free form or codified ones), various kinds of documents, images (sometimes with very high resolution that are very storage consuming), audio files…
Non numeric data should be codified so it can be processed later. The codification systems vary greatly around the world: ICD9/10, Snomed, Loinc, … and many proprietary ones. It’s therefore a challenge at many levels. Agreeing on a standard has been very difficult for the past 20 years (just look at the number of standards proposed…). Fortunately, there seems to be growing agreement to standardise on LOINC and SNOMED - at least in the care industry. Still, the challenge for many hospitals is to map all their existing, proprietary codes to the standard ones. When you know that LOINC is 80k codes and SNOMED is 300k, that’s a lot of work!
To store all these types of data, Andaman7 has come up with a very innovative “liquid data model” that combines research in medical IT and modern storage like big data, NoSQL databases, etc. Our model is basically “schema less”.
If you have some expertise in knowledge engineering / knowledge representation, you probably know that the foundations are very “mathematical”. We won’t go into the details of this here. One “level up” is the (computer) languages and data types we use to represent information, ie programming languages and their data types (characters, strings, integers, reals, symbols, ...).
And one more “level up” are the so-called “business specific models”, which represent the “components” (objects) of a specific domain. For example, the “medical domain” contains the notions of patient, care provider, sickness, test, report, treatment... and many others. HL7 was an attempt at representing these - even if it was more focused on exchanging them. FHIR is a more modern and pretty successful way of representing (modelling) that domain. However, it is still quite complex. And it’s evolving, so the successive FHIR models (or schemas) change and the compatibility between them is a challenge. And today, FHIR is better suited for “care” than for “research” (which has its own standards like CDISC, ODM, OMOP, …).
At Andaman7, we developed a way to represent data that would work for both care and research sectors. We wanted a very lightweight mechanism - ready for web and mobile. We wanted something easy to learn. We also wanted a very evolutive information storage mechanism - to be able to add new types of information, without having to adapt the whole schema (like FHIR needs to do). And we wanted a system that would be highly traceable / auditable (see another article in this series on this subject) - ie a system to know exactly when a piece of data has been generated and its source.
So we came up with a representation system that is between the level of computer languages and the level of domain models. It is still specific to the health sector but it is schema-less. The basic element is an “Atomic Medical Item” or AMI - that, in retrospect, we should have named “Atomic Health Item”, but AHI is harder to pronounce, while AMI looks more “friendly” - especially in French ;-). We won’t go into the details of AMIs here, you can take a look at our developer portal for that: What are the basic concepts of the data model?
This gives Andaman7 a very high level of extensibility: virtually any kind of data can be stored by the software - without changing the data storage. It is also very easy to add new types of information which may be required by interfacing to other IT systems or for projects like clinical trials. Andaman7 was built to be highly “interfaceable”. This shows when we interface to other (usually schema based systems): it’s extremely easy to interface, even to systems from different worlds - like FHIR in the care sector and CDISC in the research sector.
The benefits for traceability and auditability are also great and will be described in another article (it’s also in our white paper at Extreme traceability). Our model is also critical to build a really distributed collaborative EHR, like Andaman7.
And you know what? All of this can be done without changing the core application! We only need to adapt the AMIs descriptions in metadata files.
That’s it for today. Our next article will be on “A common foundation for care and research”.
To read the summary of these articles, combined into our white papers, go to:
- Andaman7 Technical Innovations: http://bit.ly/a7TechInno
- Andaman7 advanced health data management: http://bit.ly/a7DataMan
(1) In a previous company, we built a prevention-focused EHR that is today used for some 1 million people (most are in good health, some are patients). We also built the technology for the two largest “medical messaging systems” of Belgium, still being used today by 90% of all hospitals and doctors.
(2) Read our story.
(3) Consult the lexicon. It's a work in progress. Don’t hesitate to make suggestions and remarks to email@example.com.