Review Process
From GPLMedicine
Review Process
An author will download, install and review an EHR and then post the results to the wiki. From there Editors, Authors and Commentors will continuously update the document. Improving the depth of the reviews, as well as the updating the reviews with information from new releases of the software. As a result these reviews should continue to evolve with the EHR projects themselves. Even this process is subject to analysis and alteration.
Authors
Authors are the people who perform the initial write up of an EHR system. The list of Authors can be found in Reviewers. An Author is a person who actually performs the work of installing and testing the software, and communicating impressions.
Editors
Editors are people who edit the work of the authors and add information. There will be many kinds of Editors, for instance someone will check the reviews for grammatical and spelling mistakes. Others will actually change content. Generally only those who have experience with the code itself, or deep understanding of EHRs generally will be allowed to edit for content.
Commentors
The public at large will be encouraged to comment, however, people who are actually associated with the various projects will be give an opportunity to correct factual mistakes within the review. The only difference between a commentor and an editor will be the level of trust put in the changes. Changes introduced by commentors will be double-checked.
Review Format
The format is definately just a guideline. Whereever possible, it should be improved upon and deepend.
EHR Title
The name of the project. Version of the software reviewed.
History of EHR
A Brief summary of the project history.
EHR Trademark
Generally FOSS projects are controlled by trademark. The owner of the trademark defines what codebase is merits the use of the name. This is unique to the FOSS world. Because everyone generally has some rights to the codebase under the software license, anyone can rename and market the codebase as there own product (providing they abide by the license). So essentially trademarks dictate the "trusted" version of a codebase. Why does everyone trust "Linux"? Because Linus has a track record of making his kernel perform well. So the "Linux" trademark goes a long way. In many cases the owner of the trademark controls the project.
EHR Community
Where to find the community, how large and active it is. Objective measures of community.
EHR Commericial Support
What companies/people support the project codebase professionally.
EHR Websites
The various webpages used to run the project.
EHR Installation
The installation process should be simple, secure, and it should catch program level errors. The review will detail how an installation went and the assess how well it performed in these three areas.
Simple
A modern web application should be self-installing as much as possible. After placing the code in a PHP enabled web directory, and pointing a web browswer to the web directory, the installation should step me through from there. I should not have to read the README or INSTALL file in order to get the application working, although if this process does not work, then this will be done.
Secure
The installation procedure should also be secure. An installer should have the following security features.
- It should be limited by IP access, with a default of localhost. This proves that you either have root access to modify the IP default, or physical access to the local machine.
- It should be difficult to unintentionally reinstall the system.
- It should not install the application with a default password.
- It should authenticate the user using the database username and password.
Error Catching
It should catch errors, and where possible advise the user about what to do when a problem occurs. A common error might be web server write permissions on a unix system. Often these errors are not the fault of the application, however if the installer recognizes that they are a problem and either instructs the user on how to correct them or automatically corrects them, then the errors are "caught" be the application. However, if an error is generated that is a programming level error, then that is an un-caught error. It means that this installation procedure was not aware enough of the application environment to deal with errors correctly.
EHR Medical Billing System
How difficult is it to get the billing engine running? How easy is it create variations? How easy is the billing interface to manage?
EHR Medical Accounts Recievable
How difficult is it to report on AR? How about entering EOBs?
EHR Scheduling System
How capable is the scheduling engine? Does it handle overbooking? How intuitive is it?
Tracking Patient Data using EHR
A brief overview of the strategy for tracking patient data
EHR Reporting System
How difficult is it to create new reports? How cumbersome is the reporting language?
EHR Security
An evaluation of authentication, access control, logging, and generally HIPAA security measures.
EHR Architecture
How is the code arranged? Is the project well designed? This is difficult to measure fairly. Everyone tends to perfer their own coding style. For instance the FreeMED team has said that the MirrorMed/ClearHealth project is not "modular", while the MirrorMed/ClearHealth projects have said that the FreeMED project is not "OOP". OpenEMR specifically hopes to reduce depenancies on outside libraries when possible, MirrorMed/ClearHealth embraces using libraries and uses them whenever possible. We will attempt to be as objective as possible and to at least note when that is not possible. One of the ways to make this portion of the review more objective is to take statistical measures of the code bases.
Sadly there has not been much public work done (please update this if you find some) on how to evaluate PHP projects objectively.
As a result two tools were written for this evaluation. A tool that approximates cyclic complexity and one that gathers statistics from subversion. You can read more about these in the Review Tools section
EHR CCHIT evaluation
A comparison of the projects feature set to the available CCHIT standard. This is a pre-guess as to how the project would fare at a CCHIT evaluation.
EHR emrupdate.com matrix
A comparison of the project to the feature matrix on emrupdate.com.
EHR Documentation review
Summarize the types and quality of documentation for the project.
Conclusion
A summary of the current review
