Basic EHR functionality

Technical (archive)
1

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

2

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,

3

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!

4

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.

5

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

6

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

7

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

8

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

9

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

10

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

11

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:

12

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.

13

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

14

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.

15

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

16

> 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.

17

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...:wink:

Best Regards,

Ken

18

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:

19

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:

20

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...:wink:

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

Tim C