vikrasharma wrote on Wednesday, June 05, 2013:
I noticed in documents module, when i try to access an existing document by clicking the link, it downloads the document in the background and opens the information on the right. Similar behavior (document gets downloaded) when update some information for e.g. issue and click submit.
Question - Is this ok? document gets downloaded to the local computer without user requesting it.
drkay wrote on Wednesday, June 05, 2013:
I’ve noticed this behavior as well. It seems like it could be risky, especially if the EMR is being accessed from an unencrypted system for HIPAA reasons.
By the way, the documents module works pretty well in Firefox or Chrome. You can view the document right in the window.
tmccormi wrote on Wednesday, June 05, 2013:
That is the nature of a web browser based system. ALL data is “downloaded” to the client for display and processing, doesn’t matter if it’s a document or the patient summary edit screen.
That’s why ALL clients should be using secure HTTPS:// or VPN access to the web server.
–Tony
tmccormi wrote on Wednesday, June 05, 2013:
Technically you should also have your Browser set to Private browsing (Incognito) and configured to clear all cached data on exit.
drkay wrote on Wednesday, June 05, 2013:
Man, Tony, that would be hard-core, but you’re right. 
How about having the computer file system encrypted, so that the user has to enter a password each time they log in to decrypt the hard drive, like Ubuntu systems allow? Our state Medi-Cal (Medicaid) actually requires this now, I believe (hard disk encryption).
vikrasharma wrote on Wednesday, June 05, 2013:
That is correct but my question was why we download if the user doesn’t want to download? I understand we should download the document if user clicks “download” button but may not be necessary if the user just want to view the document info or update some info.
cverk wrote on Wednesday, June 05, 2013:
I have been using firefox and under the options menu and applications you can set pdf’s to open in adobe reader instead of downloading, which I think is the default.
Could you comment on what it takes to make sure clients are using HTTPS: or if that is even needed if you are just operating on a local office intranet?
tmccormi wrote on Thursday, June 06, 2013:
It does not matter what viewer / plugin you use to see the document, it still has to download it locally to view it. It’s just seamless.
Encrypting the local drive is the ultimate and may be required in MU Stage II even, not for sure though.
Vikram - are you saying that when you click on a document ALL you want to see is the META data about the document not the document itself? At this point clicking on the document tree element means you want to see the document, which requires it to be downloaded, now way around that.
yehster wrote on Saturday, June 08, 2013:
http://robsnotebook.com/xampp-ssl-encrypt-passwords
This is how you setup SSL/HTTPS on XAMPP
fsgl wrote on Wednesday, June 12, 2013:
Thanks a bunch for the link.
I noticed that Henry Alvarez had difficulties in this regard, but this tutorial seems do-able and specific enough for non-techies.
Rob’s advisory: “Note that I am only saying that I am increasing security, not making it completely secure. If you try to make XAMPP accessible to the public internet with these security steps, you do so at your own risk. I make no guarantees that I have plugged all security holes.”
Unless the feds threaten water boarding, “no” to patient portals (tongue in cheek).
yehster wrote on Thursday, June 20, 2013:
This article regarding browser caching seems relevant
For those people using OpenEMR from “shared computers” (for example in an in-patient setting) browser cache may be a bigger issue.
Something that may be helpful is to append the HTTPS headers to prevent caching.
There are no absolutes in security. Safes are rated by how long they can expect to withstand an expert thief’s efforts. Computer security is no different. HTTPS/TLS do add additional protection, but if people use weak passwords and have guessable usernames, it won’t take long to break in.
With regard to deploying patient portals on the internet I have a lot of ideas on how to address some of the concerns. For example one could setup “web facing” server with only the code needed for the patient portal. So concerns about vulnerabilities in things like gACL and PhpMyAdmin would be reduced. That server could also use a MySQL login that has a minimum of permissions so SQL Injection problems while worrisome might not be quite as catastrophic.
Security is about evaluating and understanding risk. The biggest risk for an OpenEMR server on the internet is going to be from a “drive by hacking” that exploits vulnerabilities in the underlying infrastructure (Apache and PHP) and not from something specific to OpenEMR itself. However because of the limited resources on the project, we tend to be reactive rather than pro-active when it comes to security.
I think that a number of new criteria in Stage 2 Meaningful Use are going to require activation/availability of patient portals. I’d have to double check if they are optional or required. View/Download/Transmit is the most significant.
fsgl wrote on Thursday, June 20, 2013:
Patient Portals will be a requirement, not an option, in 2014 for those of us who attested in 2011 or 2012, because it will be a Core Measure. See the Description of Core Measure 7.
The 2 exclusions don’t apply to most of us, so there won’t be any way to wiggle out of it. This Stage 2 Core Measure replaces the Stage 1 Measure for the provision of medical information in electronic form. At least the Stage 1 Measure had the exclusion that if no patient asks about it, we were absolved of the requirement. Additionally, it is far more secure to give a patient a CD or flash drive than it is to enable Patient Portals.
A number of us old folks will have to seriously think about not complying with such a dangerous mandate or retiring earlier.
Our old practice management software communicated exclusively with insurance companies and clearinghouses via dial-up. As a result, it came very close to security nirvana; no virus, no hacking and no crashes since 1995.
Voluminous amount of very sensitive information about the American people are in our medical records. It is mind boggling that individuals in the federal government fail to understand the serious and deleterious ramifications of Stage 2 Core Measure 7. The criminal class will be salivating in anticipation.
mdsupport wrote on Friday, June 21, 2013:
The option of Direct outbound messaging is far more attractive compared to running / outsourcing Patient Portal and managing patient passwords. It would also be good for patients since they can consolidate all medical interactions with multiple entities into a single mailbox. Most importantly CMS seems to be going big with that approach.
sunsetsystems wrote on Friday, June 21, 2013:
What sort of messaging is that? Email?
yehster wrote on Friday, June 21, 2013:
http://www.healthit.gov/policy-researchers-implementers/direct-project
sunsetsystems wrote on Friday, June 21, 2013:
Thanks but that looks like communication between vendors, not with patients.
mdsupport wrote on Saturday, June 22, 2013:
This is the correct link for the Direct project and patient communication is a very important aspect of the overall design. OpenEMR already has the patches from one of the trust certificate issuers. On patient side, Microsoft’s PHR - Healthvault already provides secure access to Direct messages. If patients establish an account with a PHR, we will deliver all patient portal data and automatic updates. The advantage for patients is they can log into a unified message center like this and get updates from various sources - multiple physicians, insurance companies, etc… Asking our 80 yr old patients or their caregivers to log into 4-5 patient portals is unlikely to work. A PHR approach has a better shot at giving patient access to their data. What is unclear is how MU2 will treat this type of communications.
fsgl wrote on Saturday, June 22, 2013:
From the white paper:
“In general, a Direct Project implementation is responsible for packaging message content, securing it, and transporting it from one location to another.
Content is packaged using MIME and, optionally, XDM.
Confidentiality and integrity of the content is handled through S/MIME encryption and signatures.
Authenticity of the Sender and Receiver is established with X.509 digital certificates.
Routing of messages is handled through SMTP.”
How is the Direct Project more secure than what has been attempted with OpenEMR? Please explain in terms that is understandable to end users.
This past week I had an occasion to refer a patient for a Neurological consultation. The Eye note and results of diagnostic studies were faxed to the consultant. A cover sheet with an advisory to unintended recipients was attached and the fax number of the consultant was double checked before sending. This method is far more secure and superior to the example given in the white paper. My problem is that the feds don’t agree with me.
The vast majority of my patients have no interest in obtaining their health records electronically. The World War II generation often don’t own computers, therefore accessing multiple Patient Portals is moot. Caretakers invariably accompany Mom or Dad into the exam room and engage fully in the discussion of medical issues. Often they ask the parent if they understand the doctor’s explanation before leaving.
The Direct Project proposes a glorified email system. Instead of our individual practices being subjected to cyber attacks, the target will be centralized. How is that more secure?
Irrespective of the method of conveyance of medical information to our patients, physicians are ultimately responsible for violations of HIPAA, to the tune of $250,000 and 10 years in prison as maximal penalties.
yehster wrote on Saturday, June 22, 2013:
The Direct Project proposes a glorified email system. Instead of our individual practices being subjected to cyber attacks, the target will be centralized. How is that more secure?
The centralized authority is responsible for managing public keys. The ability to decrypt the messages still lies with the physician who hold the private key.
In order to trust such a scheme you have to trust public key cryptography. Which is understandably harder to do because it is more complicated than faxes.
Trying to explain this by analogy, the centralized server simply provides “fax numbers” to use that you need to trust when sending an email. Only the intended recipient has access to the actual fax machine where the message gets printed out.
fsgl wrote on Saturday, June 22, 2013:
This brings to mind a very sound piece of investing advice; if one does not understand an investing instrument, for example, a credit default swap; don’t invest with it.
Please put on the physician’s hat for a few minutes and comment on whether the Direct Project or the facsimile device provides better protection of the medical record.