Grinding slowly on...

Next steps are slow to evolve; given the scope of development - even for the "simple" phase one of the mediblog application - I'm thinking of using an offshore development centre. This clearly upsizes the cash injection required to get things moving but may be the best way to breathe life into it. Jury's still out on that and meetings, finally, are being planned to make some sense of it all.

Biting the bullet?

Now we have a working model of the log-in application, including the JAMES email server for handling the mail transactions with new users, the time seems right to get a working application onto the net. This is curiously parallel to another debate I'm involved in with my fellow Love Commandos (the best, "Rock/metal band in Birmingham with a guy who looks like Jesus playing drums"). We're heading into the recording studio soon to begin work on our first album and although its highly improbable that we'll make money out it (or indeed that anyone who's not related to us will want to even listen to it!), we need to plan for a hypothetical contingency that we will have a hit record our hands. In that respect, for both the album and Medys its easier to sort out who owns it before its worth anything than afterwards. So, after years of avoiding the issue, it seems likely that Medys Limited, created in 2000, will stop being a Dormant Company and start being active. Interesting times ahead!

Open Source Reporting and BI for MediBlog

I've been concerned for some time about how to present reports to the users and now Liferay has announced a partnership (or something) with a group called Pentaho. This seems to be the answer to all the reporting issues and interestingly they have settled on the same sort of approach as SAP: publish reports in the Portal! So it must be a promising partnership. Probably.

Still plodding on...

Well, not much to report lately. We've been busy with day jobs, sailing training, etc. and the incentive has dimmed a little following the Google revelation. We decided during a recent meeting that we would go ahead. We have only a few dozen days of Steve's time before he's off around the world in a boat so will be concentrating on getting some basics done.

Meanwhile, my customer has agreed to donate some hardware (a couple of old Sun servers) so we have an opportunity there, also, the EU have agreed to fund the Histio Net project but with far less cash then we asked for and far less than we need. Given the Google scare and the general lack of time we're not going to pitch Medys/MediBlog for the work - too risky!

There have been a few "full & frank exchanges of view" about how to divide the new reduced budget amongst the clinicians' institutions and across the Work Packages. One of the original team has already pulled out and it's make-or-break time this week to agree the new budget or lose everything. If things are salvaged I will be travelling to Vienna, Austria this week to discuss this and also to review the offerings from the potential IT providers. It will be interesting to see what sort of quotes provided as I can't see how any normal IT company could deliver the services to the meagre budget that is now available.

Oh no - G+ogle!

It emerges that Google have been working on an application like MediBlog for a year or so and for some strange reason they've given the project the name "Weaver". This discovery has made us stop to think about whether we really want to persue the MediBlog project with a team of three enthusiasts: why bother if Google can throw 15 sqillion dollars and half of California's Uber-geeks at it? There are a few things we'll probably be doing differently and its possible that these innovations may never even get out of the Visio/Word stage - just because we've found out that Google are working in the same area.

Anyway, there are a few screenshots of the Google service around on the net, its interesting to see how Google have approached the problem and also the ensuing blog comments have highlighted a number of other existing services e.g. revolutionhealth.com and openhealthrecord.org which are in various stages on completion.

A few themes have emerged in the blogosphere:

1. "Don't trust 'em: Google are mad, bad and dangerous to know"

This was nicely countered by one comment that maybe the people who think this should use Weaver to look up what can be done to help them with "Feelings of paranoia" or Alzheimer's Disease. The current issue of The Economist dedicated a front page to just this question, neatly concluding that "As things stand today, Google has little to worry about. Most users continue to google with carefree abandon" with the caveats that:

"The test comes when the good times end. At that point shareholders will demand trade-offs in their favour".

"Besides the slow risk of calcification that comes with growth, there is also the risk that Nooglers (new Google staff) will dilute Google's un-evil values". They cited the example of Nick Leeson, the misguided criminal who gambled away Barings bank.

I suppose that we won't know what Google might do if the good times end, but Google's value also depends a lot on goodwill - if they get caught doing something really,really bad (e.g. somehow compromising private health records) then we could all decide to stop using them and the value of the company will reduce quite rapidly - shareholders will probably understand that and for that reason I doubt there will ever be much pressure for them to "turn evil". The Nick Leeson analogy is more realistic - a small bunch of criminals or fools could do something to release private information but that risk lies with every large (or small!) company.

2. Done right, this could be something really important and worthwhile (*)

This line of thinking suggests that Google is really a force for good and are the only ones who can really sort out this problem.

3. google.com/h9 still doesn't work :-/ it redirects to an "https" page with servicename = weaver

Someone found a link to it..

My current line of thinking is that there's always room for more than one player in any market so we should still continue to see if our ideas fly - at least until we have to dedicate serious money or time to it when the risks of "competing" head-on with Google will be more understood. In any case, Google haven't finished it yet - it won't be ready to help with the HistioNet project and in my opinion it will never be an appopriate tool for narrowly defined bepoke projects like that.

Persistence!

..not sure if I mentioned it earlier but just in case: after some debate, googling and consultation we decided that Hibernate is the best way of integrating data into our web application, so we've canned the idea of using Stored Procedures in favour of Java classes. Steve now has the database and has made some progress populating the JSFs with MySQL data via Hibernate.

Registration and Log in.

Well we've actually started work on the system. The first, prerequisite, application is "Registration and Log In". This actually proved to be more complicated than one might expect at first but is actually quite logical in hindsight.

Users need to register before they can log in, and when they've registered they need to maintain their details. Then they need to log out and then log in again... etc. This required some thought and a bit of time joining eBay again to see how they do it (thanks eBay). I created a "spec" in Visio, Mike has produced the data model in the MySQL database and we discussed & refined it with help from the nice Entity Relationship diagram that was produced from the MyEclipseIDE database tools, which reverse-engineered the database. So we now have the first part of the database designed and ready to go. Mike produced a script to build the database and populate the various drop-down fields then emailed it to me & Steve so we could reproduce it locally simply by running the script in either the MySQL Query Browser or the MyEclipseIDE SQL tool.

This first version now includes the rather irritating but essential capability of supporting different languages. This makes it quite tedious for some jobs because some Lookup tables need an entry for every language we want to support - and of course we need to be careful about using Unicode. Initially we will be concentrating on English and French.

While we're on the subject of languages, Steve has found the best way to handle multiple languages with JSFs - all you need is a bundle for each language and away you go. You still need to maintain them though!