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 _________________________________________ 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]
