We have had the release of two documents last week which are really quite important (and one of which needs to be responded to by June 28, 2010).
See here for an Implementation Approach (This needs a response):
http://www.nehta.gov.au/component/docman/doc_download/1012-hi-service-implementation-approach
And here for the Communication Plan:
http://www.nehta.gov.au/component/docman/doc_download/1011-hi-service-communication-plans
The real core of what is contained in the 45 page document is in 2 sections (Page 14-15):
SECTION TWO
2. How will the HI Service be implemented?
Healthcare providers in both the private and public sector have made significant investments in technology over the past 20 years. Australian governments have agreed that any national program must recognise this investment and build on existing systems.
The HI Service will:
• Assign healthcare identifiers to individuals, healthcare providers and organisations to make sure that all can be consistently identified;
• Develop and operate a Healthcare Provider Directory to facilitate electronic communication between providers by enabling them to look up the contact details of other providers, either directly or through a local services directory;
• Support the implementation of a security and access framework to ensure the appropriate authorisation and authentication of healthcare providers who access national e-health infrastructure, including the HI Service; and
• Support secure messaging from one healthcare provider to another by providing a consistent identifier that can be used in e-communication.
A number of service channels are being established for both individuals and providers to access the HI Service. Medicare Australia as the initial HI Service Operator has several existing channels that can be leveraged; however, there will be separation between the Medicare payment system and the HI Service system.
Healthcare providers (individuals and organisations) will be able to look up or enquire about identifiers from the HI Service via a secure business-to-business web service, a secure web portal or telephone. Individuals will also be able to access their own information held by the HI Service through a web portal, by telephone or face-to- face.
Identifiers will be automatically assigned by the HI Service Operator to all individuals enrolled in Medicare Australia’s and Department of Veterans’ Affairs (DVA) programs. Those not enrolled with Medicare Australia or the DVA can be provided with a temporary (unverified) IHI when they seek healthcare, and can choose to validate (verify) this number through the HI Service by providing sufficient demographic information to ensure the IHI is uniquely assigned to that individual.
Individual healthcare providers will be issued with either a HPI-I as part of their professional registration process (for example, through the Australian Healthcare Practitioner Registration Authority) or obtain one directly from the HI Service.
Healthcare organisations will need to apply directly to the HI Service Operator to be issued with a HPI-O.
Healthcare identifiers are designed to improve information management and communication in the delivery of healthcare and related services. While identifiers are designed primarily for these purposes, there will also be benefits in using the identifiers for other health-related purposes such as health research and management of health services, which would improve the timeliness and accuracy of such activities. These additional purposes will be specified in the proposed healthcare identifiers legislation and will be permitted only in accordance with strict protocols and guidelines.
----- End Extract.
And here:
2.2 How will the health sector adopt and use identifiers?
The use of HIs will be adopted by the market in an evolutionary way to support strategic initiatives and priorities at the national, state and territory level including for example, medications management, discharge summaries, and referrals, as well as a future personally controlled electronic health record. Identifiers may be used for internal clinical purposes as well as for information exchange. There will be different drivers across the healthcare sector. Most healthcare organisations will ultimately only adopt identifiers when their systems are able to support them and if they see value in making the change.
A government-run service will issue and maintain a unique identifier for every healthcare recipient and healthcare provider. Supporting standards are being developed with Standards Australia through the IT-014 Health Informatics Committee and at a practice level through the Australian Commission on Safety and Quality in Healthcare.
NEHTA and governments will support strategic projects to move toward the ‘tipping point’ where most healthcare communications include identifiers. Clinical repository projects for public hospitals, discharge summary transmission projects between hospitals and GPs, and inter-jurisdictional transfers are examples of initiatives that will implement healthcare identifiers in key functions.
----- End Extract
The waffle and impracticality of all this is just amazing.
First it is clear there will be no secure provider authentication (NASH) any time soon.
Second it is clear no one has put together the set of compelling reasons for providers to use the identifiers and take the time, cost and trouble associated. All we get is waffle on this point.
Third it will be a good 12 months before seamless access to the HI Service from practice computers will be available. Once it is every practice staff member will need an individual identifier and some form of token for access to be properly managed and authenticated. How long this will take is anyone’s guess.
For all this to be made to work there need to be some pilot, incentivised implementations where all the moving parts (communications, modified software, authentication and so on) are brought together, made to work, and implemented as a package which can then be evaluated.
Once pilots are successfully shown to work, not be too onerous and offer benefit then a phased national roll out makes sense. Until then they are ‘whistling in the wind’.
The approach of doing one bit here and another bit there as seems to be planned is just ridiculous in my view! There is just no value in this sort of approach.
I am not sure which planet the authors of this document reside but it is not Earth in the year 2010.
For any real adoption to happen there has to be a compelling reason (or incentive) to do so and a seamless, fully complete and smoothly operational system available for easy installation and use by providers. Without this the whole thing will be a fiasco.
David.
Late Addition:
There is a bit of chatter in the document about the UK NHS Number. This might help.
http://www.nhs.uk/chq/Pages/897.aspx?CategoryID=68&SubCategoryID=162
How do I find out my NHS number?
All babies born in England and Wales are given an NHS Number at birth. Other people need to officially join the NHS to get an NHS number. You can do this by:
- approaching an NHS GP surgery, or health centre, and asking to permanently join their surgery list,
- contacting a Primary Care Trust (PCT) who will place you on a local NHS GP surgery list, or
- being treated at an NHS hospital that is able to allocate NHS numbers.
Your NHS number is printed on your medical card (FP4). However, if you have a medical card that is more than eight years old, it may show your old NHS number. The new number is 10 digits long.
Your NHS number is written on your medical history notes, so to find out what it is, you can simply ask your GP, or contact your local Primary Care Trust (PCT).
To get a new medical card and NHS Number, you will also need to contact your local PCT. See 'further information' to find the contact details of your local PCT.
When registering for your new medical card and NHS number, you will be asked for your name, date of birth, and the name of your GP. You may also be asked to confirm selected personal details in order to verify your identity.
The information that you provide will be treated confidentially and the PCT will not give out any personal information over the telephone. It will usually take about two working days for your new medical card to be issued.
---- End Extract.
As you can see the NHS Number is provided to patients printed on a card! Hardly the electronic service almost implied in the NEHTA documentation – the electronic system is an internal one for the providers and care trusts. Just so we are all clear on that! A reminder that there are many ways to skin the cat!
D.
10 comments:
In all the discussion of health identifiers, I haven't heard any remarks about the practicality of the numbers itself (both from a usage and a technical implementation perspective).
From what I understand:
Each patient will have one 16-digit number
Each provider will have one 16-digit organisation number and one 16-digit individual identifier.
So a couple of issues we have:
>>>Most importantly, isn't that going to be hugely confusing and dangerous? Three numbers that are very long and look very similar supposed to appear in close proximity on every document. Sure, computers can do checksums and validation to prevent using the wrong number, but people don't do that kind of mental gymnastics.
Am I the only one who thinks this will cause lots of mistakes and difficulty for patients and clinicians?
>>>On a more technical level, we use int (32-bit) data types for identifiers in our system, feeding into the user interface, reports, etc. They can happily deal with 9-digit identifiers.
16-digit numbers will require 64-bit integers (not suggesting we need to run on 64-bit operating systems though) but we will need to change everywhere in our system where we use number-based identifiers from using int to now using long. That's throughout our system, not just in the adapter to the secure messaging system, but also in all our business logic, user interface, database, etc. That's a lot of work!
(We could move to 'string' identifiers but that would mean our queries, and hence our overall system performance, would work a lot slower as databases don't perform very will with string-based indexes)
Do we really need 64-bit identifiers, when 32-bit could have dealt with 9 digit identifiers easily. Last time I looked we had less than 1 billion patients in Australia!
We have a moderately old clinical system, but certainly not a legacy one. Won't this be a big problem for other vendors as well as for all those old systems out there that have been custom-built. A large part of our codebase was in C++ which didn't even support 64-bit integers when it was first written. Now we use C# which does support 64-bit integers, so it's not a problem for new code, but there's a huge amount of internal reengineering to do to incorporate this.
Where did the idea of 16-digit identifiers come from - Is it an existing standard? Has the practicality of re-engineering older systems to deal with them been investigated by NETHA or anyone else?
I recall attending a workshop conducted by the Victorian DHS in Nov 2008, on the now defunct CareDirect initiative, where the issue of the organisation/provider identifiers was raised. It occurred to me that replacing the existing GP provider number with a 33-digit (including a hyphen) identifier would have a major impact in ways we couldn't imagine.
I posed the question about the workflow implications of the change and it was clear that people in attendance hadn't given this much thought. I followed up with a suggestion that GPs might need larger business cards. (My effort to lighten the mood didn't work).
Anonymous raises a number of practical difficulties, some of which don't apply. Firstly, patients are not expected to remember or quote, or write down their IHI. The HI service allows providers to input name, gender, date of birth and receive back the IHI for that patient which is subsequently attached to information relating to that person. I can see some problems with spelling variations, wrong birth dates etc. But folk should never need to be typing in 16 digit numbers. Then there are the issues about the length of the number and 32-bit arithmetic. These are the sort of issues which should not be permitted to compromise the design of a new system. If you design for the oldest least-capable system inexistence today you just get a dog. Then the old systems are decommissioned and you have a dog for no good reason! You need eight or nine digits before you add any error-checking or structure (eg a class of "temporary" IHIs for visitors etc.) So the absolute minimum size is probably 12 digits, and 16 is not unreasonable. Older systems which are seriously challenged by an index of this size might employ an internal mapping function to a 32-bit variable, but I suspect that most systems will work with the 64-bit quantities. The real problems, as David mentions in various blog articles, have to do with getting the various services designed, debugged, tested and rolled out in a way that they can begin to deliver the potential benefits.
David,
You said: "... Once [seamless access] is [implemented] every practice staff member will need an individual identifier and some form of token for access to be properly managed and authenticated. ..."
You have made assumptions about the number of people who will need to obtain the IHI. I do not think your assumptions are valid.
The HI Service is likely to only be accessed by a small number of people in a practice who will be responsible for making sure it is on the patient's file. This will likely be the receptionists or the practice manager. Once it is on a patient's file there is no need for anyone else in the practice to access it.
I disagree. As I read it the Concept of Operations documents make it clear all look up it to be undertaken by authenticated providers. I have yet to see any plan for registration and authentication of receptionists and practice mangers so they can access the HI Service.
The National Registration Scheme does not cover these people as far as I know.
More importantly, if they are to do this, who has seen the plan for paying for the receptionist / practice manager time to manage all this? Or the other providers for that matter?
David.
Q25. How will an individual’s information be protected?
...
Healthcare providers who are identified with an individual HPI-I, or an authorised employee, can access the HI Service to obtain the IHI of a patient being treated.
http://www.health.gov.au/internet/main/publishing.nsf/Content/pacd-ehealth-consultation-faqs
And the employee authorisation is proven how?
We were promised there would be audit trails to assist in abuse prevention and detection. That can't work unless each individual access is some how authenticated by an authenticated provider or is a credible audit trail just spin?
David.
To the first anonymous poster re standards. The HI service has based its numbering system on a variant of the ISO 7812 standard, used for (amongst other things) credit card numbers.
See http://en.wikipedia.org/wiki/ISO/IEC_7812
This is not a bad choice in a vacuum, but does break compatibility with every other known health identifier system...
Just one of many "interesting decisions" made in building the HI service.
not just credit cards, health cards... (see ISO 20301)
7812 normative reference.
The checksum for electronic funds transfer is a single digit based on modulo arithmetic. For a number a1a2a3a4a5a6a7a8a9, the formula is
3a1 + 7a2 + a3 + 3a4 + 7a5 + a6 + 3a7 + 7 a8 + a9 mod 10 = 0
There are more complex (and yes, more precise at error detection) checksum algorithms that require more than 9 digits in total, but your correspondent of 11:30AM is not quite correct in the assertion that a minimum of 12 digits is required.
Also incorrect: "employ an internal mapping function to a 32-bit variable, but I suspect that most systems will work with the 64-bit quantities". Mathematics doesn't work like that. A 16 digit number can be decomposed to 2 x 8 digit numbers, but a 16 digit number cannot be 'mapped' to an 8 digit number without some loss of integrity. The exception to this would be if it could be assumed that the first 8 digits are invariant.
In any case, if one were to map the 16-digit integer to 2x8 digit numbers, that would then result in an index that would have to be recomposed for querying a database, interpretation, comparison or display. That results in just as much work as reengineering an application to transition from 32-bit to 64-bit integers.
There's no easy way to handle this transition if not already catered for in the existing system. Agree that design, testing, rollout etc are significant challenges but they are at a macro level. Micro-level issues in software engineering are often overlooked though and can have very significant ramifications. Just think of Y2K.
Agree IEC 7812 is probably the right standard to adopt and it's reference in ISO20301 confirms that.
But certainly, one should not understimate there is a lot of work ahead for many software vendors and existing legacy systems out there to incorporate these identifiers
Post a Comment