20081021-ooc-minutes

Architecture Board

21October2008

Attendees

Name	P/A	With	Affiliation	E-mail address
Conner,Kathleen	a	Guest	Microsoft Corporation	kathleen.connor@microsoft.com
Curry, Jane	a	ArB	Health Information Strategies	janecurry@healthinfostrategies.com
Grieve, Grahame	a	ArB	Kestral Computing	grahame@kestral.com.au
Honey, Alan	P	Guest	II4ms	E-main address
DeJong, Alex	P	Guest	Siemens	alex.dejong@siemens.com
Julian, Tony	P	ArB	Mayo Clinic	ajulian@mayo.edu
Koisch, John	P	ArB	NCI	koisch_john@bah.com
Kreisler, Austin	P	Guest	SAIC - Science Applications International Corp	duz1@cdc.gov
Lynch, Cecil	P	ArB	ontoreason LLC	clynch@ontoreason.com
Larsen, Ed	P	Guest	HITSP	erlarsen@ix.netcom.com
Mead, Charlie	a	ArB	Booz Allen Hamilton	charlie.mead@booz.com
Moehrke, John	a	Guest	GE Healthcare Integrated IT Solutions	john.moehrke@med.ge.com
Orvis, Nancy	a	ArB	DOD	nancy.orvis@tma.osd.mil
Parker, Ron	a	ArB	CA Infoway	rparker@eastlink.ca
Quinn, John	a	ArB	Health Level Seven, Inc.	jquinn@HL7.org
Shakir, Abdul-Malik	P	ArB	Shakir Consulting	ShakirConsulting@cs.com
Walker, Mead	a	ArB	Health Data and Interoperability Inc	dmead@comcast.net
Yongjian, Bao	a	ArB	GE Healthcare	yongjian.bao@med.ge.com

Call to order

The meeting was called to order at 12:00 U.S. EDT by chair John Koisch with Tony Julian as scribe.

Section 3.1.3 Contracts and Participations

Contracts talk about all of the different Collaboration Participations that must happen for the business process to be fulfilled. These participations are either that of a Commissioning Party or that of a Responsible Party participating in interactions. These interactions realize some business relationship between roles, some of which may be played by services.

Put another way, Specified Collaborations bind themselves to Specified Service Roles by way of a contract, or series of contracts. This binding, and these contracts, may or may not need to be made explicit in a particular deployment context, but the participation is valid nevertheless as parts of this contract become explicit in the design and implementation of a given collaboration.

What we are trying to get a here are both legal and IT contracts, binding roles to participations to do business tasks. We must acknowledge that this contract exists.

• Discussion

Officially this meeting is to discuss the notion that we need to do a mapping from SOAML, and create a profile for SOAML moving forward. ??:We should embrace the SOAML instead of mapping. AMS:The spirit is that we would start with the SOAML, and bring rational difference to OMG. JK: We may agree to disagree. The notion of binding roles to behaviours has been acknowledged by HL&, but SOAML looks at it differently. The other thing we have to do as a next step is to make sure that all of these classes are well defined, probably one-third done at this point. This portion of the document is really proceeding down a parallel path, specifying roles, not necessarily bindings, as well as (pertinent to OO) is specifying business purpose behaviours. Talking about the complex processes that must happen to make lab happen. AK: It is the things that lab must get around from a behavioural standpoint. AK: I am learning what I need to know. JK: Grahame, Patrick, and Austin will work together for InM, OO to come together. EL: Lab order HITSP must deliver next year, so this work is useful. JK: A lot of people are waiting for this.

JK:(Figure 5) Must be rigorous about what the role is. It is laid out in the sequence diagrams. The relationship between the behaviour and the role analysis specification is made here. THe role analysis specification is laying out the relationships between the business context and the role. Some doubt that there is a need at this level. Comments about the analysis specification: None

Section 3.2.2 HL7 Conceptual Design Specifications

There are two specifications - the Role specification, and the collaberation specification. You cna model the behaviour as having relationship to the roles, and behaviours, so that these collaberations can take place. The notion of channel type has cause some confusion. You need to be able to cope with the behaviour of a CDA document, as well as a Lab order. We are getting to the granularity to support the behaviour. The design specs are constraints on the analysis specification.

For certain set of services it is fine to specify that this service could be commissioning behaviours using interactions. You must be able expose the internal specifications to the external.

(Nancy Orvis joined) three next steps - getting the models more complete, aligning with SOAML, including mapping exercise, and places they diverge. Rich Rogers and Alan Honey will be making sure this happens.

JK: Talked to OMG, and need to have HL7 setting at the table. NO: May become a jointly developed and maintained specification. JK: Not under HSSP AH: Across the IT industry. NO: UML? AH: Profile on top of UML. NO: We (ARB) should have a link on what the collaberations/technologies/models HL7 is working with - what are the external trading partners? AK: Managed by the board NO: Need a better map, showing who is doing what JK: Governance discussions, including SOA, ISM NO: Do I have to translate this stuff in the behavioural framework? - I can support you on this, showing the methodology trading partners. Given what this is based on, that should be notated, we should never be looking at this without the source methodology. JK: What is the trajectory of this document? Are we going to harvest and put back into the SAEAF document. JK: Conceptual design spec comments: NO: Does there have to be any tie to HL7 ACTS? JK: There is implicit sterotyping by color - everyone feels secure with the green, yellow, and blue, but the red needs to be worked out - how you map to the act semantics. Not a stumbling block to getting this work done. No one-to-one mapping at this point. NO: Interaction type/contracts - need to work out the relationship to SOA contracts. AH: That was in one of the early models - two parts, two interpretations on the word contract. NO: Change the industry viewpoint to what AH is talking about. We need to use a different word than contract. JK: There are huge problems to refering to the role specification as a contract, since a legal contract is not always necessary. AH: it is a contract, same as one hand clapping is applause. NO: Trillions of dollars are modeled as a contract. I would be happy to help coordinate a paper internally. I have too much documentation that lends confusion to decision makers all the time. JK: Bring up again after the break

(15 minute break)

Role

JK: Two roles : business role is application role - decoupling system from role. Then there is the responsible party or commissioning party. Third leve of roles is service provider and service consumer. Business role binds to service role to responsible party/commission party. We need common agreement. A contrat binds role to collaberation.

AMS: There are two different things: who is asking for the service/who is sending/receiving.

JK: I think that is the relationship captured here. The difference is an abstraction layer.

AMS: There is a responsible party and a commissioning party, in every case they are the same.

JK: In the implementable design spec there is an interchange point (RMPDP) is the actual thing, physical reality, provides testable/verifiable.

AMS: I cant by looking at that know which direction the exchange is going. Within an interaction things go back and forth - I need to know who is sending and receiving.

JK: for a particular interaction - in the SAEAF document - this is the notion of interactions.

AMS: in interaction 1 there are 4 exchanges

JK: A is commisioning and B is responsible

AMS: do they remain the same. ON the first exchange the direction is from A to B, the second is from B to A. The other diagram does not tell me the direction of the exchange. Change commissioning/responsible to sender/receiver.

RE SAEAF figure 8

AH: This looks like the parties may be different. They should not be linked at the exchange level.

JK: for the initial arrow, the provider is A, consumer is B. AMS should we change to sender/receiver?

AMS:Yes

JK: There is a physical boundary

AM: Are the interactions always between a pair?

AH: Implicitly defined to be so by intent.

JK: Interactions realize a relationship. May be sender to broadcaster.

AMS: Last exchange from B-A B expects new interaction? B has an expectation for that behaviour?

JK: Not that B expects it, but the whole collaberation expects the exchanges. There is a logical consequence defined.

AMS: What I am seeing is one collaberation with 4 interactions and 8 exchanges.

JK: yes

AMS: each interaction is an exchange between parties

JL: passing of information throught an interaction point. B is responsible in 1, and commissioning in 2

AK: Same concept as Filler and Placer in lab.

AMS: collaberation, interaction, and exchange seem to collide.

AMS: wanting to know the direction of the exchange.

AH: Yes

JK: I dont disagree. At the conceptual design level we can talk of an in or out parameter to support the exchange. When you get down to the implementable, you talk about what component does what.

AK: Could polling situation change the direction

JK: The business role has not changed - in the polling situation the responsible/commissioning have not changed, but the direction is backwards.

AK: I want to avoid a choice at the communication level be forced up into the design level. Avoid that - a proliferation of patterns. I want an abstract pattern - at a lower level. Creates an explosion of artifacts.

JK: Commonalities are the responsible/commissioning , not the direction. Here the need to be ordered.

AK: Transitioning from the logical to the physical

JK: Still talking about a specification. Everything is laid out.

AK: At this point I would have to decide if I am polling

JK: That is the differentation we are trying to capture.

AH: in service terms you are not defining the physical operations. There would be a different specification at the lowest level

JK: At the implementable layer we have a channel. These exchanges can mix and match at this level. A document can be ripped apart into seven messages at this point.

AK: Those who are strict adheres to document say you cannot shred that thing.

JK: AMS are we resolving this

AMS: 1 have sender/receiver instead of provider and consumer. Using service provider/consumer may give the wrong impression.

JK: Provier/consumer are at the analysis level, not this one.(figure 7)

AMS: the parties in the interaction are the same as the exchange, but the model allows them to be different.

AH: It was represented this way for convenience. The relationship between the collaberation stuf is being made throught ht role. It can give a false impression from the implementation level. It is inconsistent.

JK: There are several diagram missing from the paper

AMS: the provider may be commissioner or responsible

AK: looks ok from the smell test

JK: You are our quality check. The differention between levels are the dotted lines. This is realy the design and implementable level. The contract binds the behaviours, participations, and roles.

AMS: It requires a newspeak, using different words in a new way. We must align with OMG, so that we introduce newspeak, we do it once.

JK: Point out another area: The soaML has notion of milestones, which sorta takes into account all of these things; Status of a work type, and status of an activity type.

They have logical relationships between interactions, work units. Not different from milestones, maybe it is just the notion of a profile.

AH: The intent may be 25% different.

JK: The gap conceptually gets coverd by Business Process Meta Model.

AH: I think that is the case

AMS: we have been down this path with OMG before, and will do it again

JK: There is interest from several parties in engaging with UML

AMS: for the HSSP project it has strengthend the relationsips. We are now orbiting the same sun.

JK: HL7 has a seat a the table

AMS: result of the HSSP project that we may be good neighbors. Thanks for sharing this diagram.

JK: The other diagram that did not get in, is the notion of an HL7 specification is collaberation and service roles. Notion that HL7 messaging, focused on static models, assumes sever limitations on who the responsible/commissioning parties are.

AK: messaging? are you talking about documents and services

JK: Only messaging

AMS: Different specificaiton

AK: even in documents there is a rudimentary behaviour - you can see structures in the document for managing the state of the document.

JK: this is the unified field theory. Documents are not an interoperability paradigm of itself. In document pardigm the CDA is a metamodel. The behaviour is coarsly grained.

AMS: Not agree of disagree - tanget topic

JK: from the standpoint of this, you can slice and dice services/messages many ways. The argument is please dont use objects in messages.

NO: I returned - fire drill is over. Thought we could go shopping too!

NO: Have we answered all of the question about the behavioural model. ? the AH concern of the roles sender/receiver/commissioner/

AK: renamed service provider/service consumer to provider/consumer

JK: we have traversed the abstraction levels. We need some flavor of this diagram in the paper as well.

JK: the trajectory of this paper - flesh it out, do mapping to the HL7 model

AH: Keep as a separate document, cross reference to SAEAF. Frequency of update will be greater.

JK: SAEAF becomes governance and conformance, this document describes various artifacts, as well as the HDF.

JK: HDF does not have anything to say on the intersection between behaviours, applications, roles. This is an alteration of where the HDF has been focused.

AK: HDF has not been focused on the behaviour

AMS: HDF only covers this in its outline, focusing on project inititation.

JK: HDF only overlaps on standard specification, which changes based on the use of abstract service view, with capabilities of behaviours. We are adding a few notions here. I see that as progress.

JK: I think that give what I am hearing/not hearing, everone is ok with the future steps. Volunteers are needed. AMS on task to do the mapping. Austin, Patrick and Grahame will be discussing needs of OO.

AK: It is dear hunting season, as well as ballot season.

JK: We have a F-F in november at the crowne-plaza in DC november 12-14, concurrent with the harmonization from november 11-14. I would hope that this document, and the rest of the SAEAF document are on the glide path. We probably will not be done, but by the end of the F-F there are comments we need to address.

NO: Are there other things that should be defined by the end of the F-F. Which methodologies?

JK: ARB provide governance model for whatever framework the TSC specifies. Charlie McCay, Ed Hammond, and John Quinn are making decisions. There is a governance aspect, in that each of the boxes in the matrix lays out where HL7 intesects with others groups. e.g. IHE profiles. The same things with DICOM, (PP slide 18).

AK: Having a diagram showing this is very useful.

JK: in the SAEAF these diagrams are missing. Another evolutionary/revolutionary

AK: How we interact with other organizations.

JK: Yess. At the end of November we need to be concrete. In december we will have a meeting with co-chairs to discuss the consequences, talking about the impact on the different groups.

NO: Should we decide what we need to decide impact on these groups. I want a work plan on what does this mean to domain committees, message committees. I am volunteering to draft for the domain experts SD, and are willing to do a draft for others.

AK: Semantic and Structured design will need the same info.

NO: There are specific for domains such as CMETS. We should tailor some briefings for role-based changes to process. I will look at as-is and add to-be. I really dont like to go into the really technical details, but could draft some kind of outline. Are there major differences?

AK: It will be the chairs of the WG's.

NO: I am not sure that many from the domain experts will come in.

AK: Models are going to have to deal with this. MnM has to have a program for training facilitators for this model. Publishing will have to figure out how to publish.

NO: Austin can you work with me?

AK: Has to be slanted for each division.

NO: I can work on a drafting template.

JK: 5 minute break

Action items

1. Mapping beharioural framework to soaml

1. Figure out the trajectory

1. roll document back into SAEAF

1. Plan for providing information to the co-chairs
   1. NO and AK to collaborate

Service Classification Schemes

JK: This diagram deals with the

• process service
  • A commissioning party for other behaviours
• Capability service
  • functional consistency and state of components, such as lab servicde
• Core Service
  • not concerned with state, but exposing domain objects, e.g. CDA
• (Allen ) Utility service

JK: The idea for the scheme is this. It give HL7 WG's a place to target what they are doing. Lab dould expose a capability service, such as lab order. OO would be worried about comissioning/responsible party.

AK: IF you are breakignit into services - yes

JK: does HL7 intend all WG to expose thier services. Making these broad classifications so that WG's can map them to their taxonomy. Do w eneed to make this normative.

AK: normative as to how to do it, not mandatory that you DO do it. Breaking it down this way will help people think along these lines to make sure it is divisible along these lines sow we acn deliver message and services.

JK: Can think of commissioning party as sending V3 messages. I dont think we will get much pushback as long as it is informative. - WGS define content as a comissioning service or capability service. Cecil this is where your issue of terminology services gets some play

CL: you saw the post about doing a referencing implementation. AMS comment about the name not being appropriate provider/consumer, which will divide into different roles. i am looking forward to getting to implementation.

JK: Maybe that is all that needs to be said. We talked of three levels. AH sees the need for a utility level , specially for CTS2. Specially for infrastructure. Specifying internal behaviours at a broad level, roles that exhibit a behavour. It is oK to specify that you are require to consume or produce.

JK: We want to talk about this taxonomy appropriately without being totally computational.

CL: We will need a normative product - to standardize the flavors of HL7. I dont see as possible unless some of this is normative. Here is how you MUST do it to be conformant. Where do we do the information expression binding to the artifact - at that junction it will have to be normative. People will not know how to realize CSI if we are not explicit. We already have a problem between documents and messages. Some aspect of this must be normative : This is how you must do it, not this is how you could do it. The expectation on service performance between trading partners must be normative.

JK: How you map acts in the messaging world to services: how the semantics on the wire get expressed in a service.

CL: yes, that is what I am saying. THis is where this is going to be choreagraphy heavy. There are things in terminfo that will have to be mapped to R2 datatypes instead of terminfo. We will have to re-think some of this when we really do it.

AK: This is entirely going to change. There are a lot of moving pieces, and we have not attached GELLO or Arden Syntax.

CL: The HSSP document, specially for GELLO constraints, will need normative view of service interaction.

JK: we are saying that whatever we persist in the iso datatypes you need to be able to map back out.

CL: If you dont persist the CE in the way they are communicated, the nesting makes it impossible to reassemble unless your persist to the level of versioning of terminology. Lack of persistance may come back to bite you.

JK: The good news is that these are quality of service elements that belong to the contract, not the interface specificaitons. There will be components of contracts or parts thereof, where HL7 will state that the contract notion may have to consist of these things. We struggle with this with clinical trials, and the question has arisen "whats our source of record?". We dont transmit ids, rather full names. We need to work through some reference implementations to make sure we are not missing anything vital.

JK: any other comments about classification scheme.

AMS: Ok with categories. Need to develop inclusion and exclusion criteria.

JK: these will come out of the models. Sterotypes constraining the model. Part of the discussion JK, AMS, and AH will have.

Next steps

• HSSP interaction was laid out.
• Minutes are available for the last two days calls
• The notion is that we need to done by the end of November
  • Heavy lifting on models
  • Heavy lifting on reference implementation

AMS: action item - TO map the curent behaviour model to the one under developement. 1 Discover the current model working with Lloyd and Woodie

JK: My understanding as well

AMS: MnM concensus view of the current model.

JK: Mapping that we need to basically have ready, should be vetted in the next week or two. Doable?

AMS: doable, depends on how long it takes to get a concensus view of the behavioural model

JK: Lots of degrees of emotion: If you were to do in conjunction with Woody or Lloyd, a concensus view, on the agenda for a MnM meeting, that would be an appropriate way forward. MnM concensus is not a requirement - AMS, woody, and Lloyd should be very close. Agreed?

AMS: Yes

JK: Bird in hand worth two in a bush. As long as we know what the glide path ist.

AMS: Concerned about the SOAML mapping, and changes to our current model. Should we wait for that?

JK: Our model will change?

AMS: Our model will change because of richness of SOAML>

JK: We will come up with a mapping of SOAML so that V2 would be aligned with SOAML.

AMS: Once you do that mapping, even for creating a profile, it will change our thinking, and we will be influenced

JK: I assume you mean going back and forth with SOA community.

AMS: we might add SOAML milestones, but where?

JK: We have the need to expand this dicussion in 2 months instead of 12. We need an answer sooner rather than later on SAEAF and the Behavioural framework. The RFP for SOAML happened in September. I have asked Rich Rogers for an up-to-date copy, so we can figure out our timeline.

JK: I dont disagree at all: The TSC want our product soon! There are pressures on HL7 - we have a responsiblity to move this thing forward.

CL: we must realize that it is iterative

JK: We are pretty close on the logical level, as we work our way down the stack it will become more difficult.

AK: I am concerned about 2.x fits in this picture. How much re-engineering will it take?

JK: My sense is that the PHER project will come out in the IHE reference implementation. I think the 2.x maps into this framework very well. We need to do a rigorous mapping of the interchange points. I do think that both sets could align at the analysis and logical levels.

AK: Ok

JK: we have to do this now rather than later

AK: and made comprehensible to committee members and co-chairs.

JK: This is why we years ago did not do the functional stuff.

AMS: we need someone from the education committee on this call.

JK: you! AMS signed me up and I have been contacted by Mary Jo. ARB is to sit in the front of the room.

AK: with a bag of tomatoes.

CL: Motion to adjourned

AK: Second

Adjournment

Meeting adjourned at 2:53pm U.S. EDT

Tony 18:54, 21 October 2008 (UTC)