The correct answer would be no. Not in an out-of-the-box implementation of cTAKES. Leaving a trail of our usage of UMLS is one of the factors contributing to its very existence. If it seemed as if no-one were using these validation APIs at UMLS - it would give ammunition to the budget cutters.
You can do more-or-less whatever you want with software, so it is an ethical question as much as a technical one. An implementation such as ours has to go to some extra lengths to obtain a user's credentials because the cTakes service is buried inside a PHI sensitive zone that has no cloud-facing ports. But still, we do it. Peter On Thu, Sep 24, 2020 at 2:13 PM Akram <as...@yahoo.com.invalid> wrote: > Thanks Peter, > Is there a way we can use cTAKES completely offline? > I mean we can download whatever we need from UMLS and use it as datasource > locally in our computers? > > > > On Thursday, 24 September 2020, 02:02:15 pm GMT-7, Peter Abramowitsch < > pabramowit...@gmail.com> wrote: > > Hi All > > I managed to have a conversation with Patrick McLaughlin who's in charge of > the Authentication changes at UMLS. I have some updates for you which I > think you will find reassuring. > > He's familiar with cTAKES but hasn't used it personally, nor was very > familiar with the different ways it could be deployed and its > authentication requirements. > > To boil the conversation down to a few key points: > > They want to get out of the business of forgotten password and username > management. but they are still creating individual user accounts and > accounts for content providers. > > There are two routes to authenticating and I think the far simpler one for > traditional cTAKES users will be that of using API keys instead of an > external Authentication service. Strangely enough, I had to ask Patrick > about it since it is not mentioned on their recent emails to our > community. So I'll describe that approach first: > > API_KEY Method. > > Our individual user accounts do and will still have an API key created for > them and you can authenticate with the API key instead of username-password > to get an access token with a specific TTL. (a surrogate for yes/no > authentication) So cTAKES will need some relatively trivial changes to > accept an API key in the usual places (EnvVar, System Property, or > Piperfile) and then make the appropriate request with that key. > > I'm using the alternate authentication URL property so I can relay requests > through a proxy authenticator, but it will forward API keys just as cTakes' > new code should do. So whoever makes these changes - please don't remove > the modifiable system property > * ctakes.umlsaddr !!* > > What the UTS will want, though, is the domain name from which the API > bearing Token request will come, so they can whitelist it. > > If you have no UMLS license yet, you will go to the UTS as usual to apply > and from there, you will be given the choice of several external sources of > identity verification. Here's where external authentication will come into > play (using Google Auth, Facebook, Login.gov etc): Once you've passed that > step, you'll get the user account and an API key. > > If you already have a UMLS license and are using the username password > paradigm, when the cTAKES fix is out, go back to your UTS profile and find > your API key. > > SECOND OPTION > (after your license is updated or newly established with whitelist & > callback info) > > If you are architecting an implementation where ad-hoc users authenticate > for one-off interactions with cTakes through a website or directly with the > UMLS metathesaurus via its APIs, the implementation will involve something > more complicated. You will need to implement a publicly visible web > service or callback-link on your site. > > Your authentication request will go out, probably with an email address and > will be forwarded by UTS to your authenticator of choice (whomever you > specified when creating your license) > > Asynchronously, the UTS will call back on your registered URL which your > application will be listening for to give you approval or rejection. This > would unblock access to cTAKES or the website behind which you've deployed > it. > > So you see that this method is not really suitable for situations where > cTAKES is used as a console app or a dedicated web-service, possibly > situated deep within a protected PHI safe zone. In this setting a > Synchronous authentication approach using the API_KEY would be simpler from > every angle. > > If I haven't been clear enough or you still have questions, call Patrick. > He's very open to working with us > > Peter >
