Re: [Gnumed-devel] clinicians: coding use case survey - please respond !

[Jim Busser]

On 2011-05-06, at 4:31 AM, Rogerio Luz Coelho wrote:

> Here in Brasil the ICD 10 code is necessary for inumerous interactions with 
> legal and funding issues, the ability to change ICD (or better yet the 
> ability to DELETE a ICD) is a deal breaker in the design of a EMR. It is 
> expected that if a ICD was entered wrongly, there be a explicit way (even if 
> a note on the SOAP entry that made this mistake) to correct this wrong doing, 
> but there must NOT be a way to modify-delete this ICD. 
> 
> What I need you guys to understand is that the EMR journal is the way LEGALY 
> we see EMR in Brasil, so I need it to show somewhere in the journal a ICD 
> field. 


No matter what is the EMR, even when the vendor says "no, the ICD10 cannot be 
modified" the truth is that the vendor can ALWAYS modify the record.

Normally, the vendor can make it impossible for the *doctor* to modify the 
record because the doctor does not have special software or the doctor does not 
have the password to the database. With gm-dbo it is always possible to modify 
a record selectively, so there are only two ways that data integrity 
(non-falsification) can be argued:

1. the table design in GNUmed takes advantage that you cannot remove a clinical 
record unless you would be able to alter the master postgres program itself. 
This is because the gnumed tables have been defined to always keep a copy of 
clinical records in the audit table. So when you make a correction to the 
original, the original gets copied into the audit copy of the table, and the 
modified record can always be checked of some actual earlier version existed.

2. you can therefore tell the Brazilian police that this software GNUmed does 
not allow the original to be gotten rid of. It can always be checked.

(It is true, the same way with the vendor, that someone with the master 
password could go through the back with the password, however Karsten can maybe 
tell us whether, even with the password, the table structure does not allow the 
record to be deleted. You would then have to
- backup the data
- restore it into a data structure that has a table that *does* allow deletion
- delete the record and pack/vacuum the database
- backup the data
- restore into a normal GNUmed data structure

(and the only real way to show that the record was not later changed, would be 
to have backups burned to some date-stamped media (CD) from a time shortly 
after the original event, this is something that the gnotary project was 
developed to help with [the signing])

-- Jim