Reference term creation needs to be more than simply typing in the wrong code and adding it. As it stands, I can enter any code I want and add it. Ideally, I'd be forced to either search & select from existing reference terms or clicking an "add new code" choice (or link), if I couldn't find what I needed, that would use a popup window for reference term creation.
As it stands, it's too easy to accidentally create a new reference term. If this isn't an easy fix, it can easily be ticketed to be done later… even post-1.9, IMHO. -Burke On Thu, Sep 1, 2011 at 7:56 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > 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]> 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]> 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]] *On Behalf Of *Darius > Jazayeri > *Sent:* Tuesday, August 30, 2011 4:16 PM**** > > > *To:* [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]> 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]> > wrote: > > > > On Tue, Aug 3...**** > > > _________________________________________ 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]
