We most likely fall into this group. We have about a dozen modules ready, but this gives us the best idea of how much money needs to be raised. If every organization listed on [the wiki kicked in $400, that would be enough for certification.
I’m not sure what modules are covered under “Privacy and Security Modules”, but my best guess leaves the individual module testing at a little more than 11.5k USD](http://openmedsoftware.org/wiki/OpenEMR_Commercial_Help)
The changes look nice. “170.306 Inpatient Certification Criteria” can be removed as it is not required for OpenEMR. Also, we need to distinguish between “Not started” and “In Progress” items
Hi,
Privacy and Security Modules are probably Risk Assessment related. Odd though, Risk Assessment is a lot more elaborate than just EHR modules. EHR is just a portion of it.
visolveemr
170.306 Inpatient Certification Criteria" can be removed as it is not required for OpenEMR
Hrm, I didn’t know that OpenEMR had decided to only limit itself to ambulatory certification. It’s possible to get certified as either Complete EHR for ambulatory (170.302 + 170.304) or inpatient (170.302 + 170.306) use. I will mostly focus on 170.302 stuff until that is complete, but I see no reason not to track 170.306 stuff in case someone would like to use OpenEMR for inpatient services. (Although, prehaps VistA is better suited to that?)
Also, by that reasoning 170.302(w) can be dropped since it is explicitly marked optional. All the Complete EHRs I looked at did handle that, but it doesn’t appear to be required for either Modular EHR or Complete EHR.
I imagine this page would continue tracking against NIST into the future. One we were certified there should probably be a link near the top to our ONC ATCB test results for users that are interested in the feature set but not all the development details.
All that said, if it would be easier for most developers if we dropped the 170.306 section for the time being, I am not strongly opposed. Looking toward the future, most of my potential clients will probably be using OpenEMR for ambulatory rather than inpatient work.
Also, we need to distinguish between “Not started” and “In Progress” items
“Current unimplemented” was my default, trying to be conservative with reported progress. That said, even if something hasn’t been tested, but you know OpenEMR does implement it or partially implements it, an update to the wiki would be appreciated.
hey,
In the wiki page did the following (note, these changes are easily reversible if anybody is opposed):
1) Removed the 170.306 section
2) Clarified the color coding with a legend. Goal in legend was to make it useful for lay people checking on the status and to help out the developers working on MU (especially useful to flag when a “fixed” criteria needs to be re-tested).
Green:PASSED TEST
Red: FEATURE NOT IMPLEMENTED OR NOT YET TESTED
Blue:CURRENTLY UNDERGOING TESTING/ANALYSIS
Orange:FLAGGED FOR RE-TESTING
Selvi,
I just committed your ethnicity patch to sourceforge. Although I still have a lingering question regarding your upgrade script (question is on your github commit).
thanks for the contribution,
-brady
Tony,
You mentioned in an email thread that the Procedure code will fulfill the computerized entry requirement. Just to mention, I spent some time with the procedure module (incorporated it into the clinical decision module), but I was never able to figure out how to enter an order in via the gui (the only way I could get an order in was to manually enter it into the order table in phpmyadmin).
-brady
The Orders are entered via an encounter format that Rod created that is part of the visits, it show up in the Adminstrative menu group. I’m not sure if that’s the best place for it but that’s where it is right now.
Sara is working on a users guide addendum that will include how to configure and use the procedures orders module.
One issue I noticed that will be important for the new version release, according to the Drummond group, each version of an EMR application needs to be certified independently but modifications can be made to an existing version without re-certification.
Rules for Modifying Certified Products:
Certification is granted to a specific product and
version-with-release (e.g., EHR Product 3.5). Methods and procedures for version control are
implementer specific, but product name, version and release must be supplied upon registration.
If a certified product is modified and the version number changes, the certification status must be
updated. See above section titled “Modifying Certified Products Retest Session” for steps on
modifying your certification status on updated versions of a previously certified product
Modifying Certified Products Retest Session – fees apply.
A previously certified Complete EHR or EHR Module may be updated for routine maintenance
or to include new capabilities that affect capabilities both related and unrelated to the
certification criteria adopted by the Secretary without its certification becoming invalid. If
changes are made to your product, you will submit to Drummond Group an attestation…
The reporting/displaying of results has to be modified to include the relevant elements and it almost 30 columns. We have started to work on the reporting. Please do share your views, if any.
These proposals add a layer of complexity, but would greatly improve
usefulness:
Problem list search should be by ICD-9 or ICD-10 and should accommodate
a range (250.00->250.99) or wild card (250.*) or multiple discreet
values (250.00, 250.02).
Reports should include =false values (may not be NIST standard, but so
very useful). For instance, I want to see all my diabetic patients who
are NOT taking a “statin” drug. Report includes Dx = 250.* and drug
list not containing “lovastatin, simvastatin, atorvastatin, pravastatin,
rosuvastatin” etc. Maybe *statin?
I see “procedure” under “options” but how would I see all dx=250.* with
NO proc=diabetic foot exam?
Once again, I don’t know how this jives with the NIST standards and
maybe the best option is to use a custom report writer elsewhere in
OpenEMR, but this is the stuff that will help me improve the care of my
patients.
We have resolved the NIST inconsistency in the Encryption Algorithm. For the General Encryption in OpenEMR, as per NIST - the following changes are done:
(a) Encryption algorithm MD5 changed to SHA1 in
- Audit Log (checksum)
- Installation (admin password)
- User create/edit (password)
- Password change (password)
(b) For 3.2.0 to 4.0.x upgrade, the password will be resetted to ‘pass’ irrespective of users and also the respective password history is changed.
Haven’t looked at code or tested it. But seems like solution for upgraders (b) is a large security risk. Wasn’t there gonna be a solution that forced users to change the password if a MD5 password was noted? I know we’re trying to get NIST as quickly as possible, but still need to ensure upgrade mechanism is acceptable before it gets put in the official codebase.
The upgrade part of the solution is not needed for NIST, so we can implement SHA1 for new installs and proceed with testing on that (from a branch if needed).
For upgrades maybe just detecting an MD5 and forcing a password change a login would be better?
A requirement for contributed code is that it supports upgraders. To convert all passwords en bloc to ‘pass’ for upgraders (with a text message for them to fix this) is simply not acceptable. NIST compatibility is not an argument to do this to upgraders (most of whom do not have paid support, and will end up with a compromised system after an upgrade that does this). Recommend forcing a password change when detect MD5 on login.
The basic read it that SHA1 is the minimum that should be used for
security and integrity, the point is that there is no specific “TEST”
for this related to user/password, we just have to provide
documentation that we are using an SHA1 algorithm. Perhaps that’s the
confusion.