Implementation of LBF visit forms in Onsite Portal

OpenEMR Development
,
63

I am getting ready to do the documentation for these topics. But I have a couple of questions:

  1. Has a page already been started?

  2. My goal is to tag the page by the version of openemr. But I would like to tag text and images by version as well. Does the wiki support this type of versioning? Or I would have to create a new page for the next version? In other words, if there is a change to the UI, but the instructions remain the same, then someone looking for v5 for example can get the v5 images, and someone looking for v6 can get the v6 images.

  3. Finally, this thread discusses multiple topics: LBF, Onsite portal, Templates, Documents and Dicom viewer. Correct? (I am just trying to get organized)

Thank you for your patience. But I needed to understand how to use all this, before I could get started with documentation.
Also, I would appreciate all the help I can get with comments and organization.

Thanks
Sandra

1 Like
64

@htuck has a page on Templates I believe and could probably help you out with your questions.
Iā€™d have DICOM on separate page.

Iā€™m sorry but I donā€™t know much about the wiki but do appreciate effort.

1 Like
65

Yes, I have seen the page on Templates (I think)
I think each topic deserves a separate page. They can then be linked.
I wonder if there is a community page for the wiki. Hmm, I will look it up.

66

Hi @gutiersa the page I wrote that @sjpadgett mentioned thatā€™s in the wiki is at:
https://www.open-emr.org/wiki/index.php/Patient_Portal_Document_Templates

It supersedes the instructions written for OpenEMR 4.2 which is on the page:
https://www.open-emr.org/wiki/index.php/Templates_for_Patient_Documents

As I understand the tagging youā€™re trying to do, I do not believe the wiki supports that.

This thread discusses a whole mess of things! It talks about LBFs used as templates for documents which are accessed both by patients through the Onsite Portal and by staff through the OpenEMR that serves that portal. And DICOM is used to view some files (though Iā€™m a little vague on this partā€¦)

  • HT
1 Like
67

ā€œI would appreciate all the help I can get with comments and organization.ā€

I have long been interested in working on documentation. I submitted a request through the recommended channel (I forget which), providing various background info so as to demonstrate my suitability. I never heard back.

1 Like
68

sorry to hear that @PeteBoyd, definitely would be great to have your assistance, am sure @brady.miller will send you a login to the wiki asap, thank you

btw hereā€™s the github issue for migrating the wiki. The Drupal conversion has lost momentum so mentioned to @brady.miller that maybe we should look at using hugo like we do for the website

although guessing itā€™s not as powerful it is approachable like this script shows

1 Like
69

@PeteBoyd and @stephenwaite ,
Just verified wiki account for @PeteBoyd . Agree, though, that time to think about a plan for documentation/wiki migration. Recommend researching options and then we can make the plunge (ie. get something up and running as the main docs (and quickly get the main stuff there) and then migrate the archived old wiki to this over time). Hugo would be tough for folks, but am pretty much desperate for anything but that old wiki :slight_smile: Note it would definitely make sense to migrate over the main pages to hugo though (things like download page, patch page, features page).

2 Likes
70

I sent an email to the folks at freeBSD asking them to allow us to use their documentation template.
I did not hear yet. They have recently (over the last month and a half) migrated their documentation project to FreeBSD DOC-NG. FreeBSD is known for their documentation.

Check out this youtube video:

Openemr needs several things:
Documentation: installation and user manual and developer manual (I assume on this last one)
A Documentation project: to encourage others to become involved with the documentation, to explain how things work and how to document it.

This is just my opinion. I think that rather than updating the documentation, it should be duplicated and modified for the newer versions, such that guides for older versions of openemr remain intact. I realize that some items become obsolete, but I believe there are folks using previous versions. Documentation for those versions should remain.

Check these out:
https://wiki.freebsd.org/
https://www.freebsd.org/
the FreeBSD handbook: https://docs.freebsd.org/en/books/handbook/
ports are the applications for the OS: https://docs.freebsd.org/en/books/porters-handbook/
and this is the developerā€™s handbook: https://docs.freebsd.org/en/books/developers-handbook/
finally, they have a primer for documentation: https://docs.freebsd.org/en/books/fdp-primer/

Those guys are pretty organized.

Also, there is a role for the wiki. I have been learning about the platform. It need not be deleted. Openemr might benefit from a documentation project to get the articles organized.

Sandra

1 Like
71

Not sure about quickly!

I think we could do season of docs
Actually I really quickly came up with a proposal based on the sample proposal. I will share and you can fill in additional info. I am willing to join summer of docs. I believe we would need minimum one other person.

I will share a link to the document.

Cool