This patch updates signon process of onsite patient portal.
Part of the change introduces a way for normal emr user to ‘impersonate’ a patient for this portal functionality. This will allow staff to logon to a tablet for use by the patient while at office.
The code exposes a hook to group access - e.g. if a single person is responsible for multiple family members, they can have a single login for access to multiple patients’ portal information or many other administrative situations where someone needs access limited to specific set of patients.
The onsite portal seems to use its own user management as well as session management. We can leave user management as it is at this time. But it would be better to leverage standard session management routines for patient sessions as well. This will let standard code be invoked subject to normal ACL restrictions rather than having to recreate every reporting function required by the portal.
Is there any set of guidelines to follow when incorporating restoreSession and verification without going through login.php?
One can think of same issue when APIs are invoked. Those system level users should go through same access control like online users.
Haven’t had time to review/test this code yet. One thing to note is that the portal was purposely kept separate and compact for security reasons; since having a onsite patient portal turned on would mean the instance would likely be available on web in public domain(which is unlike OpenEMR itself which has less users and can be protected by either not being on the web or via ssl client certificates etc.). I am not saying we can’t expand the patient portal; just need to ensure place security at the forefront when doing this.
The (?) in the topic header relates to the term onsite which is misleading. We are looking at deploying a copy emr webserver for patients that will communicate with production database with its separate webserver for internal users
With a general purpose display engine, we currently capture and transform most of the standard layout pages. This eliminates need to maintain dual logic - e.g. current documents download is a feature replicated in patient report.
Major issue is globals.php not playing nice with portal session. Using same session mechanism will eliminate need for manipulating globals.php call from portal. Session will have portal user information. Then if we assign a portal user acl role, we can look at exposing selective functionality with minimal code changes.