Obviously I could register my web server as a third party web app with an OAuth provider such as Google or Facebook, but I will not know if pharmacists, doctors and senior nurses are still working for Te Whatu Ora, plus, the email addresses associated with an administrator account for the paediatric drug calculator should really be work based. Are there any people I can contact, or programs in place to provide an OAuth authorisation provider service within Te Whatu Ora?
TL;DR
I am writing an upgrade to the paediatric drug calculator, which I first wrote about 13 years ago now in asp.net 3.5. Yes, I still break into a cold sweat at memories of having to support IE6! It still gets about 20K hits/month and is used for the majority of kids admitted in NZ, and a number of units through the South Pacific. In PICU our infusion prescription errors have fallen (basically disappeared) since its introduction - unfortunately prescription errors are only one part of the workflow which sees drugs administered to the patient in the right dose at the right time!
By and large it has been great, but I keep getting requests for new features and it is written in way outdated web technologies. A big part of the calculator (and an even more important part of the rewrite) is the ability to have the drug calculations within a database back end allow different units around the country (i.e. both hospitals and departments within hospitals, such as ED, ICU and paeds departments) to have the calculator print out drugs with which they are familiar.
It stores no patient data (hosted on a server outside Te Toka Tumai) - the patient info can round-trip in a request/response over TLS, but the database purely relates to medications. Users from different departments around the country can log in and adjust things from time to time, as the drugs themselves or protocols for dilution or administration gradually change and evolve. This evolution is a result of a myriad of factors, from Pharmac contracts changing through to implementing advice from adverse event review committees.
Obviously the danger of a malicious actor gaining access is the calculated drug doses could be adjusted to dangerously high or low doses, so solid authentication is important.
What I would like is to hand over authentication via an OAuth 2.0 to a Te Whetu Ora provider with fairly standard functionality - i.e. being able to add claims to a token to manage authorization (there are different roles/levels of authorization and access).
I’ve explored using this for the eHealth Forum as well (thanks @SamuelWong!) but got held up by the investment of time and energy required at the time - the curse of being an early adopter!
Is it to the point where it could be easily implemented here now Sam? Doing it on the Forum could be a great way to get word out about what is an excellent project.
Submit the form or browse the documentation. We will get in touch to work out a plan once but official promotion begins in August to the sector as we are still building out certain areas for Hira
Scoped down the track but not immediately due to getting processes tidied up for the New Zealand Digital Identity Trust Framework accreditation being the focus, which covers human entities only.
Thank you @SamuelWong. I have just been going through the (well written) documentation at
Importantly they state:
we will require evidence of an independent security test at minimum
Which makes sense given NHI and phone numbers can be shared with the integrating party. Unfortunately independent pen tesing is over $10K NZ, and as all I will want is an email (I can verify the domain is from one of the old DHB domains which are still the active domains for Te Whatu Ora employees), this makes this authenication option non viable for my use case, and I suspect this forum as well @NathanK
I am increasingly aware of the common use cases where it is purely being used for IDAM purposes and we need these use cases logged! We will be developing a low risk pathways for certain user groups , but existing documentation is designed for clinical applications or portal/shared care providers.
Your use cases is quite narrow (same with eHealth Forum) so we can make exceptions when we have the latest risk frameworks developed.
I would love any input or thoughts from experts or others with experience out there in OAuth 2.0 workflows. Obviously authentication and authorization workflows have changed over the last decade. There are services available to avoid having to manage and store your own password hashing, storage, email validation, 2FA. From a user perspective, hopefully not having to re-validate email and phone number (for 2FA) for every site used (rather than a few bigger providers) - particularly one like mine where administrators will likely only login every few months, should be easier.
It is not a huge hassle to set up your own identity database and provider in a .net environment, but given the factors above and the trivial cost of some services for a low number of users, I thought I would explore things.
The 2 commercial providers I looked at were Microsoft Entra ID [formerly Azure Active Directory (AD)] and Auth0. It seems to me Auth0 suits my use case because it provides a RESTful APIin addition to the web interface for managing users and roles (Entra ID only seems to have the web interface). It also has an app_metadata field which allows the users hospital and department ID to be added as a claim to the returned token.
I could store the above information in a database backing my web facing application/API and use the user ID to extract this information from that database, but it seems to me to be more intuitive to put it in a claim because:
It is directly responsible for authorizing most CRUD actions. For instance the authorization flow for a PATCH request - would include is the user in the role of department-drug-administrator or hospital-drug-administrator? if so, is this patch request for the same department and/or hospital the authenticated user is working in? By including department-id as a claim, it seems to better fit encapsulation of the concern of authentication workflow.
Less of a concern but the backing database will have to be queried to get this information for every request. In reality it should have more of a session lifetime. I could also encrypt some kind of session token, but that seems to be doubling up work and taking on other security workflows best handed off to our OAuth provider.
The only minor problem is Auth0 doesn’t allow the . character in the field name. This is an issue because I would like to stick to the OAuth standard for claim-types and use something like urn:oid:1.2.840.113556.1.2.141 for the department the user is working in etc.
Although I support the use of less general OAuth providers than Google & Facebook, I’m wondering whether people like myself, who are working outside of New Zealand, for NZ companies in the health sector will face any barriers by using this approach. Or will username/password for the Forum specifically remain a viable alternative.
No need to be concerned re the Forum! It is all about being inclusive, and the DHIS would only be one of many login options. If it becomes highly successful, it might make sense to make it the most heavily promoted login method (and depreciate most other options) - but even in that case we’d leave open an alternative for those who that would exclude.