I don't see why it's really necessary to create new mapped terms (as opposed to selecting existing terms to map) while editing concepts. If this process is actually going on in an interleaved way (make a term, make a concept and map to it, repeat), it's easy enough to open a second window and keep it on term maintenance while the first is on concept maintenance. At least if we're dynamic enough.
From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Thursday, September 01, 2011 3:03 AM To: [email protected] Subject: Re: [OPENMRS-DEV] Creating new reference terms on-the-fly on the edit concept page Personally I've never been a huge fan of setting the mappings on the edit concept page. (That page has tons going on, and as you can see, it's getting unwieldy.) (I've wanted to have us create a new page for managing mappings. (Ideally a consistant UI for managing all mappings to a terminology, or to a concept.) I haven't pushed for this because I figured it'd be less work to just put things in the current page. But if that's taking lots of work...) Are all these new bugs and difficulties introduced by trying to enable on-the-fly creation of terms? Or were they there already, and we just hadn't seen them yet due to lack of testing? Because if this is going to take significantly more work, I'm fine dropping that on-the-fly feature from 1.9. -Darius On Thu, Sep 1, 2011 at 1:20 AM, Wyclif Luyima <[email protected]<mailto:[email protected]>> wrote: I have worked on adding the code to support creating terms on the fly, but i i have realised there are alot of things that are coming into play around it. One of the issues i have run into is that i have had to cascade saving-update operations to reference terms for mappings, meaning that changes to terms will now get persisted to the database as concepts are getting created/edited which i don't think is right. Having an input box with autocomplete and working around it to support creating a new term makes the code(especially the javascript) even more messy just to be able to switch between if the user wishes to create a new one or use an existing one, i already have a couple of hacks around the reference term autocomplete and adding more to support this is starting to defeat it. Validation of the concept is getting slightly more complex given that we have to also validate the reference terms along in case they are new. I have managed to work on get around most of the above but still i ran into one worse challenge, when the form is sent back to user due to validation errors, Things get even trickier e.g should the user be able to edit the concept source or not, should the user still be able to toggle between creating a new term or use an existing one after validation, and the choices to these will have to depend on what the case on the prior submission etc. I guess my point here is that this is calling for writing boiler point scripts and javacode and yet it might still be buggy. How about having a small pop up(only the code and the source to be entered) for adding a new term first before using it in a map, this has the benefit of writing less code and the user won't leave the concept form because this is the main concern of those who wished to create terms while adding maps. Wyclif On Wed, Aug 31, 2011 at 8:12 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <[email protected]<mailto:[email protected]>> wrote: Darius -- I don't quite get your meaning. You say "you would almost never map a concept to a term" but what happens is that "you'll add that one mapping to a concept", which is mapping a concept to a term. What I think is going on is that we are seeing increasing demands for medical records being recorded using standard vocabularies, particularly ICD-10, and these vocabularies are much more granular than the information we have been gathering based on medical and monitoring forms. We need to have new concepts to represent these terms. However, we don't want to lose that data we already have, so we need to map existing concepts to terms from standard vocabularies. In some cases, these new terms/mappings will be used only for output; in others, we are also changing what we gather on input. We also see a move from local codes for answers to standard codes, used mainly for output but perhaps for translation from HL7 input. All of which is a perhaps long-winded way of saying that the image of a data entry person (or even a metadata manager) sitting there editing concepts and keying in mappings they select or add is not an accurate view of the use case. It is whole systems of codes to which we need to harmonize our concepts, which is why the bulk load is so important. Not that we don't need a basic CRUD, just that it's not where the action is. Andy, Burke, Wyclif -- As long as our API methods are based on source and code, with the display name coming through the mapped concept, I'm fine with name optional and code required. All I ask is that existing API methods like getConceptByMapping and getConceptsByMapping not be broken. Ben -- Hi, didn't want you to feel left out. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Darius Jazayeri Sent: Tuesday, August 30, 2011 4:16 PM To: [email protected]<mailto:[email protected]> Subject: Re: [OPENMRS-DEV] Creating new reference terms on-the-fly on the edit concept page My assumption about how many implementation dictionaries are managed (though I haven't verified) is that you would almost never map a concept to a term, but occasionally someone will tell you that the ICD code for malaria is xyz, and you'll add that one mapping to a concept. So I agree that enabling this workflow via a global property makes sense. -Darius (by phone) On Aug 30, 2011 3:01 PM, "Wyclif Luyima" <[email protected]<mailto:[email protected]>> wrote: I get a feeling that some implementations want to be able to create new terms on the fly since they are not going to import terms as such, right? And others don't because the terms will be already imported so creating new ones would be a rare case me, therefore it would be no big deal for them to first go to another form and first create the new term before using it. To me, this calls for adding a boolean global property to allow/disallow creating terms on the fly and it will be up to the admin to set it accordingly. On another note, we(me and Darius) agreed during the scrum chat this morning as suggested by burke's email that we will be adding a service method that fetches term-to-term mappings for a reference term where it is the term b in the mapping i.e 'incoming' mappings to a term from other terms, then these will be listed on the create/edit reference term form as links to the actual terms(term As) that own the mapping. I agree with making name nullable but unique and leaving it blank during migration. Wyclif On Tue, Aug 30, 2011 at 12:37 PM, Burke Mamlin <[email protected]<mailto:[email protected]>> wrote: > > On Tue, Aug 3... ________________________________ Click here to unsubscribe from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
