I would like to keep track of missing documentation.
Kindly add to this thread version 6 documentation that needs to be done.
If you are a developer, and have added or modified code, and you know there is no entry on the wiki for your changes/code, add a link or entry here as well. I will be happy to create the document in the wiki.
I would like to start to get organized.
I am listing the improvements here. My goal is that if anyone knows of a thread, or a wiki page, which elaborates on the following improvements, he/she will list it in this thread such that I can update the wiki. Anyone may refer to the improvement by the number only and add the links.
Numerous User Interface Improvements
Speed and Performance Optimizations
New Support for FHIR (Fast Healthcare Interoperability Resources)
New Support for SMART on FHIR
New Support for OAuth2
New Support for OIDC (OpenID Connect)
New Support For EasiPro (Patient Reported Outcomes)
New Support for Kubernetes
New Docker Support for Raspberry Pi
New Support for Argon Password Hashing
New Database Support for utf8mb4 Encoding
Patient Portal Improvements
REST API Improvements
Patient Dashboard Improvements
LDAP Improvements Including SSL Support
Payment and Batch Payment Improvements
Fee Sheet Improvements
Patient Flow Board Improvements
Patient History Improvements
Immunization Module Improvements
Dicom Viewer Improvements
Procedure Order Form Improvements
Referral Form Improvements
Prior Auth Form Improvements
Newcrop Rx Improvements
CDR (Clinical Decision Rules) Engine Improvements
Multisite Module Improvement
CouchDB Improvements Including SSL Support
Access Control Improvements
Cookie and Session Improvements
ICD10 Code Set Updated
Supported in 34 Languages
Numerous Bug Fixes
Numerous Security Fixes and Security Improvements
Numerous Fixes to Ensure Compatible with Most Recent Versions of PHP, MariaDB and MySQL
Hi @gutiersa et al-
I’m thinking the most difficult part of building the list of changes to document would be to find out precisely what the v6 improvements are. I mean, ‘Access Control Improvements’ allows for a lot of possibly documentable functionality. And ‘Patient Portal Improvements’- the Patient Portal is a deep topic.
Trying to find where the changes are detailed, the best I can come up with is the closed pull requests in github:
It’s a (‘the’?) list of specifically what changes have been completed, so it’s possible to find it in the EMR. But then it needs to be determined if it’s a user- relevant change, and also if it’s in the current release. So doing things this way is a lotta lotta work.
Maybe I’m over- thinking this. Does anybody have ideas on a better approach?
You are not overthinking it. It is a lot, but it needs to get done. OpenEMR has a lot of documentation, however, it is in many different places, and some of it is outdated.
I believe some people come, try to get information, but give up and move on to other projects.
I am willing to update the wiki (and other areas) as I am setting up my system, and as I learn to use the features I am working on. It works out for everyone, me because I will eventually forget the details and there will be a place for me to look it up, and for newcomers.
Regarding user relevant changes, I agree. But documentation for developers also needs to be done.
We could consider labeling the pages this way for example:
DICOM Uploader, Storage Engine and Viewer v6
DICOM Uploader, Storage Engine and Viewer v6-dev
Meaning one page is geared to users, and the second page would be geared to developers. In other words, the wiki would have two pages for DICOM Uploader, Storage Engine and Viewer
Scant though the changelog for new OpenEMR versions is, I can’t see such a radical change having been made in version 6 without alerting people to it. Version 6 isn’t a huge upgrade. In OpenEMR 5, these are the only tables involved, other than the lbf_* tables in which form data is saved.
layout_options - this is your layout
list_options - the contents of any lists
lbf_data - data entered into the form about patients
@gutiersa The SMART on FHIR, and FHIR api use documentation is being spearheaded by @brady.miller. Perhaps the two of you can collaborate here. We have to have a developer friendly documentation for our APIs and the ability to add 3rd party applications which is the SMART on FHIR specification. This has to be done in order for us to pass certification for the latest meaningful use certification (ONC 2015 / 2020 Cares Act certification).
I’m the one implementing the FHIR and SMART on FHIR implementation so I’m happy to answer any questions on this.
Yes, I do agree that there is likely not a lot of change in going from V5 to V6. However, say, someone wanted to change from v4 to V6, then it might be easier for them. Rather than having to chase the forum threads.
Great, in that case, I would love to be added to however much documentation is available. The way my brain works, I figure out how to apply the information before I can understand it.
If I can implement it in my system, then I can help with documentation.
Hi @gutiersa -
Seems to me like the best way to help is to simply choose a topic and write a tutorial on it. If it has been documented for earlier versions refer to those pages for background, but basically, run through it on your v6 install till you know what all the screen objects do, then write it up.
I am happy to consult on how I compose my wiki docs, the style guides I’ve used etc etc, if anybody would like to see them.
But again, as some famous outfit’s motto says, “JUST DO IT”.
DOes this mean patients can no longer self register using the portal? Patient self-registration is an incredibly useful tool.
I know there needs to be some mechanism preventing abusive or malicious signups, but there are tech solutions for that too. IIRC, limiting signups to valid emails, and throttling them for the same IP address.
Real techs will have better ideas.
Can defaulting this to ‘allowed’ be done?