Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo, mail # user - Security and data design advice on structuring data on accumulo


+
Edmon Begoli 2012-08-08, 20:08
+
Marc Parisi 2012-08-08, 22:29
+
Edmon Begoli 2012-08-09, 19:44
Copy link to this message
-
Re: Security and data design advice on structuring data on accumulo
Josh Elser 2012-08-10, 02:19
I've thought quite a bit about the approach you've outlined previously..

The main caveat I've always struggled to overcome is how to encapsulate
*when* a physician should have access to your records. This expands the
problem into n*m roles which becomes difficult to manage inside
Accumulo, especially as time elapses.

On 8/8/2012 6:29 PM, Marc Parisi wrote:
> Just some ideas and thoughts....
>
> With a system I'm building I have code to take care of user roles. Roles
> will define visibilities, how analysis is performed, information
> sharing, etc. I have a particular role for sharing. I also have an area
> of interest, usually assigned to a physician role, therefore only a
> physician's office can see certain data from it. The data corresponding
> to a given person can be accessed by that person ( if they have app
> access ), the physician that created it, and other physicians ( with a
> different area of interest ) with whom the user wants to share their
> data. Each area of interest will be cryptographically secured. Our
> approach will utilize multiple crypto technologies. I would suggest
> making crypto your last stop. Focus on getting
> the visibility hierarchy designed. HIPAA requirements can come later.
>
> In my approach, there is no elevation of fields per se. Instead, there
> are visibiilities for all assigned parties,so in my case it is a matter
> of labeling. The data can have hierarchies, and each hierarchy has
> different labels to control access.
>
> " Patient demographic fields are PHI (personal health information) and
> these should not be visible to all who want to perform analysis, but
> only to main administrators,
> patient and maybe physician. I assume these would have to have
> separate authorization label. "
>
> Yes. I think this is where roles will help. Assign roles and
> visibilities to those roles. As of right now, I'm putting ephemeral data
> in my visibilities ( user ID for a physician, among other things ). I
> will probably move this to the qualifier and take a more simple approach
> to visibilities.
>
> Each role has different actions. Right now I have four actions; syncing,
> querying, deleting, and sharing. You don't have to capture actions, but
> you might want to limit how the roles of users vary, and I think
> modeling the security actions within each role is an excellent way to do
> so.
>
>
> On Wed, Aug 8, 2012 at 4:08 PM, Edmon Begoli <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     I am trying to model the healthcare claim on accumulo and I want to
>     lay it out so that it:
>
>     A. Accurately reflects the structure of the claim
>
>     B. I could have controls finely applied to different sections of the
>     document
>
>     I am simplifying matter but claim contains claim document identifiers,
>     demographics of the patient, and line items for the procedures
>     performed:
>
>     claim identifier, data submitted, data processed, state of origin, ...
>     patient name, dob, location, other identifiers
>     procedure 1 code, procedure 1 provider, procedure 1 cost, ...
>     ...
>     procedure n code, procedure n provider, procedure n cost, ...
>
>
>     Patient demographic fields are PHI (personal health information) and
>     these should not be visible to all who want to perform analysis, but
>     only to main administrators,
>     patient and maybe physician. I assume these would have to have
>     separate authorization label.
>
>     Other fields may be visible to different groups of people - i.e.
>     federal claim administrators can see all, but  regional offices can
>     only see their states.
>     Separate, more permissive labels.
>
>     Finally, it might make sense to "elevate" some fields for easy access
>     and analysis - ie. diagnostic codes, zip code, cost.
>     This would not be a matter of labels, but data design.
>
>
>     With all this in mind, I would welcome if anyone has any security and
>     data design suggestions.
>
>
+
Adam Fuchs 2012-08-10, 12:52
+
Benson Margulies 2012-08-10, 12:56
+
Adam Fuchs 2012-08-10, 13:02
+
David Medinets 2012-08-10, 13:54
+
Edmon Begoli 2012-08-10, 14:47
+
Josh Elser 2012-08-10, 15:55
+
Adam Fuchs 2012-08-10, 16:05
+
Josh Elser 2012-08-10, 16:28
+
David Medinets 2012-08-11, 03:38
+
Edmon Begoli 2012-08-10, 16:33
+
Marc Parisi 2012-08-10, 17:00
+
Christopher Tubbs 2012-08-11, 01:05
+
Edmon Begoli 2012-08-10, 16:02