Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
+
Josh Elser 2012-08-10, 02:19
+
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
Copy link to this message
-
Re: Security and data design advice on structuring data on accumulo
That's what I meant, user*doctors.

It's not enough to say "healthteam", you have to qualify it by user too:
"adamhealthteam".

On 8/10/12 9:02 AM, Adam Fuchs wrote:
>
> I guess I should have specified that the access time labels should be
> used in conjunction with the role labels, like
> "(adamsHealthTeam&(regularCheckup|illnessEvaluation))|(massStateResearcher&populationStudy)".
>
> Adam
>
> On Aug 10, 2012 8:56 AM, "Benson Margulies" <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     On Fri, Aug 10, 2012 at 8:52 AM, Adam Fuchs <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote:
>     > Not sure I understand why this gets into n*m roles. Can you
>     elaborate?
>     >
>     > The question of when your physician should have access seems
>     like it could
>     > be represented by just a few labels, like "regularCheckup",
>     > "illnessEvaluation", and "populationStudy". Those labels could
>     then be tied
>     > to an auditing system that could verify appropriateness of
>     access over time.
>
>     And if you change doctors? Maybe that's a job for some sort of
>     role/group model.
>
>
>     >
>     > Adam
>     >
>     > On Aug 9, 2012 10:19 PM, "Josh Elser" <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote:
>     >>
>     >> 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
+
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB