NEHTA released the following a few days ago:
Certificates and Secure Message Delivery.
Overview
The ATS 5822—2010 — E-Health Secure Message Delivery (SMD) specification requires certificates for several different purposes.
There are many different types of certificates and they cannot all be used in the same way. Different purposes require different features in the certificate.
Some certificates, such as the existing Medicare Location Certificates, can be used for some of these purposes but they are not suitable for other purposes that SMD requires.
The NASH HPI-O Process Certificates are designed to support all the purposes required by SMD. Until these NASH certificates are available, a mixture of different certificates will need to be used to completely support all modes of SMD.
This article describes what types of certificates SMD requires and where existing Medicare Location Certificates can and cannot be used.
…..
What types of certificates are there?
There are different types of certificates and they cannot be used interchangeably. The PKI certificates are defined by X.509v3 and related specifications, but the X.509v3 specification allows for many variations.
For the purposes of SMD, several significant technical differences need to be highlighted:
• What are the technical policies restricting the certificate’s use? Can it be used for performing signing and/or encrypting?
• What additional information is available in the certificate? For example, domain names are needed for Transport Layer Security (TLS) server certificates.
• How is the certificate owner identified in the certificate? For example, does it contain a healthcare identifier?
These are the significant technical differences, but there are also other technical and nontechnical differences between different types of certificates.
What does SMD use certificates for?
The Secure Message Delivery (SMD) specification requires certificates for its digital signing and encrypting operations. An implementation of SMD uses certificates for five different purposes:
• Signing the sealed payload.
Certificates need to be capable of digital signing.
• Encrypting the sealed payload.
Certificates need to be capable of key encipherment.
• TLS server authentication and session establishment.
Certificates should be capable of key encipherment and contain the server’s domain name in the certificate.
• TLS client authentication.
Certificates must be capable of digital signing.
• WS-Security signing and encryption.
Certificates must be capable of both digital signing and key encipherment.
Types of Certificates
Medicare Location Certificates
…..
Commercial Certificates
…..
NASH HPI-O Process Certificates
The NASH HPI-O Process Certificates will be a single certificate that supports both signing and key encipherment. It will also contain the server’s domain name in the certificate along with the owner’s HPI-O number.
Therefore, the NASH HPI-O Process Certificate can be used for all five purposes required by SMD.
The NASH HPI-O Process Certificates identify the healthcare provider organization using their HPI-O number.
Conclusion
SMD has a range of different requirements for the certificates it uses.
The NASH HPI-O Process Certificates will meet all these requirements from SMD. When they become available, it will be possible to use a single certificate with SMD.
In the interim, SMD can be deployed using other certificates (or a combination of several other certificates). Deployments will need to address the deficiencies of these interim certificates: they will need to establish an agreement about which issuers are mutually trusted, how healthcare organizations are identified and how that identifier relates to the certificate.
----- End Extract
The full document can be downloaded from here:
http://www.nehta.gov.au/component/docman/doc_download/1133-certificates-and-smd-v11
Now the document above is dated 28 September, 2010.
However let us now look at the requirements for practitioners to get ePIP payments (from 2008 and compliance being mandatory by July, 2009):
E-health support for general practice
The Practice Incentives Program (ePIP) offers general practices an incentive of up to $50,000 pa to assist in the adoption of e-health technologies. Eligible practices receive $6.50 per Standardised Whole Payment Equivalent (SWPE) as part of the quarterly ePIP payments, capped at $12,500 per quarter.
The incentive is administered by Medicare and was developed in consultation with NEHTA based on the Australian Government's National e-Health Strategy.
Eligibility
There are three eligibility requirements that your practice must meet to receive the E-Health Incentive.
- You must have a secure messaging capability, as provided by an eligible supplier.
- You must have (or have applied for) a location/site Public Key Infrastructure (PKI) certificate for the practice and each branch. You must also ensure that each medical practitioner from your practice has (or has applied for) an individual PKI certificate.
- You must provide practitioners from your practice with access to a range of key electronic clinical resources.
To be eligible for a given quarter, your practice must have met the eligibility requirements during all of the previous quarter and be deemed eligible as of the last day of the previous quarter.
How to apply
You can apply for the E-Health Incentive at any time by completing the E-Health Incentive application form available from Medicare Australia. You can also apply for the E-Health Incentive when you join ePIP by completing the relevant parts of the Practice Incentives Program and General Practice Immunisation Incentive application form.
IT requirements
Requirement 1: Secure messaging
Your practice must have a secure messaging capability that allows patients' clinical and medical information to be securely exchanged. This capability may be a direct extension to your management system or a separate messaging system. The secure messaging capability must be provided by an eligible supplier. Visit the NEHTA website to check if your supplier is an eligible supplier for the purpose of ePIP.
Requirement 2: PKI certificates for the practice and each practitioner
Your practice must have (or have applied for) a location/site PKI certificate. If your practice has additional branches, each branch must have (or have applied for) a separate location/site PKI certificate. Each medical practitioner working at your practice (other than locums) must also have (or have applied for) an individual PKI certificate.
PKI is a combination of policies, procedures and technologies that allows healthcare providers to transmit information and images between computers securely. PKI enables documents to be encrypted prior to sending to ensure that only the intended recipient can read the files, and to be electronically signed to guarantee that documents have not been tampered with. NEHTA has endorsed PKI as the Australian standard for authentication in e-health. It is likely that your practice already uses this technology to securely send claims to Medicare Australia electronically.
It is sufficient to have applied for a PKI to meet this requirement. You do not need to wait until you receive the PKI. Location/site and individual PKI certificates are available at no cost from Medicare Australia. To maintain compliance with Requirement 2, new practitioners who do not already have a PKI certificate must apply to Medicare Australia for an individual PKI certificate within 14 calendar days of joining your practice.
Requirement 3: Access to key electronic clinical resources
You must provide each medical practitioner working at your practice with access to the current editions of a range of key electronic clinical resources intended to improve the level of care you provide. The practice must provide practitioners from the practice with access to at least one electronic clinical resource from each of the following three categories:
- Category 1: Concise, evidence-based guide to recommendations about patient management that covers all common disorders seen in general practice (latest edition) (Example: e-Therapeutic Guidelines Complete)
- Category 2: Formulary of medicines available in Australia that provides comparative drug information reflective of contemporary Australian general practice and is independent of pharmaceutical company involvement (latest edition) (Example: Australian Medicines Handbook)
- Category 3: Evidence-based guide to preventive activities in general practice that is relevant to the Australian population (latest edition) (Example: RACGP - Guidelines for Preventive Activities in General Practice)
At least three resources from any of the following three categories.
- Category 1: Journal of evidence-based clinical care (Examples: Bandolier; Clinical Evidence)
- Category 2: Clinical resources (latest editions) (Example: Immunisation - Myths and Realities; The Australian Immunisation Handbook; Assessing Fitness to Drive)
- Category 3: Regulatory resources (latest editions) (Example: Medicare Benefits Schedule (MBS); Pharmaceutical Benefits Schedule (PBS))
The resources must be available on the computer desktop in the consulting room either on the hard drive, as a CD-ROM, or as a direct link to a website. Practitioners from the practice must be able to explain how they access and use the key electronic clinical resources.
Obligations
If you receive payments under ePIP, you must:
- Be able to substantiate your claims for payments, which may include evidence of: secure messaging capability; PKI certificates for (or application for) each individual medical practitioner working at the practice; a location/site PKI certificate for the practice and each branch; and documentary evidence of the key electronic clinical resources maintained by your practice;
- Provide information to Medicare Australia as part of its ongoing audit program to verify that your practice meets the ePIP eligibility criteria;
- Ensure the information you provide to Medicare Australia is accurate; and
- Notify Medicare Australia in writing within 14 calendar days of any changes that may affect your eligibility for ePIP payments.
On joining the ePIP, your practice must nominate a contact person from the practice, who will be required to verify on behalf of the practice any changes to information submitted for ePIP claims and payments.
Contact
For further information about ePIP, visit the Practice Incentives Program website at Medicare Australia or download the ePIP brochure from the Department of Health and Ageing. For further information on PKI certificates, visit the PKI website.
Download registration forms for individual and location/site PKI certificates.
--- End Extract
The page is found here:
http://www.ehealthinfo.gov.au/healthcare-managers/standards/pip/
So, essentially 18 months after the Individual Certificates were made mandatory they are not even mentioned in a current NEHTA document on Certificates and Secure Messaging - although the recent NASH tender has individual ID management as a requirement.
It is also clear that any streamlined NASH solution is a fair way off. Also just why does the ePIP program insist on individual certificates and then NASH say for Secure Messaging they are not needed for now? I am sure someone will explain it to me.
Rather than picking up the ball and sorting all this out it just seems to be going from ball fumbling to the ball having been dropped.
Also just how we are going to wind up with NASH providing properly secured electronic prescription transmission without using individual prescriber keys and encryption - which is already being paid for - is beyond me. How can one know who has issued a prescription unless it is signed with an individual key - and it seems for a while this will just have to be the Medicare Individual Key and later there will be some sort of transition.
(Unless I have this wrong anyone who can log on to a practice computer, where a location key is installed, and access the prescribing application could, in theory, create a prescription, send it off to a prescription exchange, print off the paper bar coded copy and pick up whatever medicine they wanted. Right now the barriers to that happening do not look all that robust given the password sharing etc. that we know goes on.)
For implementation of a coherent national plan this looks a bit messy to say the least.
You would have thought all those technical experts at NEHTA would have worked this out ages ago and got delivery synchronised with requirements, but it seems not.
David.
7 comments:
It is complex, it is confusing and the vendors who have to deliver this stuff in an easy-to-use trouble-free way will need an enormous amount of support and hand holding to deliver anything which is workable to NEHTAs satisfaction.
What this means is that no vendor who wishes to remain viable will do anything without being paid to do it either by their clients - the medical practices - or by NEHTA or by DOHA, or Medicare.
By being paid to do it, I don't mean 'paid after they have done it' - they have had enough of that. I mean being paid step by step along the way where their overheads and costs in participating in this circus are underwritten regularly and weekly. The only parties who should be exposed and wear the financial risk in all of this are the ones who are responsible for a successful outcome and that is NEHTA, Medicare and DOHA.
I am sure Mr Charles Wright, Ms Karen Dearne, and Dr Mukesh Haikerwal will all agree and hold the same view as you do.
The doctors on the other hand do not care one way or t'other. If it's installed and it works without them having to worry or think about the itty bitty issues fine, no worries, no probs.
If it can't be guaranteed to work perfectly, safely, securely, quickly, transparently, then there is only one think to do - stick it up NEHTAs ....... .
Umm, David, if people can log on to a practice computer and print off a paper copy of a prescription they can already walk into a pharmacy and pick up whatever medicine they want.
(in both the current non-electronic process, and the current eRx/Medisecure process, and the new yet to be implemented NEHTA process, the paper prescription will still have to be presented, and have to be signed by a doctor, and presumably be on suitable PBS paper etc). The signed paper prescription is still the legal prescription document - the electronic stuff is just about improved information flow.
So whether the e-prescribing communications are signed/non-repudiable is almost irrelevant.
If you are talking about one day when we can get rid of the paper entirely then yes, everything will have to be aligned re SMD and NASH and Medicare keys etc. If it happens in the next ten years for community prescribing I'll be amazed.
(I'm not saying the current e-prescribing is not useful - I just think removing the paper is very hard and will need all the base technology such as NASH / SMD / IHI etc to not only be implemented, but ubiquitous and well bedded down - and that isn't going to happen soon for community prescribing). It may happen sooner in specific sectors (hospitals).
Hi Andrew,
I see your point - but if you have a script with a barcode that can call it down from a server..(with a squiggle signature) that is even a bigger fraud opportunity I reckon.
Until there is reasonable end-to-end security in place I am not thrilled and this should have been sorted ages ago!
Cheers
David.
It's worth noting we doctors don't have to write our prescription on any special paper. We can write a script on the back of an envelope if we want and it will still be dispensed; as long as it is written and signed legally ie. by an authorised medical prescriber.
Yeah but if you want access to PBS-subsidised medicines, doesn't it have to be in a certain format and with certain data items present (as dictated by Medicare Australia)? Otherwise, the patient will have to pay the full price...
Anonymous said: "It's worth noting we doctors don't have to write our prescription on any special paper."
This is true for non PBS prescriptions, but for PBS precsriptions, the size and shape of the paper and the layout of the information required on it are dictated by the PBS.
Verifying identity by electronically signing a document, such as a prescription, is quite different from securely transmitting that document.
In theory both individual and organisation (location) certificates will be used. The individual certificate will be used to sign the prescription, referral, etc. The signed document will then be saved locally and transmitted to the recipient (or to a hub for later collection), and to a PCEHR. Encryption for the secure transmission will use the organisation certificate. The organisation certificate is also used to ensure that the recipient organisation is the one intended.
So both (sets of) certificates are required for proper operation. Unfortunately there are a lot of pieces missing for this to be completely implemented, one of which is NASH.
Post a Comment