Difference between revisions of "PCC TF-1/Product Implementations"
m (Product Implementations moved to PCC TF-1/Product Implementations) |
|||
| Line 8: | Line 8: | ||
All required transactions must be implemented for the profile to be supported (for XDS-MS, refer to the transaction descriptions for XDS in ITI TF-2). | All required transactions must be implemented for the profile to be supported (for XDS-MS, refer to the transaction descriptions for XDS in ITI TF-2). | ||
| − | Implementers should provide a statement describing which IHE actors | + | Implementers should provide a statement describing which IHE actors, IHE integration profiles and options are incorporated in a given product. The recommended form for such a statement is defined in PCC TF-1: Appendix C. |
In general, a product implementation may incorporate any single actor or combination of actors. When two or more actors are grouped together, internal communication between actors is assumed to be sufficient to allow the necessary information flow to support their functionality; for example, the Document Source Actor of XDS-MS may use the Patient Identifier Cross-reference Consumer Actor to obtain the necessary patient identifier mapping information from its local patient id to that used in the document sharing domain. The exact mechanisms of such internal communication are outside the scope of the IHE Technical Framework. | In general, a product implementation may incorporate any single actor or combination of actors. When two or more actors are grouped together, internal communication between actors is assumed to be sufficient to allow the necessary information flow to support their functionality; for example, the Document Source Actor of XDS-MS may use the Patient Identifier Cross-reference Consumer Actor to obtain the necessary patient identifier mapping information from its local patient id to that used in the document sharing domain. The exact mechanisms of such internal communication are outside the scope of the IHE Technical Framework. | ||
Latest revision as of 22:06, 23 July 2007
Product Implementations
Developers have a number of options in implementing IHE actors and transactions in product implementations. The decisions cover three classes of optionality:
- For a system, select which actors it will incorporate (multiple actors per system are acceptable).
- For each actor, select the integration profiles in which it will participate.
- For each actor and profile, select which options will be implemented.
All required transactions must be implemented for the profile to be supported (for XDS-MS, refer to the transaction descriptions for XDS in ITI TF-2).
Implementers should provide a statement describing which IHE actors, IHE integration profiles and options are incorporated in a given product. The recommended form for such a statement is defined in PCC TF-1: Appendix C.
In general, a product implementation may incorporate any single actor or combination of actors. When two or more actors are grouped together, internal communication between actors is assumed to be sufficient to allow the necessary information flow to support their functionality; for example, the Document Source Actor of XDS-MS may use the Patient Identifier Cross-reference Consumer Actor to obtain the necessary patient identifier mapping information from its local patient id to that used in the document sharing domain. The exact mechanisms of such internal communication are outside the scope of the IHE Technical Framework.
When multiple actors are grouped in a single product implementation, all transactions originating or terminating with each of the supported actors shall be supported (i.e., the IHE transactions shall be offered on an external product interface).
The following examples describe which actors typical systems might be expected to support. This is not intended to be a requirement, but rather to provide illustrative examples.
An acute care EMR serving a hospital might include a Document Source Actor, Document Consumer Actor, a Document Repository Actor, a Patient Identification Consumer Actor, as well as a Secured Node Actor. An Ambulatory EMR serving a physician practice might include a Document Source Actor, Document Consumer Actor, a Patient Demographics Client Actor, as well as a Secured Node Actor.