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]> wrote: > On Fri, Aug 10, 2012 at 8:52 AM, Adam Fuchs <[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]> 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 > >>> 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. > >>> > >>> > > >
