Article written by Vincent Keunen, founder of Andaman7. @vincentkeunen 
Andaman7 technology series #6 - Dynamically generated user interface
This is the sixth 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 Andaman7’s Dynamically generated user interface.
The initial goal of Andaman7 is pretty ambitious: building a distributed, collaborative EHR that could be used simultaneously and in near real time by many actors.
This poses challenges on the architecture and the storage mechanisms of such systems. To know more on these two subjects, read:
- Andaman7 technology series #2 - A new paradigm: distributed collaborative EHR
- Andaman7 technology series #4 - Liquid data model
But it also poses a number of other challenges, this time at the visualisation level, or the user interface / user experience level.
By nature, an EHR is a complex piece of software. There are many data types: vitals, allergies, drugs, documents, blood tests, imaging reports, visit notes... and sometimes a lot of data for a given parameter or vital (does your watch take your pulse every minute?). Time stamps are also important: when did that happen, when was is registered and when was it valid? Does that sneezing happen at specific periods every year? What is the history of that data element?
And obviously, what a patient wants to see is different from what a doctor wants to see, which is different from what a nurse / physio / you name it wants to see.
So we put a lot of effort to make an EHR as simple as possible for patients to view. As Pascal said “I wrote you a long letter because I didn’t have time to make it shorter”. It’s much harder to make something look simple. So don’t underestimate the simplicity of our user interface.
At the same time, we wanted an interface that would also be complete enough for healthcare professionals.
And we had still other objectives! As explained in "Andaman7 technology series #5 - A common foundation for care and research”, we wanted a tool and platform that would be not only ready for care actors, but also for research actors. That means still more flexibility to be able to display questionnaires, symptom assessment screens, PROs (Patient Reported Outcomes) screens and others.
Given the need to be able to store any kind of data and to present that data in so many varying ways for different actors, we built a (semi) automatic user interface generator. This gives us the ability to very easily change the user interface of the app to accommodate new needs in a very efficient way (by changing metadata files without the need to change the application code).
Different actors each have their own way of seeing the same data.
And even for a given type of actor (say the patient), we can display the data in various ways:
- Very complete, with a lot of detail, including history, who registered what...
- Only an overview: useful when you go to a new doctor and need to quickly summarise your health history
- Chronological view: useful when you want to see the latest additions to your health record, possibly coming from many sources like your doctor, your hospital, your lab, your connected devices, that trial you contributed to...
An architectural principle we used is sometimes called “separation of concerns” which, in this case, means completely separating how we store data and how we display it. A very powerful choice, in retrospect.
Recently, we added “Services” to Andaman7 (also known as a “marketplace” of services). That means partners and other companies with great ideas can contribute and offer their services to Andaman7 users (example services are: discover your genetic profile, order your medications online, find a clinical trial,...). And our dynamically generated user interface will come extremely handy to integrate those services deeper, allowing these partners to display new screens at the right place, all nicely integrated.
To summarise: different user interfaces can be presented to the diverse types of users, all based on a common framework and in the same application. Advanced features like questionnaires, forms, specific screens are very flexible and powerful in Andaman7.
That’s what makes Andaman7 a great tool for care in a multi-disciplinary environment - where continuity of care is important. It’s also a great tool for next generation clinical trials and a number of uses cases in medical research.
That’s it for today. Our next article will be on “No protocol API”.
Stay tuned.
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
You can read more about our innovations in our "Andaman7 deep dive" document at https://bit.ly/
(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 support@andaman7.com.
