[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 11/29/2005: IHE Integration Profiles through ebBP...
See this progress with health care in using ebBP for electronic health
records.
1. ebBP IHE Profile (draft):
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15649
2. ebBP Editor User's Guide (draft):
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=15648
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]