Hello Ian, I'll recheck to make sure about the status of the constraint I mentioned, and this is an argument I'd love to be wrong about. IMHO Google and MS may be on the edge of falling into the well known trap for storing healthcare data: "lets build our own system". Especially Google's other work like Google apps for cloud computing gives the impression that they are focused on scaling in the first place: no relational storage etc.. I'd love to see them using a richer layer for data input/output, and the following would be my first argument if I was given a chance to talk to them: In case MS and Google omit the programmatic query aspects of the data they'll be holding, they'll simply push the cost of developing useful queries to users of that data. The users here must be perceived as (largely) GP software vendors, and secondary care solution providers, a.k.a hospital information system vendors. I do not consider the patient as the end user in terms of an information system, and this may sound a little bit strange. However, if you think about it, healthcare is an agent based service, where the resources are consumed by an agent (the doctor) on behalf of the patient. So, even if the patient can lift the burden of privacy management in the legal context from the shoulders of healthcare institutions, there is not much for him/her to do other than allowing access to his/her information for a particular user (another gp, HIS etc.) So without a rich query layer in their systems, Google and MS will realize a system where a patient's use of the system results in print outs, or a doctor using a web browser to access the data. Both scenarios will lead to doctor's complaints: they'll want things in a particular order, past medication in a particular format, etc... They'll want this data in their usual system.For UK, they should be able to see this data based on CUI components for example. (my opinion again) Again, without a rich query layer, the task of giving the doctors what they want is a cost item for the GP or HIS solution vendor. They'll have to get a chunk of data with a blunt method, and perform operations on it since they do not have a nice query mechanism in the first place. This is programmer salary! To have a larger market adoption and better integration with other vendors, these solutions by Google and MS will have to focus on strong interfacing features, and even though they do not use a standard backend, they'd better think about mechanisms better than CCR. Of course these are all my ideas, and all feedback/discussion is more than welcommed.
Cheers Seref On Sun, Sep 14, 2008 at 7:21 PM, Ian McNicoll < Ian.McNicoll at oceaninformatics.com> wrote: > Hi Seref, > > You said: > "What about the legal consequences? For example: I can remember being > told my multiple sources that it is not legal to store healthcare data > of a UK citizen outside of UK." > > I am not aware of any law restricting the storage of healthcare data > outwith the UK. I suspect there may be some confusion around the UK > Data Protection legislation which prohibits 'personal' data being held > about a subject, without the organisation holding the data being > registered. I doubt if the same could be held to apply to a patient > wishing to store their own data in an overseas hosted environment. > > I can understand that many healthcare providers and national > organisations are attracted by the Google/HealthVault model as by > putting the patient in charge of the visibility of a potentially > widely accessible health record, it relieves some of the difficult > privacy and confidentiality issues. It is also fairly easy for the > various system vendors to populate the very limited set of CCR > clinical data classes via well-documented APIs. > > The only problem I see is that this is being touted as a panacea for > all the well-known difficulties of implementing the EHR and ignores > the the necessity for a useful EHR to be 'maintained' so that it > reflects current knowledge, rather than just being a historical list > of observations and evaluations which may conflict and will certainly > not allow accurate workflow and scheduling support. > > Ian > > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at mcmi.co.uk > > Clinical Analyst - Ocean Informatics ian.mcnicoll at oceaninformatics.com > > Consultant - IRIS GP Accounts ian at gpacc.co.uk > > Member of BCS Primary Health Care Specialist Group ? www.phcsg.org > > > > 2008/9/14 Seref Arikan <serefarikan at kurumsalteknoloji.com>: > > Hi Berth, > > Please let me add my set of questions to yours, for I have not been able > to > > figure out the overall scheme of the discussed setup. Maybe its my fault, > > and I apologize in advance if I've missed the answers in the discussion > or > > on the web. > > What is the extend of Google's or Microsoft's offer to these hospitals? > Both > > MS and Google give me the impression that their offer is about personal > > healthcare records. The extend of functionality they will offer is > > important, because it can either be a complementary functionality that > will > > allow the patient to use his/her initiative to transfer data to allowed > > parties, like the next GP or hospital, or it can be a complete > alternative > > to whole idea of national healthcare information systems, which is > unlikely > > in my opinion. > > What about the legal consequences? For example: I can remember being told > my > > multiple sources that it is not legal to store healthcare data of a UK > > citizen outside of UK. Will the mentioned solution be located in USA? Are > > there similar legal constraints for discussed setup? > > > > Cheers > > Seref > > > > On Sun, Sep 14, 2008 at 4:02 PM, Bert Verhees <bert.verhees at rosa.nl> > wrote: > >> > >> All information below is published in the Dutch press, specially, the > >> always good informed website on health ICT: Qure (http://www.qure.nl). > >> Normally, I don't repeat press-messages on this or any other > mailinglist, > >> but this looks very important to many of us, who are working on a > >> OpenEhr-implementation. I hope OpenEhr related press will occur so > >> frequently that we don't need to know. Anyhow, a business-succes for > Openehr > >> related software is in my opinion a success for all of us. It means that > >> OpenEhr will be something management have to think/talk about > >> > >> The latest update on this thread is, that the MCA (medical centre > alkmaar) > >> will run, as first hospital, software based on the European EPD standard > >> (CEN 13606). This is also said by Hans Kedzierski (the person who > announced > >> that 10 hospitals are going to use the software from Google or > Microsoft), > >> member of the board of the MCA, and is published last friday > >> This latest announcement will be explained on a public meeting in > october. > >> Interesting are the companies who are working together on this: HP, de > >> 13-Groep, ERC, Unusual Visions, Carelliance/Medical Insight, > Technicolor, > >> ASP4All, Eurofiber en Priority Telecom. Special interesting for us is > ERC > >> (http://www.e-recordcompany.eu/), reseller of Ocean Software. ERC seems > a > >> brand new company, its website is not (yet) fully functional (need some > >> polishing). > >> > >> Does this mean that the MCA will be using the two systems simultaneous? > >> Does this mean that there will be data-migration software between > OpenEhr > >> and "Google or Microsoft" (always mentioned together by Kedzierski)? > >> And if, how does this reflect on us? Will Google create an > >> OpenEHR-data-exchange API? > >> > >> More on this you can read in on the news-site Qure: > >> > >> > http://www.qure.nl/modules.php?op=modload&name=News&file=article&sid=index.php?name=News&file=article&sid=3179&mode=thread&order=0&thold=0 > >> (it is not a free news-service) > >> > >> > >> > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080914/4056fe65/attachment.html>
