Draft IHE Actor profiles released for XDS secure exchanges
A proposal for an OASIS ebBP Profile for IHE Profiles realized within the scope of the IST 027065 RIDE Project(http://www.srdc.metu.edu.tr/webpage/projects/ride/) as a part of the Deliverable D.5.3.1 Contribution to Standardization Efforts sponsored by the European Commission, DG Information Society and Media, eHealth Unit(http://ec.europa.eu/information_society/activities/health/index_en.htm) has been published for community review.
The document describes how to express the IHE Profiles through ebBP language to facilitate the configuration of electronic relationships among IHE Actors and to provide an automated environment to help IHE users and vendors to exchange configuration information electronically and in a standard way.
The eBusiness eXtensible Markup Language (ebXML) Business ProcessSpecification Schema (BPSS) technical specification [ebBP] defines a standard language by which business systems MAY be configured. The ebBP defines generic Business Transactions between the Roles (the Requesting Role and the Responding Role) which exchange documents. The ebBP re-uses these transactions by specializing them in Business Collaborations. IHE Profiles [IHE], on the other hand, defines IHE Actors (which correspond to ebBP Roles) and IHE Transactions (which correspond to ebBP Business Collaborations) and organizes them into IHE Profiles (which correspond to ebBP Business Processes) specific to the healthcare domain. The profile described in this document is not proposing any change to existing IHE Profiles or its existing implementations. Note that ebBP Processes are not executable meaning that you cannot execute them to cause some action; but they are machine processable meaning that you can use the information content by executing a software.
The profile described in the released document is proposing to document the already existing information in IHE profiles in a machine processable way to help with configuration issues.
There are several benefits to be gained in defining IHE Profiles[IHE-ITI-1] through ebBP since ebBP provides standard, concise and machine processable configuration information which can be used in an automated way:
1. Re-usability: When an IHE Transaction is defined as a generic ebBPTransaction, its re-usability is increased. For example, when we define ageneric Patient Identity Feed Transaction [IHE-ITI-2] between two generic roles such as Patient Identity Supplier and Patient Identity Receiver;this transaction can be specialized to Patient Identity Feed Transactionin IHE XDS by setting the Patient Identity Supplier to Patient Identity Source and the Patient Identity Receiver to XDS Registry. The same generic Patient Identity Feed Transaction can be specialized to Patient Identity Feed Transaction in IHE PIX by setting the Patient Identity Supplier to Patient Identity Source and the Patient Identity Receiver to PIX Manager.
As a summary, when IHE defines a new profile which uses an already defined generic transaction, this transaction can be specialized to the new profile to be re-used.
This mechanism is ready in ebBP to be used in a standard way.
2. Configuration Management: The focus of ebXML is on building a framework that makes it possible to automate the creation and the configuration ofelectronic relationship. To achieve this goal, ebXML describes business processes through ebBP and the actors through CPPs (Collaboration-Protocol Profiles) [ebCPPA]. An IHE Actor, on the other hand, is in need of the configuration of its electronic relationship with other IHE Actors. Each IHE Actor needs to discover the other IHE Actors, the other Actor's supported IHE Transactions, the other Actor's role in the Transaction, and the configuration details about how the other Actor sends and receives Messages. For example, in an IHE connectivity marathon (connect-a-thon), the IHE Actors obtain network configuration parameters from an online database quite some time before the connect-a-thon. The ebBP provides all this configuration information needed by the IHE Profiles and helps this information to be discovered and used at run time in real life cases without human intervention.
3. Discovery of Configuration Information: The configuration information, independent of how it is defined, need to be discovered by the involved IHE Actors. When the configuration information is defined through ebBP andCPPAs, ebXML Registry mechanism can be used for discovery. Furthermore,there should be a machine processable mechanism to automatically find out the optional IHE Transactions a specific IHE Actor supports. When IHE Profiles are expressed through ebBP, it becomes possible to specify this by referring to the business process which includes the optional transactions.
4. Facilitating the grouping of the IHE Actors: Since IHE Profiles describe specific use cases, there is a need to combine several IHE Profiles to achieve the required functionality in realizing a real world scenario in the healthcare domain. When IHE Profiles are combined by grouping the relevant IHE Actors, the sequence of the transactions coming from different profiles must be decided. For example, when ATNA Secure Node is grouped with XDS Document Source, Document Repository and Document Registry Actors, the Record Audit Event Transaction (IHE-ITI-20) of ATNA appears between Provide and Register Document Set Transaction (IHE-ITI-15) and Register Document Set Transaction (IHE-ITI-14) of XDS. It is clear that, given the large number of IHE Profiles, determining the order of all the involved transaction manually for every real life scenario is a tedious task.
However it is possible to automate this task by developing software tools to allow users to graphically group the Actors involved, and generating the overall process automatically by using the precedence information among IHE Transactions.
5. Software Tool Support for Configuration: In order to make the process described in the document user friendly, we support it by software tools. We provide public domain software tools to support the following: The ebBP Editor to graphically define IHE Transactions and Profiles. This software is available at:http://freebxmlbp.sourceforge.net/ The IHE-AGT (Actor Grouping Tool) to group IHE Actors graphically and produce the resulting business processes automatically available at http://www.srdc.metu.edu.tr/ihe/tools/iheagt/iheagt.zip. The IHE Configuration Management Tool (IHE-CMT) available at http://www.srdc.metu.edu.tr/ihe/tools/ihecmt/IHECMT_METU_SRDC_180706.zip which consists of the IHE-CPP Editor and the IHE-CPA Editor.The document is organized as follows:
Chapter 1 provides an introduction to the rest of this document. Chapter 2 provides a brief overview of the ebBP Business Process Specification and the Collaboration-Protocol Profile (CPP) and AgreementSpecification (CPA). Chapter 3 provides a brief overview of the Integrating HealthcareEnterprise (IHE) Transactions and Profiles. Chapter 4 specifies how to represent IHE profiles in ebBP. Chapter 5 briefly summarizes the public domain ebBP Editor previouslydeveloped by the METU-SRDC Team. Chapter 6 describes how IHE Actors can be grouped using ebBP. Chapter 7 describes how to facilitate the configuration of IHE Profiles byUsing ebBP and CPP. Chapter 8 addresses the metadata configuration issues in IHE XDS. Chapter 9 describes IHE Configuration Management Tool. Chapter 10 summarizes how configuration issues are currently handled in IHEXDS connect-a-thon and provides the envisioned situation. Chapter 11 provides normative and informative references that are used within or relevant to this document.
The document describes how to express the IHE Profiles through ebBP language to facilitate the configuration of electronic relationships among IHE Actors and to provide an automated environment to help IHE users and vendors to exchange configuration information electronically and in a standard way.
The eBusiness eXtensible Markup Language (ebXML) Business ProcessSpecification Schema (BPSS) technical specification [ebBP] defines a standard language by which business systems MAY be configured. The ebBP defines generic Business Transactions between the Roles (the Requesting Role and the Responding Role) which exchange documents. The ebBP re-uses these transactions by specializing them in Business Collaborations. IHE Profiles [IHE], on the other hand, defines IHE Actors (which correspond to ebBP Roles) and IHE Transactions (which correspond to ebBP Business Collaborations) and organizes them into IHE Profiles (which correspond to ebBP Business Processes) specific to the healthcare domain. The profile described in this document is not proposing any change to existing IHE Profiles or its existing implementations. Note that ebBP Processes are not executable meaning that you cannot execute them to cause some action; but they are machine processable meaning that you can use the information content by executing a software.
The profile described in the released document is proposing to document the already existing information in IHE profiles in a machine processable way to help with configuration issues.
There are several benefits to be gained in defining IHE Profiles[IHE-ITI-1] through ebBP since ebBP provides standard, concise and machine processable configuration information which can be used in an automated way:
1. Re-usability: When an IHE Transaction is defined as a generic ebBPTransaction, its re-usability is increased. For example, when we define ageneric Patient Identity Feed Transaction [IHE-ITI-2] between two generic roles such as Patient Identity Supplier and Patient Identity Receiver;this transaction can be specialized to Patient Identity Feed Transactionin IHE XDS by setting the Patient Identity Supplier to Patient Identity Source and the Patient Identity Receiver to XDS Registry. The same generic Patient Identity Feed Transaction can be specialized to Patient Identity Feed Transaction in IHE PIX by setting the Patient Identity Supplier to Patient Identity Source and the Patient Identity Receiver to PIX Manager.
As a summary, when IHE defines a new profile which uses an already defined generic transaction, this transaction can be specialized to the new profile to be re-used.
This mechanism is ready in ebBP to be used in a standard way.
2. Configuration Management: The focus of ebXML is on building a framework that makes it possible to automate the creation and the configuration ofelectronic relationship. To achieve this goal, ebXML describes business processes through ebBP and the actors through CPPs (Collaboration-Protocol Profiles) [ebCPPA]. An IHE Actor, on the other hand, is in need of the configuration of its electronic relationship with other IHE Actors. Each IHE Actor needs to discover the other IHE Actors, the other Actor's supported IHE Transactions, the other Actor's role in the Transaction, and the configuration details about how the other Actor sends and receives Messages. For example, in an IHE connectivity marathon (connect-a-thon), the IHE Actors obtain network configuration parameters from an online database quite some time before the connect-a-thon. The ebBP provides all this configuration information needed by the IHE Profiles and helps this information to be discovered and used at run time in real life cases without human intervention.
3. Discovery of Configuration Information: The configuration information, independent of how it is defined, need to be discovered by the involved IHE Actors. When the configuration information is defined through ebBP andCPPAs, ebXML Registry mechanism can be used for discovery. Furthermore,there should be a machine processable mechanism to automatically find out the optional IHE Transactions a specific IHE Actor supports. When IHE Profiles are expressed through ebBP, it becomes possible to specify this by referring to the business process which includes the optional transactions.
4. Facilitating the grouping of the IHE Actors: Since IHE Profiles describe specific use cases, there is a need to combine several IHE Profiles to achieve the required functionality in realizing a real world scenario in the healthcare domain. When IHE Profiles are combined by grouping the relevant IHE Actors, the sequence of the transactions coming from different profiles must be decided. For example, when ATNA Secure Node is grouped with XDS Document Source, Document Repository and Document Registry Actors, the Record Audit Event Transaction (IHE-ITI-20) of ATNA appears between Provide and Register Document Set Transaction (IHE-ITI-15) and Register Document Set Transaction (IHE-ITI-14) of XDS. It is clear that, given the large number of IHE Profiles, determining the order of all the involved transaction manually for every real life scenario is a tedious task.
However it is possible to automate this task by developing software tools to allow users to graphically group the Actors involved, and generating the overall process automatically by using the precedence information among IHE Transactions.
5. Software Tool Support for Configuration: In order to make the process described in the document user friendly, we support it by software tools. We provide public domain software tools to support the following: The ebBP Editor to graphically define IHE Transactions and Profiles. This software is available at:http://freebxmlbp.sourceforge.net/ The IHE-AGT (Actor Grouping Tool) to group IHE Actors graphically and produce the resulting business processes automatically available at http://www.srdc.metu.edu.tr/ihe/tools/iheagt/iheagt.zip. The IHE Configuration Management Tool (IHE-CMT) available at http://www.srdc.metu.edu.tr/ihe/tools/ihecmt/IHECMT_METU_SRDC_180706.zip which consists of the IHE-CPP Editor and the IHE-CPA Editor.The document is organized as follows:
Chapter 1 provides an introduction to the rest of this document. Chapter 2 provides a brief overview of the ebBP Business Process Specification and the Collaboration-Protocol Profile (CPP) and AgreementSpecification (CPA). Chapter 3 provides a brief overview of the Integrating HealthcareEnterprise (IHE) Transactions and Profiles. Chapter 4 specifies how to represent IHE profiles in ebBP. Chapter 5 briefly summarizes the public domain ebBP Editor previouslydeveloped by the METU-SRDC Team. Chapter 6 describes how IHE Actors can be grouped using ebBP. Chapter 7 describes how to facilitate the configuration of IHE Profiles byUsing ebBP and CPP. Chapter 8 addresses the metadata configuration issues in IHE XDS. Chapter 9 describes IHE Configuration Management Tool. Chapter 10 summarizes how configuration issues are currently handled in IHEXDS connect-a-thon and provides the envisioned situation. Chapter 11 provides normative and informative references that are used within or relevant to this document.
posted by DRRW at
2:59 PM
0 Comments:
Post a Comment
<< Home