Notifications
Clear all
Topic starter
IS there a way to see if a patient is linked or not linked to make it easier to notice for SMPP? I mean in the patient chart do any of you have an easy way to know if the email is already registered and linked to SMPP?
Posted : February 13, 2017 10:05 am
We use the presence of a PIN (OBS: PATPORTALPIN) and put something in the banner to indicate that the patient is signed up.
However, we have been considering moving to the SureScripts sign-up model that doesn't require a PIN. Because this means that PATPORTALPIN will no longer be updated, we need to find a work-around prior to switching.
In addition, this method isn't perfect, because all it tells us is that the patient was given a PIN. It doesn't tell us if the patient ever linked his/her chart or if the patient has ever logged in to the Patient Portal.
Posted : February 13, 2017 10:22 am
We use banner also but went with the method of contact so if the patient chose secure message it shows that in the banner so we know we can message them that way.
Portal Contact: {if LASTOBSVALUE('METHCONTACT') == NULL then "None" else LASTOBSVALUE('METHCONTACT') endif}
Posted : February 13, 2017 1:19 pm
You'd think so right? Not so much
Posted : February 13, 2017 7:45 pm
My 2 cents....there is not a great way to tell if the patient actually signed up from the portal. You may need to keep the PATPORTALPIN for reporting purposes. My only suggestions are to:
1. Embed an obs term on any portal eform that would feed back to the banner to show they've communicated via the portal.
2. Redirect the success messages to a link to update method of contact. METHCONTACT
PS: I do portal optimizations if anyone is interested in a "make-over". I can evaluate what you have and either show you how to spruce it up or do it for you. email me if you are interested in an example: [email protected]
Posted : February 14, 2017 1:36 am
We have developed a work around since we are no longer printing the PIN letter that triggers the OBS. I run an inquiry report to show any patient that were seen that have an e-mail listed but the METHCONTACT is blank. Then I go into each patient copy the e-mail and check to see if they have an active portal account. If they are active, I open the encounter type Method of contact and fill that out. It is a tedious process, but it is the only way our staff can tell who is signed up. Surescripts made the sign up process easier, but missed a big piece of the workflow. We currently don't have huge numbers, so I am able to manage this process.
Posted : February 14, 2017 5:01 am
I agree there does not seem to be a good way. We actually use the patient banner by adding "Portal User" to the notes so it appears in the banner. We like the default banner and I have not been able to recreate it or have I had any help from GE on this issue. Its all about what option best works for your environment.
Posted : February 14, 2017 7:33 am
We recently wen to and auto registration application that was created by MD EMR and it puts a wingding that looks like a computer screen at the end of the patient name in the banner when they are linked. It is a very efficient way to set the patients up. You can determine your own workflows as to when you want to auto register a patient based on your practice workflows but this makes it really easy and you don't hve to change your banner or create a new one. Also lots faster than pin generator but of course there is a price associated with it.
Posted : February 15, 2017 3:10 am
I created a system for just this purpose, involving a stored procedure that populates a custom table on an hourly basis, a computed column in the PatientProfile table, and the patient banner. It seems to work pretty darn well. I haven't gotten around to blogging about it yet (shamless plug: http://www.the-mosi.net/geblog/) but I'll try to lay it all out here if I can.
First, the stored procedure. It's called cmc_UpdatePortalStatus and we have a job set up to run it on an hourly basis. It reaches out to the Enterprise database to look for registrations (because we don't fully trust the MU 510s), then it looks for 510s (because you have to trust them a little bit), then it looks in the DOCUMENT and OBS tables for evidence of declines that weren't logged as a 510. It takes all of that and populates a custom table called cus_PortalStatus, containing the status of every active patient in the database.
Then we have a function called cmc_fnPortalStatus(PID). All this does is return the portal status for a patient, based on their PID. We use this function in a calculated column called PortalStatus in the PatientProfile table. (The function script automatically drops and re-creates the calculated column.)
The function script also contains a commented section that documents how to get the portal status into the banner. This involves editing mellib.txt, mldefs3.txt, and the banner itself.
I've attached the two files to this comment, hopefully they'll come through. I'm more than happy to answer any questions. And I should probably stop being lazy and add this to my blog already. 🙂
Posted : February 17, 2017 6:17 am
