20090611 arb telcon minutes

Architecture and Review Board Meeting Minutes

June 11, 2009

Back to Agenda-minutes

Attendance

Name	Present	With	Affiliation	E-mail address
Curry, Jane	Yes	ArB	Health Information Strategies	janecurry@healthinfostrategies.com
Grieve, Grahame	No	ArB	Kestral Computing	grahame@kestral.com.au
Julian, Tony	Yes	ArB	Mayo Clinic	ajulian@mayo.edu
Koisch, John	Yes	ArB	NCI	koisch_john@bah.com
Loyd, Patrick	No	ArB	Gordon point Informatics LTD.	patrick.loyd@gpinformatics.com
Lynch, Cecil	No	ArB	ontoreason LLC	clynch@ontoreason.com
Mead, Charlie	No	ArB	Booz Allen Hamilton	charlie.mead@booz.com
Nelson, Dale	Yes	Arb	II4SM	dale@zed-logic.com
Ocasio, Wendell	No	ArB	Agilex Technologies	wendell.ocasio@agilex.com
Parker, Ron	No	ArB	CA Infoway	rparker@eastlink.ca
Quinn, John	No	ArB	Health Level Seven, Inc.	jquinn@HL7.org
Shakir, Abdul-Malik	No	ArB	Shakir Consulting	ShakirConsulting@cs.com

Discussion

SAEAF, Behavioral Framework

John Koisch: Spent lot of time to get people to meetings, then they have problems with what is being said – in terms of , if anyone says , it is important that we have a common message.

Jane Curry: One of the ways is to exercise it. Walkthrough it, and see if we can do it.

John Koisch: You didn’t think that the Australian example was getting towards concrete?

Jane Curry: I do, but they/we did not understand the milestones, or roles. ARB needs to produce concrete examples, it is too abstract.

Jane Curry: every box needs attribute, and relationships need to be named per AMS.

John Koisch: Finishing up a good draft: go through the OO use cases, and work with PL: to turn into model renditions, as well as Grahames Australian thing. Those are my next two steps.

Jane Curry: I don’t disagree – I will tell you that my participation in OHT Chicago last week, I can describe tool interoperability – add to governance slides. They are governance, and have implications for computation/information.

John Koisch: We are using BF at NCI. The BF runs straight into governance.

Jane Curry: OHT: when you defined the functional what, you ran into roles and issues – which runs into governance.

John Koisch: Jane and I should touch base on tooling.

Jane Curry: You have to put your whole head-space into META-LAND.

John Koisch: I had a tooling discussion with Grahame.

Jane Curry: Because we are talking about Eclipse, mif, mof, etc are confusing

John Koisch: Next week agenda, even more broadly – next steps. Any ideas?

EA Rollout Projects

Jane Curry: Kyoto- what are the expectations of the projects? What engagement processes do we have with the projects? Marc should attend the next meeting.

John Koisch: CTS-2 and STRUCDOC (CDA-R3)want discussions. CTS2 are running into a wall – it is compliant to SAEAF, but they are getting confused.

Dale Nelson: General observation: Don’t know where it fits in: ARB work coming out of Kyoto: It is very difficult for anyone/everyone to understand what a initial project in the SAEAF framework is. What does it accomplish, e.g. Pilot projects, what does this mean, what are the deliverables. What is the message as to what engagement really means? I am struggling with this. Maybe it is just me. We are talking in meta-meta languages/infrastructures.

John Koisch: Action item: Ask do you think you could undertake to write a paragraph or two about what SAEAF projects will come out with, to start the conversation. Is that too much to ask?

Dale Nelson: It is relevant. Til we get there, all we will get is lip service about conformance to SAEAF and BF. There is something missing in our expression.

Jane Curry: we are missing the specification stack. Suspect it is not at a priority – we should do it jointly.

Specification Stack Completion Challenges

Dale Nelson: Exactly symptomatic of the problem. I am not convinced that the chart is not further along because we don’t have time, but because we don’t understand the requirements.

John Koisch: I think that Jane understands governance and policy, what we find is limitations to the presentation format. A lot comes down to experience – using common sense. If you use a noun, e.g. Behavioral model as an expression of computation, runs into governance, information, and engineering. Consistency becomes a problem. When you create or consume an artifact, it is not like you are laying out a piece.

Jane Curry: We need composite artifacts that have relationships to the other viewpoints. BF specifies structural governance. The struggle in trying to describe something useful, as well as fitting them into viewpoints, requires you to specify the composite as well as the atomic elements. We need relationship between the viewpoint’s atomic elements.

John Koisch: I had to take apart RM-ODP, and ran into that – BF has to pull in concepts from other viewpoints.

Jane Curry: You can't talk about one without referring to another.

John Koisch: How are we going to have time to express in formalisms?

Jane Curry: That is where we are struggling. My attempt to do this, it almost strikes me that we need to talk about artifacts as composites, as well as quality.

Dale Nelson: the placement is exacting – there are elements of each viewpoint in another viewpoint. That is not clearly visualized. IT needs to have degrees of opacity, overlapping clouds? Maybe that is what is missing. Might be interesting to play with.

Jane Curry: I am coming around to the idea of working in concrete artifacts, and writing what composites live in other viewpoints.

Dale Nelson: I will try to mockup a variation on the grid.

Jane Curry: We left the reference layer in.

John Koisch: so they did not get scared.

Jane Curry: It is relevant. The valid artifacts are acknowledged.

Dale Nelson: when we go full circle, and describe the 4x4, when we have projects going on, where are the concrete steps for connecting into the abstract framework? Do we have a fair idea of the projects, and where they fit in?

Dale Nelson: Maybe that helps a bit to understand where exactly is Marc’s project? Where will that illustrate synchronization or connection to the framework.

Jane Curry: We would be helping define the artifact to demonstrate that they are filling out the layers, related to their platform-independent design. For CDA-R3 they are producing platform specific designs.

John Koisch: actually people are confused to what a platform? Guidance: I think that we need to revisit the question. A platform is something that is implementable. Is HL7 V2 a platform specific specification.

Jane Curry: It is an abstract syntax – a parsing syntax – I think is platform independent. It meets the constraints of engineering viewpoint.

John Koisch: Any trading partner agreement is a platform specification.

Dale Nelson: It always seems there is a one-to-many relationship betweens pims and pisms? One-to-many static relationships. You develop a pism that represents a platform. I realized a platform is really more than a single platform, it is an orthogonal mix – an n-dimensional cube(sic).

Platforms

John Koisch: consider this: OMG considers XML, Java, and to be independent platforms.

Dale Nelson: Included hardware, topology, computer language, expression language. That is the problem mapping a pim to a pism.

John Koisch: before you conclude – I think that what we are about is creating platforms – take V2 notions, tie to deployment considerations, trading partner agreements. It is topic oriented. e.g. ADT is an interoperability platform for exchanging adt stuff. If that is on the right track - - what we are saying is that we are about platforms, what you build on, laying out the things to provide a solution.

Jane Curry: That implies that the engineering constraints have to be applied at the conceptual level. I think I would be changeling to use exactly the same specification for a topic with an entirely different engineering viewpoint. That is what you were saying earlier on.

John Koisch: ?

Jane Curry: Even at the conceptual level platform creeps in.

John Koisch: You never build without knowing where you are going. I don’t feel as strongly about that statement as you do Jane.

Jane Curry: If you took the V2 stuff and re-engineered out the conceptual layer, you would not get the same viewpoints as if doing the same with V3.

John Koisch: V2 = V3

Jane Curry: started that way, but notion of person was not in V2. This brought out role-based.

Dale Nelson: Object wanted ot mirror on either side of an implementation.

John Koisch: That is the point? How do you build this stuff? V2 is a great solution, built to suit.

Jane Curry: Grahame said all they paid attention to is the messages, ignoring the trigger events – adapting the meaning to suit the governance. They selected a subset and implemented accordingly.

John Koisch: Those are the things, to me, that you want to get laid out.

Jane Curry: Implications don’t show in the spec. The governance and business model were assumed. (in us, intra-organizational , it worked). Cross organization, it does not hold up.

John Koisch: the concept to platform needs to be defined. Just as J@EE provided registries, serializable beans, all of those things are important. – They are just a platform. If we acknowledged that we are building platforms.

Jane Curry: or adopting platforms, e.g. using OASIS for healthcare.

John Koisch: an implementation guide, how to hook things together? That is deployment.

Jane Curry: I would agree that anybody who participates in a shared environment needs implementation guides, taking into consideration real world governance.

Jane Curry: I have to leave at 3:00.

John Koisch: Have enough for agenda/discussion for next week.

Dale Nelson: I might not be on next week. = I will see.

John Koisch: Thanks everyone.

Adjournment

The meeting was adjourned at 3:00pm

Tony 14:05, 18 June 2009 (UTC)