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

Difference between revisions of "20121108 arb minutes"

From HL7Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 54: Line 54:
 
|colspan="2"|Health Intersections Pty Ltd
 
|colspan="2"|Health Intersections Pty Ltd
 
|-
 
|-
|.||[[User:Hufnagel | Hufnagel, Steve]]   
+
|X||[[User:Hufnagel | Hufnagel, Steve]]   
 
|colspan="2"| U.S. Department of Defense, Military Health System  
 
|colspan="2"| U.S. Department of Defense, Military Health System  
 
|-
 
|-
Line 105: Line 105:
  
 
==Minutes==
 
==Minutes==
 +
#Call to order at 16:04 Eastern.
 +
#Ron will post the minutes of the last meeting.
 +
##Austin:SAIF ARchitecture is Fine. Product architecture productline discussing a kickoff date.  Need BAM.
 +
##Ron: Have definition in the BAM.
 +
###Progress on the front-end piece.
 +
###Bo and Cecil no progress on the logical.
 +
#BAM Product Line Planning
 +
##Ron: Discussed with Jane.
 +
###From product line or product family aspect?  Have to start product line definition from customer requirements - product has attributes/qualities from the customer perspective.  FHIR came about because an HL7 person recognized the complexity of adoption - a consumer based perspective.  As we move down the stack to methodology, risk, governance, the lifecycle begin & ends with the customer.  Perspective needs to also include realm.
 +
### What is attractive to the community is a usable specification that can be repeated for needs - is the qualitative aspects of the technical.  Utility of fit for purpose.  FHIR meets their customers goals.  Need coherence to solve my business problems.
 +
###Drive-by interoperability addresses the technical customers.  A large EHR initiative need the standards to be fit for purpose for business needs.
 +
###We need to adopt BOTH sets of requirements:
 +
####Utility of the product
 +
####Dynamic behavior.  Messaging is not a problem, but dynamic behavior is lacking, and leads to chaos, and inconsistent workflow.
 +
###SAIF is about both things - goodness of the product, as well as dynamics.
 +
### We are not modeling product line dynamics. - what scope and depth is enough?
 +
###Zoran:  HL7SI ontology we express service semantics.  Follows SAIF semantics.  Careplans, referals with require service semantics need the dynamic.  Is 'service' a product?
 +
##Ron: With FHIR, what are we using it for?  It feels like a problem for the front line customer.
 +
##Austin:  The front line customer is our members - which encompases both communities.  Members have to address for their customers - who are not necessarily our direct customers.
 +
##Ron: Is dynamic workflow in scope, or do we produce product that will solve any dynamic behavior.  John had us do SAIF in the first place because the service paradigm blends the implementation as well as declared business need. DO the members feel we need to position the standards from a use-case perspective.
 +
##Austin: Use case for some product lines, not all.  A lot of the questions will be answered affirmative for some product lines, but others will not - e.g. CDA.
 +
##Cecil:  They are in denial of dynamics.  There is a difference between ADT/MPII dynamics.
 +
##Austin: In some areas it is important - there are implict dynamics in a product line like V2.
 +
##Cecil: Instead of "no behavior" should stated "Minimal" or "undefined".
 +
##Austin: May be not important for a product line.Members make that decision.
 +
##Ron: How do you get new members/classes of members?  HL7 needs to be prepared to model dynamic behavior for some of our customer base.  Our members are often only members because they get paid to use our stuff.  We want to create interest/viability so members will show up to protect their vested interests.  Some of the customer base needs to believe that HL7 provides standardized dynamic behavior.  Dynamic behavior will affect product family definition.
 +
##Austin: Part of the shared methodology of a family - includes dynamic behavior.
 +
##Ron: is this usefull for adopting standards for an enterprise level.
 +
##Andy: The issue for HL7 is for people who know enough - HL7 members who show up understand the intersection.  Interested in use across HL7 specifications.
 +
##Ron: I dont think you can stand up a product line architecture group up until you know the questions they need to ask.
 +
##Austin: The program is responsible for planning, as well as standing up.
 +
##Ron: Too soon will cause frustration for the planning group.
 +
##Jane: On the right path determining the questions to ask, recognizing we do not have a homegenous membership?
 +
##Cecil:  We need to define a process by which we categorize the artifacts in a consistent manner - need a core vocabulary too look at the artifacts.  We have approached sideways by grouping to logical/conceptual models instead of looking at the attributes.
 +
##Ron: Their are people who find V2 sufficient, and dont have the problems that V3 addresses.  Often used within the organization.  V3 is for cross organization interoperability. FHIR is another one of those things - oriented to a technology. CDA serves a different customer base. Now can write up the market segmentation, find elements that are behavior agnostic.
 +
##Jane: Need a taxonomy to describe the problem space.
 +
##Ron: We have asserted that a SOA based approach regardless of payload.  A community will be attracted to the organization because of their needs - fit-for-purpose.
 +
##Jane: The mobile environment will have requirements that are not traditional.
 +
##Ron: How will potential members identify with a product model to want to participate?
 +
##Austin: Needs to be grouped under governance, methodology, management.
 +
##Jane: Way we work is of benefit over the products.
 +
##Ron: Groups can layer on their conformity assessment as needed.
 +
##Ron: Bo's concern is that we need to model what we do have.  Each group is having a struggle to get through their portion.  I will encourage Bo to put what we have in the tooling.
 +
##Jane: by the time you get to concpetual you are defining a product, not a product line.
 +
##Ron: PL and PF define what is is, and how you produce it.
  
  
 
+
#Adjournment at 5:00pm Eastern
[[Category:Arb Minutes]]
+
[[User:Ajulian|Tony Julian]] 22:02, 8 November 2012 (UTC)

Latest revision as of 22:02, 8 November 2012

ARB - Meeting (Date in Title)

logistics

Teleconferences are held on Tuesday at 4:00pm U.S. Eastern Schedules may be found at HL7.org Conference Call Center


Please join my meeting from your computer, tablet or smartphone.

  1. Join the meeting:
  2. If you cant use voip then capture the PIN from the screen for the above action, then
  • Weekly conference call.
  • For 24/7 customer service please call (844) 844-1322.

Agenda

  1. Call to order
  2. Roll Call
  3. Approval of Agenda
  4. Approval of Minutes
  5. Report from Architecture Project
  6. BAM
  7. Product line Architecture
  8. Other business and planning
  9. Adjournment

Meeting Information

HL7 ArB Work Group Meeting Minutes

Location: Telcon

Date: 2012M1108
Time: 4:00pm U.S. Eastern
Facilitator Parker, Ron Note taker(s) Julian, Tony
Attendee Name Affiliation
X Bond,Andy NEHTA
. Constable, Lorraine Constable Consulting Inc.
X Curry, Jane Health Information Strategies
. Dagnall, Bo HP Enterprise Services
. Grieve, Grahame Health Intersections Pty Ltd
X Hufnagel, Steve U.S. Department of Defense, Military Health System
X Julian, Tony Mayo Clinic
. Loyd, Patrick ICode Solutions
X Lynch, Cecil Accenture
R Mead, Charlie National Cancer Institute
X Milosevic, Zoran NEHTA
X Parker, Ron CA Infoway
. Quinn, John Health Level Seven, Inc.
. Guests
X Kriesler, Austin HL7 TSC
. Legend
X Present
. Absent
R Regrets
Quorum Requirements Met: Yes

Minutes

  1. Call to order at 16:04 Eastern.
  2. Ron will post the minutes of the last meeting.
    1. Austin:SAIF ARchitecture is Fine. Product architecture productline discussing a kickoff date. Need BAM.
    2. Ron: Have definition in the BAM.
      1. Progress on the front-end piece.
      2. Bo and Cecil no progress on the logical.
  3. BAM Product Line Planning
    1. Ron: Discussed with Jane.
      1. From product line or product family aspect? Have to start product line definition from customer requirements - product has attributes/qualities from the customer perspective. FHIR came about because an HL7 person recognized the complexity of adoption - a consumer based perspective. As we move down the stack to methodology, risk, governance, the lifecycle begin & ends with the customer. Perspective needs to also include realm.
      2. What is attractive to the community is a usable specification that can be repeated for needs - is the qualitative aspects of the technical. Utility of fit for purpose. FHIR meets their customers goals. Need coherence to solve my business problems.
      3. Drive-by interoperability addresses the technical customers. A large EHR initiative need the standards to be fit for purpose for business needs.
      4. We need to adopt BOTH sets of requirements:
        1. Utility of the product
        2. Dynamic behavior. Messaging is not a problem, but dynamic behavior is lacking, and leads to chaos, and inconsistent workflow.
      5. SAIF is about both things - goodness of the product, as well as dynamics.
      6. We are not modeling product line dynamics. - what scope and depth is enough?
      7. Zoran: HL7SI ontology we express service semantics. Follows SAIF semantics. Careplans, referals with require service semantics need the dynamic. Is 'service' a product?
    2. Ron: With FHIR, what are we using it for? It feels like a problem for the front line customer.
    3. Austin: The front line customer is our members - which encompases both communities. Members have to address for their customers - who are not necessarily our direct customers.
    4. Ron: Is dynamic workflow in scope, or do we produce product that will solve any dynamic behavior. John had us do SAIF in the first place because the service paradigm blends the implementation as well as declared business need. DO the members feel we need to position the standards from a use-case perspective.
    5. Austin: Use case for some product lines, not all. A lot of the questions will be answered affirmative for some product lines, but others will not - e.g. CDA.
    6. Cecil: They are in denial of dynamics. There is a difference between ADT/MPII dynamics.
    7. Austin: In some areas it is important - there are implict dynamics in a product line like V2.
    8. Cecil: Instead of "no behavior" should stated "Minimal" or "undefined".
    9. Austin: May be not important for a product line.Members make that decision.
    10. Ron: How do you get new members/classes of members? HL7 needs to be prepared to model dynamic behavior for some of our customer base. Our members are often only members because they get paid to use our stuff. We want to create interest/viability so members will show up to protect their vested interests. Some of the customer base needs to believe that HL7 provides standardized dynamic behavior. Dynamic behavior will affect product family definition.
    11. Austin: Part of the shared methodology of a family - includes dynamic behavior.
    12. Ron: is this usefull for adopting standards for an enterprise level.
    13. Andy: The issue for HL7 is for people who know enough - HL7 members who show up understand the intersection. Interested in use across HL7 specifications.
    14. Ron: I dont think you can stand up a product line architecture group up until you know the questions they need to ask.
    15. Austin: The program is responsible for planning, as well as standing up.
    16. Ron: Too soon will cause frustration for the planning group.
    17. Jane: On the right path determining the questions to ask, recognizing we do not have a homegenous membership?
    18. Cecil: We need to define a process by which we categorize the artifacts in a consistent manner - need a core vocabulary too look at the artifacts. We have approached sideways by grouping to logical/conceptual models instead of looking at the attributes.
    19. Ron: Their are people who find V2 sufficient, and dont have the problems that V3 addresses. Often used within the organization. V3 is for cross organization interoperability. FHIR is another one of those things - oriented to a technology. CDA serves a different customer base. Now can write up the market segmentation, find elements that are behavior agnostic.
    20. Jane: Need a taxonomy to describe the problem space.
    21. Ron: We have asserted that a SOA based approach regardless of payload. A community will be attracted to the organization because of their needs - fit-for-purpose.
    22. Jane: The mobile environment will have requirements that are not traditional.
    23. Ron: How will potential members identify with a product model to want to participate?
    24. Austin: Needs to be grouped under governance, methodology, management.
    25. Jane: Way we work is of benefit over the products.
    26. Ron: Groups can layer on their conformity assessment as needed.
    27. Ron: Bo's concern is that we need to model what we do have. Each group is having a struggle to get through their portion. I will encourage Bo to put what we have in the tooling.
    28. Jane: by the time you get to concpetual you are defining a product, not a product line.
    29. Ron: PL and PF define what is is, and how you produce it.


  1. Adjournment at 5:00pm Eastern

Tony Julian 22:02, 8 November 2012 (UTC)