20090111 arb orlando minutes

Architecture Board

January 11, 2009

Attendees

Name	Present	With	Affiliation	E-main address
Curry, Jane	Yes	ArB	Health Information Strategies	janecurry@healthinfostrategies.com
Grieve, Grahame	Yes	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
Lynch, Cecil	Yes	ArB	ontoreason LLC	clynch@ontoreason.com
Mead, Charlie	Yes	ArB	Booz Allen Hamilton	charlie.mead@booz.com
Orvis, Nancy	?	ArB	DOD	nancy.orvis@tma.osd.mil
Parker, Ron	Yes	ArB	CA Infoway	rparker@eastlink.ca
Quinn, John	Yes	ArB	Health Level Seven, Inc.	jquinn@HL7.org
Shakir, Abdul-Malik	?	ArB	Shakir Consulting	ShakirConsulting@cs.com
Yongjian, Bao	?	ArB	GE Healthcare	yongjian.bao@med.ge.com
Maclsee, Peter	Yes	Guest	?	peter.macisaa@eds.com
Mukooyo, Eddie	Yes	Guest	?	eddie.mukooyo@healthgo.ug
van der Zel, Michael	Yes	Guest	University Hospital Groningen, The Netherlands	m.van.der.zel@ict.umcg.nl

Call to order

The meeting was called to order at 8:10am by chair John Koish with Tony Julian as scribe.

Agenda approval

MMS to approve the agenda below Grahame/Cecil Vote:(5-0-0)

1. Call to order
2. Approval of Agenda for quarter
3. Approval of Minutes of previous meetings
   1. December 18,2008
4. Approval of Agenda for Working Group Meeting
5. Review of TSC decisions
6. Internal Governance for HL7
   1. specifically how ArB is expected to interact with other groups (like Harmonization)
   2. other groups (OMG) per AMS's work on MOUs
   3. Should we pursue inviting RIMBAA to ArB session on Thursday, or informal intersections through the week
   4. Should the ArB provide mentoring for groups? Who are the SOA Mentors?
   5. Question of where the SOA work should land, based on the temperate response from the SOA list and the oter co-chairs
7. Review of the Services Items for HL7 SOA Working Group, SAEAF Impacts
8. Adjournment

Approval of minutes

MMS Cecil/Jane to approve the Minutes of the December 18, 2008 meeting. (5-0-0)

Review of TSC decisions

1. Internal Governance for HL7

• The presentation was taken more literally than was expected - as a top-down organization instead of a conceptual view of the workings of the organization. Charlie McCay suggested that we re-visit the project scope statement - added to agenda for Sunday Q2.
• Slide with potential Recommendations was not well received - due to misunderstanding -specially the line about moving TSSD to ArB.

1. specifically how ArB is expected to interact with other groups (like Harmonization)

Cecil had specific recommendations: Decisions of the ArB cross multiple domains within HL7 as well as many Work Groups within HL7, and have major impacts on everything. Part of the thinking, is that for any of this to work, all of it has to work. Without us having some concrete implementation, ArB needs to be informed of decisions at Harmonization - to the extent that if it moves to dynamic we need to have some communication.

• Charlie Mead: We need to have a representative at Harmonization. The dialog will have to go two ways so that we can impact harmonization.
• Jane Curry: The voting structure works that VOCAB and MnM had stronger votes than other committees. Maybe ArB needs to have a voting seat, and possible a veto.
• Charlie Mead: If ArB is to do what John Quinn wants, ArB must have a vote. E.G. Somebody is proposing to do something that has an impact beyond the scope, ArB needs to do something.
• John Koisch: RIMBAA intended Hl7 RIM models to do things beyond messages. I would think it would impact the model.
• Mead Walker: The ArB will be effective if it works by laying out principles and general statements, working through Working Group's and TSC. If someone wants to add an artifact we are not well worked out how to handle.
• John Koisch: We started looking at impact of the dynamic model on the MIF.
• Grahame Grieve: We would go to harmonization as a Working Group to discuss. If we are on track, and making sense, we do not need an authoritative vote.
• Cecil Lynch: There are things at harmonization that we need to understand, being at the table thinking about the needs of ArB - attendance is enough. There may be instances that come up over time that need decision.
• Mead Walker: Are there any ArB members that regularly attend Harmonization?
• Jane Curry: I used to.
• Cecil Lynch: I often do.
• John Koisch: Mead is our 'official' representative.
• John Koisch: we need funding to make sure that one of the co-chairs attend.
• John Koisch: Are there any other groups we need to inject ourselves into?
• Jane Curry: There is group work during Harmonization beyond the Harmonization itself. We need concentrated analysis by veterans of their committees. Introduction of SAEAF topics during harmonization are needed. We can opportunistically take advantage of the Harmonization to provide information.

1. other groups (OMG) per AMS's work on MOUs

• AMS is not here, so we will punt.
• Cecil Lynch: We need to discuss with RIMBAA.

1. Should we pursue inviting RIMBAA to ArB session on Thursday, or informal intersections through the week

• John Koisch: There is a RIMBA tooling convocation Tuesday Q6
• Jane Curry: and a Tooling WG presentation of OHT tooling work-in-progress or other HL7 related tools readily available also in Q6- two different meetings at the same time.
• Cecil Lynch: The inaugural meeting was demonstrations of what people were doing. What I saw was that they have to plan beyond the persistence in the database. It allows us to review what real-world implementations are being done?
• Charlie Mead: Aren’t they messaging instead of services.
• Cecil Lynch: Some are doing services.
• John Koisch: Their web site shows that they have scope beyond messages.
• Cecil Lynch: The work of GELLO has an impact on RIMBAA.
• John Koisch: Are you (Cecil) going to be there?
• Cecil Lynch: Yes
• Michael van der Zel: I heard about database - you need to do services as well as messages and documents -all three.
• Charlie Mead: Given that the biggest delta is in the Behavioral Framework, RIMBAA is having to create behaviors. If they are doing this in the context of V3 messages, we are on paths that are not totally aligned?
• John Koisch: I spent a lot of time going through the materials: They are working on content models instead of messaging - using the engineering viewpoint of ArB.
• John Koisch: The other upshots of ArB - Invite RIMBAA to thursday Q3 to discuss. We can have focused discussion this week. Cecil and I will offer to help.
• Micheal Van Der Zel: We need SAEAF to do this well.

1. Question of where the SOA work should land, based on the temperate response from the SOA list and the other co-chairs
2. Should the ArB provide mentoring for groups? Who are the SOA Mentors?

• John Koisch: I received a temperate response. Galen responded that the remarks to JK would be included in SOA Tuesday Q1. The SOA co-chairs are discussing informal sessions. I had a long conversation with Charlie McCay : The ArB is responsible for the infrastructure to implement the SAEAF. If the SOA workgroup is not going to do it, the ArB must do so. If the SOA Working Group does not want to do it, we take it to the Steering Division.

WE, HL7 are moving away from Workgroups doing everything, rather cross-functional teams. ArB is responsible for delivery of this stuff, e.g. contracts, syntax of healthcare, the way the Behavioral Framework impacts is on us.

• John Koisch: Should the ArB provide mentoring for groups?

• Don Jorgenson: Where we fit in the project, par of the SOA response is because we are project oriented. John you were part of the structure of SOA to do things this way.
• Jane Curry: HSSP was the collaborative program with OMG, and that various projects were structured under HSSP. Is the SOA/HSSP doing everything as a project?
• Don Jorgenson: We are not sure that OMG makes a follow-up to the PASS work? Is there an alternative path?
• Charlie Mead: I did a project in SOA Working Group in 2006. The framework was very clear about what HL7 did. Once the HL7 material was balloted, it was handed off to OMG, or someone. Is that a correct statement?
• Don Jorgenson: It does not have to be OMG
• Charlie Mead: There was no path beyond HSSP. What SAEAF brings to the table is HL7 bringing full responsibility beyond HSSP. HL7 is not done just because it is handed off.
• Mead Walker: We should discuss our opinions with the SOA Working Group.
• John Koisch: No, there was not reason for us to be authoritative.
• Charlie Mead: Correct.
• John Koisch: HSSP and ArB both support analysis - every HSSP artifact can be included in the Behavioral Framework. We created a behavioral framework that SOA did not well received. Our behavioral framework looks like the services one. I sent a e-mail to SOA about the things we need to discuss, and there was little response. I don’t care who does the work, it just needs to be done.
• Charlie Mead: The SOA Working Group is focused on projects framed by the HSSP, so they don’t have the bandwidth to do the infrastructure stuff.
• Don Jorgenson: It makes sensed to have a framework, and ArB makes sense as a framework for projects to go. Even when you were working on it in SOA there was little bandwidth.
• John Koisch: The SOA Working Group is engaged in project facilitation, and is working within and outside of HL7 to get services working.
• Don Jorgenson: There is a lot out there.
• John Koisch: It has been suggested, SOA is doing project facilitation, Charlie McCay say we own it.
• Mead Walker: ARB will say that this needs to be done, a project team should be assembled, and the work should go forward.
• John Koisch: The HL7 SOA workgroup is committed to project facilitation. Tuesday Q1 will be a call for action.
• Jane Curry: the appropriate channel is the Foundation Working Group.

• Don Jorgenson: My perspective is one layer down: Knowing that JK is involved in Arb work, the next logical step is for us to get back to it.
• John Koisch: This body has been really trying to take a kid glove approach - does not want to own the work. There was the perception that SOA Working Group should have first right of refusal. Nobody wants to step on anybody's toes.
• Don Jorgenson: We have had good participation from implementers, domain specialists. Some don’t want to work at a UML model, and others want to look at implementation that is a step below the modeling.
• John Koisch: My sense is that in the past, a lot of this stuff helps PASS a lot, the challenges are that you don’t have a rigorous notion of a healthcare contract. The SAEAF and behavioral framework give you the foundation you need.
• Don Jorgenson: What is the next step? Who do we go to? We need to understand what you need. What you are working on now is difficult.
• John Koisch: The next problematic thing is that the HSSP thing provides for service specification at a subset of what we have defined. There need to be some re-factoring, and some specification work done by PASS and others in light of the Behavioral Framework, including a set of logical models in the HL7 space. If they make it to OMG is beyond our scope.
• Don Jorgenson: DO you see the Functional model as a work output?
• Charlie Mead: It is a deliverable that can be executed internally. I heard that the HSSP says that when you get to this point you are done, while the SAEAF says you need to go further.
• Grahame Grieve: It is up to HSSP. What we said is that the HSSP and others are separated. It is not important to us what HSSP chooses.
• Charlie Mead: We made the assumption that SOA Working Group would provide the infrastructure. They said no, they are doing HSSP. Therefore the Arb is responsible.
• John Koisch: HSSP can do what the want?
• Charlie Mead: No, SOA Working Group is stopping at HSSP.
• John Koisch: It is not a full specification.
• Charlie Mead: No, you don’t have to go beyond the requirements.
• Don Jorgenson: The HL7 SOA group is a partition, before SOA was relevant, in relation with OMG. HSSP makes sense, SOA can have another agenda.
• Charlie Mead: All of the SOA work is HSSP.
• Grahame Grieve: The problem is that the Working Group suffered personnel changes, not a policy change, but rather a loss of energy.
• John Koisch: The last point that needs to be resolved is brought up by CL: The OMG is misusing the HL7 artifacts in their specification. To what extent is HL7 endorsing the OMG output of the HSSP? In my experience the specifications that OMG puts out suffer from lack of Healthcare. Is there something we need to be proactive about?
• Cecil Lynch: One of our kinds of governance is relationships to other bodies. OMG impacts us using there standards for decision support, that ignores the healthcare Datatypes: You cant find the ODM specification and generate our UML artifacts. We need to discuss moving OMG forward beyond financial to healthcare requirements.
• John Koisch: OMG is willing to make HL7 a voting member for healthcare standards.
• Cecil Lynch: More complex: OMG has relationships with W3C. For us to get our representation in we have a problem.
• John Koisch: From the ArB advising TSC? Is it appropriate that this takes several years? When the DSTU comes back and is not in alignment with SAEAF and BF what should we say?
• Charlie Mead: We are responsible for architectural integrity.
• Mead Walker: If people in OMG have things that HL7 should do differently, we should tell them to get their representatives to raise the issues. The HL7 representative should work through OMG to do it right. The Nominated rep may not be able to do so. We are members, and have the right to comment on ballots, the Working Group has to deal with it. If the Working Group says it is not related just because it conflicts with your SAEAF, the TSC will have to get involved.
• John Koisch: What about timing?
• Mead Walker: It is not reasonable to make them happen more quickly.
• Cecil Lynch: Meads approach is correct. We need to do an evaluation of where those touch points are, and have the proactively represented to OMG.
• Jane Curry: This data type one has been around for a while. It is one of the reasons why the V2 Datatypes are preferred. We are talking about an industry revolution to recognize more complex data structures.
• Cecil Lynch: We have strength to go back and approach since we are moving to the ISO Datatypes. For us to move forward, we must have our Datatypes represented in OMG artifacts.
• Jane Curry: we must develop a communication plan to reach out to others to bring them in alignment.
• John Koisch: ArB?
• Jane Curry: We must discover the gaps.
• Charlie Mead: There is a collective ArB responsibility: John Quinn would say that ArB should enforce architectural integrity. How we do it, we don’t understand yet. Cecil was passionate about those things going to ballot that don’t have architectural integrity. Those things are beyond Major Negative - it is a global veto.
• Jane Curry: we must distribute knowledge, not at the end point.
• John Koisch: We recognize that the framework looks like this , but HSSP can cut it off early.
• Jane Curry: if someone has an informational model that is RIM derived without correct alignment with Datatypes, it must be fixed.
• Grahame Grieve: Ballot quality
• Cecil Lynch: we have CMETS that don’t meet integrity.
• Charlie Mead: We have an existing ballot quality.
• Jane Curry: Yes, ballot quality
• Charlie Mead: Knowing that there is a specific issue with OMG, Datatypes, should we triangulate on OMG with W3C about the data type specification.
• Cecil Lynch: Yes, the work from UML to OWL and back
• Charlie Mead: Is this correct alignment?
• Cecil Lynch: Since they are co-dependent on the specification, we need to raise the issue.
• Charlie Mead: They are asking for a relationship.
• Grahame Grieve: Can I be on that call?
• Charlie Mead: Yes
• Grahame Grieve: Not Can I be, rather do you want me to?
• Don Jorgenson: IF the ArB defines the framework we need a definition of architectural integrity..
• Charlie Mead: Yes, the SAEAF talks to that
• Don Jorgenson: I went to my first OMG - they have a level of detail we dont , their 'arb' enforces their Architectural integrity.
• John Koisch: There is a notion that HL7 does not have the provision for that level of rigor.
• Don Jorgenson: SAEAF and the ArB should make that question irrelevant.

Break at 10:30

• Meeting Schedule
  • John Koisch: reviewed the Working Group meeting schedule
• Charlie Mead: presented SAEAF to a NHS Group in London, and they were very receptive.
• Ron Parker: No one has provided for them the business architecture
• Charlie Mead: They were missing the behavioral framework.
• Review of touch points

Should we do a project about the touch points?

• Jane Curry: Related to ballot quality. What aspects of artifacts should be valid for the architectural integrity, e.g. appropriate use of Datatypes
• Grahame Grieve: measurable conformance points?
• John Koisch: Assertion against other organizations
• Jane Curry: which groups do we interact with on architectural questions?
• John Koisch: Intersections with groups in and out of HL7. What are the characteristics of the intersections? John will need to prioritize.
• Jane Curry: Both internal and external
• John Koisch: Volunteers?
• Jane Curry: Yes
• John Koisch: who else
• Charlie Mead: Part of external touch points, John, Ed, and Chuck
• John Koisch: We need to review the MOU's
• JQ anything really technical ends up on my desk.
• John Koisch: I don’t think this is a huge effort that does not need formalizing.
• Cecil Lynch: I am overloaded
• John Koisch: A draft
• Jane Curry: it won’t take much time
• Cecil Lynch: I will help
• Mead Walker: I will help
• Ron Parker: I will be interested with the ISO joint working group
• Mead Walker: this effort is to identify the places where we care. Some will be places inside HL7, some outside.
• Ron Parker: The Copenhagen meeting is a place to sell the SAEAF. The internationals are finding a problem with vendor uptake. I don’t mean infostructure, rather the applications that connect to the infostructure.
• John Koisch: can you review
• Ron Parker: Yes

John Koisch, Cecil Lynch, Mead Walker, and Ron Parker will review.

• • Ballot Quality
  • Architectural Rollout

Review of SAEAF

John Koisch presented the SAEAF and the Behavioral Framework.]

• John Koisch: we hoped for a project between ARB, OO, SOA, and InM. Another co-working group reviewed the BF over the holidays. Harmonization defined the need to serialize these, and get them into the MIF.
• John Koisch: it has become apparent that contracts are an integral part of the model.
• John: For contracts to work, the bus has to proxy for you (serve multiple roles) between the Commissioning agent and the Responsible Agent.
• Cecil Lynch: There will be interactions between role types, even before it gets to the agents.
• John Koisch: Can we take this off line?
• Charlie Mead: It seems to me that I agree with Grahame that we have a historical problem that creates an explosion. At the architectural are we missing the choreography? Do we need to take on a role?
• John Koisch: If you look at standards that define behavior, this aligns. This is geared toward HL7 - to define a collaboration and a standards organization. You need to be able to specify your behavior loosely coupled to capabilities. Is that true? I don’t know, but without that we cannot function. The behavior specification is the document for the service. A service specification should not specify behavior - otherwise re-use may be a problem.
• John Koisch: HL7 needs to loosely couple so things can get done.
• Grahame Grieve: we need to have a discussion about the bus's role.
• John Koisch: we did a slight-of-hand by adopting service principles: Services aware means that you don’t care what happens on the bus - the bus needs to take on a role. There may be different technology bindings on the legs of the bus.
• Grahame Grieve: The things the bus does may be semantically meaningful.
• John Koisch: It comes down to the granularity.(not satisfying, and not nice). If you can specify the agent(s), you can determine the semantic interoperability.
• Ron Parker: I have a case where there are constraints on the bus, so the bus owner needs to know how to meet the standard.
• Grahame Grieve: In Messaging, Interface engines often do broadcast, and we have not handled the single sending to multiple receivers with one rejection. We may have to fiddle.
• John Koisch: We have discussed layers of services, from focal classes to process classes. At the NCI all of the externally available 'interface' from the bus must be described fully.
• Grahame Grieve: we may need to extend the model to describe the man-in-the-middle behavior.
• John Koisch: that is why you cannot talk about contracts except at an instance.
• Grahame Grieve: late binding
• John Koisch: There are nested contracts.
• Jane Curry: I am curious about trigger types - there are multiples e.g. data state, time of day, environmental
• John Koisch: when you apply events to this, we almost got rid of them. We need to separate them out.
• Jane Curry: it could show up in pre-conditions
• John Koisch: trigger types are rigorously role or collaboration changes. I am uncomfortable with syntactically defining something as a trigger type.
• Cecil Lynch: my points have been brought up - I guess I feel that very little should be concrete, most should be dynamically generated. The information should be harvested, but the user must provide capabilities.
• John Koisch: This is a wannabe instance diagram for a collaboration.
• Cecil Lynch: One of the tracks we fall into is profiles, when we should not be doing them as all.
• Mead Walker: we have people who think that is what they want.
• Cecil Lynch: what you expose is a collection of all behaviors: the system chooses.
• John Koisch: The notion of profiling is going from concept diagrams to the Service Role Specification Instance.
• Michael van der Zel: What do we do about caching? How long?
• Jane Curry: It is in the bus behavior
• Charlie Mead: Semantically important behavior for the intermediary - which can alter the semantics of the contract. or may require additional semantics.
• John Koisch: In the short term everything will be hard-wired. In the future we may do better. You need enough information to cope with the current infrastructure.
• Ron Parker: don’t loose the theme of the evolution one extreme is extremely fine grained, the other is extremely coarse grained. It will help with adoption patterns. If we could pick an example and type this
• John Koisch: Looks like Grahame and I need to work on it.
• Ron Parker: Then I can wrap my head around it.
• Charlie Mead: so fine grained that this does not apply?
• Ron Parker: no, people inappropriately try to wrap their business rules in the services
• Charlie Mead: if this cannot be applied to the messaging environment
• Ron Parker: I misspoke - people are specifying the business in the framework
• John Koisch: Don’t loose sight of that this is geared toward a standards body creating specifications. We are fairly close to being able to describe the bus and the consequences. Especially where we have a responsible party taking on a commissioning role
• Cecil Lynch: so we have two models

1. 1. Business lines of HL7
   2. here is how the services would behave in the wild?

• John Koisch:: Second is a subset
• Charlie Mead:: a superset?
• Jane Curry:: How would a project team to the alignment - they would have to create the whole set. I think we are going to have to provide education material on how to use the specification - they have to think through their business cases and how to apply.
• John Koisch:: we had an interesting example of that a the NCI - we created service specifications, and we deployed them, but when we went to another group the project was a success, but implementation guides are good.
• Jane Curry:: Even if we only expand on the picture, and stand in the position of a person who has to make them in their environment.
• Ron Parker:: We have to do that at our level.
• John Koisch:: 2-6 rule with no specifications, there are six phone calls, two if their are good specifications.

Adjournment

The meeting was adjourned at 12:39 U.S. Eastern Tony 17:40, 11 January 2009 (UTC)