2009-12-01 EA IP Advisory Group Call Minutes

TSC EA IP Advisory Group

Tuesday, December 1, 2009 03:00 PM (US Eastern Time, GMT -5)
To participate, dial 770-657-9270 and enter pass code 124466#

The online meeting link is https://webmeeting.dimdim.com/portal/JoinForm.action?confKey=lynn_hl7

back to EA IP
back to EA IP Meeting Agenda and Minutes

Agenda

Apologies

• Marc Koehn (hopes to join at the half-hour)
• John Koisch
• Lloyd McKenzie (joining at the half-hour)
• Dale Nelson

Meeting Admin

Invited

At	Name	Affiliation	Email Address
x	Keith Boone	GE, CDA R3 project lead	Keith.Boone@GE.com
	John S. Carter	Apelon	jcarter@apelon.com
	Russ Hamm	Apelon; CTS2 Alpha project lead	rhamm@apelon.com
x	Steve Hufnagel	US DOD MHS	Stephen.Hufnagel.ctr@tma.osd.mil
x	Don Jorgenson	Inpriva; SOA PASS Alpha project lead	djorgenson@inpriva.com
	Marc Koehn	HL7 EA IP PM	marc.koehn@gpinformatics.com
	John Koisch	Guidewire Architecture, caEHR Project Lead, EHR-S FM Arb Liaison	jkoisch@guidewirearchitecture.com
	Austin Kreisler	SAIC; OO Composite Order project lead	austin.j.kreisler@saic.com
x	Lynn Laakso (scribe)	HL7 HQ	lynn@hl7.org
x	Patrick Loyd	OO Composite Order ArB Liaison	patrick.loyd@gpinformatics.com
x	Cecil Lynch	OntoReason; CTS2 project ArB liaison	clynch@ontoreason.com
x	Lloyd McKenzie		lloyd@lmckenzie.com
	John Moehrke	GE	John.Moehrke@med.ge.com
	Galen Mulrooney	US VA	Galen.Mulrooney@va.gov
	Dale Nelson	ITS alpha project, ArB liaison	aleday.elsonnay@gmail.com
x	Nancy Orvis	US DOD MHS	nancy.orvis@tma.osd.mil
	Ron Parker	CHI; Infoway Blueprint alpha project lead, ArB liaison	rparker@infoway-inforoute.ca
x	Modibo Samake'		modibo.samake@xwave.com
	Abdul-Malik Shakir	Shakir Consulting; PASS alpha project ArB liaision	AbdulMalik@Shakirconsulting.com
x	Igor Sirkovich		Igor Sirkovich@ontario.ca
x	Ed Tripp	EST	Edward.tripp@estripp.com
x	Patricia Van Dyke	Delta Dental; EHR-S FM project lead	vandykp@odscompanies.com

1. Accept Agenda –
2. Discussion Topics:
   • SAEAF Alpha project Leads and ArB liaisons invited to the EA IP Advisory group conference call to give an update on their charters, progress on artifacts, barriers to success, lessons learned, and dependencies.
   • Alpha progress reports
     • update on their charters
     • Surface barriers to success, or share learning from making real progress.
     • Identify dependencies to move the implementation process forward.
     • How did you document what you didn’t like, gaps identified need to be notified – so the SAEAF can be refined and moved forward.
   • PASS: Architecture framework and access control for PASS first to get out the door, to ballot. Don describes the learning process of RM-ODP and the MDA underlying the SAEAF. Top row found to be mostly RM-ODP, next two rows are OMG-MDA terminology.
     • There was a question on the whole RM-ODP viewpoints, not adequately represented by the MDA, you can represent the contents of the RM-ODP cells. Not really a merging.
   • lessons learned, SAEAF is poorly documented. Don notes that they’ve spent a lot of time on identifying what is intended. It was mentioned that it differs if you talk to Charlie versus John.
   • Nancy notes it is difficult to describe what its purpose and intent is, in a simple paragraph. She cannot bring up at a top level management meeting what this is, and does. It is not written to describe at that level and be able to tell them why this is important. It has to be put in business terms. Steve notes if you ask people to do something different from what they are already doing, you have to show them the value.
   • Keith offers that SAEAF is trying to get standards developers to answer 12 key questions about what it is that a standard is intended to specify. What are the 12 key questions? The boxes in the matrix – how does the standard address each level of detail in each context. Helps to understand who the audience is for the specification, understand how we’re writing it. Along the lines of EHR functional model, what’s the business function here, what kinds of information needs to be moved around, focusing on key individuals (audiences) to define the scope of what we’re creating. Viewpoints from business, analyst, informaticist, engineer/implementer. Nancy asks what the informaticist viewpoint is? Keith broke it down by audiences.

     The pictures came from http://motorcycleguy.blogspot.com/2009/09/demystifying-saeafmaybe.html -- Keith

   • Cecil notes that the metamodel is trying to build consistency, to compartmentalize the elements of application development. Touchpoints are interlinked to each other so that you cannot miss a piece and complete a consistent model with the next piece. The artifact that you produce can be measured by the ECCF. What we’re missing is the defined conformance criteria for each of these boxes. That is the purpose of the alpha projects to define the conformance and compliance of each box in the viewpoints.
   • Keith brings up the 12 boxes, with the viewpoints and specification levels. The diagram talks about different kinds of artifacts that fit in each box. XML Schema is platform specific information viewpoint level. DAM at conceptual level. Keith then showed the different target audiences that were identified for each box, with product managers at the conceptual level enterprise viewpoint, and information modelers at the Platform Specific level Healthcare Information viewpoint; business process modeler takes the model and creates computational level. HL7 V3 messages on lab orders/results you can fill out nearly every square; but just a DAM you may only fill in the upper left quadrant. But we don’t know what all these documents look like – what does a Business Governance look like (Platform Independent/ Enterprise-Business Viewpoint) – a DRSA or BPM diagram. Service collaboration is more in the computational viewpoint.
   • Don notes that for Access Control on the service side the SFM is in the computational to partition behavior into conformance testable behavior. The behavioral model feeds the computation viewpoint from the information viewpoint, and allows it to be distributed. Moving down the stack in the information viewpoint, you become more elaborate and detailed. At platform independent level you might make your first binding to the RIM. On the computational viewpoint moving down the stack determine when to bind to WS Services. Engineering viewpoint scope is causing confusion right now. Technology view not shown here, where that line is on picking equipment between engineering viewpoint and technology, or between computational and engineering viewpoint, guidance on defining scope.
   • Ed notes Nancy’s question, going through this process, what is the business benefit – how do we describe the value of the effort? What is the elevator pitch? Services aware framework that allows all different kinds of developers in HIT to find …
   • Don notes Start at high level business requirements, and then next step maps requirements to information model and policies to be realized. Then to see how to deploy across the organization using SOA. Then you can start to push down the stack.
   • Nancy asks about the table “Topic Specification” – not a good nomenclature, Call it a domain? There should be a “purpose or outcome expected” by looking at this thing. The purpose of this grid is to allow you to do ‘this’, and take any viewpoint on finishing a standard from HL7. A graphic display should stand on its own and not require five pages of explanation before and after. Ed notes EHR-S FM being developed under this. How is EHR-S FM R2 going to be better than Release 1 because of the use of this architecture? Nancy says because we considered all these viewpoints. Every project or standard should have to answer those 12 questions, even if the answer is “not applicable”. These 12 questions are the building blocks of HL7 standards. Then you have a context (unlike DICOM) of how do these work together – that’s what a framework does, is specify how these work together.
   • What do you get out of this? Do we need some negative examples? Cecil describes the guy at the top of the organization who knows the big plan needs to know what the business requirements at the conceptual level are. Can’t just launch into building a data warehouse, you have to know what needs to go into it. From upper left to lower right you’re not refactoring things each time, that each move down and right will come up with the same understanding of the problem at hand. The SAEAF gives the framework to think about issues before you start building.
   • Keith notes, we are looking at SAEAF on a standard-by-standard basis to make them play better together. Perhaps we need to look at the HL7 Functional Model in the upper left hand corner and take it to the information and engineering viewpoint and think of it in terms of HL7 V3 messaging, or documents, of V2 messaging in platform-specific model, and see how all that stuff fits together? That may be an ArB function to fit into all this, to look at clinical decision support and how do we integrate this using GELLO, and Arden, and CDA R2, and HL7 V3 Messages, and HL7 V2 messages? We can’t because we measure in inches here and centimeters over there and things don’t play well together. Arb should look at how do eht different pieces fit together and we can see what boxes we need to be worried about and what are boxes elsewhere in HL7 that I would be like to be able to connect to with my Lego blocks.
   • Ed says SAEAF provides a framework for specifying how HL7 products integrate and function together. It does so establishing conformance and compliance criteria for each of the viewpoints (shows you how and where to establish conformance). Building a DAM before building other things, allows Pharmacy to ‘own’ the pharmacy data model. Then down the informational viewpoint you can determine if you are a conformant subset of the pharmacy data set. If you have nonconformant elements it can be traced back.
   • Don says here’s a service, something that was invoked, and here’s the behavior we can expect. That’s something you can measure. If I take it out and put something behind it, it will still do the same thing? Behavior specified at the computational level. Perhaps differ the service contract from the service. Need to behavioral framework as well as computational framework. Like the dynamic model (Patrick asks?). Cecil says BF is more about the business about what you’re doing but goes the next step that says what you’re passing, an XML data blob or java bean. Must clarify responsibilities when you receive it as well. Think of each individual piece of that and specify how you measure each parameter around that box, and check it off. Need more detail than just “I’m exposing a service”. Don clarifies, when we create a service capability that is ‘request access control decision’, specifying input to identify requester, provide information to the service, and define behavior; that based upon these criteria you return, permit, or deny. For a given set of input, submitted in that way, the behavior you expect back is a decision.
   • Keith updates: SAEAF provides a framework for specifying how HL7 products integrate and function from different viewpoints and levels of abstraction. When HL7 products agree upon common viewpoint and abstraction details, they can be used together.
     • Don adds we need traceability and conformance. Cecil says that traceability is how you modify and test conformance, your feedback loop. Traceability is horizontal and vertical and bidirectional, through the stack. Intent is to produce consistency.
   • Keith has to leave for a Structured Docs call and notes that he and Cecil will begin working on a charter.
   • Cecil notes that CTS2, NCI has an RFP out for a reference implementation. In the requirements are conformance to ECCF and SAEAF. Next iteration they may be ready to have some claim to conformance and see how the artifact assessment would be updated. From the ArB perspective, has seen our understanding of what we need to do is getting better as the alpha projects move along and we see what our requirements are, to clarify what we’re trying to get out of this process. ArB folks are getting more comfortable with what needs to be done. The documentation is a separate process, identifying gaps to be addressed. Technical writing process forces a review and refocus to ensure we get out of this what is intended. Doing concept maps and OWL properties has been very helpful.
   • Communication
     • Distribution list for EA IP and Alpha project leads and liaisons has been set up - use mailto:saeaf-alpha@lists.hl7.org.