We have scheduled to begin testing for Stage 2 meaningful across 4 dates August 27th,28th and September 3rd, 4th with InfoGard.
If we miss this deadline we will be pushed back into October.
There is plenty left to do and it’s time to push. I will be posting issues and general questions and begging for contributions (development) right here.
We have the funds to pay for the testing, and some extra as needed.
My statement re: d(7) requirement:
End user device Encryption is not relevant to a web browser based system
as we (the vendor) do not control the device the end user uses nor do we
install any software there are all. How does InfoGard handle that?
InfoGard:
Regardless of the architecture, the requirement must be met.
Either you ensure that the data is encrypted on the end user device or
you prevent data from being stored on the end user device.
Question to the team: How is this even going to be possible? we have no way that I know of to control or enforce the use of a browser on any “client”.
A question back for them is what methodology do they use to verify encryption?
Maybe for the purposes of testing and certification Firefox/Chrome needs to be installed on a disk partition with encryption, and also browser caching should be disabled.
What exactly is the “EHR technology” that we’re trying to certify? OpenEMR per se is only part of the end-to-end solution.
d(7)(i)(B) says:
(B) Default setting. EHR technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users.
I don’t see offhand how we’re going to enforce that on the browser side.
You need to understand the the question refers to the functionality of
OpenEMR.
Should a user use functionality outside of OpenEMR to store data locally
that is outside the scope of this issue.
OpenEMR does not have to prevent a user from storing data on an End User
Device. A statement that the user does not have the ability to write
data to the end user device or store data on the end user device using
OpenEMR. OpenEMR prevents storage of data on the end user device by not
having the ability to write to the end user device should satisfy the
certification requirement.
That should be sufficient. Functinality of the browser is outside the
scope of OpenEMR the same way an end user hitting the print screen
button in any EMR and then saving the image to a disk is out of the
scope of any EMR.
But less is more keep it simple and only talk about OpenEMR do not talk
about Firefox, IE or Chrome.
Michael L. Brody,
(it is nice to contribute a little bit again).
OpenEMR is web broswer based. No information is written to or stored on
the local machine.
The system is designed in such a manner that the program
On 7/30/2014 3:41 PM, Tony McCormick wrote:
This is the first big issue
My statement re: d(7) requirement:
End user device Encryption is not relevant to a web browser based system
as we (the vendor) /do not/ control the device the end user uses nor do we
install any software there are all. How does InfoGard handle that?
InfoGard:
Regardless of the architecture, the requirement must be met.
Either you ensure that the data is encrypted on the end user device or
you prevent data from being stored on the end user device.
Question to the team: How is this even going to be possible? we have
no way that I know of to control or enforce the use of a browser on
any “client”.
Most SAS EMR programs utilize a custom client as opposed to a web
browser. They are expecting a custom client that you will have to
describe how it was designed to not save data to the local machine.
Michael
On 7/30/2014 4:54 PM, Rod Roark wrote:
Given that, it would appear InfoGard’s response was supremely
unhelpful and misleading. Do they understand what OpenEMR is?
On pages 54237-54238 there is a comment and response regarding encryption when dealing with hibernation, caching, and other things outside of the EMR’s control. Specifically the last paragraph of it deals with caching.
It’s my interpretation that we meet requirements as long as we include a “no-cache” header on everything sent from OEMR. Whether the browser (or other software in between) actually obeys that header or not doesn’t matter.
So putting the following code in globals.php should get us most of the way there.
Is it not a feat of OpenEMR that it logs all user steps taken or at least most steps! All in a separate log-files, so the trespasser if it is something like a misstep,can be traced? The individual USER needs to have a log in place and keep the USER and Passwords far away from unwanted intruders.
Need to make the relevant MySQL tables hidden AND encrypted when not in use, so the chances of intrusion by spying eyes is reduced to almost ZERO. Only the US Gov spy programszzzzz can intrude in every system…
I came to the same conclusion as DataGroup and InfoGard agrees, but requires “proof”, We can handle that, as proof is just the browser doing what the browser does already.
Has anyone heard from ZHH? We need the things they promised to commit after we accepted the ZEND module installer. We need time to test the tools prior to the testing date which is Aug 27th!!!
Really we do.
I have code from Ensoftek for a good chunk of it too which is posted (github) but we are testing one more time tonight then we will publish it for review. (Brady got a preview)…
Volunteer testers will be needed and lots of them…
Code from Ensoftek and MI2 for review for MU2
Covers issues
A11 – smoking status
A13 - Family health history
A14 - Patient list creation
D2 - Auditable events and tamper-resistance
D4 - Amendments
All attached is a spreadsheet with the latest test results. Sheet one is this stuff, but the rest is relevant as well.
Code from Ensoftek and MI2 for review for MU2
Covers issues
A11 – smoking status
A13 - Family health history
A14 - Patient list creation
D2 - Auditable events and tamper-resistance
D4 - Amendments
I have a spreadsheet with overall testing details, but SF won’t let me post is right now.
These items were claimed by contributors and need to be delivered for testing this week to be included:
a10. Drug-formulary checks (owner is ZH Healthcare) (NewCrop may have this)
a15. Patient-specific education resources (owner is Sunset Systems) (Unknown Resources to Complete)
Care Coordination (170.314(b))
b1. Transitions of care – receive, display, and incorporate transition of care/referral summaries (owner is ZH Healthcare)
b2. Transitions of care – create and transmit transition of care/referral summaries (owner is ZH Healthcare)
b3. Electronic prescribing (owner is ZH Healthcare)
b4. Clinical information reconciliation (owner is ZH Healthcare)
b5. Incorporate lab tests and values/results (owner is ZH Healthcare)
b7. Data portability (owner is ZH Healthcare)
c1. Clinical quality measures - capture and export (owner is ZH Healthcare)
c2. Clinical quality measures - import and calculate (owner is ZH Healthcare)
c3. Clinical quality measures - electronic submission (owner is ZH Healthcare)
e1. View, download, and transmit to 3rd party (owner is ZH Healthcare)
e2. Clinical summaries (owner is ZH Healthcare)
e3. Secure messaging (owner is ZH Healthcare)
f2. Transmission to immunization registries (owner is ZH Healthcare)
f3. Transmission to public health agencies – syndromic surveillance (owner is ZH Healthcare)
f5. Cancer case information (owner is ZH Healthcare)
f6. Transmission to cancer registries (owner is ZH Healthcare)
There are still some things unclaimed as well…
a6. Medication list (No owner) (High Resources to Complete) (NewCrop may have this)
a7. Medication allergy list (No owner) (High Resources to Complete) (NewCrop may have this)
a12. Image results (No Owner) (Unknown Resources to Complete)
d9. Accounting of disclosures (No Owner) (Low Resources to Complete)
g3. Safety-enhanced design (No Owner) (Unknown Resources to Complete)