Skip to first unread message
Kiran Babu
Apr 1, 2015, 5:55:04 PM4/1/15
to d...@openmrs.org
Hi my name is John Lingam I am a masters student at IUPUI studying Health Informatics. We want to explore and conceptualize how to make OpenMRS HIPAA and HITECH compliant. We are conceptualizing an implementation at a primary care physician free clinic. We are going to cover not only the technological issues but also the site specific privacy and security issues. We wanted to ask the community what modules are needed in such an implementation and what peoples thoughts are about such a project? I know this has been talked about before and there has been some work on thinks like audit logs. I appreciate your feedback.
Opeyemi Bakare
Apr 1, 2015, 6:08:15 PM4/1/15
to d...@openmrs.org, d...@openmrs.org
I couldn't find a clear way it was, so I installed OpenMRS in an encrypted VM, on an encrypted filesystem and setup SSL for access.
Subsequently I locked down priveleged user access to manage the risk as well.
That satisfies most of the points, but database encryption would be helpful as well.
Hope that helps!
—
Sent from my iPhone
On Wed, Apr 1, 2015 at 5:55 PM, Kiran Babu <kiran...@gmail.com> wrote:
Hi my name is John Lingam I am a masters student at IUPUI studying Health Informatics. We want to explore and conceptualize how to make OpenMRS HIPAA and HITECH compliant. We are conceptualizing an implementation at a primary care physician free clinic. We are going to cover not only the technological issues but also the site specific privacy and security issues. We wanted to ask the community what modules are needed in such an implementation and what peoples thoughts are about such a project? I know this has been talked about before and there has been some work on thinks like audit logs. I appreciate your feedback.
--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions: http://om.rs/id
*** THIS GROUP WILL BE MOVED to OpenMRS Talk effective 10 April 2015 at 19:00 UTC. Please visit https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508 for details and to make necessary changes.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.
Dugan, Tammy Marie
Apr 1, 2015, 10:09:43 PM4/1/15
to d...@openmrs.org
John,
We use OpenMRS and modules we developed to run a pediatric clinical
decision support system in 5 (soon to be all 9) of the Eskenazi
pediatric primary care clinics.
As mentioned by Opeyemi, the most secure and HIPPA compliant manner that
we have found to implement our system is by using network security and
ssl. Here is what we use:
1. VM located within the Eskenazi network firewall. I'm not convinced
that encrypting the VM would matter much because a VM isn't a
traditional physical box that someone could walk off with and the
physical machines that run it are in a secure data center, in our case
2. SSL to secure the data in transit to prevent sniffing even within the
network.
3. Using real certificates and not self signed. Self signed certificates
are a terrible idea when it comes to setting up secure systems. The
certificate authorities are there for a reason. Self signed certificates
in production level implementations is a pet peeve of mine
I'm not sure what the specific requirements are of Hitech but if it
involves auditing user access I don't think core OpenMRS does this but
there might be a module that does.
Long story short, our group already has a HIPPA compliant version of
OpenMRS running in a primary care physician (sliding scale/free) clinic.
Tammy Dugan
We use OpenMRS and modules we developed to run a pediatric clinical
decision support system in 5 (soon to be all 9) of the Eskenazi
pediatric primary care clinics.
As mentioned by Opeyemi, the most secure and HIPPA compliant manner that
we have found to implement our system is by using network security and
ssl. Here is what we use:
1. VM located within the Eskenazi network firewall. I'm not convinced
that encrypting the VM would matter much because a VM isn't a
traditional physical box that someone could walk off with and the
physical machines that run it are in a secure data center, in our case
2. SSL to secure the data in transit to prevent sniffing even within the
network.
3. Using real certificates and not self signed. Self signed certificates
are a terrible idea when it comes to setting up secure systems. The
certificate authorities are there for a reason. Self signed certificates
in production level implementations is a pet peeve of mine
I'm not sure what the specific requirements are of Hitech but if it
involves auditing user access I don't think core OpenMRS does this but
there might be a module that does.
Long story short, our group already has a HIPPA compliant version of
OpenMRS running in a primary care physician (sliding scale/free) clinic.
Tammy Dugan
> --
> OpenMRS Developers: http://om.rs/dev
> Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
> Manage your OpenMRS subscriptions: http://om.rs/id
>
> *** THIS GROUP WILL BE MOVED to OpenMRS Talk effective 10 April 2015 at
> 19:00 UTC. Please visit
> https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508
> for details and to make necessary changes.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to dev+uns...@openmrs.org
> <mailto:dev+uns...@openmrs.org>.
> OpenMRS Developers: http://om.rs/dev
> Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
> Manage your OpenMRS subscriptions: http://om.rs/id
>
> *** THIS GROUP WILL BE MOVED to OpenMRS Talk effective 10 April 2015 at
> 19:00 UTC. Please visit
> https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508
> for details and to make necessary changes.
>
> To unsubscribe from this group and stop receiving emails from it, send
> an email to dev+uns...@openmrs.org
Bob Jolliffe
Apr 2, 2015, 4:56:34 AM4/2/15
to dev
Hi
I am not an an expert on HIPAA compliance, but it strikes me that you
are taking far too technical a view of the issue. Encryption is one
(rather small) part of information security - the most important by
far is organisational. I took a quick glance at the "SUMMARY OF THE
HIPAA PRIVACY RULE" provided at
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/privacysummary.pdf
"For Small Providers, Small Health Plans, and other Small Businesses"
and was not surprised to see that they advocate an approach which I
have always tried to do - not always successfully - in all information
systems implementations.
The first 2 points of Administrative Requirements on p16 is what I
usually find missing:
- A covered entity must develop and implement written privacy policies
and procedures that are consistent with the Privacy Rule.
- A covered entity must designate a privacy official responsible for
developing and implementing its privacy policies and procedures, and a
contact person or contact office responsible for receiving complaints
and providing individuals with information on the covered entity's
privacy practices.
- etc
You can't bypass these processes with any amount or strength of
encryption. To be HIPAA compliant, ISO27002 compliant or anything
else compliant you have to look beyond the software to the entire
context of use. So whereas the various technical strategies described
(disk encryption, ssl/tls etc) are important for securing the
technical artifact in abstract, there is much more to do to secure the
system in motion.
Aside: "Proper" signed certificates can be quite difficult to
implement in many contexts, due to US sanctions, the need for
acceptable credit card etc. The whole https model of PKI is quite
unfortunate (and I can almost say broken) in this regard - so whereas
I too always try to make use of verified signed certificates on
on-line systems where it is inconvenient to try and know in advance
who your clients are, I also think there are many cases where
self-signed, or preferably local-signed, certificates can do the job
perfectly well. Certainly they are better than running clear text.
Cheers
Bob
> To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.
I am not an an expert on HIPAA compliance, but it strikes me that you
are taking far too technical a view of the issue. Encryption is one
(rather small) part of information security - the most important by
far is organisational. I took a quick glance at the "SUMMARY OF THE
HIPAA PRIVACY RULE" provided at
http://www.hhs.gov/ocr/privacy/hipaa/understanding/summary/privacysummary.pdf
"For Small Providers, Small Health Plans, and other Small Businesses"
and was not surprised to see that they advocate an approach which I
have always tried to do - not always successfully - in all information
systems implementations.
The first 2 points of Administrative Requirements on p16 is what I
usually find missing:
- A covered entity must develop and implement written privacy policies
and procedures that are consistent with the Privacy Rule.
- A covered entity must designate a privacy official responsible for
developing and implementing its privacy policies and procedures, and a
contact person or contact office responsible for receiving complaints
and providing individuals with information on the covered entity's
privacy practices.
- etc
You can't bypass these processes with any amount or strength of
encryption. To be HIPAA compliant, ISO27002 compliant or anything
else compliant you have to look beyond the software to the entire
context of use. So whereas the various technical strategies described
(disk encryption, ssl/tls etc) are important for securing the
technical artifact in abstract, there is much more to do to secure the
system in motion.
Aside: "Proper" signed certificates can be quite difficult to
implement in many contexts, due to US sanctions, the need for
acceptable credit card etc. The whole https model of PKI is quite
unfortunate (and I can almost say broken) in this regard - so whereas
I too always try to make use of verified signed certificates on
on-line systems where it is inconvenient to try and know in advance
who your clients are, I also think there are many cases where
self-signed, or preferably local-signed, certificates can do the job
perfectly well. Certainly they are better than running clear text.
Cheers
Bob
Kiran Babu
Apr 2, 2015, 9:12:00 PM4/2/15
to d...@openmrs.org
I would like to thank you all for the invaluable suggestions and comments. We feel that this will help us address some of the more technical issues we are going to face.
Tammy - Were there any specific issues you encountered during your implementation that we should look out for/ be aware of?
Bob- My partner and I think project is going to deal more with the organizational issues than the purely technical. We agree that people tend to overlook them and focus on the technical aspects alone. In your experience are there things that we should specifically address so that we have a very thorough security and privacy plan?
Dugan, Tammy Marie
Apr 3, 2015, 7:49:57 AM4/3/15
to d...@openmrs.org
Kiran,
In terms of PHI, there was a lot of work involved between us and the
hippa privacy officer when we started using tablets for chica to make
sure that the PHI was appropriately secured. Our app is web based and no
phi is stored on the device. We also have a password and pin for the
device and can remotely track and wipe the tablet.
Tammy
In terms of PHI, there was a lot of work involved between us and the
hippa privacy officer when we started using tablets for chica to make
sure that the PHI was appropriately secured. Our app is web based and no
phi is stored on the device. We also have a password and pin for the
device and can remotely track and wipe the tablet.
Tammy
Bob Jolliffe
Apr 3, 2015, 11:54:25 AM4/3/15
to dev
Hi Kiran
It depends a lot on the context of course. I don't have a huge
experience securing patient record systems or with HIPAA, but there
are some principles which are broadly applicable:
1. You must have a high level executive summary 1-pager laying out
the information security policy for the clinic. Would refer to any
existing legislation, existing standard operating procedures etc,
would motivate the need for information security (principles) and it
would indicate what technical framework if any that the clinic is
going to work towards. Such a document shouldn't be more than 1 page
(so it is easily displayed and people can read it). All the other
processes relating to backups, encryption, access control etc would
derive from this. It should be signed by the highest authority
possible to sign it to indicate top management support. Generally
such a document wouldn't originate at the clinic level, but in the
absence of other guidance it is possible.
2. There should be some named individual responsible for the
implementation of policy (inf security officer/ISO). Once security
management gets into a rhythm this person should ideally be
maintaining a risk register (spreadsheet is fine) outlining risks
which have been identified (no offsite backups, unconfigured ssl,
users sharing passwords, no NDA for consultants/volunteers etc etc),
prioritising them and addressing them systematically. Maintaining a
managed security environment is an ongoing job, with new risks always
being identified. Someone must have the job of identifying, listing
and addressing them in accordance to the principles of 1 above, In a
small scale environment it might be better to think of this as a role
rather than a (whole) person.
3. Awareness and dissemination. No point having a security policy if
nobody knows about it. There are lots of strategies can be used here.
The prominent 1 pager helps. Linking with HR induction processes of
starting (and finishing) employment etc.
I think the above 3 principles are sufficiently generic to be broadly
applicable for compliance to any security management framework.
Probably there are enough people on this list with significant openmrs
and other clinical systems to make a start on a risk register of
common risks encountered in the field, perhaps particularly with an
eye to HIPAA, which would help kick start the work of the ISO.
Similalrly, I imagine there is the makings of a relatively generic
executive summary template to help clinics get started to be had from
the vast and historic openmrs implementers experience.
Note that government clinics should be informed by public service
regulations (though often these don't exist or are hard to find or
lack relevance) and NGOs working with ICTs should be operating their
own security management system along the lines of above (but
frequently don't). In the absence of these supports, it is more
reason to make a plan than less reason. Plans should be simple and
address real rather than imaginary challenges. That's much more
important than being highly polished and superficially "professional".
Hope that gives you some actionable ideas.
Regards
Bob
It depends a lot on the context of course. I don't have a huge
experience securing patient record systems or with HIPAA, but there
are some principles which are broadly applicable:
1. You must have a high level executive summary 1-pager laying out
the information security policy for the clinic. Would refer to any
existing legislation, existing standard operating procedures etc,
would motivate the need for information security (principles) and it
would indicate what technical framework if any that the clinic is
going to work towards. Such a document shouldn't be more than 1 page
(so it is easily displayed and people can read it). All the other
processes relating to backups, encryption, access control etc would
derive from this. It should be signed by the highest authority
possible to sign it to indicate top management support. Generally
such a document wouldn't originate at the clinic level, but in the
absence of other guidance it is possible.
2. There should be some named individual responsible for the
implementation of policy (inf security officer/ISO). Once security
management gets into a rhythm this person should ideally be
maintaining a risk register (spreadsheet is fine) outlining risks
which have been identified (no offsite backups, unconfigured ssl,
users sharing passwords, no NDA for consultants/volunteers etc etc),
prioritising them and addressing them systematically. Maintaining a
managed security environment is an ongoing job, with new risks always
being identified. Someone must have the job of identifying, listing
and addressing them in accordance to the principles of 1 above, In a
small scale environment it might be better to think of this as a role
rather than a (whole) person.
3. Awareness and dissemination. No point having a security policy if
nobody knows about it. There are lots of strategies can be used here.
The prominent 1 pager helps. Linking with HR induction processes of
starting (and finishing) employment etc.
I think the above 3 principles are sufficiently generic to be broadly
applicable for compliance to any security management framework.
Probably there are enough people on this list with significant openmrs
and other clinical systems to make a start on a risk register of
common risks encountered in the field, perhaps particularly with an
eye to HIPAA, which would help kick start the work of the ISO.
Similalrly, I imagine there is the makings of a relatively generic
executive summary template to help clinics get started to be had from
the vast and historic openmrs implementers experience.
Note that government clinics should be informed by public service
regulations (though often these don't exist or are hard to find or
lack relevance) and NGOs working with ICTs should be operating their
own security management system along the lines of above (but
frequently don't). In the absence of these supports, it is more
reason to make a plan than less reason. Plans should be simple and
address real rather than imaginary challenges. That's much more
important than being highly polished and superficially "professional".
Hope that gives you some actionable ideas.
Regards
Bob
> --
> OpenMRS Developers: http://om.rs/dev
> Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
> Manage your OpenMRS subscriptions: http://om.rs/id
>
> *** THIS GROUP WILL BE MOVED to OpenMRS Talk effective 10 April 2015 at
> 19:00 UTC. Please visit
> https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508
> for details and to make necessary changes.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dev+uns...@openmrs.org.
> OpenMRS Developers: http://om.rs/dev
> Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
> Manage your OpenMRS subscriptions: http://om.rs/id
>
> *** THIS GROUP WILL BE MOVED to OpenMRS Talk effective 10 April 2015 at
> 19:00 UTC. Please visit
> https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508
> for details and to make necessary changes.
>
> To unsubscribe from this group and stop receiving emails from it, send an
Reply all
Reply to author
Forward
0 new messages