Ah yes, money. I always forget about that. :-) Mapping is also possible to other installations, module sources, etc. So it certainly won't be 99.9% for implementations.
Ben On Thu, Sep 1, 2011 at 9:43 PM, Glen McCallum <[email protected]> wrote: > 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] > _________________________________________ 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]
