mario/ohif-viewer
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
mario
2025-03-07 13:47:44 +07:00
commit c4efec5a14
3358 changed files with 303774 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
platform/docs/versioned_docs/version-3.8/configuration/_category_.json Normal file
View File

@@ -0,0 +1,4 @@
{
"label": "Configuration",
"position": 4
}

334
platform/docs/versioned_docs/version-3.8/configuration/configurationFiles.md Normal file
View File

@@ -0,0 +1,334 @@
---
sidebar_position: 1
sidebar_label: Configuration Files
---
# Config files
After following the steps outlined in
[Getting Started](./../development/getting-started.md), you'll notice that the
OHIF Viewer has data for several studies and their images. You didn't add this
data, so where is it coming from?
By default, the viewer is configured to connect to a Amazon S3 bucket that is hosting
a Static WADO server (see [Static WADO DICOMWeb](https://github.com/RadicalImaging/static-dicomweb)).
By default we use `default.js` for the configuration file. You can change this by setting the `APP_CONFIG` environment variable
and select other options such as `config/local_orthanc.js` or `config/google.js`.
## Configuration Files
The configuration for our viewer is in the `<root>platform/app/public/config`
directory. Our build process knows which configuration file to use based on the
`APP_CONFIG` environment variable. By default, its value is
[`config/default.js`][default-config]. The majority of the viewer's features,
and registered extension's features, are configured using this file.
The simplest way is to update the existing default config:
```js title="platform/app/public/config/default.js"
window.config = {
routerBasename: '/',
extensions: [],
modes: [],
showStudyList: true,
dataSources: [
{
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
sourceName: 'dicomweb',
configuration: {
friendlyName: 'dcmjs DICOMWeb Server',
name: 'DCM4CHEE',
wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
qidoSupportsIncludeField: true,
supportsReject: true,
imageRendering: 'wadors',
thumbnailRendering: 'wadors',
enableStudyLazyLoad: true,
supportsFuzzyMatching: true,
supportsWildcard: true,
omitQuotationForMultipartRequest: true,
},
},
],
defaultDataSourceName: 'dicomweb',
};
```
> As you can see a new change in `OHIF-v3` is the addition of `dataSources`. You
> can build your own datasource and map it to the internal data structure of
> OHIF’s > metadata and enjoy using other peoples developed mode on your own
> data!
>
> You can read more about data sources at
> [Data Source section in Modes](../platform/modes/index.md)
The configuration can also be written as a JS Function in case you need to
inject dependencies like external services:
```js
window.config = ({ servicesManager } = {}) => {
const { UIDialogService } = servicesManager.services;
return {
cornerstoneExtensionConfig: {
tools: {
ArrowAnnotate: {
configuration: {
getTextCallback: (callback, eventDetails) => UIDialogService.create({...
}
}
},
},
routerBasename: '/',
dataSources: [
{
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
sourceName: 'dicomweb',
configuration: {
friendlyName: 'dcmjs DICOMWeb Server',
name: 'DCM4CHEE',
wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
qidoSupportsIncludeField: true,
supportsReject: true,
imageRendering: 'wadors',
thumbnailRendering: 'wadors',
enableStudyLazyLoad: true,
supportsFuzzyMatching: true,
supportsWildcard: true,
omitQuotationForMultipartRequest: true,
},
},
],
defaultDataSourceName: 'dicomweb',
};
};
```
## Configuration Options
Here are a list of some options available:
- `disableEditing`: If true, it disables editing in OHIF, hiding edit buttons in segmentation
panel and locking already stored measurements.
- `maxNumberOfWebWorkers`: The maximum number of web workers to use for
decoding. Defaults to minimum of `navigator.hardwareConcurrency` and
what is specified by `maxNumberOfWebWorkers`. Some windows machines require smaller values.
- `acceptHeader` : accept header to request specific dicom transfer syntax ex : [ 'multipart/related; type=image/jls; q=1', 'multipart/related; type=application/octet-stream; q=0.1' ]
- `investigationalUseDialog`: This should contain an object with `option` value, it can be either `always` which always shows the dialog once per session, `never` which never shows the dialog, or `configure` which shows the dialog once and won't show it again until a set number of days defined by the user, if it's set to configure, you are required to add an additional property `days` which is the number of days to wait before showing the dialog again.
- `groupEnabledModesFirst`: boolean, if set to true, all valid modes for the study get grouped together first, then the rest of the modes. If false, all modes are shown in the order they are defined in the configuration.
- `showPatientInfo`: string, if set to 'visible', the patient info header will be shown and its initial state is expanded. If set to 'visibleCollapsed', the patient info header will be shown but it's initial state is collapsed. If set to 'disabled', the patient info header will never be shown, and if set to 'visibleReadOnly', the patient info header will be shown and always expanded.
- `requestTransferSyntaxUID` : Request a specific Transfer syntax from dicom web server ex: 1.2.840.10008.1.2.4.80 (applied only if acceptHeader is not set)
- `omitQuotationForMultipartRequest`: Some servers (e.g., .NET) require the `multipart/related` request to be sent without quotation marks. Defaults to `false`. If your server doesn't require this, then setting this flag to `true` might improve performance (by removing the need for preflight requests). Also note that
if auth headers are used, a preflight request is required.
- `maxNumRequests`: The maximum number of requests to allow in parallel. It is an object with keys of `interaction`, `thumbnail`, and `prefetch`. You can specify a specific number for each type.
- `modesConfiguration`: Allows overriding modes configuration.
- Example config:
```js
modesConfiguration: {
'@ohif/mode-longitudinal': {
displayName: 'Custom Name',
routeName: 'customRouteName',
routes: [
{
path: 'customPath',
layoutTemplate: () => {
/** Custom Layout */
return {
id: ohif.layout,
props: {
leftPanels: [tracked.thumbnailList],
rightPanels: [dicomSeg.panel, tracked.measurements],
rightPanelClosed: true,
viewports: [
{
namespace: tracked.viewport,
displaySetsToDisplay: [ohif.sopClassHandler],
},
],
},
};
},
},
],
}
},
```
Note: Although the mode configuration is passed to the mode factory function, it is up to the particular mode itself if its going to use it to allow overwriting its original configuration e.g.
```js
function modeFactory({ modeConfiguration }) {
return {
id,
routeName: 'viewer',
displayName: 'Basic Viewer',
...
onModeEnter: ({ servicesManager, extensionManager, commandsManager }) => {
...
},
/**
* This mode allows its configuration to be overwritten by
* destructuring the modeConfiguration value from the mode fatory function
* at the end of the mode configuration definition.
*/
...modeConfiguration,
};
}
```
- `showLoadingIndicator`: (default to true), if set to false, the loading indicator will not be shown when navigating between studies.
- `useNorm16Texture`: (default to false), if set to true, it will use 16 bit data type for the image data wherever possible which has
significant impact on reducing the memory usage. However, the 16Bit textures require EXT_texture_norm16 extension in webGL 2.0 (you can check if you have it here https://webglreport.com/?v=2). In addition to the extension, there are reported problems for Intel Macs that might cause the viewer to crash. In summary, it is great a configuration if you have support for it.
- `useSharedArrayBuffer` (default to 'TRUE', options: 'AUTO', 'FALSE', 'TRUE', note that these are strings), for volume loading we use sharedArrayBuffer to be able to
load the volume progressively as the data arrives (each webworker has the shared buffer and can write to it). However, there might be certain environments that do not support sharedArrayBuffer. In that case, you can set this flag to false and the viewer will use the regular arrayBuffer which might be slower for large volume loading.
- `supportsWildcard`: (default to false), if set to true, the datasource will support wildcard matching for patient name and patient id.
- `allowMultiSelectExport`: (default to false), if set to true, the user will be able to select the datasource to export the report to.
- `activateViewportBeforeInteraction`: (default to true), if set to false, tools can be used directly without the need to click and activate the viewport.
- `autoPlayCine`: (default to false), if set to true, data sets with the DICOM frame time tag (i.e. (0018,1063)) will auto play when displayed
- `addWindowLevelActionMenu`: (default to true), if set to false, the window level action menu item is NOT added to the viewport action corners
- `dangerouslyUseDynamicConfig`: Dynamic config allows user to pass `configUrl` query string. This allows to load config without recompiling application. If the `configUrl` query string is passed, the worklist and modes will load from the referenced json rather than the default .env config. If there is no `configUrl` path provided, the default behaviour is used and there should not be any deviation from current user experience.<br/>
Points to consider while using `dangerouslyUseDynamicConfig`:<br/>
- User have to enable this feature by setting `dangerouslyUseDynamicConfig.enabled:true`. By default it is `false`.
- Regex helps to avoid easy exploit. Default is `/.*/`. Setup your own regex to choose a specific source of configuration only.
- System administrators can return `cross-origin: same-origin` with OHIF files to disallow any loading from other origin. It will block read access to resources loaded from a different origin to avoid potential attack vector.
- Example config:
```js
dangerouslyUseDynamicConfig: {
enabled: false,
regex: /.*/
}
```
> Example 1, to allow numbers and letters in an absolute or sub-path only.<br/>
`regex: /(0-9A-Za-z.]+)(\/[0-9A-Za-z.]+)*/`<br/>
Example 2, to restricts to either hosptial.com or othersite.com.<br/>
`regex: /(https:\/\/hospital.com(\/[0-9A-Za-z.]+)*)|(https:\/\/othersite.com(\/[0-9A-Za-z.]+)*)/` <br/>
Example usage:<br/>
`http://localhost:3000/?configUrl=http://localhost:3000/config/example.json`<br/>
- `onConfiguration`: Currently only available for DicomWebDataSource, this option allows the interception of the data source configuration for dynamic values e.g. values coming from url params or query params. Here is an example of building the dicomweb datasource configuration object with values that are based on the route url params:
```
{
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
sourceName: 'gcpdicomweb',
configuration: {
friendlyName: 'GCP DICOMWeb Server',
name: 'gcpdicomweb',
qidoSupportsIncludeField: false,
imageRendering: 'wadors',
thumbnailRendering: 'wadors',
enableStudyLazyLoad: true,
supportsFuzzyMatching: false,
supportsWildcard: false,
singlepart: 'bulkdata,video,pdf',
useBulkDataURI: false,
onConfiguration: (dicomWebConfig, options) => {
const { params } = options;
const { project, location, dataset, dicomStore } = params;
const pathUrl = `https://healthcare.googleapis.com/v1/projects/${project}/locations/${location}/datasets/${dataset}/dicomStores/${dicomStore}/dicomWeb`;
return {
...dicomWebConfig,
wadoRoot: pathUrl,
qidoRoot: pathUrl,
wadoUri: pathUrl,
wadoUriRoot: pathUrl,
};
},
},
},
```
This configuration would allow the user to build a dicomweb configuration from a GCP healthcare api path e.g. http://localhost:3000/projects/your-gcp-project/locations/us-central1/datasets/your-dataset/dicomStores/your-dicom-store/study/1.3.6.1.4.1.1234.5.2.1.1234.1234.123123123123123123123123123123
:::note
You can stack multiple panel components on top of each other by providing an array of panel components in the `rightPanels` or `leftPanels` properties.
For instance we can use
```
rightPanels: [[dicomSeg.panel, tracked.measurements], [dicomSeg.panel, tracked.measurements]]
```
This will result in two panels, one with `dicomSeg.panel` and `tracked.measurements` and the other with `dicomSeg.panel` and `tracked.measurements` stacked on top of each other.
:::
### More on Accept Header Configuration
In the previous section we showed that you can modify the `acceptHeader`
configuration to request specific dicom transfer syntax. By default
we use `acceptHeader: ['multipart/related; type=application/octet-stream; transfer-syntax=*']` for the following
reasons:
- **Ensures Optimal Transfer Syntax**: By allowing the server to select the transfer syntax,
the client is more likely to receive the image in a syntax that's well-suited for fast transmission
and rendering. This might be the original syntax the image was stored in or another syntax that the server deems efficient.
- **Avoids Transcoding**: Transcoding (converting from one transfer syntax to another) can be a resource-intensive process.
Since the OHIF Viewer supports all transfer syntaxes, it is fine to accept any transfer syntax (transfer-syntax=*).
This allows the server to send the images in their stored syntax, avoiding the need for costly on-the-fly conversions.
This approach not only saves server resources but also reduces response times by leveraging the viewer's capability to handle various syntaxes directly.
- **Faster Data Transfer**: Compressed transfer syntaxes generally result in smaller file sizes compared
to uncompressed ones. Smaller files transmit faster over the network, leading to quicker load
times for the end-user. By accepting any syntax, the client can take advantage of compression when available.
However, if you would like to get compressed data in a specific transfer syntax, you can modify the `acceptHeader` configuration or
`requestTransferSyntaxUID` configuration.
## Environment Variables
We use environment variables at build and dev time to change the Viewer's
behavior. We can update the `HTML_TEMPLATE` to easily change which extensions
are registered, and specify a different `APP_CONFIG` to connect to an
alternative data source (or even specify different default hotkeys).
| Environment Variable | Description | Default |
| -------------------- | -------------------------------------------------------------------------------------------------- | ------------------- |
| `HTML_TEMPLATE` | Which [HTML template][html-templates] to use as our web app's entry point. Specific to PWA builds. | `index.html` |
| `PUBLIC_URL` | The route relative to the host that the app will be served from. Specific to PWA builds. | `/` |
| `APP_CONFIG` | Which [configuration file][config-file] to copy to output as `app-config.js` | `config/default.js` |
| `PROXY_TARGET` | When developing, proxy requests that match this pattern to `PROXY_DOMAIN` | `undefined` |
| `PROXY_DOMAIN` | When developing, proxy requests from `PROXY_TARGET` to `PROXY_DOMAIN` | `undefined` |
You can also create a new config file and specify its path relative to the build
output's root by setting the `APP_CONFIG` environment variable. You can set the
value of this environment variable a few different ways:
- ~[Add a temporary environment variable in your shell](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-temporary-environment-variables-in-your-shell)~
- Previous `react-scripts` functionality that we need to duplicate with
`dotenv-webpack`
- ~[Add environment specific variables in `.env` file(s)](https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#adding-development-environment-variables-in-env)~
- Previous `react-scripts` functionality that we need to duplicate with
`dotenv-webpack`
- Using the `cross-env` package in a npm script:
- `"build": "cross-env APP_CONFIG=config/my-config.js react-scripts build"`
After updating the configuration, `yarn run build` to generate updated build
output.
<!--
Links
-->
<!-- prettier-ignore-start -->
[dcmjs-org]: https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado
[dicom-web]: https://en.wikipedia.org/wiki/DICOMweb
[storescu]: https://support.dcmtk.org/docs/storescu.html
[webpack-proxy]: https://webpack.js.org/configuration/dev-server/#devserverproxy
[orthanc-docker-compose]: https://github.com/OHIF/Viewers/tree/master/platform/app/.recipes/Nginx-Orthanc
<!-- Archives -->
[dcm4chee]: https://github.com/dcm4che/dcm4chee-arc-light
[dcm4chee-docker]: https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker
[orthanc]: https://www.orthanc-server.com/
[orthanc-docker]: https://book.orthanc-server.com/users/docker.html
[dicomcloud]: https://github.com/DICOMcloud/DICOMcloud
[dicomcloud-install]: https://github.com/DICOMcloud/DICOMcloud#running-the-code
[osirix]: https://www.osirix-viewer.com/
[horos]: https://www.horosproject.org/
[default-config]: https://github.com/OHIF/Viewers/blob/master/platform/app/public/config/default.js
[html-templates]: https://github.com/OHIF/Viewers/tree/master/platform/app/public/html-templates
[config-files]: https://github.com/OHIF/Viewers/tree/master/platform/app/public/config
<!-- prettier-ignore-end -->

4
platform/docs/versioned_docs/version-3.8/configuration/dataSources/_category_.json Normal file
View File

@@ -0,0 +1,4 @@
{
"label": "Data Sources",
"position": 2
}

177
platform/docs/versioned_docs/version-3.8/configuration/dataSources/configuration-ui.md Normal file
View File

@@ -0,0 +1,177 @@
---
sidebar_position: 6
sidebar_label: Configuration UI
---
# Configuration UI
OHIF provides for a generic mechanism for configuring a data source. This is
most useful for those organizations with several data sources
that share common (path) hierarchies. For example, an organization may have several DICOM stores
in the Google Cloud Healthcare realm where each is organized into various projects,
location, data sets and DICOM stores.
By implementing the `BaseDataSourceConfigurationAPI` and
`BaseDataSourceConfigurationAPIItem` in an [OHIF extension](../../platform/extensions/index.md), a data source can
be made configurable via the generic UI as is depicted below for a
Google Cloud Healthcare data source.
![Data source configuration UI](../../assets/img/data-source-configuration-ui.png)
:::tip
A datasource root URI can be [fully or partially specified](../../deployment/google-cloud-healthcare.md#configuring-google-cloud-healthcare-as-a-datasource-in-ohif)
in the OHIF configuration file.
:::
## `BaseDataSourceConfigurationAPIItem` interface
Each (path) item of a data source is represented by an instance of this interface.
At the very least each of these items must expose two properties:
|Property |Description|
|---------|-----------|
|id|a string that uniquely identifies the item|
|name|a human readable name for the item|
Note that information such as where in the path hierarchy the item exists
has been omitted, but can be added in any concrete class that might implement this
interface. For example, the the Google Cloud Healthcare implementation of this
interface (`GoogleCloudDataSourceConfigurationAPIItem`) adds an `itemType`
(i.e. projects, locations, datasets, or dicomStores) and `url`.
## `BaseDataSourceConfigurationAPI` interface
The implementation of this interface is at the heart of the configuration process.
It possesses several methods for building up a data source path based on various
`BaseDataSourceConfigurationAPIItem` objects that are set via calls to the `setCurrentItem`
method.
The constructor for the concrete class implementation should accept whatever
parameters are necessary for configuring the data source. One argument
to the constructor must be the string identifying the name of the data source
to be configured. Furthermore, considering that the `ExtensionManager` possesses
API to configure and update data sources, it too will likely be an argument to
the constructor. See [Creation via Customization Module](#creation-via-customization-module)
for more information on how the constructor is invoked via a factory method.
For an example implementation of this interface see `GoogleCloudDataSourceConfigurationAPI`.
### Interface Methods
Each of the following subsections lists a method of the interface with a description
detailing what the method should do.
#### `getItemLabels`
Gets the i18n labels (i.e. the i18n lookup keys) for each of the configurable items
of the data source configuration API. For example, for the Google Cloud Healthcare
API, this would be `['Project', 'Location', 'Data set', 'DICOM store']`.
Besides the configurable item labels themselves, several other string look ups
are used base on EACH of the labels returned by this method.
For instance, for the label `{itemLabel}`, the following strings are fetched for
translation...
1. `No {itemLabel} available`
- used to indicate no such items are available
- for example, for Google, `No Project available` would be 'No projects available'
2. `Select {itemLabel}`
- used to direct selection of the item
- for example, for Google, `Select Project` would be 'Select a project'
3. `Error fetching {itemLabel} list`
- used to indicate an error occurred fetching the list of items
- usually accompanied by the error itself
- for example, for Google, `Error fetching Project list` would be 'Error fetching projects'
4. `Search {itemLabel} list`
- used as the placeholder text for filtering a list of items
- for example, for Google, `Search Project list` would be 'Search projects'
#### `initialize`
Initializes the cloud server API and returns the top-level sub-items
that can be chosen to begin the process of configuring a data source.
For example, for the Google Cloud Healthcare API, this would perform the initial request
to fetch the top level projects for the logged in user account.
#### `setCurrentItem`
Sets the current path item that is passed as an argument to the method and
returns the sub-items of that item
that can be further chosen to configure a data source.
When setting the last configurable item of the data source (path), this method
returns an empty list AND configures the active data source with the selected
items path.
For example, for the Google Cloud Healthcare API, this would take the current item
(say a data set) and queries and returns its sub-items (i.e. all of the DICOM stores
contained in that data set). Furthermore, whenever the item to set is a DICOM store,
the Google Cloud Healthcare API implementation would update the OHIF data source
associated with this instance to point to that DICOM store.
#### `getConfiguredItems`
Gets the list of items currently configured for the data source associated with
this API instance. The resultant array must be the same length as the result of
`getItemLabels`. Furthermore the items returned should correspond (index-wise)
with the labels returned from `getItemLabels`.
## Creation via Customization Module
The generic UI (i.e. `DataSourceConfigurationComponent`) uses the
[OHIF UI customization service](../../platform/services/ui/customization-service.md) to
instantiate the `BaseDataSourceConfigurationAPI` instance to configure a data source.
A UI configurable data source should have a `configurationAPI` field as part of
its `configuration` in the OHIF config file. The `configurationAPI` value is the
customization id of the customization module that provides the factory method
to instantiate the `BaseDataSourceConfigurationAPI` instance.
For example, the following is a snippet of a Google Cloud Healthcare data source configuration.
```js
dataSources: [
{
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
sourceName: 'google-dicomweb',
configuration: {
name: 'GCP',
wadoUriRoot: 'https://healthcare.googleapis.com/v1/projects/ohif-cloud-healthcare/locations/us-east4/...',
...
configurationAPI: 'ohif.dataSourceConfigurationAPI.google',
...
},
},
]
```
This suggests that the factory method is provided by the `'ohif.dataSourceConfigurationAPI.google'`
customization module. That customization module is provided by the `default` extension's
`getCustomizationModule` and looks something like the following snippet of code. Notice that
the factory method's name MUST be `factory` and accept one argument - the data source name.
Furthermore note how the constructor is invoked with anything required by the concrete configuration
API class.
```js
export default function getCustomizationModule({
servicesManager,
extensionManager,
}) {
return [
{
name: 'default',
value: [
{
// The factory for creating an instance of a BaseDataSourceConfigurationAPI for Google Cloud Healthcare
id: 'ohif.dataSourceConfigurationAPI.google',
factory: (dataSourceName: string) =>
new GoogleCloudDataSourceConfigurationAPI(
dataSourceName,
servicesManager,
extensionManager
),
},
],
},
];
}
```

194
platform/docs/versioned_docs/version-3.8/configuration/dataSources/dicom-json.md Normal file
View File

@@ -0,0 +1,194 @@
---
sidebar_position: 3
sidebar_label: DICOM JSON
---
# DICOM JSON
You can launch the OHIF Viewer with a JSON file which points to a DICOMWeb
server as well as a list of study and series instance UIDs along with metadata.
An example would look like
`https://viewer.ohif.org/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json`
As you can see the url to the location of the JSON file is passed in the query
after the `dicomjson` string, which is
`https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json` (this
json file has been generated by OHIF team and stored in an amazon s3 bucket for
the purpose of the guide).
## DICOM JSON sample
Here we are using the LIDC-IDRI-0001 case which is a sample of the LIDC-IDRI
dataset. Let's have a look at the JSON file:
### Metadata
JSON file stores the metadata for the study level, series level and instance
level. A JSON launch file should follow the same structure as the one below.
:::tip
You can use our script to generate the JSON file from a hosted endpoint. See
`.scripts/dicom-json-generator.js`
You could run it like this:
```bash
node .scripts/dicom-json-generator.js '/path/to/study/folder' 'url/to/dicom/server/folder' 'json/output/file.json'
```
Some modalities require additional metadata to be added to the JSON file. You can read more about the minimum amount of metadata required for the viewer to work [here](../../faq.md#what-are-the-list-of-required-metadata-for-the-ohif-viewer-to-work). We will handle this in the script. For example, the script will add the CodeSequences for SR in order to display the measurements in the viewer.
:::
Note that at the instance level metadata we are storing both the `metadata` and
also the `url` for the dicom file on the dicom server. In this case we are
referring to
`dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm`
which is stored in another directory in our s3. (You can actually try
downloading the dicom file by opening the url in your browser).
The URL to the script in the given example is `https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178`. This URL serves as the parent directory that contains all the series within their respective folders.
```json
{
"studies": [
// first study metadata
{
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
"StudyDate": "20000101",
"StudyTime": "",
"PatientName": "",
"PatientID": "LIDC-IDRI-0001",
"AccessionNumber": "",
"PatientAge": "",
"PatientSex": "",
"series": [
// first series metadata
{
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
"SeriesNumber": 3000566,
"Modality": "CT",
"SliceThickness": 2.5,
"instances": [
// first instance metadata
{
"metadata": {
"Columns": 512,
"Rows": 512,
"InstanceNumber": 1,
"SOPClassUID": "1.2.840.10008.5.1.4.1.1.2",
"PhotometricInterpretation": "MONOCHROME2",
"BitsAllocated": 16,
"BitsStored": 16,
"PixelRepresentation": 1,
"SamplesPerPixel": 1,
"PixelSpacing": [0.703125, 0.703125],
"HighBit": 15,
"ImageOrientationPatient": [1, 0, 0, 0, 1, 0],
"ImagePositionPatient": [-166, -171.699997, -10],
"FrameOfReferenceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.229925374658226729607867499499",
"ImageType": ["ORIGINAL", "PRIMARY", "AXIAL"],
"Modality": "CT",
"SOPInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.262721256650280657946440242654",
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
"WindowCenter": -600,
"WindowWidth": 1600,
"SeriesDate": "20000101"
},
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm"
},
// second instance metadata
{
"metadata": {
"Columns": 512,
"Rows": 512,
"InstanceNumber": 2,
"SOPClassUID": "1.2.840.10008.5.1.4.1.1.2",
"PhotometricInterpretation": "MONOCHROME2",
"BitsAllocated": 16,
"BitsStored": 16,
"PixelRepresentation": 1,
"SamplesPerPixel": 1,
"PixelSpacing": [0.703125, 0.703125],
"HighBit": 15,
"ImageOrientationPatient": [1, 0, 0, 0, 1, 0],
"ImagePositionPatient": [-166, -171.699997, -12.5],
"FrameOfReferenceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.229925374658226729607867499499",
"ImageType": ["ORIGINAL", "PRIMARY", "AXIAL"],
"Modality": "CT",
"SOPInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.512235483218154065970649917292",
"SeriesInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.179049373636438705059720603192",
"StudyInstanceUID": "1.3.6.1.4.1.14519.5.2.1.6279.6001.298806137288633453246975630178",
"WindowCenter": -600,
"WindowWidth": 1600,
"SeriesDate": "20000101"
},
"url": "dicomweb:https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-002.dcm"
}
// ..... other instances metadata
]
}
// ... other series metadata
],
"NumInstances": 133,
"Modalities": "CT"
}
// second study metadata
]
}
```
![](../../assets/img/dicom-json.png)
### Local Demo
You can run OHIF with a JSON data source against you local datasets (given that
their JSON metadata is extracted).
First you need to put the JSON file and the folder containing the dicom files
inside your `public` folder. Since files are served from your local server the
`url` for the JSON file will be `http://localhost:3000/LIDC-IDRI-0001.json` and
the dicom files will be
`dicomweb:http://localhost:3000/LIDC-IDRI-0001/01-01-2000-30178/3000566.000000-03192/1-001.dcm`.
After `yarn install` and running `yarn dev` and opening the browser at
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json`
will display the viewer.
Download JSON file from
[here](https://www.dropbox.com/sh/zvkv6mrhpdze67x/AADLGK46WuforD2LopP99gFXa?dl=0)
Sample DICOM files can be downloaded from
[TCIA](https://wiki.cancerimagingarchive.net/display/Public/LIDC-IDRI) or
directly from
[here](https://www.dropbox.com/sh/zvkv6mrhpdze67x/AADLGK46WuforD2LopP99gFXa?dl=0)
Your public folder should look like this:
![](../../assets/img/dicom-json-public.png)
:::tip
It is important to URL encode the `url` query parameter especially if the `url`
parameter itself also contains query parameters. So for example,
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json?key0=val0&key1=val1`
should be...
`http://localhost:3000/viewer/dicomjson?url=http://localhost:3000/LIDC-IDRI-0001.json?key0=val0%26key1=val1`
Notice the ampersand (`&`) is encoded as `%26`.
:::
:::note
When hosting the DICOM JSON files, it is important to be aware that certain providers
do not automatically handle the 404 error and fallback to index.html. For example, Netlify
handles this, but Azure does not. Consequently, when you attempt to access a link with a
specific URL, a 404 error will be displayed.
This issue also occurs locally, where the http-server does not handle it. However,
if you utilize the `serve` package (npx serve ./dist -c ../public/serve.json), it effectively addresses this problem.
:::

54
platform/docs/versioned_docs/version-3.8/configuration/dataSources/dicom-web-proxy.md Normal file
View File

@@ -0,0 +1,54 @@
---
sidebar_position: 4
sidebar_label: DICOMweb Proxy
---
# DICOMweb Proxy
You can launch the OHIF Viewer with a url that returns a JSON file which
contains a DICOMWeb configuration. The DICOMweb Proxy constructs a DICOMweb
datasource and delegates subsequent requests for metadata and images to that.
Usage is similar to that of the [DICOM JSON](./dicom-json.md) datasource and
might look like
`https://viewer.ohif.org/viewer/dicomwebproxy?url=https://ohif-dicom-json-example.s3.amazonaws.com/dicomweb.json`
The url to the location of the JSON file is passed in the query
after the `dicomwebproxy` string, which is
`https://ohif-dicom-json-example.s3.amazonaws.com/dicomweb.json` (this json file
does not exist at the moment of this writing).
## DICOMweb JSON configuration sample
The json returned by the url in this example contains a dicomweb configuration
(see [DICOMweb](dicom-web.md)), in a "servers" object, which is then used to
construct a dynamic DICOMweb datasource to delegate requests to. Here is an
example configuration that might be returned using the url parameter.
```json
{
"servers": {
"dicomWeb": [
{
"name": "DCM4CHEE",
"wadoUriRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado",
"qidoRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs",
"wadoRoot": "https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs",
"qidoSupportsIncludeField": true,
"supportsReject": true,
"imageRendering": "wadors",
"thumbnailRendering": "wadors",
"enableStudyLazyLoad": true,
"supportsFuzzyMatching": true,
"supportsWildcard": true
}
]
}
}
```
The DICOMweb Proxy expects the json returned by the url parameter it is invoked
with to include a servers object which contains a "dicomWeb" configuration array
as above. It will only consider the first array item in the dicomWeb
configuration.

241
platform/docs/versioned_docs/version-3.8/configuration/dataSources/dicom-web.md Normal file
View File

@@ -0,0 +1,241 @@
---
sidebar_position: 2
sidebar_label: DICOMweb
---
# DICOMweb
## Set up a local DICOM server
ATTENTION! Already have a remote or local server? Skip to the
[configuration section](#configuration-learn-more) below.
While the OHIF Viewer can work with any data source, the easiest to configure
are the ones that follow the [DICOMWeb][dicom-web] spec.
1. Choose and install an Image Archive
2. Upload data to your archive (e.g. with DCMTK's [storescu][storescu] or your
archive's web interface)
3. Keep the server running
For our purposes, we will be using `Orthanc`, but you can see a list of
[other Open Source options](#open-source-dicom-image-archives) below.
### Requirements
- Docker
- [Docker for Mac](https://docs.docker.com/docker-for-mac/)
- [Docker for Windows (recommended)](https://docs.docker.com/docker-for-windows/)
- [Docker Toolbox for Windows](https://docs.docker.com/toolbox/toolbox_install_windows/)
_Not sure if you have `docker` installed already? Try running `docker --version`
in command prompt or terminal_
> If you are using `Docker Toolbox` you need to change the _PROXY_DOMAIN_
> parameter in _platform/app/package.json_ to http://192.168.99.100:8042 or
> the ip docker-machine ip throws. This is the value [`WebPack`][webpack-proxy]
> uses to proxy requests
## Open Source DICOM Image Archives
There are a lot of options available to you to use as a local DICOM server. Here
are some of the more popular ones:
| Archive | Installation |
| --------------------------------------------- | ---------------------------------- |
| [DCM4CHEE Archive 5.x][dcm4chee] | [W/ Docker][dcm4chee-docker] |
| [Orthanc][orthanc] | [W/ Docker][orthanc-docker] |
| [DICOMcloud][dicomcloud] (**DICOM Web only**) | [Installation][dicomcloud-install] |
| [OsiriX][osirix] (**Mac OSX only**) | Desktop Client |
| [Horos][horos] (**Mac OSX only**) | Desktop Client |
_Feel free to make a Pull Request if you want to add to this list._
Below, we will focus on `DCM4CHEE` and `Orthanc` usage:
### Running Orthanc
_Start Orthanc:_
```bash
# Runs orthanc so long as window remains open
yarn run orthanc:up
```
_Upload your first Study:_
1. Navigate to
[Orthanc's web interface](http://localhost:8042/app/explorer.html) at
`http://localhost:8042/app/explorer.html` in a web browser.
2. In the top right corner, click "Upload"
3. Click "Select files to upload..." and select one or more DICOM files
4. Click "Start the upload"
#### Orthanc: Learn More
You can see the `docker-compose.yml` file this command runs at
[`<project-root>/platform/app/.recipes/Nginx-Orthanc`][orthanc-docker-compose], and more on
Orthanc for Docker in [Orthanc's documentation][orthanc-docker].
#### Connecting to Orthanc
Now that we have a local Orthanc instance up and running, we need to configure
our web application to connect to it. Open a new terminal window, navigate to
this repository's root directory, and run:
```bash
# If you haven't already, enable yarn workspaces
yarn config set workspaces-experimental true
# Restore dependencies
yarn install
# Run our dev command, but with the local orthanc config
yarn run dev:orthanc
```
#### Configuration: Learn More
> For more configuration fun, check out the
> [Essentials Configuration](../index.md) guide.
Let's take a look at what's going on under the hood here. `yarn run dev:orthanc`
is running the `dev:orthanc` script in our project's `package.json` (inside
`platform/app`). That script is:
```js
cross-env NODE_ENV=development PROXY_TARGET=/dicom-web PROXY_DOMAIN=http://localhost:8042 APP_CONFIG=config/docker_nginx-orthanc.js webpack-dev-server --config .webpack/webpack.pwa.js -w
```
- `cross-env` sets three environment variables
- PROXY_TARGET: `/dicom-web`
- PROXY_DOMAIN: `http://localhost:8042`
- APP_CONFIG: `config/docker_nginx-orthanc.js`
- `webpack-dev-server` runs using the `.webpack/webpack.pwa.js` configuration
file. It will watch for changes and update as we develop.
`PROXY_TARGET` and `PROXY_DOMAIN` tell our development server to proxy requests
to `Orthanc`. This allows us to bypass CORS issues that normally occur when
requesting resources that live at a different domain.
The `APP_CONFIG` value tells our app which file to load on to `window.config`.
By default, our app uses the file at
`<project-root>/platform/app/public/config/default.js`. Here is what that
configuration looks like:
```js
window.config = {
routerBasename: '/',
extensions: [],
modes: [],
showStudyList: true,
dataSources: [
{
namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
sourceName: 'dicomweb',
configuration: {
friendlyName: 'dcmjs DICOMWeb Server',
name: 'DCM4CHEE',
wadoUriRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/wado',
qidoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
wadoRoot: 'https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs',
qidoSupportsIncludeField: true,
supportsReject: true,
imageRendering: 'wadors',
thumbnailRendering: 'wadors',
enableStudyLazyLoad: true,
supportsFuzzyMatching: true,
supportsWildcard: true,
},
},
],
defaultDataSourceName: 'dicomweb',
};
```
### Data Source Configuration Options
The following properties can be added to the `configuration` property of each data source.
##### `dicomUploadEnabled`
A boolean indicating if the DICOM upload to the data source is permitted/accepted or not. A value of true provides a link on the OHIF work list page that allows for DICOM files from the local file system to be uploaded to the data source
:::tip
The [OHIF plugin for Orthanc](https://book.orthanc-server.com/plugins/ohif.html) by default utilizes the DICOM JSON data
source and it has been discovered that only those studies uploaded to Orthanc AFTER the plugin has been installed are
available as DICOM JSON. As such, if the OHIF plugin for Orthanc is desired for studies uploaded prior to installing the plugin,
then consider switching to using [DICOMweb instead](https://book.orthanc-server.com/plugins/ohif.html#using-dicomweb).
:::
![toolbarModule-layout](../../assets/img/uploader.gif)
#### `singlepart`
A comma delimited string specifying which payloads the data source responds with as single part. Those not listed are considered multipart. Values that can be included here are `pdf`, `video`, `bulkdata`, `thumbnail` and `image`.
For DICOM video and PDF it has been found that Orthanc delivers multipart, while DCM4CHEE delivers single part. Consult the DICOM conformance statement for your particular data source to determine which payload types it delivers.
To learn more about how you can configure the OHIF Viewer, check out our
[Configuration Guide](../index.md).
### DICOM Upload
See the [`dicomUploadEnabled`](#dicomuploadenabled) data source configuration option.
### DICOM PDF
See the [`singlepart`](#singlepart) data source configuration option.
### DICOM Video
See the [`singlepart`](#singlepart) data source configuration option.
### BulkDataURI
The `bulkDataURI` configuration option allows the datasource to use the
bulkdata end points for retrieving metadata if originally was not included in the
response from the server. This is useful for the metadata information that
are big and can/should be retrieved in a separate request. In case the bulkData URI
is relative (instead of absolute) the `relativeResolution` option can be used to
specify the resolution of the relative URI. The possible values are `studies`, `series` and `instances`.
Certainly the knowledge of how the server is configured is required to use this option.
```js
bulkDataURI: {
enabled: true,
relativeResolution: 'series',
},
```
### Running DCM4CHEE
dcm4che is a collection of open source applications for healthcare enterprise
written in Java programming language which implements DICOM standard. dcm4chee
(extra 'e' at the end) is dcm4che project for an Image Manager/Image Archive
which provides storage, retrieval and other functionalities. You can read more
about dcm4chee in their website [here](https://www.dcm4che.org/)
DCM4chee installation is out of scope for these tutorials and can be found
[here](https://github.com/dcm4che/dcm4chee-arc-light/wiki/Run-minimum-set-of-archive-services-on-a-single-host)
An overview of steps for running OHIF Viewer using a local DCM4CHEE is shown
below:
<div style={{padding:"56.25% 0 0 0", position:"relative"}}>
<iframe src="https://player.vimeo.com/video/843233881?badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479" frameBorder="0" allow="autoplay; fullscreen; picture-in-picture" allowFullScreen style= {{ position:"absolute",top:0,left:0,width:"100%",height:"100%"}} title="measurement-report"></iframe>
</div>
[dcm4chee]: https://github.com/dcm4che/dcm4chee-arc-light
[dcm4chee-docker]:
https://github.com/dcm4che/dcm4chee-arc-light/wiki/Running-on-Docker
[orthanc]: https://www.orthanc-server.com/
[orthanc-docker]: http://book.orthanc-server.com/users/docker.html
[dicomcloud]: https://github.com/DICOMcloud/DICOMcloud
[dicomcloud-install]: https://github.com/DICOMcloud/DICOMcloud#running-the-code
[osirix]: http://www.osirix-viewer.com/
[horos]: https://www.horosproject.org/
[default-config]:
https://github.com/OHIF/Viewers/blob/master/platform/app/public/config/default.js
[html-templates]:
https://github.com/OHIF/Viewers/tree/master/platform/app/public/html-templates
[config-files]:
https://github.com/OHIF/Viewers/tree/master/platform/app/public/config
[storescu]: http://support.dcmtk.org/docs/storescu.html
[webpack-proxy]: https://webpack.js.org/configuration/dev-server/#devserverproxy

19
platform/docs/versioned_docs/version-3.8/configuration/dataSources/introduction.md Normal file
View File

@@ -0,0 +1,19 @@
---
sidebar_position: 1
sidebar_label: Introduction
---
# Data Source
The internal data structure of OHIF’s metadata follows naturalized DICOM JSON, a
format pioneered by `dcmjs`. In short DICOM metadata headers with DICOM Keywords
instead of tags and sequences as arrays, for easy development and clear code.
Here in this section we will discuss couple of data sources that are commonly used
and OHIF has provided the implementation for them.
## Custom Data Source
Do you have a custom data source? or a custom data that you want to use in OHIF?
You can easily write a data source to map your data to OHIF’s native format.
You can read more in the [Data Source Module](../../platform/extensions/modules/data-source.md)

47
platform/docs/versioned_docs/version-3.8/configuration/dataSources/static-files.md Normal file
View File

@@ -0,0 +1,47 @@
---
sidebar_position: 5
sidebar_label: Static Files
---
# Static Files
There is a binary DICOM to static file generator, which provides easily served
binary files. The files are all compressed in order to reduce space
significantly, and are pre-computed for the files required for OHIF, so that the
performance of serving the files is just the read from disk/write to http stream
time, without any extra processing time.
The project for the static wado files is located here: [static-wado]:
https://github.com/OHIF/static-wado
It can be compiled with Java and Gradle, and then run against a set of dicom, in
the example located in /dicom/study1 outputting to /dicomweb, and then a server
run against that data, like this:
```bash
git clone https://github.com/OHIF/static-wado
cd static-wado
./gradlew installDist
StaticWado/build/install/StaticWado/bin/StaticWado -d /dicomweb /dicom/study1
cd /dicomweb
npx http-server -p 5000 --cors -g
# you can use npx serve ./dist -l 8080 -c ../public/serve.json as an alternative to http-server
```
There is then a dev environment in the platform/app directory which can be
run against those files, like this:
```
cd platform/app
yarn dev:static
```
Additional studies can be added to the dicomweb by re-running the StaticWado
command. It will create a single studies.gz index file (JSON DICOM file,
compressed) containing an index of all studies created. There is then a small
extension to OHIF which performs client side indexing.
The StaticWado command also knows how to deploy a client and dicomweb directory
to Amazon s3, which can then server files up directly. There is another build
setup build:aws in the viewer package.json to create such a deployment.

208
platform/docs/versioned_docs/version-3.8/configuration/url.md Normal file
View File

@@ -0,0 +1,208 @@
---
sidebar_position: 3
sidebar_label: URL
---
# URL
You can modify the URL at any state of the app to get the desired result. Here
are different part of the APP that you can modify:
## WorkList
The WorkList can be modified by adding the following query parameters:
### PatientName
The patient name can be modified by adding the `PatientName` query parameter.
```js
/?patientName=myQuery
```
### MRN
The MRN can be modified by adding the `MRN` query parameter.
```js
/?mrn=myQuery
```
### Description
The description can be modified by adding the `Description` query parameter.
```js
/?description=myQuery
```
### Modality
The modality can be modified by adding the `modalities` query parameter.
```js
/?modalities=MG
```
### Accession Number
The accession number can be modified by adding the `accession` query parameter.
```js
/?accession=myQuery
```
### DataSources
If you happen to have multiple data sources configured, you can filter the
WorkList by adding the `dataSources` query parameter.
```js
/?dataSources=orthanc
```
Note1: You should pass the `sourceName` of the data source in the configuration file (not the friendly name nor the name)
Note2: Make sure that the configuration file you are using actually includes that data source. You cannot use a data source from another configuration file.
:::tip
You can add `sortBy` and `sortDirection` query parameters to sort the WorkList
```js
/?patientName=myquery&sortBy=studyDate&sortDirection=ascending
```
:::
## Viewer
The Viewer can be modified by adding the following query parameters:
### Mode
As you have seen before, the Viewer can be configured to be in different modes.
Each mode registers their `id` in the URL.
For instance
```js
/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.7009.2403.871108593056125491804754960339
```
will open the viewer in the basic (longitudinal) mode with the StudyInstanceUID
1.3.6.1.4.1.14519.5.2.1.7009.2403.871108593056125491804754960339.
And if configured, the same study can be opened in the `tmtv` mode
```js
/tmtv?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.7009.2403.871108593056125491804754960339
```
### StudyInstanceUIDs
You can open more than one study in the Viewer by adding the `StudyInstanceUIDs`
```js
/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095722.1&StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095258.1
```
:::tip
You can use this feature to open a current and prior study in the Viewer.
Read more in the [Hanging Protocol Module](../platform/extensions/modules/hpModule.md#matching-on-prior-study-with-uid) section. You can also use commas to separate
values.
:::
### SeriesInstanceUIDs
Sometimes you need to only retrieve a specific series in a study, you can do
that by providing series level QIDO query parameters in the URL such as
SeriesInstanceUIDs. This does NOT work with instance or study
level parameters. For example:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&SeriesInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8
```
This will only open the viewer with one series (one displaySet) loaded, and no
queries made for any other series.
Sometimes you need to only retrieve a subset of series in a study, you can do
that by providing more than one series, separated by commas. For example:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&SeriesInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8,1.3.6.1.4.1.25403.345050719074.3824.20170125095506.10
```
This will only open the viewer with two series (two displaySets) loaded, and no
queries made for any other series.
### initialSeriesInstanceUID
Alternatively, sometimes you want to just open the study on a specified series, but allowing other
series to be present too. This is the same behavior can be
achieved by using the `initialSeriesInstanceUID` parameter. For example:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&initialSeriesInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8
```
This will open all the series in the study, but the viewer will start with the
series specified by the `initialSeriesInstanceUID` parameter.
Note that you can combine these, if you want to load a specific set of series
plus show an initial one as the first one selected, for example:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&SeriesInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8,1.3.6.1.4.1.25403.345050719074.3824.20170125095506.10&initialSeriesInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095506.10
```
### initialSopInstanceUID
You can also specify the initial SOP Instance to be displayed by using the
`initialSopInstanceUID` parameter. For example:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&SeriesInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8&initialSopInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095501.9
```
This will open the study with the filtered series, and navigate to the slice 101
which happens to be the SOP Instance specified by the `initialSopInstanceUID`
Note: again you can mix and match
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&SeriesInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095449.8,1.3.6.1.4.1.25403.345050719074.3824.20170125095506.10&initialSeriesInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095506.10&initialSopInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095510.8
```
You can even load the whole study and only specify the initial SOP Instance to be displayed. Although
it will take more time to match, but it works as expected.
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&initialSopInstanceUID=1.3.6.1.4.1.25403.345050719074.3824.20170125095510.8
```
### hangingProtocolId
You can select the initial hanging protocol to apply by using the
hangingProtocolId parameter. The selected parameter must be available in a
hangingProtocolModule registration, but does not have to be active.
For instance for loading a specific study in mpr mode from start you can use:
```js
http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.25403.345050719074.3824.20170125095438.5&hangingProtocolId=@ohif/mnGrid
```
### token
Although not recommended, you can use the token param in the URL which will inject
the token into the Authorization header of the request.