This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

August 18, 2009 Out-Of-Cycle Minutes

From HL7Wiki
Jump to navigation Jump to search

Proposed Agenda

Tuesday

Agenda

  • Q1 EA Rollout Review - inventory of projects, expectations, POCs,
  • Q2 EA Rollout Review - inventory of artifacts (existing and gaps)
  • Q3 HDF Review
  • Q4 EA Rollout Review - Schedule for WGM to include all EA Rollout Projects, coverage, etc

Wednesday

Agenda

  • Q1 - EA Rollout Review
    • PASS Project Review
    • ArB Facilitators, ArB Capability Facilitators
  • Q2 - Behavioral Framework - Update, Project Review, Contracts, Artifacts, Primitives, Composites
  • Q3 - Primitives, Composites, and Governance
    • DAMs as normative versus Informative Content Models
  • Q4 - Primitives, Composites, and Governance, Celebrity Deathmatch

Thursday

Agenda

  • Q1 - TSC request for " ArB provide a policy statement RE domain analysis models, their context within SAEAF, whether it “makes sense” for a DAM to be published as a normative standard, and if so, in what contexts."
  • Q2 - Review of tasks, due outs, assignments

Minutes

ARB Notes 2009-08-18

Agenda for the meeting

  • John Quinn Update
    • TSC/ArB
    • “SAEAF Book” contract
  • SAEAF Update
    • Hitchhikers Guide
    • HDF
    • HSSP stuff -> Architecture
    • SAEAF & OHT
    • SAEAF & National Programs
  • EA Rollout
    • Inventory of Projects
  • Wrapup & Assignments
  • TSC/ArB update - A recent agenda item at the TSC was a proposed GOM change to revise the ArB’s position under the TSC. The TSC has no issue with the current relationship and has communicated that to the Executive Committee which has requested that the GOM change proposal not go forward.
  • SAEAF Book Contract - an open process to acquire resources to draft the “SAEAF Book” has completed and a successful technical editor has been contracted. A first draft with at least the SAEAF Introduction is expected by the September WG Meeting and is intended to cover the full topics eventually, including incorporating the portions of HDF we wish to include. Also the topic on compatibility as discussed with the Implementation and Conformance WG. Here is the e-mail from Lynn re the TSC notes on the topic.
  • The SAEAF book chapters are:
  1. Introduction
  2. Behavioral Framework BF (has part of Core Principles)
  3. Information Framework (suggested name) has part of Core Principles
  4. ECCF includes Refinement and Localization
  5. Governance (GF)
  6. Implementation Guide (IG) includes HDF, Facilitator’s Guide and Publisher’s Handbook
  7. Examples and lessons learned
  • Categories of foundational documents
    • Technical (specification):
    • RIM
    • Structural Vocabulary,
    • Data Types,
    • How these three relate: core principles
    • Refinement and localization
  • Process:
    • HDF
    • Facilitators’ Guide
    • Publisher’s Handbook
  • Support:
    • V3 Guide
  • Discussion Points:
    • What happens to the documents and how do they get approved going forward. Refinement/localization is dependent on RIM, Core Principles. If we have problems maintaining balloting of those as separate documents… we’ll have similar problems with SAEAF book.
    • Publishing format of SAEAF not to follow the handbook. Approval and endorsement process do not have closure yet. This discussion is not about publishing, just approval process.
    • SAEAF is framework for developing EA but there are foundational documents that are not defined in SAEAF.
    • If EA is combination of Business and Technical Architecture, then GOM is part of the book. SAEAF is a framework, not the things that are generated by the framework.
    • Woody says BF and IF are part of core principles.
  • So the EA contains the primitives from engineering -
    • RIM
    • Structural Vocabulary
    • ITS
    • Data Types
    • CDA
    • There is another category then, with manufacturing stuff (composites) or real products
      • CMET
  • Hitchhikers Guide from SOA has draft documents - we are to review documents and discuss tomorrow.
  • HSSP Practitioners Guide & Reference Architecture is also being held as an HL7 authoritative document.
    • It is a governance issue about who can claim to be HL7 an authority. The current state is that, although the ArB reviewed the original draft and provided comments, no revision has come back to the ArB to continue the review.
    • Charlie will remind the TSC that their role is governance and this is a case where we need to clarify what group can claim to have the authority to speak for HL7 on what is the recommended strategy and artifacts for using services in healthcare.
    • There is an outstanding action item for the TSC to produce a RASCI chart to clarify the roles of various Working Groups on producing definitive specifications on different topics, not the least of which is services. Charlie will remind the TSC.
  • Charlie updated the ArB on what the relationship is between the ArB and OHT - there is an OHT Architecture Project that is currently approved and has been working on producing an OHT Tools Architecture. There is now a commitment by a core group of national programs to adopt the SAEAF approach to managing tooling architectures with governance and there will be a “reorganization” of OHT to emphasize this, including the necessary funding to resource OHT accordingly and to review project governance and its relationship to the emerging Tooling Architecture.
  • John Quinn talked about the use of SAEAF in various national initiatives - this led to a discussion of the need to get SAEAF branded by HL7, with the corresponding expectation that the continuing evolution of SAEAF would need to be able to accept input from non-HL7 parties. The Governance Framework will need to accommodate this kind of governance as well. Note-after the meeting John Quinn talked to Chuck Jaffe and such a branding will be pursued.
  • EA Rollout Projects discussion-
    • NCI - caEHR - external initiative bringing mature specifications into HL7 and determine how they are balloted to become HL7 informative or normative specifications
    • PASS - initiative developing service specifications within HL7 with an intent to produce actual implementations
    • CTS II - HSSP project
    • Structured Documents - newly emerging IG or retrofit a completed IG project
    • The intent is to have ArB members support each alpha project

ARB Notes 2009-08-19

Q1 - Don Jorgensen presented the PASS initiative and subprojects to describe their intent, status, work products, milestones and working processes.  The specification stack is helping them work out ways of expressing what they are currently doing at a platform specific implementation level to identify patterns.  Guidance is desired on what criteria to use to partition services into logical sub-sets of operations - they are using the term “profile” to group services and produce descriptions of these logical subsets.  They also anticipate some interesting challenges to harmonize vocabulary before going to ballot.
Q2 - John presented current Behavioral Framework model - discussion occurred but is not landed yet - agree at the high level, no complete model agreed to yet. 
Q3 - Review of Hans presentation on need for simplified structure to represent unified approach to producing payloads that may be used across messaging, document sharing and services transport mechanisms.

ARB Notes 2009-08-20

' Wrap up and assignments'

  • HichHikers Guide - we will work with the author as requested.
  • HDF - we will selectively extract pertinent parts of the HDF and provide them to the technical editor of the SAEAF Book. The continued refinement of implementation guidance will then follow the resulting format as the ArB works with MnM to clarify methodology and quality criteria to produce relevant artifacts associated with the specification stack. We will no longer work on the HDF document.
  • DAM status - from the perspective of SAEAF, does it the DAM need to be normative?
  1. Does everybody need to have a DAM in a balloted specification? Most of the time if the intent of the specification is to produce an interoperability specification, with exceptions to be preauthorized.
  2. What is the scope of a DAM in an interoperability specification - Topic, Domain, Work Group? Topic, but may be drawn from more than one WG or Project DAMs and is congruent

What constitutes a well formed DAM - we have a definition of what it should have but not yet what it shall not have - needs work - HDF has content that can be leveraged - AMS will work with MnM to clarify quality criteria for well formed DAMs Can the DAM to become normative? Not at this time because many existing DAMs are not well formed and may be inconsistent with each other on how they address overlapping concepts. What quality criteria are required to be met to become normative - To be done in conjunction with 3. Cecil moved: our recommendation is that at this point in time DAMs should not be allowed to be balloted as a normative specification. Existing DAMs have been examined and there is considerable inconsistency in how DAMs are documented. Before a DAM can be proposed to become normative the ArB will have quality criteria that define what a well formed DAM is and how it aligns with other artifacts in the specification stack. Patrick seconded - 7,1,0 approved

  • Conversation with Structured Documents - Mark Koehn led a dialogue to select a Structured Documents Alpha Project. Structured Documents have determined that a proposed project to produce an implementation guide for a type of procedure report is a good candidate. We will meet with SD on Thursday Q3 at the Atlanta meeting to consult for the Alpha Project and also to brainstorm how SAEAF can also support CDA R3 - Charlie will send out an e-mail to the SD list-serve and cc the TSC indicating what our expectations are for that meeting.
  • Candidate EA Alpha Projects

We need to work out with Marc Koehn to develop the expectations of the ArB from the EA projects and corresponding obligations to them. The following areas of interest are being pursued by the designated ArB members to work with Marc and the respective WG chairs to formalize relationships. Some projects may not result in HL7 balloted specifications but we will learn a lot in any case:

  • NCI - Charlie & John
  1. CaEHR - cancer Ambulatory Care EHR
  2. SMS - Specification Management System
  • Infoway - Ron
  1. Blueprint 2015
  • Gov. Projects, DOD - Charlie
  1. EHR FM Mapping
  • SD
  1. Oregon Procedure Report Implementation Guide - Cecil
  2. CDA R3 - Patrick
  • Security - AMS
  1. PASS - confirmed project
  • OO - Patrick
  1. OO Dynamic Model
  • ITS - Dale
    1. XML ITS R2 for Data types R2
    2. ITS simplified
  • Vocabulary - Cecil
  1. CTS II - confirmed project
Retrieved from "https://wiki.hl7.org/w/index.php?title=August_18,_2009_Out-Of-Cycle_Minutes&oldid=26468"