The OHIF Framework provides ohif-header package to add a header into application layout. ohif-header package is designed as a custom block helper named header to define your own header context.
-
If you would like to add SVG logo to header please follow these steps.
-
-
Add your SVG logo into public folder.
-
-
Add header content block which will be located on the top of the application layout into your application's main template. You can also pass some parameters to header content block to customize the header.
-
-
headerClasses: the list of classes which will be applied to header element
-
brandHref: the url of the logo to link
-
-
-
-
{{#header headerClasses="header-big bg-blue" brandHref="your logo link"}}
-...
-{{/header}}
-
-
-
Create a section called as brand in header content block and add your logo content which is displayed on the left side of the header as default into section brand.
Follow the DCM4CHEE Guidelines for Running on Docker.
-
The easiest path is to use Docker-Compose which will start and stop multiple containers for you. There are excellent instructions provided by the DCM4CHEE team on the 'light archive' repository:
Create docker-compose.yml and docker-compose.env files
-
Start the containers:
-
docker-compose start
-
-
Note: If you are running this on Mac OSX you will probably need to change the default docker-compose.yml file slightly. Specifically, the paths that refer to /var/local/ will likely need to be changed to /opt/
-
-
-
-
Run the OHIF Viewer or Lesion Tracker using the dcm4cheeDIMSE.json configuration file
-
-
-
cd OHIFViewer
-PACKAGE_DIRS="../Packages" meteor --settings ../config/dcm4cheeDIMSE.json
-
DICOMWeb refers to RESTful DICOM Services and is a recently standardized set of guidelines for exchanging medical images and imaging metadata over the internet. Not all archives fully support it yet, but it is gaining wider adoption.
DIMSE Stands for DICOM Message Service Element and is the standard method through which DICOM archives communicate. We support this messaging standard for the retrieval of study, series, and instance metadata because it is widely support. For certain PACS systems, it also (currently) provides faster query results than DICOMWeb.
We support DIMSE and DICOMWeb. Which one to use is up to you and depends on your PACS system. DICOMWeb requires no setup on the PACS-side whatsoever, whereas DIMSE may require you to add the 'OHIFDCM' aeTitle to the known DICOM Modalities of your Archive. This is the case for Orthanc, for example (See https://github.com/OHIF/Viewers/wiki/Orthanc-with-DIMSE).
Depending on whether or not you want uploaded studies to persist in Orthanc after Docker has been closed, there are two different methods for starting the Docker image:
-
Temporary data storage
-
This command will start an instance of the jodogne/orthanc-plugins Docker image. All data will be removed when the instance is stopped!
-
docker run --rm -p 4242:4242 -p 8042:8042 jodogne/orthanc-plugins
-
Persistent data storage
-
In order to allow your data to persist after the instance is stopped, you first need to create an image and attached data volume with Docker. The steps are as follows:
-
-
Create a persistent data volume for Orthanc to use
I would like to contribute code - how do I do this?
-
Fork the repository, make your change and submit a pull request.
-
Any guidance on submitting changes?
-
While we do appreciate code contributions, triaging and integrating contributed code changes can be very time consuming. Please consider the following tips when working on your pull requests:
-
-
Functionality is appropriate for the repository. Consider posting on the forum if you are not sure.
-
Code quality is acceptable. We don't have coding standards defined, but make sure it passes ESLint and looks like the rest of the code in the repository.
-
Quality of design is acceptable. This is a bit subjective so you should consider posting on the forum for specific guidance.
-
The scope of the pull request is not too large. Please consider separate pull requests for each feature as big pull requests are very time consuming to understand.
-
-
We will provide feedback on your pull requests as soon as possible. Following the tips above will help ensure your changes are reviewed.
-
Testing contribution pull requests
-
OHIF uses netlify so that pull requests are autogenerated and available for testing.
Replacing the number 237 in the link below with your pull request number should let you test it as well and you can use this link for discussions on github without requiring reviewers to download and build your branch.
OHIF Viewer will be built normally, but with no DICOM Server information, which needs to be added when running the build. This is described in Manually adding DICOM Server to the Viewer.
SET MONGO_URL=mongodb://localhost:27017/myapp
-SET ROOT_URL=http://localhost
-SET PORT=3000
-node main.js
-
-
Manually adding DICOM Server to the Viewer
-
If DICOM Server was configured automatically during the building process, skip this step.
-
Access the viewer http://localhost:3000 and toggle the Options menu, located at top right corner. Select Server Information option.
-
In Server Information dialog click on Add a new server button and fill the fields accordingly to the DICOM Server to be added.
-
In case of doubts about any field in this dialog, use config/orthancDICOMWeb.json as reference.
-
After filling the form, click on the Save button and the new server will be listed. Make sure to activate it by clicking on the left most button (a checkbox button) in the Actions column.
-
Refresh the page and Viewer will be connected to the DICOM Server.
The OHIF Framework is built as a set of small Meteor packages which can be included as necessary in the final application. Since the logic and templates are largely pushed into packages, the actual application-specific code for each Viewer is relatively short.
-
In brief, to create a new Viewer application, you need to:
-
-
Define the existing pages and the routes which will lead to them
-
Define the overall application layout
-
Include child templates from the OHIF Packages into your application layout
-
Specify desired template options as necessary (e.g. which tools should appear in the toolbar)
-
-
User interface components for your application can be defined in any View layer supported by Meteor (Officially: Angular, React, Blaze, Unofficially: Vue).
There are a few pre-defined settings files that you can find in config folder. These are Meteor files and all settings can be accessed as showed on Meteor Website. UI settings are also available as OHIF.uiSettings. See the schema for more information.
-
Server settings
-
-
dropCollections (boolean): the server will drop all Mongo collections when it's set to true as soon as it has finished starting. This is useful for demo and development environments.
-
-
UI Settings
-
-
studyListDateFilterNumDays (integer): define the default date filter (range) on study list. If it's 02/15/2017 and this config is set to 5 then it will search for studies between 02/10/2017 and 02/15/2017.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/latest/_book/history/v1/essentials/meteor-packages.md b/docs/latest/_book/history/v1/essentials/meteor-packages.md
deleted file mode 100644
index e172aba86..000000000
--- a/docs/latest/_book/history/v1/essentials/meteor-packages.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Meteor Packages
-
-### Commands (*ohif-commands*)
-### Core (*ohif-core*)
-
-## Cornerstone Package (*ohif-cornerstone*)
-
-This package contains a number of front-end libraries that help us build web-based medical imaging applications.
-
-These are:
-- [dicomParser](https://github.com/cornerstonejs/dicomParser):
-A lightweight JavaScript library for parsing DICOM P10 byte streams in modern web browsers (IE10+), Node.js, and Meteor.
-
-- [Cornerstone Core](https://github.com/cornerstonejs/cornerstone):
-A lightweight JavaScript library for displaying medical images in modern web browsers that support the HTML5 canvas element.
-
-- [Cornerstone Tools](https://github.com/cornerstonejs/cornerstoneTools):
-A library built on top of cornerstone that provides a set of common tools needed in medical imaging to work with images and stacks of images
-
-- [Cornerstone Math](https://github.com/cornerstonejs/cornerstoneMath):
-Math and computational geometry functionality for Cornerstone
-
-- [Cornerstone WADO Image Loader](https://github.com/cornerstonejs/cornerstoneWADOImageLoader):
-A Cornerstone Image Loader for DICOM P10 instances over HTTP. This can be used to integrate cornerstone with WADO-URI servers or any other HTTP based server that returns DICOM P10 instances (e.g. Orthanc or custom servers).
-
-- [Hammer.js](https://github.com/hammerjs/hammer.js):
-A JavaScript library for multi-touch gestures
-
-### Design (*ohif-design*)
-### DICOM Services (*ohif-dicom-services*)
-It contains a number of helper functions for retrieving common value types (e.g. JSON, patient name, image frame) from a DICOM image. This package is for server-side usage.
-
-### Hanging Protocols (*ohif-hanging-protocols*)
-### Header (*ohif-header*)
-### Hotkeys (*ohif-hotkeys*)
-
-### Lesion Tracker (*ohif-lesiontracker*)
-This package stores all of the oncology-specific tools and functions developed for the Lesion Tracker application. Here we store, for example, the Target measurement and Non-target pointer tools that are used to monitor tumour burden over time.
-
-This package also stores Meteor components for the interactive lesion table used in the Lesion Tracker, and dialog boxes for the callbacks attached to the Target and Non-target tools.
-
-### Logging (*ohif-log*)
-### Logging (*ohif-measurements*)
-### Metadata (*ohif-metadata*)
-### Polyfilling Functionality (*ohif-polyfill*)
-
-### Select Tree UI (*ohif-select-tree*)
-### Server Settings UI (*ohif-servers*)
-### Studies (*ohif-studies*)
-### Study List UI (*ohif-study-list*)
-### Common Themes (*ohif-themes-common*)
-### Theming (*ohif-themes*)
-### User Management (*ohif-user-management*)
-### User (*ohif-user*)
-
-### Basic Viewer Components (*ohif-viewerbase*)
-This is the largest package in the repository. It holds a large number of re-usable Meteor components that are used to build both the OHIF Viewer and Lesion Tracker.
-
-### WADO Proxy (*ohif-wadoproxy*)
-Proxy for CORS
diff --git a/docs/latest/_book/history/v1/essentials/troubleshooting.html b/docs/latest/_book/history/v1/essentials/troubleshooting.html
deleted file mode 100644
index 169b2ccd1..000000000
--- a/docs/latest/_book/history/v1/essentials/troubleshooting.html
+++ /dev/null
@@ -1,1008 +0,0 @@
-
-
-
-
-
-
- Troubleshooting ยท OHIF
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1. QIDO root URL is incorrect 2. DICOM Web is not enabled on PACS
-
-
-
Can't retrieve Study List over DIMSE
-
1. PACS is not configured to allow connections from OHIF Meteor Server
-
-
-
Can't retrieve images
-
1. WADO Root URL is incorrect 2. DICOM Web is not enabled on PACS 3. HTTP Basic Authentication username and password are incorrect or not provided.
-
-
-
-
Debugging Steps
-
Can't retrieve Study List over DICOMWeb
-
-
Check that you can query your PACS using an alternative DICOM Web client (e.g. cURL, or a Web Browser). If you cannot, then your PACS is configured incorrectly. Refer to the documentation of the image archive.
-2.
Make sure your issue is reproducible: If we try to reproduce your issue given your provided steps and we cannot reproduce it, we will not be able to fix it. Nobody wants to spend time guessing how to reproduce your issue! Before filing, please reproduce your issue more than once and clearly describe the steps taken.
-
If you are reporting a user interface issue, provide screenshots: A picture is worth a thousand words. If your issue concerns the UI, screenshots will help us identify the issue dramatically faster since it can be extremely challenging to describe UI bugs with text. You should still clearly describe the steps that you took to produce the issue.
-
Include platform & environment: Your operating system, web browser, and web browser version are highly relevant for many bugs. Please provide these with all bug reports.
-
Include expected and actual result: Tell us what you expected to happen, and what actually happened. If you don't do this, we might not consider it a bug.
-
-
How can I request a new feature?
-
At the moment we are in the process of defining our roadmap and will do our best to communicate this to the community. If your requested feature is on the roadmap, then it will most likely be built at some point. If it is not, you are welcome to build it yourself and contribute it. If you have resources and would like to fund the development of a feature, please contact us.
-
Who should I contact about Academic Collaborations?
-
Gordon J. Harris at Massachusetts General Hospital is the primary contact for any academic collaborators. We are always happy to hear about new groups interested in using the OHIF framework, and may be able to provide development support if the proposed collaboration has an impact on cancer research.
-
Do you offer commercial support?
-
The Open Health Imaging Foundation does not offer commercial support, however, some community members do offer consulting services. The following contacts may be useful:
Please file a Pull Request if you wish to add your name or organization to this list.
-
I emailed my question to you directly and you did not respond. Why not?
-
Emailing developers directly is not a shortcut to faster support. Please file your issues and questions on Github so that everyone can benefit from the discussion and solutions.
NO. The OHIF Viewer, Lesion Tracker, and Standalone Viewer, NOT F.D.A. cleared or CE Marked. It is the users responsibility to ensure compliance with applicable rules and regulations. The License for the OHIF Framework does not prevent your company or group from seeking F.D.A. clearance for a product built using the framework.
-
If you have gone this route (or are going there), please let us know because we would be interested to hear about your experience.
NO. The OHIF Viewer, Lesion Tracker, and Standalone Viewer DO NOT fulfill all of the criteria to become HIPAA Compliant. It is the users responsibility to ensure compliance with applicable rules and regulations.
-
The Lesion Tracker application demonstrates some available components and features (e.g. Audit Trail, automatic logoff, and unique user identification for User Accounts) which could be used by third parties seeking HIPAA compliance.
At the time of project conception, Meteor was a simple way to begin using bleeding edge web technologies without putting significant effort into configuration and build processes. Although Meteor does have some drawbacks, it remains a simple all-in-one solution.
-
Do you have any plans to stop using Meteor?
-
We have considered migrating templates from Blaze (http://blazejs.org/) to React (https://reactjs.org/) or Vue (https://vuejs.org/), simply because these decouple the view layer from the remainder of the application. Blaze currently lacks Stand-alone Support which means that our templates are not re-usable outside of a Meteor application. This is certainly a downside, but the resource cost to migrate every template is significant.