|
|
| Line 94: |
Line 94: |
| | | | |
| | ===Minutes=== | | ===Minutes=== |
| − | Convened 4:35 PM
| |
| − | *Austin describes to Jane the idea of setting up governance for a V2.x product line formally declaring V2 Publishing as the management group and InM as the methodology group, with an overarching all-product family governance body
| |
| − | **BAM is nearing readiness for this use; MaryKay notes the illustrations were very helpful in understanding and Austin adds they have made great progress in the last cycle to provide descriptive narration.
| |
| − | **They hope to have it ready to hand off in the next month or so.
| |
| − | **V2 is a good start with assigning formal recognition to governance structures that already exist. Question is whether V2 IGs would be part of that or separate. Might need a call with V2 Publishing and CGIT cochairs to review along with InM. Invite Juba and Woody. Need Frank (also CGIT cochair) also. If IGs are a different methodology ergo a different family we may not need to continue CGIT involvement.
| |
| − | *Agenda review - defer MaryKay's work-in-progress
| |
| − | *Notes of [[20140709_PLA_call]] review
| |
| − | *BAM-lite feedback and review
| |
| − | **Review section 7
| |
| − | ***CDS vMR different product family. Different methodology for data types, not RIM or FHIR, ITS (schema generation) dependent on tooling in EA. Encouraged to harmonize to RIM or FHIR but no deadlines for accomplishing this.
| |
| − | ****Implemented in academic institutions theoretically and brought to international standards under the radar lacking due diligence.
| |
| − | ****Example of poor governance practices.
| |
| − | ***MaryKay notes that FHIR is not conformant to the RIM, but Austin notes that Lloyd has mapped it to the RIM. Some infrastructure pieces in FHIR cannot be mapped to RIM. Ontological reasoning processes are theoretically enabled due to RIM mapping. FHIR datatypes laid atop ISO datatypes (V3 abstract Datatypes R2), applying the 80% rule.
| |
| − | ***V2 product family governance board would set criteria for establishing cutoff dates for V2.x proposals and the V2 management group (V2 editors) would set the cutoff date. Also allows for formal lines of authority and responsibilities.
| |
| − | ***constraint of a standard as definition of an IG based on a use case and applying a methodology for doing so. CGIT defines this for V2.x.
| |
| − | ***CDA IGs have a very different methodology.
| |
| − | ***What criteria is used to determine conformance? Constraints need to be testable. Testable conformance criteria definition is no one specific group's responsibility at this time. V2.x IG product family if it were established would likely name CGIT as its methodology group notes Austin.
| |
| − | ***Balloting provides governance and management to any balloted artifact.
| |
| − | **Until the TSC stands up a cross-product governance board the TSC would be the governance board for a V2.x IG product family. The TSC remains the management group or delegates to the work groups the management. OO's LOI, LRI, eDOS examples have state of the art for V2.x message profiling. Default management group could be argued to be OO.
| |
| − | **2.x IG product family would have to reflect relationship and dependency on V2.x standard product family.
| |
| − | ***CDA IGs use Trifolia, MDHT, and ART-DECOR tooling for producing their artifacts. V2 IGs don't use those tools.
| |
| − | ***Because we don't have a definition for what an IG is, anyone can go out and write something and slap the IG name on it, notes MaryKay. All IGs should have some structure conformant across all product families, what they should contain. Every IG should have a purpose, a purpose statement, some high-level requirements. Austin notes that this would be a set of rules created by the overarching governance board. Cross-product family issues should be guided by the governance board.
| |
| − | ***Austin nominates MaryKay as the overall governance board chair.
| |
| − | **Bring forward these basic steps from http://gforge.hl7.org/gf/project/hlbam2b/scmsvn/?action=browse&path=%2F%2Acheckout%2A%2Ftrunk%2Fdocuments%2Fbam_section_7_business_architecture.docx&revision=44 in the 3rd page which lists artifacts that need to be generated, potentially on a form, for setting up a product family. Concept proposal: Describe the opportunity (opportunity assessment); describe the market segmentation (checkboxes for stakeholders), describe the business artifacts (conceptexample). Review Proposal: aspiration confirmation, proposal assessment. Create concept recommendation, assess organizational readiness. Scope Recommendation: submit recommendation. Adjudicate recommendation: product decision and scope decision.
| |
| − | **Goal: develop form to request establishing a Product Family for next conference call. Need also a joint session scheduled at the next WGM. Use the PLA session Wednesday Q4 as joint TSC, V2.x publishing, CGIT, INM, Juba. Need to interpret the steps in "real words" and start working on the process steps and routing, etc.
| |
| − |
| |
| − | Mary Ann not available Oct 1 so next meeting Oct 15.
| |
| − |
| |
| − | Adjourned 4:47PM
| |
| | | | |
| | ===Meeting Outcomes=== | | ===Meeting Outcomes=== |
