Correct guidance on signing in Common IM

Description

See .

Activity

Show:
Heath Frankel
March 8, 2016, 1:25 PM

I don't think there is anything wrong with the current text and removing it is likely to lead to incorrect use.

Thomas Beale
March 11, 2016, 9:46 PM

When we designed this, the problem we were trying to solve was how a user could sign content that was what the server committed. I think I had in mind some (too complex) scheme where the server would cause a signing request to the user (process) after it had committed the content. This probably is not feasible, and a more normal model would be for the user-created content to be signed as part of creation, and the content + the sig passed to the EHR service commit() call.

I have not really thought about 'server signing', although I can see it might be useful. But the main problems we are trying to solve here are medico-legal non-repudiation of the content and also integrity check on the data (i.e. detection of hacking, data corruption).

I believe if we reword the text in the way I have said it correctly describes user signing, whereas the current text is actually wrong. So I think we need the change.

BTW Heath referred to attestation but this is a different thing; it is a proof that a certain user (probably not the author) 'saw' and OK'd the content, i.e. took medico-legal responsibility for it. Signing is proof that the authoring user really did create the content (or at least someone who stole her health professional card or laptop .

Heath Frankel
March 12, 2016, 3:50 AM

OK, I probably misunderstood your original intent for this, I never considered it as user signatures.

However, you say "But the main problems we are trying to solve here are medico-legal non-repudiation of the content and also integrity check on the data (i.e. detection of hacking, data corruption)". I am not sure why a user has to be involved in this. In most systems I have been involved in within Australia, when we want medico-legal non-repudiation of the content and also integrity check on the data it is done at a system or organisational level.

Then you talk about attestation being different, although in principle I agree the purpose is different but if you have the user doing it on commit then I don't see why you need them to do it again at the attestation level.

The reality is that user signing is difficult to support (perhaps better in recent years but still painful), so we only do it when we really need too such as attestation scenarios. For non-repudiation and also integrity checking we don't need these overheads, organisation/system level signing is sufficient is is done in communications.

Thomas Beale
March 12, 2016, 4:10 PM

Well, the analysis of both signing and attestation were done in about 2002, so we undoubtedly need a new analysis today. But in Europe, individual signing is quite normal. So I'd say we need different models to support all countries. But attestation really is a different thing - it isn't needed that often, and it's often not the author of the content who does it.

So I suggest that for now we adjust the spec to be minimally 'correct', even if deficient and do a proper set of changes in 1.1. Or else we don't touch the spec now, and just go for 1.1. Either is fine by me.

Boštjan Lah
March 12, 2016, 4:33 PM

I vote to adjust to be minimally correct now and do the proper change for 1.1.

Reporter

Thomas Beale

Raised By

Thomas Beale

Components

Affects versions

Configure