FAQ

The IHE-RO Technical Committee Site

Q: What is the purpose of this Wiki?

These pages are meant to fulfill a few different purposes:

  • Relay General Information about the IHE-RO Technical Committee
  • Support The Activities of the IHE-RO Technical Committee
  • Inform and Aid in Preparation for Those Interested in Participating in the IHE-RO Connectathons
  • Support the Data Gathering and Testing Activities of the Connectathon Judges

Q: What is the IHE-RO?

IHE stands for Integrating the Healthcare Enterprise. It is a non-profit group of domains looking to bring together vendors and clinicians to increase the viability and success of cross-vendor interoperability, to increase patient service and clinical efficiency. Link to IHE.net

IHE-RO is specifically the domain that addresses these concerns in Radiation Oncology. Link to main IHE-RO Wiki

Each IHE Domain contains a Planning Committee and a Technical Committee. The pages you are viewing now are intended to serve the interests of the IHE-RO Technical Committee

Q: Do you really need another web presence/Wiki page???

We found that at the last Connectathon that the amount of “tribal knowledge”, or information known because of year after year participation was hidden from new participants, and was not available in a coordinated fashion.

One challenge that the IHE-RO has been striving to address is easing the entry of new companies/participants. To that end, we thought to start a separate presence that would address the Connectathon issues. Along with that, we could combine a few other areas of information that would be of value.

Another way to say it is, we did not have a place that would meet all of the stated goals of the first question above.

Definitions and Processes

Q: What is a Use Case?

The Planning Committee proposes and writes statements of RO clinical issues in the form of Use Cases. They are statements of interoperability challenges in the RO clinical space. They then evaluate and rate these Use Cases in terms of value, ease of addressing and other criteria.

These Use Cases then are addressed by the Technical Committee via Profiles.

For example, the Planning Committee may state that a clinical need or use case is having a standard way to express Prescription information across devices. The Technical Committee may then take up this mandate and try to build a Profile that addresses this Use Case.

Q: What is a Profile?

To address Use Cases, the Technical Committee defines Profiles. Profiles describe interoperable behavior between systems in terms of “transactions”.

These transaction descriptions use existing standards, such as DICOM, or XML. The groupings of transactions and behaviors that fulfill a useful role in the clinic are called Actors.

For example, in order to promote the standard description of a Prescription, the Technical Committee may create a profile that describes what information a Prescription display may require, and how to display it.

Q: What is an Actor?

In a profile, a device is described usually in terms of the role it fulfills, and these descriptions are called Actors.

The intent is to divorce the operation of a device as it is represented in a Profile from its actual clinical role. For example, the actor in the Dose Compositing Profile called “General Dose Viewer” will have transactions and behavior required of it that meet that Actor description.

In earlier profiles, sometimes the actor name is exactly the same as the role of the device in the clinic, such as “Treatment Delivery Device”. This is a convention we are moving away from, and that description is not intended as a hard rule for the types of devices that can adhere to that actor behavior. A device will be judged as adhering to an actor as long as it meets the transaction and behavior descriptions of that actor, any accident of the name of the actor to whether it agrees to that devices stated role in the clinic is not the determining factor

In our example, we may describe an actor called “Prescription Display” which would then have certain behaviors attached to it in terms of what data the Actor needs to accept, what data needs to be visible and how it is formatted.

Q: How does this description of behavior actually benefit the Healthcare Enterprise?

When a profile is complete, it is publicized to the Clinical arena. If it addresses a common enough problem, it is expected that the clinical personnel will ask that products they consider for purchase will include these behaviors that should ease their work and service to patients.

This should in turn drive activity at vendors to implement these behaviors and interoperable capabilities.

Q: How does this benefit the Vendor?

The Vendor will get specific requirements with a built in demand, and also gets a monitored chance at cross-vendor testing, with well defined standards of operation and adherence.

Q: How do I work with the Profiles and Actor descriptions as a Vendor?

Reading and Commenting on Profiles

The Technical Committee is in various stages in developing profiles. This activity is done by volunteers, usually from the Vendor arena. It is important to have as many reviewers from many RO Vendors to insure that the profiles represent Clinical behavior and cover varied ways of addressing the Use Case. You can participate by reading the material that the IHE-RO publishes and…

Meeting

Much of the work of the Profile development and other work planning is done through face-to-face meetings at various times of the year. By joining the IHE-RO Technical Comittee mailing list, you can get information on meetings and other important information. Please email Jill Moton at AAPM at jill@aapm.org for details on joining.

When not meeting face-to-face, we hold teleconferences once a month that you can participate in.

Proposing / Writing Profiles

As stated previously, profile development is done by volunteers, usually in the Vendor arena. The Technical Committee will take guidance from the Planning Committee on what Use Cases should be addressed, and one or more person(s) will volunteer to draft the profile and be responsible for updating it. The contents of the profile then come before the Technical Committee as it is improved. Eventually, it will be promoted to Public Comment status, and follow the document approval procedures that are outlined on the IHE site.

Testing and Adherence

Once a year, the IHE-RO Technical Committee, with the support of AAPM, hosts a proctored cross-vendor testing activity called Connectathon. (If you are familiar with the IHE Connectathon, this is similar, except that IHE-RO hosts a separate one)

The intent of these sessions is to have Vendors bring their devices and applications to be tested against the Profiles and Actors they would like to prove that they adhere to. The independent judges assess the ability of the Vendors to interoperate and comply with the behaviors described in the Profiles. If the Vendor product is found to be adherent to an actor, then the vendor can publicize an “Integration Statement” in a public forum, and will be given the right to claim adherence to that actor when marketing their products.

In general, the Connectathon is held in the last half of the year. The Connectathons generally have one session in the U.S., one in Europe to balance the travel burden for US/European attendees. The European Connectathon is hosted by a vendor volunteer.

Working with the Wiki

Q: How Do I Edit Data Here?

Not all users will have the ability to change the information in this wiki…If you do have that level of access…

Create a page

In order to create a page, create a link on an existing page, save it and then click on the link (see below, how links are created). You will then be directed to the new page. In the upper right corner there is the command “Create” which will start the edit mode for the new page. Once you have entered information, press “Preview” to review the current state of the information. If this is ok, press “Save” to make the page available.

Edit a page

On any page you have the right to edit the content, there is the command button “Edit” in the upper right corner next to the search field. Press this button and a text editor will show up allowing for modification of existing data.

Please familiarize yourself with the buttons above the edit window. Please also read the page about the Wiki syntax. You can try out all the features on the playground.

A link to a Wiki page is defined as

[[:<namespace>:<pagename>|<title]]

e.g.

[[doc:faq|FAQ]]

is displayed as FAQ and links to page 'faq' in namespace 'doc'.

test

Acronyms

  • BRTO: Basic RT Obj. Integration Profile
  • ARTI: Advanved RT Objects Interoperability
  • IPDW: Integrated Positioning & Delivery Workflow Profile
  • TDW: Treatment Delivery Workflow
  • DCOM: Dose Compositing
  • DPDW: Discrete Pos & Delivery Workflow Profile
  • TCON: TelefConf.
  • ROIS: Radiation Oncology Information System, same as TMS
  • HIS: Hospital Information System
  • RIS: Radiation Information System
  • MRN: Medical Record Number
  • ADT: Admission Discharge and Transfer
  • UPS: Unified Procedure Step. See also ftp://medical.nema.org/medical/dicom/supps/sup96_lb.pdf
  • ATC: Advanced Technology Consortium (for Clinical Trials Quality Assurance)
  • Beam technique = IHE-RO name for different types of plans, e.g. IMRT or SMLC
  • R+ = The requirement is an IHE extension of the DICOM requirements and needs to be displayed (note: when consumed!, not produced)
  • R* = The attribute is not required to be displayed
  • R+* = The Requirement is an IHE extension of the DICOM requirements, but it is NOT required to be displayed
Log In