20100506 arb minutes
Template:Arb minutes Architecture review Board Meeting Agenda
May 6, 2010
Contents
Attendance
| Name | Present | Affiliation | E-mail address |
| Bond,Andy | Yes | NEHTA | andy.bond@nehta.gov.au |
| Curry, Jane | Yes | Health Information Strategies | janecurry@healthinfostrategies.com |
| Grieve, Grahame | ? | Kestral Computing | grahame@kestral.com.au |
| Julian, Tony | Yes | Mayo Clinic | ajulian@mayo.edu |
| Koisch, John | Yes | Guidewire Architecture | jkoisch@guidewirearchitecture.com |
| Loyd, Patrick | No | Gordon point Informatics LTD. | patrick.loyd@gpinformatics.com |
| Lynch, Cecil | Yes | ontoreason LLC | clynch@ontoreason.com |
| Mead, Charlie | No | National Cancer Institute | meadch@mail.nih.gov |
| Nelson, Dale | ? | II4SM | dale@zed-logic.com |
| Ocasio, Wendell | No | Agilex Technologies | wendell.ocasio@agilex.com |
| Parker, Ron | yes | CA Infoway | rparker@eastlink.ca |
| Quinn, John | ? | Health Level Seven, Inc. | jquinn@HL7.org |
| Shakir, Abdul-Malik | ? | Shakir Consulting | ShakirConsulting@cs.com |
| Guests | |||
| Koehn, Marc | No | Gordon point Informatics LTD | marc.koehn@gpinformatics.com |
| Laakso, Lynn | No | Health Level Seven International | lynn@hl7.org |
| McGaughey, Skip | No | ||
| Peres, Greg | No | CA Infoway | gperes@infoway-inforoute.ca |
| Robertson, Scott | No | Kaiser Permanente</td? | scott.robertson@kp.org |
| Smith, Karen | No | HL7 Technical editor | karen@smithspot.com |
| Thompson, Cliff | Yes | OntoSolutions LLC | cliff@ontosolutions.com |
| Hufnagel, Steve | Yes | ??? | Stephen.Hufnagel.ctr@tma.osd.mil |
Agenda
- Call to order
- Approval of Agenda
- approval of Minutes
- Agenda for Rio
- Peer Review update
- Other business and planning for next meeting
- Agenda for Rio
- Adjournment
Call to order
The meeting was called to order at 6:00pm U.S. EDT with Ron Parker as chair and Tony Julian as Scribe. Quorum was achieved.
Approval of Agenda
The above agenda was approved by concensus.
approval of Minutes
Motion to approve (Tony/Steve) (3/0/0) April 15, 2010 minutes
Agenda for Rio
Tony will meet with Ron by phone, and Saturday. Agenda was reviewed. Jane Curry: It will be difficult for groups to achieve quorum. How do we handle if we dont have sufficient responsiveness. Cost was an issue in participating in the WGM. Jane Curry: OHT has come up with a govenance proposition. I need to bring to ARB.
Peer Review update
Ron Parker: Steve has provided comments.
Cecil Lynch: What is the current version?
Steve: Version C. Two categories of comments: 1. Document is hard to build spec from. There is no "how to". Entingger did not find it intuitively obvious where the artifacts go. There was a guideline on vertical traceability. The suggestions are in conflict with normal flow.
Cecil Lynch: A lot of that is in the information viewpoint as well as implementation guide.
Steve Hufnagel: Traceability is both horizontal and vertical. If the use case belongs in the enterprise view, you need traceability to the computational view.
There is no guidance on structural specifications - where to put module that links one viewpoint to another. Section 2 lists ambigous items. One could argue where the artifacts should go - many belong to computational instead of the other groups. RE: Ontology, software overloading of 'capability' and 'contract' should be defined better. Capability can be at all of the levels. So the terms show up in multiple cells, and it introduces ambiguity.
Steve Hufnagel: THis appears to be a SOA template, not a service aware template. The template should not discuss services when it means functions. Steve presented example on line 112. We put footnotes on the key terms, with definitions at the bottom of the page. There probably is a better style, but this is one way of defineing the terms within the context. After doing immunization management, we had more artifacts than were in the table. We tried to focus on these things intuitivly fitting into a place. There are 2 options - take the section we provided as a how-to-guide, which contains BF, and put in your document, or reference it from your documents. It was really tought. We had a lot of senior engineers doing a lot of head scratching.
Ron Parker: We knew at the outset, in the early days, we were rationlizing what it is, and why we might care. We struggled with artifact placement both HL7 and non. We appreciate the second table - which did what we hoped the alpha's would do.
Steve Hufnagel: That is why we should put it in an appendix, or main line.
Ron Parker: We are a little from the Implementation guide, and hoped to flesh it out from the input from the alpha projects. The challenge is we have to look at the language, and what we need to state specifically. On the traceability down the stack, we felt that each would be transmutted downward, which would give traceability implicitly.
Jane Curry: You ran into the proble we did - many of the artifacts are composite between viewpoints.
Ron Parker: It will be an ongoing problem - things already done may not fit neatly in a cell. THe synthesis is needed. How is the compartmentalization servicing us.
Steve Hufnagel: We did not find a place for structural specs.
Jane Curry: Is it an architectural artifact when you are considering interoperability?
Steve Hufnagel: Building a soa, the modules form the binding between the stack cells. If the is no place for structural artifacts, you need to state that. We took traditional artifacts, and tried to place them. Structural definitions did not seem to have a place - we dumped them into the computational viewpoint.
Ron Parker: For sunday - seperating the terms between soa artifacts, and the object you need to modularize. We are not attempting to create a framework, but to provide a means to conceptualize the places. We also talke about using the stack to help us to create service/contract templates. Are we reaching too far?
Jane Curry: Is it a granularity issue? There are conformance statements on the interface, as opposed to a complete service specification that you build as a software module. SOA world builds fully functional capability, we are looking at interoperability.
Steve Hufnagel: BF requires interface specification, et. al, ECCF does not, but the BF tables were helpful.
Cecil Lynch: At NCI we are seeing that you have to be cery specific definign the information viewpoitn having ECCF mhave any meaning. If you dont, you end up with mismatches in the service specification with what you anticipated in tracing. We have some work to do to specify the sequence of steps for relationships along the vertical as well as horizontal axis. Maybe another column that defines context between viewpoints. You have to be able to walk the context thru to the behaviour.
John Koisch: ECCF is about conformance and compliance, it is easy to get lost - there is the intention that the horizontal pieces hand together - you are building 3 things, not 12. There are arguements for use cases to be in enterprse as well as computational. We have use cases at various levels, that you can turn into wsdl. You have a cntrack, however loose, that sets the stage to refine, getting better, driving to interoperability. The first cut is barely to define one end poing.
Steve Hufnagel:The idea of a mature ECCF is that when you start you are placing puffs of smoke in the cells, the mature as you work on it. The end result, it needs to be simple for mere mortals to make user of. The document had esoteric definitions that were nit-picking. The BF was better grounded. If the ECCF was all we had, we would have been in trouble.
Ron Parker: How coherent are the definions between specs?
Steve Hufnagel:We defined it as an exchange architecture. Make simple and intuitive.
Jane Curry: That is useful - that is a different way of explaining the intention. The focus was not on modular design, but on what do you need to have in common to exchange information usefully - the interoperability elements.
Steve Hufnagel:I have been struggling with compliance and conformance in HITSP for years. Once we told people it was an exchange architecture, they knew it was a topology with nodes. We are building a real system on this at the VA as an executive summary exchange architecture.
Ron parker: Nice to know.
Steve Hufnagel:You dont want it to be shelfware. Made it central to understand the architecture. Then you can drill down.
Ron Parker: Interesting.
Steve Hufnagel:That brings in stucture - you have to do it some where.
John Koisch: Interface specifications?
Steve Hufnagel:You build a component that has an interface.
John Koisch: There is a bit of a sheel game here - the fact is you can create an interface specification that says anything you want - if you take the interface requirements you are defining system specification. As Cecil pointed out, if the persistance layers on both ends are not capturing a flavor of the datatypes, you will loose data integrety. We never went into system requirements. You cant tell the vendors how to develop -but if you offer a way to participate, they will join.
Steve Hufnagel: The counter arguement is any vendor will want to deal with it, so you have to accomadate.
John Koisch: There is a lot to be said for a reference implementation, but I dont see that happent with two vendors.
Ron Parker: Steve - who are the consumers - outside of the organization? Can you declare an enforce the business?
Steve Hufnagel: Yes it is described in the practical guide, within the DOD model. That is our governance model.
Ron Parker: So all falls under that model.
Steve Hufnagel:Yes, we showed that. You have an audit to the conformance statements at each review. John is working withing a model where you cant specify the governance.
Ron Parker: Thanks for the feedback. On our sunday meeting, the granualrity should be discussed. There will be need to develop coherence. It is difficult to apply witout the information model -they had to substitute their own. Thanks Steve.
Jane Curry: Was there any intent to create reusable?
Steve Hufnagel:Yes.
Jane Curry: In your analysis did you run into granularity problems between atomic and composite components.
Steve Hufnagel:Resuable's are capabilities. At each levelther is a question as to what is reusable. We had a request to fill out a form for an alpha project. We want approval - we filled out the form.
Ron Parker: I am interested in the degree of use of the SAIF artifacts, but what other?
Steve Hufnagel: EHR-S was the business criteria.
Jane Curry: I ran into the model as either a business or system capability. It has governance problems.
Steve Hufnagel:A capability may have one or more EHR-S functions.
Jane Curry: Capability may be around one or more boundaries.
Steve Hufnagel: I will be available on Sunday at Rio.
Ron Parker: Thanks for the documents and the discussion.
Jane Curry: We did not like it either, but had not applied.
Steve Hufnagel: In version 1 was the chart with strict traceability to columns.
Ron Parker: I will try to have the call thursday.
Other business and planning for next meeting
Next Thursdays call:
- Call to order
- Approval of Agenda
- approval of Minutes
- Agenda for Rio
- Peer Review update
- Alpha Projects update
- Review of action items
http://gforge.hl7.org/gf/project/saeaf/tracker/?action=TrackerItemBrowse&tracker_id=590
- Review of Wiki Pages
- Other business and planning for next meeting
- Agenda for Rio
- Adjournment
Adjournment
Meeting was adjourned at 7:00pm U. S. EDT Tony Julian 23:08, 6 May 2010 (UTC)
