[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebxml-bp] ebBP 11/29/2005: IHE Integration Profiles throughebBP...(Files Updated)
Sorry for any inconvenience, but the original draft documents became corrupted when downloaded and uploaded to OASIS. See below. > See this progress with health care in using ebBP for electronic health > records. > > 1. ebBP IHE Profile (draft): mm2: Updated: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15657 > 2. ebBP Editor User's Guide (draft): mm2: Updated: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15658 > This is an important development to promote adoption of ebBP. What is > of particular interest here is: > > 1. Leveraging registry/repository > 2. Exercising the v2.0.1 advanced features > 3. The draft editor under development > 4. The importance of the patterns and semantic information in this > domain (which are core capabilities in ebBP) > > I encourage your comments particularly on Asuman's questions and my > responses. Their needs and questions are similar to those we have > received from local UK government and textiles. Thanks. > -------------------------------- > Email response 28 November 2005 (Martin To Dogac, et al) > Questions and comments recreated here: > Asuman, first I commend you and your team on the progress thus far. > I've reviewed the report in detail and will also do so for the editor > user guide (tomorrow). See comments inline and at the end of this > email on the report itself and (starting) answers to your specific > questions below. Thank you very much. We are encouraged by your > efforts. Regards. > >> dr. dogac: Dear Monica, >> Here is a report on where we stand now and where we need >> your help in integrating IHE Profiles through ebBP: >> >> 1. As you know, IHE has defined a number of of Integration >> profiles describing collaborations among the IT systems >> in Healthcare. However, an Integration Profile by itself is usually >> not enough; >> several different integration profiles must be used together >> to handle the cases in real life. For example, the documents >> stored in the ebXML registry/repository through IHE XDS Profile are >> usually provided >> as a result of executing "IHE Scheduled Workflow" profile and >> hence XDS needs to work together with IHE Scheduled Workflow profile. >> Furthermore, since security of patient information is very important, >> other IHE Integration Profiles such as IHE Audit Trail and Node >> Authentication (ATNA) >> and Cross-Enterprise User Authentication (XUA) must be used in >> conjunction with >> the XDS profile. >> >> IHE addresses this "dependency" among different integration >> profiles by "grouping" the necessary actors of the involved >> profiles. "Grouping actors" means that the IT system(s) that represent >> the involved actors must implement the mandatory transactions >> of each of the actors. Although the result of this "grouping" >> is a collaborative healthcare business process, IHE does not >> attempt to define this process formally. > > > mm1: This composability is quite important. It is more than just > actors, though. It is composability of functions, technology, etc. > (which was part of the original foundation and vision of ebXML) - > composability of many technologies to enable heterogeneous > environments. On profiles, this is timely because we (ebBP team) is > now engaged with ebXML IIC to develop a profile based on their > deployment template format. We have only just begun and this will be > a complementary exercise for both efforts. Please see the recently > approved Committee Draft for the CPA profile from ebXML IIC for > reference: > > * TC page: > > http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/document.php?document_id=15200 > > * public: > > http://www.oasis-open.org/committees/document.php?document_id=15200&wg_abbrev=ebxml-iic > > > In addition, as previously indicated, we are engaged with UBL for the > Small Business Subset to realize the modular, composable process > definitions (profiles) you envision. See the latest draft of modular > definitions under development from Stephen Green: > > * public: > http://lists.oasis-open.org/archives/ebxml-bp/200511/msg00067.html > > I would suggest there are multiple ways to approach this. What we have > found is flexibility in composability is highly desirable (from > textile, financial services, supply chain, local government, and now > health care perspectives). First: > > * Modular definitions can be defined for: > o logical business documents > o transactions - Recognizing: > + patterns used > + signals desired > + quality of service required - maps to your desires to > associate business QoS to profiles that concretize the > mechanisms to realize them > o actors > o rules > * Modular definitions can be composed (in the context of the process > and in support of other mechanisms (such as stated above): > o Activities combined, nested or related. > o Constraints and transitions defined. > o Rules applied. > + timing > + documents and conditions expressions interrogating > that data (internally and externally). For example, > mechanisms such as CAM can be used. > + semantic information (semantic variables) > >> dogac: 2. METU team has implemented an ebBP Editor, >> to facilitate defining collaborative >> healthcare business processes in ebBP. Enclosed >> please find a draft of the ebBP Editor user guide. >> We will highly appreciate your comments. >> After we agree on the design and the content of the user >> manual, it may be a good idea to put it on SourceForge >> for public use. > > > mm1: Grand idea! As indicated, I will review the user guide in quick > order and also provide to the ebBP team for comment and suggestions, > with your permission. > >> dogac: 3. What we intended to was, to define IHE Integration >> Profiles like XDS, SW, etc. through this ebBP Editor tool and then >> let the user select which actors it wishes to group and then >> generate the whole business process in ebBP. >> Enclosed please find a paper which describes the initial >> steps but it not complete for the following reasons: >> when we tried to define IHE Integration Profiles >> through ebBP, we face the following problem: >> every IHE transaction has a triggering event >> which may be an external event such as an HL7 or a DICOM event >> or a user initiated event. > > > mm1: We have had similar and related questions from other user > communities, whereby the functionality was there although we either > needed to be more explicit and descriptive about its value and use or > work more closely with adopters to implement. We wish to work with you > in the same way. > > Several mechanisms exist to support externally influenced activities. > For example: > > 1. Semantic variables: A semantic element supports the effective use > of conditional constraints. The variable can be accessed by > external elements. The businessTransactionActivityRef and > businessDocumentRef point to what context and documents are > relevant to Condition Expression evaluation. Variable assumes > type, if any, from expression evaluation. This element, for > example, could be associated with a logical Business Document. > Given whether simple or complex variables are used, XPath or XSLT > could be used, for example. This could allow externally driven > mechanisms to be used. > * Semantic variables can also enable use of externally defined > timing constraints (TimeToPerform for example). > 2. Condition expressions: Sometimes overlooked are the condition > expression types BeginsWhen, EndsWhen, and Pre- and PostCondition. > For example, these could be automated (I believe) to accomplish > what you seek. BeginsWhen would trigger the start of an activity > while the PreCondition could designate the condition that allows > the activity to start. If the expression attribute is rendered as > computable, the BSI may use these attributes at run-time. If > desired, variables may also be used to further enable Pre- and > PostCondition, BeginsWhen and EndsWhen elements, as they are of > type ConditionExpressionType. For example, an XSLT variable may be > used for these attributes and allow values to be placed in them. > > This will be a good opportunity to test these assumptions and also > understand if any subsequent changes/improvements should be considered. > >> dogac: For example, admission of a patient (which is an external HL7 >> trigger event) triggers >> the first step of IHE Scheduled Workflow, namely, the >> "IHE Admit/Register Patient" transaction >> which informs the Order Placer about this patient. >> However, the second step in the Scheduled Workflow, >> which is "IHE New Order from Order Placer", >> does not automatically start after the first step is >> completed but it is initiated externally by a medical doctor >> as in real life. >> >> We thought of capturing these external events through guards >> in the ebBP definition. For example, we should be able to define a guard >> for "IHE New Order from Order Placer" transaction which becomes true >> when an external event becomes true (a physician enters an order). > > > mm1: Yes, see previous comments. > >> However, it seemed to us that the current definition of >> guards in ebBP do not naturally capture >> external events. Is there something that we miss? >> If not, it would be good if the draft is extended >> to include mechanisms to naturally handle external events >> in the ebBP. >> >> Note that in ebBP specification, it is stated that "when a transition >> is validated, it >> does not mean that the target Business Activity would start >> immediately. It >> means the Business Activity is enabled and will be initiated whenever >> appropriate." Although this is stated, it is not clear to us how this >> is realized. We think that it should be possible to initiate >> a business activity or Collaboration Activity by explicitly stating >> its guards. > > > mm1: This is historic to the ebBP (ebXML BPSS), it realizes in a > standard way the expected (even exceptional paths) activities that > should occur. And those expectations can be monitored; the process > definitions is computable and may be used at runtime rather than > focused on an executable language. Dale may wish to add to these > comments, and I expect we will have other inputs from our team. In > addition, the sequences defined are expected and logical in nature, > recognizing that at runtime the asynchronicity of the business > messages may be different but guided by timing parameters and > expectations, at a minimum. > > The condition guards, transitions, condition expressions and semantic > variables are enablers to accomplish this. See previous comment such > as the differences between BeginsWhen and PreCondition (trigger vs. > enabled) as well. > > We would welcome suggestions on clarifying descriptive language to > best communicate our intent and address your question. > >> dogac: Another observation is the following: IHE XDS is using >> ebXML registry just as a "document registry" to store >> parient healtcare records. However, >> one of the main advantages and in fact reason of developing >> ebXML is for the purpose of storing business processes >> through ebXML registry. IHE is a very important industry >> initiative, so if we can collaboratively show that it brings >> added value for IHE Integrations profiles (workflows) >> there may be a chance for them to adopt it. So it would be good >> if we find or develop ways of expressing IHE Integration Profiles >> in ebBP. > > > mm1: An ebBP profile for ebXML Registry would also be a considered > next step. I've cc: Farrukh Najmi here for information. > >> dogac: Finally, I would like to take this opportunity to thank the >> Deputy Head >> of Unit of eHealth, Dr. Iakovidis and the Artemis Project officer, >> Dr. Purcarea of the European Commission who are copied >> in this email for sponsoring our work through the Artemis project. > > > mm1: Likewise - here, here for the substantive work thus far. Asuman, > is it acceptable to forward this work to the ebBP list for comment? > Thank you. > ========== > Other comments on the ebBP paper (in addition to the initial comments > and answers above): > > 1. Section 1: > * Document Registry (as an Actor) would likely need to provide > user defined signals (notifications that could be tracked) > to enable Register Document Set. Same would apply for query > functions. We do allow user-defined signals although they > need to provide the base information expected for a Business > Signal. > * Quality of service expectations can be guided by > DocumentSecurity and Quality aspects inherent in ebBP. These > may be realized by tooling, Registry mechanisms, etc. > * Grouping of Actors or even process definitions themselves in > a composable way may be achieved via tools which is what is > envisioned by UBL. Visibility is very important based on > the business documents, process activities and actors so > there may be more granularity that can be achieved here via > the profile concepts (and as supported by the elements in > ebBP). > 2. Section 2.1: > * ebXML BPSS = ebXML Business Process Specification Schema > (short name ebBP). ebBP was coined after the actual TC name > of ebXML Business Process TC. > * As specified in the patterns matrices, business signals are > highly recommended particularly for state alignment. > However, we recognized that other mechanisms may be used. > * Historically there have been differing opinions about > Business Signals on a Response. The ebBP sees how important > they are for state alignment. However, the UMM had indicated > they were not part of the business collaboration protocol > (i.e. they served as warnings). The operational criteria > defined in ebBP further enables the BT patterns in the UMM. > * There are 6 concrete patterns, 1 legacy pattern (for Legacy > Business Transaction) and 1 fully extensible pattern (Data > Exchange). You cite 6 and then list 8. Note that the core > schema actually has typed the Business Transaction using > BusinessTransactionType - it can be commercial or not > (Commercial Transaction or Business Transaction > respectively). This was specifically done to accommodate > other than commercial intentional activities (such as for > government - which is where we received the request). > 3. Section 2.4: > * 3. When Order Filler acknowledges the initiation of an > Order, is the Order Status Update a Response or as an > acknowledgement of the Order? This is important in the > process definition and how the pattern (or which pattern) is > used. If response to initiation of order, could use > Business Transaction; if a separate Notification, the > Notification pattern (as stated in your document). > * 4. Do external events trigger th Query Modality Workflow > List? Or is this driven by notifications by the Order > Filler? Or are these periodic and nature? See previous > comments on external events. > * Exceptions can enable the additional issues you cite in this > section. > * See previous comments on logical sequence (expectations of > the parties). This enables you to to use constraints, > transitions and timing for example to manage. See > improvements in v2.0.1 for semantic variables, condition > expressions, and the latest externalDocumentDefRef (external > source to apply business rules or additional semantics to a > business document processing - real-world example UBL). > * There are several key differences between WS-CDL and ebBP, > some philosophical and others technical. CDL is based on a > distributed computing model and is focused on web services > for choreography. ebBP innately uses business semantics and > mechanisms (such as semantic variables) and the > international BT patterns - focusing on collaborating > parties and business partners. This comment is not > specifically related to the paper but focused on > understanding these two capabilities, and at some point use > of them in complementary ways. > 4. Section 3.1: > * Acknowledgements and exceptions are actually part of the > patterns and business transactions themselves. > > Relevant references: Bob Glushko's book chapters that talk about large > scale, inter-departmental collaboration: > Chapter 9: > http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch9_FINAL.pdf > > Chapter 10: > http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch10_FINAL.pdf > > Actual book reference: http://www.docengineering.com/. > > Working drafts as a result of Public Review process: > Spec (diff) > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15523 > public: > http://www.oasis-open.org/committees/document.php?document_id=15523&wg_abbrev=ebxml-bp > > > Spec (r02) > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15524 > public: > http://www.oasis-open.org/committees/document.php?document_id=15524&wg_abbrev=ebxml-bp > > > Document, Supplements > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15525 > public: > http://www.oasis-open.org/committees/document.php?document_id=15525&wg_abbrev=ebxml-bp > > > Schema > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15526 > public: > http://www.oasis-open.org/committees/document.php?document_id=15526&wg_abbrev=ebxml-bp > > > SignalSchema > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15528 > public: > http://www.oasis-open.org/committees/document.php?document_id=15528&wg_abbrev=ebxml-bp > > > Document, Schema > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15529 > public: > http://www.oasis-open.org/committees/document.php?document_id=15529&wg_abbrev=ebxml-bp > > > Document, SignalSchema > http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15531 > public: > http://www.oasis-open.org/committees/document.php?document_id=15531&wg_abbrev=ebxml-bp > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]