Hi David, Definitely a component to be included in the: facility-facility-DataStore-Management network. There are other candidates, i.e., want to avoid focusing on a single technology.
-Thomas Clark ----- Original Message ----- From: "David Forslund" <[email protected]> To: "Patrick Lefebvre" <patrick.lefebvre at psl.ap-hop-paris.fr>; <openehr-technical at openehr.org>; "Thomas Beale" <thomas at deepthought.com.au> Sent: Tuesday, May 06, 2003 11:29 PM Subject: Re: openEHR security > At 03:18 PM 5/6/2003 +0200, Patrick Lefebvre wrote: > >Hi everyone, > > > >As Thomas & al. pointed, security addresses "a number of aspects", > >including security policy (defining who does what), data safety, and how > >security is ensured: so, including safety of the network, the application > >architecture -including management of messages: asynchronous/EHRcom/XML, > >or synchronous/CorbaMed/IDL-, the programs, and the platform. > > Just a minor comment here. "CORBAmed" and thus CORBA deals with both > asynchronous and synchronous "messaging". > I would also second the comment by Tom Culpepper about a service which goes > a long way to mediate the security requirements in healthcare. > > Dave > > >Great. > > > >I agree with Gerard Freriks's considerations (legal, social control and > >organisational aspects) but for now I only focus on the technical > >specification. > > > >For now, I will focus on far restricted objectives. > >One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure > >ascending compatibility. > >ENV13606 messages (part 3 : "distribution rules") describe access policy > >in terms of objects ("Who", "When", "Where",etc.) whose instanciations > >define the allowed access context to message objects. > > > >So, in the viewpoint of EHRcom release 1 in 2004, > >* Will this (or such an) architecture be reused in EHRcom ? > >* If no, will we have a tool to convert distribution rules into > >corresponding archetypes ? > >* If no, how is it planned to ensure ascending compatibility ? > > > >Another basic, technical, concrete security point is: ensuring data > >(transmission + authoring) integrity in the message. > >One solution proposed by ENV13606 was: systematic digital signature of > >each transaction. > >Will EHRcom reuse this mechanism ? > > > >One last point is: our deadline for a (definitive ? initial ?) specification. > >In EHRcom specs, what can we define for now as a stable 2004 milestone ? > > > >Maybe my questions are FAQs. > >Thank you for your kind replies. > > > >-- Patrick Lefebvre > > > >- > >If you have any questions about using this list, > >please send a message to d.lloyd at openehr.org > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
