You are currently browsing the category archive for the 'Uncategorized' category.
Because my work email account is Exchange, I can’t use the activesync-style connection to Google Mail from my iPhone (you’re only allowed one activesync account). The only alternative is IMAP, which is OK but (arguably) uses more battery and is slower to notify when new mail arrives. I also use Gmail labels a lot, so I miss not having them when using the iPhone Mail app. A combination of notifications with using the Gmail web app (for labels) would be ideal in the absence of a proper Google Mail app. So I’ve experimented with Google Mail push apps. These apps display push notifications when your Google Mail account receives a new message. Often they also embed the Gmail web app. Here’s what I thought of the three I tried over the past few months:
G-Push Mail by Jon D: The first one I tried. Notifications were at best intermittent and the app was quite slow. OTOH the developer responded quickly to requests for technical support.
GPush by Tivieras Apps: The second attempt. Notifications were more reliable. One thing really bugged me though: every time I opened the app to view an email, I had to sign in to Gmail. What a pain. I asked the developer for help but got no response. Eventually I got so hacked off that I decided to try another app.
PushGmail by Gary Fung: This is the app I currently use. Notifications are very good, usually instantaneous. The embedded Gmail web app works well, faster than either of the other two apps and only makes me login very occasionally.
Just in case it helps someone else: My XP mode under Windows 7 was very slow to start – 10+ minutes in fact – after I added the XP mode VM as a member of our AD. The problem was that the Virtual PC settings had the network set to “Shared/NAT”. I changed the setting to point at my network card instead and XP mode started much quicker, i.e. a couple of minutes or less.
I wasn’t able to attend the Traction User Group this year, as usual – I’m not sure what the NHS would say to my request for funding for a trip to Rhode Island ;) However, I did follow the TUG on Twitter, and Traction have now posted videos of many of the talks. I’ve only managed to watch one so far, so it had to be the keynote from Carmen Medina (Director of the CIA’s Center for the Study of Intelligence). You can watch it here. It’s really interesting stuff. Carmen describes the various circumstances which led to the catastrophic failure of the electrical system in the north-eastern are of USA/Canada in 2003. She uses the lessons learned as a template for “diagnosing big goof-ups” in any system or organisation. Here’s her template:
- Strategic failure
- Lack of fundamental knowledge awareness
- “Some nutty technical issue”
- Lack of effective collaboration
She then goes on to break down the reasons for the lack of effective collaboration:
- Physical separation between teams
- No shared electronic spaces
- Inadequate handover briefing
- No training in emergency scenarios
As you can see, it starts to look rather relevant to the NHS. I was even more struck by her description of what she called “HR²” (i.e. HR squared) organisations. These are “high risk, high reliability”, categorised like so:
- Think about failure all the time, avoiding failure is critical
- Tend not to simplify problems too soon, are used to dealing with “messy” problems
- Designed for resilience
- Are operations/process-oriented, i.e. like predictable, reliable causal processes
- Emphasise expertise and experience over hierarchy/seniority
Doesn’t that sound like a description of the NHS, or at least what the NHS aspires to be? If you listen to the talk, you can hear why Carmen thinks social web technologies can help such organisations, both in the “business as usual” situations and also the positive effect the resulting networks of trust have on teams when they end up coping with an emergency. Finally, here are a couple of quotes which I thought were particularly relevant:
[On the subject of dealing with complexity] We still cling to the “failing assumption that individual control nodes can understand the complexity of a large system”
and
“[In regard to the younger, supposedly tech-expert generation] It’s not tech-savvy that matters, it’s individual [or group/communal] ownership of work”
P.S. If you watch till about 17 minutes from the end, she answers a question from me via Twitter! So bizarre to hear my own name and NHS Orkney mentioned. I asked how you deal with “lines of responsibility” when working collaboratively without the old hierarchies. Carmen answered well (once she understood my poorly-phrased question) by giving the example of Cockpit Resource Management, i.e. when people work regularly in teams, they trust each other enough to make quick, collective, accurate decisions. I would counter that by asking “what if working with other people led you to trust them *less*…?”
This Washington Post article describes some of the problems clinicians have had with EPR deployment in the USA. In particular, I was struck by this statement from a doctor:
Last year, his department found that physicians spent nearly five of every 10 hours on a computer, he said. “I sit down and log on to a computer 60 times every shift. Physician productivity and satisfaction have fallen off a cliff.” Link.
I wonder how much of that 5 hours was spent logging in? Made me think of a previous post. Looking at the article as a whole, I find it astonishing that hospitals would rollout a new computer system with no dead-tree backup. A common misconception is that the IT implementers will assume that the clinicians, managers and admins already have established procedures and failover tactics; the clinicians et al will assume that the IT guys have already worked all this stuff out. And then when it breaks, IT blames the clinicians/management and everybody else blames IT!
Troubling news from the EU – they’re smudging the difference between “open source” and “homogeneity” in software. Here’s what Cory at Boing Boing had to say in reference to the story on Computer World / Slashdot:
Lobbyists at the EU have gutted the definition of “open” (part of a proposal to require more open standards and open source tools in European government) to mean “the willingness of persons, organisations or other members of a community of interest to share knowledge.” This meaningless drivel replaces a more robust definition that included, “The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).” Link.
Ars Technica teases out the implications for data, something which we in the NHS should be particularly aware of when we’re considering portals etc:
This statement implies that interoperability can be achieved if everyone merely uses the same exact software. Although a homogeneous environment simplifies a lot of things, it’s deeply misleading to suggest that it is equivalent to open standards as means of achieving interoperability. Open standards make it possible for third-party developers to create independent software implementations that can access and manipulate the data. Depending on a homogeneous environment to facilitate interoperability without open standards naturally creates a very strong risk of lock-in.It’s not enough to be able to share content between users of the same software application; you need to be able to pull apart the data so it can be repurposed and used in other systems. This is a key aspect of interoperability. Open standards make data more future-proof and guarantee that it will still be accessible when the software you use to produce and access the data is no longer available or maintained. Link.
Here’s a wonderful article from a GP in the USA. [Discovered via @DrChrisPaton] He explains why doctors don’t like using EPRs. I recognise virtually all the arguments in there, and I completely agree with his conclusion that there are inevitable trade-offs: e.g. doctors making eye-contact with patients, but you can access the patient’s medical record from home at 2 in the morning. The last paragraph in particular reiterates the principle that we tried to follow in our development of an EPR here in Orkney: “the key to physician satisfaction is flexible software that does not dictate workflow choices. New software is not the goal; the goal is an information system with a good measure of flexibility”. I couldn’t agree more. And the following sentence seems like a timely warning to the NHSS when we are on the cusp of investing a lot of money in new infrastructure: “properly guarantee interoperability and avoid paradoxically funding software that is not only too expensive but that also create silos of proprietary isolation”.
For the past year or so I’ve been using MobileMe to store my contacts and several calendars. I couldn’t find any other way at the time to sync both my NHS Mail Exchange account and my personal calendars and contacts to my iPhone and Outlook. But I’ve now given up on MM for the following reasons. Firstly, the MM applet which runs on my PC is buggy and doesn’t run properly if you don’t have Outlook set as the default mail client. Secondly, it’s too expensive – I really don’t want to pay £60/year for the service. Finally, it’s much more difficult & expensive to share stuff in your MM account with other people than it is with e.g. Google calendars. So I decided to look for an alternative.
The solution I’ve settled on is (so far) very reliable and doesn’t cost me an arm and a leg. It is admittedly less convenient, but at least I don’t have to put up with the MM applet any more. [Of course, none of this would be necessary if we could have two activesync accounts on the iphone! A feature which has turned up in Android 2, I notice.]
- Get a Google Mail/Calendar account. I decided to get a Google Apps domain of my own.
- Import the calendars from Mobile Me to Google Calendar (GCal). MM doesn’t provide any way that I could find to export the calendars, so I had to export from Outlook.
- Create a new Outlook profile on the PC to host the GCal stuff, then add ical subscriptions for the calendars. [It's important to do this in a separate profile - if you do it in your Exchange profile, the calendars will be synced to Exchange and you end up with the same calendars twice on the iphone.] [Update 2009-12-03: Adding ical subscriptions can be a bit tricky. The best method appears to be to copy the private ical address from your calendar settings in Google, paste the url into the address bar in Internet Explorer, replace the https with webcals and then Go. It should offer to open the file in Outlook. For some bizarre reason, you can't just paste that address into Outlook, otherwise you get an "invalid url" error.]
- Open Outlook with your Exchange profile and then add the new Gcal-connected .pst as an additional data file to be opened. I use Outlook 2007, so I can then have my Exchange calendar overlaid with my personal calendars.
- There’s no equivalent of ical for contacts unfortunately, so I’ve had to make do with dumping contacts out of Outlook, importing them into Gmail and then using sync tools to keep everything up to date on PC and iphone. (More of that in a minute.)
- On the iphone, get rid of the MobileMe account. This is pretty scary of course, but you can always add the account back if things go awry!
- Add a new account – choose Caldav and follow Google’s instructions here. Note that by default you only get one calendar, but at the bottom of those instructions it gives you the URLs for changing which calendars are synced. So that’s the calendars sorted!
- I use SyncInABlink to sync my contacts from Gmail to iphone. This is not convenient of course, since you have to remember to do it, it’s not automatic and doesn’t have the push facility of Mobile Me. But my contacts don’t change much over time and the SyncInABlink app is very good at helping you keep your contacts organised and duplicate-free. I also really like the fact that I can now share my contacts list with my family via Google’s sharing feature, something which would have cost a fortune on MM.
- As a final tweak, use Tungle to allow people to check your free/busy times against all your calendars.
So that’s it. Not great, I know, but it’s possible to live with it. I only ever used the Calendar and Contacts in MM, so I don’t miss the disk storage or url syncing. I don’t get the “where’s my phone” facility or push syncing any more either, and I do miss those a little bit. I doubt I would go back to MM unless it became a lot cheaper and more open. I think the big improvements we need to see in this field are: sync two activesync accounts on the iphone; Google Apps syncing should allow more than one calendar over activesync; there really needs to be some sort of Caldav-like standard for Contacts syncing. I hope this info is helpful – please let me know if I’ve got anything wrong or if you can suggest better methods for keeping everything in sync.
I enjoyed this post from a GP who writes iPhone apps. In particular, it was interesting to hear that he now understands how difficult it is to give clear roadmaps for software development, something I guess is not always clear when you’re not a programmer. He also advocates mandating open APIs for GP Practice software, something I completely agree with. I wonder if the announcement about the CFH interoperability standards includes GP software?
“But for now it’s about publishing standards and getting suppliers to open up the APIs [Application Programming Interfaces].”
A recent Ars Technica article reminded me of the substantial effort we put into designing the identification and authorisation mechanism in our EPR project. Just about every computer system in the NHS uses username/password combinations for identification at the beginning of each session, and we experience all the same problems which are described in the Ars Technica article. Not only are usernames/passwords a problem from a confidentiality/safety point of view, but it also creates a phenomenal amount of work for the IT support team. As we heard at the BCSHS conference, NHS Tayside are working with Sun on a single-sign-on project – which will come as a great relief to our beleaguered IT staff. But a SSO process only really helps the back-room staff, who have their own computer and are logged in all day. It doesn’t help the staff, say, on an acute ward who are sharing one computer between many staff.
The biggest problem for ward staff is the amount of time it takes to switch identity on the computer. It’s all very well setting a computer policy saying “everyone must sign-in to each computer system using their own username”, but that’s no use at all in a busy ward environment where the cost (in terms of time) of switching from one username to another is so high that people just don’t do it. User accounts end up being shared between many staff, with the account details often stuck to the front of the computer or written in a desk diary. We considered using some kind of identification card, like they use on tills in shops, but in practice this sort of system gets abused in the same sort of way: one card ends up getting stuck to the computer so that it’s always signed in.
So we took the approach of only requiring identification/authorisation when data is changed. All ward staff share the same session in the software, but when they click Save (or whatever) they are asked to identify themselves. Identification is via biometrics (a fingerprint scanner embedded in the mouse) or username/password (using their Active Directory account). If the fingerprint option is used, the software works out who the user is. (In both cases, authorisation for the chosen action is granted or not depending on that user’s rights.) So identification is “just in time” – staff do not have to sign in and out all the time. Accounts do not get shared between staff. As a result, the accuracy of our audit information tends to be very high.
The trade-off is that we do not audit *viewing* of data by *user* (although we do record the IP address of the computer being used to view stuff). We decided that it was more important to know who authored data than to know who looked at it. And our design is no worse in this regard than most others, given that the tendency to share accounts undermines the audit quality. It’s also still somewhat better than a paper record, where there is no viewing audit at all.
The key point here is that we recognised what is actually going on in wards, rather than assuming some sort of ideal where all staff have time to follow security policy. That means compromising on the auditing design, but the overall result is better for everyone – patients (better audit quality), ward staff (saves time) and sysadmins (no more shared accounts).
