Developing the "OCL for OpenMRS" Application

go ahead without me

Noted, will do

Hi all, Are we planning to have a call in a few minutes here? Could you share the connection information?

Hello Community,

Just a simple reminder. We shall be having our weekly sync at 15:00 UTC which is about 1 hour from now

Here is a link to the meeting video call

cc: @madraja18 @dkayiwa @c.antwi @paynejd @darius @karuhanga @alexkayabula @danuluma

I am not able to make it, but would appreciate a link to the board… I don’t see a lot of important changes loaded up into demo yet. The mappings seem to be fixed, but the addition of a concept from CIEL with dependent concepts is not yet moving over the dependent (answer/set members) concepts. Also, the word searching for CIEL is not working yet. acquir immun returns nothing, when acquired immun does.

Hello @akanter

The ticket that works on this issue is currently under review.

With regards to this issue, we have a ticket for it but because of the need for a backend fix, it was pushed to Post MVP.

Hello Community, these are the notes and the video link to the sync held on 15th May 2019.

MVP +

  1. Make maptypes when creating a mapping dynamic
  2. When creating a concept, make the description smart enough to ignore an empty description text area
  3. Review the OCL custom validation

Other notes:

Finalize all tickets and send instructions to the community for the user testing phase

cc: @akanter @paynejd @c.antwi @dkayiwa @alexkayabula @karuhanga @danuluma @darius

FYI https://issues.openmrs.org/browse/OCLOMRS-471 was fixed on the back-end. See https://github.com/OpenConceptLab/ocl_issues/issues/98

Quick comment on MVP+:

There are several sources in the OCL organization that are used as lookups. These include map types, concept classes, datatypes, locales, name types, and description types. In the future, OCL for OMRS should pull lookup values from sources in OCL rather than hard coded values. Which sources are used should be set in a configuration file in case we change which source will populate the lookups. FYI in the future, OCL will allow dictionary managers to set a custom source for the lookup values.

I know, which was why I didn’t understand why it was not showing up in the front end. I think this should be fixed if possible.

Andy

I don’t know if the Andela team can deploy new versions of the OCL backend. Is this definitely already deployed to demo?

We are planning to enhance OpenMRS integration with OCL and see that there is considerable progress already made on this front based on the conversations and this document: https://docs.google.com/document/d/1R_Fgr5SBl4xFNJgj6yMJNVY63b5H_OUqM55o1GFqFKs/edit#

Who can we connect with on this? @angshuonline @mksd @mksrom @christine

CC: @vmalini @snehabagri @mohitd @rdeolal

3 Likes

Hi @jinal, feel free to post any specific questions on this channel, or the user feedback channel(OCL for OpenMRS User Feedback discussion) depending on the question.
Otherwise in case of any further queries, you can reach out to @darius or @dkayiwa.

1 Like

Hey @darius,

A few follow up points from the call in regards to the custom validation.

  1. First, using the custom validation applies it to both the source and collection, i.e if you try to create a concept from that source, it is rejected(when validation fails) at the time it is being created, not when its reference is being added to the collection.
  2. We have encountered an issue in regards to the validation of the map types. A bunch of them are being rejected e.g CONCEPT-SET and Q-AND-A. We took a look at the API code and it seems that they are rejected at this point. What we understood was that map types are concepts as well and need to exist in order to be used(when custom validation is enforced on a collection).
    We would like to find out at what point these are seeded into the db.
    We suspect this file is used to seed the map types(oclapi/maptypes_fixed.json at master · OpenConceptLab/oclapi · GitHub) which happens to be missing some of the map types.
    We would not mind adding them ourselves to this file, but we couldn’t quite be clear on the external_id field.

cc @paynejd, @akanter, @dkayiwa

@karuhanga The custom validation schema validates map types against this source: /orgs/OCL/sources/MapTypes/. The file you are referring to I believe is what is used to populate the source when OCL is first deployed. For the time being, you can simply add the missing map types to the MapTypes source. Note that the validation may be case sensitive, so check that first.

@raff Can you confirm where the list of map types (and other lookup tables) that are imported into OCL upon deployment are defined?

@paynejd we don’t seem to have permission to add the missing map types to the Maptypes source.

cc @dkayiwa @paulk @danuluma @karuhanga

Which map types are you missing?

At the moment, we have only identified Q-AND-A and CONCEPT-SET.

We also double checked the case, so I think we are safe on that end.

It’s good to do the validation in both places. But there are cases where a concept will pass validation in the source, but fail in the collection. Because this validation looks across the whole source/collection.

Here’s an example:

  1. Add the “Malaria” concept from CIEL to your collection
  2. Create a custom concept whose preferred name is “Malaria”
    • this is invalid in the collection (because you can’t have two concepts with identical preferred names)
    • this is valid in the source (because the conflicting concept is not in the source)

Ahh, yes, I see that now. Just noticed the earlier error was due to the same concept name already existing in that source. Thanks a lot. (The ticket was created for MVP+)