http://wiki.ihe.net/api.php?action=feedcontributions&user=Rgioirdano&feedformat=atomIHE Wiki - User contributions [en]2024-03-28T12:31:27ZUser contributionsMediaWiki 1.35.5http://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=115131Document Metadata Subscription2019-04-18T15:11:36Z<p>Rgioirdano: /* Systems Affected */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:pull style notification framework.png|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:Actor_transaction_dsub.png|frameless|upright=1.3]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Actor_transaction_dsub.png&diff=115130File:Actor transaction dsub.png2019-04-18T15:10:38Z<p>Rgioirdano: </p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=115127Document Metadata Subscription2019-04-18T14:50:06Z<p>Rgioirdano: </p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:pull style notification framework.png|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png|frameless|upright=1.3]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Pull_style_notification_framework.png&diff=115126File:Pull style notification framework.png2019-04-18T14:43:29Z<p>Rgioirdano: Rgioirdano uploaded a new version of File:Pull style notification framework.png</p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Pull_style_notification_framework.png&diff=115125File:Pull style notification framework.png2019-04-18T14:40:22Z<p>Rgioirdano: </p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Dsub_graph1.png&diff=115124File:Dsub graph1.png2019-04-18T14:39:36Z<p>Rgioirdano: Rgioirdano uploaded a new version of File:Dsub graph1.png</p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114842Document Metadata Subscription2019-04-09T13:36:33Z<p>Rgioirdano: /* Systems Affected */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png|frameless|upright=1.3]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114841Document Metadata Subscription2019-04-09T13:36:21Z<p>Rgioirdano: /* Details */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png|center|frameless|upright=1.3]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114840Document Metadata Subscription2019-04-09T13:35:58Z<p>Rgioirdano: /* Systems Affected */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png|center|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png|center|frameless|upright=1.3]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114839Document Metadata Subscription2019-04-09T13:35:09Z<p>Rgioirdano: /* Details */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png|center|frameless|upright=2.0]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114838Document Metadata Subscription2019-04-09T13:25:06Z<p>Rgioirdano: /* Systems Affected */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:dsub_graf2.png]]<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Dsub_graf2.png&diff=114837File:Dsub graf2.png2019-04-09T13:24:31Z<p>Rgioirdano: </p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Document_Metadata_Subscription&diff=114836Document Metadata Subscription2019-04-09T13:23:52Z<p>Rgioirdano: /* Details */</p>
<hr />
<div>__TOC__<br />
<br />
==Summary==<br />
<br />
This profile describes the use of subscription and notification mechanism for use within an XDS Affinity Domain and across communities. The subscription allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. This profile is based on the OASIS WS-BaseNotification standard and, in accordance to that, defines two methods of subscription and notification: <br />
<br />
'''a)''' In the '''“Push-style”'''method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled.<br />
<br />
'''b)''' In the''' “Pull-style”''' method, a Notification Puller actor creates a Pull Point resource able to store notification generated by the Document Metadata Notification Broker actor. This Pull Point resource is a resource managed by the Pull Point actor that allows the storing of notification targeted to a specific recipient.Notifications stored in the Pull Point actor can be retrieved by the Notification Puller actor using a specific transaction<br />
<br />
==Benefits==<br />
<br />
This profile creates a framework for the creation and the delivery of notifications for a published document or for an update occurred to a specified folder. A Notification is created if the content published fit into specific criteria selected by the Recipient of notifications itself. The DSUB environment should involve, as recipients of notifications, systems that are behind a firewall, systems unable or unwilling to provide endpoints to which the notification creator can send notifications and systems that do not want to be notified at unpredictable times but rather at a time of their own choosing.<br />
<br />
==Details==<br />
<br />
<br />
'''''a)'' Push-style:''' In the “Push-style” method, a Document Metadata Subscriber may subscribe on behalf of the Document Metadata Notification Recipient to receive notifications about the availability of documents based on specific criteria. A Document Metadata Notification Broker keeps track of the subscriptions and sends the appropriate notifications based on the registration of objects in an XDS Document Registry. Subscriptions exist for a certain period of time and can be cancelled. The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient. The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists. The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions it receives, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers. This actor may optionally receive Document Metadata Publish transactions representing the stream of events against which the existing subscriptions are matched. The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.<br />
<br />
<br />
'''''b)'' Pull-style:''' A Notification Pull Point actor creates a Pull Point resource in response to each CreatePullPoint Request and collects all notifications destined for the requesting Notification Puller actor. Within the Notification Pull Point actor, each Pull Point resource allows the storing and managing of notifications. A Pull Point resource is associated with a Notification Puller actor. A Pull Point resource is an abstract concept that creates a relationship between a Notification Puller actor and notifications stored for that actor in the Pull Point actor. The Notification Pull Point actor serves as a Pull Point resource “factory” in processing CreatePullPoint Request messages. It can be asked to create Pull Point resources by many Notification Puller actors. The Notification Pull Point actor can manage many Pull Point resources for each Notification Puller actor. The creation of a Pull Point resource requires grouping the Notification Pull Point actor with a Document Metadata Notification Recipient for receiving notifications sent by the Document Metadata Notification Broker. If many Notification Puller actors are involved in the notification system, the Notification Pull Point actor is grouped with many Document Metadata Notification Recipient actors (see figure below). When a Notification Puller actor sends a CreatePullPoint Request message, the Notification Pull Point actor returns an endpoint in the CreatePullPoint Response message. This endpoint is associated with a Document Metadata Notification Recipient actor. The Document Metadata Notification Recipient SHALL store in the Pull Point resource the notifications received. This is an additional requirement for a Document Metadata Notification Recipient that is grouped with a Notification Pull Point actor. The Notification Puller actor uses this endpoint for subsequent transactions (subscription requests, pulling of notifications and destroying of the Pull Point resource itself).<br />
<br />
[[Image:dsub_graph1.png]]<br />
<br />
==Systems Affected==<br />
<br />
<br />
Systems involved in this profile are: <br />
<br />
• Enterprise-wide information systems that manage a patient’s Electronic Health Record, such as a Hospital Information System;<br />
<br />
• Laboratory Information Systems;<br />
<br />
• Local Health Authorities application;<br />
<br />
• GP’s EHR.<br />
<br />
<br />
<br />
'''Actors & Transactions:'''<br />
<br />
[[Image:DSUB_Actor_transaction2013.png]]<br />
<br />
<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
<br />
'''Documents:''' <br />
* [http://www.ihe.net/Technical_Frameworks/#IT ITI Technical Framework]<br />
:* Vol. 1 - Section 26<br />
:* Vol. 2b - Sections 3.52, 3.53, 3.54<br />
:* Vol. 2c - Sections 3.69, 3.70<br />
<br />
'''Additional Supplement'''<br />
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_DSUB_Extensions.pdf Extension to the Document Metadata Subscription (DSUB) Profile]<br />
<br />
'''Underlying Standards:'''<br />
* OASIS Web Services Notification Family of Standards <br />
* WS-BaseNotification 1.3 OASIS Standard <br />
* WS-BrokeredNotification 1.3 OASIS Standard <br />
* WS-Topics 1.3 OASIS Standard<br />
* WS-BaseFault 1.2 Standard<br />
<br />
==See Also==<br />
<br />
[[Document Sharing]]<br />
<br />
This page is based on the [[Profile Template]]<br />
<br />
[[Category:Profiles]]<br />
[[Category:ITI Profile]]<br />
[[Category:DocShare]]<br />
<br />
Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:Dsub_graph1.png&diff=114835File:Dsub graph1.png2019-04-09T13:22:15Z<p>Rgioirdano: </p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=File:DSUBpullstyle.png&diff=114834File:DSUBpullstyle.png2019-04-09T13:18:05Z<p>Rgioirdano: Rgioirdano uploaded a new version of File:DSUBpullstyle.png</p>
<hr />
<div></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=OID_Registration&diff=114520OID Registration2019-03-20T10:09:50Z<p>Rgioirdano: </p>
<hr />
<div><br />
<br />
==IHE Root OID==<br />
IHE maintains a namespace under an object identifier (OID) obtained from the [http://www.iana.org/ IANA]. The structure of the root OID (1.3.6.1.4.1.19376) is described below:<br />
<br />
<blockquote><br />
1 = International Organization for Standardization (ISO)<br /><br />
3 = Organization identification schemes registered according to ISO/IEC 6523-2<br /><br />
6 = United States Department of Defense (DoD)<br /><br />
1 = Internet<br /><br />
4 = Internet Assigned Numbers Authority (IANA)<br /><br />
1 = Private enterprises<br /><br />
19376 = Integrating the Healthcare Enterprise International<br /><br />
</blockquote><br />
<br />
Top-level OIDs under this namespace are assigned and registered by the IHE Documentation Specialist. Send inquiries about assignment of top-level domains to: secretary@ihe.net.<br />
<br />
<br />
==IHE Domain Namespaces==<br />
Each IHE domain manages its own namespace under the root OID designated for IHE domain namespaces (1.3.6.1.4.1.19376.1). The root OID for each domain's namespace is provided below, along with a link to a page describing its OID assignments.<br />
<br />
{| style="width:50%" border="1" cellpadding="1"<br />
! Domain !! Top-level OID <br />
|-<br />
| Anatomic Pathology (ANAPATH)|| See Pathology and Laboratory Medicine (PaLM) <br />
|-<br />
| [ftp://ftp.ihe.net/Cardio/OID%20registry/Cardiology_OIDs_current.xlsx Cardiology (CARD)]|| 1.3.6.1.4.1.19376.1.4<br />
|-<br />
| Dental (DENT)|| TBD<br />
|-<br />
| Eye Care (EYECARE)|| 1.3.6.1.4.1.19376.1.10<br />
|-<br />
| [http://wiki.ihe.net/index.php/ITI_-_OID_assignment_1.3.6.1.4.1.19376.1.2 IT Infrastructure (ITI)]|| 1.3.6.1.4.1.19376.1.2<br />
|-<br />
| Laboratory (LAB)|| See Pathology and Laboratory Medicine (PaLM)<br />
|-<br />
| [ftp://ftp.ihe.net/PaLM/OIDregistry/PaLM_OIDs.pdf Pathology and Laboratory Medicine (PaLM)] || 1.3.6.1.4.1.19376.1.3 (1st root inherited from Laboratory) and 1.3.6.1.4.1.19376.1.8 (2nd root inherited from Anatomic Pathology)<br />
|-<br />
| [http://wiki.ihe.net/index.php/PCC_Vocabulary_Registry_and_Data_Dictionary Patient Care Coordination (PCC)]|| 1.3.6.1.4.1.19376.1.5<br />
|-<br />
| [http://wiki.ihe.net/index.php/PCD_OID_Management Patient Care Device (PCD)]|| 1.3.6.1.4.1.19376.1.6<br />
|-<br />
| Pharmacy (PHARM)|| 1.3.6.1.4.1.19376.1.9<br />
|-<br />
| [http://wiki.ihe.net/index.php/QRPH_Registry Quality, Research and Public Health (QRPH)]|| 1.3.6.1.4.1.19376.1.7<br />
|-<br />
| Radiation Oncology (RO)|| 1.3.6.1.4.1.19376.1.11<br />
|-<br />
| [ftp://ftp.ihe.net/Radiology/TF_Final_Text_Versions/IHE-RAD-TF_section-numbering.xls Radiology (RAD)], [https://wiki.ihe.net/index.php/Radiology-controlled-vocabulary Radiology Controlled Vocabulary]|| 1.3.6.1.4.1.19376.1.1<br />
|-<br />
| Surgery (SURG)|| TBD<br />
|}<br />
<br />
==IHE National Deployment Committee Namespaces==<br />
IHE National Deployment Committees may also manage their own namespaces under the root OIDs designated for national deployment committees (1.3.6.1.4.1.19376.2 and 1.3.6.1.4.1.19376.3). The suggested practice is to use the appropriate ISO national country identifier to designate a top-level OID for a national deployment committee namespace under one of these OIDs. Identified national deployment committee namespaces are provided below.<br />
<br />
{| style="width:50%" border="1" cellpadding="1"<br />
! National Deployment Committee !! Top-level OID <br />
|-<br />
| [http://wiki.hl7.de/index.php?title=OID-Konzept_IHE-D IHE Germany] || 1.3.6.1.4.1.19376.3.276<br />
|-<br />
| IHE Switzerland || 1.3.6.1.4.1.19376.3.756<br />
|-<br />
| IHE USA || 1.3.6.1.4.1.19376.3.840<br />
|-<br />
| [[RSNA OID Registration | IHE USA -> RSNA]] || 1.3.6.1.4.1.19376.3.840.1<br />
|-<br />
|}<br />
<br />
<br />
==IHE Format Codes==<br />
For information about IHE Format Code see [http://wiki.ihe.net/index.php/IHE_Format_Codes this page]<br />
<br />
<br />
==IHE Type Codes==<br />
For information about IHE Type Code see [https://wiki.ihe.net/index.php/IHE_Type_Codes this page]<br />
<br />
<br />
==General Information about Creating Unique Identifiers==<br />
<br />
<br />
For general information about Unique Identifiers see [http://wiki.ihe.net/index.php/Creating_Unique_IDs_-_OID_and_UUID Creating Unique IDs - OID and UUID]</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=114188IHE Type Codes2019-03-06T14:14:23Z<p>Rgioirdano: </p>
<hr />
<div>The tables below lists the [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)] metadata. <br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes=<br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.2<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.3<br />
|}<br />
<br />
<br/><br />
<br />
=How to generate Type Codes metadata in a specific domain=<br />
<br />
<b>1.3.6.1.4.1.19376.1.2.6.2</b> identifies the valueSet for typeCode metadata.<br/><br />
<b>1.3.6.1.4.1.19376.1.2.6.2.domain_number</b> identifies the typeCode metadata for a specific domain:<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |Domain<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |domain_number <br />
|-<br />
| Patient Care Coordination (PCC)<br />
| 1 <br />
|-<br />
| Quality, Research and Public Health (QRPH)<br />
| 2<br />
|-<br />
| Radiology (RAD)<br />
| 3<br />
|-<br />
| Cardiology (CARD)<br />
| 4<br />
|-<br />
| Dental (DENT)<br />
| 5<br />
|-<br />
| Endoscopy (ENDO)<br />
| 6<br />
|-<br />
| Eye Care (EYECARE)<br />
| 7<br />
|-<br />
| IT Infrastructure (ITI)<br />
| 8<br />
|-<br />
| Pathology and Laboratory Medicine (PaLM)<br />
| 9<br />
|-<br />
| Patient Care Device (PCD)<br />
| 10<br />
|-<br />
| Pharmacy (PHARM)<br />
| 11<br />
|-<br />
| Radiation Oncology (RO)<br />
| 12<br />
|-<br />
| Surgery<br />
| 13<br />
|}</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=114187IHE Type Codes2019-03-06T14:13:48Z<p>Rgioirdano: /* IHE defined Type Codes for Workflow Document profiles */</p>
<hr />
<div>The tables below lists the [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)] metadata used by the Workflow Document Profiles. <br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes=<br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.2<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.3<br />
|}<br />
<br />
<br/><br />
<br />
=How to generate Type Codes metadata for a Workflow Document profile in a specific domain=<br />
<br />
<b>1.3.6.1.4.1.19376.1.2.6.2</b> identifies the valueSet for typeCode metadata.<br/><br />
<b>1.3.6.1.4.1.19376.1.2.6.2.domain_number</b> identifies the typeCode metadata for a specific domain:<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |Domain<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |domain_number <br />
|-<br />
| Patient Care Coordination (PCC)<br />
| 1 <br />
|-<br />
| Quality, Research and Public Health (QRPH)<br />
| 2<br />
|-<br />
| Radiology (RAD)<br />
| 3<br />
|-<br />
| Cardiology (CARD)<br />
| 4<br />
|-<br />
| Dental (DENT)<br />
| 5<br />
|-<br />
| Endoscopy (ENDO)<br />
| 6<br />
|-<br />
| Eye Care (EYECARE)<br />
| 7<br />
|-<br />
| IT Infrastructure (ITI)<br />
| 8<br />
|-<br />
| Pathology and Laboratory Medicine (PaLM)<br />
| 9<br />
|-<br />
| Patient Care Device (PCD)<br />
| 10<br />
|-<br />
| Pharmacy (PHARM)<br />
| 11<br />
|-<br />
| Radiation Oncology (RO)<br />
| 12<br />
|-<br />
| Surgery<br />
| 13<br />
|}</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=113709IHE Type Codes2019-02-07T15:23:05Z<p>Rgioirdano: </p>
<hr />
<div>The tables below lists the [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)] metadata used by the Workflow Document Profiles. <br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes for Workflow Document profiles=<br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.2<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
| 1.3.6.1.4.1.19376.1.2.6.2.3<br />
|}<br />
<br />
<br/><br />
=How to generate Type Codes metadata for a Workflow Document profile in a specific domain=<br />
<br />
<b>1.3.6.1.4.1.19376.1.2.6.2</b> identifies the valueSet for typeCode metadata.<br/><br />
<b>1.3.6.1.4.1.19376.1.2.6.2.domain_number</b> identifies the typeCode metadata for a specific domain:<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |Domain<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" |domain_number <br />
|-<br />
| Patient Care Coordination (PCC)<br />
| 1 <br />
|-<br />
| Quality, Research and Public Health (QRPH)<br />
| 2<br />
|-<br />
| Radiology (RAD)<br />
| 3<br />
|-<br />
| Cardiology (CARD)<br />
| 4<br />
|-<br />
| Dental (DENT)<br />
| 5<br />
|-<br />
| Endoscopy (ENDO)<br />
| 6<br />
|-<br />
| Eye Care (EYECARE)<br />
| 7<br />
|-<br />
| IT Infrastructure (ITI)<br />
| 8<br />
|-<br />
| Pathology and Laboratory Medicine (PaLM)<br />
| 9<br />
|-<br />
| Patient Care Device (PCD)<br />
| 10<br />
|-<br />
| Pharmacy (PHARM)<br />
| 11<br />
|-<br />
| Radiation Oncology (RO)<br />
| 12<br />
|-<br />
| Surgery<br />
| 13<br />
|}</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=113606IHE Type Codes2019-01-31T08:24:07Z<p>Rgioirdano: </p>
<hr />
<div>The tables below lists the [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)] metadata used by the Workflow Document Profiles. <br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes for Workflow Document profiles=<br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1 <br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.2<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.3<br />
|}<br />
<br />
<br/><br />
=How to generate Type Codes metadata for a Workflow Document profile in a specific domain=<br />
<br />
1.3.6.1.4.1.19376.1.2.6.2 identifies the valueSet for typeCode metadata.<br/><br />
1.3.6.1.4.1.19376.1.2.6.2.x identifies the typeCode metadata for a specific domain (1 = PCC, 2 = QRPH, 3 = RAD...)<br/></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=113591IHE Type Codes2019-01-30T14:58:23Z<p>Rgioirdano: </p>
<hr />
<div>The tables below lists the [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)] metadata used by the Workflow Document Profiles. <br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes for Workflow Document profiles=<br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.1 <br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.2<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.3<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.4 <br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.2.1<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.3.1<br />
|}<br />
<br />
<br/><br />
=How to generate Type Codes metadata for a Workflow Document profile in a specific domain=<br />
<br />
1.3.6.1.4.1.19376.1.2.6.2 identifies the valueSet for typeCode metadata.<br/><br />
1.3.6.1.4.1.19376.1.2.6.2.x identifies the typeCode metadata for a specific domain (1 = PCC, 2 = QRPH, 3 = RAD...)<br/><br />
1.3.6.1.4.1.19376.1.2.6.2.x.y identifies the typeCode metadata for a specific profile in the domain x.<br/></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=IHE_Type_Codes&diff=110500IHE Type Codes2018-07-20T16:11:37Z<p>Rgioirdano: Created page with "The tables below lists the Document Sharing [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)], template identifiers, and media types u..."</p>
<hr />
<div>The tables below lists the Document Sharing [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf type codes (TypeCode)], template identifiers, and media types used by the Document Sharing "Document Content" Profiles. <br />
<br />
This page represents a ValueSet identified by '''missing OID'''<br />
<br />
__TOC__<br />
<br/><br />
=IHE defined Type Codes=<br />
Note that the code system for these codes is '''missing OID''' as assigned by the ITI Domain ('''maybe''') for codes used for the purposes of cross-enterprise document sharing (XDS). For more information see [[ITI - OID assignment 1.3.6.1.4.1.19376.1.2]]. <br />
<br />
These codes are part of the IHE TypeCodes ValueSet identified by <span style="color:red">1.3.6.1.4.1.19376.1.2.6.2</span>.<br />
<br/><br />
Note these codes have been pulled into a FHIR value set -- http://hl7.org/fhir/ValueSet/formatcodes '''and typeCode??'''<br />
<br/><br />
These codes have been published by IHE on the IHE FTP - FHIR directory as a FHIR CodeSystem and FHIR ValueSet. See [[Implementation Material]] '''and typeCode??'''<br />
<br/><br />
<br />
{| class="wikitable"<br />
|-<br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2"|Profile <br />
| style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" colspan="2" |Type Code <br />
|style="background: silver; text-align: center; font-weight: bold; border: 2px solid gray" rowspan="2" | workflowReferenceId<br />
|-<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| code<br />
| style="font-weight: bold; text-align: center; background: silver; border: 2px solid gray"| codingScheme<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| PCC Profiles<br />
|-<br />
| Cross-Enterprise TeleHomeMonitoring Workflow Definition Profile (XTHM-WD)<br />
| XTHM-WD <br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.1 <br />
|wfId<br />
|-<br />
| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)<br />
|XTB-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.2<br />
|wfId<br />
|-<br />
| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)<br />
|XCHT-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.3<br />
|wfId<br />
|-<br />
| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)<br />
|XBeR-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.1.4 <br />
|wfId<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| QRPH Profiles<br />
|-<br />
| Early Hearing Detection and Intervention - Workflow Document (EHDI-WD)<br />
| EHDI-WD<br />
| style="color:red" | 1.3.6.1.4.1.19376.1.2.6.2.2.1<br />
|wfId<br />
|-<br />
| colspan="4" style="font-weight: bold; border: 2px solid gray"| RAD Profiles<br />
|-<br />
| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)<br />
|XRR-WD<br />
|1.3.6.1.4.1.19376.1.2.1.41.1<br />
|wfId<br />
|}<br />
<br />
<!--{{T|Profile|Type Code|workflowReferenceId|Title=XDS Metadata by Profile|<br />
Rows=<br />
{{RH|4|PCC Profiles}}<br />
{{R| Cross-Enterprise TeleHomeMonitoring Workflow Definition (XTHM-WD)|code: “XTHM-WD” codingScheme: to be defined|?|?}}<br />
{{R| Cross-Enterprise Tumor Board Workflow Definition (XTB-WD)|code: “XTB-WD” codingScheme: to be defined|?|?}}<br />
{{R| Cross-Enterprise Cardiovascular Heart Team (XCHT-WD)|code: “XCHT-WD” codingScheme: to be defined|?|?}}<br />
{{R| Cross-Enterprise Basic eReferral Workflow Definition (XBeR-WD)|code: “XBeR-WD” codingScheme: to be defined|?|?}}<br />
<br />
{{RH|4|RAD Profiles}}<br />
{{R| Cross-Enterprise Remote Read Workflow Definition (XRR-WD)| code: “XRR-WD” codingScheme: 1.3.6.1.4.1.19376.1.2.1.41.1 | ? | ?}}<br />
<br />
}}--!></div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Profiles&diff=109096Profiles2018-05-03T16:46:34Z<p>Rgioirdano: /* IHE Patient Care Coordination Profiles */</p>
<hr />
<div><!-- EDITORS:<br />
<br />
Please provide user-understandable descriptions that give the gist of the profile in 20 words or less.<br />
<br />
Don't worry about what detail is missing.<br />
Look for words that can be removed without losing the gist of the main function.<br />
These one-line profile descriptions link to full pages where you can elaborate on details and mechanisms.<br />
Don't elaborate on mechanisms in the one-line.<br />
<br />
Don't link to pages that are not based on the [[Profile Overview Template]].<br />
We want this to be a user catalog with consistent format and content.<br />
Technical Documents are linked from other places (including the Specification & See Also sections at the bottom of the Overview)<br />
<br />
--><br />
'''IHE Profiles''' describe specific solutions to integration problems. A profile documents how standards will be used by each system's '''[[Actors]]''' to cooperate to address the problem.<br />
* '''See [http://wiki.ihe.net/index.php/IHE_Profile_Design_Principles_and_Conventions IHE Profile and Design Principles] for guidance when authoring new or updated profiles''' <br />
<br />
Referencing IHE Integration and Content Profiles lets implementers and users be sure they're talking about the same solution without having to restate the many technical details that ensure actual interoperability.<br />
<br />
For convenient reference, each Profile has a short acronym.<br />
<br />
The profiles can also be viewed:<br />
* [[:Category:Profiles| Alphabetically]]<br />
* By Standard: [[:Category:CDA|CDA]], [[:Category:FHIR|FHIR]], [[:Category:DICOM|DICOM]], [[:Category:HL7v2|HL7v2]], [[:Category:XDW|XDW]], [[:Category:DocShare|Document Sharing]]<br />
* By Focus: [[:Category:Security|Security & Privacy]]<br />
<br />
Each [[Domains| domain]] defines and publishes profiles to address interoperability issues related to its clinical and operational scope.<br />
<br />
__TOC__<br />
<br />
<br />
===Symbols Key===<br />
The Profiles listed here may be in one of five states:<br />
: [[Image:Final.gif]] - Final Text - stable<br />
: [[Image:Trial.gif]] - Trial Implementation - frozen for trial use; changes permitted prior to Final Text; not all TI profiles may be listed here<br />
: [[Image:TIBackToPC.gif]] - Public Comment - a Trial Implementation profile republished for Public Comment<br />
: [[Image:Comment.gif]] - Public Comment - new profile published for public comment (not for implementation; description may not be available until TI; not all PC profiles may be listed here)<br />
: [[Image:Retired.gif]] - Deprecated/Retired - no longer recommended or maintained by IHE<br />
Additional Indicators<br />
: [[Image:FHIRDSTU2.png]] - Indicates a FHIR DSTU 2 Profile<br />
: [[Image:FHIRSTU3.png]] - Indicates a FHIR STU 3 Profile<br />
<br />
<br />
A template for developing profile overview pages is [[Profile_Overview_Template|available here]].<br />
<br />
The links below provide brief overviews of each profile (based on the [[Profile Overview Template]]).<br />
<br />
==[[Cardiology| IHE Cardiology]] Profiles [[File:IHE_Cardiology_Logo_thumbnail.jpg |100px| link=Cardiology]]==<br />
<br />
[[Image:Final.gif]] [<span ID='CATH'>CATH</span>] - [[Cardiac Cath Workflow]] integrates ordering, scheduling, imaging acquisition, storage and viewing for Cardiac Catheterization procedures <br />
<br />
[[Image:Final.gif]] [<span ID='ECHO'>ECHO</span>] - [[Echocardiography Workflow]] integrates ordering, scheduling, imaging acquisition, storage and viewing for digital echocardiography<br />
<br />
[[Image:Final.gif]] [<span ID='ECG'>ECG</span>] - [[Retrieve ECG for Display]] provides access throughout the enterprise to electrocardiogram (ECG) documents for review purposes<br />
<br />
[[Image:Final.gif]] [ED] - [[Evidence Documents]] adds Cardiology-specific options to the Radiology ED profile for DICOM Structured Reports <br />
<br />
[[Image:Trial.gif]] [<span ID='STRESS'>STRESS</span>] - [[Stress Testing Workflow]] provides ordering and collecting multi-modality data during diagnostic Stress testing procedures<br />
<br />
[[Image:Trial.gif]] [<span ID='DRPT'>DRPT</span>] - [[Displayable Reports]] manages creation and distribution of “display ready” (PDF or CDA) clinical reports from the creating application, to the department, and to the enterprise.<br />
<br />
[[Image:Trial.gif]] [<span ID='REWF'>REWF</span>] - [[Resting ECG Workflow]] workflow for collecting ECG data in both ordered and unordered procedures, data storage and access, and ECG reporting <br />
<br />
[[Image:Trial.gif]] [<span ID='IEO'>IEO</span>] - [[Image-Enabled Office Workflow]] integrates an imaging suite with an EHR system in an ambulatory office setting, including ordering, imaging, report creation, and web-based imaging exam review.<br />
<br />
[[Image:Trial.gif]] [<span ID='CIRC'>CIRC</span>] - [[Cardiac Imaging Report Content]] format for a CDA report of a cardiac diagnostic imaging procedure, including discrete data elements<br />
<br />
[[Image:Trial.gif]] [<span ID='CPN'>CPN</span>] - [[Cardiac Procedure Note]] implementation guide for a cardiac procedure note, including Cath/PCI, Structural Heart Interventions and Electrophysiology Implant/Explant procedure.<br />
<br />
[[Image:Trial.gif]] [<span ID='CRC'>CRC</span>] - [[Cath Report Content]] format for a CDA report of a cardiac Cath/PCI procedure, including discrete data elements<br />
<br />
[[Image:Trial.gif]] [<span ID='EPRC'>EPRC</span>] - [[Electrophysiology Report Content]] format for a CDA report of a Electropshyiology Implant/Explant Procedure including discrete data elements.<br />
<br />
[[Image:Trial.gif]] [<span ID='RCS-C'>RCS-C</span>] - [[Registry Content Submission-CathPCI]] format for a CDA report to facilitate submission of NCDR® CathPCI V4.4 data elements to the NCDR® CathPCI Registry®.<br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Eyecare| IHE Eye Care]] Profiles==<br />
<br />
[[Image:Retired.gif]] [A-EYECARE] - [[Advanced Eye Care Workflow]] manages and distributes the workflow across equipment within the eye clinic. Includes advanced DICOM features such as DICOM MPPS and Storage Commitment. <br />
<br />
[[Image:Retired.gif]] [B-EYECARE] - [[Basic Eye Care Workflow]] manages and distributes the workflow across equipment within the eye clinic. A sub-set of A-EYECARE.<br />
<br />
[[Image:Retired.gif]] [C-EYECARE] - [[Core Eye Care Workflow]] manages and distributes the workflow across equipment within the eye clinic. Establishes the workflow for when the organization does not integrate a centralized image archive (PACS).<br />
<br />
[[Image:Final.gif]] [U-EYECARE] - [[Unified Eye Care Workflow]] takes the best features of previously defined eye care workflows, combines them into one workflow profile, and provides more flexibility for real world implementation models for systems such as EHRs and PACS.<br />
<br />
[[Image:Final.gif]] [EC-CHG] - [[Eye Care Charge Posting]] collects and posts timely billable claims related to Eye Care procedures.<br />
<br />
[[Image:Final.gif]] [ECED] - [[Eye Care Evidence Documents]] manages observations, measurements, and peri-procedural results.<br />
<br />
[[Image:Final.gif]] [ECDR] - [[Eye Care Displayable Report]] supports the creation, query/retrieve and reading of ubiquitous display–ready eye care reports.<br />
<br />
[[Image:Trial.gif]] [ECAS] - [[Eye Care Appointment Scheduling]] standardizes the means of requesting patient appointments. <br />
<br />
[[Image:Trial.gif]] [GEE] - [[General Eye Evaluation]] defines the C-CDA document collected during a patient's eye examination. <br />
<br />
[[Image:Trial.gif]] [EC-Summary] - [[Eye Care Summary Record]] defines the C-CDA document collected for a patient's eye care summary medical record. <br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[IT Infrastructure| IHE IT Infrastructure]] Profiles==<br />
<br />
Alphabetical by profile name; grouped by [[Profiles#Symbol Key|profile state]].<br />
<br />
[[Image:Final.gif]] [<span ID='ATNA'>ATNA</span>] [[Audit Trail and Node Authentication]] Basic security through (a) functional access controls, (b) defined security audit logging and (c) secure network communications. <br />
<br />
[[Image:Final.gif]] [<span ID='BPPC'>BPPC</span>] [[Basic Patient Privacy Consents]] records a patient's privacy consent acknowledgement (for enforcing privacy appropriate to the use).<br />
<br />
[[Image:Final.gif]] [<span ID='CT'>CT</span>] [[Consistent Time]] synchronizes system clocks and time stamps of computers in a network (median error less than 1 second).<br />
<br />
[[Image:Final.gif]] [<span ID='XCA'>XCA</span>] [[Cross-Community Access]] queries and retrieves patient electronic health records held by other communities. <br />
<br />
[[Image:Final.gif]] [<span ID='XCPD'>XCPD</span>] [[Cross-Community Patient Discovery]] locates communities with electronic health records for a patient and translates patient identifiers across communities.<br />
<br />
[[Image:Final.gif]] [<span ID='XDM'>XDM</span>] [[Cross-enterprise Document Media Interchange]] transfers documents and metadata using CDs, USB memory, or email attachments.<br />
<br />
[[Image:Final.gif]] [<span ID='XDR'>XDR</span>] [[Cross-enterprise Document Reliable Interchange]] exchanges health documents between health enterprises using a web-service based point-to-point push network communication. <br />
<br />
[[Image:Final.gif]] [<span ID='XDS'>XDS</span>] [[Cross Enterprise Document Sharing]] shares and discovers electronic health record documents between healthcare enterprises, physician offices, clinics, acute care in-patient facilities and personal health records.<br />
<br />
[[Image:Final.gif]] [<span ID='XDS-SD'>XDS-SD</span>] [[Cross-enterprise Sharing of Scanned Documents]] shares unstructured electronic documents including scanned legacy paper and film.<br />
<br />
[[Image:Final.gif]] [<span ID='XUA'>XUA</span>] [[Cross-Enterprise User Assertion]] communicates claims about the identity of an authenticated principal (user, application, system...) across enterprise boundaries - Federated Identity.<br />
<br />
[[Image:Final.gif]] [<span ID='XDW'>XDW</span>] [[Cross Enterprise Workflow]] coordinates human and applications mediated workflows across multiple organizations.<br />
<br />
[[Image:Final.gif]] [<span ID='DSG'>DSG</span>] [[Document Digital Signature]] specifies digital signatures for documents.<br />
<br />
[[Image:Final.gif]] [<span ID='DSUB'>DSUB</span>] [[Document Metadata Subscription]] subscribes for metadata-triggered notifications within an XDS Affinity Domain and across communities. <br />
<br />
[[Image:Final.gif]] [<span ID='EUA'>EUA</span>] [[Enterprise User Authentication]] enables single sign-on inside an enterprise by facilitating one name per user for participating devices and software.<br />
<br />
[[Image:Final.gif]] [<span ID='MPQ'>MPQ</span>] [[Multi-Patient Queries]] aggregates queries to a Document Registry for data analysis such as provider accreditation, clinical research trial data collection or population health monitoring. <br />
<br />
[[Image:Final.gif]] [<span ID='PAM'>PAM</span>] [[Patient Administration Management]] establishes the continuity and integrity of patient data in and across acute care settings, as well as among ambulatory caregivers.<br />
<br />
[[Image:Final.gif]] [<span ID='PDQ'>PDQ</span>] [[Patient Demographics Query]] queries by patient demographics for patient identity from a central patient information server.<br />
<br />
[[Image:Final.gif]] [<span ID='PIX'>PIX</span>] [[Patient Identifier Cross Referencing]] queries for patient identity cross-references between hospitals, sites, health information exchange networks, etc.<br />
<br />
[[Image:Final.gif]] [<span ID='PDQv3'>PDQv3</span>] [[Patient Demographics Query HL7 v3]] extends the Patient Demographics Query profile leveraging HL7 version 3. <br />
<br />
[[Image:Final.gif]] [<span ID='PIXv3'>PIXv3</span>] [[Patient Identifier Cross-Reference HL7 v3]] extends the Patient Identifier Cross-Reference profile leveraging HL7 version 3. <br />
<br />
[[Image:Final.gif]] [<span ID='PSA'>PSA</span>] [[Patient Synchronized Application]] allows cooperating applications on a workstation to synchronize to selected patient context. <br />
<br />
[[Image:Final.gif]] [<span ID='PWP'>PWP</span>] [[Personnel White Pages]] provides basic directory information on human workforce members within an organization.<br />
<br />
[[Image:Final.gif]] [<span ID='RFD'>RFD</span>] [[Retrieve Form for Data Capture]] requests forms from clinical trial sponsors and public health reporting.<br />
<br />
[[Image:Final.gif]] [<span ID='RID'>RID</span>] [[Retrieve Information for Display]] provides simple (browser-based) read-only access to clinical information (e.g. allergies or lab results).<br />
<br />
[[Image:Final.gif]] [<span ID='SVS'>SVS</span>] [[Sharing Value Sets]] distributes centrally-managed, common, uniform nomenclatures.<br />
<br />
[[Image:Trial.gif]] [<span ID='APPC'>APPC</span>] [[Advanced Patient Privacy Consents]] defines a structural representation of a patient-specific Privacy Policy.<br />
<br />
[[Image:Trial.gif]] [<span ID='RESTATNA'></span>] [[Add RESTful Query to ATNA]] adds Retrieve capabilities to the Audit Record Repository (ARR). [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='CSD'>CSD</span>] [[Care Services Discovery]] queries directories containing data about organizations, facilities, services, and providers.<br />
<br />
[[Image:Trial.gif]] [<span ID='XCF'>XCF</span>] [[Cross Community Fetch]] fetches a single or small pre-negotiated list of documents from another community.<br />
<br />
[[Image:Trial.gif]] [<span ID='XCDR'>XCDR</span>] [[Cross-Community Document Reliable Interchange (XCDR)]] pushes documents to systems in another community.<br />
<br />
[[Image:Trial.gif]] [<span ID='DEN'>DEN</span>] [[Document Encryption]] encrypts individual documents and portable media content.<br />
<br />
[[Image:Trial.gif]] [<span ID='HPD'>HPD</span>] [[Healthcare Provider Directory]] supports discovery and management of healthcare provider information, both individual and organizational, in a directory structure. <br />
<br />
[[Image:Trial.gif]] [<span ID='IUA'>IUA</span>] [[Internet User Authorization]] provides user authorization for RESTful interfaces. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='mACM'>mACM</span>] [[Mobile Alert Communication Management(mACM)]] provides a RESTful interface to an alert infrastructure. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='MHD'>MHD</span>] [[Mobile access to Health Documents]] provides a RESTful interface to Document Sharing including XDS. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='mCSD'>mCSD</span>] [[Mobile Care Services Discovery (mCSD)]] provides a RESTful interface to discover Care Services: Organization, Location, Practitioner, and Health Services. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='mXDE'>mXDE</span>] [[Mobile Cross-Enterprise Document Data Element Extraction]] accesses data elements extracted from shared structured documents. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='NPFSm'>NPFSm</span>] [[Non-patient File Sharing (NPFSm)]] provides a RESTful interface enable sharing of non-patient files such as clinical workflow definitions, domain policies, and stylesheets. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PDQm'>PDQm</span>] [[Patient Demographics Query for Mobile (PDQm)]] provides a RESTful interface to a patient demographics supplier. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PIXm'>PIXm</span>] [[Patient Identifier Cross-Reference for Mobile (PIXm)]] provides a RESTful interface to patient identifier cross-references. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PLT'>PLT</span>] [[Patient Location Tracking]] tracks the location of a patient within a facility.<br />
<br />
[[Image:Trial.gif]] [<span ID='RMD'>RMD</span>] [[Remove Metadata and Documents (RMD)]] removes documents and related metadata.<br />
<br />
[[Image:Trial.gif]] [<span ID='SeR'>SeR</span>] [[Secure Retrieve]] defines a model for Access Control for XDS environments that have a centralized Access Control Decision, with Document Repository enforcement.<br />
<br />
[[Image:Trial.gif]] [<span ID='XAD-PID Change Management'>XPID</span>] [[XAD-PID Change Management]] updates the relationship between XDS Affinity Domain patient identifiers and other patient identifiers.<br />
<br />
[[Image:Retired.gif]] [<span ID='DRR'>DRR</span>] [[Document-based Referral Request]] transfers referral requests by document sharing (e.g., XDS, XDR, XDM).<br />
<br />
[[Image:Retired.gif]] [<span ID='NAV'>NAV</span>] [[Notification of Document Availability]] supports out-of-band notifications of documents of interest between systems or users.<br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Pathology and Laboratory Medicine | IHE Pathology and Laboratory Medicine (PaLM)]] Profiles==<br />
[[Image:Trial.gif]] [APW] - [[Anatomic Pathology Workflow]] integrates ordering, imaging and reporting for basic pathology exams.<br />
<br />
[[Image:Trial.gif]] [ARPH] - [[Anatomic Pathology Reporting to Public Health]] transmits anatomic pathology reports to public health organizations (cancer registries, centers for diseases control, screening organizations, etc).<br />
<br />
[[Image:TIBackToPC.gif]] [APSR] - [[Anatomic Pathology Structured Report]] templates anatomic pathology structured reports for cancers, benign neoplasms and non-neoplastic conditions.<br />
<br />
[[Image:Final.gif]] [LTW] - [[Laboratory Testing Workflow]] integrates ordering and performance of in-vitro diagnostic tests by a clinical laboratory inside a healthcare institution. <br />
<br />
[[Image:Final.gif]] [XD-LAB] - [[Sharing Laboratory Reports]] describes the content (human and machine readable) of an electronic clinical laboratory report.<br />
<br />
[[Image:Final.gif]] [LDA] - [[Laboratory Device Automation]] integrates an Automation Manager and robotic laboratory equipment (pre-analytical devices, analyzers, post-analytical devices) in a clinical lab. <br />
<br />
[[Image:Final.gif]] [LBL] - [[Laboratory Barcode Labeling]] integrates robotic specimen container labeling systems with sources of order-related labelling information.<br />
<br />
[[Image:Final.gif]] [LPOCT] - [[Laboratory Point Of Care Testing]] integrates performing and collecting the results of in-vitro testing at the point of care or patient’s bedside. <br />
<br />
[[Image:Final.gif]] [LCSD] - [[Laboratory Code Sets Distribution]] distributes managed sets of clinical laboratory codes (battery, test and observation codes).<br />
<br />
[[Image:Trial.gif]] [ILW] - [[Inter Laboratory Workflow]] supports the workflow of orders and results with a subcontracting laboratory.<br />
<br />
[[Image:Final.gif]] [LAW] - [[Laboratory Analytical Workflow Profile]] supports the workflow of test orders and results with IVD specimens on Analyzers.<br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Patient Care Coordination| IHE Patient Care Coordination]] Profiles==<br />
<br />
Alphabetical by profile name; grouped by [[Profiles#Symbol Key|profile state]].<br />
<br />
[[Image:Final.gif]] [<span ID='XDS-MS'><span ID='XDS-MS'>XDS-MS</span></span>] [[Medical Summaries Profile|Cross Enterprise Sharing of Medical Summaries]] describes the content and format of Discharge Summaries and Referral Notes. <br />
<br />
[[Image:Final.gif]] [<span ID='EDR'>EDR</span>] [[Emergency Department Referral Profile|Emergency Department Referral]] communicates medical summary data from an EHR System to an EDIS System. <br />
<br />
[[Image:Final.gif]] [<span ID="XPHR">XPHR</span>] [[Exchange of Personal Health Record Content Profile|Exchange of Personal Health Record]] describes the content and format of summary information extracted from a PHR system for import into an EHR system, and visa versa. <br />
<br />
[[Image:Final.gif]] [<span ID='IC'>IC</span>] [[Immunization Content|Immunization Content]] describes the content and format of documents for exchange of immunization data.<br />
<br />
[[Image:Trial.gif]] [<span ID='APE'>APE</span>] [[Antepartum_Profiles|Antepartum Education]] records educational material provided during the office visit(s) for the antepartum episode.<br />
<br />
[[Image:Trial.gif]] [<span ID='APHP'>APHP</span>] [[Antepartum_Profiles|Antepartum History and Physical]] records data often collected at the initial ambulatory office visit for a pregnant patient.<br />
<br />
[[Image:Trial.gif]] [<span ID='APS'>APS</span>] [[Antepartum Care Summary Profile|Antepartum Summary]] records the aggregation of significant events, diagnoses, and plans of care during an antepartum episode.<br />
<br />
[[Image:Trial.gif]] [<span ID='APL'>APL</span>] [[Antepartum_Profiles|Antepartum Laboratory]] records results from standard laboratory tests administered during an antepartum episode.<br />
<br />
[[Image:Trial.gif]] [<span ID='BED'>BED</span>] [[Bed Management]] augments ITI PAM to communicate bed management for admissions.<br />
<br />
[[Image:Trial.gif]] [<span ID='CM'>CM</span>] [[Care Management Profile|Care Management]] exchanges information to manage care for specific conditions.<br />
<br />
[[Image:Trial.gif]] [<span ID='CMAP'>CMAP</span>] [[Clinical Mapping]] translates codes from one terminology to another for exchange of information between systems. [[Image:FHIRDSTU2.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='XCHT-WD'>XCHT-WD</span>] [[Cross Enterprise Cardiovascular Heart Team]] orchestrates the creation of a dynamic network of cardiovascular professionals called a Heart Team.<br />
<br />
[[Image:Trial.gif]] [<span ID='DCP'>DCP</span>] [[Dynamic Care Planning]] shares and updates patient care plans.[[Image:FHIRDSTU2.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='DCTM'>DCTM</span>] [[Dynamic Care Team Management]] shares information about a patient's care teams.[[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='XBeR-WD'>XBeR-WD</span>] [[Cross-enterprise Basic eReferral Workflow Definition|Cross-enterprise Basic eReferral Workflow Definition]]<br />
<br />
[[Image:Trial.gif]] [<span ID='XTHM-WD'>XTHM-WD</span>] [[Cross-enterprise TeleHome Monitoring Workflow Definition|Cross-enterprise TeleHome Monitoring Workflow Definition]]<br />
<br />
[[Image:Trial.gif]] [<span ID='XTB-WD'>XTB-WD</span>] [[Cross-enterprise Tumor Board Workflow Definition|Cross-enterprise Tumor Board Workflow Definition]]<br />
<br />
[[Image:Trial.gif]] [<span ID='CTNN'>CTNN</span>] [[Emergency Department Encounter Summary|Emergency Department Encounter Summary Composite Triage and Nursing Note]] records both triage and nursing care delivered to a patient in the emergency department.<br />
<br />
[[Image:Trial.gif]] [<span ID='EDPN'>EDPN</span>] [[Emergency Department Encounter Summary|Emergency Department Encounter Summary ED Physician Note]] records care delivered to a patient in the emergency department.<br />
<br />
[[Image:Trial.gif]] [<span ID='NN'>NN</span>] [[Emergency Department Encounter Summary|Emergency Department Encounter Summary Nursing Note]] records nursing care delivered to a patient in the emergency department.<br />
<br />
[[Image:Trial.gif]] [<span ID='TN'>TN</span>] [[Emergency Department Encounter Summary|Emergency Department Encounter Summary Triage Note]] records triage of a patient upon presentation to the emergency department.<br />
<br />
[[Image:Trial.gif]] [<span ID='ETS'>ETS</span>] [[EMS Transport Summary]] shares information during situations where patients are being transported to a hospital emergency department facility.<br />
<br />
[[Image:Trial.gif]] [<span ID='ITS'>ITS</span>] [[Interfacility Transport Summary]] shares information during situations where patients are being transported between two healthcare facilities.<br />
<br />
[[Image:Trial.gif]] [<span ID='LDHP'>LDHP</span>] [[Labor and Delivery History and Physical]] records data often collected during initial admission to a birthing facility.<br />
<br />
[[Image:Trial.gif]] [<span ID='DCP'>MCV</span>] [[Multiple Content Views]] tags CDA text to achieve different rendering behaviors. <br />
<br />
[[Image:Trial.gif]] [<span ID='PMDT'>PMDT</span>] [[Point-of-Care Medical Device Tracking]] records medical device information acquired at the point-of-care. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='DCP'>RECON</span>] [[Reconciliation of Clinical Content and Care Providers]] communicates lists of clinical data that were reconciled, who did the reconciliation and when. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='DCP'>ROL</span>] [[Referral Order Linking]] communicates and links the referral and/or order number in documentation and metadata associated with services requested by an order placer<br />
<br />
[[Image:Trial.gif]] [<span ID='QED'>QED</span>] [[Query for Existing Data]] queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance. <br />
<br />
[[Image:Trial.gif]] [<span ID='QEDm'>QEDm</span>] [[Query for Existing Data for Mobile]] queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='RIPT'>RIPT</span>] [[Routine Interfacility Patient Transport]] supports interoperability between systems used on transport vehicles between healthcare facilities. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
<!-- EDITORS: Uncomment the following entries when the linked Profile page is filled in and they have a one line description (see notes at top of this page)<br />
[[Image:TIBackToPC.gif]] [<span ID='RPM'>RPM</span>] [[Remote Patient Monitoring]]<br />
<br />
[[Image:Retired.gif]] [<span ID='ETC'>ETC</span>] [[EMS Transfer of Care]]<br />
<br />
[[Image:Trial.gif]] [<span ID='ENS'>ENS</span>] [[eNursing Summary]]<br />
<br />
[[Image:Trial.gif]] [<span ID='GAO'>GAO</span>] [[Guideline Appropriate Ordering]] <br />
<br />
[[Image:Trial.gif]] [<span ID='LDS'>LDS</span>] [[Labor and Delivery Summary]] records data often collected during the labor and delivery period at a birthing facility.<br />
<br />
[[Image:Trial.gif]] [<span ID='MDS'>MDS</span>] [[Maternal Discharge Summary]] records data often collected post-delivery until discharge from the birthing facility.<br />
<br />
[[Image:Trial.gif]] [<span ID='NDS'>NDS</span>] [[Newborn Discharge Summary]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PPOC'>PPOC</span>] [[Patient Plan of Care]] exchanges data related to creating and managing individualized patient care.<br />
<br />
[[Image:Trial.gif]] [<span ID='PPVS'>PPVS</span>] [[Postpartum Visit Summary]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PtCP'>PtCP</span>] [[Patient Care Plan]]<br />
<br />
[[Image:Trial.gif]] [<span ID='PW'>PW</span>] [[Perinatal Workflow]]<br />
<br />
[[Image:Trial.gif]] [<span ID='QED'>QED</span>] [[Query for Existing Data]] queries data repositories for clinical information on vital signs, problems, medications, immunizations, and diagnostic results.<br />
<br />
[[Image:Trial.gif]] [<span ID='RCG'>RCG</span>] [[Request for Clinical Guidance]] obtains decision support when ordering medications, determining appropriate immunizations, diagnostic tests, et cetera. <br />
<br />
[[Image:Trial.gif]] [<span ID='RCK'>RCK</span>] [[Retrieve Clinical Knowledge]]<br />
<br />
<br />
--><br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Patient_Care_Devices| IHE Patient Care Device]] Profiles==<br />
<br />
[[Image:Final.gif]] [DEC] [[PCD_Profile_DEC_Overview|Device Enterprise Communication]] transmits information from medical devices at the point of care to enterprise applications.<br />
<br />
[[Image:Final.gif]] [PIV] [[PCD_Profile_Point-of-Care_Infusion_Verification_Overview| Point of Care Infusion Verification]] communicates medication orders to an infusion pump or pump management system.<br />
<br />
[[Image:Final.gif]] [IDCO] [[PCD_Profile_Implantable_Device_Cardiac_Observation|Implantable Device Cardiac Observation]] transfers information from an interrogated implantable cardiac device to information management system.<br />
<br />
[[Image:Final.gif]] [RTM] [[PCD_Profile_Rosetta_Terminology_Mapping_Overview | Rosetta Terminology Mapping]] harmonizes ISO/IEEE 11073-10101 nomenclature standard terms used in PCD transactions.<br />
<br />
[[Image:Final.gif]] [ACM] [[PCD Profile Alert Communication Management Overview | Alert Communication Management]] communicates alerts (alarms - physiological or technical, or advisories), ensuring the right alert with the right priority gets to the right individuals with the right content.<br />
<br />
[[Image:Trial.gif]] [RDQ] [[PCD Profile Retrospective Data Query (RDQ) Overview | Retrospective Data Query]] queries archived point-of-care device observations for clinical decision support or other data analysis purposes.<br />
<br />
<!-- Please refer to editors instructions at the top of this wiki page.<br />
The links here should be to user-oriented pages based on the Profile Overview Template.<br />
Supplement Documents are linked elsewhere.<br />
Keep descriptions brief. Elaborate in the overview.<br />
--><br />
[[Image:Trial.gif]] [IPEC] [[Infusion Pump Event Communication]] communicates clinical and technical events from an infusion pump to an information system for recording, action or presentation to a user.<br />
<br />
[[Image:Trial.gif]] [WCM] [[PCD Profile Waveform Content Module (WCM) | Waveform Content Module]] includes waveform data in IHE PCD profiles such as DEC and ACM.<br />
<br />
[[Image:Trial.gif]] [POI] [[Pulse Oximetry Integration | Pulse Oximetry Integration]] guides implementation of pulse oximetry devices using IHE PCD profiles.<br />
<br />
[[Image:Trial.gif]] [MEMDMC] [[MEM-DMC | Device Management Communication]] sends device information and status observations to CMMS/CEMS for equipment management purposes.<br />
<br />
[[Image:Trial.gif]] [MEMLS] [[MEM-LS | Location Services]] abstracts device and people location observations and events from location tracking implementation technology.<br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Pharmacy| IHE Pharmacy]] Profiles==<br />
<br />
[[Image:Trial.gif]] [<span ID='CMPD'>CMPD</span>] [[Community Medication Prescription and Dispense]] integrates prescription, validation and dispensation of medication in the ambulatory sector.<br />
<br />
[[Image:Trial.gif]] [<span ID='MTP'>MTP</span>] [[Community Medication Treatment Plan]] Document records the planning of medication to a patient. <br />
<br />
[[Image:Trial.gif]] [<span ID='PRE'>PRE</span>] [[Community Prescription]] Document records a prescription to a patient.<br />
<br />
[[Image:Trial.gif]] [<span ID='PADV'>PADV</span>] [[Community Pharmaceutical Advice]] Document records a pharmaceutical advice (validation outcome, management command, etc.) in response to a planned or prescribed medication. <br />
<br />
[[Image:Trial.gif]] [<span ID='DIS'>DIS</span>] [[Community Dispense]] Document records the dispensation of medication to a patient. <br />
<br />
[[Image:Trial.gif]] [<span ID='CMA'>CMA</span>] [[Community Medication Administration]] Document records the administration of medication to a patient. <br />
<br />
[[Image:Trial.gif]] [<span ID='PML'>PML</span>] [[Community Medication List]] carries a list of planned, prescribed, dispensed or administered medication to a patient. <br />
<br />
[[Image:Trial.gif]] [<span ID='HMW'>HMW</span>] [[Hospital Medication Workflow]] integrates prescription, validation, dispensation, distribution and administration of medication inside healthcare institutions.<br />
<br />
[[Image:Trial.gif]] [<span ID='MMA'>MMA</span>] [[Mobile Medication Administration]] connects EHRs with devices such as smartphones and smart pill boxes using RESTful web services. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [<span ID='UBP'>UBP</span>] [[Uniform Barcode Processing]] returns a FHIR resource (for a medication, device, patient, etc) corresponding to a submitted barcode.[[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
<!-- EDITORS: Uncomment the following entries when the linked Profile page is filled in and they have a one line description (see notes at top of this page)<br />
--><br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Quality| IHE Quality, Research, and Public Health]] Profiles==<br />
<br />
[[Image:Trial.gif]] [ADX] [[Aggregate Data Exchange]] captures and communicates information for birth and fetal death reporting for vital registration purposes.<br />
<br />
[[Image:Comment.gif]] [ADX-HIV] [[Aggregate Data Exchange - HIV]] describes content used with the ADX profile for transmission of HIV information.<br />
<br />
[[Image:Retired.gif]] [BFDR] [[Birth and Fetal Death Reporting]] describes the content and format used in the pre-population data part of the Retrieve Form Request transaction from the RFD Integration Profile.<br />
<br />
[[Image:Trial.gif]] [BFDR-E] [[Birth and Fetal Death Reporting Enhanced Profile]] captures and communicates information for birth and fetal death reporting for vital registration purposes. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Final.gif]] [CRD] [[Clinical Research Document]] describes the content pertinent to the clinical research use case required within the Retrieve Form for Data-Capture (RFD) pre-population parameter.<br />
<br />
[[Image:Trial.gif]] [CRPC] [[Clinical Research Process Content]] specifies content, which is appropriate to help automate the sharing of information among systems during the clinical research process using the transactions from the Retrieve Process for Execution (RPE) profile. Using the transactions from the Retrieve Process for Execution (RPE) profile, CRPC will improve the recruitment for, setup, and performance of clinical studies.<br />
<br />
[[Image:Trial.gif]] [DEX] [[Data Element Exchange]] adds mapping metadata to an annotated data capture form at the point of form design instead of the exchange of data instances.<br />
<br />
[[Image:Final.gif]] [DSC] [[Drug Safety Content]] describes the content pertinent to the drug safety use case required within the Retrieve Form for Data-Capture (RFD) pre-population parameter. <br />
<br />
[[Image:Trial.gif]] [FP] [[Family Planning]] describes the use of ITI’s RFD to report encounter-level family planning clinical visits. The profile describes the basic data elements that are needed to report quality metrics, a new Family Planning Pre-pop document in alignment with PCC conventions, and maps the data elements to CDA (consisting of the Header, Pregnancy History, Pregnancy Status Review, Coded Vital Signs, Coded Social History, Coded Care Plan, and Coded Results sections).<br />
<br />
[[Image:Trial.gif]] [HW] [[Healthy Weight]] supports electronic information capture and exchange for managing and monitoring healthy weight among clinical systems and public health surveillance systems.<br />
<br />
[[Image:Trial.gif]] [mRFD] [[Mobile Retrieve Form for Data Capture]] describes the exchange of context data to allow a seamless form launch with supporting clinical context. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Trial.gif]] [PRPH-Ca] [[Physician Reporting to a Public Health Repository – Cancer Registry]] defines data elements retrieved from the EMR and transmitted to the cancer registry or to a healthcare provider.<br />
<br />
[[Image:Comment.gif]] [QORE] [[Quality Outcome Reporting for EMS]] describes content used for continuity of care between the emergency transport scene records and destination hospital where the emergency will be treated. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
[[Image:Retired.gif]] [RSP] [[Redaction Services]] redacts data from a document in a user's application to meet requirements for exporting to an external system.<br />
<br />
[[Image:Retired.gif]] [RM] [[Research Matching]] publishes research process definitions to EHR systems to match patients and investigators with appropriate research studies.<br />
<br />
[[Image:Trial.gif]] [RPE] [[Retrieve Process for Execution]] accesses a process definition, such as a research protocol, and executes automated activities without leaving an EMR session.<br />
<br />
[[Image:Trial.gif]] [SDC] [[Structured Data Capture]] utilizes the IHE Retrieve Form for Data Capture (RFD) profile for retrieving and submitting forms in a standardized and structured format. This supplement is based on the work of the US Office of the National Coordinator for Health Information Technology, Standards & Interoperability (S&I) Framework SDC Initiative.<br />
<br />
[[Image:Trial.gif]] [VRDR] [[Vital Records Death Reporting]] defines a Retrieve Form for Data Capture (RFD) content profile that will specify derivation of source content from a medical summary document. by defining requirements for form filler content and form manager handling of the content. [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
'''Early Hearing Detection and Intervention Family of Profiles'''<br />
<br />
[[Image:Retired.gif]] [EHCP] [[Early Hearing Care Plan]] communicates care plans to care providers to assist early detection, documentation and intervention for hearing loss.<br />
<br />
[[Image:Trial.gif]] [EHDI-HPoC] [[Early Hearing Detection and Intervention-Hearing Plan of Care]] communicates care plan information to assist early detection, and document interventions for hearing loss. <br />
<br />
[[Image:Trial.gif]] [EHDI-HSDmsg] [[Early Hearing Detection and Intervention-Hearing Screening Device Message]] automates collection of hearing screening results from screening devices.<br />
<br />
[[Image:Trial.gif]] [EHDI-WD] [[Early Hearing Detection and Intervention-Workflow Document]] orchestrates the collection and exchange of EHDI data between clinical and public health information systems. <br />
<br />
[[Image:Final.gif]] [NANI] [[Newborn Admission Notification Information]] transfers basic newborn demographic data electronically to public health programs from a birthing facility. <br />
<br />
[[Image:Trial.gif]] [QME-EH] [[Quality Measure Execution-Early Hearing]] communicates patient-level data to electronically monitor the performance of early hearing detection and intervention (EHDI) initiatives for newborns.<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Radiation Oncology| IHE Radiation Oncology]] Profiles==<br />
<br />
[[Image:Final.gif]] [BRTO] [[Basic Radiation Therapy Objects]] integrate the flow of treatment planning data from CT to Dose Review for basic treatments<br />
<br />
[[Image:Retired.gif]] [MMRO] [[Multimodality Image Registration for Radiation Oncology]] integrates PET and MRI data into the contouring and dose review process.<br />
<br />
[[Image:Final.gif]] [MMRO-II] [[Multimodality Image Registration for Radiation Oncology 2012]] updates MMRO to accommodate a change in the DICOM Spatial Registration Object and to require reference images for a Frame of Reference <br />
<br />
<!--<br />
[[Image:Draft.gif]] [MMRO-III] [[Multimodality Image Registration for Radiation Oncology 2013]] extends MMRO-II to allow additional modalities other than CT as the primary dataset <br />
--><br />
[[Image:Trial.gif]] [ARTI] [[Advanced Radiotherapy Objects Interoperability]] adds additional RT treatment techniques to those defined in BRTO<br />
<br />
[[Image:Final.gif]] [TDW] [[RT_Treatment_Delivery_Workflow | Treatment Delivery Workflow]] standards-based radiation therapy treatment scheduling using workflow<br />
<br />
[[Image:Trial.gif]] [TDW-II] [[RT_Treatment_Delivery_Workflow-II | Treatment Delivery Workflow-II]] updates TDW to accommodate changes in DICOM Supplements 74 and 96<br />
<br />
[[Image:Trial.gif]] [DCOM] [[Dose Compositing]] transfers spatially-related dose information between systems.<br />
<br />
[[Image:Trial.gif]] [ECSI] Enterprise-Centric Scheduling Interoperability describes a Radiation Oncology workflow where scheduling information is handled by an institution-wide information system and exchanged with a TMS<br />
<br />
[[Image:Trial.gif]] [QAPV] [[Quality Assurance with Plan Veto]] describes a Radiation Oncology workflow where a Treatment Delivery Device verifies the correctness of Delivery Instructions just prior to treatment<br />
<br />
[[Image:Trial.gif]] [IPDW] Integrated Patient Positioning and Delivery Workflow describes delivery workflow for a Treatment Delivery Device (TDD) with an integrated positioning system<br />
<br />
<!-- EDITORS: As indicated in the Key, this page is for Profiles in Final Text or Trial Implementation. When Profiles are still being drafted, they are managed on the Domain Pages of the relevant Domain <br />
<br />
[[Image:Draft.gif]] [DPDW] [[Discrete Patient Positioning and Delivery Workflow]] describes delivery workflow for a Treatment Delivery Device (TDD) and discrete (separate positioning system(s)<br />
<br />
[[Image:Draft.gif]] [CPRO] [[Consistent Patient Identification in Radiation Oncology]] describes information exchange between a Treatment Management System (TMS) and other RO systems for consistent identification of patients in radiation oncology<br />
<br />
[[Image:Draft.gif]] [ROIT] [[Region-of-Interest Templates in Radiation Oncology]] describes templates for RT Structure Sets for consistent structure identification and coding<br />
<br />
[[Image:Draft.gif]] [QRRO] [[Query/Retrieve in Radiation Oncology]] describes Q/R structures for radiation oncology objects<br />
<br />
[[Image:Draft.gif]] [TDPC] [[Treatment Delivery - Plan Content]] defines the information necessary in an RT Plan when being transferred to a Treatment Delivery Device (TDD) <br />
<br />
[[Image:Draft.gif]] [TPPC] [[Treatment Planning - Plan Content]] defines the information necessary in an RT Plan during the planning process and transfer to a Treatment Management System (TMS)<br />
<br />
[[Image:Draft.gif]] [TDIC] [[Treatment Delivery - Image Content]] describes the information necessary in a verification image when it is transferred to a Treatment Delivery Device (TDD)<br />
<br />
[[Image:Draft.gif]] [TPIC] [[Treatment Planning - Image Content]] describes the information necessary in a verification image during the planning process and transfer to a Treatment Management System (TMS) <br />
<br />
[[Image:Draft.gif]] [RXRO] [[Prescription in Radiation Oncology]] describes the information necessary for transfer of a radiation oncology prescription between RO systems <br />
--><br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]<br />
<br />
==[[Radiology| IHE Radiology]] Profiles==<br />
<br />
:'''Profiles for Workflow''' <br />
<br />
[[Image:Final.gif]] [SWF] [[Scheduled Workflow]] integrates ordering, scheduling, imaging acquisition, storage and viewing for Radiology exams.<br />
<br />
[[Image:Final.gif]] [PIR] [[Patient Information Reconciliation]] coordinates reconciliation of the patient record when images are acquired for unidentified (e.g. trauma), or misidentified patients.<br />
<br />
[[Image:Final.gif]] [PWF] [[Post-Processing Workflow]] provides worklists, status and result tracking for post-acquisition tasks, such as Computer-Aided Detection or Image Processing.<br />
<br />
[[Image:Final.gif]] [RWF] [[Reporting Workflow]] provides worklists, status and result tracking for reporting tasks, such as dictation, transcription and verification.<br />
<br />
[[Image:Final.gif]] [IRWF] [[Import Reconciliation Workflow]] manages importing images from CDs, hardcopy, XDS-I, etc. and reconciling identifiers to match local values.<br />
<br />
[[Image:Trial.gif]] [MAWF] Mammography Acquisition Workflow handles mammography-specific exceptions to routine image acquisition based on Scheduled Workflow.<br />
<br />
[[Image:Trial.gif]] [PAWF] Post-Acquisition Workflow provides worklists, status and result tracking for post-acquisition tasks and application hosting.<br />
<br />
:'''Profiles for Content''' <br />
<br />
[[Image:Final.gif]] [NMI] [[Nuclear Medicine Image]] specifies how Nuclear Medicine images and result screens are created, exchanged, used and displayed.<br />
<br />
[[Image:Final.gif]] [MAMMO] [[Mammography Image]] specifies how Mammography images and evidence objects are created, exchanged, used and displayed.<br />
<br />
[[Image:Final.gif]] [ED] [[Evidence Documents]] specifies how data objects such as digital measurements are created, exchanged, and used.<br />
<br />
[[Image:Final.gif]] [SINR] [[Simple Image and Numeric Report]] specifies how Diagnostic Radiology Reports (including images and numeric data) are created, exchanged, and used.<br />
<br />
[[Image:Final.gif]] [REM] [[Radiation Exposure Monitoring]] specifies how radiation details from imaging procedures are created, exchanged and used.<br />
<br />
[[Image:Trial.gif]] [REM-NM] [[Radiation Exposure Monitoring for Nuclear Medicine]] specifies how radiation details from procedures using radiopharmaceuticals are created, exchanged and used.<br />
<br />
[[Image:Trial.gif]] [PERF] [[CT/MR Perfusion Imaging]] specifies encoding of Contrast Perfusion imaging data using Enhanced CT/MR DICOM objects.<br />
<br />
[[Image:Trial.gif]] [DIFF] [[MR Diffusion Imaging]] specifies encoding of MR Diffusion imaging data using Enhanced MR DICOM objects.<br />
<br />
[[Image:Trial.gif]] [CXCAD] Chest X-ray CAD display specifies how Chest X-Ray images and evidence objects are created, exchanged, used and displayed.<br />
<br />
[[Image:Trial.gif]] [DBT] [[Digital Breast Tomosynthesis]] specifies how Mammography and Digital Breast Tomography images and evidence objects are created, exchanged, used and displayed.<br />
<br />
:'''Profiles for Presentation''' <br />
<br />
[[Image:Final.gif]] [KIN] Key Image Note lets users flag images as significant (e.g. for referring, for surgery, etc.) and add notes.<br />
<br />
[[Image:Final.gif]] [CPI] [[Consistent Presentation of Images]] maintains consistent intensity and image transformations between different hardcopy and softcopy devices.<br />
<br />
[[Image:Final.gif]] [PGP] [[Presentation of Grouped Procedures]] helps view and report individual requested procedures (e.g. head, chest, abdomen) that an operator has grouped into a single scan.<br />
<br />
[[Image:Trial.gif]] [FUS] Image Fusion integrates systems creating, registering and displaying fused image sets and storing their results.<br />
<br />
[[Image:Trial.gif]] [BIR] [[Basic Image Review]] defines baseline features and user interface for simple review of DICOM images.<br />
<br />
:'''Profiles for Infrastructure''' <br />
<br />
[[Image:Final.gif]] [PDI] [[Portable Data for Imaging]] stores image data and diagnostic reports on CDs, DVDs or USB for importing, printing or displaying in a browser.<br />
<br />
[[Image:Final.gif]] [XDS-I.b] [[Cross-enterprise Document Sharing for Imaging]].b extends XDS to share images, diagnostic reports and related information across a group of care sites.<br />
<br />
[[Image:Final.gif]] [TCE] [[Teaching File and Clinical Trial Export]] lets users flag images and related information for automatic routing to teaching file authoring or clinical trials management systems.<br />
<br />
[[Image:Final.gif]] [ARI] [[Access to Radiology Information]] shares images, diagnostic reports, and related information inside a single network.<br />
<br />
[[Image:Final.gif]] [ATNA] [[Audit Trail and Node Authentication - Radiology Option]] defines Radiology-specific audit trail messages and security measures to protect patient information confidentiality.<br />
<br />
[[Image:Final.gif]] [CHG] [[Charge Posting]] provides timely procedure details from modalities to billing systems.<br />
<br />
[[Image:Final.gif]] [XCA-I] [[Cross-Community Access for Imaging]] extends XCA to share images, diagnostic reports and related information across communities.<br />
<br />
[[Image:Trial.gif]] [XDR-I] Cross-Enterprise Reliable Document Interchange for Imaging extends XDR to push images, diagnostic reports and related information between healthcare providers.<br />
<br />
[[Image:Final.gif]] [IOCM] [[Imaging Object Change Management]] communicates image replacement or deletion instructions between multiple imaging systems.<br />
<br />
[[Image:Trial.gif]] [IID] [[Invoke Image Display]] allows an EHR/PHR/RIS to request a PACS (IM/IA/ID) to display images of a patient or study.<br />
<br />
[[Image:Trial.gif]] [CDS-OAT] [[Clinical Decision Support Order Appropriateness Tracking]] communicates Appropriate Use Criteria (AUC) results downstream for inclusion in reporting and billing.<br />
<br />
[[Image:Trial.gif]] [WIC] [[Web-based Image Capture]] stores imaging objects using a DICOM RESTful API.<br />
<br />
[[Image:Trial.gif]] [SOLE] [[Standardized Operational Log of Events]] stores and retrieves logs of operational events (patient arrives, scan complete, etc). [[Image:FHIRSTU3.png|40px| link=Category:FHIR]]<br />
<br />
:[[Profiles#Symbol Key|'''*Symbol Key''']]</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Cross-enterprise_TeleHome_Monitoring_Workflow_Definition&diff=109075Cross-enterprise TeleHome Monitoring Workflow Definition2018-05-02T23:48:16Z<p>Rgioirdano: /* Details */</p>
<hr />
<div>This supplement is written according to the specific template defined for Workflow Definition profiles. The structure of this document differs from a PCC Content Profile. In particular the XTHM-WD Profile establishes a common set of rules to share between participants involved in a telemonitoring workflow. The telemonitoring process, and workflow related to it, is applicable to many different sharing infrastructures. In this profile we present a specific XDS based use-case.<br />
<br />
__TOC__<br />
<br />
==Summary==<br />
''<Describe the profile in about a paragraph using user-oriented language. Focus on what it accomplishes for a user (i.e. the Use Cases). Don't get into how it works, leave that to the Details section.>''<br />
<br />
''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about. Do not use an actor/transaction diagram here. Show your graphic to someone for 5 seconds (literally) and ask them what it's about. If what they say hits the main points in your summary paragraph, you have succeeded. E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them. .>''<br />
<br />
''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>''<br />
<br />
==Benefits==<br />
The workflow related to the management of patients with chronic diseases (e.g., heart failure, COPD, diabetes) followed by a telemonitoring service is a cross-enterprise workflow since many different individuals from different enterprises can be involved: specialists and physicians, working in hospitals, rural areas or urban areas, general practitioners (GP), and general caregivers, as well as the telemonitoring centre’s staff. <br />
<br />
For the correct management of these patients, each of these individuals, managing his part of the telemonitoring workflow, should have also the possibility to share and manage the patient’s complete clinical history. However, at the moment there are no technical specifications allowing this to be done in a standardized manner. <br />
<br />
This profile provides guidelines to define this kind of cross-enterprise workflow using the XDW profile, allowing every participant involved in a patient's care to share the complete telemonitoring workflow, including all related documents produced for each event occurring during the process (data sending, request for a visit, change of therapy), and the related workflow status.<br />
<br />
This proposal focuses on the Cross Enterprise TeleHomeMonitoring Workflow Definition in<br />
support of telemonitoring workflow document and status management. <br />
<br />
The key elements are:<br />
* managing telemonitoring cross-enterprise workflow, tracking all events and related documents;<br />
* managing workflow specific status with relationship to one or more documents;<br />
* tracking status of all events in telemonitoring process (in progress, completed, etc.). <br />
<br />
With the increase in the elderly population and the consequent increase in the prevalence of patients with chronic diseases (as diabetes, chronic heart failure and COPD), the introduction of a telemonitoring service for these patients, with good workflow management, as defined in this profile, would entail a considerable advantage in terms of quality of life for patients and cost savings. <br />
<br />
To demonstrate the scale of the problem, an analysis has been performed on some European data about the most relevant chronic diseases: now COPD affects approximately 44 million people (Eur Respir J 2011); heart failure affects about 15 million people (ESC 2008). The introduction of a telemonitoring service for these patients, with good workflow management, as defined in this profile, would entail a considerable advantage in terms of quality of life for patients and cost savings.<br />
<br />
==Details==<br />
<br />
The general telemonitoring process flow can be described with the following steps:<br />
<br />
'''A.''' The Telemonitoring process starts when a GP or a general caregiver requests the activation of a telemonitoring service for his patient to a telemonitoring service provider. In this initial phase of the process the GP defines the telemonitoring protocol for the patient and produces a telemonitoring Workflow Document with a “Request Activation” task as the first entry.<br />
<br />
'''B.''' The service provider now evaluates and approves the physician's request and activates the service; the workflow document is updated with a new “Approve Request” task. <br />
<br />
'''C.''' The patient starts to collect the required clinical parameters at his home or place of residence. The data collected is transmitted to the service provider that manages the data, making them available to any clinicians involved in the process. The Workflow Document is updated with a “Telemonitoring” task.<br />
<br />
'''D.''' If the data sent by the patient goes outside the threshold levels defined in the protocol, the service provider alerts the referring physician and updates the Workflow Document with a “Consult Request” task.<br />
<br />
'''E.''' The physician analyses the patient's data and decides if the patient needs to change their therapy, to have a specialist visit, or if there is no need to perform any action. The Workflow Document is updated with a task that depends on the decision taken by the clinician:<br />
<br />
{{pad|4.4em}}'''E1.''' “Analyze and Request Visit”;<br />
<br />
{{hidden text|9999–9999}}'''E2.''' “Analyze and Change Protocol”;<br />
<br />
'''E3.''' “Analyze and Take Clinical Action”;<br />
<br />
'''E4.''' “Analyze and Take No Action”.<br />
<br />
'''F.''' Depending on the resulting task from step E, two options can result: <br />
<br />
'''F1.''' If the decision is to schedule a visit, an eReferral process is activated. When the eReferral workflow ends the clinician that performed the referral updates the Workflow Document with the task “Visit Result”.<br />
<br />
'''F2.''' If the result includes a need to change the protocol, the service provider receives the protocol from the clinician and activates it, updating the Workflow Document with the task “New Protocol Activation”.<br />
<br />
'''G.''' If needed the Telemonitoring service can be closed by the Service Provider or by the referring physician according to a shared management of the service closing: if the request of closing is started by the referring physician, the Service Provider has to confirm the closing; if the request of closing is started by the Service Provider, the referring physician has to confirm the closing. This allows to acknowledge about the service closing both these actors that have in charge the patient during the telemonitoring process, the Service Provider from the technical point of view, the referring physician from the clinical point of view.<br />
<br />
The patient now continues with the telemonitoring service. These steps can be tracked in eleven different tasks throughout the workflow:<br />
<br />
# Request Activation: tracks step A, performed by the patient’s clinician;<br />
# Approve Request: tracks step B, performed by the telemonitoring service provider;<br />
# Telemonitoring: tracks step C, performed by the telemonitoring service provider;<br />
# Consult Request: tracks step D, performed by the telemonitoring service provider;<br />
#Analyze and Request Visit: tracks step E1, performed by the patient’s clinician;<br />
#Visit Result: tracks step F1, performed by the patient’s clinician;<br />
#Analyze and Change Protocol: tracks step E2, performed by the patient’s clinician;<br />
#New Protocol Activation: tracks step F2, performed by the telemonitoring service provider;<br />
#Analyze and Take Clinical Action: tracks step E3, performed by the patient’s clinician;<br />
#Analyze and Take No Action: tracks step E4, performed by the patient’s clinician.<br />
#Close Telemonitoring Service<br />
<br />
[[File:XTHMWDactivity.PNG|center]]<br />
<br />
==Systems Affected==<br />
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''<br />
<br />
<!--<br />
* ''PACS systems may store, manage, and/or display Evidence Documents.''<br />
* ''Display systems may query, retrieve and display Evidence Documents.''<br />
* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports<br />
--><br />
<br />
'''Actors & Transactions:'''<br />
[[File:ActorTransactionXTHM.PNG|700px|center]]<br />
''<Insert an actor-transaction diagram, and or list of Content Definitions>''<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
''<Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>''<br />
<br />
'''Documents:''' <br />
<br />
''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>''<br />
<br />
<!--<br />
[http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf Vol. 1] - Section 5 (SWF Profile)<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E<br />
--><br />
<br />
'''Underlying Standards:'''<br />
<br />
<br />
''<list all the standards on which the profile is based; if possible with links to sources>''<br />
<!--<br />
:* [http://dicom.nema.org DICOM]<br />
:* [http://www.hl7.org HL7]<br />
:* ...<br />
--><br />
<br />
==See Also==<br />
<br />
''<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>''<br />
<br />
<br />
'''Related Profiles'''<br />
<br />
''<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>''<br />
<br />
<!--<br />
* ''[[Reporting Workflow]] [RWF] may use Evidence Documents as inputs to the reporting process.''<br />
* ''[[Simple Image & Numeric Reports]] [SINR] may include data copied from Evidence Documents.''<br />
* ''[[Cross-enterprise Document Sharing for Imaging]] [XDS-I] can be used to share Evidence Documents between sites over a network.''<br />
* ''[[Portable Data for Imaging]] [PDI] can store Evidence Documents on media such as CDs.''<br />
* ''[[Import Reconciliation Workflow]] [IRWF] can fix patient ids, etc. of Evidence Documents when importing.''<br />
--><br />
<br />
'''Consumer Information'''<br />
<br />
The [[Profile FAQ Template]] answers typical questions about what the Profile does. ''<Replace the link with a link to the actual FAQ page for the Profile>''<br />
<br />
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile. ''<Replace the link with a link to the actual Purchasing page for the Profile>''<br />
<br />
'''Implementer Information'''<br />
<br />
The [[Profile Implementation Template]] provides additional information about implementing this Profile in software. ''<Replace the link with a link to the actual Implementation page for the Profile>''<br />
<br />
'''Reference Articles'''<br />
<br />
''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >''<br />
<br />
<br />
<br />
This page is based on the [[Profile Overview Template]]</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Cross-enterprise_TeleHome_Monitoring_Workflow_Definition&diff=109074Cross-enterprise TeleHome Monitoring Workflow Definition2018-05-02T23:16:11Z<p>Rgioirdano: /* Benefits */</p>
<hr />
<div>This supplement is written according to the specific template defined for Workflow Definition profiles. The structure of this document differs from a PCC Content Profile. In particular the XTHM-WD Profile establishes a common set of rules to share between participants involved in a telemonitoring workflow. The telemonitoring process, and workflow related to it, is applicable to many different sharing infrastructures. In this profile we present a specific XDS based use-case.<br />
<br />
__TOC__<br />
<br />
==Summary==<br />
''<Describe the profile in about a paragraph using user-oriented language. Focus on what it accomplishes for a user (i.e. the Use Cases). Don't get into how it works, leave that to the Details section.>''<br />
<br />
''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about. Do not use an actor/transaction diagram here. Show your graphic to someone for 5 seconds (literally) and ask them what it's about. If what they say hits the main points in your summary paragraph, you have succeeded. E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them. .>''<br />
<br />
''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>''<br />
<br />
==Benefits==<br />
The workflow related to the management of patients with chronic diseases (e.g., heart failure, COPD, diabetes) followed by a telemonitoring service is a cross-enterprise workflow since many different individuals from different enterprises can be involved: specialists and physicians, working in hospitals, rural areas or urban areas, general practitioners (GP), and general caregivers, as well as the telemonitoring centre’s staff. <br />
<br />
For the correct management of these patients, each of these individuals, managing his part of the telemonitoring workflow, should have also the possibility to share and manage the patient’s complete clinical history. However, at the moment there are no technical specifications allowing this to be done in a standardized manner. <br />
<br />
This profile provides guidelines to define this kind of cross-enterprise workflow using the XDW profile, allowing every participant involved in a patient's care to share the complete telemonitoring workflow, including all related documents produced for each event occurring during the process (data sending, request for a visit, change of therapy), and the related workflow status.<br />
<br />
This proposal focuses on the Cross Enterprise TeleHomeMonitoring Workflow Definition in<br />
support of telemonitoring workflow document and status management. <br />
<br />
The key elements are:<br />
* managing telemonitoring cross-enterprise workflow, tracking all events and related documents;<br />
* managing workflow specific status with relationship to one or more documents;<br />
* tracking status of all events in telemonitoring process (in progress, completed, etc.). <br />
<br />
With the increase in the elderly population and the consequent increase in the prevalence of patients with chronic diseases (as diabetes, chronic heart failure and COPD), the introduction of a telemonitoring service for these patients, with good workflow management, as defined in this profile, would entail a considerable advantage in terms of quality of life for patients and cost savings. <br />
<br />
To demonstrate the scale of the problem, an analysis has been performed on some European data about the most relevant chronic diseases: now COPD affects approximately 44 million people (Eur Respir J 2011); heart failure affects about 15 million people (ESC 2008). The introduction of a telemonitoring service for these patients, with good workflow management, as defined in this profile, would entail a considerable advantage in terms of quality of life for patients and cost savings.<br />
<br />
==Details==<br />
<br />
<br />
[[File:XTHMWDactivity.PNG|center]]<br />
''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>''<br />
<br />
''<If the user might be familiar with the mechanisms used by the profile, you can mention them here. E.g. Evidence Documents is based on DICOM Structured Report (SR) Templates.>''<br />
<br />
''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short. E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>''<br />
<br />
==Systems Affected==<br />
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''<br />
<br />
<!--<br />
* ''PACS systems may store, manage, and/or display Evidence Documents.''<br />
* ''Display systems may query, retrieve and display Evidence Documents.''<br />
* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports<br />
--><br />
<br />
'''Actors & Transactions:'''<br />
[[File:ActorTransactionXTHM.PNG|700px|center]]<br />
''<Insert an actor-transaction diagram, and or list of Content Definitions>''<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
''<Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>''<br />
<br />
'''Documents:''' <br />
<br />
''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>''<br />
<br />
<!--<br />
[http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf Vol. 1] - Section 5 (SWF Profile)<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E<br />
--><br />
<br />
'''Underlying Standards:'''<br />
<br />
<br />
''<list all the standards on which the profile is based; if possible with links to sources>''<br />
<!--<br />
:* [http://dicom.nema.org DICOM]<br />
:* [http://www.hl7.org HL7]<br />
:* ...<br />
--><br />
<br />
==See Also==<br />
<br />
''<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>''<br />
<br />
<br />
'''Related Profiles'''<br />
<br />
''<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>''<br />
<br />
<!--<br />
* ''[[Reporting Workflow]] [RWF] may use Evidence Documents as inputs to the reporting process.''<br />
* ''[[Simple Image & Numeric Reports]] [SINR] may include data copied from Evidence Documents.''<br />
* ''[[Cross-enterprise Document Sharing for Imaging]] [XDS-I] can be used to share Evidence Documents between sites over a network.''<br />
* ''[[Portable Data for Imaging]] [PDI] can store Evidence Documents on media such as CDs.''<br />
* ''[[Import Reconciliation Workflow]] [IRWF] can fix patient ids, etc. of Evidence Documents when importing.''<br />
--><br />
<br />
'''Consumer Information'''<br />
<br />
The [[Profile FAQ Template]] answers typical questions about what the Profile does. ''<Replace the link with a link to the actual FAQ page for the Profile>''<br />
<br />
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile. ''<Replace the link with a link to the actual Purchasing page for the Profile>''<br />
<br />
'''Implementer Information'''<br />
<br />
The [[Profile Implementation Template]] provides additional information about implementing this Profile in software. ''<Replace the link with a link to the actual Implementation page for the Profile>''<br />
<br />
'''Reference Articles'''<br />
<br />
''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >''<br />
<br />
<br />
<br />
This page is based on the [[Profile Overview Template]]</div>Rgioirdanohttp://wiki.ihe.net/index.php?title=Cross-enterprise_TeleHome_Monitoring_Workflow_Definition&diff=109073Cross-enterprise TeleHome Monitoring Workflow Definition2018-05-02T23:08:52Z<p>Rgioirdano: </p>
<hr />
<div>This supplement is written according to the specific template defined for Workflow Definition profiles. The structure of this document differs from a PCC Content Profile. In particular the XTHM-WD Profile establishes a common set of rules to share between participants involved in a telemonitoring workflow. The telemonitoring process, and workflow related to it, is applicable to many different sharing infrastructures. In this profile we present a specific XDS based use-case.<br />
<br />
__TOC__<br />
<br />
==Summary==<br />
''<Describe the profile in about a paragraph using user-oriented language. Focus on what it accomplishes for a user (i.e. the Use Cases). Don't get into how it works, leave that to the Details section.>''<br />
<br />
''<Insert a simple graphic that, at a glance, visually summarizes what the profile is about. Do not use an actor/transaction diagram here. Show your graphic to someone for 5 seconds (literally) and ask them what it's about. If what they say hits the main points in your summary paragraph, you have succeeded. E.g. a graphic of a hospital, a clinic, and a lab with patient records moving between them. .>''<br />
<br />
''<See [[Help:Contents#Tips_.26_Tricks| Help - Tips and Tricks]] for details on inserting an image/graphic.>''<br />
<br />
==Benefits==<br />
''<If the profile can improve Cost, Safety, Quality or Efficiency then list the specific examples of that benefit (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler). Consider using a bullet list for readability. Such benefits help users and vendors make the business case for the profile. If the profile does not improve any aspect of Cost, Safety, Quality or Efficiency feel free to talk about something else here.>''<br />
<br />
==Details==<br />
<br />
<br />
[[File:XTHMWDactivity.PNG|center]]<br />
''<A few paragraphs, if appropriate, providing more details (mostly in user-speak, not tech-speak) on what the profile does and how it works.>''<br />
<br />
''<If the user might be familiar with the mechanisms used by the profile, you can mention them here. E.g. Evidence Documents is based on DICOM Structured Report (SR) Templates.>''<br />
<br />
''<If the user might have an appreciation for the problems addressed in the profile, you can mention them here, but keep it short. E.g. Mapping HL7 Order fields to DICOM Modality Worklist attributes can be inconsistent in the marketplace, so Scheduled Workflow provides vendors with more detailed instructions.>''<br />
<br />
==Systems Affected==<br />
''<List (in user terms) the types of systems they might expect to have implemented actors from this profile, e.g. RIS, PACS, HIS, CAD Workstation, etc. and for each, how it would participate.>''<br />
<br />
<!--<br />
* ''PACS systems may store, manage, and/or display Evidence Documents.''<br />
* ''Display systems may query, retrieve and display Evidence Documents.''<br />
* ''Reporting workstations may retrieve, process and include details from Evidence Documents in reports<br />
--><br />
<br />
'''Actors & Transactions:'''<br />
[[File:ActorTransactionXTHM.PNG|700px|center]]<br />
''<Insert an actor-transaction diagram, and or list of Content Definitions>''<br />
<br />
==Specification==<br />
<br />
'''Profile Status:''' [[Comments| Final Text]] <br />
''<Replace "Final Text" with "Trial Implementation" or "Public Comment" as appropriate.>''<br />
<br />
'''Documents:''' <br />
<br />
''<Provide direct links to the specific volumes or supplements, and list the volume sections relevant to this profile. This is a simple inventory of official normative and informative text. If you would like to provide a reading guide or walkthrough of what is in each of the different sections for implementers or users, do that in the Profile FAQ or the Profile Implementation Page linked below. If the profile uses transactions from multiple Tech. Frameworks, repeat the structure below.>''<br />
<br />
<!--<br />
[http://www.ihe.net/Technical_Framework/index.cfm#radiology IHE Radiology Technical Framework:]<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8.pdf Vol. 1] - Section 5 (SWF Profile)<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-2.pdf Vol. 2] - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23<br />
:* [http://www.ihe.net/Technical_Framework/upload/ihe_tf_rev8-3.pdf Vol. 3] - Appendix E<br />
--><br />
<br />
'''Underlying Standards:'''<br />
<br />
<br />
''<list all the standards on which the profile is based; if possible with links to sources>''<br />
<!--<br />
:* [http://dicom.nema.org DICOM]<br />
:* [http://www.hl7.org HL7]<br />
:* ...<br />
--><br />
<br />
==See Also==<br />
<br />
''<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>''<br />
<br />
<br />
'''Related Profiles'''<br />
<br />
''<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>''<br />
<br />
<!--<br />
* ''[[Reporting Workflow]] [RWF] may use Evidence Documents as inputs to the reporting process.''<br />
* ''[[Simple Image & Numeric Reports]] [SINR] may include data copied from Evidence Documents.''<br />
* ''[[Cross-enterprise Document Sharing for Imaging]] [XDS-I] can be used to share Evidence Documents between sites over a network.''<br />
* ''[[Portable Data for Imaging]] [PDI] can store Evidence Documents on media such as CDs.''<br />
* ''[[Import Reconciliation Workflow]] [IRWF] can fix patient ids, etc. of Evidence Documents when importing.''<br />
--><br />
<br />
'''Consumer Information'''<br />
<br />
The [[Profile FAQ Template]] answers typical questions about what the Profile does. ''<Replace the link with a link to the actual FAQ page for the Profile>''<br />
<br />
The [[Profile Purchasing Template]] describes considerations when purchasing equipment to deploy this Profile. ''<Replace the link with a link to the actual Purchasing page for the Profile>''<br />
<br />
'''Implementer Information'''<br />
<br />
The [[Profile Implementation Template]] provides additional information about implementing this Profile in software. ''<Replace the link with a link to the actual Implementation page for the Profile>''<br />
<br />
'''Reference Articles'''<br />
<br />
''<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >''<br />
<br />
<br />
<br />
This page is based on the [[Profile Overview Template]]</div>Rgioirdano