I have included a small button when clicked, a small pop up get displayed to create a new term without leaving the page via DWR, i have added a special privilege that is required for the button to be visible in the form and this was way easier to code.
Wyclif On Thu, Sep 1, 2011 at 3:05 PM, Ben Wolfe <[email protected]> wrote: > Ah yes, money. I always forget about that. :-) > > Mapping is also possible to other installations, module sources, etc. > So it certainly won't be 99.9% for implementations. > > Ben > > On Thu, Sep 1, 2011 at 9:43 PM, Glen McCallum <[email protected]> wrote: > > I would estimate that 99.9% of reference terms will be created during a > bulk upload. I've never created a single one manually in the past. I > hesitate to even recommend the feature of single ref term creation. > > > > Ben, I'm unsure of the licensing around distributing terminologies. > Certainly, most terminologies can be used in 3rd world countries without > charge but I'm not sure that openmrs can package and distribute them. > > > > Glen > > > > On 2011-09-01, at 11:16 AM, Ben Wolfe wrote: > > > >> Could we leave it as is and instead put the development cycles into > >> packaging up terms from the more popular terminologies out there? > >> Then we can document that the easiest solution is to download/import > >> these massive blocks of codes from the wiki. > >> > >> Ben > >> > >> On Thu, Sep 1, 2011 at 8:59 PM, Burke Mamlin <[email protected]> > wrote: > >>> 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... > >>> > >>> ________________________________ > >>> Click here to unsubscribe 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] > > > > _________________________________________ > > > > 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] > > > > _________________________________________ > > 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] > _________________________________________ 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]
