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]<mailto:[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]<mailto:[email protected]>> wrote:
>
> On Tue, Aug 3...
________________________________
Click here to unsubscribe from OpenMRS Developers' mailing list
________________________________
Click here to
unsubscribe<mailto:[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]
