> But that's not really n*m, since it only specifies me by name. This should > be roughly linear with users, no?
Correct. On Fri, Aug 10, 2012 at 12:05 PM, Adam Fuchs <[email protected]> wrote: > But that's not really n*m, since it only specifies me by name. This should > be roughly linear with users, no? > > There is definitely a reliance on some external service managing the roles > that docs are in, but this should be tractable. > > Adam > > On Aug 10, 2012 11:56 AM, "Josh Elser" <[email protected]> wrote: >> >> 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]> 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. >>> >>> >>> >>> >>> > >> >> >
