See AK> below -------------------- 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: Darius Jazayeri <[email protected]> >To: [email protected] >Sent: Tuesday, August 30, 2011 11:33 AM >Subject: [OPENMRS-DEV] Creating new reference terms on-the-fly on the edit >concept page > > >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. > > >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. > > >AK> I don't get the idea that a data entry field should also be a search field >and a display field... This seems to go against UI standards. I would prefer >if the field was simply used to capture the code. If you want to search by >code or name, you should popup a search box. I also don't like putting the >code and name together in a single field. Why not have two columns. The name >associated with a code might be different based on locale, or preferred terms, >etc. > > >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. > > >AK> I also don't know about this. Reference terminologies should not be added >to on the fly. It is going to cause management issues if these are updated >automatically or managed remotely. Not sure about other maps such as to PIH or >MVP. > > >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.) > > >AK> Agree. > > >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.) > > >Quick thoughts? > > >-Darius >________________________________ > 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]
