We need to disable the auto-creation of reference terms. I was able to create a source (like LOINC) and then go into a concept and add a mapping to a code "foo" without any feedback that the reference term didn't exist. We either need to have the creation done explicitly (via a "add new code" choice or link) or not done at all. If turning it off is easier, then that's fine by me (maybe a little "Manage reference terms" link if the user has appropriate privileges that opens the admin screen for reference terms in a new window would be a reasonable short-term compromise).
-Burke On Thu, Sep 1, 2011 at 2:16 PM, Ben Wolfe <[email protected]> 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]
