New Portal Patch v6.0.4 and v6.1.0

Updated 02/20/22
For all those that will be installing v6.0.0(4) patch that also use the patient portal, there have been some major changes to managing patient forms and documents from the Portal Dashboard.
The portal has also undergone a major restyle for better patient experience on small devices.

A clarification. I have been calling the forms created for eventual documents once patient submits in portal, templates. This is confusing to some so consider template building as a form builder.

Patch
02/20/22 Removed pre patch due to upcoming release of patch 4. The following instructions will apply to patch 4 the same.
Be sure to run sql_patch.php after install.

Please read this thread for background for additional info on setting up necessary Lists and capabilities:

Install patch.

  • Backup your openemr directory.
  • Unzip patch inside of openemr directory.
  • Run sql_patch.php from browser.
  • Set up your Groups, Profiles and Categories in Lists.

Setting up Groups, Profiles, and Categories are done in Lists. the following are the list titles:

  • “Patient Groupings”
  • “Document Template Profiles”
  • “Document Template Categories”

All the lists have defaults that are general assuming user will change list titles to be more appropriate to user application of portal templates.

Import existing templates.
Once above is done you will need to import all your existing templates from the current file system at:
sites/default/documents/onsite_portal_documents/templates. If you’ve templates assigned directly to patients then also upload as well.
These will install to the Template Repository so you can then assign to Profiles or patient Location and/or categories.

The patch includes the normal default templates that shipped with previous versions of portal. They are assigned to both Repository and Default Patient Templates.

  • A quick note about Default Patient Templates. Since any template assigned here always appear in all patient portals, they will not appear in the Patient Assigned Templates view. I recommend to not use this feature(Default Patient Templates) and delete all forms, except Help, from Default Patient Templates and assign as normal templates in Profiles. Though there are many that may only need the same templates for all patients, by all means keep and add additional templates from repository. This is the reason I left this legacy feature intact.

Assign Templates.
Time to setup for template assignments. To remove item from any drag and drop dialog simply drag the item from the right panel into the left panel.
Patient Groups

  • Drag and drop patients from left panel to appropriate group in right panel. I highly recommend using this feature because assigning templates to each patient from the location in Scope toolbar will be tedious to say the least. Plus once setup, all that is necessary to assign templates to new patients is to add patient to group on intake or registration.

Profiles

  • Again drag and drop the assignment. For Profile scheduling, Recurring is recommended if the template set is needed to be forms the patient needs to address more than once. If Recurring is not selected then once the patient has finished the form, it will never reappear unless sent directly.

Categories
You may assign templates to categories for further help with organizing. This is done in the Repository using the category pulldown. The effect of categories in portal is that all categories become titles in Document menu.

  • The red menu items means the patient has saved a document to their history and still needs to finish.

Finishing up
Once ready go to the Repository view and scroll to


To send or activate Profiles in portals. Note:

  • You activate Profiles that have Groups and Send profiles to Location if a profile is not assigned a Group.
  • Check the checkbox for the Profiles to activate. A button will appear anytime a change is made to a Profile checkbox .

    Click Update and now the profiles are active in portal.
  • For profiles that haven’t any Groups then the profile may be sent to one or more patients by selecting the patient(s) from the Location toolbar searchable multiselect. A Send button will appear in toolbar for sending to the Locations.

    This action has no affect on the Profiles with Groups and I probably need to hide as I do otherwise.

Patient Assigned Templates
You must select what you want to view from Location. You may select one patient, a group of patients or All Patients the click the search button. The view will show what templates are currently assigned and some status information. The only templates that may be deleted in this view are those specifically sent to the patient.

Some other neat stuff
A couple new template directives namely

  • {SignaturesRequired} when added to a template with patient signature directive will force patient to sign their document before being allowed to submit document to review.
  • {AcknowledgePdf:id or name:prompt} for example:
    Upload a pdf to repository where it will be assigned an id and template name.

    Then create and upload a template similar to:
{ParseAsHTML} {SignaturesRequired}
{AcknowledgePdf:80:Click to view and acknowledge}
Please sign here to acknowledge you have read and understand content: {PatientSignature}

Resulting in a rendered portal document:


and

Of course this is example pdf and currently fillable pdf is not supported however, soon will be.

I’ll soon be doing more documentation on template directives and template design. Until then this should keep you busy.:slight_smile:
Anyone that wants to contribute to documenting portal it’d be a great help!

3 Likes

@sjpadgett

I am a little lost, what are the groups for?
I am not sure how to set it up in “lists”
Also, I have to admit that I copied my templates before I finished reading the instructions.
Hence I have templates but did not set up groups.

in lists is it:

a new list named “portal-template-groups” with a list of:
group I
group II
group III
?

Wait, there already is a “Document template categories” and “Document template profiles” in lists. I am assuming I need to create a “Document template group” then.

I already create Patient Groupings in lists where user can rename/change Titles to their needs. You don’t have to have all the groups as long as there is at least one.
Groups is where you can categorize your patient populate for use in portal.
Hopefully you’re ran sql_patch.php for upgrade.

1 Like

I did run it, however, for some reason, the confirmation was

successfully updated 6.0.0(3)

which I found odd. I had meant to look up the version of the portal, how do I do that? It does not show up in Portal dashboard.

Here it is:

Patient Portal v6.0.0 (3) Copyright © 2022 By sjpadgett@gmail.com License GPLv3

I think my update did not work, let me try it again.

No it worked. The portal follows the openemr versioning.
I’ll check to ensure grouping is in patch

I do so it should be in lists and Groups in dashboard

1 Like

This is what I get when I patch:

after uploading and unzipping “portal_patch_v6.0.4”

I probably should have named the patch portal_patch_v6.0.3 to avoid confusion. But, it will be meant for patch 4 so…
Portal versioning always follows openemr versioning. I have thought about maintaining portal separate for releases but this will have to wait until it’s is made into a module.

1 Like

Wait a minute, I found it, the groups where there, so sorry for the confusion

Consider changing this above to:

Set up your Groups, Profiles, and Categories in Lists, under the titles:
    "Patient Groupings"
    "Document Template Profiles"
    "Document Template Categories"
1 Like

This is amazing, love I!

This is amazing, patients can re-do their HIPAA, insurance assignment and other consents yearly!

1 Like

Hi @gutiersa Thanks for the input. I’m not used to positive comments!:slight_smile:
I can’t wait to do the template builder. Although, somebody pointed out on the Saturday call that perhaps “template” is misleading and can cause confusion. I agree so I’ll probably start calling them forms that then become documents when patient dispose in portal.

1 Like

Hmm, “forms” does make sense, definitely.

@sjpadgett

Hello:

I have installed the latest patch above, and have been working with it today. The red lettering for required fields in the layout forms looks very very nice, I like it. Also I see that the alignment has changed a bit, I do need to finish reading all instructions above.

However, my portal is broken from the patient front end. I get this error:

Uncaught Twig\\Error\\SyntaxError: Unknown "fireEvent" function. in openemr/templates/portal/home.html.twig:331

I am not sure if I am missing a PHP module. I did upgrade my server from PHP 7.4 to PHP 8.0 in the last week or so. Hence, I am not sure.

Another bug (I think) is that on scheduling a patient, I have selected “Established patient” as my default visit type, but the system is now using “Office visit”. That changed after the most recent openemr update. (I think! Should I post that here or in github, or am I missing something?)

thanks

Hi Sandra,
For the twig error I suggest you go to src/Common/Twig/TwigExtension.php and check the file exist plus the permissions are correct.
Also recommend that you clear your browser cache and also your smarty cache.

1 Like

Hmm, I have src/Common and src/common directories. Twig/TwigExtension.php is located in both directories, with the appropriate owner. The permissions for the actual extension is 0644 in both dirs.

Why? src/common is not a namespace and I believe TwigExtension.php is new to v6 so may not be loaded by autoloader so instantiation relies on namespace. At any rate, delete the src/common(lowercase) directory.

I’ve installed this patch numerous times(both new install and upgrade) and haven’t seen this however, who knows right!

1 Like

Hmm, I don’t know, check out how much stuff I have in src/Common:

It seems to have been installed/updated 1/15/22 with the “6-0-0-Patch-3” update.
I am hesitant to delete it.

Commenting out lines 331 and 478 in openemr/templates/portal/home.html.twig did the trick, but what portal functionality am I missing out on by doing that?

This is the contents of lower case src/common:

lower common

…Oh, wait a minute, ok yes, I will delete the lower case one.

Leave the uppercase src/Common alone. I said delete the lowercase directory src/common!

Patching out the event dispatch won’t hurt anything in portal and is there for module developers.
Still you shouldn’t have to do this.

1 Like