DV_WORLD_TIME and timezone

Technical (archive)
21

The information a healthcare provider submits to the record is what he/she
sees on the screen. This committed information has to be signed. It is not
sufficient that the author is recorded but for legal proof it is necessaryb
that he/she signes the text with his/her private key.

This is the position we (at TNO-PG) take after having studied the legal
literature (1500 pages of texts from EU Directives, Dutch laws, FDA
documents and ethics documents)

So an EHR is a series of signed, authored messages that can be used in
court. Without the fulfillment of the requirements, the EHR is nothing but
information written in the sand before a wave of the sea washes it away.

What an application does with the information on a screen and in its
database is much less relevant from a legal perspective.
What is signed is relevant.

-- <work> --
Gerard Freriks
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800

22

So an EHR is a series of signed, authored messages that can be used in
court. Without the fulfillment of the requirements, the EHR is nothing but
information written in the sand before a wave of the sea washes it away.

This is, however, the way medicine worked for thousands of
years, and reasonably well, obviously. It is trust that
defines the doctor-patient relationship, not proof.

What an application does with the information on a screen and in its
database is much less relevant from a legal perspective.
What is signed is relevant.

Are you suggesting applications should store digitally signed
screenshots ?

Regards,

Karsten Hilbert, MD
GnuMed i18n coordinator

23

Karsten,

It is the opinion of the Applied Technical Research Institute (TNO-PG), I
work for, after having studied European law and Dutch law that possibly the
only legally valid proof is a signed 'picture' of what was shown on the
screen. E.g. A prescription, an order, a referral.
Next to the information formally submitted into the EHR their will be a
whole gamut of other secondary information: private notes, not evaluated
results and opinions.
This 'picture' could be generated from information in a database.
Why a 'picture'? Not only the stored information is information; the way it
is presented is information as well. How can one be sure that what is stored
in the database is what has been presented visibly on the screen? (black
characters on a black background, information hidden behind on other window,
etc)

The question open for debate is: what is this 'picture'?
Is it a PDF? Is it Microsoft Word? Is it data in a XML-Document plus the
style sheet used? Is it ...?
What a signature is and what a signed document is, is more clear in Europe.

All this is part of the TNO-PG Essential Requirements for the EHR.
Only systems that comply will fulfil all basic requirements as expressed by
European Directives and Dutch law (that is derived from these Directives)

Gerard

Helas. Copies of these Essential Requirements are not available for
publication, yet. It is a difficult complex document that is being revised
and improved all the time. Until it has been transformed into a usable and
easy readable format we only have copies for internal use and for our
customers that want to have their products approved.
It is our goal to present them to the ISO/TC215 community in due time for
consideration.

So an EHR is a series of signed, authored messages that can be used in
court. Without the fulfillment of the requirements, the EHR is nothing but
information written in the sand before a wave of the sea washes it away.

This is, however, the way medicine worked for thousands of
years, and reasonably well, obviously. It is trust that
defines the doctor-patient relationship, not proof.

What an application does with the information on a screen and in its
database is much less relevant from a legal perspective.
What is signed is relevant.

Are you suggesting applications should store digitally signed
screenshots ?

Regards,

Karsten Hilbert, MD
GnuMed i18n coordinator

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

+31 252 544896
+31 654 792800

24

Gerard,

Hopefully these TNO "Essential EHR Requirements" will be compatible with the ISO
13808 "Requirements for an EHR Reference Architecture". The draft 18308
Technical Specification will go for ballot in November so it would be very
important that we have the TNO requirements congruent with 18308 before then. I
latest draft of 18308 was circulated to TC 215 WG1 on Friday and should be
available on the WG1 website within a few days but I will send you a copy
directly via separate email.

Peter Schloeffel
ISO 18308 EHR Requirements project leader

25

Karsten,
And others,

What is your idea?

- Can you agree with me that it is possible to proof that information was in
a database at a certain time in most systems?
But most systems are unable to proof what was seen on a screen and signed
before being committed to the record or sent to an other entity?
- What are the consequences of the extreme but defendable position of
TNO-PG?

Gerard

Gerard,

that possibly the
only legally valid proof is a signed 'picture' of what was shown on the
screen. E.g. A prescription, an order, a referral.

Well, I heard that point of view before. I just wanted to
verify that this is actually what the organisation you are
associated with is suggesting.

Karsten

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

+31 252 544896
+31 654 792800

26

Karsten,
And others,

What is your idea?

- Can you agree with me that it is possible to proof that information was in
a database at a certain time in most systems?

Certainly. That's what Horst's gnotary is about.
http://www.gnumed.net/gnotary/

But most systems are unable to proof what was seen on a screen and signed
before being committed to the record or sent to an other entity?
- What are the consequences of the extreme but defendable position of
TNO-PG?

Gerard

The logs would show that all the relevant patient data had been
downloaded to the client. I think it is asking too much of the process
to also verify that the doctor saw it on the screen, was in a fit state
to process the data and come to a logical conclusion.

In my experience only the clinical note written on the day can concisely
log what data was processed to come to the clinical management plan.
Having pointers to the relevant data is helpful (e.g. see last entry 5
July 2002; Dr Jones' letter, 26 February 2000, histopathology skin 14
September 2002). I once thought a drag and drop hyperlink might be the
best way to do this but text entry is as efficient; just not as cool.

Is this what you are trying to achieve?

David

27

Karsten,
And others,

What is your idea?

- Can you agree with me that it is possible to proof that information was in
a database at a certain time in most systems?

Certainly. That's what Horst's gnotary is about.
http://www.gnumed.net/gnotary/
>>>

Trusted functions like these are necessary in general for a better use of
the Internet.

But most systems are unable to proof what was seen on a screen and signed
before being committed to the record or sent to an other entity?
- What are the consequences of the extreme but defendable position of
TNO-PG?

Gerard

The logs would show that all the relevant patient data had been
downloaded to the client. I think it is asking too much of the process
to also verify that the doctor saw it on the screen, was in a fit state
to process the data and come to a logical conclusion.

I'm not talking of the state of the healthcare provider.
I'm talking about what he saw and thought to sign.

He has no way to see what is in the database down deep in the system.
The only thing is is able to see and vouch for is what he sees on a screen,
piece of paper, etc.

In my experience only the clinical note written on the day can concisely
log what data was processed to come to the clinical management plan.
Having pointers to the relevant data is helpful (e.g. see last entry 5
July 2002; Dr Jones' letter, 26 February 2000, histopathology skin 14
September 2002). I once thought a drag and drop hyperlink might be the
best way to do this but text entry is as efficient; just not as cool.

Is this what you are trying to achieve?

No: Vide supra.

Text as pointers or URL's it is all fine with me.
But he signes what he sees.

David

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

+31 252 544896
+31 654 792800

28

I think I've got it, Gerard. What are you signing is that a certain
dataset was available to you on a particular day for a particular
patient. You are not signing that you have understood or even looked at
it but that it was available.

Wouldn't a hash of the data be both smaller and a more reliable
attestation of the data available?

David

29

NO.
You didn't get it.
So I try again.

I'm making the subtle difference between information in a database and
information presented on a screen.
And signing what is in a database and signing what is on the screen.

By the way. Signing means: "I, the signer, take full responsibility for what
was signed"

Making a hash and signing the hash indicates that a system retrieved
information made a hash out of it and signed it. There is no human
involvement. The human triggered the process, but was no part of it. He
doesn't know what information went into the hash before he signed it. He was
unable to inspect what went into the hash. The signature of the hash means:
this is my hash. It doesn't mean: This is the information I've seen and take
responsibility for by signing.

Making a hash of a screen dump indicates: This is the information as I saw
it on a screen and take responsibility for it by signing.

Information in a database is one thing.
Information on a screen is almost the same but isn't all the times.
Writing black letters on a black background. The information is there but
the healthcare provider can't see it. Information written in a window that
is overlapped constantly by an other window. Etc.

Signing a hash directly from a database is (to me) signing a clean sheet of
paper. And hoping that the system performs well. It won't hold in court or
creates serious problems, al least.

The legal basis for our position is the European Directive
(1999/93/EC,OJL013, 19/01/2000 p.0012-0020)
This directives indicates under which conditions electronic signatures are
equal to paper documents and signatures in ink.
"Advanced electronic signatures which are based on qualified e-certificates
and which are created by a secure-signature-creation device shall:
1 Satisfy the legal requirements of a signature in relation to data in
electronic form in the same manner as hand-written signature satisfies those
requirements in relation to paper-based data; and
2 Be admissible as evidence in legal proceedings"

The above we translate to: a person signs (takes responsibility for) what he
sees on paper (on a screen) and not what is deep down in a complex system
else where outside of his control and not visible.

We are aware that our position will cause serious problems for all present
day systems. They produce signed information perhaps not admissable in
court.
Therefore we are of the opinion that these legacy systems will have to
change in order to get approval (TNO QM-ICT®) of TNO-TRUST® that they
comply with Dutch and European laws and Directives.

With regards

Gerard

Text as pointers or URL's it is all fine with me.
But he signes what he sees.

I think I've got it, Gerard. What are you signing is that a certain
dataset was available to you on a particular day for a particular
patient. You are not signing that you have understood or even looked at
it but that it was available.

Wouldn't a hash of the data be both smaller and a more reliable
attestation of the data available?

David

-- <work> --
Gerard Freriks
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800

30

Melvin Reynolds wrote:

Once again I agree (mostly!) - and certainly did not want to imply different levels of medico-legal requirement within any particular jurisdiction.
The integrated healthcare record is very usefully regarded as a single repository which contains, either directly or by reference, all the data that relates to the process of actually clinical care (not the facilitating aspects of the healthcare infrastructure*) - but upon which there are appropriate "views" according to the use context. However, the difficulty I have is with the "throwaway" statements (perhaps just intended as 'shorthand' but if so not sufficiently specific to be helpful at this stage of development and email communication) which if taken literally will result in flawed design:

"generally not come from messages - there is no other place for this data to come from but the GP application"
"generally" and "there is no other place" is the problem here, "often" would be more accurate because, as an example, the giving of vaccinations to children in school is not likely to be noted through the multiple GP systems related to the children - but through a Community system (of whatever sort) - and then "messaged" back to the EHR as seen by the GP - so there's clearly an "other place". Similarly Social history information may well arrive from the Social services system ...

ah well - I guess I was talking in the idea future world of EHRs being everywhere, not today. In the future of a shared care, community-based EHR I would expect both types of carers you mention to be entering the data into the EHR, not in some other system... maybe I am wrong here.

Anyway, I accept what you say - let's just say that now and in the future, in many instances, the data for the transaction types i mention will come from GPs and other carers accessing and modifying the EHR.

"instead come through the application / EHR kernel API,"
fine, so long as this means:
"through *an* application *and/or* the kernel API"

yes - whatever application being used.

"and create EHR data on the fly."
fine, so long as this means, for example:
"receive (and store) message data,
acknowledge message data if appropriate according to implementation requirements,
assign message data to EHR as agreed by all users of EHR *or*
reject message data for EHR as agreed by all users of EHR (but in this case log receipt of message data even if not available for 'default display')."

well I wasn't talking about messages here - I was talking about communication through a network-visible API, which is what you get with .net, SOAP, Corba etc.

This should have read "Sorry if I have missed *something*". I guess from mails on another thread that these issues will get another airing in Baltimore. What it underlines for me is the need for precision in our use of terms - and I plead guilt to imprecision when doing/saying things in haste, and sometimes at other times too :).

me too;-)

- thomas beale

31

If health and social care continue to converge as is happening in the UK
then the protocol of Soc Services is to also record things that may have
been considered appropriate in principle but which the individual
professional based on knowledge of the individual client circumstances
chose explicitly NOT to do. This and the current discussion about
'signing' could have major ramifications on size and performance of
records management systems. Any comments?
Jean Roberts

st <dguest@zeeclor.mine.nu> writes

32

1) How do I know that the passphrase I typed in to be used for
  the secret key is used to sign what I see on screen and
  nothing else ?

2) How does the court know that a signed screenshot was
   actually shown on screen and not just fabricated and never
   shown ? (It is my responsibility to _inspect_ what is being
   shown but I cannot prove that signed "screenshots" were
   actually displayed (on current-day systems).

This isn't about 100% proof, this is about level of trust,
feasability, deniability and due process. Even with signing
screenshots.

Or did I miss something ?

Since it is my responsiblity to carefully inspect the
on-screen information I could just as well extend that view to
that it is my responsibility to use a system that I can trust
to show me what is actually in the database. Thusly I could
just as well sign database content. Gerard himself remarked
that we cannot sign that anyone actually reviewed any
information, only that it was made available. The latter can
be at the level of a screenshot - or at the level of database
content. After all it is my responsibility to inform myself
no matter where I get the information from. Say, I am using an
SQL shell and sign screenshots of my queries. Does this mean I
am not liable for the anaphylactic reaction just because I
didn't do the query for the known penicillin allergy ?!?
Obviously not, although I understand your position to be: "It
hasn't been shown to me hence I am not to blame." What other
purpose might a signed screenshot server ? To shift blame to
the EHR software manufacturer ?

Lastly, one simple question. How does TNO propose to handle
the audit trail of signed screenshots simply in terms of
storage requirements ?

Making a hash of a screen dump indicates: This is the information as I saw
it on a screen and take responsibility for it by signing.

Nah, I doubt you really believe in the coherency of this
statement. A screendump merely shows what a screen _may_ have
looked like.

Karsten Hilbert

33

1) How do I know that the passphrase I typed in to be used for
the secret key is used to sign what I see on screen and
nothing else ?

Because a special secure device does all the encrypting.
After having inserted the Health professional Card

2) How does the court know that a signed screenshot was
actually shown on screen and not just fabricated and never
shown ? (It is my responsibility to _inspect_ what is being
shown but I cannot prove that signed "screenshots" were
actually displayed (on current-day systems).

Because the secure device is able to place the information on the screen.

Having a screenshot provides a richer picture than a set of bits and bytes
down deep in the database.

This isn't about 100% proof, this is about level of trust,
feasability, deniability and due process. Even with signing
screenshots.
>>>

True.
I'll have more confidence in a message displayed on a screen than bits and
bytes in a distributed database in an Health Information Infrastructure

Or did I miss something ?

Since it is my responsiblity to carefully inspect the
on-screen information I could just as well extend that view to
that it is my responsibility to use a system that I can trust
to show me what is actually in the database. Thusly I could
just as well sign database content. Gerard himself remarked
that we cannot sign that anyone actually reviewed any
information, only that it was made available. The latter can
be at the level of a screenshot - or at the level of database
content. After all it is my responsibility to inform myself
no matter where I get the information from. Say, I am using an
SQL shell and sign screenshots of my queries. Does this mean I
am not liable for the anaphylactic reaction just because I
didn't do the query for the known penicillin allergy ?!?
Obviously not, although I understand your position to be: "It
hasn't been shown to me hence I am not to blame." What other
purpose might a signed screenshot server ? To shift blame to
the EHR software manufacturer ?

The whole thing has to do with liability and legal proof.

If next to the information in a database the style sheet used to display is
stored, it is possibly good enough for legal proofs.

Lastly, one simple question. How does TNO propose to handle
the audit trail of signed screenshots simply in terms of
storage requirements ?
>>>>

This is a simple problem.
Now every year one hospital needs 1 kilometre of shelf space.

Have you ever compressed XML documents?
Have you ever looked at diskspace and prices?

Making a hash of a screen dump indicates: This is the information as I saw
it on a screen and take responsibility for it by signing.

Nah, I doubt you really believe in the coherency of this
statement. A screendump merely shows what a screen _may_ have
looked like.
>>>>

I think it is fully coherent.

Yes. But systems that have been certified will have a perfect screendump.
This is something that can be tested easily.

To proof that in a distributed environment all informationsystems worked
100% is much more difficult?
Right? Or wrong?

Gerard

Karsten Hilbert

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

+31 252 544896
+31 654 792800

34

Lastly, one simple question. How does TNO propose to handle
the audit trail of signed screenshots simply in terms of
storage requirements ?
>>>>

This is a simple problem.
Now every year one hospital needs 1 kilometre of shelf space.

Well, the treeware equivalent of what we are talking about
here is: Any time I look at the paper chart I'll make a copy
of the page I look at, date and sign it and add it to the
ever-growing chart, e.g. any time I invoke a screen I should
need to sign what I saw, right ?

Have you ever compressed XML documents?

I thought we were talking screenshots here ? Binary data ?
Already compressed ?

Have you ever looked at diskspace and prices?

Yes, and I have looked at my salary. I am talking GP level
here.

Making a hash of a screen dump indicates: This is the information as I saw
it on a screen and take responsibility for it by signing.

Nah, I doubt you really believe in the coherency of this
statement. A screendump merely shows what a screen _may_ have
looked like.

I think it is fully coherent.

Are you telling me you mean "a signed hash of a screendump
proves that I saw the screendump" ?!?

To proof that in a distributed environment all informationsystems worked
100% is much more difficult?
Right? Or wrong?

Right.

Karsten Hilbert

35

Karsten

I do not go with the screen shot idea - the issue here is the accountability
and if the information is stored in an explicit manner and the rendition can
be stored (XSLT or application) then it will be clear what the person saw -
the problem with screenshots is the plethora of views that might be used in
a single consultation. And can we be sure that the screen was paged down?
And what was the resolution of the screen - and the visual acuity of the
practitioner - and what parts of the screen did their eyes stray to...

Our research in GEHR had a clear outcome - clinicians did not want this sort
of EHR and it served no useful purpose.

Cheers, Sam

36

Hi All,

I am rather late to this thread, but it seems to me that there are a
number of alternatives here:

a) Do nothing
b) Have a reasonably secure system, but no signing
c) Sign the content in the database
d) Sign what was on the screen and store the signed image

You can spend all day arguing about which one to adopt, but the reaility
is the is no one true answer to this as it is all horses for courses. In
an evnrionment where everyone is trustworthy or the conseuqneces of
violation are low then (a) is an option. In some environments where the
system administrators and developers can be trusted then option (b) is
enough. In other environments where no one can be trusted then even (d)
might not be enough.

What you need to do is tailor your choice of what you sign (or even if you
sign anything) based on the potential risks and the consequences if
that risk occurs and wether you are willing to spend the money to prevent
it from occurring.

cheers, Andrew

37

Andrew Goodchild wrote:

Hi All,

I am rather late to this thread, but it seems to me that there are a
number of alternatives here:

a) Do nothing
b) Have a reasonably secure system, but no signing
c) Sign the content in the database
d) Sign what was on the screen and store the signed image

You can spend all day arguing about which one to adopt, but the reaility
is the is no one true answer to this as it is all horses for courses. In
an evnrionment where everyone is trustworthy or the conseuqneces of
violation are low then (a) is an option. In some environments where the
system administrators and developers can be trusted then option (b) is
enough. In other environments where no one can be trusted then even (d)
might not be enough.

What you need to do is tailor your choice of what you sign (or even if you
sign anything) based on the potential risks and the consequences if
that risk occurs and wether you are willing to spend the money to prevent
it from occurring.

I think this is a good overall comment. To which I'll add that what needs to be shown to have been understood in court are simple clinical or other facts, in the form of propositions, not screen bit patterns. In court, it will nee to be shown that that clinician understood fact A, B and C before attesting the addition to the EHR. Screen shots are not the way to do this. I suggest that a "standardised XML rendition" of the EHR entries in question are the way to go.

Also, we should be careful to differentiate between "attestation" - the act of the clinician agreeing that he/she has in fact seen and understood what is on the screen be fore committing it to the EHR, and "signing" which is an attestation that some lump of content was created by a certain person, and not someone else. I don't think "signing" guarantees anything about comprehension, just that a particular stream of bytes emanated from a source which is positively identified as "Dr so-and-so".

- thomas beale

38

Slowly we are making progress.
I agree that there are several reasons to sign and possibly we need ways to
indicate this.
I agree that there are several contexts. The lonely healthcare provider on
his IT island, the one that exchanges information with a few other
colleagues, the healthcare providers that are part of a complex network for
the exchange of messages, the ones that are part of an higly integrated
system of systems. The more complex the more detail has to be stored
explicitly.
I agree that 'screenshots', 'pictures' can be engineered in several ways.
The most likely candidate is XML-document and XML-stylesheet. But perhaps
there are others.

Gerard

Ps: sorry for having an extemist view.

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

+31 252 544896
+31 654 792800

39

Sam,

There is a difference between looking at various screens during a
consultation and the signing of part of the information that needs to be
signed. E.g. Orders, communications with others.

It is clearly not necessary to make movies of what was presented on the
screen during the consultation.

Gerard

Karsten

I do not go with the screen shot idea - the issue here is the accountability
and if the information is stored in an explicit manner and the rendition can
be stored (XSLT or application) then it will be clear what the person saw -
the problem with screenshots is the plethora of views that might be used in
a single consultation. And can we be sure that the screen was paged down?
And what was the resolution of the screen - and the visual acuity of the
practitioner - and what parts of the screen did their eyes stray to...

Our research in GEHR had a clear outcome - clinicians did not want this sort
of EHR and it served no useful purpose.

Cheers, Sam
____________________________________________
Dr Sam Heard
The Good Electronic Health Record
Ocean Informatics, openEHR
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard@bigpond.com
www.gehr.org
www.openEHR.org
__________________________________________

From: Karsten Hilbert [mailto:Karsten.Hilbert@gmx.net]
Sent: Saturday, 14 September 2002 5:49 PM
To: Gerard Freriks
Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard;
Openehr-Technical
Subject: Re: Archetype ontology

So an EHR is a series of signed, authored messages that can be used in
court. Without the fulfillment of the requirements, the EHR is

nothing but

information written in the sand before a wave of the sea washes it away.

This is, however, the way medicine worked for thousands of
years, and reasonably well, obviously. It is trust that
defines the doctor-patient relationship, not proof.

What an application does with the information on a screen and in its
database is much less relevant from a legal perspective.
What is signed is relevant.

Are you suggesting applications should store digitally signed
screenshots ?

Regards,

Karsten Hilbert, MD
GnuMed i18n coordinator
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

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

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

+31 252 544896
+31 654 792800

40

Hello all

This is a useful discussion - I am much more with Karsten than Gerard on
this - all the 'proofs' in the world amount to nothing in the digital
world - as things can be altered at any point anyway. The GnuMed trust
solution does get someway towards this.

The technical solutions offered at the moment really do not match the
reality and until we have working EHR systems and integration, these sorts
of debate need to stay in the background. They do not really impinge greatly
on the EHR requirements.

But keep it up!

Sam Heard