Setting Patient Context

rajitkei wrote on Tuesday, January 03, 2017:

Is it posisble to pre-set patient context in OpenEMR? Imagine OpenEMR is showing Patient A’s schedule. I want to be able to change the openEMR view to show Patient B’s schedule by calling an API of some sort. I know there is a HL7 protocol implementation called CCOW which allows this kind of context switching operation. Anyone here in the forum tried this or has any knowledge if eopnEMR supports CCOW. Any guidance, appreciate. Thanks

mdsupport wrote on Thursday, January 05, 2017:

It is not clear what you are looking for. Your HL7 reference is misleading. HL7 is just a protocol - it relies on source and destination systems to act on contents of communications.

If it is just scheduling, you could search appointments from calendar and add/change appointments for any patient. But if you want to explore more details about multiple patients, you have a bigger issue. This application is not object based. It uses global variables like active patient, active encounter etc. between multiple frames.

A system to system interaction can reliably manage 1000s of “contexts”. Now imagine a busy doctor looking 2-3 screens that look alike except some context indicator. That will be a receipe for some fatal errors.

rajitkei wrote on Friday, January 06, 2017:

My use case is this: we are in call center business. A patient calls in and call is routed to a call center agent. Call Center then identify patient with patient phone number and then pulls patient record in EMR. We want to automate this. Based on the callerId of the patient, we want to open the patient page in openEMR programmatically. After reading CCOW protocol of HL7, it sounded like this protocol can allow us to programatically set the EMR screen to the patient chat. Any input, appreciate.

mdsupport wrote on Saturday, January 07, 2017:

Application uses browser session so concurrent chats with multiple patients should be handled by putting a old frame shell on top of standard code so that “window” is sandboxed. Interesting.

medfetch wrote on Saturday, January 07, 2017:

Anything is possible. As a call center, would you be focused soley on openEMR implimentations? If so are they on the same server? Do they share the same database? Lot’s of questions…

The incoming DID would be linked to the correct openEMR database. The incoming callerid, if present (and not forged) would be passed to a variant of the The Patient Finder form to open the correct chart.

That being said, our call center/answering service links our DIDs in their call center software. Like all call center software, our “page” is displayed with instructions on how to answer the call, and how to link to our secure installation of openEMR. They have their own login username and password to our openEMR, which has restricted access (based on openEMR ACLs) and a unique, very limited, role-based menu (Answering Service). They login manually. Given the limited tasks they are charged with, there is minimal training required to learn openEMR. They perform the usual answering service functions in addition to being able to add new patients and book/change appointments.

What I think you are essentially asking for is a secure way to login and automatically pull up a patient record in one step, with one link. There are plenty of security risks here that will need to be addressed for each client’s type of install. It is not a part of the base openEMR codebase.

bradymiller wrote on Monday, January 09, 2017:

Hi,
Would it be helpful to have ability to place the information in the http address when login. In the past, I did work on code that allowed placing the patientid(id or pid as I recall) in the http address of the login screen link, so when logged in, it would then open that patient(and if used a desktop app that auto fills in credentials, then a link from the application would then open the patient window in OpenEMR). Could also add more flexibility to this to go to Finder screen for example with other information like phone number. My code never got into the codebase but I could dig it up which could be used as a starting poing if this would solve the issue.
-brady
OpenEMR