Projects are all about assumptions and decisions In my experience projects go wrong as soon as an invalid assumption or bad decision is made. Once one of these occur, unless it is detected and corrected, the project will fail. The earlier in a project this happens, the greater the impact and the harder it is to detect. In the case Continue reading When the PCEHR went wrong
The AMA’s submission is here: https://ama.com.au/system/files/ama_submission_to_pcehr_review_nov_13.pdf and their press release is here: https://ama.com.au/media/too-much-personal-control-reduces-effectiveness-pcehr My submission was based on the assertion that those developing the PCEHR did not understand the complexity of health information. The AMA has come to the same conclusion, although they have expressed their concerns in the language of health professionals. Here are some selected quotes from the Continue reading The PCEHR: The AMA agrees with me.
You would have thought the most obvious thing to do when building an Information System is to have at least some understanding of the information you want in it. Not the PCEHR. As I explained in my unsolicited submission to the PCEHR review team: My opinion is that, in the case of the PCEHR, the root cause is a simplistic Continue reading PCEHR. How not to build an Information System
The PCEHR is being reviewed. In six weeks. Dr David More, who runs the Australian Health IT blog, has been invited to make a submission. David asked for input, and I responded with the following: David, I’m glad to hear that the enquiry is at least prepared to listen to views from the outside. I’ve been looking at the whole Continue reading PCEHR Review
Delimiter published a piece “Badly designed contracts doom public IT projects to failure” Badly designed contracts doom public IT projects to failure My comment: Badly designed contracts doom public IT projects to failure re “IT contracts often obscure objectives…” I disagree. – IT contracts ALWAYS obscure objectives. IT contracts are written around requirements. Requirements describe (for better or worse) solutions, Continue reading Badly designed contracts always obscure objectives