V6 Documentation wish list

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.

Thanks

1 Like

Hi Sandra-
As a starting point here’s this rather sketchy (i.e., not detailed) list of the improvements in the 6.0 release:
https://www.open-emr.org/wiki/index.php/Release_Features#Version_6.0.0

Though I guess one would need to have a v5 install to compare with to find the actual changes…

1 Like

@htuck @sjpadgett @stephenwaite @robert.down @brady.miller

I am interested in updating the Layout Based Forms page of the wiki:

https://www.open-emr.org/wiki/index.php/LBV_Forms

I would like to update it specifically as to how these forms function in version 6
I plan on starting a new page for v6

These are my questions:

  1. Has this already been done, perhaps I have not researched this topic well enough!
  2. The first paragraph refers to “these tables” is it just these two tables? list_options and layout_options tables
  3. For v6, is it still only those two tables?
  4. I would like to add to this page practical examples. One which includes nation notes within a form. I am thinking of writing up SOAP notes sample. I believe that is pretty widely used.

Finally, if you know someone who knows a little or a lot about this particular topic, kindly tag them in this thread.

Thanks for your consideration of this topic.

Thanks so much for this link:

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.

  1. Numerous User Interface Improvements
  2. Speed and Performance Optimizations
  3. New Support for FHIR (Fast Healthcare Interoperability Resources)
  4. New Support for SMART on FHIR
  5. New Support for OAuth2
  6. New Support for OIDC (OpenID Connect)
  7. New Support For EasiPro (Patient Reported Outcomes)
  8. New Support for Kubernetes
  9. New Docker Support for Raspberry Pi
  10. New Support for Argon Password Hashing
  11. New Database Support for utf8mb4 Encoding
  12. Patient Portal Improvements
  13. REST API Improvements
  14. Installer Improvements
  15. Patient Dashboard Improvements
  16. LDAP Improvements Including SSL Support
  17. Billing Improvements
  18. Payment and Batch Payment Improvements
  19. Fee Sheet Improvements
  20. Patient Flow Board Improvements
  21. Calendar Improvements
  22. Encounter Improvements
  23. Messaging improvements
  24. Patient History Improvements
  25. Immunization Module Improvements
  26. Dicom Viewer Improvements
  27. Procedure Order Form Improvements
  28. Referral Form Improvements
  29. Prior Auth Form Improvements
  30. Newcrop Rx Improvements
  31. CDR (Clinical Decision Rules) Engine Improvements
  32. CCDA Improvements
  33. MedEx Improvements
  34. Multisite Module Improvement
  35. CouchDB Improvements Including SSL Support
  36. Access Control Improvements
  37. Cookie and Session Improvements
  38. Logging Improvements
  39. Docker Improvements
  40. ICD10 Code Set Updated
  41. Supported in 34 Languages
  42. Numerous Bug Fixes
  43. Numerous Security Fixes and Security Improvements
  44. Numerous Fixes to Ensure Compatible with Most Recent Versions of PHP, MariaDB and MySQL
  45. Modernization of Codebase
  46. Automated Testing
  47. Docker Development Environment Improvements

For example:
26. Webservices, DICOM and DICOMSR support
26. https://www.open-emr.org/wiki/index.php/DICOM_Uploader,_Storage_Engine_and_Viewer

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?

Best- Harley

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

That seems a reasonable method to categorize the documents but must be careful to not add yet another layer of organization that has to be navigated by the clueless info- seeker…

1 Like

No, it shouldn’t if these conventions are clearly documented. Also, that is what the Table of documents and index are for. Don’t worry, I will not do anything on my own.
These are just ideas!

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
1 Like

@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.

2 Likes

@PeteBoyd

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.

@adunsulag @brady.miller
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.

Thanks

The current API documentat is found in the codebase for the API here and for FHIR here.

SMART on FHIR app installation is linked to in the documentation but it really should be integrated directly into the FHIR docs. It can be found here.

1 Like

Thank you
I would really love to help more. What would I have to do to help integrate it?

How do I test this test script? I mean, what do I enter into the address bar?
Https://domain.com/tests/api/InternalApiTest.php/

that did not work for me! :frowning:

Are there any plans to use something like swagger for API docs? That would be awesome if possible.