Is there a way in GE to tell if the patient has a Portal account and if we can send things to that patient via the portal? This question has come up several times by our providers. They would like to send things via the portal but they are not sure who they are able to send to.
Any help is much appreciated.
We put the following into the patient banner :
{if (LAST_SIGNED_OBS_VALUE(“METHCONTACT”) <> "") then "Portal Access" else "" endif}
We have this code in the patient banner to identify who has been issued a PIN:
{if OBSANY("PATPORTALPIN") == "DECLINED" then " (" + "PORTAL DECLINED" + ")" else if OBSANY("PATPORTALPIN") <> "" then " (PORTAL)" else "" endif endif}
If a patient has logged in- there should be an entry in their chart that says " Clin Updt MOC". That is for those who have changed/ added any info to their portal account.
In messaging tab you can check if your letter/ document you sent has been received/ read in the SENT folder- it will be unbolded.
I tried adding the code into the Patient Banner. The issue we are having with it is patients when registering at the front desk for their appointment do not specify their Preferred Method of Contact. So we are still having to search to see if that Patient is on the Portal. This creates a lot of extra work for the Nurses and Providers.
We are also struggling with this and found out that we cannot add the code to the Standard banner, but have to make a custom banner. The other wrinkle is that our standard banner contains our patient photo and you cannot get the photo to populate onto the custom banner you have to create....Not very useful if you ask me!
I agree!!!
we made the "preferred method of contact" part of our portal registration steps. Once the patient verifies their identity, they submit permission to receive things via the portal. In our case, we don't consider this the preferred method of contact nor do we call it that, because we will never notify them of critical results via messaging versus phone, but it allows us to see who is registered versus who declined.
We've taken it a step farther, and it may be farther than many are interested in taking it but it's working for us. This involves a combination of SQL and MEL.
First thing to bear in mind is the difference between a patient who's been issued a PIN, and one who has actually gone to the site and registered. It's the ones who've registered that count.
To get a count or list of patients who've been issued a PIN, query the Centricity db's DOCUMENT table for records where DOCTYPE=1623583212002750 and STATUS='S'.
To get a count or list of patients who've actually registered, you have to query the Portal db. This may or may not be on the same SQL Server instance as your Centricity db, so there may be some server linking involved before you can do the following. In the following query, which is run from the Centricity db, the Portal db resides on linked server EMRDMPP. We're looking for a list of patient identifiers (PIds) for patients who've registered:
SELECT p.PId
FROM EMRDMPP.Enterprise.dbo.KUser ku
INNER JOIN EMRDMPP.Enterprise.dbo.DCommunityAccount dca
ON ku.UserID = dca.UserID
INNER JOIN EMRDMPP.Enterprise.dbo.DPartner dp
ON dca.DCommunityAccountKey = dp.DCommunityAccountKey
INNER JOIN PatientProfile p
ON dp.Identifier = p.PId
We can use that list of PIds to pull whatever kind of information we want from the Centricity db for reporting, etc.
We can also use it to maintain the "preferred method of contact" in our registrations, which is how we control the banner display. We have a SQL Agent job that runs nightly, and updates the PatientProfile.ContactByMId field to either "Secure Message" (if they have registered) or "Letter" (if they have not):
;WITH cte_PIDS AS
( SELECT DISTINCT p.PId
FROM EMRDMPP.Enterprise.dbo.KUser ku
INNER JOIN EMRDMPP.Enterprise.dbo.DCommunityAccount dca
ON ku.UserID = dca.UserID
INNER JOIN EMRDMPP.Enterprise.dbo.DPartner dp
ON dca.DCommunityAccountKey = dp.DCommunityAccountKey
INNER JOIN PatientProfile p
ON dp.Identifier = p.PId)
UPDATE p
SET ContactByMId = CASE WHEN c.PId IS NULL THEN 1648 ELSE 226704 END
FROM PatientProfile p
LEFT JOIN cte_PIDS c
ON p.PId = c.PId;
Now we have a value we can look at for the banner. Next step is to add this value to a data object in one of our mldefs*.txt files. We chose mldefs3.txt, and we added it to an object we'd created some time ago called _EstablishedPatient:
Object: _EstablishedPatient
Table: PATIENTPROFILE
Refresh: RBook
Property: Snapshot
Property: Prepare
Field: NewEstPatient Type: String Length: 25
Field: ContactByMId Type: Long
Filter: PatientFilter, PatientProfileId = Patient.PatientProfileId Hidden
Note that this will not work for you as-is, because we have added a calculated field to PatientProfile called NewEstPatient that lets us easily determine whether a patient is new or established. (That's also in our banner, and I'll be happy to make those details available if anyone is interested.)
Next, this needs to be in mellib.txt:
global _MELNewEstPatient = _EstablishedPatient
Finally, this goes in the banner:
{! fn CONTACT_METHOD(){
local a = getRow("_MELNewEstPatient",0,"ContactByMId")
local ret
if a == 226704
then ret = "MyChart"
else ret = ""
endif
return ret
}}{CONTACT_METHOD()}
That puts the text "MyChart" wherever we want it in the patient's banner.
we are looking to incorporate preferred method of contact and whether the patient is on the portal or not into the banner - I've tried all the suggestions so far with absolutely no luck.
Any other ideas?? All help appreciated.
Sue
Sue, What is your current registration workflow?
We send out a PIN via email, the patient registers/verifies their identity and then submits the preferred method of contact. This updates the obs term in the chart, which updates our banner. We have 5 different terms that populate our banner. No portal access (no email in registration), verify (email in reg, no PIN issued), pending (PIN issued, registration not complete), messaging (patient is signed up for the portal), portal declined (patient declined portal access). It makes it easy for staff to know what needs to be done.
I can email you our banner language.
But, like I said previously, we don't consider this a preferred method of contact, we use this more for seeing portal access. We will never only contact someone electronically, whether they prefer that or not. We don't let them put home phone, or email, or work, etc.... so we have modified this to fit our purpose.
Malissa:
If you could email me banner language, that would be great - we are looking for 2 separate new entries - whether they are on portal or not, and separately, their preferred method of contact.
thanks,
Sue