Is there a way around for a Non CIEL implementation to support the Reference Application or a means to develop one ?
Hi @ulrich 
Can you say more? I don’t quite understand the question.
Are you wondering if there’s a way to build against the reference application if you don’t use the CIEL dictionary?
The reference application has workflows that are dependent on certain metadata it ships with which include CIEL concepts. I think you can but you would have to set up a lot of concept mappings, concept sets and global properties which for sure won’t be a simple task
The Reference Application itself is built to include out-of-the-box content, which means that the application is basically usable out of the box. The downside is that this makes it hard to install the application on top of a pre-existing (and inconsistent) data model.
The reusable components that make up the reference application can be used on top of any data dictionary. The most advanced example of this is what PIH does with their Mirebalais and PIH-EMR distributions. Unfortunately this isn’t explicitly documented anywhere, so to make this work you’ll have to do a large amount of trial and error, and peeking at the underlying code to see what is going on.
Generally the approach is something like:
- Install all the Reference Application modules except for: referenceapplication, referencemetadata, and referencedemodata
- Write your own module (e.g. a fork of referenceapplication) to:
- provide a login and home page
- change the configuration that happens in the referenceapplication module’s activator
Are you starting from scratch with a given non-CIEL concept dictionary? Or do you already have other types of metadata defined like visit types, encounter types, etc?
@darius, @michael, @dkayiwa, @pascal, @wyclif, @paul
I have the visit types and encounter types metadata in the database.
In short my problem is that recently I did an upgrade from version 1.9.7 to 1.11.4. Later, I installed the reference app modules, all the modules loaded and started successfully with the exception of the Reference metadata and Reference demo data modules. The log talks about duplicate entry for concept_uuid_index. RefAppErrors - Pastebin.com
Looking at all the db backups I have, the db before the upgrade does not have these duplicate concepts, the db before installation of the Reference App modules have these concepts already.
My questions are
- How do I know if the installation is running the CIEL Dictionary ?
- Does it mean that the imports and modules I installed during the upgrade did insert some concepts and the Reference App modules did insert other concepts with the same uuids or what ?
@wyclif, If you can remember I started an upgrade recently and had some difficulties that you and the others helped in solving I did the upgrade from version 1.9.7 to version 1.11.4 successfully and installed the modules of the ref app, unfortunately all the modules of the ref app loads and start successfully with the exception of the Reference Metadata and the Reference demo data modules. The log talks about duplicate entry for concept_uuid_index
Looking at all the db backups I have, the db before the upgrade does not have these duplicate concepts, the db before installation of the Reference App modules have these concepts already.
My questions are
1- How do I know if the installation is running the CIEL Dictionary ? 2- Does it mean that the imports and modules I installed during the upgrade did insert some concepts and the Reference App modules did insert other concepts with the same uuids or what ?
Thanks for the assistance.
I think the only way to know whether a CIEL dictionary was loaded from the dropbox script, would be to check for a global property ciel.conceptsVersion. To be honest, if you download the appliance, I am not sure that this global property is set. You could also look for concept UUIDs that look like ###AAAAAAAAAAAAAAAAAAAAA, etc.
@akanter I have concepts with UUIDs of the form ###AAAAAAAAAAAAAAAAA but I don’t have the global property ciel.conceptsVersion.
I think this basically means that you have some CIEL content. If ALL the concepts have those UUIDs, then you have a CIEL dictionary which must have come from an appliance. If some of them have the UUIDs, then you have some PIH dictionary or someone used MDS to move the concepts around. Since the CIEL SQL which overwrites the dictionaries sets the global property, unless that was manually removed it was not updated using the CIEL dictionary SQL which is distributed via the dropbox.
He attempted to run the reference application modules which added a few of
the concepts.
I did a restore of the db state I had before the installation of the reference application modules and I still have concepts with this type of UUIDs !!!
Daniel, thanks. I forgot that is another way where a few of these concepts would be added. But most would have been that way if the CIEL dictionary was used as a start.
There shouldn’t be any hardcoded CIEL concepts; any references to concepts should be through a concept mapping. Do we have a list of these anywhere?
I don’t think we have them explicitly listed anywhere.
A few I know of offhand are vital signs (for the vitals form) and the visit diagnoses set and the concepts of contains (for diagnoses on the visit note form).
I would certainly want to get this listed posted somewhere… as it applies to the reference application and Bahmni 