This wiki has undergone a migration to Confluence found Here
20140120 FMG WGM
Jump to navigation
Jump to search
HL7 TSC FMG Meeting Minutes Location: Frio |
Date: 2014-01-20 Time: 12:30 PM U.S. Eastern | |
Chair: Lloyd | Note taker(s): Lynn |
Quorum = chair + 4 | yes | |||||
Co chairs | x | Hugh Glover | x | Lloyd McKenzie | ||
ex-officio | x | Ron Parker, FGB Chair | . | John Quinn, CTO |
Members | Members | Members | Observers/Guests | ||||
X | Lorraine Constable | regrets | Paul Knapp | attending by Skype | John Moehrke | x | Lynn Laakso, scribe |
regrets, attending by Skype | David Hay | x | Josh Mandel | x | Brian Pech | Austin Kreisler | |
x | Woody Beeler |
Agenda
- Roll Call
- Agenda Check
- Hosting DSTU and managing changes
- two URLs: hl7.org/fhir and fhir.hl7.org. That's a bit confusing. We need 3 sites (Official DSTU, "frozen" version for Connectathons and "development" version (could put access restrictions on the latter)
- Where are we going to capture changes? (DSTU page vs. gForge)
- How do we track and post what the "guidance" is for implementers on breaking changes without having them dig through the development release in between DSTU releases
- Objectives for next release
- Additional QA criteria/requirements
- New resources
- Profiles (including CCDA)
- Additional mappings
- Hosting DSTU and managing changes
- Metrics
- Questionnaire questions?
Minutes
- Agenda Check - early topics managed on Sunday; objectives need to include best practices or specific use cases notes Lorraine, also need to estimate timing of new release notes Hugh
- Hosting DSTU and managing changes
- two URLs: hl7.org/fhir and fhir.hl7.org. That's a bit confusing. We need 3 sites (Official DSTU, "frozen" version for Connectathons and "development" version (could put access restrictions on the latter)
- Where are we going to capture changes? (DSTU page vs. gForge)
- How do we track and post what the "guidance" is for implementers on breaking changes without having them dig through the development release in between DSTU releases
- Objectives for next release
- Additional QA criteria/requirements
- update for what things should look like, methodology, vetting, best practices, adherence to FGB precepts
- New resources
- Lloyd reports a set of additional resources needed for CCDA R2: coverage, referral, capturing user/patient preferences e.g. "policy" (Lorraine notes food and medication preferences is Patient Care but they didn't have bandwidth and they deferred to OO). John notes that privacy and security preferences have been handled by CBCC. Lloyd points out that the specific requirements for CCDA is Advanced Directives. Ron suggests communication preferences might be in order, along with other dimensions of preferences in consumer health. PC, CBCC, Sec, OO are candidates for primary lead. John suggests we use the consent resource. Hugh suggests we might consider it as managing as a policy and discussion ensued. PC needs to own referral and care transfer. Healthcare advance directives scope can be proposed to CBCC. John notes the privacy example allows you to contain a pointer outside. Lloyd will approach CBCC to assess their appetite.
- Lloyd asks Lorraine if OO will take on Lab orders and nutrition as well; she meets with a professional association tomorrow and if they support the work then OO can take it on.
- Scheduling, appointment, slot etc is underway in PA.
- Lorraine notes that compositional resources for BP and other of that type needs further evaluation.
- timing of new release - when will we get to these other resources? Lloyd notes that the development server provides flexibility in permitting development yet preparing for another release in 12-18 months. Next DSTU ballot would then be for 2015Jan. 2014Sep ballot would require finalized material by August and a challenge for OO. Paul asks about balloting resources by themselves - Lloyd notes we can ballot multiple times with different resources but aiming for the next ballot to encompass CCDA R2 is what he envisions. Anything short of that would just create more work in extra ballot cycles. You can re-ballot with limiting scope to just the resource in question but publication requires publishing the whole spec and not just a single resource. Brian notes the ES/Publishing infrastructure would also be needed before we went to another ballot. Lloyd would like to see that by May.
- first driver to ballot is a completed significant step on spec validating a complete review of the whole spec. Lloyd anticipates this will be needed at least once more before going normative
- second driver to ballot would be users dependent on a resource or enhancement to resource - Brian suggests such a ballot would be eligible for a US Realm ballot. Lloyd would not want a US Realm resource, but a US Realm profile would be appropriate. They might develop it externally not as part of the FHIR specification, and if it is worthy can bring it back into HL7 for consideration. In this case you want to constrain comment to the incremental content. Infrastructure components and the set of schemas may provide the example where use of specific releases of resources have different infrastructure components. There will not be resources with version numbers, but whole DSTU release versions. John notes an example using digital signatures that could be invalidated by a future release.
- third driver is the need to provide people the opportunity to comment on changes made post ballot included in publication
- Next ballot for 2015Jan, publish in May, etc. is the current plan.
- MnM will be working on additional QA requirements and methodology guidelines this week and hope to have them by end of February - and Lloyd will reiterate the proposed timeline at tonight's cochairs meeting
- Additional QA criteria/requirements
- Hosting DSTU and managing changes
Next Steps
Actions (Include Owner, Action Item, and due date) | |||
Next Meeting/Preliminary Agenda Items
|
Back to FHIR_Management_Group
© 2014 Health Level Seven® International