Ok, what I'm seeing is that it doesn't ask you when you import it or as a global property, but rather, it's an option in each import template, a check box where you can designate if to create an encounter.
Sound good? 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 Thu, Apr 12, 2012 at 10:53 AM, Ben Wolfe <[email protected]> wrote: > If you are importing from different sources that recorded data in > different ways you might want it changed. > > The middle ground here is that you present it as an option at each > import. But store it behind the scenes as a global property so that when > the next import is attempted the checkbox is either marked or unmarked as > the person did it the previous time. > > Ben > > > On Mon, Apr 9, 2012 at 2:45 PM, Joaquín Blaya < > [email protected]> wrote: > >> 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 >>> >> >> ------------------------------ >> 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]
