Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

SMPP patient linked or not linked

General Discussion

Last Post by ronmoses 8 years ago

9 Posts

9 Users

0 Reactions

63 Views

RSS

jairoclaustro

(@jairoclaustro)

Posts: 6

Active Member

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

chaddix

(@chaddix)

Posts: 177

Estimable Member

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

jryan

(@jryan)

Posts: 119

Estimable Member

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

petemarkey

(@petemarkey)

Posts: 373

Honorable Member

You'd think so right? Not so much

Posted : February 13, 2017 7:45 pm

angelahunsberger

(@angelahunsberger)

Posts: 290

Reputable Member

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

sborchardt

(@sborchardt)

Posts: 218

Reputable Member

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

cecild

(@cecild)

Posts: 314

Reputable Member

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

tcross

(@tcross)

Posts: 165

Estimable Member

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

ronmoses

(@ronmoses)

Posts: 158

Estimable Member

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. 🙂

CPSPortalStatus

Posted : February 17, 2017 6:17 am

24 Forums
9,940 Topics
39.9 K Posts
1 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed