Major Patient Portal restructure

Let’s face it, the portal is dated.
The major issue IMO is the top level menus. On small devices these menus turn to hamburger styles making navigation clumsy and frustrating. So they need to go as primary navigation.
To achieve this I plan to create a dashboard landing page. Similar to the providers portal dashboard.
From dashboard, components will be called as apps.

For the initial phase I plan to remove the custom portal theme and replace with BS using our Dark and Light theme selectable by the patient. Then a navigation dashboard.

I just wanted to let people know where I’m heading to perhaps save some time trying to make the current navigation workable. My main focus is patient documents.

1 Like

Good initative. What are you thoughts here?
Rewrite the patient portal completely?
What platform? Angular?
-ViSolve OpenEMR development Team

1 Like

Very worthwhile idea. With the great work done on questionnaires, a better layout will help users take advantage.

1 Like

i was curious if anyone is using tablets in their practice for fill of history and/or demographics/ or just patient checkin data? The portal doesn’t work well for that type of activity for local data input.


One main reason for portal restructure is to gain a better responsive interface for patient intake/assessment forms.
Currently there is a feature under patient documents to pull up a portal form and fill out from main openemr. Perhaps can init in reception on tablet and handed to patient

@sjpadgett I can carve out some time to work with you if you want some help. I would like to spend more time in the portal. I have a couple of features that can be brought in while renovations are going on.

1 Like

Hi @engg Welcome,
It’s always nice to hear from our long time friends at ViSolve.
Sorry it took so long to answer you but been out lately.

I don’t have a plan to rewrite portal in any framework but instead to keep main portal code as simple and dependency free as possible then leverage modules for the nice apps we want to achieve.

I will say that eventually I need to rewrite the secure message app as it is written in angularjs which is deprecated I believe.

I always welcome input from your group so follow my issues and PR’s

Thanks so much for the offer @juggernautsei and sure I’d love the help however great or small.

I’m currently getting ready to put up a PR once I finish modifying our Header class to support the portal theme inclusion. Once Brady and Robert approve/ensure I’m okay on approach in Header class you’ll be able to pull my branch and we can collaborate from there.

Be nice if Robert would jump in as well. Maybe better care team support!

What is your most interested value add you’d like to see and would it be a module?
It could be our example portal module for new app integration dashboard.

@sjpadgett it is nothing so grand as that. It is just a small thing to allow the patient to take a picture to upload.

The old secure message editor I had used to allow that. I think you and add a drop/upload image to new editor(ckeditor).

People need to be able to take a picture with their mobile device or webcam for their ID cards and such like. Can we implement password less entry?
The tools to do it already exist in the portal IMO.

1 Like

@juggernautsei and all others
I emailed you a testing patch for v7.0.1.
It should have everything I just merged into master.

I’ll try to put up a short video of various changes.

If anyone would like to test/install what will eventually be in patch2 as I build this out let me know and I’ll put it up here for download.

1 Like

ViSolve is in the process of enhancing and releasing their Next version of patient portal that can also work with OpenEMR 7.0

The next version will have increased, performance, functionality, responsiveness with FHIR support along with some AI function

Please do let us know if any specific functionality is a “hi want” for OpenEMR. You can play with the current version here
Click on the patient portal link
-ViSolve AI Team

Main problem with standard portal is the idea that set of scripts designed to operate a clinic is used for use case that would be the “custom” report in standard code.

Over years we have found portal needs to be a separate repo that at minimum shares the database and at maximum shares the classes to expose data models. For standard project hard-link approaches could be to rip all portal related code into a brand new repo with clinical version as dependency. A soft-link but with database access would do most processing separately but use fetch api for leveraging the model portion. Of course a FHIR app would be best for future certifications and integrations.

I’m aware. I’m gradually getting there by first tearing a single page app down.
I decided to start with portal documents and pulling that out into a separate app. Once it’s call boys the separate app I can then get the responsive working i.e get the frame and frame sort it out.
In the demographics profile is next where I’m going to convert it over to API other than the rest API in the current framework.

What I hope you folks can get is that I’m only one person with one working hand to type with and as I age possibly a half of brain! :slight_smile:

Hopefully after patch 2 Steven and I will have the questionnaire essentially done with the questionnaire endpoints which Steven already has done.
Steven is also already developed a questionnaire smart app that is very nice in my opinion. That coupled with one time that I have close to being fully integrated should speed things up with possibly creating a separate repo or essentially bringing it in as a core module. So guys in the end there’s much to do plus I have all the other stuff going on with administration duties. I just asked that you all bear with me.

Hi @sjpadgett
So, you’re doing a major portal restructure? Is this topic still current? I’m in awe of all the work you’re doing and have done on this portal in the past few years; it’s become very capable and useful tool for healthcare delivery.

I’m curious about this new portal restructure: how’s it going, what are the revision priorities and do any options exist for specific feature requests?

I ask because over the past, I as a support pro have received several requests from customers for modifications of the username/ password credential creation method. I’m curious if these things might be considered for revision, or will they remain as they are, and depend on 3d party development?


  • Could the user be allowed to set the patient’s username and have it stay the same, rather than having it be taken from the email and changing every time the credentials are re-issued? Or just use the trusted email then leave it the same despite credential re-issues.
  • Would it be possible to make the randomly assigned password meet the requirements, rather than being too short and a new compliant one needing to be made up?
  • When patients create their permanent credentials, they can’t see the password they are typing in. Is that something that can be enabled?

Anyway, if these sorts of feature requests aren’t on the game plan for the revision, I understand.
Hope to hear some updates re: the effort- or are they in a forum thread I haven’t discovered yet?
Best- HT

1 Like

Hey Harley,
I just merged a PR for next patch that get the portal to a place that I can start moving features to a module. I renamed the Quick Start panel to Dashboard and added an event to add cards/items to menu/Dashboard. I know of at least one group that are hoping to hook into the portal to allow patient SMART App launches.
I have started a portal feature add on module as both an example and for others that want to add to it in core. I’m thinking of moving the Patient Documents to it first.

First currently the username stays the same on reset unless email changes. I don’t like using the trusted email because it is designated for Direct Email. But I think I look at both to ensure a username. Let me know if I’m mistaken.

Yes of course. That makes perfect sense and is an oversight. I’ll see if I can get to for patch.

I understand that seems to be the trend these days and personally in my experience I find useful. I will see what I can do depending on how much time I have for next patch.

I have added the ability to send notification by SMS/email to patient by admin users that provides an auto login and renders a portal document needed by users. This capability has spun off of my one-time token class that was created for TeleHealth module and sponsored by ComLink.
Everything is in place where when users reset portal credentials they may chose to send a one-time and set the expiry time to what ever they wish say 30, 90 or 180 days. Then they would request a renewed token.

I have many capabilities that are unknown to many because I simply have failed to write documentation.

Anyway Harley thanks for the post and also all the time and effort you and Mi-Squared put into the excellent support supplied to the community on our forum and documenting portal. Though I feel bad for you because it seems like every time you catch up on documentation, I change everything around in portal. Maybe a few choice words uttered and directed my way under your breath! Don’t blame you!:slight_smile:


Hi @sjpadgett
Thanks for the quick, informative response! For one thing, I’ll refer some of our customers to it who have been asking these questions, they can respond to you themselves if they have questions but this should make them happy :slight_smile:
For the other, I’m happy that you’re upgrading the portal and no prob re: needing to re-do the documentation, it’s job security!
How are your code commenting habits? Back in my C++/ COBOL/ VBA coding days they had us put almost as much text in the comments as we used for the code. I do not know php, but if yours is commented enough, when I have the time I might be able to learn how to look in the source and find hidden features to include in the docs?
And last, are you posting updates re: the portal restructure somewhere else or would this thread be a good place to check for news?
Thanks again, and ROCK ON!
Best- HT

1 Like

I sparsely comment in code and limit to items that might affect upstream/downstream. Sometimes general notes. This bad habit I’ve gotten into is just pure laziness and one I should correct!

Depending on what changes I’ve made determines where I may post documentation. This thread I’ll probably start posting links to where I’ve documented more in depth.

For next patch you’ll see me catch up on more specific documentation of features. I sometime don’t remember something I’ve done until I run across in code!:slight_smile:


v kool, will look forward to that!