I'm not sure which part this refers to. For example, theRAD is a standard
specification that
can be implemented in multiple technologies.
Thanks,
Dave
Thomas Clark writes:
> 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" <dwf at lanl.gov>
> 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
