There have been a couple of articles appear on the NASH Tender and related matters today.
First we have:
Health minister Nicola Roxon says e-health safeguards are in place
- Karen Dearne
- From: The Australian
- September 21, 2010
HEALTH Minister Nicola Roxon has rejected suggestions key patient protections are not yet in place.
The Healthcare Identifiers service went live in July after the rushed passage of new laws in parliament in June.
Doubts emerged about the readiness of the underpinning authentication, secure messaging and audit capabilities when an Audit Office report found GPs had been paid $83 million in the past year to use a messaging standard that did not exist.
GPs also had to obtain digital certificates from Medicare, although these could not be used for authentication purposes.
The auditor found the National E-Health Transition Authority had not finalised the messaging standard until March this year, and Medicare's certificates were designed for electronic claiming only.
Last week NEHTA issued a tender for the National Authentication Service for Health (NASH) -- intended to support the launch of the identifiers service -- admitting the design and build would be done by the private sector.
While Ms Roxon, NEHTA, Health and Medicare officials all pointed to NASH as evidence of stronger security for patient information during consultations on the HI framework, it is unclear whether these protections are in place.
A spokeswoman for Ms Roxon said it was incorrect to suggest the key authentication, secure messaging and audit-trail functions did not exist.
"All necessary capabilities were in place to support the HI service from the outset," she said.
"While originally designed for (business) communication with Medicare, its PKI (public key infrastructure) is appropriate to encrypt messages and provide the required level of security.
"There are already 17,000 Medicare certificates in use, and this supports the tough penalties in the legislation (for misuse of HI information)."
More here:
and second we have:
Smartcard tender issued for National Authentication Service for Health
- Karen Dearne
- From: The Australian
- September 21, 2010
A SMARTCARD and a public key infrastructure tender has been issued for the National Authentication Service for Health.
And NEHTA is "moving on" from problems and delays over the project.
Almost three years after Deloitte recommended the NASH be put to commercial tender, the National E-Health Transition Authority admitted the project was beyond them and preferred partner, Medicare.
NEHTA head of infrastructure services Stephen Johnson said NASH would underpin authentication of users beyond the Healthcare Identifiers service now being established.
More here:
With all this appearing I thought it would be interesting to look at the scope of the actual tender.
Here is the very basic bits of the requirements (Page 14/15 of tender):
3 Statement of Requirements
It is proposed that the NASH project will include three main phases which are design, build, and operate. NEHTA is seeking Tenders which will address each of these phases and provide NEHTA with a fit-for-purpose solution(s).
NEHTA’s conceptual architecture (as depicted in Figure 4 in Section 6.3) proposes a number of Capabilities for the NASH.
NEHTA’s delivery priorities are designing, building and operating the Credential Management Services followed by Token Management Services (including Smartcard build and integration).
It is intended that the end-to-end NASH capabilities will be fully implemented by 30 June 2012.
3.1 Capabilities
These Capabilities are:
The Services Catalogue
The NASH Services Catalogue will publish all Services available in the NASH.
Management and Workflow
The Management and Workflow will manage and co-ordinate all requests from the different services, devices and systems for the provision and management of credentials and tokens.
Credential Management Services
The Credential Management Services will generate and manage NASH credentials including credential types, credential validation and lookup interfaces, credential request and management interfaces, subscribing entity access standards, operating systems, and applications.
Token Management Services
The Token Management Services will be responsible for the personalisation and branding of NASH tokens and support token lifecycle operations including the management of token types, token request and management interfaces, token holder access standards, operating systems and applications.
Identity Management Services
The Identity Management Services will manage the authentication of every participant within the NASH Communities of Interest who accesses the NASH Services.
Fulfilment Services
The Fulfilment Services will be responsible for the despatch and delivery of NASH credentials, tokens and token readers.
Reporting and Audit Services
The Reporting and Audit Services will provide internal and external billing and management reporting, compliance and audit capabilities for the NASH Services; and
Service Desk
The Service Desk will provide a centralised helpdesk and support functions for participants within the NASH Communities of Interest.
Tenderers are invited to submit Tenders for provision to NEHTA of one or more of the phases and/or Capabilities:
1. Design – is the activity that defines the components that will be built and implemented to meet the requirements of the NASH;
2. Build – is the activity that creates and constructs the authentication services that will be operated; and
3. Operate – is the activity that includes the day-to-day operation and management of the NASH including the supply of secure tokens and supporting infrastructure.
The full list of detailed functional, technical and non-functional requirements for these phases and Capabilities is included in Sections 6 and 7 of this document.
---- End Extract.
Also important is this table:
Appendix D: Demand Forecast
The following tables provide an estimate of the number of Subordinate Certification Authorities, Subscribing Entities, Credentials, and Secure Tokens that will be required over the first five years of NASH operations.
Table 6 is based on the number of new entities that will join NASH each year and the following assumptions:
1. Each subscribing entity will be issued with a single secure token that contains two credentials. It will be possible for subscribing entities to be issued with credentials only but this use case has not been specifically included as it seen as a minor use case so far as creating demand for credentials is concerned;
2. Each year 10% of the tokens, and credentials, in circulation from the previous years will need to be replaced due to loss, theft, or malfunction;
3. Tokens are expected to have a lifetime in excess of five years; and
4. Credentials will have a lifetime of five years.
Table 7 provides the cumulative totals for each year of operation. This includes an estimate of the number of times a day a relying party may wish to obtain the public key certificate of and/or validate the status of a credential. Tenderers should prepare cost estimates based on the following but keep in mind that actual demand may differ significantly from the estimates provided.
----- End Extract
The tables (which are a bit hard to reproduce on the blog) show the following over a 5 year period - which presumably begins once the system is operational from ‘end to end’ in June 2012 - runs over 5 years and shows:
Subscribing Entities rising from 5,000 to 250,000
Credentials Managed rising from 10,000 to 500,000
Subordinate Certification Authorities rising to 5 from 0.
Transactions rising from 50,000 per day to 5,005,000 per day.
If you take a moment to read the capabilities at 3.1 you will see this is really a ‘gigantic’ national project which will be ramped up over 5 years and which will presumably then grow to being able to provide credentials and authentication for pretty much all professional health sector staff.
Just how much nonsense was provided to the Australian by Ms Roxon’s spokeswoman is obvious when you think to ask the question that ‘if Medicare PKI is good enough, just why is such a huge project necessary?’
The answer is obvious. What is in place for the HI Service is only good enough while essentially no-one is using it! I do recognise NASH will assist other areas but we are repeatedly told the HI Service is foundational.
I look forward to knowing just what NEHTA has budgeted for delivery and maintenance and just where these funds are coming from! I anticipate a little ‘sticker shock’ when the tenders are delivered.
One area of special interest, it is by no means clear how this service it to be integrated into the various applications that might want to use the credentials.
Additionally the governance proposed by NEHTA does not seem to recognise this is just a component of a much larger set of e-Health services which need overall, inclusive governance. general.
I have a very bad feeling about this whole endeavour - as it seems rather grandiose and overarching - again without a clear public cost benefit and business case being available so some rational assessment of just where we are heading and what we are letting ourselves in for.
I hope a full spectrum of overseas approaches to ‘skinning this cat’ have been explored before this tender was let out the door - or that the prospective tenders will steer things in minimally risky directions.
We shall all see I guess!
David.
16 comments:
Just how much nonsense was provided to this blog's readers is obvious when you think to ask the question "Does Medicare PKI work with SMD?"
Medicare PKI is NOT good enough is why such a project necessary.
They work with themselves but not with each other - now isn't that the whole point!?!
They work with themselves but not with each other! - now that's the whole point isn't it!?!
This prompts another Question...
"Why wasn't SMD designed to work with Medicare PKI when Nehta presumably knew that NASH was a speck on the horizon"
Its not as if it couldn't be designed to work with Medicare PKI, but Nehta forced it to be dependant on NASH.
SMD is now also a speck on the Horizon thanks to Nehta.
And if NEHTA was competent why would they not have worked to get the current providers working together rather than pushing on to replace them commercially - as is their announced policy?
David.
So how come Argus, Healthlink and Medical Objects and others Secure Messaging works so well with no NASH? Not perfect - but delivering a fair bit and could be developed and refined.
I think the question is "where are the arguments for doing this huge project exposed to the 'sunlight' of public review and discussion"?
David.
All reading this need to recognise what a huge and technically risky national project this actually is. It is technically and culturally pretty enormous!
With no real business case, cost benefit assessment, serious public discussion and so on one has to remain skeptical.
The HI Service started July 1, 2010. And what has anyone seen of it since then?
David.
Ah well, everything must seem huge from the armchair there. Rest of the us can get on with what the rest of the world just does with security.
Last I checked, the N in NASH standards for NATIONAL not your home office.
It's a little amusing to hear Medicare trying to pretend that the Medicare PKI was never intended for clinical data when the Electronic Transaction act (up until 2009) specified it as the only valid PKI to authenticate clinical referrals. So its role was actually specified in legislation!
There are some serious attempts to rewrite history going on here. What exactly have Nehta managed to get right, I am happy to be shown some of their work out there and in active use, but I am struggling to find anything.
During the SMD meetings Medical-Objects attempted to push for a solution that worked with the Medicare PKI and we are using both the Site Certificates and Individual PKI keys every day to deliver/sign clinical data now. Its possible to automate this using the Medicare LDAP server and this is what we do.
Medicare not only provides a PKI Infrastructure, but a PKI library and the whole SMD infrastructure is over-engineered to satisfy Nehta's pipe dreams. A Rest/PKCS-7 based specification using HL7V2 as the messaging format (It is designed for that after all) would support and the clinical use cases and also support CDA with ease.
Instead we have bloated SOAP/xml Encryption and usage that requires new certificate usage (ie NASH) which would seem to be years away.
I am annoyed that we wasted time and opportunity developing a specification that depended on something that Nehta must have known was in deep strife. It's like removing a patients heart in the hope a donor organ will magically appear before the patient dies on the table.
SMD depends on having automated access to certificates with the correct attributes and any workarounds will be clumsy and not scalable. It's also not acceptable to send data off over the internet to third parties unless you have a solid Certification Authority, which is now back in the planning stages.
It's not a situation that is acceptable for the supposed "NATIONAL" NASH, David's assessment is correct.
What? ATS 5820-2010 has no mention of NASH...the standard refers to industry standard x509.
Sounds more like a soap vs rest geekfest argument. :)
This comes from the act so you have the wrong document:
"c) Be digitally signed by the referring/requesting practitioner using an individual
private key for which there is a current public key certificate recognised by the
HIC (in accordance with HIC’s PKI standards), to allow a specialist,
consultant physician, or Approved Pathology Practitioner or medical
practitioner to verify the authenticity of the Referral or Request upon receipt."
Where in SMD (the ATS doc) does it exclude the use of Medicare provided certificates?
David
You are perennially narrow in your view and lack the breadth to consider that you might, just might, be off the mark with all of this.
TT
And your qualifications to put this view are?
Just what do you think I need more information on..maybe you can provide it?
David.
During the industry meetings that developed SMD, every time the issue of certificates was raised there were assurances that NASH would be ready. Either that, or some other solution would be available.
At one meeting we were even given a presentation by someone from NASH who said real soon now. That was almost a year ago.
Post a Comment