V6 Documentation wish list

Management and Administration
1

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
2

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
3

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

1 Like
4

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

5

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

6

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

7

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
8

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!

9

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
10

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

@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

12

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
13

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:

14

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

1 Like
15

Hi All-
New doc posted in the v6 user guide (https://www.open-emr.org/wiki/index.php/OpenEMR_6.0.0_Users_Guide)
Check it out:
https://www.open-emr.org/wiki/index.php/HOWTO_Activate_a_Patientā€™s_portal_access_-_v6.0
Itā€™s not explicitly mentioned on the wish list; mebbe add it so it can be crossed offf?
:slight_smile: -Harley

2 Likes
16

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ā€.
Best- Harley

1 Like
17

Thanks Harley for doing this.
However, portal has changed since v6(0) and now supports categories. For example:

Category setup in Lists(Repository is a place to put templates not used or being worked):

image
image1536Ɨ711 14.8 KB

In Dashboard(upload, move or edit templates to categories):

image
image1536Ɨ711 54.3 KB

And the Portal:(Templates are duplicated for this example)

image
image1519Ɨ794 52.4 KB

Also note that now Portal is a SPA(Single Page App) and now includes a HELP template to individualize for each practice.

Please also note that the portal now requires that any user that needs to be included in portal must have portal flag set in Users:

image
image1536Ɨ711 45.6 KB

All these changes also apply to the same demographics patient document feature.

image
image1536Ɨ711 40.8 KB

1 Like
18

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?

19

Iā€™m talking about what OpenEMR users/providers/doctors/administrators are able to be seen in portal for such things as receiving secure messages. Registration is still available for all.

And here I though I was a real tech!:slight_smile:

20

YOU are a real tech!
I was was just flapping gums with ideas for securing the portal!!