mbrinson wrote on Wednesday, September 20, 2006:
Before I get really deep into trying to figure out how to get the color settings for the categories for the calendar working, I wanted to confirm something.
I’ve seen talk on the forums about moving away from smarty, but are we really serious about that and are there really any other workable solutions?
I just don’t want to get it all figured out and then a short time later we completely nullify whatever I’m able to come up with.
Thanks,
Mike.
drbowen wrote on Wednesday, September 20, 2006:
We want to get away from smarty templates and have "frozen" new development in smarty.
Getting rid of the current calendar, obviuosly, takes a a new calendar. Something that is on the list but we have not yet devoted resources to.
Sam Bowen
ggd wrote on Saturday, July 26, 2008:
<quote>
We want to get away from smarty templates and have "frozen" new development in smarty.
</quote>
Is this the ‘last’, i.e. up-to-date word on Smarty & OpenEMR in the sense that Smarty is no longer used to customize OpenEMR?
I saw some thread speaking about replacing frames with CSS styling, and then, I believe, Smarty can be a handy way for not so savvy users to tailor OpenEMR according to their needs.
otoh, argument of introducing another technology can be balanced by adding support for PostgreSQL and then the task of maintaining the system will be improved by having one database only.
Sincerely,
Gour
drbowen wrote on Monday, July 28, 2008:
There are certainly a lot of different opinions on Smarty Templates.
Smarty Templates can be very useful if they have been expertly implemented and used consistently throughout the project.
Smarty Templates require a steep learning curve that pretty much precludes non-professional developers from participating in the development process.
In OpenEMR the Smarty Templates were inherited primarily with the calendar. The original calendar was very slow and very clunky. The Smarty Templates were not implemented very well.
For the OpenEMR guidance committee decided in 2005 to work away from Smarty Templates as an unnecessary abstraction layer that made attracting volunteer part-time and non-professional developers difficult.
Sam Bowen, MD
ggd wrote on Tuesday, July 29, 2008:
<quote>
For the OpenEMR guidance committee decided in 2005 to work away from Smarty Templates as an unnecessary abstraction layer that made attracting volunteer part-time and non-professional developers difficult.
</quote>
Thanks a lor for clarification.
Now it’s clear that Smarty is not the way to customize OpenEMR, but I still wonder if there is some “definite-customization-guide”?
OpenEMR has many features we do not need and we want to get rid of some, e.g. Immunization and/or we want to customize drop-down entries for Issue-types etc. ?
Sincerely,
Gour
drbowen wrote on Tuesday, July 29, 2008:
If you know some (or are willing to learn) PHP and can do some programming, customizing OpenEMR is pretty easy. I am a minimal programmer and started with no knowledge of PHP. I wrote two of the forms: Ankle Injury and the Bronchitis form from scratch. I have also customized OpenEMR so that I upload all of my images into the database as BLOBS. (I.E. I don’t have a separate documents directory).
If you are not a programmer, don’t want to be, and don’t want to learn PHP then customization is hard(er).
Adding drop down entries would require finding the list of drop down entries and adding them to the list in the hard code. This is about as basic a modification as I can imagine.
If there are features that you don’t need, you are better off leaving them where they are and just don’t use them. There are a lot of features that I don’t use for various reasons. (Haven’t had time to implement them being the biggest reason.)
Changing the Issue Types would be a more significant change because the "patient problem list" interacts with other parts of the OpenEMR. Changing these may impact other parts of the system in a way that you may not want.
Remember, that if you modify OpenEMR you are free to do so. However, every time there is an upgrade, you either have to not upgrade or you will have to make your modifications in a cumulative fashion on the upgrade. The only way to avoid this is to contribute improvements back to the project under the GPL license. Then the next version will already have your changes. 
Sam Bowen, MD
ggd wrote on Wednesday, July 30, 2008:
<quote>
If you know some (or are willing to learn) PHP and can do some programming, customizing OpenEMR is pretty easy. I am a minimal programmer and started with no knowledge of PHP. I wrote two of the forms: Ankle Injury and the Bronchitis form from scratch.
</quoute>
I’m not speaking PHP, but, if required, will learn some…
<quote>
If you are not a programmer, don’t want to be, and don’t want to learn PHP then customization is hard(er).
</quote>
Heh,my primary education is computer-engineering, but then i went into another direction.
During the education on the university was exposed to many imperative languages, but now, after ‘returning’ to programming I am fiddling with Haskell and functional programming for my next project…so, I believe PHP is learnable
<quote>Adding drop down entries would require finding the list of drop down entries and adding them to the list in the hard code. This is about as basic a modification as I can imagine.
</quote>
Good.
<quote>If there are features that you don’t need, you are better off leaving them where they are and just don’t use them. There are a lot of features that I don’t use for various reasons. (Haven’t had time to implement them being the biggest reason.)
</quote>
I was thinking about removing them in the sense of not cluttering interface.
<quote>Changing the Issue Types would be a more significant change because the "patient problem list" interacts with other parts of the OpenEMR. Changing these may impact other parts of the system in a way that you may not want.
</quote>
I see…so some care is required.
<quote>
Remember, that if you modify OpenEMR you are free to do so. However, every time there is an upgrade, you either have to not upgrade or you will have to make your modifications in a cumulative fashion on the upgrade. The only way to avoid this is to contribute improvements back to the project under the GPL license. Then the next version will already have your changes.
</quote>
Sure.
Don’t worry - if I decide for OpenEMR, will make all the changes available.
Thank you for your input. Now the tipe is ripe to do localhost install and see how the customization is going on, do some testing and then decide which application is the right one.
Sincerely,
Gour
mike-h30 wrote on Thursday, July 31, 2008:
Sam,
"I have also customized OpenEMR so that I upload all of my images into the database as BLOBS. (I.E. I don’t have a separate documents directory). "
Is there a performance reason for using BLOBS vs. the documents directory? Should we consider using BLOBS for our document storage? We are currently utilizing the documents directory which I back up daily. I am just curious.
Regards,
-Mike
drbowen wrote on Thursday, July 31, 2008:
There is an old running debate between two factions in web management.
Method 1) Store images in a directory. The SQL database just holds a pointer that points to a particular file on the hard drive.
Method 2) Store everything in the database. Store images as BLOBS. Feed the images from the database as needed.
1. Hard drive
Pros:
Modestly simpler to program
very fast database response
(pulling the images may be subject to how fast the hard drive is and how far out on the disk the images are being stored.)
Cons:
If the server is attacked successfully or semi-successfully, it may allow access to the images which are confidential information exposing the owner to legal liability.
To get full access the attacker still has to compromise the MySQL database. Unfortunately, since MySQL is really popular on the web, there are lots of attackers who have a lot of practice at this.
The typical attackers may not know what they have if they successfully compromise the server and may just want to vandalize your system.
Professional attackers will be looking for stuff they can sell. Such as very carefully validated names, addresses, telephone numbers, personal ID numbers (such as SSN in the USA) for purposes of sale to third parties for identity theft. The favorite attacks are SQL injection where malformed SQL statements can cause your server to dump all of the demographic data to the screen of the attacker. A successful SQL injection would be piped to a file on the attackers machine where it can be sold to a less than savory third party.
You have to back up the SQL database and the documents directory (where all your images are kept). This is by its nature a two step process. (rsync is awesome at this). One caveat, if you rsync the MySQL database you need to stop the MySQL process before beginning and then restart when you finish.
All of the images are stored as individual files in one really big directory. Depending on the operating system of the host, the sheer number of files may overwhelm the hosts ability to keep track of the files. Not only are there host operating system limitations, but file system limitations. You won’t find out until you run out of room then everything just stops without warning. This is not as much a problem now as it was 10 years ago when Linux struggled with lots of files in a directory.
It is important to maintain relative paths to these files to allow upgrades to newer / faster hardware as needed. File pemissions most also be set correctly to help improve security.
2. BLOBS in the database Pros:
Single point of entry for security. If you secure the database correctly, maintain good password policies, this makes administrative life easier.
Allows the use of MySQL replication to provide real time backup of the database.
Cons:
Slower response by the database. I personally, have not had an issue with this. I set up a metadata table and the metadata table has a pointer to the image table. This gives very fast response. You can probably measure faster reponse with database performance tools. I don’t think normal users can tell the difference.
While the number of files is not an issue, the maximum size of files is. The image table gets huge. The default OpenEMR table is MyISAM. MyISAM tables have a 4 gigabyte hard limitation. One quickly has to convert the table type to InnoDB to be able to store the data. InnoDB has a lot of advantages including better data integrity, extremely flexible when it comes to adding more space. One has to watch the maximum file size in the underlying operating system, file system and whether you are running 32 bit or a 64 bit system. Again this situation is much better tahn it was ten years ago. The new table limit size is measured a unit of number so huge that I have trouble remembering how many zeros it has. (32 TiB)
Note in the above: 1024 Bytes = 1 KiB; 1024 KiB = 1 MiB; 1024 MiB = 1 GiB; 1024 GiB = 1 TiB; 1024 TiB = 1 PiB; 1024 PiB = 1 EiB
ext2/3 with 8 KiB blocksize (Systems with 8 KiB pages like Alpha only) 32768 GiB (= 32 TiB)
ReiserFS 3.6 16384 GiB (= 16 TiB)
XFS 8 EiB
JFS with 4KiB blocksize 4 PiB
All of these file systems now exceed the maximum disk space that most of us have available to us on our current systems. For instance my curent production server has 4 x 1 TiB in a RAID configuration giving me 3 TiB of storage space. My current InnoDB table holding the images is around 54 GiB.
"The Lowdown on MySQL Table Types
Most people use MyISAM if they need speed and InnoDB for data integrity. You can use more than one or any combination of these table types in your database. Remember to asses the needs of your application before building it. Even though MyISAM is faster than InnoDB in the MySQL world, InnoDB is fast compared to any database engine. With InnoDB you get transactions, speed and integrity three features not usually used in the same sentence. Most of my customers want as much speed as they can get, but at the end of the day, good data integrity lets them sleep at night. "
http://www.developer.com/db/article.php/2235521
MyISAM is reportedly going to be deprecated in future versions of MySQL.
InnoDB does not have tool for a "hot copy" unless you purchase a third party solution.
Most of the "cons" listed above end up having similar problems in the BLOB method.
In the end, which way you go, hard drive with database pointer vs. BLOB in the database ends up being largely personal preference.
This was discussed in the OpenEMR forums in 2004. The vote at the time was 2 votes for method 1 (Rod and Andres), 2 votes for method 2 (Tekkno Genius and myself).
We ended up with the current method because Andres Paglayan is a much faster (and definitely a more elegant coder) than I am.
I, being an independent soul, finished my code and went with method 2.
Sam Bowen, MD
ggd wrote on Friday, August 01, 2008:
Hi Sam,
thank you for your deep insight into the issue.
<quote>
Most people use MyISAM if they need speed and InnoDB for data integrity. You can use more than one or any combination of these table types in your database. Remember to asses the needs of your application before building it. Even though MyISAM is faster than InnoDB in the MySQL world, InnoDB is fast compared to any database engine. With InnoDB you get transactions, speed and integrity three features not usually used in the same sentence. Most of my customers want as much speed as they can get, but at the end of the day, good data integrity lets them sleep at night. "
</quote>
How is the situation in PostgreSQL world (considering OpenEMR might get that back-end) ?
Sincerely,
Gour
mike-h30 wrote on Friday, August 01, 2008:
Sam,
Thanks for taking the time to pass on this information.
Regards,
-Mike