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**** > > ------------------------------ > > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > **** > ------------------------------ > 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]
