So how would one configure these dynamic attributes, would it be pr program?
I would love to see a model where "person" don't exist anymore. A person would be something you'd assemble from a starting point (lets call it entity), and then add attributes to it. It also allows to re-use the model (without the person confusion) for monitoring, etc, a simple example would be creating a entity called Server with attributes Name, IP, Location, then this entity could be sending multiple single events with registration to the system, and you could to healthchecks that way. One thing I didn't quite get, why would we not collapse attributes and identifiers? I get the thing about referential integrity, but we have the same issues with requires attributes, length of attributes, type of attributes etc. We will have to validate this model anyways, adding a uniqueness validation seems like a small task with only benefits (i.e. removing the patientidentifiers table) -- Morten On Mon, Nov 18, 2013 at 10:20 AM, Lars Helge Øverland <[email protected]>wrote: > Re Ola's point, I suggest we go for the option with a property on > attribute discriminating between "confidential" and not confidential > attributes. Then we can put these into separate tables and encrypt the > confidential ones. Suggest that confidential attributes are simply not > available in "analysis" reports (ie. tabular report). This will be > difficult since we cannot access this data using plain SQL anymore, and it > will be a way to circumvent security in any case. They must be available in > person search of course. > > > > -- > Mailing list: https://launchpad.net/~dhis2-devs-core > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dhis2-devs-core > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp
