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<[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]
