I think it makes sense to require a separate form for creating a new reference term. However, If I am adding a reference term as a map, I shouldn't have to create the term as well. It should be OK to just store the code for the map without the required key in the reference table.
I think Burke and I both disagree with Roger on the required fields that the code should be required and the name not (on the mapping table). On the reference table it seems that you would want to have both code and name populated. Andy -------------------- Andrew S. Kanter, MD MPH - Director of Health Information Systems/Medical Informatics Millennium Villages Project, Earth Institute, Columbia University - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology Columbia University Email: [email protected] Mobile: +1 (646) 469-2421 Office: +1 (212) 305-4842 Skype: akanter-ippnw Yahoo: andy_kanter >________________________________ >From: Wyclif Luyima <[email protected]> >To: [email protected] >Sent: Tuesday, August 30, 2011 2:57 PM >Subject: Re: [OPENMRS-DEV] Creating new reference terms on-the-fly on the edit >concept page > > >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 30, 2011 at 11:33 AM, Darius Jazayeri <[email protected]> wrote: >> >>Hi Andy, Burke, Roger, Ben, etc, >>> >>> >>>Wyclif wants to finish off the work on concept mappings for 1.9. One >>>specific point of discussion was about whether or not you're allowed to >>>create new terms just by entering them as mappings in the edit concept page. >>>Originally Wyclif implemented it such that you could, then we asked him to >>>remove that feature. Then we asked him to put it back. I want to make sure >>>we all clearly agree on an approach. >> >>I agree that we should agree. >> >>See the screenshot on https://tickets.openmrs.org/browse/TRUNK-412. This >>shows the page as it stands now. The idea is that if you haven't chosen a >>Source from the dropdown, then the text box after it will autosuggest >>possibilities from all terminologies in the DB. Whereas if you choose a >>source, it searches just terms in that source. >>> >>> >>>My further proposal is that if you have explicitly chosen a terminology, and >>>you type in a term that doesn't exist yet in that terminology, it gets >>>created on the fly (when the page is saved). That will be much easier for >>>the end-user than having to flip to a Manage Terminology page and add the >>>term there, before being able to map to it. And since the user will already >>>have chosen a terminology from the source dropdown, it'll cut down on >>>accidentally creating terms. >> >>Fine with me as long as we have a separate permission for creating reference >>terms. >> >>Ideally, we'd have separate privileges for editing concepts, editing >>mappings, and creating refererence terms. Anyone with all three could do >>what you say. Someone without the privilege to create reference terms would >>_not_ be able to add them on the fly. Someone with the privilege to edit >>concepts but not edit mappings would be able to edit other aspects of the >>concept, but couldn't change the mappings. >> >>The further point is that the term table has both a code and a name. I would >>say that when creating a term on-the-fly in this manner, we should create a >>term with just code, but leave the name blank. (It seems awkward to add name >>into the UI.) >> >>I agree that putting the code in as the name is probably not right. It would >>be nice to have a separate method for getting the displayable text -- i.e., >>that returns "name (code)" most of the time but returns "code" when the name >>is missing -- for consistent display throughout the application. >> >>Also, apparently someone had previously given Wyclif a To Do that both code >>and name should be required for terms, and when migrating current data with >>only codes, we should just copy the code into the name column. This seems >>wrong to me--I'd argue that if we don't know the name we should just leave it >>null, and not require it. (That said, we can still follow my proposed >>approach and copy the code the user enters for the term to create on-the-fly >>into name. Or, for a tougher-to-program and probably more confusing UI, we >>could make it such that if you type a new code that doesn't match anything in >>the autosuggest, we display a new Name field.) >> >>Since the name of the mapped term belongs to the reference terminology, >>pumping in some default value on the fly doesn't feel right. I'd rather just >>leave it blank if it's not supplied -- e.g. SNOMED 62315008 is less >>convenient for quickly reading than SNOMED Diarrhea (62315008), but it's not >>ambiguous without the name. >> -Burke >> >> >>> >>>Quick thoughts? >>> >>> >>>-Darius >>>________________________________ >>> Click here to unsubscribe from OpenMRS Developers' mailing list >> >>>>________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list > >________________________________ > 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]
