20130923 FMG WGM meeting

HL7 TSC FMG Meeting Minutes Location:		Date: 2013-09-23 Time: 9
Chair:		Note taker(s): Brian

Quorum = chair + 4			yes/no
Co chairs	regrets	Hugh Glover	x	Lloyd McKenzie
ex-officio	x	Ron Parker, FGB Chair	.	John Quinn, CTO

Members		Members		Observers/Guests
x	Lorraine Constable		John Moehrke	x	Patrick Loyd
x	Jean Duteau	x	Brian Pech
regrets	David Hay	x	Woody Beeler, FGB
x	Paul Knapp	x	Josh Mandel
x	Grahame Grieve, FGB	x	Ewout Kramer, FGB

Agenda

• Roll Call - Joint FMG/FGB
  • Welcome new members?
  • Governance/policy-related ballot issues
  • Criteria for requiring second ballot
  • Release plans - specifically how to manage a 60 day connectathon freeze in parallel with DSTU ballot/publication
  • Metrics during DSTU
  • External project engagement: HData, vMR, Clinical genomics, Structured data capture

    how do we track and manage "projects" that may impact resourcing needs

  • Moving forward on precepts

FMG session

• liaison responsibilities
• ballot prioritization
• 12:00 - Connectathon planning

Minutes

Introductions; agenda review: agreed on agenda from wiki.

Governance/policy-related ballot issues

Comment 72 from ARB:

• "Governance and methodology shouldn't be interspersed." May want to separate extensions, terminology, profiles etc. from the main implementer-facing FHIR docs. Grahame: "We need a separate document with all these things. We can't put this off to a distant future problem because conversations with governments +vendors are happening now. We also need a council to manage relationships with CIOs, CEOs, creating a formal structure for those people to provide corporate- and national-level feedback that FHIR can take into account. So that's two things we need."
• Brian: Ron, is there overlap with "BAM Lite" (first three stages of business architecture: opportunity recognition and onboarding of new project)?
• Ron: Yes, and HL7 governance needs to take that into account. Mostly an external non-HL7 audience.
• Woody: That means we need more than HL7 internal-facing documentation.
• Lloyd: We need to cover not internal HL7 processes, but things that are relevant to external orgs.
• Lorraine: Yes, and anything that external orgs need to consider.
• Woody: And to point out this is still just a DSTU.
• Hugh: I can't quite make out what everyone's saying.
• Lorraine: IS this a task for FGB or FMG?
• Ron: Both need a role. FGB is prepared to own it, but will assign sections to FMG.
• Lloyd: Any volunteers to lead on drafting a TOC?
• Ron, Grahame, Brian: Yes, us.
• Ron: And Ewout can lead the FMG orientation.
• Lloyd: motion to accept this proposal (need restatement of the motion/proposal)
• Lorraine: Seconds.
• Paul: This resolution is important but doesn't address the point of #72. Can we ask back about what areas are specifically unclear?
• Lloyd: We asked ARB already, which led to our current proposed resolution.
• Ron: It's better to have a separate contextualizing piece, an addendum to the spec, and then apply that to the specification.
• Lorraine: Friendly amendment to ensure the document addresses methodology, management, and governance.
• Vote: No objections or extensions; Resolution passes.

Comment 84:

• Grahame summarizes: FHIR's family history resource was defined by a GP for common outpatient use. It's not clear how this might relate to a full clinical genomic family history. This ballot comment correctly states, "FHIR's Family history doesn't align with HL7's Pedigree model." Which is true…
• At the same time, a group at Harvard is proposing a set of operational genomics resources, which still need work. They may be related too.
• Woody: I also believe the Pedigree model is now in an ISO standardization process. There was also an email claiming that the clinical genomics model contained genomics data, and I don't know whether that's true, or whether it's more of a clinical assessment. I thought the current CG workgroup pedigree spec was more or less clinical. Is that right?
• Brian: Initially CG didn't want to engage with FHIR's modeling group. And then we engaged with someone more peripheral in CG.
• Woody: But could we do a resource that summarizes ("my dad died of X") at the family practice level, and also is more rigorous?
• Lloyd: Several options. Option A) I'm thinking full genetic family profile is essentially a regular family history plus additional data (generic info on each ancestor + specific relationship). Other detail ("dad died of lymphoma") is the same info you'd capture in a regular GP family history. And the gap could be managed with extension. Option B) We provide parallel resources, one for general GP and another for more complex/sophisticated histories.
• Paul: are the concepts in fact different?
• Grahame: this is more of a coordination issue. When we ask CG's input, we need to see a proposed resource from them in order to consider.
• Lloyd: CG's perspective is "we created our Pedigree model in V3; everyone should use that." There has been CDA work which is incompletely aligned to Pedigree; CG doesn't like that. Any FHIR resources won't be exactly aligned; even if the gap could be closed with a profile, CG is concerned that it's still >1 way to do it
• Patrick: This problem happens broadly in HL7, e.g. for labs where a summary is good enough for public health but more detail is required in other use cases. So the issue of needing different views of the same data (at different granularity) is a real problem happening elsewhere.
• Paul: And it's not just the case that one is a trivialized case of the other.
• Patrick: Right. I like Lloyd's Option A.
• Josh: Why extensions, and not real properties?
• Lloyd: We'll need to understand which elements are part of core (80% of systems supporting).
• Brian: Feels like 2 different use cases.
• Grahame: Right, and 2 use cases like this is a challenge to the 80% argument. Seems wrong to say that Pedigree is a huge bag of extensions.
• Lloyd: benefit to having a single resource is that a general GP system could at least understand part of the full genetic workup (because it would already know how to use that model). If it's a partitioned, independent resource, we don't get that behavior.
• Grahame: But if you make that choice, you need to say the 80% argument modulates.
• Lloyd: No, I think SNPs would still be extensions in general, even if geneticists treat them as core. I think from FHIR Management perspective, we could tell CG: "If you don't like the current FamilyHistory, please create a new resource or modify FamilyHistory, based on a '80% of systems that do genetics' perspective." If they produce that, we'll have a basis for making a decision.
• Brian: But then we're back to design by constraint; they'll produce a model with everything.
• Woody: Is the gap a simple filter that could be applied to the complex resource? A profile? Or are they totally different?
• Lorraine: Challenge for a Family History resource that follows CG; unclear how Harvard contributions relate.
• Lloyd: the Harvard group needs to work through genetics; their contributions will need significant refactoring no matter what. It's unclear whether we need two resources, or a profile on one. We need to see the resources and the use cases, and assess.
• Lorraine: What if CG doesn't want to do that?
• Lloyd: If CG is not willing to do that work, then we have the power to find someone else.
• Woody: There is now a community of internists who are doing fairly sophisticated work involving detailed family history to make diagnoses. If you can't handle these use cases, then I'd question the utility.
• Lloyd: we can capture diagnoses, but not arbitrary observations, on family members.
• Woody: But damn it we should have a richer model that doesn't rely on extensions.
• Paul: We need structured data.
• Woody: there's no history here, just a list of family members and conditions.
• LLoyd: there's use cases for simple, for intermediate, and for full-blown genetic profiles. Currently CG is not happy with the status quo, and our challenge is to get them to do more than say "we don't like it," and instead provide us something we can move foward with.
• Lorraine: Right. First step is to CG to draft an alternative proposal.
• Ron: We need a group to come forward with a clear narrative on what their requirement is. This is an emerging problem/pattern. We probably need a narrative to start, since CG is not equipped to start building resources yet.
• Woody: why use a dumbed down condition for family members' conditions? Why not use the regular FHIR condition resource?
• Ron: This proposal allows us to render a family history, but it might be post-factored from a patient's report.
• Lorraine: Let's get back to our ballot comment response.
• Woody: But I want to propose we call the current Family History something else. Maybe "family history summary," or something else that won't imply it's suppose to handle more sophisticated use cases.
• Grahame: this is a domain problem; we can't solve it ourselves.
• Ron: Okay, so let's work with CG to develop a candidate resource.
• Paul: and at the same time let's recognize this problem applies not just to CG, but to other domains that define things called "histories." Collecting their rationales could help us work through a nomenclature issue.
• Ron: This is an interesting idiosyncrasy.
• Lloyd: is the proposed summary in spreadsheet now acceptable?
• Paul: I see CG is persuasively stating that FHIR's FH model is not, in fact, "vetted all the way down."
• Lloyd: I think it's still possible there should be alignment. Can we ask CG to "examine alignment"?
• Grahame: We still need to define whether this comment holds up the DSTU. We should say that this won't block DSTU, but can happen afterwards.
• Ron: I think we need to give CG a nod and explain that we understand the gap, and will proceed with a plan of building resources, opening dialog, and determining whether we need one resource or two.
• Paul: They shouldn't need to actually create a resource definition to prove their case. We can have this discussion at the logical level, without spreadsheets. Discuss with CG that there are different use cases: a GP's "family history" vs. CG's notion of family history.
• Paul: Suggest changing the proposal so we don't say "Request them to develop a candidate resource." And explain that FHIR's current Family History was harvested from the conept of a GP family history, not invented de novo.
• Brian: We're talking at the GP level, as opposed to an academic medical center.
• Patrick: We're getting caught up with the details of the issue; we need to get a handle on the bigger issues of granularity, overlapping use cases, specializations of models…
• Woody: And we still haven't made it clear what the scope of Family History is. We never stated the scope in the resource definition.
• Lorraine: We have general questions on the table here, and we need a specific resolution, and we also need to get through other agenda items.
• Ewout: Let's finish wording the current proposed response.
• Lorraine: We should also clarify our process for mapping back to RIM, ontology. We haven't done it yet and we need to.
• Ewout: Three issues: need to respond about the resource; about its ties to ontology; and the broader issue.
• Lloyd: How about this proposed language to address ontology approach?
• Woody: We need to clarify that this resource is not the only place in FHIR where you can record "family history."
• Lloyd: Every resource has a scope; we need to decide when to broader/constrain that scope. Our current leaning is towards a small number of broad resources when possible.
• Paul: So what committee owns FHIR's "Family History."
• Lloyd: currently, FHIR core. with interest from CG and patient care.
• Paul: So this is a problem we'll face any time we as FHIR core takes on responsibility for a resource.
• Ewout: Time out. We have recognized the issues and we still need to produce a response. I think we've answered each of the points in #84.
• Lorraine: Move to accept as persuasive.
• Ewout seconds.
• Vote: Lloyd: No further discussion or objections. One abstention. Motion passes: 9/0/1.

Lorraine: Getting scope and boundary conversations across-committees is still one of the big tasks we need to mature the standard. We may just need a few point calls between committees, but this conversation needs to happen. "Your resource does x, mine does y, how do they work together?"

• Paul: I don't know whether FMG+FGB is diverse enough to handle those discussions. They're going to be domain-level discussions.
• Lloyd: I'm sensing differences here.
• Grahame: Let's push forward on the agenda.

Release plans

60 day connectathon freeze in parallel with DSTU ballot/publication
LLoyd: we'll discuss a second ballot Friday, when we'll need to decide. But we can postpone discussion to Q2. Regarding release plans + freeze for Australian connectathon, Grahame, do you want it to be based on the version of FHIR from today?

• Grahame: Yes, since it's in four weeks.
• Lloyd: When we make changes over the next month, do we need to publish them too?
• Lorraine: We'll always need to deal with hosting multiple documents. Branching and releasing will always be a problem.
• Lloyd: do we need to host frozen + current changes at the same time?
• Woody: does HQ consider this a problem?
• Lorraine: FHIR's not unique in needing this.
• Grahame: though the FHIR publication process is unique, a two-step process that generates a local copy + HL7 copy that's reorganized into a directory structure with updated URLs, tracking code added, and packs them into an upload format that I upload directly to the web site.
• Lloyd: so, short term, we can keep the current version up through the Australian connectathon.
• Grahame: Yes. The point is that we can easily build and rebuild, but others aren't that comfortable with the build tools.
• Josh: why not just host the latest copy on an independent site with automatic updates?
• Grahame: that's possible; are you volunteering?
• Josh: I'm looking at the build process more generally and will whether this is doable.
• Grahame: I also host multiple forks: regional, connectathon, genomics stuff…
• Ewout: is it easier if we keep resource definitions somewhere else?
• Grahame: so we'll start updating the main site?
• Lloyd: no, we'll keep the main site frozen until we determine whether they're an alternate. Plan A) is we keep the main site frozen until the connectathon. If we do get an alternate site, we can decide which hosts the frozen and which hosts the latest.
• Ewout: We'll need to figure out details of managing forks.
• Lloyd: so we have a short-term plan.
• Grahame: No, there will be another period after the connectathon while ballot reconciliation is still happening. I don't see any prospect that we'll finish ballot rec before the 60-day freeze.
• Lloyd: So you think we'll still be doing with ballot reconciliation at end of November?
• Grahame: seems likely
• Lloyd: That may interfere with January ballot timing, given timing requirement of QA. We can choose to go to ballot with some content changes not yet applied, if focus is on getting feedback on a limited set of content. I think regardless we'll aim to have, by mid-November, the content we'd need to for second ballot (if we have one) + content for 5th connectathon in place, with recognition that behind-the-scenes changes will still be needed after that.

Next Steps

Actions (Include Owner, Action Item, and due date)

Next Meeting/Preliminary Agenda Items

Back to FHIR_Management_Group

© 2013 Health Level Seven® International