Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DicomWebClient should be more explicit about the serviceUrlPrefix #86

Open
dzelemba opened this issue Jun 19, 2020 · 1 comment
Open
Labels
code cleanup p3 Priority: Issue with HCLS products with easy work around

Comments

@dzelemba
Copy link
Contributor

Sometimes this value contains just the base healthcare URL (e.g. https://healthcare.googleapis.com/v1 for the export adapter), sometimes it also includes the datastore path (https://healthcare.googleapis.com/v1/project/..../dicomStores/blah/dicomWeb) and sometimes it's the full STOW URL. This makes the code hard to read and understand.

@dzelemba dzelemba added p3 Priority: Issue with HCLS products with easy work around code cleanup labels Jun 19, 2020
@danielbeaudreau
Copy link
Collaborator

Specifically what we can do here to make the dicomweb client always consume the dicomweb address:

  • Truncate "/studies" from the legacy stow path, and pass it in as the dicomweb path, so that the dicomweb client can now treat the two as the same.
  • For the export adapter, only initialize a new dicomweb client when we have the complete address from the pubsub message + healthcare API flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code cleanup p3 Priority: Issue with HCLS products with easy work around
Projects
None yet
Development

No branches or pull requests

2 participants