Cross-Domain Dependency Process

From IHE Wiki
Jump to navigation Jump to search

The purpose of the Cross-Domain Dependency process is to collect, maintain and use a mapping of profile dependencies across IHE Domains. It is not intended, and should not be used, to map dependencies among profiles within the same domain. A google spreadsheet will be used to collect dependencies. Each IHE Development Domain has two responsibilities with respect to updating and using the spreadsheet.

  1. Add dependencies on other domains
  2. Check dependencies when signinficant updates to profiles are considered

Each of these topics is described in detail below.

Format of Cross-Domain Profile Dependency Spreadsheet

Dependencies are added to the Spreadsheet when a profile declares a dependency to another profile within a different IHE Development Domain.
The profile declaring the dependency is the dependent profile and the IHE Development Domain that developed that profile is the dependent domain. The profile upon which a dependency exists is the subject profile and the IHE Development Domain for that profile is the subject domain.
The Cross-domain Profile Dependency Spreadsheet has one tab for each active IHE domain. Click on the link at the bottom of the screen to change to the proper subject domain's tab. Each domain tab has the following columns:

  • Dependent Domain - this is the domain that is submitting the dependency to the domain named by the tab. For example, for the PCD domain to submit a dependency on ITI it would select the ITI tab and enter PCD in the Dependent Domain column.
  • Profile from Dependent Domain - this is the profile within the dependent domain which has declared a dependency on a profile from another domain. For example, if the DEC profile of the PCD domain is dependent on an ITI profile this column would contain DEC.
  • <domain> profile - this contains the subject profile on which the profile from dependent domain is dependent. For example, if the DEC profile is dependent on ITI's CT profile, then this column is named "ITI profile" and it would contain CT.
  • ITI Profile Actor/Transaction - this contains the part of the profile which is called out by the dependent profile. For example, If the DEC profile specifies a grouping with the Time Client from the CT profile, this column would contain "Time Client". If the DEC profile uses a transaction from ITI this colume would describe the transaction that is used. Other types of dependencies could be included here, the heading can be expanded as we understand the types of dependencies that exist.
  • Dependency Type - A few words to help understand the nature of the dependency.
  • Concerns/Issues - A place to collect concerns and issues if there are any.

Adding dependencies

The technical co-chairs of the dependent domain are responsible for updating the spreadsheet tab associated with the subject domain. Each dependency results in one line within the subject domain tab. Dependencies are entered when a profile is released for Trial Implementation and whenever a change is approved for Trial Implementation use which results in a new dependency.
There is a catch-up task that existing IHE Development Domains must address to add existing Trial Implementation and Final Text profile dependencies to the Cross-domain Profile Dependency Spreadsheet. Once this catch-up process is complete it is expect that updates would happen once a year, when new Trial Implementation Supplements are released.

Checking dependencies

Every IHE Development Domain is required to check the Cross-domain Profile Dependency Spreadsheet whenever a significant change to an existing profile is being considered. If there are dependent profiles found for the updated profile the Subject Domain should contact the Dependent Domain to allow them to review the considered change and express any concerns regarding the dependency.
The process a subject domain activites:

  1. When a significant change is considered, check the spreadsheet and identify dependent domains.
  2. Contact the co-chairs of the dependent domain, informing them of the intended change and documented dependency.
  3. The dependent domain co-chairs review the intended change and initiate a resolution problem if there is any concern