Regular readers will know that I have been complaining that I could not seem to find a document which was referenced in the HI Services Documentation.
I was kindly given a link earlier today. I also had an e-mail from NEHTA letting me know of the link six days after I asked by e-mail (20/11/2009 3pm). I hope the support for the HI Service is going to be a trifle better than this!
The document was published on the 24th November. The link is here:
http://www.nehta.gov.au/component/docman/doc_download/886-introduction-to-national-e-health-services
Despite the grand title:
NEHTA, Introduction to National e-Health Services, version 1.0, November 1 2009
The document turns out the be a riveting 13 page read explaining how someone with an apparently clinically fractured wrist can be passed between GP, Radiologist, Surgeon, (not Hospital but having surgery anyway – where who knows?) and back to GP followed and guided by securely sent and signed documentation all laden with patient and provider IDs courtesy of NEHTA.
The whole scenario is really clinically quite odd – and I leave it as an exercise for the reader to point out where. Oddities include
1. The unreality of the details provided (tip do GPs really decide on surgery and does all the surgery happen absent a hospital and a discharge summary etc?)
2. The number of IHI look ups and encrypted messages – does not look like we are actually adding a great deal efficiency here – who do you imagine made the decision not to have a way of having the verified IHI consumer who wants to have a personalised something with their IHI on it so look ups can be avoided? Most regular health system users I am sure would be keen on that!
There are other little issues – like the assumption of all this non NEHTA software all using the HI Service. That might take a while.
NEHTA really should provide an implementation plan of how we are going to reach this nirvana and maybe refine their plans and scenarios a little for reality.
David.
10 comments:
> The unreality of the details provided (tip do
> GPs really decide on surgery and does all the
> surgery happen absent a hospital and a
> discharge summary etc?)
Since the scenario was primarily developed by a working GP and a working Practice Manager, you are simply WAY off base with your comment.
And as a doctor of 20+ years experience I respectfully disagree!
David
The thing I'm finding lacking about all of this documentation is what we do with merged/duplicate IHIs. There is mention of them but I don't see any good descriptions of what happens and the different scenarios.
Also why is the onus on the parents of a newborn to verify their child's IHI when every other person will get one automatically through Medicare? The scenarios mention that the verification process will be used infrequently but the last time I checked Australia's birth rate was around 220,000 per year.
You said "who do you imagine made the decision not to have a way of having the verified IHI consumer who wants to have a personalised something with their IHI on it". If I understand your convoluted sentence properly you are asking why don't we have a smart card that contains an IHI. The answer to this is that it (the Access Card) was killed at the last federal election.
What about just a card (paper) with your name and the IHI you could carry in your wallet if you chose (totally voluntary). I had one for years with my Royal North Shore Hospital Unit Number as did my now departed Mum. Made things a lot easier.
David.
> Also why is the onus on the parents of a
> newborn to verify their child's IHI when every
> other person will get one automatically
> through Medicare?
To get a IHI "automatically through Medicare" you need to be registered with Medicare.... even newborns! Today, parents need to register their newborns with Medicare sooner or later.
Howevere, before they do that, the newborn is already in a healthcare event (birth). In the UHI world the newborn will acquire an unverified IHI figuratively at the moment of birth, in order that they can be consistently identified during their natal event, and any subsequent healthcare events that occur prior to registration with Medicare.
All the parent needs to do is get the issued-at-birth unverified IHI converted to a verified IHI at the same time they register the newborn with Medicare.... the registration process for the Medicare Program (MBS) reauires an EoI on the newborn and this is all that is needed to convert an unverified IHI to a verified IHI.
So this is effectively no different to what parents do now.....
> What about just a card
Like the Medicare or DVA cards that nearly all the population already has?
So why not put the IHI on a card for those who want it?
That has been excluded for a high tech approach as I read it?
David.
1. Because every system which can read a customer carried magstripe card can already read a Medicare card.
2. Why force vendors to replicate functionality which already exists? (and makes them no money)
3. Why make healthcare invididuals carry *two* cards if one can key to both numbers?
This is a rare case where NEHTA and its stakeholders seem to have made a choice which will suit the overwhelming majority of users.
If the Medicare smartcard does ever eventuate, the IHI number could be carried on there also - PIN protected if the customer wanted (but that's another thing to have to remember once a year when you need to allow access to it).
However a Medicare smartcard project is a minimum five year deployment to get updated infrastructure in place, and would need a better business driver than just being an IHI container (prescriptions container perhaps?).
The debacle of Easyclaim should be ample demonstration of how hard it is for Medicare to get even simple things to work in primary care...
I think you missed my point. I was suggesting it might be useful not to have to look up the IHI electronically every time it is needed or needs to be confirmed. Simple and cheap for the frequent users.
Your comments about PINs, Smartcards and Easyclaim are all spot on in my view.
David.
DM: I was suggesting it might be useful not to
DM: have to look up the IHI electronically every
DM: time it is needed or needs to be confirmed
My understanding is that once an IHI is embedded in local medical records (that is, a 'known customer' model comes into effect) it wont be looked up against the HI Service on every access, but rather retrieved by practice software from local records.
It's only "new customer" cases (and presumably whatever level of perioidc data quality management the local systems implements) that will cause an IHI retrieval from the HI service.
The scenario in the NEHTA overview document seemed to be a mostly a "new customer" case (injured at work, goes to nearest GP), presumably to provide an opportunity to illustrate the lookup process.
Post a Comment