Just for the record....much of the work my company does is around electronic clinical decision support within the the GP work flow with his/her chosen software. This requires read access to data so that the decision support engine can consider the clinical record of the record that is open during a consultation. I can assure you that we are well aware of the bits that some systems make it difficult to access. The best way forward is the establishment of a rich primary health EHR that vendors agreed upon and which was populated as GPs used their native systems. The vendor only has to deal with the interface to the EHR while all of the interoperability would be with the EHR. This is part of what the MSIA Interoperability project could achieve. It preserves the independence of approach of the various GP vendors while saving the national economy millions in interfaces and duplicate projects. Regards John Johnston MSIA and Pen Computer Systems hat this time -----Original Message----- From: [EMAIL PROTECTED] on behalf of Simon James Sent: Fri 22-Jun-07 9:31 PM To: GPCG Talk Cc: Subject: Re: [GPCG_TALK] Encryption & CEHR
> John,
>
> The key issue is about the "secondary use" of data...not prime access
to
> the dat through the vendor application, which, as far as I am aware is
> totally open, as it should be. The issue arises when data needs to be
> extracted for other purposes and some of the vendors have made parts
of
> the data inaccessible for reasons that may be support related, or some
> other reason.
Hi John,
Glad someone made this distinction as I think it's import. No vendor is
preventing access to practice data - all products allow any
user-generated
data to be accessed via the product's native, supported interface.
To further repeat what you've just said, the real question is what other
types of access vendors do/could/should provide to the data in their
products.
I can think of 5 broad options:
1. None.
2. Export to an unencrypted format (all data, vendor determined format).
3. Export to an unencrypted format (agreed minimum standard).
4. Read-only live access via SQL or another interface.
5. Read/Write live access via SQL or another interface.
I think (2) should be the minimum expectation.
(3) would obviously be better in many cases, but folks need to be aware
that
solely relying on a "minimum data set" or CEHR as described in the
adjacent
thread will result in varying levels of data loss during a product
switch
(somewhere between "zero" and "heaps").
No matter how capable the third-party developer, (4) will result in a
burden
for the 1st-party developer. As such, I expect I'll be inviting
ridicule by
suggesting that this level of access SHOULDN'T be mandated.
Of course, if the 1st-party developer is incentivised adequately or can
construct a business case using some other reasoning (e.g. current or
future
customer demand), there is no reason why this sort of access can't
happen.
(5) would obviously be more involving and risky for both the 1st and 3rd
party developer. Is this happening in the market presently?
All the best,
Simon
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
John Johnston
Pen Computer Systems Pty Ltd
Level 6, The Barrington
10-14 Smith Street
Parramatta NSW 2150
Ph: (02) 9635 8955
Fax: (02) 9635 8966
<<winmail.dat>>
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
