accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edmon Begoli <ebeg...@gmail.com>
Subject Re: Security and data design advice on structuring data on accumulo
Date Thu, 09 Aug 2012 19:44:33 GMT
Thanks Marc for the ideas and thoughts. Very helpful.

Few more bits of information on my labeling requirements - in my case
there is matrix of permission that
reflects individuals visibility into data, his/her providers rights
and then a whole state/federal hierarchy of permissions.

For example:

John Doe from Tennessee can see his/her data as well as his/her physician.

Doe's state medicare/medicaid administrator can see this PHI data as well.

So does federal medicare or mediaid administrator.

Then, if Tennessee and Georgia have data use agreements, they can see
each others state data.
(this is very much like law enforcement)

In general, there is a matrix of roles.

Btw, I welcome any collaboration on this aspect of privacy research
in the context of Accumulo that would result in open source software
development
and R&D publications.

Regards,
Edmon

On Wed, Aug 8, 2012 at 6:29 PM, Marc Parisi <marc@accumulo.net> 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 <ebegoli@gmail.com> 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.
>
>

Mime
View raw message