RFC CR-000024 - Revert "meaning" to String - ARB deadline 23 july 2004

[Nathan Lea]

Please note that due to engineering works, the OpenEHR server will have  
to be shutdown today until tomorrow morning (approx 9am).

With best wishes,

Nathan
 
--
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems
Centre for Health Informatics and Multi-Professional Education
University College London
Holborn Union Building
Highgate Hill
London N19 5LW
Direct Line: +44.20.72.88.33.72
www.ehr.chime.ucl.ac.uk

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Data Security was: Basic EHR functionality

[Nathan Lea]

On 9 Mar 2004, at 06:51, Thomas Beale wrote:
> A well known study in Harvard medical school (I think) showed that 
> putting the message "Do not inappropriately access patient data - all 
> your accesses are being logged" on clinician screens a few times a day 
> resulted in a drop to near 0 of inappropriate access. No other 
> technology was used

Indeed - but the (perhaps) disingenuous claim which is flashed across 
clinicians' screens will only work for a finite period before people 
stop believing it and revert to their old habits.  Security is a 
process, and it requires constant amendment and updating.  If someone 
wants to "attack" a system (in this case by inappropriately accessing 
records), they will.  To use a phrase which is undoubtedly well known 
to everyone, "there is no silver bullet" - especially where security is 
concerned...

A good book to look at on the subject of insecure data is The Art of 
Deception by Kevin Mitnik.

Never say die.

Best,

Nathan
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1008 bytes
Desc: not available
URL: 

Data Security was: Basic EHR functionality

[Nathan Lea]

After discussion with Dr Dipak Kalra, we felt that the following would 
be of interest:

As part of the EHR developments at UCL we have been looking at 
appropriate ways of auditing user interactions with individual EHRs, as 
part of an overall security approach. For over a year our record server 
has kept an audit trail of each user access to or addition of data to 
any EHR. Through a helpful student project last summer (thanks to Asif 
Ali) we now also have a first prototype client and query service that 
permits an administrator to examine which users have accessed parts of 
an individual patient's record, which records a given user has 
accessed, or the general accesses that have occurred for any given 
archetype, within any date-time period. What we next need to do is to 
extend the client to support richer interrogation, and to examine again 
if we are retaining the most appropriate data items within the audit 
log. A further challenge is for us to explore the level of granularity 
at which to retain the audit information.

The biggest question in Dipak's mind is how best to "audit" the result 
of running a query in which many record components are extracted and 
examined (perhaps by an application) to determine if they fulfil the 
query criteria, but only a few are actually returned to the end user 
initiating the request. The record server might not "know" of the 
filtration taking place, since its interactions would only be with the 
application, and not the end-user.

On consideration of the recent discussion regarding the Harvard 
University experiments to display warning messages on the screens of 
clinicians, we have this facility to log user (whether users are 
clinicians or patients) access to EHRs; a work in progress project to 
develop a browser screen to access this data and display it is 
described above - please see:

  http://www.ehr.chime.ucl.ac.uk/docs/Ali,%20Asif%20(MSc%202003).pdf

The data which is persisted and the GUI is keyed to logging user 
access, primarily to ensure that patient episode information and 
treatment recording is exported in a way which promotes efficient 
patient care and clinician support, with the added value that records 
access is logged for scrutiny should it be necessary.

Best wishes,

Nathan

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR discussion lists

[Nathan Lea]

> Q - should the list be completely open to any openEHR member (i.e. 
> anyone with a login), as for the existing 3 lists?
> Q - or should it be more closed, to protect commercial sensitivities 
> of some members? If so how would new members get onto it?
>
> Personally I think it should be open like the other lists. I believe 
> that commercial organisations have to take responsibility themselves 
> for using such lists while protecting any "secret" knowledge they 
> have. There is always, after all, private email. When we have an 
> answer to this, we will provide an access point to the list.

I agree with Tom's point on this.  Sensitivity to secrets of commercial 
orgs is of course important, but I feel that understanding by the 
community that there are such concerns, especially in an open 
environment, should be encouraged; I don't like the idea of making a 
more conditional use of a discussion list for implementors, a list I 
hope will be as useful a medium to share ideas and discussion as the 
other lists.

With best wishes,

Nathan

On 29 Jan 2005, at 14:38, Thomas Beale wrote:

>
> Dear all,
>
> IMPLEMENTERS LIST
> a discussion list for early adopters has been set up. We decided to 
> call it "openehr-implementers" (NOTE spelling of "implementers"!), 
> rather than "early-adopters" since in a couple of years' time there 
> will be people on the list who are at a mature stage of development.
>
> We are testing the list at the moment. What we need to know from the 
> community is how we should run it.
>
> Q - should the list be completely open to any openEHR member (i.e. 
> anyone with a login), as for the existing 3 lists?
> Q - or should it be more closed, to protect commercial sensitivities 
> of some members? If so how would new members get onto it?
>
> Personally I think it should be open like the other lists. I believe 
> that commercial organisations have to take responsibility themselves 
> for using such lists while protecting any "secret" knowledge they 
> have. There is always, after all, private email. When we have an 
> answer to this, we will provide an access point to the list.
>
>
> THE Reply-to PROBLEM
> We have asked in the past which way the openEHR community wanted the 
> list servers set, and it seemed pretty clear that most people would 
> prefer to have Reply-to set to the list, avoiding the annoyance of 
> using "reply-all" in your email client. However, our system 
> administrators have so far preferred to keep it the way it is, due to 
> the extra work involved in dealing with automatic holiday/absence 
> mail, as well as various other nuisances. As I am sure everyone will 
> agree, email is not what it used to be - spam and the sheer numbers of 
> people using email have made life more challenging for those who 
> manage systems. Nevertheless, we will endeavour to get this setting 
> changed for the community as soon as possible.
>
> - thomas beale
>
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
>
---
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems
Centre for Health Informatics and Multiprofessional Education
Royal Free and University College London Medical School
4th Floor, Holborn Union Building
Archway Campus
Highgate Hill
London N19 5LW
www.ehr.chime.ucl.ac.uk

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

possible rename of major package

[Nathan Lea]

Do it now or forever hold your peace ;)

"Information model" needs to be carried forward (it makes much more  
sense).  I don't think that it will be a disastrous change to  
anything done so far either...

Cheers,

N

On 11 Jul 2005, at 18:23, Thomas Beale wrote:

>
> In the current openEHR reference model, there are 3 top-level  
> packages, known as:
> - rm: the information model
> - am: the archeype model
> - sm: the service model
>
> The first of these really should be "im", not "rm", and is only  
> "rm" for historical reasons. As we convert from BitKeeper to  
> Subversion, and also as we are approaching release 1.0, it occurs  
> to me that it would be nice to make the change of "rm" to "im",  
> which would make documentation clearer, and reduce the confusion  
> around the phrase "reference model".
>
> However, there is already a fair bit of software, schemas and so on  
> around the place. It might be too late to make such a change. Note  
> that it need not be done for software still to be correct, since we  
> are only talking about a package name - it does not change any  
> class names, nor any tag names in XML data that I can think of.
>
> Can I have reactions on how this change would be received. It were  
> ever to be made, now would obviously be the time.
>
> - thomas beale
>
> -- 
> __ 
> _
> CTO Ocean Informatics (http://www.OceanInformatics.biz)
> Research Fellow, University College London (http:// 
> www.chime.ucl.ac.uk)
> Chair Architectural Review Board, openEHR (http://www.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
>
>

---
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems
Centre for Health Informatics and Multiprofessional Education
Royal Free and University College London Medical School
4th Floor, Holborn Union Building
Archway Campus
Highgate Hill
London N19 5LW
www.ehr.chime.ucl.ac.uk


-- next part --
An HTML attachment was scrubbed...
URL: 

A useful Java 5 book

[Nathan Lea]

For anyone out there who has an interest in using in Java 5.0 and  
needs a good, concise, quick, reasonably priced and accurate guide to  
the new features, I found the following extremely useful:

http://www.amazon.com/exec/obidos/ASIN/0072258543/ref%3Dnosim/ 
deliciousmons-20/002-9381773-9618440

The best thing is that it's less than 200 pages long and gives good,  
clear illustrations by short example.

Note this is the American Amazon site.  The book should be available  
locally in all cases.

Cheers,

N
---
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems
Centre for Health Informatics and Multiprofessional Education
Royal Free and University College London Medical School
4th Floor, Holborn Union Building
Archway Campus
Highgate Hill
London N19 5LW
www.ehr.chime.ucl.ac.uk


-- next part --
An HTML attachment was scrubbed...
URL: 

potential use of openPGP in openEHR

[Nathan Lea]

Thomas Beale wrote:

 >>* what standard or other open specification can openEHR point to that 
accurately specifies the format of digital digests and signatures of EHR 
data? It has to be something avalable to everyone, and implementable 
(preferably already implemented)?<<

openPGP seems a reasonable place to start.  I have also had some 
experience with the GPG implementation, and have found it useful, 
versatile and usable, but...

Vincenzo Della Mea wrote:
>> However, we also have to be mindful of how it can be implemented in 
>> all major OSs and languages. Gnu GPG is one approach, but I don't 
>> have any direct experience of it.
>
> As far as I understood, the current Italian law on digital documents 
> puts PGP/GPG on the weak side of digital signatures, following 
> european directives. You have strong signatures when you have a 
> certification infrastructure, where certification authorities fulfill 
> some legal constraints. PGP/GPG is more on a social certification method.
Thomas Beale wrote:

 >>I think this is true if PGP is specified as the certification 
infrastructure. We are not trying to do that here - just use the openPGP 
message specification to define the format of signature strings etc in 
openEHR data. I don't think openEHR should be specifying anything in 
terms of certificates, PKI, certainly not at this stage of the game.<<

... I agree with Tom on this point - it would be far too soon to get 
into these details.  I think that we will need to be open minded on the 
entire area for now, and watch various initiatives - PKI and 
certification are under a lot of scrutiny from both an engineering and 
usability perspective in terms of various e-Science projects in the UK 
within the security space - see 
http://portal.acm.org/citation.cfm?id=1090417&dl=GUIDE&coll=GUIDE&CFID=15151515&CFTOKEN=6184618
 
- while this is relevant to grid security in particular, you may agree 
that there are general issues regarding the use of PKI and so forth 
within the openEHR context.

With best wishes,

Nathan


-- 
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems
Centre for Health Informatics and Multiprofessional Education
Royal Free and University College London Medical School
4th Floor, Holborn Union Building
Archway Campus
Highgate Hill
London N19 5LW
http://www.chime.ucl.ac.uk/~rmhincl

openehr website

[Nathan Lea]

I have tested Firefox version 2.0.0.3 on Windows XP running off my  
MacBook and Parallels.  The openEHR site seems to work fine.

Bert - maybe you need to upgrade your version of Firefox? What  
version are you using at the moment?

With best wishes,

Nathan

---
Nathan C. Lea
Research Fellow
Electronic Healthcare Record Systems and Information Security
Centre for Health Informatics and Multiprofessional Education
4th Floor
Holborn Union Building
Highgate Hill
London N19 5LW
www.chime.ucl.ac.uk/~rmhincl/


On 16 May 2007, at 11:00, Dipak Kalra wrote:

> Dear Bert,
>
> As a quick check, it works perfectly on Firefox for Mac version  
> 2.0.2 Feb 2007 without any enhancements.
> Maybe someone else can test for Windows.
>
> With best wishes,
>
> Dipak
> 
> Dr Dipak Kalra
> Clinical Senior Lecturer in Health Informatics
> CHIME, University College London
> Holborn Union Building, Highgate Hill, London N19 5LW
> Direct Line: +44-20-7288-3362
> Fax: +44-20-7288-3322
> Web site: http://www.chime.ucl.ac.uk
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Discussion on persistence

[Nathan Lea]

Works fine for me (on a Mac using Safari and Firefox)...

What error are you getting, Eddy? We can pick this up outside of the  
mailing list if you want.

With best wishes,

Nathan

Nathan C. Lea
Research Fellow
Electronic Healthcare Records and Information Security
Centre for Health Informatics and Multiprofessional Education
University College London
4th Floor, Holborn Union Building
Highgate Hill
London N19 5LW
www.chime.ucl.ac.uk/~rmhincl
+44(0) 207 288 3798

On 8 Nov 2007, at 18:34, Eddy Rospide wrote:

> Hi David,
>
> The thesis link does not work.
>
> Thanks,
>
> Eddy
>
> David Ingram  wrote:
> The interesting discussion about database persistence layers for  
> EHRs minds me to point the group to my PhD student Tony Austin's  
> research, which underpinned the current CHIME clinical cardiology  
> record and decision support system demonstrators, based on our  
> precursor work to openEHR, in the EU GEHR and Synapses projects.
>
> The thesis can be accessed at:
>
> http://www.ehr.chime.ucl.ac.uk/download/attachments/71/Austin%2C+Tony+%28PhD+2004%29.pdf?version=1
>
> The main quantitative results begin on page 191, although that whole  
> chapter needs to be read to understand how the tests were set up and  
> performed.
>
> Here is the abstract, to give an idea of the scope. It was a huge  
> piece of experimental work, with live records, and probably could  
> have made two PhDs;  it took a long time!
>
> The new version of the server, in beta test, is archetype based, but  
> is not a native implementation of the openEHR Reference Model  
> specifications, as that is a step too far for us at our demanding  
> clinical application coal face, at the moment.
>
> Abstract of Tony Austin's PhD thesis, April 2004.
>
> Records grow and multiply for a patient throughout their life.  
> Healthcare enterprises are presently
> unable to integrate the clinical information continuously  
> accumulating from patient care or to
> communicate it to a point of need. Their medical records are  
> expected to be legally valid, complete,
> accurate, and available in a timely fashion. As a consequence they  
> must be adequately expressive and
> maintained in such a way as to facilitate secure physical retrieval.
> This thesis begins by considering the history of structured and  
> electronic medical records, along with
> the histories of distributed systems and databases. It proposes key  
> infrastructure technologies that
> could be used for the development of an electronic healthcare record  
> server. Two models are then
> established, to represent transferable clinical records in general,  
> and to represent the structure that
> those records are required to take. With these there is a means to  
> ratify healthcare data between
> different providers and ensure that received healthcare data of any  
> type can be meaningfully
> processed.
> The performance strengths and weaknesses of seven different physical  
> databases are assessed. These
> represent a cross-section of relational, object-oriented and XML  
> technologies. Another
> implementation is created for the purposes of federation. A large- 
> scale deployment involving
> anticoagulant therapy management within a hospital Cardiology  
> Department provides clinically valid
> evaluation data.
> An object-oriented model is shown to be highly suited to the task of  
> representing medical data.
> Middleware code converting object model data to any of the database  
> architecture formats is never
> demonstrably the limiting factor in the performance of the overall  
> server. Consequently relational
> databases are equally suitable as persistence engines for medical  
> records. The new class of XML
> databases perform well but incur significant space overhead.
>
> Hope this may be of interest to those considering these issues, now.  
> Obviously the world has moved on but the way we tackled the issues  
> may still have some relevance.
> David Ingram, Professor of Health  
> Informatics, Tel.  020 7288 5965
> CHIME, University College  
> London, Fax. 020 7288 3322
> Archway Campus, Highgate Hill, London N19 3UA  
> http://www.chime.ucl.ac.uk 
>  ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>