In parallel with the implementation of the National Health Identifier Service (Hi Service) we have been led to believe there will be implemented a robust individual provider authentication system (termed the National Authentication Service for Health – NASH for short).
The intent of having this authentication service is so that access to the planned HI Service for now, and later for the proposed, but still a bit vague, PCEHR Service, can be robustly controlled and appropriate audit trails put in place to assure public confidence as to who has accessed their private health information and who has modified and update information contained in such a system.
It is clear that without NASH (or some equivalent) this system being available there will be major issues and concerns about how any information leakage or abuse can be properly detected.
From this link you can read what was initially planned for NASH.
http://aushealthit.blogspot.com/2010/03/for-all-those-who-think-it-will-be-easy.html
More recently (AAPP Forum – March 11, 2010) we have been told:
The National Authentication Services for Health (NASH) provides the required strong authentication of healthcare providers and organisations, and is an important foundation service in the developing e-health community.
Establish a national supply of trusted digital credentials available to all entities in the health sector
(Slide 20). Logo of NEHTA, DoHA and IBM at the bottom of the slide.
We are also told (next slide) NASH will:
• Support software vendors to transition their products to use nationally recognised digital certificates;
• Provide sufficient flexibility to leverage investment from organisations such as Medicare Australia; and
• Encompass the current use of PKI by Medicare and in the future National Individual credentials.
• Services will be available to support required functionality of HI Services and Secure Messaging
(Slide 21)
You can review the whole presentation from here (other interesting stuff also):
http://moreassoc.com.au/downloads/AAPP%20Presentation-Forum11-3-10%20vSumm.pdf
For some reason, it does not seem to be on the NEHTA’s web site but it is also here:
http://www.communiogroup.com/aapp/AAPP%20Presentation-Forum11-3-10%20vSumm.pdf
It is not clear why the Communio Group is hosting the file.
Even more interesting when hunting around for hints of progress with NASH I came across brief descriptive resume for a developer of the NASH.
Gil Carter
.....
Previous roles with the National eHealth Transition Authority (NEHTA) included undertaking the development of successful multi-million business case proposing the development of a new smartcard service to be used by doctors when accessing sensitive electronic health information. The NASH program is noted as a key piece of national e-health infrastructure in the National E-Health Strategy (2008) and is leveraged by a number of other e-health programs, including NEHTA's Unique Healthcare Identifiers service.
Gil has been a frequent public presenter on NEHTA and NASH program - e.g., CeBIT (May 2008) and Australian Smartcards Summit (July 2008), Identity Management Summit (Feb 2009).
See here:
http://www.businessaspect.com.au/key-people
So NASH is to be smartcard based, funding for millions has been secured and those who are to use this service (Docs, Nurses and So on) are still in the dark! Additionally a key manager (Gil Carter) in the area seems to have left.
I understand there are upwards of 600,000 professionals and support staff who may need to be issued a smart card. The cost of those cards, checking ID’s and maintaining all the infrastructure – your guess is as good as mine. Even $2 per card + $5 per 10 mins to confirm ID get to close to $5M. Then of course there is the mandatory ‘public information campaign’ at who knows how much
With just one month until the HI Service is meant to start, the chance of any real security around it looks a bit illusory to me.
Just typical is all one can say.
David.
Well the issues are bigger than just HI. The secure messaging standard chose to specify technology that basically excludes the use of Medicare (aka HESA) certificates. The Medicare certificates do not have the key usage that is required for SMD.
ReplyDeleteSo in order to get SMD working smoothly every practice and provider will need to be reissued with Nehta NASH certificates despite being required to obtain Medicare certificates as part of the PIP requirements!!!!
The problem of course is that the Nehta NASH service does not exist and this will be a huge cost and take years to implement.
They were made aware of this during the profile development, but pragmatism is a dirty word it seems.
This is an area where NEHTA is just foolish beyond belief.
ReplyDeleteThere are lots of smartcard projects already happening in Australia and around the world both in healthcare and other industries.
There are international standards at an ISO level governing not only how the cards should work, how they should be used, as well as all the management processes for card issue, certificate issue, reissue, lost cards, revoked certificates etc. There are certification and compliance schemes like FIPS 201 in the US (but mirrored in Europe and elsewhere)
There are dozens and dozens of vendors with proven solutions. There are authorisation services such as standards-based SAML assertions that work off the back of these approaches to provide authorisation and authentication. There are OpenID service providers for authenication.
Yet in a consultation session I attended two years ago, NEHTA's Gil Carter described how NEHTA would design a whole new specification and management framework for the 'unique' requirements of Australian e-health. The only unique aspect is how 'uniquely unqualified' NEHTA is to achieve anything in this area.
Two years later, I'm not surprised Gil is not there, but there's been zero consultation since and from what I hear, NEHTA is still ignoring reality and pressing down the path of a central issued smartcard.
There are only two winners in that circumstance: more money for Medicare and their hoster IBM. Oh, but isn't it curious that IBM is advising NEHTA on all this...
(Incidentally, David, $5m is nowhere near correct. Based on international comparisons, you would need to multiply by at least a factor of 50!. The German smartcard project, which was admittedly for 60 million patients was suspended in June - they had already spent 1.7 Billion Euros.)
What should NEHTA do:
- endorse the ISO standards that already exist and leverage existing frameworks like FIPS. Stop reinventing the wheel
- support a market of authentication providers that can enable federated authentication and authorisation using OpenID, SAML, FIPS models, PKI. Endorse the standards, don't establish a service.
- accept that health jurisdictions, private health providers and internet services are doing and will continue to do their own thing. NEHTA's role should be supporting interoperability, not designing new specifications in ignorance of what already works.
If there needs to be a PKI central authority in their model, it should do no more than a root authority. It definitely should not be issuing certs to health professionals or even worse, trying to issue smartcards.
Australia is not unique. Healthcare does have specific requirements, but international standards in this area are mature. NEHTA's approach towards them and towards the reality of what is already happening in the market is not.
David,
ReplyDeleteMost HI Service accesses will very likely be done using an HPI-O and it's certificate. This will be a soft certificate installed on a server somewhere, not a smart card.
Anonymous, Tuesday, June 01, 2010 4:16:00 PM
The certificate problem was discussed in detail while developing SMD. Unfortunately there was no pragmatic answer that worked for all the development platforms. All the explored solutions had problems. Requiring a new certificate if you wish to host web services seemed the simplest solution. Medicare Location certificates are adequate if you are using a sender or receiver intermediary.
Yup. And that means there will be no individually identifiable audit trail - as has been repeatedly promised to prevent misuse of the HI Service.
ReplyDeleteDavid.