2009-09-23 EA IP TSC WGM Minutes

TSC Enterprise Architecture Implementation Project (HL7 EA IP) Progress Update

Wednesday September 23, Q4 3:30-5 PM

• Hosted session for Sept 2009 WGM
  

back to EA_IP_Meeting_Agenda_and_Minutes
back to EA IP

Call to order 3:39 PM - Delay of game due to no AV support

File:2009Sep TSCEAIP attendance.pdf

• Marc : intro
• ArB has provided, not an enterprise architecture, but an architecture “framework”. We are gaining a progressively more solid set of items to describe it.
• Jump into some projects that would exercise the SAEAF.
  • EA IP Journey so far… see slide presentation
  • Alpha approach
  • Alpha Projects
  • Acknowledged that there is always more communication that can be done; however this has progressed at the pace with which we were ready to move forward.

(SA)EAF Pioneers (aka “Alpha” Projects)

• Don Jorgenson (Privacy, Access, and Security Services - PASS) –
  

Spent time today getting everyone on the same path. SAEAF alpha project has provided us with a template – viewpoints, MDA, moving “across and down in the stack”. How we move through the artifacts, how we might groups them for balloting the standards. Now looking at conformance points, traceability of elements – new concepts. Audit, access control, identity, and consent are the four points being elaborated to go for ballot in January. It’s an aggressive timeline.

• Dale Nelson – ITS. Project: The ITS Is Might Be Broken
  

Try to establish governance in the process of deciding if something in ITS is broken, is there a problem, whose problem is it, how do we make it better, how do we define what is better? Are there measurable success criteria? We don’t know the answers but want to try to formalize the process to find the answers.

• Patrick Loyd: OO – Composite Order.
  

How to define the artifacts we’re using, computation and platform specific viewpoints, what are the real outcome artifacts. Starting with Composite order, particularly lab as Composite Order has many departments. May 2010 likely a guess for balloting.

• Ron Parker: Infoway Blueprint 2015
  

Project will not produce messages directly. No work group to land artifacts into yet. Extending the Blueprint to provide support for healthcare in Canada. Healthcare service bus, put into the shared space. Using the SAEAF infrastructure to support e-referral patterns and other functions. Service patterns and orchestration are missing from their current SOA work. Their SAEAF scope as a Reference Enterprise Architecture to go from conceptual to platform independent and from business to computational with just a little engineering viewpoint (box within the box).

• Keith Boone: Structured Documents –
  

They don’t know a lot about SAEAF, pretty much just what’s on the slide. Discussions in Kyoto on what is in the boxes and what they have to do, what fits and what parts of it don’t fit. Working with Cecil on this, going forward and will be learning a lot quite rapidly.

• Pat vanDyke with EHR work group:
  

They have EHR-S FM and an interoperability model that runs parallel. How do we pull these together... We don’t have understanding of how they fit. How do these two relate? So far they are parallel. EHR WG will look at the combination of these two models going forward with EHR-S FM R2.

• Charlie Mead: projects under SAEAF –
  

Along with the work in the EHR WG and Steve Huffnagel and DOD on HITSP interoperability standards for EHR. NCI officially running caEHR under SAEAF, for full specification and reference implementation of EHR to support ambulatory oncology care. NCI’s vision that it is the first to integrate bedside to bench and back. Proteomics and genomics work, patients typically under protocols for care are advantages to this type of project. One common spec or several specs common to a framework – SAEAF. Will probably result in about 20 service specifications and will bring them back to HL7 for balloting.

Charlie also reports the development of a Specimen management service – was an RMIM and NCI will wrap a specification around it.

ArB update

Charlie on ArB. We’ve worked as long as we should on the SAEAF without practical feedback on it. Needs broader input at this point. The ArB currently understands the SAEAF is relatively stable, and future movement should be gradual. Starting to learn what artifacts populate the specification stack. HL7 side doesn’t have the computational and enterprise/business columns background. Behavioral Framework has semantics and capability that used to be in the Dynamic Model. Where do the artifacts go, how are they linked? Just having them up on a GForge site under version control is not enough. The artifacts have a semantic linkage; NCI will contribute a semantic wiki. Jane Curry working on Governance Framework ‘book’.

Ron adds they’ll be adding patterns for folks to post their stuff. Teams that build things are concerned about architectural composites. ArB will extract primitives from the alpha projects and show how work groups can produce them for other projects.

Thoughts from the TSC perspective.

Charlie McCay takes the floor. Recognize as an organizaion that over the 3, 4, 5 years that we needed a technical architecture, architectural framework - it’s taken a long time to get there. Board of Directors asks why can’t we see a worked example? That is one of the things we need to produce. We have, however, said the alpha projects are going to develop not just work examples, but with dedicated reciprocity and feedback with the ArB. Other committees doing other work don’t need to think about the SAEAF. ArB doesn’t have the bandwidth to work with all the committees on all projects. Alpha projects will build the scalable framework for organization-wide uptake. That is the answer to “what does this project mean to me”. Looking for the concrete examples to demonstrate benefits.
What will those benefits look like at 12 months, 24 months, 36 months out? Will be working out the rollout plans along the timelines. What will be done, how will projects change, what benefits will they get from that. TSC will be looking for clear visibility for the benefits to that rollout, governance to ensure it will be used. Would look to make it easier to develop stuff for our stakeholders and our users.

Charlie Mead adds: to help the alpha projects one of the most important elements to show you what you have to do. Just saw the first draft of the “SAEAF book” from the DITA platform as being built by a technical editor. We need to get the SAEAF book in the hands of the alpha projects.

Charlie McCay: any feedback from the floor?
Ann Wrights: is it the expectation that the alpha will be only in their bubble, or will there be a process of osmosis and how will that be managed? McCay answers that we don’t put up walls between anyone. Some of the stuff within the SAEAF project will “osmose” with ease. As we look at the scalable rollout, it may not be a step-change process, but the alpha projects proceeding alongside the scalable rollout to address how much terminology in SAEAF starts rolling into other work. Charlie Mead says we didn’t want to suddenly inflict something new on everybody. Picked projects with importance in breadth and depth, led by committees that said we want to do it. We hope that other committee members on committees running SAEAF projects see the value of it. McCay continues that the risks to publishing getting a bunch of new stuff and such will indeed be managed. Marc Koehn has been working on the implementation plan all along, and if you encounter or foresee any such problems, please communicate them to Marc so they can be collated and addressed. We really do want to try to make this a success.
Galen Mulrooney asks: if the alpha projects are going to determine what goes into those 12 buckets in the grid, is it up to certain committees as owners or stewards of the three integration paradigms e.g. MnM, Struct Docs, also to determine what those buckets will hold? I don’t want to define artifacts and find out that someone else has determined they won’t be used going forward. McCay responds that the alpha project process takes a rough cut of a specification include taking materials from various strands, including work between the custodian committees and ArB to define the foundational specifications the alpha projects run off of. We are evolving the framework and how the existing documents messaging services methodology documentation fit into that framework. Alpha projects won’t take over the definition from the custodian committees but will synthesize with it. Ron Parker adds that alpha software testing is rather raw. The project groups will do their best. They will expose what they’re doing and what works and what doesn’t. Not expecting totally consistent balloted artifacts coming out of the alpha projects. Will later begin to formalize the expression. Galen responds that it sounds like the custodial work groups need some formal relationship with the ArB along with the alpha projects.
Stephen Hufnagel asks will the ArB give guidance on how we represent these artifacts, UML or what ever? Charlie Mead says style guides have been developed and will soon be distributed. They will be candidate suggestions based on their own experience.
Woody asks about the implication of whether we were going to change everything; intent is not to reinvent the wheel but to continue to use the wheels we have.
Keith Boone asks to get links to the presentations from Sunday. Charlie Mead asked John Quinn the same question at lunch today. Membership needs to push the question, but education is a revenue stream for HL7 and there will be some reluctance. This would need to be separated out from the education stream. Woody adds that we have historically shared slides within the organization as long as they weren’t used for commercial development. He recommends take it to the Education committee.

Charlie McCay asks would such a session be useful in this slot in the upcoming WGM. He ‘hears’ some general nodding… (smile) Please remove the filters that automatically take the cochairs emails out of the inbox and watch for upcoming information on the progress of the alpha projects. We’ll get stuff out in the Technical Newsletter as well.