Sounds good to me. On Thu, Apr 12, 2012 at 3:38 PM, Joaquín Blaya < [email protected]> wrote:
> 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 >> > > ------------------------------ > 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]
