20081112 ArB Out of cycle

Architecture Board

November 12, 2008 

Attendees

Name	With	Present	Organization	Email
Beeler, Woody	Guest	Yes	Beeler Consulting	woody@beelers.com
Connor, Kathleen	Guest	Yes	Microsoft	Kathleen.connor@microsoft.com
Curry, Jane	ArB	Yes	Health Information Strategies	janecurry@healthinfostrategies.com
Duteau, Jean-Henri	Guest	Yes	HL7 Canada	jean.duteau@gpinformatics.com
Grieve, Grahame	ArB	No	Kestral Computing	grahame@kestral.com.au
Honey, Alan	Guest	No	II4MS
Julian, Tony	ArB	Yes	Mayo Clinic	ajulian@mayo.edu
Klein, Ted	Guest	Yes	Klein Consulting, Inc	kci@tklein.com
Koisch, John	ArB	Yes	NCI	koisch_john@bah.com
Kriesler, Austin	Guest	Yes	SAIC	duz1@cdc.gov
Larsen, Ed	Guest	Yes	HITSP	e.larsen@ix.netcom.com
Loyd, Patrick	Guest	Yes	GPI	patrick.loyd@gpinformatics.com
Lynch, Cecil	ArB	Yes	ontoreason LLC	clynch@ontoreason.com
McKenzie, Lloyd	Guest	Yes	HL7 Canada	lloyd@mckenzie.com
Mead, Charlie	ArB	Yes	Booz Allen Hamilton	charlie.mead@booz.com
Mulrooney, Galen	Guest	Yes	VHA	galen.mulrooney@va.gov
Ocasio, Wendell	Guest	Yes	DOD/MHS	wendell.ocasio@agilex.com
Orvis, Nancy	ArB	Yes	DOD	nancy.orvis@tma.osd.mil
Parker, Craig	Guest	Yes	ASU	craigparkermd@gmail.com
Parker, Ron	ArB	No	CA Infoway	rparker@eastlink.ca
Quinn, John	ArB	Yes	Health Level Seven, Inc.	jquinn@HL7.org
Shakir, Abdul-Malik	ArB	Yes	Shakir Consulting	ShakirConsulting@cs.com
VanHyenteryck, Karen	Guest	Yes	HL7	karenvan@hl7.org
Walker, Mead	ArB	Yes	Health Data and Interoperability	dmead@comcast.net
Yongjian, Bao	ArB	Yes	GE Healthcare	yongjian.bao@med.ge.com
Bear, Yogi(template)	Guest	No	US Dept. Interior, National Park Service	yogi@jellystonepark.gov

8:00 Welcome

Approval of Agenda

The following agenda was approved:

• • 0800 - 0830 -- Welcome, Approval of Agenda, Review of October Out Of Cycle Meeting
    • Welcome
    • Approval of Agenda
    • Approval of minutes of October Virtual F2F
  • 0830 - 0900 -- SAEAF Review and Overview
  • 0900 - 1000 -- SAEAF Behavioral Framework Review
  • 1000 - 1015 -- Break
  • 1015 - 1130 -- SAEAF Behavioral Framework, Developmental Governance, and Impacts
  • 1130 - 1230 -- SAEAF Collaborative Governance with other SDOs
    • Discuss HITSP and NHIN
    • OHT
  • 1230 - 1330 -- Lunch
  • 1330 - 1500 -- SAEAF Internal Governance
    • Discuss Collaborative Governance between Workgroups
  • 1500 - 1530 -- Break
  • 1530 - 1700 -- Review of Impacts and Next Steps
  • 1700 --adjournment

Approval of minutes of October Virtual F2F

Motion	By/Second	Tally
The minutes of the October 20-21 Virtual meeting were approved as posted/amended	Kathleen/Tony	12-0-3

08:30 SAEAF Review and Overview

John presented the SAEAF overview. Questions will be asked as the points are raised.

09:00 Behavioral Framework Review

The latest document was posted to Behavioral Framework 20081112. This came about as an outcome of a joint ARB/INM/MNM/SOA meeting in Vancouver, September 2008.

Behaviors, participations, and roles have to be separated from service specifications in contracts.

John Koisch: The notion of "Process service" does not take on a role, but rather a set of defined behaviors. It is a collaberation between the comissioning party and a responsible party. From the collaberation point of view, you can specify the contracts at multiple levels. Behaviors can be re-used. From HL7 view there are order management services, patient scheduling services, etc.

O&O is discussing extended behaviors with dependancies. The separate specification of these w/o service context has value. CBDI specifies service roles, without providing structures.

Allan Honey: A contract binds two parties, the service role only binds one - that is the key difference.

Mead Walker: That is a specialized definition of contract.

Charlie Mead: We need to be clear: a contract is a relationship between a service consumer and a service provider.

John Koisch: A process service has a behavior as well as a role.

Wendell Ocasio:You are creating responsibility from the consumer.

Lloyd McKenzie:There are places in HL7 where that is a requirement.

Wendell Ocasio: The placer is the consumer.

John Koisch: THere are shared states/behaviors that can be expressed. The consumer as well as the Database are in a contract.

Wendell Ocasio:I dont want to lose sight of the fact that a service is loosly coupled.

Allan Honey:The purpose of the framework is to specify what CAN happen, but this is not enforced. It must represent all of the permutations of HL7 requirements.

John Koisch: All of this is as needed.

John Quinn:I wish that this industry was always that simple. The complexity of hospital operations requires tightly-coupled systems.

Woody Beeler:Dont tell us the other stuff does not exist. We are spending a lot of time - we are not defending service structures.

John Koisch:Continuing walkthrough

John Koisch: An exchange in the framework is an HL7 interaction.

Lloyd McKenzie:I could have an interaction type of create order, or manage order. DOes the BF provide any guidance?

John Koisch: HSSP and Service provide granularity specifications and analysis.

Lloyd McKenzie: the business will contain the models.

John Koisch:The state transitions need to be bound early.

Charlie Mead:There are guidelines in diagram 2.2. In a complex business scenario, there are often two parties that change roles from comissioning to responsible, and vice-versa.

Lloyd McKenzie: From a physician perspective there is no change - My objective is to get the WBC. I am comissioning for order, but responsible party for the receipt of the results. Is there a broad interaction type - overall fulment, which contains other interactions.

Charlie Mead:The contains is the WorkUnitType, which encapsulates the entire collaboration.

John Koisch: From the model, InteractionType, WorkUnitType, and ExchangeType are all subclasses of ActivityType.

John Koisch: The notion of role-relationship is important: a notion that there are comissioning and responsible parties that can be specified and modeled. Service defines roles independently, while we do not. It depends on how you granulate your processes.

John Koisch: you can stereotype services - you need these concepts to manage the expectations of other HL7 WorkGroups.

John Koisch: HL7 has things to say about things that are NOT rim based, e.g. template registry.

Lloyd McKenzie: The expectation is that the BF could apply to service definitions other than those that are RIM based.

John Koisch: I agree.

Charlie Mead: The behavioral framework is the stairway to heaven, and is not in all places traceable to the RIM.

Abdul-Malik Shakir::We can expect some abuse from the community if we don't provide the guidance.

Lloyd McKenzie:I want to see documentation of when to use RIM and when not. I want some place to point to where I can say "You are violating this".

Kathleen Connor:You may want to share a service between HL7(RIM based) and X12.

Lloyd McKenzie:If you want to say you are HL7 you must be RIM based -except for . . .Is there a policy written?

Charlie Mead:The primary obligation for developing this is the ARB, not the TSC.

John Koisch:Discussing Figure 5: Contracts. The notion of types is a modeling convention - there is more specificity at the behavioral levEd Larsen:

Lloyd McKenzie: Is this specification and instance.

John Koisch: This is showing M1 and M1.5

Charlie Mead: The type is on top, which comes down through subclasses - not exactly going from class to instance.

Lloyd McKenzie: In the existing we have Interaction with ID, and an instance that gets passed over the wire. Is the exchange thing there the interaction that goes over the wire?

John Koisch: Yes

Jane Curry:This is the design of the interaction that goes over the wire, not the instantiation.

John Koisch:This diagram is traversing the steps - there is a class missing from the diagram - the message port.

Galen Mulrooney:What are the colors?

John Koisch: Act, participation, and role.

Tony 15:00, 12 November 2008 (UTC)

10:30 SAEAF Behavioral Framework, Developmental Governance, and Impacts

JK presented Figure 6( Continuance of Specification Stack:)

Lloyd McKenzie:Can we change names? Role and RoleRelationship are already RIM classes, and may confuse others. You might have generic domain information models for orders, and a more defined information model for pharmacy. Is domainanalysismodel recursive?

John Koisch:An analysis specification embodies things with a behavior.

Lloyd McKenzie:You could have a behavioral model at a low or high level. Clinical statements is a DIM, as is the pharmacy model.

John Koisch:Since we are binding behavior to static models, is the behavior bond to the concept?

Lloyd McKenzie:It would be useful to define generic patterns as the same level as clinical statements that could then be used by pharmacy.

John Koisch:We can state that this Analyis model is traceable to pharmacy. This is academic - my analysis model is your domain model.

Domain models have

• Static semantics
• Functional semantics
• behavioral semantics
• business semantics

DIM realizes static components of the DAM and is HL7ized static model.

Service Role Specification embodies the function semantics and is loosely coupled to the DIM.

Behavioral specification realizes the behavioral semantics.

Discussion moved on to Figure 7. The HL7 Conceptual Design Specifications and went on to Figure 8:HL7 Implementable Design Specifications.

Discussion was held about where the platform binding takes place.

Abdul-Malik Shakir: presentation Hl7 Behavioral Framework mapping to Legacy.pdf

Lloyd McKenzie: we need two mappings - one at the analysis level, and one at another level.

Charlie Mead: Receiver responsibility maps to consumer/responsible.

Lloyd McKenzie: No mapping to trigger-event is a problem.

Abdul-Malik Shakir:: Slight modification to SAEAF may solve the problem.

LM & Austin Kriesler: Storyboard is an exemplary sequence, not a collaboration.

Jane Curry: you agree to enter into a subset of the set. Even the variations are constraints of the specification.

Abdul-Malik Shakir:: The storyboard most closely maps to a storyboard, but . .

John Koisch: Storyboards are the meet in the middle of what service specifications look at.

Abdul-Malik Shakir: surfaced a number of mapping issues :

two that must be reconcilled

• Interaction as aggregation not composition of one or more oredered Exchange
• Implementable Information Model as payload of Exchange, not use dependent of interchange point

four that are unresolved

• Receiver Responsibility
• Trigger event
• Conformace Statement
• Storyboard Example

and four potential issues dealing with

• Acknowledgements
• Batch Messages
• Broadcast messages
• Query/Response

11:30 SAEAF Collaborative Governance with other SDOs

Defered until November 13, 2008

• Discuss HITSP and NHIN
• OHT

12:30 Lunch

Lunch was held at 12:30-13:30 U.S. EST

13:30 SAEAF Internal Governance

Discuss Collaborative Governance between Workgroups

• Collaborative Stack
  • Participants in Collaboration
  • Discussed Page 9, Diagram SAEAF (Part 2)

• HL7 w/ SDO's
  • Discussed Page 11, diagram "The SAEAF Applied(2) Governance and Other "Standards"(DRAFT)
  • Conceptual design is missing SIM, LIM, ITS.
  • IHE belongs at another level
  • Page9 comments: Most of analysis sits outside of normative HL7 balloting. Page11 we have pushed
  • WorkGroup x WorkGroup

The two diagrAbdul-Malik Shakir: need to be harmonized.

Discussion was held that some of the specifications that HL7 defines fall on the lines between categories, especially between Conceptual Design and Implementable Design.

John Koisch:The ArB intends that the specifications created are testable-verifiable at all of the contained levels. This was discussed from many viewpoints.

Lloyd McKenzie: You can only have traceability from your design to the final. You can document level of traceability, and the pedigree of each element. In reality if You and I both are traceable to the same base specification then we have a change of interoperability.

John Quinn: Normative has to do with the governance and discussions within the committees.

Lloyd McKenzie: Normative should be testable.

Mead Walker: Not the fundamental reason - it is more political than social.

John Quinn: It is marketing.

Woody Beeler: The core question: I adopt a Domain model and a framework, and say they must do, what is it they must do? Are we going to mega-systems? Only one interface?

John Koisch:I assert that claiming conformance to the BRIDG - getting all the parties to agree to that DAM means that we agree on the context, boundaries, and framework. It may not be testable in an automatable fashion?

Lloyd McKenzie: We went normative so we could make the RIM available from ANSI.

Abdul-Malik Shakir:: Any specification we produce can be input to another specification. The new specification is subject to more scrutiny than if it is based on informative specifications.

John Koisch: We are talking about HL7 specification stack, which have relatonships with organizations outside of HL7 that are basing their work on HL7.

Jane Curry: Some of our guidance has gone through the ballot process with restriction to DAM, DIM, and platform. The cloud may provide constraints upon HL7 work.

John Koisch: There are some factors in here that support good analysis and design. Woody - who among us is smart enough? There is broad concensus as to where service roles fall out.

Woody Beeler: My comment had to do with the mandatory nature of it.

John Koisch: I would like to see HL7 put out specifications so that people can run with it. Analysis specifications provide value.

Woody Beeler: When we refine it, we dont want to have to retract the former work, but we want to add to it to make implementable.

John Koisch: People need to look to an analysis spec to justify the design.

Woody Beeler: but I have to translate it into Mayo-speak so that they can understand it.

John Koisch: The line of business SOA stuff lives at the analysis/Conceptual design level

Woody Beeler: How to you test that the Mayo Clinic can be able to get the data out of their system? That is not testing, that is traceability.

John Koisch: There is value in agreeing on concepts. There is value in asserting a normative specification - at some point you are asserting that this is the way we do business. We agree on granularity, etc.

Charlie Mead: At computable interoperability, nothing above platform binding makes sense. There is value above computable, even if it is verifiable by non-computing.

Woody Beeler: You are putting more value on Normative than I do. The DAM's should not be documented as standards. I am not certain that we can ballot behaviors.

John Koisch: One DAM, whether role or behavior , the service role specifications have relevance within that DAM. A behavior can be discussed coarse broad business terms, but operational discussion begins to pin it down.

Woody Beeler: If these things are to be normative, who is wise enough to create the scope specifications such that there is only one of them. I am not sure I/we know how to create the scope that will not prevent chaos.

15:54 Review of SAEAF Peer Review

John Koisch: The document went out to various workgroups, and the peer reviews have been consolidated as raw comments which Charlie Mead is presenting:

Charlie Mead: Categorized comments as

• Stylistic
• Comments requiring further explanation - 2/3 of comments
• Things like "how come you arent using other work?" 1/3

Abdul-Malik Shakir:: SOAml (soa modeling language) misses the mark on many levels. I still think we do need to work with OMG to avoid discord. They are only interested in the implementation layer so the analysis and design are simply not there.

Charlie Mead: we are not just doing services. Even if we were, SOAML is not robust enough.

Charlie Mead: "Use of Fowlers pattern" we are using only the basic framework, not the whole document.

Galen Mulrooney: The use of commissioning and responsible parties I found confusing since services uses provider and client.

Charlie Mead: Geeks will bind directly to web services, but we are trying to go above that.

 Charlie Mead: We will scan through these.  Most of them have been addressed in our various discussions.  Comments will be folded back into the new document.  

Abdul-Malik Shakir:: SOAML only describes the extensions to UML necessary for services, but does not describe how to use the rest.

Charlie Mead: All of Alan Honey's comments have been incorporated into the document.

 John Koisch: we need to document references both by link in the document, as well as on the ARB wiki.

Charlie Mead: Comment :HL7 should embrace a "service-oriented" not "Service-aware" document is WRONG. That was not our scope.

ACTION: we need formal artifacts for each trigger event. Each artifact needs an ID.

RM-ODP consists of Business, Information, Computational, Engineering, and Technology binding.

Charlie Mead: Item 7:Ioana: "Conformance/Compliance" should be "Conformance". In RM-ODP Conformance is a collection of conformance assertions. Any implementation can implement a sub-set of the assertions. NCI is looking for those who can plug in - they may not be totally conformance, we used conformance profile as a formal subset of conformance assertions. Compliance expresses the difference between the comformance profile and the implementation.

John Koisch: Our task was to provide foundation for compliance.

Charlie Mead: A conformance profile is what you are going to implement.

 Woody Beeler: Change Conformance/Compliance to Conformace and Compliance

Item 8: 2.4.1 "Static semantics" should read Information Semantics"

Woody Beeler: from the perspective of defining the applicability of services you will not define wrapper.

Item 11:Ioana: ":CDA Instances: are not based on the RIM, but on XSD's. Only the CDA XSD is based on the RIM.

Change Instances to CDA Schemas - CDA is rim based, but instances is the wrong context 

Item 13.Ioana: "The fact ehat HL7 specifies interactions rathere tan operation does not meant that one cannot map application roles to services and a set of interactions to a single operation. This is a major error in this document.

John Koisch: She is trying to conflate the roles.

Woody Beeler: So, what does that have to do with the content of Page 12, first bullet. I dont understand it in context.

John Koisch: we have addressed this in the Mapping document from Abdul-Malik Shakir:.

Item 15:Ioana:  Change blue classes to MessageCommunicationsControl subject area classes.

Item 16:Ioana: "What is this section trying to say? This is the kind of thing our V3 audience will want to know.

Item 17: Ioana: NOTE: CCOW is a services specification.

 Charlie Mead: Remove CCOW from the paragraph. 

Item 18:Ioana:

Charlie Mead: Define migration of V2 as out of scope.

Item 22:

Item 23: Sourced from ArB, not elsewhere.

Item 25: Sorted out in behavioral framework (look for mispelled ISRS as ICSR)

Item 26: Sorted out in behavioral framework

Item 27: Sorted out in behavioral frameworkds

Item 28:Sorted out in behavioral framework

Item 29 obvious

Item 30: Obvious

Mead Walker: I like the proposal of removing acronyms. Not for diagrAbdul-Malik Shakir:, just in text.

Galen Mulrooney: Core concepts such as SAEAF and CSI that are used in the document. C/C drove me nuts.

Add CTS/CTS2 to discussions

Carnigie mellon Item is not applicable.

Item 31: Fundamental disagreement - You cannot express analysis, logical, and implementable design as models.

Woody Beeler: do you want to impose it now, or later?

Lloyd McKenzie: we need to acknowledge that this will be necessary at some time.

Woody Beeler: This is an if/then statement - if we conclude that this is a model, then it will be expressed in UML. Mead Walker: Not force modelling. Lloyd McKenzie: We will use UML, and state what tools later. Item 32: HL7 will specify service roles, not collaborations.

Remove any "Service-level agreement" language and replace with the correct term.

Item 33: make sure functional profile is not confused with EHR Functional profile.

Item 34: Explained in behavioral framework

Item 35:Clarify diagram as specified in bF

Item 36: agree

Item 37: BF

Item 38, 39 BF

Item 40: fine Item 41: Item 42: Leave in this will be defined in "Core Principles"

Item 43:Answered

Item 44,45,46,47,48,49:answered

Item 50:

Lloyd McKenzie: Replace utilized with used.

Mead Walker: eliminate the paragraph

Lloyd McKenzie: What is the difference between messages and services

Woody Beeler: There are fundamental differences that may not be apparent.

Charlie Mead: There is unfied field theory - messaging is not incompatable with that.

Charlie Mead: the behavioral framework was forced by services and can be used for messaging.

John Koisch: BF makes receiver responsibilities quantifiable. In addition in certain service specifications may cause state changes.

Woody Beeler: Are there none of those that are dependent on external actions. Is it always testable?

John Koisch: I hesitate to say always, but in most cases. If you build your implementation correctly, state is there. V3 messaging relies on a signal coming back.

Lloyd McKenzie: There is a request-response pair in a single transaction. There is nothing in V3 that spans transactions.

John Koisch: Shared states could become to all parties. The services paradigm forces these out because there was no place for it to live.

Lloyd McKenzie: I dont think that is a difference between messaging and Services.

Charlie Mead: Much of this paragraph is not related to the discussion or agreements reached.

Woody Beeler: Is a service not an implementation of an act or entity? So the question is, do we still have a concern that the RIM cannot support services or not?

John Koisch: Never a question that the RIM cannot support services.

Woody Beeler: Lloyd may be rolling in my grave.

John Koisch: The RIM can express semantics - we have not found a case where it doesnot. You can model in RIM semantics, but how you break that down to implementable components is the point. All of the semantics in act conceptualization live in function/proceedure calls.

Lloyd McKenzie: The wrappers may be handle differently? We have two wrappers, should have three (not including batch, which I am ignoring). The control act structure should remain in a service structure.

Charlie Mead: they should be re-worded, and the examples taken out, and "one of the benefits of the service paradigm motivates the expression of the service paradigm.

Lloyd McKenzie: what we have is more powerful.

John Koisch: Figure 2: The paradigms are not orthogonal. Make sure that your interface preserves a boundary.

Lloyd McKenzie: If you were to create a distinct physical port for each message

John Koisch: then you would have redundant semantics.

Lloyd McKenzie: you have a soap wrapper that declares the service.

John Koisch: you are relying on the infrastructure to provide some of the things that HL7 does.

Lloyd McKenzie: In services, instead of having HL7 specific header, you can have a generic cross-industry header. SOAP headers are the same in the Auto industry as in the Healthcare industry.

John Koisch: Where you put that semantic is much more usable to shove into port 80.

Galen Mulrooney: This is the difference between EDI and XML.

Lloyd McKenzie: MLLP is HL7 developed. It was developed before HTTP, but is not encouraged. The same way we have an MSH in v2 or transmission wrapper in V3, because when we started V3, there wasnt anything that did that for us. Now that there is we will move to the perspective that you can still do that.

Woody Beeler: People are telling you that everything that you gain from Services paradigm are valuable, but not a net gain over what you have been doing in healthcare for a decade. We do it in the interface engines. THe document reads like the old HL7 stuff did not do that.

Lloyd McKenzie: I have been told that the messaging paradigm is different.

John Koisch: Software engineering process leads you down that road. You write a library, based on business requirements. I want to be able to re-use the code at the library level. The semantics is expressed explicit about functionality.

Charlie Mead: Align legend for Figure 5 with diagram

Item 51: Correct

HSSP Comments:Deals specifically with implemtable design: John Koisch: Two things - most of the rest we have dealt with. HSSP feels that IHE stuff is extremely valid, and we should show the intersection. John Koisch: Add IHE where SAEAF deals with other SDO's and similar bodies. Mead Walker: Distinction between SDO's and non-SDO's. Lloyd McKenzie: IHE uses our stuff and other SDO's use it also.

17:56 Adjournment

The meeting was adjourned at 17:56 upon motion by Galen/Lloyd.

Action Items

ACTION "Service is defined by SAEAF as" is defined in various ways in the SAEAF as well as the executive summary. 
We need to clean this up.

ACTIONPlaceholder for policies/requirements.  This needs to be fleshed out.

ACTION: Add recursive relationship do DomainAnalysisModel.

ACTION: Service role should be derived.

ACTION: Change name of RoleRelationship to ???? RoleCommunicationIdentifier? RolePair? RolePairIdentifier.

ACTION: Change name of Role to BehaviorRole

ACTION:  Reconcile the two matrix slides:  HL7 artifacts are at different levels on the two slides. Tony Julian