Hi Patrick, Good questions! I have been looking at the issues at the record level:
1)archival (personal, facility, Secure Data Store; no direct government involvement) 2)who serves the records (e.g., can't keep going to the archive) 3)record updates at the server 4)EDI for the records 5)Translation for the records (temporary vs permanent foreign format) 6)Interfacing with Insurance organizations (priority databases) 7)maintaining records at the Healthcare facility (temporary vs permanent; single vs multiple record formats; caching records; facility records that incorporate non-healthcare data; privacy, security) 8)inter-facility, record-based communications, e.g., conferencing, remote and roving participation 9)replication and modification 10)summary record formats, e.g., for the Patient and facilitators (e.g., administrators) Lots of development issues embedded here, both record implementation and information. Moving content between record systems and retrieving, re-formatting and transmitting information are the two main areas. Possible solutions/directions: 1)a 'carrier' system for Healthcare records, e.g., a 'wrapper' for Healthcare records that is capable of many formats and essentially passes the buck to the recipient system (FibreChannel transmission; frame-based communications) 2)multiply-formatted information (redundant), e.g., identical information stored in multiple, dissimilar records (different formats; each potentially serving different areas, legal systems, etc) 3)yet another Healthcare record format My suspicion is that facilities will be dealing with multiple record formats for a rather long time. Deployed software uses foreign record formats and is unlikely to change when an OpenEHR format/protocol is announced. My suggestion is to direct efforts at developing a format/protocol that interfaces to most of the existing formats and grows from there. Would be nice to form a close relationship with device vendors on this. The bottom line is that deployment requires something close to transparency, i.e., a facility should be able to ignore the fact that there are devices and systems working together that support different record formats. -Thomas Clark ----- Original Message ----- From: "Patrick Lefebvre" <[email protected]> To: <openehr-technical at openehr.org>; "Thomas Beale" <thomas at deepthought.com.au> Sent: Tuesday, May 06, 2003 6:18 AM Subject: Re: openEHR security > 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. > 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
