Currently patients get access to both the FHIR api and patient portal through the Allow Patient Portal flag. It seems like we may want to either rename the flag to explain the dual purpose or we break this up into two flags. I can imagine use cases where patients don’t want to use the patient portal but do want to use a 3rd party app (or vice versa). So the flags I’m thinking we add are:
Allow Patient Portal (grants patient access to view,download, transmit and other portal functionality)
Allow 3rd Party API Access (grants patient access to the FHIR api so they can use things such as Apple Health or any other SMART on FHIR application).
If we want to keep a single flag I suggest we rename the flag to make it more clear what is being granted. This is the easiest and simplest option but will require some rework for language translations
Allow Patient Portal and 3rd Party API Access Grants both access to the patient portal and to the FHIR api.
I bring this up as I’m in the middle of working through the Automated Measures Calculation for CMS’s MIPS program (US regulations for those of you outside the USA) and we have to handle users who opt-out of having access to their data to satisfy the Patient Access Promoting Interoperability requirement. Right now we key off the single flag but as I’ve been thinking about it I wonder if we need to support more granularity in the opt-out criteria.
In case anyone is wondering for MIPS your patient will still qualify to be counted in each performance period if the patient opts out of patient portal or fhir. This is because OpenEMR gives the patient access to all of their historical data the moment they opt back in.
It’s unclear to me why we even have a separate allow patient portal.
The patient role is the patient role. Meaning, patient should have access to any available resource guided by their selected scopes.
Access to the portal would be determine from their selected preference in demographics.
Access to the portal API should be automatic for any patient imo.
I’m not sure if the allow patient portal is linked to a specific HIPAA/HITRUST or some other healthcare law allowing the patient to restrict how their patient information can be accessed. I know a number of places I visit for healthcare ask it, it’d be great to get someone to chime in if they can trace that feature to a specific legal requirement.
One challenge for automatic access is that to access the API you have to have login credentials which are generated by the clinician if registration is disabled. If registration is always enabled then they’d have automatic API access due to the credentials being created.
HIPPA is pretty clear on patient rights concerning access to their health care information.
What is troublesome is what rights the patient gives the provider to disclose. All our APIs should be aware of what info patient grants the EHR. This is recorded in demographic choices. This means that the HIPAA privacy agreement is signed.
Whether the portal is enabled or not should not have an impact on API access to their info. Their recorded response to the HIPAA allowed permissions would. These are generally collected by user on patient intake.
Even if registration is enabled, someone would have to generate the credentials. So some responsibility falls to both the patient and user.
For AMC if patient doesn’t have credentials then that would be on the patient. Unless I’m missing something.
For some reason I thought patient registration generated patient portal credentials. Guess I need to revisit that process to familiarize myself again with it.
If I’m understanding you correctly you are saying that we should not add a flag for ‘Allow 3rd Party API Access’ and leave the Allow Patient Portal flag as is in the Demographic Choices section.
What we would have to do is unlink the generate patient credentials button from the Patient Portal so providers could still generate credentials even if the patient portal is turned off. Otherwise the patient would have no access to the api.
True that if the user has decided to not allow portal access and to comply with HIPAA in other ways, I can see the issue.
Unsure what the solution is. Possibly instead of looking at the global for portal enabled we can look at the patient choice for allow portal to enable credential button. Giving user ability to generate the credentials without allowing the portal.
However this causes another issue where the initial password is temp and patient is force to change on log in so, unsure what would happen through the API.
From a security perspective, there is a definite benefit to be able to turn both these features on/off independently for entire system. No reason to have these features “open” from a security perspective if the feature is not being used by the practice. For the patient fhir api, would probably add this in the Connnections globals section maybe something like Enable OpenEMR Patient FHIR REST API. What is legal or not can be decided by the user (for example, a boutique clinic, vet clinic, or clinic outside us in low resource will have very different contraints).
Edit: above Allow 3rd Party API Access global setting name also ok
So I’m in the middle of implementing this AMC measure now and we already have flags to disable FHIR for the entire practice in the connectors tab:
Enable OpenEMR Standard FHIR REST API
Enable OpenEMR Patient Portal REST API (EXPERIMENTAL)
What we DON’T have is a flag at the patient level for turning on and off 3rd party API access. At this point I’m leaning towards just leaving it alone and using the patient portal flag the same as the FHIR access, but we still have the issue that if a patient opts out of the portal it also means they turn off 3rd party app access. Do @brady.miller and @sjpadgett think that’s acceptable?
@adunsulag too me, if a practice decides to not support portal then we can either use the existing Allow Patient Portal in demographic choices or add a new flag perhaps, Allow Third Party Apps as well.
It’s the easiest convenient way to keep at the patient level. This way if practice has the new connector Allow Third Party API Access set, it’d still be up to the patient.
@adunsulag ,
For security purposes should have a separate global. If a practice is not using patient portal or not supporting third party apps then much better to cut off that specific vector at the knees (ie. if a vulnerability shows up in one of these uses, then no reason for practices that do not even use one of these to be vulnerable).
Sorry, i just realized i repeated myself (should of actually read this thread ). I can’t go into details on this since specific to security, but the ability to turn on/off specific parts of openemr’s features has definitely limited the scope of openemr security vulnerabilities in the past (and vice versa the ability to work around these global limitations when not done robustly has expanded the scope of openemr security vulnerabilities).
Goodness, I don’t even think I answered your question so can disregard my posts (looks like you are using the already existent global FHIR flag which is fine). Haven’t had my coffee for the day. You are asking about the per patient permissions. On that I agree with @sjpadgett post.
What I’m concerned about is that we’ve seen in several instances people getting database exceptions where the MySQL/MariaDB row size exceeds the maximum allowed because patient_data has gotten so many columns now (and LBF lets them add more). I could add a new column there for allow_third_party_api but I’m concerned this will continue to exacerbate the issue.
It’s row size exceeding limit. InnoDB is 8126 I believe however, since we’ve started using utf8mb4 that added another byte. We probably need to convert to Dynamic from compact or change varchar(256) to tinytext in upgrade.
The row size limit in patient_data was in theory dealt with awhile ago (newly created columns in layout editor are text and when we add columns to that, they are text). Problem more arises in legacy where this wan’t case and/or a mariadb bug where it wasn’t accurately counting this (then all of sudden when upgrade to a newer version of mariadb it breaks). We could really put this issue to rest by converting all the current fields in patient_data table in database.sql (and then the upgrade script for those items changed) from varchar(255) to TEXT (like we had to do for the eye form table in the past).
EDIT: btw, I think this was not done previously because of concern that the varchar(255) items are all set to default to ‘’ whereas text will default to null (so would require some testing, but guessing not big issues would arise).
). I can’t go into details on this since specific to security, but the ability to turn on/off specific parts of openemr’s features has definitely limited the scope of openemr security vulnerabilities in the past (and vice versa the ability to work around these global limitations when not done robustly has expanded the scope of openemr security vulnerabilities).