20090416 arb OOC Minutes

Architecture Board

April 16, 2009

Call to Order

Meeting was called to order at 9:00am by Chair John Koisch with Tony Julian as scribe. Quorum was achieved.

Attendees

Name	Present	With	Affiliation	E-main address
Curry, Jane	Yes	ArB	Health Information Strategies	janecurry@healthinfostrategies.com
Davis, Brian	Yes	Guest	3rd Millennium	bdavis@3rdmill.com
Grieve, Grahame	No	ArB	Kestral Computing	grahame@kestral.com.au
Jorgenson, Don	No	?	Inpriva	djorgenson@inpriva.com
Julian, Tony	Yes	ArB	Mayo Clinic	ajulian@mayo.edu
Koehn, Marc	Yes	Guest	Gordon Point Informatics Ltd	Marc.Koehn@GPInformatics.com
Koisch, John	Yes	ArB	3rd Millennium	koisch_john@bah.com
Loyd, Patrick	Yes	ARB	Gordon point Informatics LTD.	patrick.loyd@gpinformatics.com
Lynch, Cecil	Yes	ArB	ontoreason LLC	clynch@ontoreason.com
Mead, Charlie	Yes	ArB	Booz Allen Hamilton	charlie.mead@booz.com
Mulroney, Galen	Yes	?	VHA	galen.mulroney@vha.gov
Nelson, Dale	Yes	ArB	II4SM	dale@zed-logic.com
Ocasio, Wendell	Yes	ArB	Agilex Technologies	wendell.ocasio@agilex.com
Parker, Ron	No	ArB	CA Infoway	rparker@eastlink.ca
Quinn, John	Yes	ArB	Health Level Seven, Inc.	jquinn@HL7.org
Shakir, Abdul-Malik	Yes	ArB	Shakir Consulting	ShakirConsulting@cs.com
Walker, Mead	Yes	ArB	Health Data and Interoperability Inc	dmead@comcast.net
Beeler, Woody	Yes	MnM	??????????????????????	?????????????????????
McKenzie, Lloyd	Yes	MnM	??????????????????????	?????????????????????
Kriesler, Austin	Yes	OO	??????????????????????	?????????????????????

Q1 - HDF, Core Principles, and the SAEAF

John Koisch: The impacts for the rascii were displayed (see ????) Glossary Lens of the SAEAF Update to GOM and Quality criteria to reflect SAEAF SAEAF specification Stack Addition to core principles business architecture of HL7 Tooling impact assessment Update to HDF to reflect SAEAF Update to core principles to reflect SAEAF ARB Architectural GOvernance Project

WB: The framework is a specification for methodology, instead of a specification developed from the methodology? A detailed document of HL7's view of the methodology.

John Koisch: They are outputs of applying the framework. WB: you said the specification is the output of applying the framework.

John Koisch: This has caused a lot of confusion in a lot of circles, not just HL7. John projected the diagram (SAEAF-EAS) as well as the wordine "Although a robust, scalable, supportable, extensible – and, of course, implementable – EAS requires all of the critical compnents specified in the SAEAF, it is the ECCF which supplies the “skeleton” of the SAEAF through the construct of the Specification Stack -- a construct whose structure and content will be discussed in detail in the course of this document. The analogy of the Specification Stack (SS) as the “skeleton” of an EAS is made because of the following observation:

An Enterprise Architecture Specification (EAS) consists of a set ofSpecification Stack instances -- largely produced via “bottom-up” and/or “middle-out” project-based activities within an overarching “top-down-specified” Enterprise Architecture Framework -- along with associated architecture Best Practices, patterns, etc.

Thus, the ECCF Specificaiton Stack (SS) is thus the single, basic, and overarching construct that guides and informs the discussion of the ECCF. The following “Terms of Art” are essential in understanding the motivation for, as well as the structure, content, and usage (including cell-to-cell and row-to-row navigation of SS instances) of both the abstract concept of a Specification Stack and its multiple instances which collectively embody the core content of an EAS."

WB: In the ballot it is called infrastructure, not part of the domains. Not comfortable with the name.

John Koisch: It is EAS because trading partners discuss architecture. Pattern, practice, things. What people want to see a large scale enterprise architecture specification. - WB: It needs to be made clear to HL7 that it contains things that people are familiar with, and that often dont have to be re-written to be defined with EAS.

Mead Walker: YOu need to be careful what/how you state it.

Abdul-Malik Shakir: The products how are they related to the EAS.

John Koisch: The laboratory message is conceptualized in a topic specification. WB: EAS is a fancy name for future standards.

Abdul-Malik Shakir: EAS is things you build things from.

John Koisch: More - patterns and practices. We can parse this out. There are things that are not part of the EAS, but are affected e.g. publishing. WB: If it is something HL7 has produced as a standard is part of the EAS. This is a consultant word, but does not describe what it is.

Charlie Mead: Andy Bond commented we are not doing enterprise architecture, we are doing the aspects of EA that affect production of standards. It is practices and primitives that make up standards, WB: I was seeing terminology, etc as part of EAS.

Charlie Mead: The sort-of anology is engineering and manufacturing. You can manufacture any thing, engineering allows you to mass produce interchangeable parts. WB: Not what we have heard.

John Koisch: Standards applies governance to standards. WB: Specification and standard are the same.

Don Jorgenson: THere are two EAS - one focused on HL7, the other at the enterprise. HL7 architecture framework, from which enterprises build specifications. Standards are specifications developed by collaberation.

John Koisch: This is not a system architecture, which is different thing.

Wendell Occasio: what would we loose if we dropped the EAS altogether. Since we described the 4x4 as things you fill in. Is the EAS the sum total of everything that goes into the cells?

John Koisch: You loose the result of governance applied to the framework.

Wendell Occasio: that fills in the cells?

John Koisch: THe aggregate.

Wendell Occasio: The framework described what has to be filled in. THe whole idea is to get it to governance, to fit this paradigm. You have to be specific about what is not part of the EAS. Why do you need a new name? To organize it in a certain way?

John Quin:

• less concerned about outcome of conversation, but want to see it recorded, so as not to repeat.
• we dont have to have an architecture, but saying that everything HL7 does in an architecture? We cant push everything we have developed, and call it an architecture. We map everything to SAEAF thats fine.

WB: If there is an EAS I am comfortable with Charlies statement. I understand that. When it is everything we do, it is like other organizations, it turns into fluff. We can work SAEAF without a blob of stuff that confused people.

John Koisch: You asked about datatypes - they have to be part of this. There are things that dont live in this space. THe model we have now is good, but incomplete - part are EAS, the stuff you need to do, but if you want to write stuff, there is this other stuff. WB: We need to map even crudely, these things qualify for the SAEAF (patterns ,practices, primitives). Then people are cool.

John Koisch: would you be willing to do that to the current ballot structure? WB: Yes, I will do it now.

Abdul-Malik Shakir: I would assume that things under DOMAIN would not be part.

Jane Curry: We dont have this framework. Patterns are parts of the domain that belong to SAEAF.

Charlie Mead: Cmets may be there if they had worked.

Wendell Occasio: Is there a difference between the concensus of the architecture and the reference layer? Is there a difference between what belongs to that layer.

John Koisch: My primitive is your composite. Services does that - would not be part of reference layer. EAS is reference layer PLUS?

Wendell Occasio: Why so many axis? IT is confusing. If it is used by folks, it belongs to the reference layer.

Jane Curry: Reference layer chops it up into viewpoints. Tools are part of the context of the reference layer.

Wendell Occasio: The EAS, not the tooling or methodology. If we have SS, you need a rule to understand what belongs to the EAS why?

John Koisch: What do you think it is?

Wendell Occasio: I am not sure we need and EAS? If you do need it, what do you loose if you dont have it.

John Koisch: What you loose is clarity - because that is what people are looking for - the consume the outputs of the framework Customers consume standards built on specification. These are working terms used internally.

Wendell Occasio: If we cannot define it, how can we use it, otherwise it is a fuzzy concept.

Mead Walker: These are the things in the architecture should be high in the document. The people who use standards have architecture, this is architecture of the standards.

John Koisch: Outputs of framework should be adoptable by those who dont have the framework.

Mead Walker: to adopt it, they need to understand what is theirs and what is ours.

Jane Curry: At the platform specific level is the transform of the specification into their architecture

John Koisch: When you bind to technology.

Jane Curry: There are implications to other levels - it has criteria. We are targeting understanding the framework explicit or implicit relationship to their enterprise architecture, whethere they know they have it or not. Do we produce anything that does not fit into those cells? Yes we have artifacts, as well as implementation guidance on how to use the artifacts. Guidance do not fit neatly, customers wish we had more of it, but it does not fit neatly into one of the cells. YOu could say the implementation guides at the platform independant levels fit in as reference.

John Koisch: We will make the difference between the frameworks and the HL7 products will be made more specific. WB: The statement that Framework would be used to create the EAS, if we do the parsing, and come up with a distinction, and HL7 architecure it would be clear.

Charlie Mead: The framework is specified and governed top-down, while the products are bottom-up.

John Koisch: The SAEAF does not state organization, the business architecture of HL7 is different from the EAS. We need to look at the entreprise of HL7, but we could not get to that question until we came up with the SS. WHen we get to chart of concerns,

Wendell Occasio: Did we agree on something? Can we put it in writing? JK Patters, practices, and primitives, including governance model by which those specifications become standards. The EAS is intended to be consumed, but is different from the HL7 business architecture. Not everying goes through the SS

Wendell Occasio: Why and EAS if it is not a specification.

John Koisch: two specifications - this is the topical specification stack focused on the business. It generates an organized group of specifications.

Wendell Occasio: RM-ODP based, specifies how to define an architecture. Everything you need fits one of the viewpoints.

John Koisch: RM-ODP states that any viewpoint alone defines a sytem.

Wendell Occasio: We created a cross product, within the viewpoints, everything fits.

Charlie Mead: We constrained, modified

John Koisch: The lens of saeaf.

Wendell Occasio: You have to describe it withing the viewpoints.

John Koisch: We did things this way: We separated out the reference layer, since datatypes dont fit in the business viewpoint, lots to say in the information viewpoint. DO we have to go back and generate a full topic spec. for datatypes? NO, same with RIM, EHR-FM. HL7 produced a lot of material in various viewpoints, but they are not a full specification. Topics deal with a topic - the reference material can be called in by any viewpoints. There are specification stacks - the rim is reference to a stack.

Wendell Occasio: It needs to be simple, without a 20 minute statement, without multiple organizing principles.

John Koisch: I dont understand why the EAS is not the sum of these things.

Wendell Occasio: Then why ?

Charlie Mead: Principles, patterns, and primitives are the things we need to do what we do.

Wendell Occasio: Reference is a good organizing principle. If the reference layer is not enough, what belongs and what does not.

John Koisch: You want to see the EAS to conform to this?

Wendell Occasio: Follow the organizing pattern. THe top row, and then what other stuff?>

John Koisch: If you point is that this 4x4 grid can be used to specify you architecture.

Wendell Occasio: How are you going to fit HL7 into the 4x4?

John Koisch: Not the right question. You use the 4x4 to generate this. But it is not everything we do.

Wendell Occasio: THe entire reference layer belongs to the EAS. Why do the rest of the rows belong.

Abdul-Malik Shakir: some things are not referenced.

John Koisch: I said that these viewpoints and layers are helpful - as soon as you make it topical you have an aggregate.

Tony Julian: Are we discussing the binding of the layers?

Wendell Occasio: How do we know when we are done?

John Koisch: Are they implementable?

Wendell Occasio: Is lab part of the EAS?

John Koisch: Yes WB: no, it is down there, not by charlies definition - not a practice or pattern.

Wendell Occasio: There is uncertainty. WB: If lab is part of the EAS, then everything is. Lab is lab.

Charlie Mead: Primitives, Practices, patterns - once persons composite is someone elses primitive. WB: HL7 ends when the universal standard and how to refine it is the end product. Lab is not part of it.

Charlie Mead: we need to differentate between the HL7 EAS and others EAS. There are some primitives at core. If we built the frame, stuff will fillup the box, and it will get easier - at some point we can say we are done.

Abdul-Malik Shakir: a specification we use to create specifications.

Charlie Mead: Cmets dont work because of the governance of their used.

John Koisch: If HL7 defines a LAB specification, and draws boundaries about re-use. WB: Re-use is fundamental. My use of your model does not make it part of the reference model. e.g. LAb does a speciment common pattern - which may be part of EAS, but lab is not. IF all re-use pushed into EAS you have a problem.

John Koisch: We need to take offline- to me to say you cannot implement universal standards with constructs. WB: They are designed to be constrained.

John Koisch: They happen at a different place. WB: Several others were nodding. We cannot take offline. The lab standard may be part of MAYO's EAS, but it it not ours.

Wendell Occasio: Does EAS require different governance?

Abdul-Malik Shakir: No WB: clearly needs governance - clear and complete.

Wendell Occasio: There is a discrepancy over whether an item belongs - is it academic? WB: no

Wendell Occasio: if there are no governance implications the it is clear

John Koisch: there are implications.

Wendell Occasio: changing needs governance. WB: a group says what is in and out, governance of the EAS, not part of balloting.

John Koisch: It sounds like re-usability. WB: What is governance? a process of having a group responsible. We have this. We dont need infrastructure to manage.

John Quin: exceptions need to go the board, so it is governed?

Wendell Occasio: Is there a difference in governance? WB: It is meaninless with different groups. A group will make decisions, with an appeal to the TSC or BOD for exceptions.

John Koisch: It is an additional checkbox.

Wendell Occasio: Is there a need to know what fits?

Abdul-Malik Shakir: Yes, everything we do needs to pride a differenct. WB: a group responsible for EAS will create arbitrary rules, which will be harmonized.

Jane Curry: As we work the process

Wendell Occasio: We can spend two days on every item, or develop a criteria.

Jane Curry: We dont know governance since we have not figured out the framework?

Wendell Occasio: Are we going to put everything in writing?

John Koisch: There is a difference of opinion.

Wendell Occasio: It is the things we use to do stuff, some things are out like specific specifications, some primitives, and we will work out the rest.

John Koisch: everyone ok with that? Im not. I need to be convinced.

Mead Walker: you need to be convinced since you are the facilitator.

Abdul-Malik Shakir: I am concerned about first times, educators, and chairs who need to do the work.

Jane Curry: I want to try something: TO me this the distinction is that you come from a services background - messages are known to be non-implementable until extended, same with CDA. Service drive down, and are intended to be reused, and are defined to the platform.

Wendell Occasio: I am not the only one who tells you what your point is.

John Koisch: The consequences are you have to make the distinction after you write the specification, it comes apriori. I think there is no difference between messages and services.

Jane Curry: what we create is good enough to be an EAS - that does not change ]governance. THe source may be internal, external, which is what we do with alignment with othere SDO's. THis stack is necessary but not sufficient - our composites dont fit neatly, but draw from other stuff. You guys agree, then we stop.

Jane Curry: until you agree you will confuse the next audience.

HDF

John Koisch: what is it, and what is the evolution and what are the next steps? WB: it gets into the confusion between HDF and core principles. The HDF talks of them as work products. Core principles tells you what they are.

John Koisch: THe HDF should give you the process. Core principles talks about the artifacts. SAEAF is a super-set of core principles. Core principle artifacts bfit somehwer in the 4x4. The discussion about the HDF is how the next generation supports the SAEAF. WB: I am worried that we have spent more time worrying about the who , the core principles is not done, and I am not sure that the core principles is different than the saeaf.

John Koisch: we have been discussing HDF, core principles, and the SAEAF. Forget what has been. We feel there is alignment to the SAEAF. We have posited merging all into the SAEAF. We thought the easiest way would be, since the HDF is not complete, we felt it was a low threshold hurdle, but in term o starting poing of discussion to genereate the integration semantics.

Abdul-Malik Shakir: HDF is not complete, neither are SAEAF or core principles. All explain holes in the process. THose gaps need to be filled. Our end game is that all those gaps be filled in the saeaf, and need to shore up HDF and Core Principles.

Charlie Mead: we need to have a coherent tsc announced, arb and MNM effort to evolve the HDF to be the SAEAF implementation guide. WB: I think there is no objection to saying that is the direction.

John Koisch: we spend a lot of time doing that.

Galen Mulroney: she was blindsided by the prospect of deleting everything. LM: I actulally dont have any issue with charlies propsal - missing is the third piece, which is MIF, the detailed meta-model. You dont put it in eithere of the other documents, should be appendix to core-principles or HDF. We need a tightly constrained meta-model. We need to figure out what it looks like, where it lives, and maintains its functions, and provides direct support.

Mead Walker: We need to remember the existence so we dont re-create. We need to walk thorught hcore principles to create it.

Dale Nelson: I am confused. i would expect the MIF to fall into the platform independent Computational viewpoint.

Mead Walker: The MIF is computational as well as informationa. WB: the mif contains some of core principles - defines class and it contents. I disagree with dale - MIF is for HL7 not for othere enterprises.

Dale Nelson: DOes it not fall into one of these slots? WB: I dont want to go down that. Anyone can write processes. Original MDF99 one wrote processes, and other wrote core-principles, so every chapter had a core-principles beginning and a process ending. If you get core-principles wrong, it wont work. .Coreprinciple is not finished -MDF99 is a good revision of MDF97, and is a foundation of core principles. It is silly to re-map Core principles now, and re-map to SAEAF. THe lore needs to be documented, in MnM's camp, and invested in the SAEAF, which is what core principles should become.

John Koisch: Low hanging fruit - can we decide that the HDF undergo surgery and become a full-blown process, make a motion to modify HDF to support SAEAF as a process spec.

Mead Walker: I make the suggestion that what we vote on be the end-state - a unified document set that is harmonious and consistent. We do that knowing that all are not in the end state, and figure what we do to get there. People become paranoid when they hear re-write. It needs to evolve.

John Koisch: The ea rollout points to the HDF as the lingua-franca of process. WB: where is it difficient?

John Koisch: YOu will not generate the requirements. It comes down to different readings. If alpha projects are looking at the HDF as authoritative, they are not generating SAEAF artifacts.

Mead Walker: we said there is an end-state, but the HDF does not include the things we need. We need to say what the HDF needs, and put it in the hopper. I dont hink they are the same.

Abdul-Malik Shakir: alpha projects will try to achieve what they need, and will come looking for guidance if it is difficient.

John Koisch: Alpha projects and domain groups are using the HDF as an authority of process, not deliverables. WB: what is the deficiency.

John Koisch: HDF does not mandate a DAM, and it is the authoritive model. WB: There is a rule that has not been socialized.

John Koisch: HDF is held up as authority. WB: you are creating a new rule that has not been socialized. JK The HDF is an authority for process and authority. LM: You do not have to create DAMs anywhere. HL7 does not require it.

John Koisch: HDF is governance: the HDF needs to be facilitating guidance for the SAEAF, and the notion of the core document. WB: This group draws from arcrim: a fundamental divergence within arcrim a single domain model. Other think they are being forced. The ARCRIM management issue is put aside. The HDF is not a barrier. Set it asside

John Koisch: Forget the HDF and do your own process? WB: No, socialize the requirements within HL7. WHen the groups say it does not require it, they will come back to you.

John Koisch: Tight governance? WB: Live with the HDF: if the missing DAM is a project, make the decision. LM: worrying about tightening the HDF is last - first is DAM format, publishing, does it work, and once we get to the comfort to expose, tools to capture, what UML you are allowed to use or not, we are not close to that.

John Koisch: John asked the ArB to evaluate the HDF, re-write, or come up with what needs to happen. Ultimately it is not wrong. There is advice from eh SAEAF as to what the HDF should and shouldnot require. It is not mandated for all projects. We have been living with this for a year. LM: upodating the process document to state what must occur is lowest on the priority. We can get committees to voluntarily to do anything. We will figure process after some experience

John Koisch: The HDF is being held up as a reason NOT to do things.

Abdul-Malik Shakir: I agree with Lloyd, at least I think i do. THe alpha projects - we need to make it clear to them that the HDF is not gospel, or authoritative - part of the alpha experience should be to identify the shorcomings. The DAM is recommended by the HDF, but not required. It is for all kinds of projects - it is not needed for all projects, e.g. datatypes. We need criteria for what must be done

John Koisch: There are two EAS, the universal HDF, and an additional HDF for constraint for implementation.

Jane Curry: THat chapter did not get written. WB: I am in tune - we should leave it there, i sense that there is violent conflict, but the HDF does not specify the models.

John Koisch: The facilitating aspect of goevernance. We felt we need to harmonize with the HDF - from the owners of the HDF it is so generic that it is almost optional. We dont have anything to say about it. If it is informative guidance, then that is the answer. IF that is the case, that needs to be clarified. WB: they are using it for information - the alpha projects should follow the HDF, but it should not conflict with the things you want to do, not about forcing then to do DAMs. Bringing in a requirement for DAMs may be a good thing.

John Koisch: I thought John Quinn agreed to revise an bring forward. WB: re-write over time, next 12 months.

John Koisch: I understood we would re-write it. LM: you came into this with an issue of not doing a DAM. FOr most commitees it is not an issue - for the alpha projects should include expectations including a, b, c. YOu may want to let different alpha projects to do DAM's in different ways. After the projects provide feedback, then we re-write the HDF>

John Koisch: I have no mandate on timeline. I dont want to re-write the HDF, I am concerned that it is informative.

Wendell Occasio: did anyone do a gap analysis? Is the problem partially semantic?

John Koisch: we did parts of that analysis.

Jane Curry: there is a piece of the HDF where there was references on how to do services - one paragraph and one diagram. There are two timelines, with scarce resources, so the two groups could not effectly accomplish the review of the SAEAF or HDF. Both groups are coming for peer review.

Wendell Occasio: HDF is a couple of hundred pages.

Jane Curry: Two chunks - how do you get a project started, and a big chunk on change management, and a decent requirements section, implementation, and little development.

John Koisch: My position is that the SAEAF is structured differently from the HDF. It is not just a layer of artifacts, it is a set of layers with governance.

Wendell Occasio: If that is an issue, expand it into the discrepancies, come up with a list, how big is the problem, and adjucate the problem. How far off are we? Let understand the problem.

John Koisch: the DAM issue is trivial.

Wendell Occasio: we discussed implementation guide do we have enumeration of them?

Jane Curry: There is inconsistent terminology between core-principles and HDF.

Wendell Occasio: align to the core principles first, then the HDF.

Jane Curry: The other conversation is the BF.

John Koisch: we resisted a peer review comment.

Wendell Occasio: peer review is a review with comments. We need to do a GAP analysis, and adjucate the problems.

Jane Curry: it is a bandwidth and timing thing.

John Koisch: that is within the core-principles dicusssion. I think there are foundational things that are different, it is more than a gap analysis. WB: Core principles is easier and harder. More difficult since it has more technical detail. We need to take an objective to transform coreprinciples - it is fundamentaly different from the HDF. We do not have the time or bandwidth - we could use a bright paid writer to correct it, then align to SAEAF. There should be a major activity to align the core-principles to the SAEAF, which should contain current and new. We should have a process document and artifact document. Core principles defines the technical model in the MIF. Prospectfully if it functions as our meta-model it should be instantiated. LM: Core principles should be recognizable in the ballot. As we go forward, we will have core-principles in flux. We will need a method to publish the to-be.

John Koisch: Charlie McKay rejected dual tracking. WB: we cant do that - we need to make it a complex document, all in one place. LM: a piece of core-principles and MIF have a tight coupling to tooling.

Jane Curry: The Change management process needs to hook these things together. Current mIF is 2.14, not refelected in our current ballot. The future tooling is more expressive. This is a versioning and management issue. We have a transition management issue. Two audiences are content creators, and another is content consumers. It will need professional change management.

Abdul-Malik Shakir: I am leaning toward Lloyds opinion, I am worried about the confusion using old-speak and new-speak in the same space.

John Koisch: Charlie was really concerned about running two ballots at the same time. LM: Datatypes R1 and R2 are published side-by-side. Each ballot could state the basis of the methodology used.

John Koisch: we have discussed the difference in the new material publishing and ballot. LM: It does now.

John Koisch: the expressed normative edition with more visual space and less document space.

Abdul-Malik Shakir: v3 guide discusses interactions, we build exchanges, and in the ballot we call them different things. PL: at what point do we finish the Core Principles, if we dont merge them, we will be more confused - we should not do the R1/R2 approach. I support Woody's idea - it is more confusing to not. WB: we are adding a semantic structure. PL: we need to come up with what is more intutive. what is easier for the balloters.

John Koisch: is this one of the requirements. WB: lets understand what the future looks like, re-align, and announce future morphs.

John Koisch: take 5

Q2 - Behavioral Framework

WB:I looked at the current ballot ballot to determine which ballot products are EAS, out of it: Content standard, EAS content, Publishing Artifacts, and questional?

John Koisch: There are composites and primitives. Lloyd pointed out the intent of some content may be core when it is really EAS. WB: Is CTS a content server or a primitive or what? LM: CTS has an aspect to be used to define constaints. WB: The imbeded constraint language is interesting, but not core. LM: Pieces may be infrastructure - some will live in both spaces. WB: we have to reference one from the other.

Abdul-Malik Shakir: It would be interesting to develop inclusion and exclusion criteria. WB: This was to generate thought, not be all encompasing.

Jane Curry: Can we do dynamic model before we use the audience?

John Koisch: What do we show?

Jane Curry: The behavioral framework model.

Abdul-Malik Shakir: walked us through the document on slide 106 of the slide deck.

Abdul-Malik Shakir: basically some of the concepts we currently have in our BF remain, but are given a new name for context. Interactions today has the sender/receiver/responsibilities, which may end up with another interaction. LM: Is interchange point made up?

John Koisch: From RM-ODP.

Abdul-Malik Shakir: Interchange point is either a consumer or a provider. LM: a given point can do either/ both depending on the peer.

John Koisch: Martin Fowlers definition of interaction. There is a commissioning agent, or a consuming agent. LM: In lab you have a simple transaction pattern where I make a request and get a response - that is a unit of work. It is a portion of a larger set, including order, promise, fulfilment, result. Where is the broader thing. PL: the overall process is the order and fulfillment. Different things happen, and all are required.

John Koisch: the notion of milestone and composite milestones align with the W3C real-world event. Lab order would be a collaberation type. It may have sub-units of work-unit type, which are collections of interactions. LM: we can process asynch as well as parallel interactions?

John Koisch: yes. They must be nested carefully. LM: last time, we had gotten to the point where you represent this thing, it get big/fat and ugly fast. WE discussed patterns for workgroups so they dont have to re-pmodel themselves - e.g. a fulfilment pattern = these are the aspects of the pattern that are required or not. How far have we gotten?

John Koisch: there are three structures in ght BF: collaborations, alot of what you are describing is collaborations. This is the patterning mechanism at a certain level. Service providers may encapsulate within services. The third pattern is how the services are aggregated - process services equate with the collaboration type. LM: there are multiple layers of patterns. What I would like to get is that eventually we will have a publication tool - here is a template you fill out.

John Koisch: here is stuff you may re-use. LM: there will be balltion for the patterns, then make it available in the domaing tooling to create a concrete specification. How close are we to saying what patterns look like, this is what the tool is. We cannot implement until that is in place. Otherwise everyone will go in there own way.

Jane Curry: alpha projecst will determine candidate tools.

John Koisch: we have draft versions of uml profiles for this, and the schemas. We have the notion of contracts that add a layer of semantics. All of those things are important - the formats etc. need to be discussed. You need run-time tooling. LM: I dont care about implementation. I do care about what the publication leaf for pharmacy will fill out to pass to publishing.

John Koisch: you will work with UML or XML in the alpha projects. LM: That is not a long-term solution. WB: not enought detail work. LM: the alpha project will not have the tool we need - but I would like them to behave as if we had the tool.

John Koisch: Should that be in the HDF? (:-}. Specifically with OO they are thinking of the patterns, although they do not support the tooling underneath. There are tools and analytical constructs. LM: I know there are tools. Do they take pattern based approach? So they can be published with the parameters?

John Koisch: we have had long discussions with Steven Ross Talbot - HL7 is the first vertical industry organization that it rigorously thinking about it. A leve lf magnitude above x12. I have discussed with him templating. he has expressed interest in getting a project to do so. LM: there is a tool. What I want to ensure that the alpha project create discrete objects -fulfilment pattern, composed of individual artifacts. how do we want to publish.

John Koisch: the semantics will be the semantics. The connections will be clean, the discrete artifacts will have a good first cut. An artifact from the HL7 aspect is discrete pieces published and encompases multiple boxes. Static model has pointers - some are in the model, some are not.

John Koisch: my pushback on re-usable stuff - collaberative patterns can be re-used, and balloted: underneath it are services, e.g. lab order management service. The management is the the dependancies. What needs to be build, re-used - relates to durable service structures. LM: we will not have a section in the ballot with milestones that are balloted separately. The alpha project needs to understand what they are, and what they are called.

John Koisch: this is the expresson of an artifact. WB: large fraction of whats there is algorithmic once it is there. People will spend all their time building these. LM: today trigger events, application roles, interactions are artifacts. Some are one or many of these boxes. We need to get to the same level in the saeaf. It is too hard to understand, we need smaller granuarity - a step we need to do. THe bigger boxes Hl7 membership will care about. WB: I see this as a structure within which I can define a system. HL7's business is not defining a system, not define the ultimate system for doing orders: Even if we got it right to role out business objects, we could not do it. Interoperability is a pattern of these.

John Koisch: My response is this is a model that supports rich descriptions of things that need rich descriptions, and slim descriptions of things that are slim. The BF is providing a place for those semantics. I would argue against a system description. If you dont provide a rich framework, you back, yourself into a wall. I would see them granulated differently. GS: We currently have several common patterns. We in admin could exploit the common patterns. PL: the meeting in sandiego had state machines on each side with stick/ladder diagrams, but we never go to the final pattern. GS: expression of business responsibilities

John Koisch: this is a layered model - is at the conceptual level. Implementable specification includes error-handling and fault types. PL: the old methodology did not capture enought information - conversly the worst problem is that we expose enough information to the balloters. Some of what you hear is a balloter, to digest fifteen different models will not have the time. We need to fight ballot fatigue. Hide everything else, and make it accessible.

John Koisch: at NCI we have cross-functional teams with cross purposes who wants to see it differently. Business analyst want to see a different level. THe layering of the communication is not easy, nor efficient. However, it is something we tried to deal with with the notion of layered specification. The point is that we have all the answers, my big concern is that we strategize how to publish.

Jane Curry: Alpha projects need feedback to the ArB as well as the tooling requirement.

Abdul-Malik Shakir: People will do bad things. WB: If we dont help them they will.

Abdul-Malik Shakir: we need to look at the mind-map. LM: we need a mock publication - this is the sections, pictures, etc.

John Koisch: the behavioral aspects are hard. To ignore the hard parts is bad.

Abdul-Malik Shakir: It reminds me of a sales class: when they ask does it come in almond the refrigerator has been sold. We have thought about it.

John Koisch: t`his is the place where tooling jumps over hurdles.

Jane Curry: were are not asking you to do it Woody. WB: the proble`m with tooling is that the tooling tends to expand it. People will pay attention to the semantics. IF we set down, five fields are important.

John Koisch: They are verbose. WB: does the reviewer need more than five? There is stuff necessary, not completeness, what is necessary to assess it. We are developers and voters of standards. The developers can crank out fifty subsets of patterns, but not fifty models. Tools are not the problem.

Lunch - Architecture Governance topics outstanding

Q4 - Gap analysis

Gap analysis of supporting artifacts from the SAEAF for Alpha project teams, including arriving at straw samples if necessary (Conformance Assertion Matrix)

Q4

Note to tony:
	Add to web page 
	(lens)
	SAEAF
	^
	^Governance
	^
	
	EAS  Tony Julian