I would estimate that 99.9% of reference terms will be created during a bulk upload. I've never created a single one manually in the past. I hesitate to even recommend the feature of single ref term creation.
Ben, I'm unsure of the licensing around distributing terminologies. Certainly, most terminologies can be used in 3rd world countries without charge but I'm not sure that openmrs can package and distribute them. Glen On 2011-09-01, at 11:16 AM, Ben Wolfe 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]
