# Basic EHR functionality

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2004-03-05 18:55 UTC
**Views:** 23
**Replies:** 49
**URL:** https://discourse.openehr.org/t/basic-ehr-functionality/14456

---

## Post #1 by @Matt_Evans

Dear all,

I would be grateful for some advice on an issue that has been troubling me
for some time\. I am a clinician currently on secondment full time to an EHR
project\. I do not wish to name the software house we are using but they are
a major EHR developer with an interest in the UK\.

The application on which we are currently basing our documentation strategy
seems to have a flaw\. The following is a made up example but I hope it
illustrates a point\.

The application allows the creation of documents with standard windows form
controls \(e\.g\. drop down lists, multiselects, radio buttons etc\)\. When I
open a document it pulls though the appropriate value to each field from a
previous form\. Let's say I have a free text field that says 'Reasons patient
unfit for surgery' and I have entered "pneumonia" as the value\. I save the
document and can view the information from the document viewer\.

A month later I review the patient and they no longer have pneumonia\. I open
the pre\-op assessment document \(which pulls through pneumonia to the
relevant field\) and delete it\. The form is therefore either saving a zero
length string or null value\. The amended document is saved and the correct
information can be viewed in the document viewer\.

Now, the patient phones up with some additional information which I wish to
add to the assessment\. I open it up to add that info\.  On a different page
of the document however the 'reasons not fit' box pulls through not the last
value \(null or ""\) but the last non\-null or "" value i\.e\. pneumonia\. When
the document is signed the author has unwittingly signed the fact that the
patient is unfit for surgery as that is the value in that field now\. The
system automatically runs a theatres scheduling query and that patient is
permanently rejected as being unfit for surgery\.

This is one of a number of significant problems with the system that in my
opinion make it at best inconvenient or in some cases unsafe to use\. All
control types are affected and the solution we have been offered thus far is
that you don't pull any values through\. Therefore you have to retype all the
information every time\!  The other worrying thing is the number of hours
spent by Trust staff and IT staff on designing and building all the
documentation is phenomenal and has resulted in very little\.

The UK government has spent an estimated £2\.3 billion on systems for the NHS
for the first 3 years of a 10 year contract\. This causes me concern given
the above issue may be the tip of the iceberg\.

I am something of an amateur dabbling in the world of IT so would appreciate
some informed opinion\.\.\.

Thank you\.

Matt

---

## Post #2 by @Tim_Cook1

That is incredible\!\!\! I really like their idea of a fix\! <sarcasm>

The actual fix of ensuring a null \(or a space in it's place if the
system won't allow null fields\) is written should be easy enough to do\.
I think if I were in charge of the project I would have to insist they
fix this\.  If nothing else a warning should pop up that states other
fields have changed on non\-viewed pages\. If for some reason \(poor
design?\) they can't fix it\. Then the feature of pulling through the data
should be disabled completely and not touted as an application feature\.

I'm not sure what kind of opinions you are looking for but I would
consider this unacceptable for any business application much less in a
case where lives could be in jeopardy\.

I fear that now you are going to become embroiled in a politically
charged situation now\.

Good Luck,

---

## Post #3 by @Thomas_Clark

Hi Matt,

Comments in text\.

Regards\!

\-Thomas Clark

Matt Evans wrote:

> Dear all,
>
> I would be grateful for some advice on an issue that has been troubling me
> for some time\. I am a clinician currently on secondment full time to an EHR
> project\. I do not wish to name the software house we are using but they are
> a major EHR developer with an interest in the UK\.
>
> The application on which we are currently basing our documentation strategy
> seems to have a flaw\. The following is a made up example but I hope it
> illustrates a point\.
>
> The application allows the creation of documents with standard windows form
> controls \(e\.g\. drop down lists, multiselects, radio buttons etc\)\. When I
> open a document it pulls though the appropriate value to each field from a
> previous form\. Let's say I have a free text field that says 'Reasons patient
> unfit for surgery' and I have entered "pneumonia" as the value\. I save the
> document and can view the information from the document viewer\.
>

Sounds like a database retention/persistence problem\.

Q: How are the documents stored?

Caution: Document translations can get munched as well as the primary database, e\.g\.,  create
and save a document\. A week later you retrieve 'a document' and it is different\. One can
blame it on the database but it may be the procedures used to store the document
permanently\. Try creating a document and immediately retrieving it\. Assuming no problems,
logout or get off the system and after some number of hours get back on and access the
document\.

This proves enough time for the document to be flushed out to permanent storage\. Too soon
and you are likely accessing a cache memory\. Try again 'once' each successive day and
verify that the document can be correctly retrieved\. A problem might show upon after the
next application 'update' process, e\.g\., flush the data\.

If everything looks OK then focus on how the document is being archived and how it is
being retrieved when you notice the errors\. If  different versions of the document are
contained with the system or storage subsystems there is a change that the retrieval
process has a bug, e\.g\., you update and one or more others access the document\.
Audit trails catch this stuff\.

> A month later I review the patient and they no longer have pneumonia\. I open
> the pre\-op assessment document \(which pulls through pneumonia to the
> relevant field\) and delete it\. The form is therefore either saving a zero
> length string or null value\. The amended document is saved and the correct
> information can be viewed in the document viewer\.
>
> Now, the patient phones up with some additional information which I wish to
> add to the assessment\. I open it up to add that info\.  On a different page
> of the document however the 'reasons not fit' box pulls through not the last
> value \(null or ""\) but the last non\-null or "" value i\.e\. pneumonia\. When
> the document is signed the author has unwittingly signed the fact that the
> patient is unfit for surgery as that is the value in that field now\. The
> system automatically runs a theatres scheduling query and that patient is
> permanently rejected as being unfit for surgery\.
>
> This is one of a number of significant problems with the system that in my
> opinion make it at best inconvenient or in some cases unsafe to use\. All
> control types are affected and the solution we have been offered thus far is
> that you don't pull any values through\. Therefore you have to retype all the
> information every time\!  The other worrying thing is the number of hours
> spent by Trust staff and IT staff on designing and building all the
> documentation is phenomenal and has resulted in very little\.
>

Here you are, at least, are making updates\. The application likely has a version control system
that is supposed to keep this straight and correct\.

Q: Can you rollback to prior versions of the document? If so, then you definitely need to talk
with the Administrator\. Also check the commands you present to the application\.

> The UK government has spent an estimated £2\.3 billion on systems for the NHS
> for the first 3 years of a 10 year contract\. This causes me concern given
> the above issue may be the tip of the iceberg\.
>
Comment: Bet you did not receive a guarantee or a warranty\.

Q: Was this application submitted to a rigorous Software QA procedure?

Q: Does the application have a 'Bug' Tracking system? You may not be alone\!

---

## Post #4 by @Tim_Churches

> The application allows the creation of documents with standard windows form
> controls \(e\.g\. drop down lists, multiselects, radio buttons etc\)\. When I
> open a document it pulls though the appropriate value to each field from a
> previous form\. Let's say I have a free text field that says 'Reasons patient
> unfit for surgery' and I have entered "pneumonia" as the value\. I save the
> document and can view the information from the document viewer\.
>
> A month later I review the patient and they no longer have pneumonia\. I open
> the pre\-op assessment document \(which pulls through pneumonia to the
> relevant field\) and delete it\. The form is therefore either saving a zero
> length string or null value\. The amended document is saved and the correct
> information can be viewed in the document viewer\.
>
> Now, the patient phones up with some additional information which I wish to
> add to the assessment\. I open it up to add that info\.  On a different page
> of the document however the 'reasons not fit' box pulls through not the last
> value \(null or ""\) but the last non\-null or "" value i\.e\. pneumonia\. When
> the document is signed the author has unwittingly signed the fact that the
> patient is unfit for surgery as that is the value in that field now\. The
> system automatically runs a theatres scheduling query and that patient is
> permanently rejected as being unfit for surgery\.
>
> This is one of a number of significant problems with the system that in my
> opinion make it at best inconvenient or in some cases unsafe to use\. All
> control types are affected and the solution we have been offered thus far is
> that you don't pull any values through\. Therefore you have to retype all the
> information every time\!  The other worrying thing is the number of hours
> spent by Trust staff and IT staff on designing and building all the
> documentation is phenomenal and has resulted in very little\.

First of all, I would ask the developers to show you the data model they
are using, and in particular explain how it stores versions of
documents/records\. Don't be fobbed off\. If they say "it's too
technical", explain that you are not thick and insist that they explain
it to you\.

The detailed answer is that there needs to be some way for the EHr
application to determine, for each data item, whether pre\-filling the
field for that data item on a new form/record with the value from a
previous record/form is a useful, neutral or counterproductive thing to
do\. For example, sex is unlikely to change, so it is a safe bet to
pre\-fill the form with the patient's sex last time\. Likewise DOB and/or
current age\. Others are value\-dependent\. For example, there is no such
thing as chronic pneumonia \(recurrent, yes, but not chronic\), so there
is no point repeating such a diagnosis, whereas if the diagnosis is
diabetes, it is worth keeping\. Obviously, under the bonnet, an EHR
should not be modelled like a paper\-base medical record, but rather as
many different but related data items, some of which are persistent
properties of the patient, others of which relate to the particular
clinic episode or service\. All these may be presented using a paper form
paradigm, but that's not how it should be stored\. That's why you need to
ask to see the logical data model, or maybe the conceptual data model
\(the physical data model probably contains too much operational clutter
to make sense to anyone but the developers\)\. If the developers don't
have a logical data model to hand, which they can explain to interested
testers/end users like yourself, then it is time to get some new
developers\.\.\.

> The UK government has spent an estimated £2\.3 billion on systems for the NHS
> for the first 3 years of a 10 year contract\. This causes me concern given
> the above issue may be the tip of the iceberg\.

Yes, a budget of £2\.3 billion is a problem, given that the probability
of success seems to be an inverse function of the funds available\.

> I am something of an amateur dabbling in the world of IT so would appreciate
> some informed opinion\.\.\.

The worlds of IT and health are about to collide, or coalesce, or
intersect, or something, in an inescapable way\. So no need to apologise
for being a "dabbler"\. It is the IT people who need to apologise for so
often obfuscating and complicating things \(of course, the same criticism
has been levelled by patients at the medical profession\.\.\.\)\. Anyway,
just as \(some\) patients now come armed with copies of the latest
clinical trial results or meta\-analyses, so should health professionals
meet with their IT providers clutching entity\-relation diagrams and be
prepared to ask difficult questions about data models and other "arcane"
IT matters\. Of course, the openEHR two\-level model hopes to make this
interchange easier\.

---

## Post #5 by @Jean_Roberts

This thread takes me back \(30 years\) to a Cobol\-based NHS payroll system
which in one glorious month paid every single NHS employee in the region
a safety boot allowance, because the first person on the payroll was an
ambulance man who at that time got it and the record was not cleared
down between processes\!\!\!\!  It was only a pittance per person but it was
a lot overall but still too costly to recover\. \.\.\.\.\. and that one was
only money\. To have similar this far on and with clinical data is
frightening and just the sort of thing that UKCHIP \(www\.ukchip\.org\.uk\)
registered health informaticians should not accept\.
If any of you are at HC2004 in Harrogate \- come to BCS stand D2 and tell
me how things are progressing, please

Jean Roberts
Brit Comp Soc Health Informatics Committee

---

## Post #6 by @thomas.beale

Matt Evans wrote:

> A month later I review the patient and they no longer have pneumonia\. I open
> the pre\-op assessment document \(which pulls through pneumonia to the
> relevant field\) and delete it\. The form is therefore either saving a zero
> length string or null value\. The amended document is saved and the correct
> information can be viewed in the document viewer\.
>
> Now, the patient phones up with some additional information which I wish to
> add to the assessment\. I open it up to add that info\.  On a different page
> of the document however the 'reasons not fit' box pulls through not the last
> value \(null or ""\) but the last non\-null or "" value i\.e\. pneumonia\. When
> the document is signed the author has unwittingly signed the fact that the
> patient is unfit for surgery as that is the value in that field now\. The
> system automatically runs a theatres scheduling query and that patient is
> permanently rejected as being unfit for surgery\.
>

this is basic software error\. Where it is, or how indicative it is of the quality of the whole package I have no idea, but it is unacceptable\. You have to proceed on the principle that if such an error can occur in this part of the system, it can occur anywhere \- which really means the whole system has to be viewed suspiciously \- what if such an error occurred in some more vital bit of information? I would be asking for proof of quality assurance and customer acceptance testing \- this means documents showing that numerous system level tests were performed and passed\.

Mike Mair mentioned versions \- he is right, it's a key issue in this scenario \- correct conceptualisation and implementation of versions is crucial to properly capturing changes to data\. And usually badly / not implemented\.

> This is one of a number of significant problems with the system that in my
> opinion make it at best inconvenient or in some cases unsafe to use\. All
> control types are affected and the solution we have been offered thus far is
> that you don't pull any values through\. Therefore you have to retype all the
> information every time\!
>

that's also completely unacceptable \- apart from the annoyance factor, you will eventually make keyboard/fatigue errors and put a wrong value in \- what logic does the system have for resolving conflicts?

>  The other worrying thing is the number of hours
> spent by Trust staff and IT staff on designing and building all the
> documentation is phenomenal and has resulted in very little\.
>
> The UK government has spent an estimated £2\.3 billion on systems for the NHS
> for the first 3 years of a 10 year contract\. This causes me concern given
> the above issue may be the tip of the iceberg\.
>
> I am something of an amateur dabbling in the world of IT so would appreciate
> some informed opinion\.\.\.
>

I would ask for:
a\) documented requirements which this system is supposed to fulfill \- i\.e\. what must have been given to the vendor\. If no\-one can  supply this, you can be sure that the system has no fitness for purpose
b\) proof that those requirements were fulfilled in the form of customer witness test results \- as I say above \- a standard procurement exercise \(these consists of: a test plan, procedure and test cases, and a set of reports showing which ones passed and which failed during controlled, witnessed testing\)\. If no\-one can supply this, you know nothing about the quality or fitness of the system to fulfill the requirements \(assuming you can get those\)\.
c\) documents describing the problem reporting and fault\-rectification process, and some indication of time the vendor will take to recitify faults of high priority \(like those you describe\)

that's just for starters\. Please report back on how you get on\!

\- thomas beale

---

## Post #7 by @Mike_Mair

Dear Matt,

Helping out here may be like giving away trade secrets\. However in the
interests of the open EHR, try this\.

The problem is similar to one I had with an Ophthalmology data base\. This
created a 'general screen' on first patient contact with an appropriate
'SOAP' structure, then would allow the clinician to graduate to a more
specialized protocol such as 'glaucoma' or 'cataract' as the client's
condition became understood and a care plan made\. There would be copy
forward of fields for new 'general' encounters or for successive iterations
of encounters structured by the more specialized screens\. But if you went
the other way and created a general screen from a specialized screen \(to
follow some other bit of pathology that turned up\), and wanted to share data
harvested in field common to both \(e\.g\. IOP or 'intra\- ocular pressure',
which is a simple numerical value\), you had to reverse copy, with as many
lines of programming as there were separate forms that might share fields\.

It was much simpler to make the field entities into 'classes' just like
archetypes, so that the forms which shared fields always 'looked at' the
latest instantiation from the latest encounter\. The 'carry forward' was
achieved because the 'object' looked at was always the latest one
harvested/instantiated \(for that class/archetype\)\. So whatever form you
pulled down, all the 'fields' in it that were shared with any other forms
\(or new ones you might make\), looked at the same corpus of harvested
'objects', and would always show the most recent one \(and thus the most
current value, in the case of IOP, or pneumonia status, as in the example
quoted\)\.

Its a kind of 'versioning', since in this model, all forms would end up as
attested documents for storage and communication \(as CDAs\), and later ones
are also attested\. So you don't usually look at the pre\- op assessment
document you originally created, but an updated version of it, although the
earlier one is there to remind you of your errors when required to\.

Mike Mair

---

## Post #8 by @Matt_Evans

Thank you to all for your helpful suggestions\. I shall start to go through
them all and see what we can do\. No doubt I'll be seeking further advice in
due course\.

The basic problem for us is that changes to code are controlled by the
software house HQ\. Sometimes changes take months \(on one occasion 18 months
I am told\) to be introduced\. For this particular problem they have given the
official response that they do not intend to change the functionality\. I
don't see how we can continue to develop documentation until they do\.

There is a theory in psychology about learned helplessness\. If you keep
giving a rat an electric shock even when it attempts to do things to avoid
the shock, it eventually gives up and just sits there being shocked\. In
psychiatry we talk about the locus of control\. If we perceive control over
our destiny not to be internal we become depressed\. It is no wonder that our
project has an air of depression about it\. Going back to my original email
what concerns me is that it seems to be taken on trust that multi million
pound software is up to the job and that the negotiations occur around how
quickly and how cheaply it can be implemented\. Who is actually checking the
software meets the needs of the users technically and clinically before
handing over the cheque? Apologies for sounding unduly pessimistic here but
I think it's a debate that needs to occur\.

Matt

---

## Post #9 by @Thompson_Ken

This entire thread was interesting\.

I was reviewing a versioning design proposal with some of my physician
customers the other day and we worked through some of the same territory\.
One thing we talked about a bit that did not get touched on here was the
issue of interim saving of data for short term recovery from technical
failures\.

This is the functional equivalent of the "Autosave" feature of Microsoft
Word, which continually writes over a temporary file in accordance with a
time schedule as you are editing a document\. This file is typically deleted
when the copy in program memory is formally saved by the user\. If for some
reason the editing process terminates abnormally, the program recognizes
that an in\-process document was not closed properly and offers the
opportunity to re\-open the document at the point of the last automatic save\.

One of the questions raised during the discussion is whether the overriting
of the temporary file would be considered a violation of proper medical
record handling procedures\. Clearly, once a version of the document is
formally saved, it has standing as a historical document that prevent
subsequent modification without appropriate noting regarding the source of
the change, original text, and the date and time of the change\.

Do you thing that a document being informally saved by an automated process
designed to support recovery of the document should be subject to the same
modification constraints as a formally saved document?

Best Regards,

Ken Thompson
UNC Healthcare

---

## Post #10 by @Tim_Cook1

I would say that the data is not a formal document until a deliberate
action is made by the creator to commit it as such\.

Does anyone know if there is any existing legal precedent on this?

Tim

---

## Post #11 by @lakewood

Hi Matt,

The following are suggestions that depend upon specific functionality in the EHR software
and should be the topic of discussions with your Systems Administrator:

1\)Create a personal record stream accessible by you that contains all records accessed
and updated by you plus all records in which you are entered in and that are accessed
and updated by others \(thus includes services, e\.g\.,backup, restore, compression,
archiving\)\.

This 'forking' will allow you to look at the records and filter those associated with
specific Patients\. Another useful utility is one that can scan for changes\.

2\)If a record\-locking mechanism exists, and records can be 'locked' by Providers,
use it\.

3\)See if 'field\-locking' is available, e\.g\., select a field, lock it and receive notice of
attempts to access and modify\.

These may or may not exist\. If they do, you will need help from the System Administrator\.

Regards\!

\-Thomas Clark

Matt Evans wrote:

---

## Post #12 by @Tim_Churches

> Thank you to all for your helpful suggestions\. I shall start to go through
> them all and see what we can do\. No doubt I'll be seeking further advice in
> due course\.
>
> The basic problem for us is that changes to code are controlled by the
> software house HQ\. Sometimes changes take months \(on one occasion 18 months
> I am told\) to be introduced\. For this particular problem they have given the
> official response that they do not intend to change the functionality\. I
> don't see how we can continue to develop documentation until they do\.

How come you have to develop the documentation? Doing the documentation,
both system documentation AND end\-user documentation, should be an
integral part of the software development job \- it is when the
documentation is written that all those horrible, overlooked design
flaws really come to light\. The software firm might need to hire domain
experts such as yourself to help them prepare such documentation, not to
mention technical writers, but it should be part of their contract to
supply it, and the documentation, like the actual code, needs to be part
of the UAT \(user acceptance testing\) which Thomas mentioned\.

> There is a theory in psychology about learned helplessness\. If you keep
> giving a rat an electric shock even when it attempts to do things to avoid
> the shock, it eventually gives up and just sits there being shocked\. In
> psychiatry we talk about the locus of control\. If we perceive control over
> our destiny not to be internal we become depressed\. It is no wonder that our
> project has an air of depression about it\. Going back to my original email
> what concerns me is that it seems to be taken on trust that multi million
> pound software is up to the job and that the negotiations occur around how
> quickly and how cheaply it can be implemented\. Who is actually checking the
> software meets the needs of the users technically and clinically before
> handing over the cheque? Apologies for sounding unduly pessimistic here but
> I think it's a debate that needs to occur\.

If you are having a house built for you, then typically you make
regular, detailed inspections of the construction works, and/or you ask
your architect or an independent building inspector or site manager to
check that the builders are doing everything they should be doing to the
standard required\. Hired inspectors typically carry clipboards with long
lists of things to check on them\.

What you don't do is engage the builders, then wait for their phone call
telling you the house is finished, at which stage you take a quick
walk\-through, say, "looks fine" and sign the cheque\.

---

## Post #13 by @thomas.beale

Tim Cook wrote:

>> Do you thing that a document being informally saved by an automated process
>> designed to support recovery of the document should be subject to the same
>> modification constraints as a formally saved document?
>>   
> I would say that the data is not a formal document until a deliberate
> action is made by the creator to commit it as such\.
>
> Does anyone know if there is any existing legal precedent on this?
>

don't know about the legal precendents, but the openEHR specifications model this notion of versions and committal explicitly; they will be even more visible in the EHR service model we are producing\. If the "commit" action performed by the user is implemented by bundling of version changes into change sets, and a proper two\-phase transaction protocol, then it is easy to know if it worked or not \- the operation won't succeed unless it really has worked at the transaction level, and the user will know that in the GUI \(it is easy to post a message saying that it failed\)\. The only question then is whether the client side \(or even server side\) software implemented some kind of caching \(like MS autosave files\) \- and whether you can get back to the previous position by accessing something in a cache rather than redoing the changes from scratch\. Client\-side file caching is probably a security hole, but memory caching is safe enough\.

\- thomas beale

---

## Post #14 by @Tim_Churches

You are assuming that computers are turned off when they are not
attended or in use\. Increasingly that is not the case, with low\-power
workstations, laptops in suspend mode, and held\-held PDAs\. All that by
way of saying that much more attention now needs to be paid to the
security of client\-side caches in general, including those held in
sometimes\-but\-not\-always\-volatile memory\. In general, caches should be
held on encrypted filesystems, either on\-disc or in\-memory, with the
keys \(or a key to the keys\) to the encryption/decryption managed by a
daemon which purges the keys from memory when asked \(eg locking the
device\) or automatically after a short period of disuse\.

---

## Post #15 by @Tim_Cook1

Well, now that would certainly be a secure way to handle caching\.  If I
were worrying about national secrets\.

Do you go to this extreme now \(as a manager\) when doing your risk
assessments?  I am wondering what the total \(additional\) costs of system
design and hardware resources is when these facilities are implemented\.

I think that in most cases we can reliably depend on locked doors and
holding people responsible for protecting data they are entrusted with\.
I will agree that security training needs to include this awareness so
that users know how to properly store each of these devices when not in
use\.

Later,
Tim

---

## Post #16 by @Tim_Churches

> > In general, caches should be
> > held on encrypted filesystems, either on\-disc or in\-memory, with the
> > keys \(or a key to the keys\) to the encryption/decryption managed by a
> > daemon which purges the keys from memory when asked \(eg locking the
> > device\) or automatically after a short period of disuse\.
>
> Well, now that would certainly be a secure way to handle caching\.  If I
> were worrying about national secrets\.

Personal health information is more important than national secrets to
the individuals concerned\. Furthermore, it only takes the compromise of
a handful of individuals' confidential information, and publication of
this fact, before public confidence in your EHR evaporates\. So I don't
think that is overkill\. Note, however, the use of the subjunctive
"should"\. That's the way it ought to be done, and it is technically
achievable\. Unfortunately, browser and OS vendors/writers don't chose to
do that by default\. But certainly it can be done \- on Linux systems, it
is quite easy to set up encrypted filesystems and to store the browser
cache on these\. Likewise on Windows \- individual directories can be
encrypted \(although there are distinct flaws in the way the encryption
keys are handled in Windows \- still, better than not encrypted\)\.

> Do you go to this extreme now \(as a manager\) when doing your risk
> assessments?  I am wondering what the total \(additional\) costs of system
> design and hardware resources is when these facilities are implemented\.

Risk assessment: client workstations are often shared between users and
located in insecure locations, laptops are stolen or lost all the time\.
Thus confidential information which is captured in a cache on these
systems needs to be secured\. Note that if the EHR user is, say, a
physician, then there may be details of hundreds of patients in their
workstation/laptop cache\.

Does this represent a challenge to applications,especially Web browser
applications? Yup\.

Are technical solutions possible? Yup \- see above\.

Is all of this costly? Well, my view is that additional hardware
security devices are probably unnecessary \(and almost all are
unnecessarily proprietary anyway\), and the software required to
implement what I describe above is free \(at least for Linux \- on
Windows, file system encryption is only available on server versions, I
think \- at least that is the case with Windows 2000 \- not sure with
Windows XP/XP Pro\)\. Does the administration and training involved cost
money? Definitely, security doesn't come free\. Is the expense worth it?
See above \- only takes a handful of confidentiality breaches before you
can kiss confidence in your EHR goodbye for several years\.

> I think that in most cases we can reliably depend on locked doors and
> holding people responsible for protecting data they are entrusted with\.

Surely you jest? Client workstations, even in large hospitals \(or
especially in large hospitals\) have to be considered insecure, likewise
desktop PCs in doctor's offices \- common targets for drug\-related
burglary, and especially laptops and handheld devices which are pinched
or misplaced with monotonous regularity\.

The same applies to EHR/EMR servers, especially servers which are not
housed in dedicated, secured data centres, although even the latter are
far from invulnerable \- see for example
http://www.smh.com.au/articles/2003/09/04/1062548967124.html \- and then
there is the off\-site back\-up media etc to consider\.

> I will agree that security training needs to include this awareness so
> that users know how to properly store each of these devices when not in
> use\.

Security engineering is all about building systems which fail
gracefully\. Certainly training users is vital, but relying entirely on
users, or system administrators, or anyone, to always do the right thing
is a recipe for inevitable security failure\. It is always better to
build additional protection into the fabric of information systems, as
long as the cost is justified \- and that comes back to risk assessment
as you note\.

---

## Post #17 by @Thompson_Ken

The argument that we could lose our collective behinds in the event of a
significant security failure seems consistently incapable of generating
interest or resource allocations from senior management\. Basically, the
issue comes down to a legal deparment deciding whether or not they can
convince a jury that actions were reasonable and prudent given the resources
and situation\.  They have absolutely no interest or concern that a forensic
technical investigation would find design or implementation lacking, thereby
ruining the careers of the dedicated engineers that have worked on the
project\.

To a large extent, this is a result of poor of statistical data regarding
security breaches because organizations with something to lose are quick to
hush things up when they go wrong\. It is a basic part of the damage control
strategy of any large organization\.

In most cases, it is impossible to keep small scale security breaches under
control\. Copy and paste are still effective means of extracting data and
putting it into a document, mail message, database, etc that is outside of
the EHR system security\. Anyone with reasonable access can do this, and one
statistic I am familiar with is that 60% of all information security
breaches involve disgruntled employees\.

We deal with these issues as a matter of policy, auditing, and lawyers, not
expensive technical means\. Until someone is able to convince senior
management that their careers, reputations, etc\. are going to suffer from a
security breach, I suspect this will continue to be our strategy\.

The engineering staff, of course, keeps detailed documentation regarding our
recommendations and the eventual decisions that were made in all of these
matters\.\.\.;\-\)

Best Regards,

Ken

---

## Post #18 by @Thomas_Clark

Hi Tim,

One needs to look at where caching is applied and what type\. A memory cache could
care less about who owns the data; IO caching is tailored to the IO subsystems;
File System caching depends on the file system, e\.g\., distributed and journaling;
application caching is probably a bigger application for security, e\.g\., separating users
is feasible\.

Other security techniques can be applied to resource caching if deemed necessary\.

Restricted file systems for 'cached' data can do more than encryption, e\.g\., fragment,
has and encrypt\.

Regards\!

\-Thomas Clark

Tim Cook wrote:

---

## Post #19 by @Thomas_Clark

Hi All,

If one resorts to hardware to support security be sure to post guards\. WWII proved than
reliance upon hardware devices to provide adequate security is misplaced\.

Hardware components in a security system are acceptable if the software can re\-configure
them and alter even their basic functionality, e\.g\., re\-configurable computer systems and
networks\.

One significant advantage of ATM networking was the use of fixed\-size cells to transmit
data \(essentially a switching technology\)\. Try reconstructing cell\-based data on the fly or
store data in cellular format with separately stored reconstruction algorithms\. The problem
was solved long ago \- cellular systems\.

Any static security system is sensitive to determined efforts\. No security or inadequate
security mechanisms are invitations\. A single breach will likely destroy confidence\. The
ability to re\-configure and re\-deploy is essential\.

Regards\!

\-Thomas Clark

Tim Churches wrote:

---

## Post #20 by @Tim_Churches

> The argument that we could lose our collective behinds in the event of a
> significant security failure seems consistently incapable of generating
> interest or resource allocations from senior management\. Basically, the
> issue comes down to a legal deparment deciding whether or not they can
> convince a jury that actions were reasonable and prudent given the resources
> and situation\.  They have absolutely no interest or concern that a forensic
> technical investigation would find design or implementation lacking, thereby
> ruining the careers of the dedicated engineers that have worked on the
> project\.

Agreed\. Part of the problem is that it is viewed from the point of view
of legal exposure only, ignoring the fact that regardless of whether a
case is proved in court, the fact that the security of an EHR
implementation is seriously in question will be incredibly damaging to
that EHR \(and probably to some degree to all other EHRs, by
association\)\. This is made worse by the proponents of community\-wide
EHRs stating things like "it will be bullet\-proof" etc\. I can understand
the motivation behind such statements, but generally they are made
without the slightest appreciation of what is actually involved in
achieving the promised, or hinted\-at, level of security\.

> To a large extent, this is a result of poor of statistical data regarding
> security breaches because organizations with something to lose are quick to
> hush things up when they go wrong\. It is a basic part of the damage control
> strategy of any large organization\.

Absolutely\. There is a need for mandated reporting of information system
security breaches, in the same way that many countries have mandated
financial reporting requirements for public companies etc\.

> In most cases, it is impossible to keep small scale security breaches under
> control\. Copy and paste are still effective means of extracting data and
> putting it into a document, mail message, database, etc that is outside of
> the EHR system security\. Anyone with reasonable access can do this, and one
> statistic I am familiar with is that 60% of all information security
> breaches involve disgruntled employees\.

I absolutely agree, but it is nevertheless important to close
inadvertent security holes, such as invisible\-to\-the\-user browser
caching\. Certainly the biggest threat is from within \- from people who
are already "authorised users"\. Many security models focus entirely on
keeping out "unauthorised users", thus missing the majority of the
threat\. It is also necessary to think clearly about what is meant by an
"authorised user" \- in particular, do you mean the actual person, or do
you really mean anyone with access to that person's credentials/login
password\. The two are not necessarily the same\.

> We deal with these issues as a matter of policy, auditing, and lawyers, not
> expensive technical means\. Until someone is able to convince senior
> management that their careers, reputations, etc\. are going to suffer from a
> security breach, I suspect this will continue to be our strategy\.

Yes, that is what I have observed also\. But that is not the way it ought
to be\. And because centralised EHRs significantly increase the size of
the hazard associated with security breaches, I don't think that the
current methods of addressing security issues, as you describe, are
sufficient \- they need to be supplemented by architectural and technical
safeguards as well\.

> The engineering staff, of course, keeps detailed documentation regarding our
> recommendations and the eventual decisions that were made in all of these
> matters\.\.\.;\-\)

Yes, maintenance of "I told you so\.\." files is vital\.

Tim C

---

## Post #21 by @Tim_Churches

> Hi All,
>
> If one resorts to hardware to support security be sure to post guards\.
> WWII proved than
> reliance upon hardware devices to provide adequate security is misplaced\.

One should never rely entirely on any single security mechanism \- be it
hardware, software or wetware \(human behaviour\)\. I think you are
probably referring to the German Enigma encryption machines\. The
encryption was only broken because of operator error in re\-using the
same keys, or in using standard opening phrases in the messages\. Had
these human errors not been made, then the people at Bletchley Park
would never have broken Enigma, despite their very clever use of
electronic mechanical computers \(and later thermionic valve computers\)
to attach the ciphers\. The Enigma hardware itself was not flawed\.

> No
> security or inadequate
> security mechanisms are invitations\.

I think that is an important observation \- attackers will chose the
easiest path, thus it is important to close easy and obvious problems
\(such as client\-side browser caching\) if at all possible\.

Tim C

---

## Post #22 by @Sam

Tim

The openEHR and before it GEHR work on legality made it clear to me that a document has no legal status until it is saved in some voluntary manner \- just as a correction in a written document has no status as fact \(if you contemporaneously correct the document\)\.

Sam

---

## Post #23 by @system

Hi,

I agree\.
One can only be responsable for facts if this is shown by a conscious act like signing\.

TNO\-PG has developed a set of Essential Requirements for the application of IT in Healthcare systems\.
This is based on European Directives and other relevant texts\.
One of the basic items deal with the attestation of texts\.

Gerard

\-\-  <private> \-\-
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

\+31 252 544896
\+31 654 792800

---

## Post #24 by @Matt_Evans

Having been away for a couple of days it's difficult to know where to start
with so many responses\!

I think that the basic problem lies in the way the documentation system is
intended to be used\. That is for "one off assessments" where every time you
sign the document you are supposed to be signing that every piece of
information on the form is correct and/or a new event\. Therefore values are
pulled through to be 'helpful' rather than to form part of a piece of
ongoing documentation\. Items not verified are meant to be deleted by the
user I assume\. Whilst this is useful for some forms e\.g\. a rating scale it
is not helpful for most of the documenation we have designed\. There are a
number of different document behaviours I think we need to meet
requirements\.

An example of recording a blood pressure is that in an assessment I may wish
to record the blood pressure\. This could be taken by me and recorded as
such\. This may however have been taken by the nurse during the nursing
assessment 10 minutes earlier\. I may wish to record in my assessment that I
am happy with the value the nurse took and that it was part of this current
assessment\. Alternatively I may access the EHR and pull through a value 1
week ago and accept that \(with an appropriate explanation of what I've
done\)\. I may even want to use an automatically calculated value to include
the interquartile range of BPs over the past week and record that\. Our
system seems to either record a BP as new or not\. Any inclusion of a BP
value saves it as a new BP and all other controls seem to behave the same
way\. I can in theory have pulled through a blood pressure at every monthly
appointment \(from the value within the last month\) for 5 years and the
system would think the BP was being recorded as that every month\. A human
might find it suspicious that they are all the same looking back through the
history but the system has no means of knowing this\.

I believe the system is appropriately storing the versions of the documents\.
When I do include nothing in a field when a document is signed I can open up
that document at any point in time and see no value present\. When I open a
new document pulling through the last value this is when the previously
mentioned error occurs\. It is also true that the last value may be derived
from the same concept recorded in another form or document\.

Some of this behaviour and functioning is desirable in some circumstances
but it is assumed that it will work across all situations which I don't
think it does\. I shall take the issues about quality assurance to those in
the project better equipped to deal with them\.

Thanks,

Matt

---

## Post #25 by @Matt_Evans

Hello

Sam \- do you distinguish between saving and signing a document? Some
documents we have are works in progress \(e\.g\. a discharge summary document
added to bit by bit by multiple authors during an admission\) that only get
signed once ready for release\. I'm not sure how to represent this\.

Gerard \- do you have a link to a summary of the document you mention please?

Regards,

Matt

---

## Post #26 by @Ignacio_Valdes

At the VA, a note is still deletable until it is electronically signed\. You can save it and not sign it and still be able to delete it\. I do not know the algorithm of signature but it involves a pin\-like password that is different from your login\. I bet the VistA crowd would know\.

\-\- IV

---

## Post #27 by @Simion_Pruna

A successful operational medical record system for Diabetes based on the
Good European Health Record \(GEHR\), derived from an European research
project is the Black Sea TeleDiab system\. The diabetes data is based on the
WHO \(Europe\) Diabcare dataset\. This sysetm is written in C\+\+ and uses
Microsoft Access as its database\.  For whom are interested please let me
know and I am pleased to send you the source code\.   Code is not posted now
becasue had no time to up\-date the open source licence\.  Please visit  here:
http://www.sincromed.ro/bstd.htm

Best regards,
Simion Pruna

---

## Post #28 by @thomas.beale

Tim Churches wrote:

>> Client\-side file caching is probably a security hole, but memory caching is safe enough\.
>>   
> You are assuming that computers are turned off when they are not
> attended or in use\. Increasingly that is not the case, with low\-power
> workstations, laptops in suspend mode, and held\-held PDAs\. All that by
>

actually, I was assuming that al EHR user sessions are killed after N minutes of inactivity, and all client\-side resources let go\.

> way of saying that much more attention now needs to be paid to the
> security of client\-side caches in general, including those held in
> sometimes\-but\-not\-always\-volatile memory\. In general, caches should be
> held on encrypted filesystems, either on\-disc or in\-memory, with the
> keys \(or a key to the keys\) to the encryption/decryption managed by a
> daemon which purges the keys from memory when asked \(eg locking the
> device\) or automatically after a short period of disuse\.
>

this sounds about right to me\.

\- thomas

---

## Post #29 by @thomas.beale

Tim Cook wrote:

---

## Post #30 by @Sam

Matt

The openEHR model distinguishes this \- attestation can be done at any time and any number of times\.

Sam

Matt Evans wrote:

---

## Post #31 by @thomas.beale

Matt Evans wrote:

> Hello
>
> Sam \- do you distinguish between saving and signing a document? Some
> documents we have are works in progress \(e\.g\. a discharge summary document
> added to bit by bit by multiple authors during an admission\) that only get
> signed once ready for release\. I'm not sure how to represent this\.
>

this is a question we have been asked a few times\. There seems to be the following strategies:
A \- unfinished work could be committed to a 'holding bin' on the client machine; the author comes back in the next day and finishes it, then commits it for real\. Q: is this a security risk \(A: undoubtedly\); Q: what's to stop the author accidentally or intentionaly committing the work unfinished to the server anyway? If they did, we would still need to mark it as 'draft'
B \- unfinished work \(if marked as such\) could be committed to a holding bin on the server\. Safer\.\.\.

C \- unfinished work could just be committed to the EHR proper; the "draft" marker will cause it to be ignored from queries\.

If you think about it for 5 minutes, you see that B and C are the same, or at most, simply a question of where you store the information in your database\.

So\.\.\.I think that the solution is:

\* all documents \(they are "Compositions" in CEN and openEHR, "documents" in HL& CDA\) should always be committed to the server whether draft or completed
\* Compositions \(or some related class in the version control area \- probably Version in the openEHR Common model\) needs a status marker which can be "draft", "active" etc etc\.

\- thomas beale

---

## Post #32 by @Gavin_Brelstaff

Thomas Beale wrote:

> Tim Cook wrote:
>
>>> In general, caches should be
>>> held on encrypted filesystems, either on\-disc or in\-memory, with the
>>> keys \(or a key to the keys\) to the encryption/decryption managed by a
>>> daemon which purges the keys from memory when asked \(eg locking the
>>> device\) or automatically after a short period of disuse\.
>>>  
>> Well, now that would certainly be a secure way to handle caching\.  If I
>> were worrying about national secrets\. Do you go to this extreme now \(as a manager\) when doing your risk
>> assessments?  I am wondering what the total \(additional\) costs of system
>> design and hardware resources is when these facilities are implemented\.
>> I think that in most cases we can reliably depend on locked doors and
>> holding people responsible for protecting data they are entrusted with\. I will agree that security training needs to include this awareness so
>> that users know how to properly store each of these devices when not in
>> use\.
>>
>
> 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
> \- thomas

There must be a downside to do that too \- discouraging access by those
who have urgent need while being undertrained on the system \- it would
sure scare me off  \- and that would effectively reduce medic\-medic
communication rather than promote it\.  Sure security is important
but don't forget it is always compromise \[Bruce Schneier\]\.

---

## Post #33 by @Nathan_Lea

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

---

## Post #34 by @Thompson_Ken

Has anyone got any experience with the effect of providing users a periodic
summary of their activities on an EHR system? We are looking at a couple of
different options\.

1\) A periodic report to our user's inbox outlining their use of the system\.
This has an added benefit of giving the user a concrete sense of the
benefits they receive from the system as well as confirming that their
actions are, indeed, being monitored\.

2\) A mechanism on the patient record itself that displays a list of all
users that have accessed the record \(with date and time\)\. This will probably
be made available to the patient at some point, so they will actually
provide a critical part of the checks and balances in the system\.

Any other thoughts on this?

Best Regards,

Ken Thompson

---

## Post #35 by @Tim_Churches

This is similar to the mechanisms envisaged under the "Consent and
notification" secion of the now\-famous BMA Security Policy, developed by
Ross Anderson \- see
http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html

This is still the gold standard for EHR security policies, IMHO, yet
most people I have met who are involved in EHR work and who know of it
\(curiously many seem ignorant of it\) tend to dismiss it, not because the
policies are unsound \(although they do need minor tweaking here and
there\), but because implementing them is very difficult in practice \-
particularly the multilateral as opposed to multilevel access control
policy\. In fact you need both, but of the two, the former is more
important\. In other words, role\-based access control, where the "roles"
are specific to each patient, as well as to each health professional\.

---

## Post #36 by @Thomas_Clark

Hi Thomas,

A security audit coming across this tidbit would raise more than one red flag\!

Regards\!

\-Thomas Clark

Thomas Beale wrote:

---

## Post #37 by @Thomas_Clark

Hi Nathan,

The real estate codes in most jurisdictions require landowners to post notices
warning of everything from dangerous conditions to prohibitions\. Interpretations
extend well beyond this to impose duties upon the landowners to take active
measures to persons that may be classified as trespassers to protect them
against dangers\.

In short, nailing\-up a sign on a tree or a fence is just step \#1 and it doesn't stop
there\.

Another analogy is a financial services firm that takes your certificates and holds
them for safe keeping\. They may post a sign but they had better do a whole lot
more than that\.

The topic of Patient record security is a tough one\. Some jurisdictions have already
established code\. The real question is does the security in whole comply with the
code and available case law\. If so, will it next month?

Security is an ongoing requirement, responsibility and duty\.  Consult an experience
attorney\.

Regards\!

\-Thomas Clark

Nathan Lea wrote:

---

## Post #38 by @Thomas_Clark

Hi Ken,

Software Agents and Data Mining\. Summaries can be helpful but may, and probably
will be insufficient to satisfy demands for information\. Data Mining can solve many of the
anticipated requests for information but not all\. Software Agents can be developed to
address the majority of requests for information\.

The EHR system must be structured to respond to both type of  interrogations\.

"\.\.\.

periodic report \.\.\. summary of their activities \.\.\.
\.\.\."

could be helpful but possibly not very useful\. A Patient or Provider tool with an audit
trail and a 'grep' tool would probably be better\. Additionally, the user is probably not
interested in getting a summary report of what they did and are likely not interested in
their own security\.

Record locks and loggers could be valuable in part at specific points in the global system\.
This would not, however, provide record\-based security at other points where no
security or protections exists\.

Alternative methods could provide additional security but they would likely involve
translation and mutation, translation of information to mask identities and mutations
to mask record formats\. These would be accompanied by notifications so that the
prior security mechanisms would be able to track record handling\.

This is a deep topic and as always requires constant attention and modifications\.

Regards\!

\-Thomas Clark

Thompson, Ken wrote:

---

## Post #39 by @Thomas_Clark

Hi Tim,

Might want to add:

Computer Security Basics
http://www.oreilly.de/catalog/csb/toc.html

IEEE; Compartmented Mode Workstation: Prototype Highlights
http://csdl.computer.org/comp/trans/ts/1990/06/e0608abs.htm

CMU; Trusted Operating Systems
http://www.sei.cmu.edu/str/descriptions/trusted_body.html

Operating System Security
http://www.cs.ucd.ie/staff/tahar/home/courses/4thyear/chapter4/ppframe.htm

From Security protocols to System Security
http://www.hpl.hp.com/techreports/2003/HPL-2003-147.html

Trusted Computing Platforms
http://www.hpl.hp.com/techreports/2002/HPL-2002-221.html

ASPECT \- a tool for checking protocol security
http://www.hpl.hp.com/techreports/2002/HPL-2002-246.html

Resilient Infrastructure for Network Security
http://www.hpl.hp.com/techreports/2002/HPL-2002-273.html

Security Infrastructure for A Web Service Based Resource Management  System
http://www.hpl.hp.com/techreports/2002/HPL-2002-297.html

Trusted Solaris Developers Guide
http://docs.sun.com/db/doc/805-8060?q=compartmented+mode+workstation

Trusted Network Environment
http://www.tinfosol.com/lab/lab.html

RFC 1825 \- Security Architecture for the Internet Protocol
http://www.faqs.org/rfcs/rfc1825.html

RFC 1827 \- IP Encapsulating Security Payload \(ESP\)
http://www.faqs.org/rfcs/rfc1827.html

Secure Trusted Operating System \(STOS\) Consortium
http://www.stosdarwin.org/

The Blue Book
http://secinf.net/info/rainbow/tg29.txt

UK Security Citations Bibliography
http://chacs.nrl.navy.mil/xtp1/uksecbib.html

Regards\!

\-Thomas Clark

Tim Churches wrote:

---

## Post #40 by @Tim_Churches

> Hi Tim,
>
> Might want to add:
>
> Computer Security Basics
> http://www.oreilly.de/catalog/csb/toc.html
>
> IEEE; Compartmented Mode Workstation: Prototype Highlights
> http://csdl.computer.org/comp/trans/ts/1990/06/e0608abs.htm
>
> CMU; Trusted Operating Systems
> http://www.sei.cmu.edu/str/descriptions/trusted_body.html
>
> Operating System Security
> http://www.cs.ucd.ie/staff/tahar/home/courses/4thyear/chapter4/ppframe.htm
>
>  From Security protocols to System Security
> http://www.hpl.hp.com/techreports/2003/HPL-2003-147.html
>
> Trusted Computing Platforms
> http://www.hpl.hp.com/techreports/2002/HPL-2002-221.html
>
> ASPECT \- a tool for checking protocol security
> http://www.hpl.hp.com/techreports/2002/HPL-2002-246.html
>
> Resilient Infrastructure for Network Security
> http://www.hpl.hp.com/techreports/2002/HPL-2002-273.html
>
> Security Infrastructure for A Web Service Based Resource Management  System
> http://www.hpl.hp.com/techreports/2002/HPL-2002-297.html
>
> Trusted Solaris Developers Guide
> http://docs.sun.com/db/doc/805-8060?q=compartmented+mode+workstation
>
> Trusted Network Environment
> http://www.tinfosol.com/lab/lab.html
>
> RFC 1825 \- Security Architecture for the Internet Protocol
> http://www.faqs.org/rfcs/rfc1825.html
>
> RFC 1827 \- IP Encapsulating Security Payload \(ESP\)
> http://www.faqs.org/rfcs/rfc1827.html
>
> Secure Trusted Operating System \(STOS\) Consortium
> http://www.stosdarwin.org/
>
> The Blue Book
> http://secinf.net/info/rainbow/tg29.txt
>
> UK Security Citations Bibliography
> http://chacs.nrl.navy.mil/xtp1/uksecbib.html

All of those deal with security implementation issues i\.e\. how you
achieve certain objectives\. The BMA security policy sets out what those
objectives ought to be\. Defining the security objectives, which in turn
ought be be informed by specific threat models, needs to be done before
you can consider which security technologies are appropriate\. But yes,
most of those are appropriate\.

Tim c

---

## Post #41 by @b.cohen

I produced a formal definition of most of Anderson's Security 'Principles' in
1996 \(see http://www.soi.city.ac.uk/~bernie/hsp.pdf) and circulated it within
TC251 and ASTMS 31\.1 in an attempt to promote a more formal approach to the
definition of EHR standards in general, and their security in particular\.
This approach was met with almost universal hostility from both supply and
demand communities\.
The problem is not only that formalisation is intellectually difficult but that
it exposes logical inconsistenciies in the composition of what practitioners
and users believe to be in their best interests \(and promote as 'common
sense'\)\.
The exposure of such inconsistencies, and their repair by altering models on
both the supply and demand sides, is the essence of strategic  development\.
Unfortunately, it is also the bane of standardisation\.

Quoting Tim Churches <tchur@optushome\.com\.au>:

---

## Post #42 by @Tim_Churches

> I produced a formal definition of most of Anderson's Security 'Principles' in
> 1996 \(see http://www.soi.city.ac.uk/~bernie/hsp.pdf)

Nice paper\! Haven't read it in detail but on a quick scan I see the
value in the formalisation\.

> and circulated it within
> TC251 and ASTMS 31\.1 in an attempt to promote a more formal approach to the
> definition of EHR standards in general, and their security in particular\.
> This approach was met with almost universal hostility from both supply and
> demand communities\.
> The problem is not only that formalisation is intellectually difficult but that
> it exposes logical inconsistenciies in the composition of what practitioners
> and users believe to be in their best interests \(and promote as 'common
> sense'\)\.

Yup, but these tensions need to be worked out before you invest in
building vastly expensive community\-wide EHRs \- because they will surely
come to light once the thing is in operation, and by then they will be
even more expensive, or impossible, to fix\.

> The exposure of such inconsistencies, and their repair by altering models on
> both the supply and demand sides, is the essence of strategic  development\.
> Unfortunately, it is also the bane of standardisation\.

Apart from altering models, it is also possible to press new
technologies into service\. For example \(wearing my epidemiologist hat
now\), many of the new "privacy\-preserving" data mining techniques, based
on secure multi\-party computation, can now be used to solve many of the
researcher vs individual privacy issues\. The "emergency access" problem
is tricky, but reasonable compromise schemes can be worked out \-
although they may be expensive\. I think that is teh bottom line: no\-one
likes the fact that to do EHRs properly costs a lot more than
maintaining all the redundant copies of the partial paper records which
we currently maintain\. Do the benefits outweigh the costs, and the
benefits can't really be assessed until someone has built and operated a
comprehensive community\-wide EHR for half a decade or more\.

Tim C

---

## Post #43 by @thomas.beale

Gavin Brelstaff wrote:

> 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
>> \- thomas
>
> There must be a downside to do that too \- discouraging access by those
> who have urgent need while being undertrained on the system \- it would
> sure scare me off  \- and that would effectively reduce medic\-medic
> communication rather than promote it\.  Sure security is important
> but don't forget it is always compromise \[Bruce Schneier\]\.

I actually suspect the key to this is: whatever the security measures, we must assume that someday, one day, health data of you or me, or a politician or an actress will be hacked and sent to the Mirror or Sun \(gutter tabloid press in Britain, for US readers\!\), or simply posted on a website\. What will be the acceptable costs of preventative measures against this? When it happens, what will be the acceptable outcome? For the latter: it has to be at least that perpetrators' accesses were logged \(assuming they weren't so smart that they bypassed logging and all other access detection systems\); it has to be that the victim is informed of the information theft; and there have to be legislative measures which are severe enough that stories do not get published in the Mirror or on the web\. Stopping a story in a newspaper is possible in most countries; stopping the posting of information on the web is going to be much harder, but if the identities of the information thieves can be logged, then something can be done\. Perhaps "publishing another's health record" can be made so severe a crime that it just isn't worth it for some would\-be hackers? That leaves us with hackers with personal or particular motives, e\.g\. insurance companies, private investigators, family members, political parties\.\.\.\.again, it seems to me that the greatest deterrent to actually using stolen health information is the sure knowledge that your illegal accesses were logged somehow, not that you were prevented getting in in the first place; then you know that any use you make of the information, once detected will lead to severe action\.

\- thomas beale

---

## Post #44 by @thomas.beale

Ignacio Valdes wrote:

> At the VA, a note is still deletable until it is electronically signed\. You can save it and not sign it and still be able to delete it\. I do not know the algorithm of signature but it involves a pin\-like password that is different from your login\. I bet the VistA crowd would know\.
>

Ignacio,

that means that:
\- anything not signed is a 'draft' and not to be read by anyone, or even made visible by the software
\- things have to be signed to 'promote' them into the shared space

am I right?

\- thomas

---

## Post #45 by @lakewood

Hi Tim,

Security policies are included as are implementation approaches\.

Regards\!

\-Thomas Clark

Tim Churches wrote:

---

## Post #46 by @lakewood

Hi Tim,

One I failed to include is:

RFC 3586 \- IP Security Policy \(IPSP\) Requirements
http://www.faqs.org/rfcs/rfc3586.html

Some of the included links support searches, e\.g\., The CMU link returned over 2200
hits on a search for 'security policy'\. Lots of policy\-related information that is appropriate\.

Regards\!

\-Thomas Clark

Tim Churches wrote:

---

## Post #47 by @Tim_Churches

I think it is very important for all proponents of community\-wide EHRs
to sit down and contemplate a series of worst case scenarios\. Sure, they
can be dismissed as too unlikely to worry about \- but they do need to be
contemplated\.

How about this one: a sysadmin of an EHR facility copies not just the
one medical record, but 100,000 medical records, and passes them
secretly to a "data terrorist" who threatens to publish them on the
Internet via BitTorrent or one of the other distributed, anonymous
peer\-to\-peer networks \- so that rounding up and destroying the
information is nigh on impossible \- in order to extort money from a
government, or just to politically embarrass it \(to death, probably\)\.
The sysadmin bypasses the audit logs, or simply doctors them to cover
his/her tracks, or just skips the country\.

Then consider the slightly more probable scenario that the above happens
not to your community EHR, but to some other community EHR, somewhere
else in the world, with the whole event widely reported in the media\.

Either way, you need to be able to articulate why either a\) this
scenario could never happen or b\) why the costs of protecting against it
are too great, given the low but unknown probability of it occurring and
c\) what measures are justifiable to take to protect against it\.

As a member of the public, I hope and trust that the people responsible
for,  say, a nuclear power plant, have workshopped all kinds of
extremely unlikely but extremely devastating scenarios\. Failure to do so
results in Three Mile Islands and Chernobyls\.

Community\-wide EHRs are the nuclear power plants of the health
informatics world\.

---

## Post #48 by @Tim_Churches

OK, I suppose I was just trying to distinguish things like the BMA
security policy, which are very high\-level, from nitty\-gritty policies
at the operating system or network layer levels\. Both are essential, but
the former are much less rarely articulated than the latter\.

---

## Post #49 by @Vincent_McCauley

I would strongly support the concept that logging
of access \(hand in hand with significant penalties\)
should be the underlying principal to deter
inappropriate access to the EHR\.

This is already used in other high security domains \(police etc\)\.

Regards
Vince

Dr Vincent McCauley MB BS, Ph\.D
CEO McCauley Software Pty Ltd
Vice President Medical Software Industry Association

---

## Post #50 by @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

---


**Canonical:** https://discourse.openehr.org/t/basic-ehr-functionality/14456
**Original content:** https://discourse.openehr.org/t/basic-ehr-functionality/14456