I'd like to hear others, but I don't think so because you probably (or perhaps should) have all of your imports behave the same way.
Joaquín ___________________________________________________________________ Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> Moderador, GHDOnline.org <http://www.ghdonline.org/> On Mon, Apr 9, 2012 at 2:35 PM, Ben Wolfe <[email protected]> wrote: > Wouldn't this be better as in option per import? > > Ben > On Apr 9, 2012 1:32 PM, "Joaquín Blaya" <[email protected]> > wrote: > >> Ok, will make this an option that can be turned on or off through global >> properties. >> >> Joaquín >> ___________________________________________________________________ >> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >> Research Fellow, Escuela de Medicina de Harvard <http://hms.harvard.edu/> >> Moderador, GHDOnline.org <http://www.ghdonline.org/> >> >> >> On Mon, Apr 9, 2012 at 1:48 AM, Andrew Kanter <[email protected]>wrote: >> >>> If we are going to support CDA-like interactions of data imports, then I >>> think we want them to have the option of showing as an encounter... >>> >>> Andy >>> >>> *-------------------- >>> 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:* Sunday, April 8, 2012 5:44 PM >>> *Subject:* Re: [OPENMRS-DEV] Should Spreadsheet Import Module create an >>> encounter? >>> >>> Offhand, I'd say that having the spreadsheet import module create an >>> encounter to group the obs it imports is a good thing. It's not a clinical >>> encounter, obviously, and the downside is that the patient dashboard would >>> show that encounter, but it seems helpful to have a handle to "what I >>> imported in that transaction". >>> >>> -Darius >>> >>> On Sun, Apr 8, 2012 at 2:20 PM, Burke Mamlin <[email protected]>wrote: >>> >>> Observations are not required to be linked to an encounter. If you want >>> to represent or will later need to know that a group of observations belong >>> to the same clinical transaction (e.g., observations created from the same >>> form, gathered within a single patient interview, etc.), then encounter >>> would be the solution. If you just want the observations in the database >>> and there isn't any natural grouping and/or any need to group them within >>> individual transactions, then encounter creation is optional. >>> >>> -Burke >>> >>> >>> On Sat, Apr 7, 2012 at 2:25 PM, Joaquín Blaya < >>> [email protected]> wrote: >>> >>> Hi, >>> I've been creating the document to improve the spreadsheet import module >>> (I'm attaching it here in case anyone wants to look at it and give me >>> suggestions. If you do please make them with Track Changes in the Word doc). >>> >>> One thing I came across was whether the module should create a new >>> encounter if it imports observations for a patient. From what I can tell >>> right now the import module inserts the observations, but doesn't link them >>> to an encounter (I have to admit that I'm guessing a little there because I >>> haven't gotten it to work on OMRS 1.6). This means that you can search for >>> the observation and even use it in the patient summary module or others, >>> but there isn't an encounter where you can see (and modify) what was >>> imported. >>> >>> I see that as being useful, but >>> a. wanted to check with others how useful they thought that >>> functionality would be >>> b. how complicated it would be do to that? For example, is there a way >>> for this to create an encounter without having a form linked to it and if >>> now form is required how would it display the data. >>> >>> Joaquín >>> ___________________________________________________________________ >>> Gerente de Desarrollo, eHealth Systems <http://www.ehs.cl/> >>> Research Fellow, Escuela de Medicina de Harvard<http://hms.harvard.edu/> >>> Moderador, GHDOnline.org <http://www.ghdonline.org/> >>> ------------------------------ >>> 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 >>> >>> >>> ------------------------------ >>> 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 >>> >> >> ------------------------------ >> 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]
