IHE Profile Design Principles and Conventions

From IHE Wiki
Revision as of 19:00, 4 October 2016 by Kevino (talk | contribs)
Jump to navigation Jump to search

IHE has evolved a number of concepts, principles, mechanisms and conventions for designing, structuring and documenting solutions to user problems.

If you find yourself wanting to go against one of these guidelines you should REALLY bring it to the Domain Coordination Committee for discussion so either you can be talked out of it or this page can be updated to make room for your situation.

Profiles

  1. A profile is the fundamental concept of IHE. If a user simply gets the same profile on all their systems, the main features of the profile should work.
  2. A profile should solve a describable user need/problem.
  3. A profile should use flexible mechanisms that can be adapted to site differences.
  4. A profile should avoid having two different mechanisms to do the same thing.
  5. A profile should generally have standalone value (i.e. it adds value when deployed alone, even if it's full benefits might not be realized until it is deployed together with other profiles).
  6. A profile is something a vendor can claim, a Connectathon can test, and a user can request. It allows a short profile name to "include by reference" the many pages of detailed specification behind it. "Brief AND Effective".
  7. A profile is a "unit of marketing". It should generally address problems users can relate to and be named for users. Where transactions talk to engineers, profiles should talk to users.
  8. Profile granularity is a tradeoff:
    1. Large profiles require less decision making and coordination on the part of the user.
    2. Small profiles give users more flexibility to select features a la carte and design their own solutions.
    3. In general, err on the side of making larger profiles.
  9. Profiles go through several Phases of Development

Profile Dependency

  1. A dependency is a requirement that when a system implements one profile/actor, it must also implement another profile/actor.
  2. Dependencies should be limited to situations where the dependent profile will not function or provide value if the other profile is not present. E.g. PGP depends on CPI and SWF to function.
  3. Dependencies should not be used for "useful synergies". Selection of profiles should be left to the user/market. If they want both they can ask for both.

Options

  1. Options are evil and should have been called extensions. :-)
  2. An option is a (minor) extension of capability in a profile.
  3. If a user is completely unaware of the options and ignores them, the primary features of the profile should function.

Actors

  1. Actors are assigned to profiles when they have a role to fill.
  2. An actor is what a user (or another system) interacts with (in a sense).
  3. An actor represents a "bundle of responsibility".
  4. Focus on what an actor is responsible for in a larger sense. Don't name them based on a single transaction they are at the end of. It's OK to have various actors at the other end of a transaction.
  5. Using the same Actor in multiple profiles is acceptable and encouraged when the role/responsibility is essentially the same.
  6. If a certain function could logically belong in more than one place, it should probably be a separate actor.
  7. If a function could reasonably be a standalone product, it should probably be a separate actor.
  8. Actor granularity is a tradeoff:

Transactions

  1. A transaction should complete a specific task (see granularity discussion below).
  2. A transaction should usually select a single standard.
  3. A transaction may involve bi-directional communication (e.g. query and response).
  4. Transaction names should usually be Verb-Noun, describing what is accomplished from the point of view of the initiator (e.g. Store Image, Register Document Set)
  5. Transactions can be used in multiple profiles. Transaction design should keep this type of reuse in mind.
  6. Transactions can be assigned to multiple actors.
  7. Transaction granularity is a tradeoff:
    1. Transactions might be split if parts of it could logically be used separately
    2. Transactions should not be split gratuitously. They should complete some collection of work.

Actor Grouping

  1. Grouped Actors are actors which are implemented together on a single system.
  2. Vendors commonly group actors to bring together useful collections of functionality.
  3. Some profiles require that an implementation group certain actors together.
  4. Grouped Actors are permitted to use equivalent non-IHE protocols when performing transaction functions between themselves. E.g. A Display that is grouped with an Image Manager may use an internal protocol to retrieve images rather than the DICOM protocol required in the IHE Retrieve Images transaction.
  5. Grouped Actors are still required to support all the required IHE transactions in order to integrate with Actors on other systems. E.g. The Image Manager in the previous example must be able to use DICOM as specified in the IHE Retrieve Images transaction to provide images to an external Display actor.
Retrieved from "http://wiki.ihe.net/index.php?title=IHE_Profile_Design_Principles_and_Conventions&oldid=97788"