20090625 arb telcon minutes
Architecture Board
June 25, 2009
Contents
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 |
| Koehn, Marc | No | Guest | Gordon Point Informatics Ltd | Marc.Koehn@GPInformatics.com |
| Koisch, John | Yes | ArB | NCI | koisch_john@bah.com |
| Loyd, Patrick | Yes | 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 | No | Arb | II4SM | dale@zed-logic.com |
| Ocasio, Wendell | No | ArB | Agilex Technologies | wendell.ocasio@agilex.com |
| Parker, Ron | Yes | ArB | CA Infoway | rparker@eastlink.ca |
| Quinn, John | No | ArB | Health Level Seven, Inc. | jquinn@HL7.org |
| Shakir, Abdul-Malik | Yes | ArB | Shakir Consulting | ShakirConsulting@cs.com |
| Yan, Peter | Tes | Guest | NCI |
Agenda
- Call to order
- Approval of Agenda
- Approval of minutes June 18, 2009 Minutes
- Update on the SAEAF EA Rollout Project
- Presentation on behavioral compatibility and platforms
- Adjournment
Call to order
The meeting was called to order at 2:00pm U.S. EDT with five attending.
Approval of Agenda
MMS to approve agenda as published Jane/Tony (5-0-0)
Approval of minutes June 18, 2009 Minutes
MMS to approve the minutes of the June 18, telcon Patrick/Tony (4-0-1)
Update on the SAEAF EA Rollout Project
John Koisch: Did not reach out to people as to time. I can do that if there is discomfort.
John Koisch: RE: Changing times, I did not send out e-mail. Wendell Occasio has not, Abdul-Malik Shakir: time is ok, Ron Parker: and Charlie Mead have schedule confilicts.
John Koisch: Charlie Mead does follow the minutes, with discussions from JK:
Jane Curry: Please post to wiki if you reach conclusion during dicsussions.
John Koisch: If there is a side communication, post to wiki, and notify.
Jane Curry: There are some offline conversations where I forget who has heard what.
John Koisch: I brought up a notion
Peter Yan from NCI joined.
Presentation on behavioral compatibility and platforms
John Koisch: I brought up the concerns of platforms - and they are not defined properly in MDA.
"the specification of a common set of features of a technology in sufficient detail that a logical model may be consistently and traceably instantiated"
John Koisch: The outline is simple-
Dale Nelson: Very motivational, as is the title.
John Koisch: I dont want to talk about motivations section, but go through it. I will publish for markup.
John Koisch: WHY? See Janes Governance slides.
John Koisch: We use a framework to discuss the relationships. Standardization is an aspect that Jane has a lot of material on. Implementations are the goal - to make them seamlessly interoperable, or what transformation components are needed to make system interoperable.
Jane Curry: Can you make specifications interoperable or applications?
John Koisch: Implementations are interoperable, you can only measure implementations.
Dale Nelson: This is the 'Holy Grail'. Reason V2 is not.
John Koisch: You are right, next couple of slides.
Abdul-Malik Shakir: We called it plug-and-play.
Jane Curry: Another piece - HL7 specs are not implementable per se, the need constraints applied. Universal spec constrain to a level, further specs need to be produced. HL7 derived specs are implementable.
Dale Nelson: I have been in dicusssions about which tools are available. I think that the statement on slide 9 "Make implementations of HL7-derived specidications to be seamlessly interoperable. Assumption is that if there are schemas, there are tools that will plug them in and make them interoperable. Eclipse, OMG, et. al. who are struggling to make this possible have a magic bullet.
Jane Curry: Additionaly with applications that are not tuned to this. Localized/customized applications give implementors fits from day one. It is not the applications that are not interoperable, it is the business rules.
Dale Nelson: We know how to exchange XML things. But we are not exchanging business rules. "Send me the Schema", but it does not work with existing tooling.
John Koisch: We are having tooling with infrastructure - CABIG V1 tooling was built for purpose, then assumed to be fit for all purposes. Goal is to reverse-engineer to that purpose. FOr this topic the tool kit works, for this one here it does not. You will have to cope.
Jane Curry: That needs to get across. Implementation experience is that the hardest thing is the business rules as they affect the model - functions are not exchanged, just values.
John Koisch: Any issues.
Dale Nelson: No implicit issue, but a larger issue I am learning that there are US agencies coming together with mandates for universal continuity, and we need toolsets.
Jane Curry: The timeframe is too short.
Dale Nelson: Call about easy ways we can implement all the semantics of V3 by the end of summer. People are serious! We need to express these slides in a way that will be disseminated!
John Koisch: This is hard - - Oh #$%^- dont panic!
John Koisch: This is for RM-ODP - R is not readable. (slide 11). Systems are cahracterized by behavior and state. RM-ODP was created for distribution transparency. This is the notion of a helpdesk call center, and you dont care who serves you. Another is universal healthcare record. This is the spectrum.
Jane Curry: You are using transparency in a way that is not understood from the dictionary - you really want encapsulation.
Ron Parker: There are two levels of abstraction - you cant see what is behind the bar: all of the stuff on the left of the bar, only needs to know if it is behaving to the constract.
John Koisch: I go into an explanation of transparency, then to behaviour. Includes 7 types of transparency in RM-ODP. Jane is right, we should make transparency/encapsulation clear.
John Koisch: What you are getting at, is behaviorable compatability and replacability. When you create standards built on RM-ODP, you define system compatability. Another way of looking at the "Stairway to Heaven". How replaceable is your person service to mine? Most of content is RM-ODP, the presentation is my fault. These things need to be laid out.
John Koisch: Why do we need multiple PSM's? There are multiple PSM conformant interfaces, but do them in different ways, so each may need an adapter. Everyone thinks we will define two boxes, but you have to build boxes on the fly (slide 15) to get the job done.
Jane Curry: If you dont have agreement at the conceptual level of the content, you cant build adapters. People have not collected the data they want, in a consistent way.
John Koisch: Jane you need your own quote book.
Jane Curry: We never had agreement as to what information is important - vendors provide at the customer lever, which vary.
Dale Nelson: That is central. Every project that begins with "forget the concepttual model" we will see where it fits in later.
Ron Parker: Like slide 15 a lot.
Jane Curry: Deal to concrete people. Needs to have an application that just cannot play.
Dale Nelson: Wrong data type.
Jane Curry: Pick up the phone, this application cannot cancel orders.
Dale Nelson: We need to define how two can interoperate when they cannot agree on the timestamp.
John Koisch: YOU would not belive the discussion on iso datatypes.
Dale Nelson: That would be the orphan, that cannot semantically interact.
John Koisch: You cannot prove a negative. Tranparencies (slide 17-18). I have gone through RM-ODP in detail - Wendell O and I have gone back and forth - you read it, and suddenly the light dawns - these guys were genius before anyone else was discussing. The yellow (slide 18) are HL7 concerns.
Ron Parker: A whole series on failure.
John Koisch: When you get into these, oh, thats right.
John Koisch: Notion of platform specific model makes clear which transparencies are laying out. From PIM you cannot lay them out. We have been missing transparency inthe spec stack. When you choose your platform, you are after access transparency, or persistance transparency. These are clarifying things - why did you choose the platform, what charactistics were involved in the choice.
John Koisch: Here are the requirements at the tranparancy level - makes one PSM work with another.
Jane Curry: Does HL& not also tcare aoubt relocation transparency, given the defintino on slide 18?
John Koisch: yes
Jane Curry: Receiver responsibilities?
John Koisch: SUre
Jane Curry: you have to read 40 times, we need examples.
Ron Parker: yes, I agree.
Jane Curry: Migration transparency is on the groun, as is relocation. We care about the rest of them, and have mechanism to deal with the concerns.
John Koisch: Three parts to PSM (Slide 26) - you are dealing with a cube, not single layer at the Platform Definition. OMG has affirmed this with their definition of platform.
Abdul-Malik Shakir: the encodng rules are the constraint on V2, the ITS on V3.
John Koisch: Those are platforms, which have their pluses and minuses. V2 and V3 prseume different transparancies. You pick a platform on what is will give you or how you will implement it.
John Koisch: I am close to submitting this deck which proposes the framework around the stack.
Abdul-Malik Shakir: Trying to understand multiple platform definitions.
John Koisch: Trying to convey that platforms can build on other platforms.
Dale Nelson: You can model a PIM to PSM as a 1 to N. The problem is that the N PSM specifications are a parts-explosion of platforms, really 1 to N,N,N. Some absorb charactistics of others, e.g. XMT/JAVA vs XML.NET. It is 1 - N influnced by multiple platform definitions.
Abdul-Malik Shakir: It is a collection of platform definitions.
John Koisch: Yes, you can use XML, Java, J2EE, .Net, WSDL in many combinations.
Jane Curry: We need to example why the install base is overwhelmingly V2, since it was platform dependent on hardware - cant jump to V3 it the install base architecture cannot deal with it, and where the vendors are the maintenace source, looking at the complexity of changing to it. Current envirenment is not sufficiently robust to accept it.
John Koisch: The downsteam stuff . . it is an adjunct to the SAEAF book. Needs work to explaing implementation guides, and some concepts we have not fleshed out. We ahve not discussed platform definition.
John Koisch: We have seven minutes - I feel support that this is the right direction.
Ron Parker: That is fair.
John Koisch: I will now do what we do - HL7 needs all of these (slide 18).
John Koisch: Any action items or issues for next call.
Jane Curry: You were to talk to John Quinn about harmonization.
John Koisch: I have submitted formal request for funding for those who needt it for Traverse City, with the reasons behind it. Nine of us going, we will have to come up with agenda, plus justifications. John Quinn is trying to find absolute affirmation.
Jane Curry: I will follow up tomorrow.
John Koisch: I dont have answers, I talked to Karev Van today. It seems to be on track.
Patrick Loyd: August 18,19,20.
Ron Parker: I have 18-20.
John Koisch: In Traverse city Michigan.
Ron Parker: Prefered location?
John Koisch: HL7 should have published on site with Harmonization.
Abdul-Malik Shakir: Not yet confirmed?
John Koisch: Not yet. I will let everyone know.
Dale Nelson: On the calendar the dates are marked out, with no location specified.
John Koisch: It is not in a hotel,it is in a tent.
Ron Parker: Long as there is a white board.
John Koisch: When geeks go camping.
Abdul-Malik Shakir: We can write on the ground.
John Koisch: I will send this out soon.
Adjournment
Meeting was adjourned at 4:00pm U.S. Eastern
Tony 20:00, 25 June 2009 (UTC)
