Difference between revisions of "2018-05-12 TSC WGM Agenda"
Jump to navigation
Jump to search
Anne wizauer (talk | contribs) |
Anne wizauer (talk | contribs) |
||
Line 125: | Line 125: | ||
#*What are the questions and issues we want to solve? How do we evaluate new methodology projects? Two architecture problems: organizational architecture and architecture of the material. How do we deal with an architected plan with how we put our standards together – do we have the infrastructure and tooling in place to deal with that? Wayne: One issue is modelling vs. architecture. SAIF-CD predates product line/family. BAM is not consumable at the line level. Floyd: When we looked at SAIF in CQI, it helped us understand what components we need. There needs to be something at the governance level that says you have these pieces and here’s how they have to work together. We haven’t had enough applied bandwidth to take the formal specification into a real application to day to day work. Discussion over what it would take to widely operationalize, and whether that is the ultimate goal. Do we wish to have an architectural view of how our standards fit together? SAIF is an architectural view of how you create interoperable standards. Then there’s the whole question around cross domain modeling issues. How many models do we need? If everyone has their own model then everyone has to map to everyone else. Paul: One issue is if one should do modeling; another is if one should use the same tool or limited subset of tools, and another is if we should use a canonical definition. Some WGs have found value in oing a conceptual business model of their space and then figure out what has to go into V2, V3 or FHIR. RDAM project sees that as a problem – they want everybody to have one single model that drives everything. What is the real problem that we’re solving, and does everyone see the same problem? Conceptual modeling isn’t a bad idea for WGs to do to determine business needs. MK: You need to be clearly able to define the scope for the particular model, and there should be an overarching precept about how you’re going to do it. Lorraine: One of the requirements that ARB put into effect was there must be a clearly defined scope for normative track conceptual models. Perhaps we should enumerate the issues we want to tackle and then make a plan to move forward. Paul: It’s reasonable that domains have an area of expertise and responsibility that will consume things outside their area of responsibility – for example, everyone’s domain interacts with Patient. It’s reasonable to encourage WGs to develop a model of the domain of things for which they’re responsible. Discussion over common vocabulary and harmonization efforts. We haven’t applied that consistently across the organization. Floyd notes that the backlash of not having consistency is people abandoning the work. John: If the burden falls on everyone else, it doesn’t work. Paul: If the intention of a standards body is to manage the artifacts we’re producing, we should have the principal of interoperability as our guide. Lorraine: That was the intent of SAIF. Paul: The tooling layer would be a place where WGs could have differences as long as the product output is standard. | #*What are the questions and issues we want to solve? How do we evaluate new methodology projects? Two architecture problems: organizational architecture and architecture of the material. How do we deal with an architected plan with how we put our standards together – do we have the infrastructure and tooling in place to deal with that? Wayne: One issue is modelling vs. architecture. SAIF-CD predates product line/family. BAM is not consumable at the line level. Floyd: When we looked at SAIF in CQI, it helped us understand what components we need. There needs to be something at the governance level that says you have these pieces and here’s how they have to work together. We haven’t had enough applied bandwidth to take the formal specification into a real application to day to day work. Discussion over what it would take to widely operationalize, and whether that is the ultimate goal. Do we wish to have an architectural view of how our standards fit together? SAIF is an architectural view of how you create interoperable standards. Then there’s the whole question around cross domain modeling issues. How many models do we need? If everyone has their own model then everyone has to map to everyone else. Paul: One issue is if one should do modeling; another is if one should use the same tool or limited subset of tools, and another is if we should use a canonical definition. Some WGs have found value in oing a conceptual business model of their space and then figure out what has to go into V2, V3 or FHIR. RDAM project sees that as a problem – they want everybody to have one single model that drives everything. What is the real problem that we’re solving, and does everyone see the same problem? Conceptual modeling isn’t a bad idea for WGs to do to determine business needs. MK: You need to be clearly able to define the scope for the particular model, and there should be an overarching precept about how you’re going to do it. Lorraine: One of the requirements that ARB put into effect was there must be a clearly defined scope for normative track conceptual models. Perhaps we should enumerate the issues we want to tackle and then make a plan to move forward. Paul: It’s reasonable that domains have an area of expertise and responsibility that will consume things outside their area of responsibility – for example, everyone’s domain interacts with Patient. It’s reasonable to encourage WGs to develop a model of the domain of things for which they’re responsible. Discussion over common vocabulary and harmonization efforts. We haven’t applied that consistently across the organization. Floyd notes that the backlash of not having consistency is people abandoning the work. John: If the burden falls on everyone else, it doesn’t work. Paul: If the intention of a standards body is to manage the artifacts we’re producing, we should have the principal of interoperability as our guide. Lorraine: That was the intent of SAIF. Paul: The tooling layer would be a place where WGs could have differences as long as the product output is standard. | ||
#*Question is what degree of modeling and architectural guidance do we need to move closer to the interoperability mission? Where is the gap? What are we not providing? Austin: Do we have to have a single overarching DAM for all health information for everything that we do? Is there enough bang for the buck in that? Lorraine: Doing the big bang approach anywhere doesn’t usually work. There is value in providing a framework and asking projects to discuss where they fit in the framework. What do we have, and how do they fit together? Wayne notes that some of our standards are part of the interoperability vision, and others are just here doing something they want/need and we end up as a custodian. Having a vision and framework should help us be clearer on how we communicate with our members and stakeholders. Melva: Agree that the big bang isn’t right, but all of these things going forward are worrisome. There has to be a balance and some governance. We need to make sure that we involve everyone whose work and areas are affected to avoid overlapping work. Austin notes that some of this stuff is developed for an external audience. Wayne: We should be applying some sort of test against these things when we get them to make sure there aren’t overlaps. Perhaps we need a graphical framework to look at. Austin: RDAM is intended for consumption within HL7, although it was developed externally. Discussion over the FHIM and control over it – need to figure out a TSC perspective on it. | #*Question is what degree of modeling and architectural guidance do we need to move closer to the interoperability mission? Where is the gap? What are we not providing? Austin: Do we have to have a single overarching DAM for all health information for everything that we do? Is there enough bang for the buck in that? Lorraine: Doing the big bang approach anywhere doesn’t usually work. There is value in providing a framework and asking projects to discuss where they fit in the framework. What do we have, and how do they fit together? Wayne notes that some of our standards are part of the interoperability vision, and others are just here doing something they want/need and we end up as a custodian. Having a vision and framework should help us be clearer on how we communicate with our members and stakeholders. Melva: Agree that the big bang isn’t right, but all of these things going forward are worrisome. There has to be a balance and some governance. We need to make sure that we involve everyone whose work and areas are affected to avoid overlapping work. Austin notes that some of this stuff is developed for an external audience. Wayne: We should be applying some sort of test against these things when we get them to make sure there aren’t overlaps. Perhaps we need a graphical framework to look at. Austin: RDAM is intended for consumption within HL7, although it was developed externally. Discussion over the FHIM and control over it – need to figure out a TSC perspective on it. | ||
− | FHIM should identify and put forward resources to manage it. Discussion over too many canonical models creating chaos and works again interoperability. HL7 community needs to be able to sculpt the models to their needs. Lorraine: The RDAM question is a slightly separate question. SGB is looking at the evaluation piece so perhaps we should look at that first before we make a decision. There is value of having a conceptual view of our information space and how our standards fit together in a framework, and then we can come up with a plan to handle overlaps and gaps. Wayne: Should we consider having an Interoperability Review Board? Perhaps it should just be a function rather than another group. The product management council could look at these issues too. We need some sort of framework that people can understand and see where the pieces fit together. Perhaps ARB should establish criteria for establishing interoperability. | + | #*FHIM should identify and put forward resources to manage it. Discussion over too many canonical models creating chaos and works again interoperability. HL7 community needs to be able to sculpt the models to their needs. Lorraine: The RDAM question is a slightly separate question. SGB is looking at the evaluation piece so perhaps we should look at that first before we make a decision. There is value of having a conceptual view of our information space and how our standards fit together in a framework, and then we can come up with a plan to handle overlaps and gaps. Wayne: Should we consider having an Interoperability Review Board? Perhaps it should just be a function rather than another group. The product management council could look at these issues too. We need some sort of framework that people can understand and see where the pieces fit together. Perhaps ARB should establish criteria for establishing interoperability. |
#**MOTION to request that ARB define a checklist of interoperability criteria for the evaluation of new projects: Ken/Floyd | #**MOTION to request that ARB define a checklist of interoperability criteria for the evaluation of new projects: Ken/Floyd | ||
#**VOTE: All in favor | #**VOTE: All in favor | ||
+ | |||
===Q3 - 1:45 pm to 3 pm=== | ===Q3 - 1:45 pm to 3 pm=== | ||
#Visitor: Scott Robertson | #Visitor: Scott Robertson |
Revision as of 06:33, 13 May 2018
TSC Saturday meeting for Cologne WGM
back to TSC Minutes and Agendas
TSC WGM Agenda/Minutes
HL7 TSC Meeting Minutes Location:Salon 6, Siebengebirge |
Date:2018-05-12 Time: 9:00 AM | |
Facilitator: | Note taker(s): Anne Wizauer | |
Attendee | Name | Affiliation |
Calvin Beebe | HL7 Board Chair (member ex officio w/ vote) | |
x | Giorgio Cangioli | HL7 Affiliate Representative |
x | Lorraine Constable | HL7 ARB Co-Chair |
Regrets | Jean Duteau | HL7 Affiliate Representative |
x | Floyd Eisenberg | HL7 DESD Co-chair |
x | Russ Hamm | HL7 FTSD Co-chair |
Pat Van Dyke | HL7 Immediate Past Board Chair (member ex officio w/ vote) | |
Chuck Jaffe | HL7 CEO (member ex officio w/o vote) | |
Regrets | Tony Julian | HL7 ARB Co-Chair |
x | Paul Knapp | HL7 FTSD Co-Chair |
Q2 | Austin Kreisler | TSC Chair, SSD-SD Co-chair |
x | Wayne Kubick | HL7 CTO (TSC member ex officio w/vote) |
x | Ken McCaslin | Adhoc Member |
x | Mary Kay McDaniel | SSD-SD Co-chair |
x | John Roberts | Adhoc Member - GOM Expert |
x | Anne Wizauer (scribe, non-voting) | HL7 HQ |
x | Melva Peters | HL7 DESD Co-Chair |
Regrets | Andy Stechishin | HL7 T3SD Co-Chair |
x | Sandra Stuart | HL7 T3SD Co-Chair |
Quorum Requirements (Co-chair +5 with 2 SD Reps) Met: (yes/No) |
Agenda Topics
Q1 - 9 am to 10:30 am
- Roll Call and Introduction of visitors (including declaration of interests)
- (May) Identify TSC Nominations Committee/agree on chair
- New product family management council
- GOC Changes related to balloting
Q2 - 11 am to 12:30 pm
- SGB Update
- Role of modeling and architecture spanning the organization
Q3 - 1:30 pm to 3 pm
- FHIR and ballot topics:
Q4 - 3:30 pm to 5pm
- Technology roadmap and tooling
- Messaging at co-chair dinner/steering divisions/general sessions
Minutes
Q1 - 9 am to 10:30 am
- Roll Call and Introduction of visitors (including declaration of interests)
- No visitors
- What do we do well/what can we do better/what in your life is affecting your ability to participate
- Sandy: Making progress on essentialism has been good. My mom passed away so life has been crazy.
- Lorraine: Grandbaby is now 8 days old. TSC is making progress and now we need to work on the roadmap and get the product management groups going. Work has been chaotic but things should slow down in the summer a bit.
- Giorgio: Might be interesting to focus on the role of tooling and how to develop FHIR IGs. Group agrees tooling is a conundrum. Will discuss later on the agenda.
- Melva: She has retired but has a couple small contracts that she’s limiting to one day a week plus her HL7 work. TSC is getting better – need to find ways to stick to the mission and get to the goal quicker than we sometimes do.
- MK: My mom is 96 and losing her eyesight. Work is going well.
- Russ: Seems to be a gap between what he deals with at the cochair level and what he deals with at the cochair level. Wayne would like to hear more specifics later in the meeting. What we’re doing well – we have a good grasp of where we would like to go but the wheels aren’t always aligned with the WGs. Day job is what affects ability to participate as he has become a manager. His organization doesn’t always understand the value of HL7 work. Struggles with prioritizing between work and HL7, and between Vocab and TSC. Discussion over need to better describe both the value of standards and the value of participating in the development of standards. Organizations struggle to see the value in using existing standards as opposed to doing something quick to get it done.
- Wayne: We need to better at communicating this kind of TSC feedback to the board in a formal way. Need to develop formal statements. Group agrees.
- John: Disconnect between product lines, WGs, and TSC. Has come out of retirement to work “half time” which bleeds into full time with HL7.
- Ken: People from the Board don’t show up here regularly – that’s one issue that’s a gap. Wayne agrees that the chair should at least periodically come. Ken is having an issue with work; not going to be funded for HL7 meetings and may not be at Accenture for too long.
- Floyd: Understanding at the WG level what’s going on at TSC is a good point. Challenge is people are volunteers and it’s difficult to get people to do the hard work. So many competing priorities. Multiple versions of FHIR make things difficult. The community need better understanding of how to think about data. Projects are competing and it’s difficult to navigate when people don’t understand why we do things. Need to be more careful in our approval processes – not very good at not approving things. Need to consider the long term goal and how to these things fit in. MK: We don’t have an efficient way of coordinating work across WGs, Steering Divisions, and pulling information in from the community. Discussion over how we communicate TSC information.
- ACTION: Add WGH to Baltimore agenda
- Wayne: We spend too much time on details of non-essential stuff – need to work on bigger issues. We bring up issues but often they go nowhere. Communication is the other big piece we need to work on.
- (May) Identify TSC Nominations Committee/agree on chair
- The committee is made up of steering division co-chairs not up for re-election: Floyd, MK, Andy, Russ; John is willing to help. Those five will set up a call and choose a co-chair. Andy may not continue – Sandy will report back. Nominations due 6/15. SD cochairs should announce in the Monday night meetings that nominations will open soon.
- Wayne notes that Austin has questions about continuing and we may have to consider that in the future depending on how things go. Lorraine: We need to consider succession planning in general. Wayne wonders if we should elect a vice chair like the board does. Group agrees that it would be beneficial in a number of ways. MK: We’re also missing a broad international perspective – we are North America-centric as a group. Lorraine notes there are things going on with our stuff all over the world that we don’t know anything about.
- Table this until next quarter for a possible motion
- New product family management council
- Meeting is Q0 on Monday. Wayne has slides. Roadmap planning is one activity they will be charged with. Implementing SGB precepts. Product family messaging. Addressing the diversity of approaches. Moving toward common tooling. Adjusting to new tooling initiatives. Impacts across product families.
- GOC Changes related to balloting
- This is a proposal from Lloyd for GOM changes based on JIRA balloting. Lorraine: Process should be separated from the tooling. Lloyd proposed some changes to our process separate from balloting as well. Ken notes that in the past, we haven’t made GOM changes during a pilot process. If the process is accepted, then we make the GOM changes. We could make a resolution that in the pilot process, it isn’t necessary to do the spreadsheet. Lorraine: Right now the GOM outlines the how, not the why or the what. Need to focus on the business requirement of communicating results to the balloters. Floyd: The issue isn’t JIRA or Gforge – it’s a matter of saying “I’m a member and making a comment on the ballot.” Ken proposes that the JIRA process may still be within the law outlined in the GOM – JIRA would replace the ballot desktop.
- MOTION to put the JIRA ballot process under pilot consideration so we can review, validate, and confirm how we want to move forward; appropriate GOM changes would be made after the pilot is deemed successful: Ken/Paul
- Discussion: Paul notes that we don’t have a test system we can demo at this point. Discussion over the pilot process. This is our most major organizational process and we need to proceed cautiously. The GOM should be more general about the business requirement. Paul suggests we don’t pilot on live stuff yet. MK: So we’re going to test something, but what are we testing it against if there weren’t requirements defined? Wayne notes there are requirements in the proposed revised ballot process document. Ken is also working on a test plan.
- AMENDED MOTION to test the proposed JIRA ballot process changes to determine if we’re ready to request permission from the TSC to proceed to a pilot; appropriate GOM changes would be made after the pilot is deemed successful: Ken/Paul
- VOTE: All in favor
- MOTION to put the JIRA ballot process under pilot consideration so we can review, validate, and confirm how we want to move forward; appropriate GOM changes would be made after the pilot is deemed successful: Ken/Paul
- Same motion applies to the proposed changes to the Essential Requirements
- This is a proposal from Lloyd for GOM changes based on JIRA balloting. Lorraine: Process should be separated from the tooling. Lloyd proposed some changes to our process separate from balloting as well. Ken notes that in the past, we haven’t made GOM changes during a pilot process. If the process is accepted, then we make the GOM changes. We could make a resolution that in the pilot process, it isn’t necessary to do the spreadsheet. Lorraine: Right now the GOM outlines the how, not the why or the what. Need to focus on the business requirement of communicating results to the balloters. Floyd: The issue isn’t JIRA or Gforge – it’s a matter of saying “I’m a member and making a comment on the ballot.” Ken proposes that the JIRA process may still be within the law outlined in the GOM – JIRA would replace the ballot desktop.
Q2 - 11 am to 12:30 pm
- SGB Update
- Paul here to update. We elected Lorraine to replace Austin in cochair role. Have been working to stand up the V2 and CIMI management groups. Will be addressing some larger issues this week including looking at the impacts of larger projects on the organization. Lorraine: TSC asked us to look at how we deal with big new product or methodology proposals coming in the organization. We agreed to try piloting the initial assessment from the BAM against the evaluation of those projects. We’ll then make a lightweight guide/checklist for potentially broader use. Paul: We’re also doing a report out at the cochair dinner that we’ll look at during Q2 tomorrow in preparation and bring back to TSC tomorrow evening for review/blessing. Last item is we’ll start talking about modeling and architecture spanning the organization.
- Role of modeling and architecture spanning the organization
- What are the questions and issues we want to solve? How do we evaluate new methodology projects? Two architecture problems: organizational architecture and architecture of the material. How do we deal with an architected plan with how we put our standards together – do we have the infrastructure and tooling in place to deal with that? Wayne: One issue is modelling vs. architecture. SAIF-CD predates product line/family. BAM is not consumable at the line level. Floyd: When we looked at SAIF in CQI, it helped us understand what components we need. There needs to be something at the governance level that says you have these pieces and here’s how they have to work together. We haven’t had enough applied bandwidth to take the formal specification into a real application to day to day work. Discussion over what it would take to widely operationalize, and whether that is the ultimate goal. Do we wish to have an architectural view of how our standards fit together? SAIF is an architectural view of how you create interoperable standards. Then there’s the whole question around cross domain modeling issues. How many models do we need? If everyone has their own model then everyone has to map to everyone else. Paul: One issue is if one should do modeling; another is if one should use the same tool or limited subset of tools, and another is if we should use a canonical definition. Some WGs have found value in oing a conceptual business model of their space and then figure out what has to go into V2, V3 or FHIR. RDAM project sees that as a problem – they want everybody to have one single model that drives everything. What is the real problem that we’re solving, and does everyone see the same problem? Conceptual modeling isn’t a bad idea for WGs to do to determine business needs. MK: You need to be clearly able to define the scope for the particular model, and there should be an overarching precept about how you’re going to do it. Lorraine: One of the requirements that ARB put into effect was there must be a clearly defined scope for normative track conceptual models. Perhaps we should enumerate the issues we want to tackle and then make a plan to move forward. Paul: It’s reasonable that domains have an area of expertise and responsibility that will consume things outside their area of responsibility – for example, everyone’s domain interacts with Patient. It’s reasonable to encourage WGs to develop a model of the domain of things for which they’re responsible. Discussion over common vocabulary and harmonization efforts. We haven’t applied that consistently across the organization. Floyd notes that the backlash of not having consistency is people abandoning the work. John: If the burden falls on everyone else, it doesn’t work. Paul: If the intention of a standards body is to manage the artifacts we’re producing, we should have the principal of interoperability as our guide. Lorraine: That was the intent of SAIF. Paul: The tooling layer would be a place where WGs could have differences as long as the product output is standard.
- Question is what degree of modeling and architectural guidance do we need to move closer to the interoperability mission? Where is the gap? What are we not providing? Austin: Do we have to have a single overarching DAM for all health information for everything that we do? Is there enough bang for the buck in that? Lorraine: Doing the big bang approach anywhere doesn’t usually work. There is value in providing a framework and asking projects to discuss where they fit in the framework. What do we have, and how do they fit together? Wayne notes that some of our standards are part of the interoperability vision, and others are just here doing something they want/need and we end up as a custodian. Having a vision and framework should help us be clearer on how we communicate with our members and stakeholders. Melva: Agree that the big bang isn’t right, but all of these things going forward are worrisome. There has to be a balance and some governance. We need to make sure that we involve everyone whose work and areas are affected to avoid overlapping work. Austin notes that some of this stuff is developed for an external audience. Wayne: We should be applying some sort of test against these things when we get them to make sure there aren’t overlaps. Perhaps we need a graphical framework to look at. Austin: RDAM is intended for consumption within HL7, although it was developed externally. Discussion over the FHIM and control over it – need to figure out a TSC perspective on it.
- FHIM should identify and put forward resources to manage it. Discussion over too many canonical models creating chaos and works again interoperability. HL7 community needs to be able to sculpt the models to their needs. Lorraine: The RDAM question is a slightly separate question. SGB is looking at the evaluation piece so perhaps we should look at that first before we make a decision. There is value of having a conceptual view of our information space and how our standards fit together in a framework, and then we can come up with a plan to handle overlaps and gaps. Wayne: Should we consider having an Interoperability Review Board? Perhaps it should just be a function rather than another group. The product management council could look at these issues too. We need some sort of framework that people can understand and see where the pieces fit together. Perhaps ARB should establish criteria for establishing interoperability.
- MOTION to request that ARB define a checklist of interoperability criteria for the evaluation of new projects: Ken/Floyd
- VOTE: All in favor
Q3 - 1:45 pm to 3 pm
- Visitor: Scott Robertson
- FHIR and ballot topics:
- Ken: Right now you either vote negative, abstain, or affirmative with several flavors. Ken is suggesting we do away with the flavors of affirmative because balloters don’t comprehend what they mean. Melva: From a reconciliation standpoint, I like the flavors. Lorraine agrees. If it’s affirmative with typo, it can be lumped together and passed on to editors. If it’s not labeled, then each on has to be examined. Giorgio suggests combining affirmative – comment and affirmative – suggestion in order to simplify things. Ken: So we would have affirmative – comment, affirmative – question, and affirmative – typo.
- MOTION to reduce the affirmative to the above options (affirmative – comment, affirmative – question, and affirmative – typo): Lorraine/Sandy
- VOTE: All in favor
- We also have a number of reconciliation dispositions. Ken would like to reduce them to persuasive and persuasive with mod, non-persuasive, and non-persuasive with mods. Discussion over the merits of each. Decision that “deferred and tracked” should be “referred and tracked.” Decision to remove it altogether. Discussion over changing not related to non-persuasive. Discussion over removing “input from balloter” as a ballot disposition, although group agrees that you still need to be able to find that information. Should be a status issue rather than a disposition. Considered for future use: we need a way to label something as work we haven’t had a chance to do yet. Lorraine states she would like it to stay as a disposition. Discussion over removing one of the considered question dispositions and adding explanation in to the motion.
- MOTION to keep Persuasive, Persuasive with mods, non-persuasive, and considered for future use for the JIRA balloting pilot: Ken/Lorraine
- VOTE: All in favor
- Existing rules for dispositions
- Covered above
- FHIR proposed ballot and product naming conventions
- Proposal is to simplify names and put metadata elsewhere. Discussion over how to do so appropriately. Ken: What if the product name stays the same no matter what and is versioned? Reviewed metadata examples from Lorraine. Ken proposes that the name is, for example, HL7 FHIR Profile: US-Core and the rest is metadata. Floyd states that it’s then extra work to figure out what edition it is that people aren’t going to want to do.
- Further discussion on JIRA balloting, testing, and communication plan
- Ken: Right now you either vote negative, abstain, or affirmative with several flavors. Ken is suggesting we do away with the flavors of affirmative because balloters don’t comprehend what they mean. Melva: From a reconciliation standpoint, I like the flavors. Lorraine agrees. If it’s affirmative with typo, it can be lumped together and passed on to editors. If it’s not labeled, then each on has to be examined. Giorgio suggests combining affirmative – comment and affirmative – suggestion in order to simplify things. Ken: So we would have affirmative – comment, affirmative – question, and affirmative – typo.
Q4 - 3:30 pm to 5pm
- Wayne is putting together a communication plan for the JIRA balloting pilot; Ken is working on the test plan. Still need to look into project management. Need to make sure we’re addressing all the different needs of our disparate communities. Lorraine: We need to look at the business processes. Things will change for affiliates, for example. Ken: We seem to have this idea of a primary balloter and a secondary balloter, which is not in the GOM. Lorraine: The process he’s got is, if you’re going to enter a comment, you look to see if it’s already been entered. If it hasn’t, you enter the comment and promote it to the level of a ballot vote. Floyd notes that sometimes one person handles all the votes, for example, on behalf of X person or organization.
- ACTION: TSC to re-review full document for future agenda
- Proposed ballot naming conventions, continued
- Reviewed proposed rules. Discussion over the problems with using Release twice for both STU and Normative publications. Could use Edition to avoid confusion. Reviewed how the spec is named on the FHIR site. Discussion over how errata publications affect things like implementation guides. Paul notes that the IGs delineate which version it references. Lorraine notes that the name of the ballot is not the name of the spec, which this document confuses a little. Wayne: Maybe there’s a perpetual name of everything we’re going to do with a product, then there are ballot names and publication names on top of that – all uniquely named and traceable. There’s a fixed name at the front. Reviewed most recent ballot announcement for naming. The next normative ballot will be the same – the only thing that will change is the unique ballot ID. The main problem from Grahame/Lloyd’s standpoint is having the Release 1 is confusing to the implementers/the community. Lorraine notes that in V3 they decoupled ballot name from publication name. Discussion over whether or not ANSI cares how we name things as long as we follow our conventions; the essential requirements just say we have to follow our processes.
- ACTION: Ask Lynn if Release number is an ANSI requirement; other than that we need something else to make it unique.
- ACTION: Wayne and Anne to meet with Lynn to discuss
- ACTION: Add to future call: ARB Definition of Guidance Document (from September)
- Reviewed proposed rules. Discussion over the problems with using Release twice for both STU and Normative publications. Could use Edition to avoid confusion. Reviewed how the spec is named on the FHIR site. Discussion over how errata publications affect things like implementation guides. Paul notes that the IGs delineate which version it references. Lorraine notes that the name of the ballot is not the name of the spec, which this document confuses a little. Wayne: Maybe there’s a perpetual name of everything we’re going to do with a product, then there are ballot names and publication names on top of that – all uniquely named and traceable. There’s a fixed name at the front. Reviewed most recent ballot announcement for naming. The next normative ballot will be the same – the only thing that will change is the unique ballot ID. The main problem from Grahame/Lloyd’s standpoint is having the Release 1 is confusing to the implementers/the community. Lorraine notes that in V3 they decoupled ballot name from publication name. Discussion over whether or not ANSI cares how we name things as long as we follow our conventions; the essential requirements just say we have to follow our processes.
Sunday evening Agenda Topics
- ArB
- BAM
- FHIR
- CDA-MG
- Messaging at co-chair dinner/steering divisions/general sessions
Wednesday lunch
- Technology roadmap and tooling
- TSC Mission and Charter review - add to upcoming call/e-vote