This popped up a little while ago.
'Grave concerns' over new GP dataset
16 January 2013 Rebecca Todd
GPs and privacy experts have “grave concerns” about an extensive new dataset to be extracted from GP practices.
The NHS Commissioning Board published its first planning guidance for the NHS - ‘Everyone Counts: Planning for patients 2013-2014’ – last month.
It says a new GP dataset will be “requested” from GP practices for submission to the Health and Social Care Information Centre, described as a “statutory safe haven.”
“The patient identifiable components will not be released outside the safe haven except as permitted by the Data Protection Act,” it adds.
Practices will be requested to provide data on patient demographics, events, referrals, diagnosis, health status and exceptions.
This includes information on patients’ alcohol consumption and whether a GP has given exercise or dietary advice or completed a mental health review.
GP practices are expected to provide the data using the General Practice Extraction Service.
“The data will flow securely, via GPES, to the HSCIC, the statutory safe haven, which will store the data and link it only where approved and necessary, ensuring that patient confidentiality is protected,” the guidance explains.
Potential uses for this data are not detailed, however the NHS CB’s national director of patients and information, Tim Kelsey told a conference in December that a “standardised routine set of data” would be required from all GPs to help assess their quality.
Dr Paul Cundy, joint chairman of the BMA and RCGP's joint IT committee, said the committee had no prior warning of the new data set before it was published in December.
The committee has met with Kelsey to discuss the proposals and invited him to its next meeting for “further discussions.”
“It’s an interesting proposal, but as with many simple ideas it has got some complex issues behind it,” Dr Cundy said.
“If you compare this data set with the Summary Care Record data set and the time it took to agree the SCR it’s obvious that we will need to be having quite prolonged discussions.”
“I know that there will be a significant number of patients who will not want their identifiable data to leave the practice.”
“The issue for me is what should a GP do if a patient explicitly dissents from this sort of data set going on to the IC?”
Lots more concerns here:
Frankly this is just horrifying and is so open to abuse it is really worrying. Anyone who thinks the Government’s lust for data is any less than policy makers in the UK is delusional and there is one clear lesson here - do not give any sensitive information to Government agencies that you want to remain in charge of and retain control over.
I am sure the ‘nanny state’ wants to know how much we drink and smoke and eat - but my view is that it is our business and not theirs.
Be both alert and alarmed and keep your sensitive information to yourself. The only saving grace is that it will be a good while before the NEHRS contains enough data to be statistically useful and maybe annoyance on the public’s part and much better governance might just save us!
David.
52 comments:
On the note of inappropriate access to personal health records, I have accessed my PCEHR and run the audit log. I was shocked to see that my record had been accessed by the role of "external provider" (no further details given about who this is). The type of access included reading and updating of documents, reading of my emergency contact details and even updating of my access controls. Most of these accesses occurred in July/August 2012. I am guessing that this was a time when the system was not very stable and was being fiddled with by the system operator. But is is very disconcerting to see that some sort of "external provider" has been messing with my record. If it is the system operator it should clearly show that - not pretend to be a provider. Has anyone else tried this? And is there an explanation? I don't feel comfortable ringing the help desk - I don't want anyone else messing around in my record. Also, I did not get any emails or notifications that an external provider had accessed my record, even thought I set this up in the record. Not happy.
I am in agreement with all the concerned comments however we may be "protected" for a while becasue current systems -particulallry in primary care - and currently proposed systems (NEHRS/PCEHR)have data which is so inaccesible and poorly accurate it is "relatively safe".
@Anonymous: that sounds a significant complaint, unfortunately the PCEHR support team cannot act on any information from a blog site.
I would strongly suggest that you contact the support desk so as to get a resolution on that incident.
As a general rule, the expectation would be that:
1. If it says external provider, that would generally mean a clinician. There were very few clinicians on the system in July/August, so there's a relatively short list of people that could be
2. Access by the operator itself would normally show as being by the operator. The operator in general only accesses a record in response to a request from a patient themselves, there are some other provisions in the legislation but they are very rarely exercised.
In short, what you describe doesn't match my expectations of how the system is being operated, and I would want to take a look at it - but cannot without you logging a call and providing some information that we can use to track it down.
As some additional information, when I look at the audit log screen for my record (which has clinician accesses in it), the columns I have are:
Date/Time
Operation Performed
Organisation Name
Role
Access condition
Action type
Subject Type
Subject
I have some external accesses. Firstly, I have some marked with organisation of DHS Medicare, Role of External Provider. These are all add document, and the action type is create. This is the creation of my Medicare records. This is normal if I selected when creating my PCEHR that I wanted Medicare records loaded. The action is a system action, no person looks at the record or touches it on the way in. It provides a link to the actual documents that were loaded. You would not receive a notification for this access, as it's an upload, not a read of your records.
Then I have a clinician using the provider portal to access my record. I get a transaction entitled "Retrieve All Documents", with an organisation name (my clinician), and then it says "External Provider" and provides my IHI as the thing accessed. In my case, I then have an emergency access, which clearly states the access was an emergency, and again shows the practice name and "External Provider." I'd doubt you'd have one of these, the legislation is quite explicit about when this can happen.
In my case I have no provider document upload, so I cannot comment on how that looks in the record.
Is one of these access types perhaps similar to what you have?
Dear Anonymous (support)
You sound like you work in the support team. May I suggest that you run a simple report on the system to see how many transactions were performed by 'External Provider' on anyone's record during July/August 2012. I have not visited a provider at all for the last 12 months nor had any reason for a provider to look at my record. Also I understand that there were no providers registered in that timeframe, and so no clinicians (providers) would have been able to access my record. Hence my concern when I see "external provider" listed as accessing my record. Why doesn’t it tell me which provider that was? I am assuming that it is a glitch that has eventuated from the many fixes and new versions required to fix the early problems with the system. I would be happy if it said honestly 'System Administrator' or ‘data quality function’. However, I suspect it is probably a programmer somewhere that has had the task of unloading and reloading data as part of a new version. Someone made a silly decision to put 'External Provider' in the role field, without thinking how that would be perceived by those who are anxious about their privacy.
I do not wish to log a call with the help desk, because I do not want to draw any attention to my record and wish to remain anonymous. On this blog I can log my concern anonymously, and I can see that the support desk is listening and will take action. Perhaps when I next look at my record it will be fixed?
Come on now, you don't need me to call the support desk - you just need to fix the problem before it upsets a lot of other people.
It doesn’t feel very Personally Controlled at the moment.
Yes, I am close to the support team. I agree, there were very few providers in that time period. Given the anonymous nature, I had question as to whether the commenter had user error (reading the fields wrong) or a legitimate problem. Clearly that's difficult to assess on a blog.
From the second comment I'm a little clearer on what sort of status you have, and level of knowledge. I understand therefore your desire for privacy.
It is clearly more difficult for us to troubleshoot without some level of patient identification, and in general we try to avoid looking at the records in the absence of a specific request from the patient themselves to do so. Nonetheless, the legislation does make some provision for such a thing in the case of system troubleshooting.
Can I ask for some data that wouldn't be identifying of yourself. I think you're saying that the audit log record(s) in question:
(a) have an "Approval Date/Time" in July or August (i.e. before 1st September).
(b) You haven't noted the "Operation Performed", but I am presuming from your reply that this is something other than "Add Document". Is this correct? (If so, it's not Medicare loading documents, and that rules out the majority of our audit logs with "External Provider", so helps to narrow it down)
(c) The "Organisation Name" field is blank
(d) The Role is "External Provider"
(e) The Access Condition is blank
(f) The action type you haven't mentioned. It matters in the trouble shooting whether it is "Read" or "Update", or perhaps a combination of both.
It would be useful, but not critical, to have the action type(s) and operation(s) performed.
And as an FYI, we haven't unloaded nor reloaded any data as part of the various releases, we upgrade the database tables in place when that is needed.
My best guess at present is that we actually have the organisation id in the database, but for some reason that id has no associated name, and on the screen we chose to show the name but not the id (presumably because very few patients would know the ids anyway). But that would be what we in the industry call a WAG (wild a***d guess) without some more information.
Dear WAGer,
You have told me enough to understand that the quality of the data in the system is such that you cannot always tell who updated and read a record other than to say "External Provider". I have lost trust in the system - at least for my record. May I suggest others run their audit logs over the periods Jul-Aug 12 and Dec12.
Dear Anonymous. I cannot control what conclusions you draw, but it is not the conclusion that I would draw from the information provided. I am not currently aware of any instance in the system where we have an audit record marked as "External Provider" that we do not have an identification of the organisation or person that performed that transaction.
I am aware of a large number of "External Provider" transactions that occurred in August that relate to the loading of historical Medicare records, these transactions continue to this day for those newly registered. You have not provided me sufficient information to rule that out as being the transaction that you are seeing.
We will investigate to the extent that we can with the information you have provided, and as this is the only channel for communication, will provide such (non-personally identifying) information as we can if we find more detail.
this is surreal!
re: My best guess at present is that we actually have the organisation id in the database, but for some reason that id has no associated name, and on the screen we chose to show the name but not the id (presumably because very few patients would know the ids anyway).
That doesn't fill me with confidence that this is a system (and that includes the system operators) that can be trusted with a nation's health information.
The really scary thing here is not that they don't seem to know the ids or the names of the clinicians supposedly accessing this (and possibly other) person's record. The really scary thing is that the system operators/trouble shooter seems to think it was OK for one of the 'very few providers (registered) in that time period' to access a record which they had clearly no cause or right to access - the poor person has claimed that the reason he was surprised by his audit log is that he has not visited a clinician for a very long time, so why was one of a handful of early registered doctors accessing his record? I thought the legislation was very clear on this. Also, the only way a clinician could have accessed a person's record in that timeframe is to go through the clinical portal and know the patient's IHI or name, DOB and Medicare Number. Very unlikely in this case. More likely that the system design and the audit log functionality is so poorly designed that even those tasked with trying to support and trouble shoot problems are tripping over themselves trying to explain the anomalies. I fear this is not going to end well.
Genuine thank you for the contribution anonymous (support ). It is commendable to have a go at answering the questions.
I think we need to hear from anonymous (vendor test ) to recreate a test case with the scenarios being reported.
Maybe if they read the feedback they can recreate it, however , "user error" is something that lies at the heart of any poor system design. User error possibilities should be removed and chased away at all cost!
If the user can make errors it is not a very well designed or tested system ;) and should be fixed.
"re: My best guess at present is that we actually have the organisation id in the database, but for some reason that id has no associated name, and on the screen we chose to show the name but not the id (presumably because very few patients would know the ids anyway)."
response:
That doesn't fill me with confidence that this is a system (and that includes the system operators) that can be trusted with a nation's health information.
on the contrary
I am filled with confidence that this is a system that can not be trusted
but that's cause I know more.
I understand the general audience on this blog, and I understand the risks of participating in the discussion, which is that pretty much anything we say can, and probably will, be misinterpreted. That makes it hard to interact, and it is clear that making my WAG was a mistake.
Conversely, we cannot easily allow someone who appears to have a support issue to be ignored, and if that person doesn't choose to use the other channels of support, then that inevitably means participating here.
Before people draw too many conclusions, let's recap:
1. We have a user who believes they have records in their audit log that are:
a) from an External Provider
b) have no organisation name
c) occurred in July/August
d) they had no legitimate provider interaction in that time period.
2. During that time period there was External Provider activity that is likely to be on most records that was legitimate, as each time a Medicare record is loaded it shows in the audit log as External Provider activity. The user in question has not confirmed whether the audit log records they are concerned about are of type add record or not. If it were the case that they are of type add record (in which case it would provide a link to the record added, and the user could confirm for us whether that record was a Medicare document), then the only issue here is that the audit log apparently doesn't show Medicare's organisation name (and we know that most of them do). With more information we could investigate that.
3. During that time period there were a handful of clinicians using the system, and their activity shows as External Provider. The user in question asserts that they did not interact with any of those providers, but clearly we'd have no way of knowing that without some actual details of the user in question so we could check the clinicians and ask them why they accessed the record.
4. The user asserts that there is no organisation name. If we assume this to be true (we have no reason to doubt, but it is, after all, an anonymous comment on a blog) then many are assuming this means we don't know who the clinician is. The audit log database table has fields in addition to those shown on the screen. It is unlikely that we wouldn't know who the clinician is (most likely we would have their id at a minimum), but again, without finding the records in question it is hard to make any meaningful comment.
Clearly we do have concern about this perceived situation - otherwise we wouldn't be contributing here. But again, at present, it is an assertion with very little detail from an anonymous commenter on a blog. That's a rather hard thing to track down, many on here seem to interpret that as a sign of a system issue.
The main aim of contributing to the discussion was to elicit additional information that might permit some tracking down of the problem. The user in question appears reluctant to provide any additional information, even information that clearly wouldn't identify him or her. I think we could draw some conclusions from that.
Dear Anonymous (support)
Your efforts in trying to explain and contribute to this discussion are appreciated. But you seem to not understand the issue.
This is not a support issue. If it was, then the blog commentator would certainly be calling the help desk to ask who has been wrongfully accessing their record. Perhaps the “conclusions” you should be drawing are:
1) The commentator considers that it is not possible that a provider (with the exception of Medicare loading their records) has accessed their record to view and/or update it. Therefore, they consider that the data presented to them in the audit log is incorrect. They see this as a symptom of poor system design, lack of testing, and incorrect presentation of data at the user interface. This has the potential to lower credibility and trust in the system.
2) This blog is a forum where such issues with systems such as the PCEHR can be raised anonymously and discussed. I am not sure your help desk would cope with a complaint about poor system design? Also, the commentator obviously does not want to be identified in making such a complaint.
3) It is good that this blog is being monitored for issues, but perhaps what you should be doing is taking a look at the issue of the audit log now, as well as the underlying data structures in records. If there is a design/presentation/data quality issue, then it is likely to escalate considerably when providers commence accessing the system as their conformant clinical information systems are implemented in their practices and health services. Now is the time to act.
Is there a formal mechanism (other than the help desk) to address these problems?
A mechanism for people with concerns about the information in the PCEHR and the way it may have been accessed?
A mechanism independent of the system operator, NEHTA and DoHA, so as to avoid conflict of interest and potential negative repercussions?
A mechanism with authority to properly investigate and take appropriate action to remedy the situation?
If not, why not?
"Is there a formal mechanism (other than the help desk) to address these problems? "
I understand that there is a new clinical governance committee for the PCEHR, run from the Commission for Quality and Safety. I could not on a quick search find their terms of reference, but I'm guessing that it is their job to respond to incidents such as the one above.
I suppose a quick call to the Commission would identify how one communicates to the committee, and I assume that such communications would be confidential if requested.
re: I understand that there is a new clinical governance committee for the PCEHR, run from the Commission for Quality and Safety. I could not on a quick search find their terms of reference, but I'm guessing that it is their job to respond to incidents such as the one above.
Are you (or is someone else) suggesting that a governance committee is an appropriate operational mechanism to ensure information integrity in the PCEHR?
Oh dear.
"re you (or is someone else) suggesting that a governance committee is an appropriate operational mechanism to ensure information integrity in the PCEHR?"
Cynical you Bernard. Everyone knows Committees are the path to salvation (well politically at least).
All I was saying is that there is another avenue open for those with PCEHR concerns, and if individuals have such concerns they should use every available channel to convey their concerns. Never leave yourself open to the charge that you knew of risks and didn't do everything in your power to address them. No matter how flawed the channels on offer are. Especially if there are risks to patients.
That does not absolve the 'higher ups' for creating the opaque governance and reporting structures that they have for PCEHR, with plausibly deniable lines of responsibility for political benefit - which is the only reason you would design it this way. If you were serious about good governance and safety/security you would have a single line to an independent entity that did the job, had the mandate and resources, and took the rap if it failed.
The appalling Governance Framework for the PCEHR is a very good reason to have nothing to do with it in my view.
David.
Cynicism often arises in an environment of vagueness and uncertainty. Cynicism is difficult in an environment of well substantiated facts and evidence.
The thrust of my comment, although I phrased it in terms of questions, is: there should be a highly visible and responsive channel for resolving problems with an individual's health information. Especially with a new system when there will probably be teething problems.
AFAIK, there is none.
There is a conflict of interest certainly. You can see that in this comment trail.
The system operators will maintain that there is nothing wrong with the system! Of course it was fully tested before being rolled out. You are a mere anonymous blog commenter and you must be wrong! Our data is perfect! How dare you criticise. And why don't you just accept that you did see those External Providers in that time period! You must have given them your IHI or your medicare number. You might even have dementia. After all what sort of people hang around reading a blog like this! And if they think there is a problem to patient safety, then they have an obligation to tell someone about it!
And yet there lurks a serious risk that might need to be addressed, and could be nipped in the bud now. If I was the system operator I would do this:
1) get the system development team to review the program that extracts the data to display in the audit trail. Is it doing this correctly? Does it allow the Provider Name to be blank? Are the links from the document ids still valid? Test a few scenarios.
2) If the audit trail display program seems to be OK, then write a simply program to extract data from the system - count the number of transactions in a time period that have 'External Provider' role but no provider name and were not simply Medicare record uploads. (E.g. a read, an update or a change of access controls). If there are a significant number of these, then you can assume that you have a problem with the integrity of the data in the system, and will need to investigate further, to ensure that the problem does not escalate. If there are only a few of these as a result of a historical system upgrade glitch, then you probably should write to those people explaining how it happened.
Re: "If I was the system operator I would do this:"
If this were a proper production system, with proper controls over data, the system operator would not be allowed to do this.
Live data should only be accessible through properly written system functions monitored and controlled like any other user access mechanism.
The system operator should only be allowed to create and change executable code in the development environment and then request migration into production via the properly controlled test and verification procedures.
Development and support staff should NEVER be able to see production data using special privileges.
Has the architecture and design of this system been audited? By someone who has at least done Production Systems 101?
I can't believe that you are demanding action to be taken by posting anonymous comments on a blog website!
One person complaining about a specific issue (that doesn't seem to have occurred for anyone else) and then refusing to provide specific details!
They (the operator?) then reached out to you to encourage you to help yourself but you refused. If you had just called initially, they probably would have been able to just look at your audit logs (without going into any uploaded documents or the like) and this whole thing would have been sorted. You've now painted yourself into a corner, because if you do now contact the helpdesk they will know exactly who you are.
Disclaimer: I am a card carrying member of one of the opposition political parties so will bash the government every chance I get. I do not have a PCEHR.
Just my $0.02 worth...
@Freddy
re: "I can't believe that you are demanding action to be taken by posting anonymous comments on a blog website!"
Maybe the demand is coming through this blog website because there is no other mechanism.
The original poster said "I don't feel comfortable ringing the help desk - I don't want anyone else messing around in my record."
In other words the poster is not confident that his/her information will be treated properly and/or that there may be reprisals.
I've asked questions about formal mechanisms to address this issue but nobody has responded.
Postscript:
On checking my record now, I can see that there have now been adjustments to my audit log. It is now quite different. (Yes I downloaded my own extract from the original set of audit entries and have compared them to today's version of the audit log). I no longer have the strange 'External Provider' access transactions appearing in my log. It has been tidied up by the PCEHR fairy! I wonder if it was in response to the comments on this blog. I hope so, otherwise I think I should be setting up my own audit log of the audit log.
"I can see that there have now been adjustments to my audit log. It is now quite different. "
What??!!! So there were transactions that appeared either unexplained or potentially illegal on your audit record. Now they have been spirited away from the record.
That does not mean they didn't happen. Making the audit trail 'clean' does not explain the existence of the transactions that you were concerned about.
Talk about tampering with the evidence!
Do you hear that?
That's the sound of the integrity and sanctity of the PCEHR system crumbling and disappearing before our very eyes.
There is no difference between incompetence and corruption in this instance.
Will this even get a mention at Senate Estimates as surely it should be one of the leading questions if the PCEHR system’s trust and integrity has now been compromised?
umm, an anonymous contributer who refused to identify himself has withdrawn his complaint, with neither evidence from before, and after, and that's "sound of the integrity and sanctity of the PCEHR system crumbling and disappearing before our very eyes"?
rofl
So, audit logs can be changed.
I wonder if there is log of changes to the audit log and if it is available to the owner of the health record?
And its the fact that an audit log can be changed that destroys integrity and credibility, not the withdrawal of a complaint.
Hi Bernard
If indeed audit logs can be changed, that would be a very serious issue, and certainly counter to the whole concept of the design and operating governance of the system. Those things were put in place by people who believed they were necessary and real (I watched), and they would be most concerned if this report is true.
But say what you like, so far the report remains anonymous and unsubstantiated. Until someone wants to offer evidence, it's hardly "integrity and sanctity crumbling before our eyes" - though I think it will be if that claim is substantiated.
@K
You said "Those things were put in place by people who believed they were necessary and real (I watched), and they would be most concerned if this report is true."
Can you clarify if by "put in place" you mean it was a requirement, or that is how it was initially implemented.
"was it a requirement, or that is how it was initially implemented"
Umm, it was a requirement. It was tested in test area, and though I didn't see the contract, it would be normal for a contract to specify that such conditions are actually followed. It was certainly taken very seriously by all the team that I worked with.
@K,
Are you suggesting that it looks as though the system operator might not be complying with the contract?
IMHO, the system architecture and functionality should make it impossible to change an audit log, not something that is an option but which is regulated by contract.
My guess is that the system operator has access to the database and has been making record level changes using admin privileges.
I would also guess that audit logs are created on request by the user. Which means it isn't really an audit log, it's just a query on the health record database.
A true audit log would have entries created at data access time and be held on a read only basis, completely separate from health data.
What would be really nice is a proper Concept of Operations that describes how all the features of the system actually work as implemented. The ConOps released in the past are a) not complete and b) do not reflect what has been implemented.
@Bernard - your guesses contradict each other.
Either the audit log is created on-demand by reading the 'health record database' (and hence can't be manipulated), or it's created at data access / write time (and hence, absent appropriate controls, could be manipulated at the record level by the Operator).
Hi Bernard
First, the system operator is DOHA. Neither NEHTA nor Accenture/Oracle have access to the production system. I was distantly involved in the specification design phase, and this was taken seriously. But read only data is a flag set on the database, and sysadmins have to have rights.
But right now, all we gave is an anonymous claim, and no evidence. Perhaps David could nominate a neutral third party who both the individual and the system operator would trust to witness the evidence, but in the absence of that, how can we know? My view is that this is the gravest of accusations that could be raised, and therefore needs both good evidence, and alos a very convincing response from the operator. We've already had as convincing a response as I could imagine without evidence, btw.
In most systems audit logs are a combination of what Bernard is talking about.
The raw data is write-once, and written when the transaction that's being audited occurs. However, because audit logs can use a lot of space, they're typically stored in a compressed format - using identifiers and the like.
When the user requests those logs to be put on the screen there are some lookups that occur - mapping ids to human readable data.
If the system is using this approach then a change in the way data is displayed doesn't necessarily mean a change in the underlying data.
re: "Either the audit log is created on-demand by reading the 'health record database' (and hence can't be manipulated),"
I'm suggesting that data in the 'health record database' can be manipulated and so the generated audit log does not reflect what actually happened at data access time.
re:"When the user requests those logs to be put on the screen there are some lookups that occur - mapping ids to human readable data.
If the system is using this approach then a change in the way data is displayed doesn't necessarily mean a change in the underlying data."
That is a really bad approach. The audit log should contain all relevant information. To do look-ups when the audit log is being created means that any change in the look-up table after the log entry was created would destroy the integrity of the data.
@K
re: "But read only data is a flag set on the database"
That's only one way of making data read only. There are hardware devices e.g. WORM (write once, read many) drives, often optical drives or DVDs/CDs that are finalised after creation.
It depends on the lengths you want to go to, to achieve credibility and trust.
hi Bernard
"There are hardware devices e.g. WORM (write once, read many) drives, often optical drives or DVDs/CDs that are finalised after creation"
yeah, but the sys admin can rewrite new ones. This is a question of governance and policy.
Do you really think that after some anonymous claim that the audit trail shows unauthorised access, that the syster operator would (a) magically determine who the claim was from (b) update the access records so it didn't show the accesses that weren't authorised?
You really think that's believable? Cause I don't. There's just to much information gap and risk in that scenario. (given a much more precise report, with real malfeasance from the system operator, then I'd think it more likely, but there's still policy and risk reasons to think it's very unlikely)
I find it much more likely that the anonymous claimant is mistaken and/or misreading what is not as usable a system as it should be. Or malicious, though that's not as likely (Occam's razor, see)
But in the absence of evidence, we'll never know, huh?
@K
re: but the sys admin can rewrite new ones"
you could write two copies, one off site and not accessible by the sys admin.
as I said "It depends on the lengths you want to go to, to achieve credibility and trust."
re:
"Do you really think that after some anonymous claim that the audit trail shows unauthorised access, that the syster operator would (a) magically determine who the claim was from (b) update the access records so it didn't show the accesses that weren't authorised?
You really think that's believable?"
No it's not believable - as you describe it.
However, what seems to be true is that the audit log changed. That's the behaviour of the system that's being questioned.
and as you say:
"But in the absence of evidence, we'll never know, huh?"
It's a pity that such an important national infrastructure has been built without greater transparency.
I don't think anybody is asking for content, other than their own, or even details of technical security, just a clear description of what it is and how it works, as an Information System, not an IT system.
I guess there are only two parties that know what really happened. The system operator and the original blog commentator. Now that the audit trail has been 'cleaned up', how could anything be 'proven'; even if the blog commentator presented his copy of the original audit log, would the system operator agree that they had changed it? I think not. More likely to say 'you must have read it wrong!'
But if the blog commentator is correct, then the whole thing smacks of a poor system design compounded by slack testing, and a lack of governance around data quality and integrity.
I hope this blog stream has made an impact on at least some of these issues, although as we all know, it is very difficult to fix poor system design after the horse has bolted.
In politics it is not the mistake that gets you, it is the cover up.
I think that one or more well meaning technical people from DOHA posted, trying to find out what was happening with the audit log.
They didn't realise the consequences of what they were saying. They were a bit naive.
I doubt we will see any more posts from them, either because they are concerned about what DoHA will do if they are identified or as the result of management instructions.
It would be a pity if anything does happen to them, at least they had good motives. I can't say the same about DOHA executives.
DoHA/NEHTA/Accenture/Oracle must all be in survival mode, hopping things don't get worse. Unfortunately these things always have a habit of getting worse.
Re: "Unfortunately these things always have a habit of getting worse."
PCEHR faces patent probe
The Australian
US software firm MyMedicalRecords.com is investigating a possible infringement of its patents by the National E-Health Transition Authority (Nehta), which is spearheading the rollout of the national personally controlled e-health records system.
Mymedicalrecords.com is a patent troll. There's nothing I'd like to see more than them try to sue a government for patent violation. Blood sucking parasites.
Re "Mymedicalrecords.com is a patent troll. There's nothing I'd like to see more than them try to sue a government for patent violation. Blood sucking parasites."
That may be your opinion - but the patents they have registered here are genuine and if they choose to sue then IP Australia will take it seriously like they do any other patent suit. In which case NEHTA and DOHA better be prepared! It could get very, very messy.
Here is a link to those patents
2008202401 Method and system for providing online medical records
2006202057 Method and system for providing online medical records MyMedicalRecords.com, Inc.
http://pericles.ipaustralia.gov.au/ols/auspat/quickSearch.do?queryString=MyMedicalRecords.com%2C+Inc&resultsPerPage=
Arrogant Americans. If they think they can win a Patent fight with the Australian Government they are sorely wrong. If they think they can force NEHTA to succumb to their legal onslaught they may be right. But as we all know NEHTA will continue to spiral downwards towards its deathbed. The with no NEHTA does Mymedicalrecords.com think it will just be able to step in to pick up the pieces and fill the hole? It could not do so without Government support. Perhaps MMR.com.au has already aligned with the Liberals and this is a well timed political ploy to bring further embarrassment to Labor. Surely they aren't trying this on from the USA without having a mouthpiece down under to represent their interests.
It was me that said, "bring it on". And I know the patents are genuine, and it will be long and expensive.
But that doesn't mean that the patents in question aren't stupid. If these patents cover the pcEHR, then what online medicals records system wouldn't they cover? It's not right that you can patent a concept of how to do things like that. (Actually, I don't think they do cover the pcEHR. The invention "includes assigning a phone number individually associated with the consumer for fax and voice communications" - not something the pcEHR does. I'll stop there)
The more the patent trolls take the governments on, the more likely it is that the governments will get around to reforming the stupid system. And that means they are spending less time suing small companies that don't have the resources to fight them.
The patents appear frivolous and easily circumvented. I would not be quaking in my boots if I was DOHA or NEHTA. The key is to realise that you must meet *all* of the criteria specified in the first claim to infringe the patent. All subsequent claims in a patent depend on the first claim holding true. Drop even one element of claim 1 in your product and you are home free.
Re the audit log issue:
The PCEHR System probably should not call it an "Audit Log". It is not truly an audit log if it does not faithfully trap all accesses (including by the system operators/system admin staff), and is in fact a view of underlying data, which can appear to be different over time if underlying data is changed or cleaned up. It probably should be called something like "Record access tracking".
Post a Comment