How do we pick "safe" concept IDs for our implementation?

Hi @akanter

In the context of a real implementation we need to add new concepts. We will submit in due time to the community those that are not 100% specific to our implementation.

However in the meantime, how do we pick the concept IDs?

We don’t want to use IDs that may be assigned later on to the MVP-CIEL Concept Dictionary concepts because we want to avoid potential ID overlaps. When playing around with the admin UI, the IDs are just incremented, so that would lead to overlaps if we don’t pick them with precaution right now.

Thanks for letting us know.

Dimitri, This is not exactly how it works… You have a couple of options:

  1. You can use CIEL exactly how it is. You have to make all requests through us. This is the easiest for updating as you simply run the SQL each time. It is also available right now.
  2. You can set up a development server which accepts the SQL from CIEL and then use the MetadataSharing (MDS) module to move the concepts you want from CIEL to your server and reset the appropriate IDs. This is what PIH does. It also is available right now, but requires more work to keep things in synch. @ball Can help you with that.
  3. The last option is actually the preferred option, but it is not quite ready to production. This is to use the Open Concept Lab (OCL) platform to create your concepts. OCL has the entire CIEL dictionary. You can then add your own concepts either on your own server or in OCL and “subscribe” to the CIEL dictionary and these will then be merged. We are about to go into Beta testing of OCL. If you plan to use OCL, then it might be easier to use 1) now and then 3) when it is in production hopefully this Fall.

Hi Andrew,

Thanks for your detailed and prompt reply. Yes it seems that the OCL addresses the issue and we would certainly want to use it as soon as it can be.

I guess it is the merging that I don’t understand. Please look at the example below:

I am currently using a CIEL version whose last concept is 162967 “Current oncology treatment comment”. If I add a new concept locally, it will be assigned the next incremented ID: 162968.

On your side you will, in the meantime, produce new concepts, such as the one advertised in this thread. And in particular this one: 162968 “Number of children who died within the first month of birth”.

What I don’t understand is how to avoid the overlap between “my” concept ID 162968 and the new CIEL concept ID 162968?

Imagine, we may be using HFE forms that already refer to ID 162968 while hardcoding it in the XML markers. I would assume that the OCL can deal with this, but how do we avoid overlaps in the meantime?

[EDIT] I guess I could summarise my question as: is there a range of IDs that can be used safely locally? Such as, for instance, among many others, the below IDs that are currently not in use in CIEL: … 5363 5423 5482 5540 5597 5653 5708 5762 5815 5867 5918 5968 …

@mksd - We never use concept id in our forms for the reason you mention. We use mappings. In the example above, we would use this:

Then add your non-CIEL concept (162968) with your own source/mapping. At PIH, we would give it 2 mappings: “PIH:162968” & “PIH:Number of chidren who died within month of birth”, then use one of those mappings in the htmlform.

You can’t count on the concept ids, but you can preserve mappings or uuids. I prefer not to use the uuids in our forms since it makes for unreadable htmlforms. At PIH, we use ‘synch’ to maintain the databases of multiple servers. Synch does not preserve the concept ids, but mappings or uuids are maintained.

If you want to understand how PIH uses the awesomeness of CIEL + our own concept dictionaries, I’m happy to advise. I thought it was documented on the OpenMRS wiki, but cannot locate it. We do hope to use OCL when it’s ready for us.

Please see Ellen’s reply. You cannot count on the concept_ids being the same and that is why you should not use IDs but either UUIDs or mappings to bind to forms. Even in the OCL model, I am not sure you can always count on the concept_id to be the same across systems. Therefore there is no “safe” range of IDs to use locally. If you provide the concepts to CIEL, they can be added to the dictionary and get a sequential ID, but that still does not solve your underlying problem of binding to forms.

Thank you so much @ball and @akanter, these were the clarifications we needed. Combining UUIDs and mappings allows for ensuring unicity across implementations and safe usage in the forms.

For now we are importing our custom concepts via a CSV, hopefully we will switch to using OCL when it is ready.

@mksd - are you working on an oncology? I’d love to hear about your project.

Partners In Health is working on an oncology htmlform for University Hospital in Mirebalais, Haiti. It should be completed by the end of the month. Let me know if you are interested. I’ll add to the OpenMRS form bank.

1 Like

Hi Ellen.

Sorry, we were swamped with work, just crazy. Apologies for not replying any sooner.

No, this is for a pediatric hospital. Yes I was just reading about the form bank, it sounds very interesting. Is it such that a form and the relevant concepts needed by it can be packaged for being reused elsewhere?

@mksd - If you have the htmlform entry (HFE) module and the metadata sharing module (MDS), you should be able to download the oncology form mds package from the form bank, import into OpenMRS, and have an oncology form. You will also see the corresponding paper form in the form bank, although the paper doesn’t exactly match the electronic version. The paper includes additional forms for specimen tracking.

Ellen Partners In Health

@ball Any chance that you have found the documentation on how PIH manages the non-CIEL concepts? I would like to experiment with this approach too

@ssmusoke @jordan @judy @mndisha■■■■■■■■■■ @arbaughj

I’ve improved the concept server management documentation on the OpenMRS wiki. Seems like there was a common interest in the way that PIH manages the CIEL and non-CIEL concepts.

Please let me know if any is unclear.


1 Like