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

Difference between revisions of "20160803 FMG concall"

From HL7Wiki
Jump to navigation Jump to search
(Date 2015 to 2016)
 
Line 59: Line 59:
 
==Minutes==
 
==Minutes==
  
 +
Attending: Brian Pech, Brian Postlehwaite, John Moehrke, Josh Mandel, Lloyd
 +
McKenzie, Paul Knapp, Grahame Grieve.
 +
 +
Vote to approve agenda: Josh M / Brian Postlehwaite. All in favor.
 +
 +
Vote to accept minutes: Brian Pech / Postelhwaite. Abstaining, John, Josh.
 +
 +
Arriving: Grahame Grieve
 +
 +
Virtual connectathon on 8/12 will flesh out Provider Director scenarios for
 +
September WMG.
 +
 +
Grahame: I have taken IG maintenance (not publicaton) conversation to FGB.
 +
Still discussing what processes are required to allow maintenance on GitHub
 +
while HL7 retains full history.
 +
 +
==== Progress on ballot ====
 +
 +
Lloyd has been involved in IG work.  Grahame indicates he is involved in QA
 +
work on core, including broken links (now from 25k down to 1k), then to work on
 +
validating instances. One issue is that link checking was disabled to speed up
 +
the build.
 +
 +
Lloyd: 1 week to go before final freeze. Any concerns about getting everything
 +
ready?
 +
 +
Lloyd: SDC is taking longer than hoped.
 +
 +
Brian Pech: still working on numbers for September Connectathon attendance.
 +
 +
Lloyd: is "Consent" solid for ballot?
 +
 +
John: Yes.
 +
 +
Grahame: Getting IG infrastructure in place is an ongoing challenge. Still
 +
requires manual work on my end.
 +
 +
==== Workflow and Medication Orders ====
 +
 +
Lloyd: Request for Fulfillment is handled as a Task, so Medication Prescription
 +
represnts the authorization. There is a proposal to rename it to
 +
MedicationRequest, which encompasses prescritions, proposals, plans, encoded
 +
orders, MARs, with a code to distingish among them. Same is true for
 +
DiagnosticRequest, etc.
 +
 +
Josh: Are these details schedule to be in STU3?
 +
 +
Lloyd: These are changes intended to occur after ballot, given that the
 +
proposed patterns emerged late. Some workgroups including OO have applied the
 +
changes; but Pharmacy and Patient Care have not yet done so.
 +
 +
Paul: How will we get feedback from the community?
 +
 +
Lloyd: All of the relevant resources shoudl have text indicating that these
 +
will align with their expected patterns.
 +
 +
Josh: I'm not sure ballot participants will be able to understand what all of
 +
this means if they're asked to understand the "expected patterns" from abstract
 +
descriptions and no concrete details.  Could we add some text to
 +
MedicationOrder indicating what changes are anticipatd, specifically?
 +
 +
Lloyd: The pharmacy workgroup hasn't had time to do it, and we may not have
 +
time before 8/10. We could add an intro to ballot page that provides some
 +
context about this.
 +
 +
Grahame: OK. Lloyd, can you add this?
 +
 +
Lloyd: Yes, Grahame and I togther will figure it out.
 +
 +
==== DecisionSupportServiceModule ====
 +
 +
Arriving: Bryn Rhodes.
 +
 +
Bryn: I've been asked to address how DecisionSupportService Modules are
 +
different from operations generally. In general, our metadata is important for
 +
searching. Parameters and data requirements are a little different from
 +
OperationDefinitions. And we want to support common parameters for all
 +
services, with specific differences per-module.
 +
 +
Lloyd: Couldn't this be handled with profiles on OperationDefinition?
 +
 +
Bryn: Then we're back to using profiles and extensions to get this job done.
 +
We've tried profiles to describe the data we need, without success.
 +
 +
Lloyd: profiles on basic are painful, but what about on OperationDefinition?
 +
 +
Bryn: we have content in our modules represented using complex extensions that
 +
would be difficult to use. Things like "related resource", or "data
 +
requirement". If we could avoid complex extensions, this might be possible.
 +
But we still would have problem with common parameters across our modules.
 +
Currently we allow parameters to be defined on the module, or also within the
 +
Evaluate operation.
 +
 +
Grahame: It's not clear to me what "related resources" are. What if the module
 +
described more than just the operation, so it included information about what
 +
you're invoking, rather than just the process (e.g. what and why you're
 +
invoking)? Then the module could refer to an OperationDefinition while still
 +
defining the context for the invocation.
 +
 +
Lloyd: I'd still want to see Conformance describing these details.
 +
 +
Bryn: but we want to be able to turn modules on and off dynamically.
 +
 +
Grahame: I'm not sure that changes things. Some information in the
 +
ModuleDefinition are things that have come up in our Terminology Service. Some
 +
of these also look like DataRequirements and RelatedResources. So I think the
 +
scope of DecisionSupportServiceModule has a different scope from
 +
OperationDefinition, but there are definite questions about the design.
 +
 +
Lloyd: But we'd want to use OperationDefinition for the parts where it meets
 +
the scope, and other pieces that could be addressed by profiling OpDef, or
 +
multiple OpDefs, and it's worth exploring how those pieces relate to the
 +
general idea of a Service Definition.
 +
 +
Grahame: We don't need to approve this prior to ballot.
 +
 +
Lloyd: Correct. Just prior to publication if it's going to be non-draft.
 +
 +
Grahame: So let's table this, and work through Baltimore to further consider
 +
relationship between OpDef, DecisionSupportService, and these metadata. Then we
 +
can update the proposal.
 +
 +
Bryn: OK.
 +
 +
Lloyd: Great. We will review that in late September / early October.
 +
 +
Bryn: Can the resource still make it into STU3?
 +
 +
Lloyd: Yes.
 +
 +
Paul: Isn't designing or substantially modifying in September too late?
 +
 +
Lloyd: we can make substantial changes between ballot and publication. During
 +
the reconciliation timeframe we decide whether to publish or not, and what
 +
maturity levels. We evaluate changes that have occurred, and we can choose
 +
between re-balloting, accept the substantive changes and with the original
 +
maturity level, or publish without changes, or with a downgraded maturity
 +
level, or remove the content entirely.
 +
 +
 +
==== End of meeting ====
 +
 +
Lloyd: motions to adjourn?
 +
 +
Josh / Paul
  
 
===Next Steps===
 
===Next Steps===

Latest revision as of 21:08, 3 August 2016

HL7 TSC FMG Meeting Minutes

Location:
https://global.gotomeeting.com/join/279790597
(voice and screen)

Date: 2016-08-03
Time: 4:00 PM U.S. Eastern
Chair: Note taker(s): Anne W.
Quorum = chair + 4 yes/no
Co chairs David Hay Lloyd McKenzie
ex-officio Woody Beeler,
Dave Shaver
FGB Co-chairs		 . John Quinn, CTO
Members Members Members Observers/Guests
Hans Buitendijk Brian Postlethwaite Paul Knapp Anne W., scribe
Josh Mandel John Moehrke Brian Pech
Grahame Grieve .

Agenda

  • Roll Call
  • Agenda Check
  • Minutes from 20160727_FMG_concall
  • Administrative
    • Action items
      • Lloyd to update explanation on how to read the reports spreadsheet and see if he can get the emails to work properly; then send an email to the co-chairs to review/address the stale column
      • Brian Post to fill in scenarios on Provider Directories and Scheduling
      • Grahame to take issue of publication of IGs to FGB
  • Discussion Topics:
    • Progress on balllot
  • Reports
  • Process management
  • AOB (Any Other Business)

Minutes

Attending: Brian Pech, Brian Postlehwaite, John Moehrke, Josh Mandel, Lloyd McKenzie, Paul Knapp, Grahame Grieve.

Vote to approve agenda: Josh M / Brian Postlehwaite. All in favor.

Vote to accept minutes: Brian Pech / Postelhwaite. Abstaining, John, Josh.

Arriving: Grahame Grieve

Virtual connectathon on 8/12 will flesh out Provider Director scenarios for September WMG.

Grahame: I have taken IG maintenance (not publicaton) conversation to FGB. Still discussing what processes are required to allow maintenance on GitHub while HL7 retains full history.

Progress on ballot

Lloyd has been involved in IG work. Grahame indicates he is involved in QA work on core, including broken links (now from 25k down to 1k), then to work on validating instances. One issue is that link checking was disabled to speed up the build.

Lloyd: 1 week to go before final freeze. Any concerns about getting everything ready?

Lloyd: SDC is taking longer than hoped.

Brian Pech: still working on numbers for September Connectathon attendance.

Lloyd: is "Consent" solid for ballot?

John: Yes.

Grahame: Getting IG infrastructure in place is an ongoing challenge. Still requires manual work on my end.

Workflow and Medication Orders

Lloyd: Request for Fulfillment is handled as a Task, so Medication Prescription represnts the authorization. There is a proposal to rename it to MedicationRequest, which encompasses prescritions, proposals, plans, encoded orders, MARs, with a code to distingish among them. Same is true for DiagnosticRequest, etc.

Josh: Are these details schedule to be in STU3?

Lloyd: These are changes intended to occur after ballot, given that the proposed patterns emerged late. Some workgroups including OO have applied the changes; but Pharmacy and Patient Care have not yet done so.

Paul: How will we get feedback from the community?

Lloyd: All of the relevant resources shoudl have text indicating that these will align with their expected patterns.

Josh: I'm not sure ballot participants will be able to understand what all of this means if they're asked to understand the "expected patterns" from abstract descriptions and no concrete details. Could we add some text to MedicationOrder indicating what changes are anticipatd, specifically?

Lloyd: The pharmacy workgroup hasn't had time to do it, and we may not have time before 8/10. We could add an intro to ballot page that provides some context about this.

Grahame: OK. Lloyd, can you add this?

Lloyd: Yes, Grahame and I togther will figure it out.

DecisionSupportServiceModule

Arriving: Bryn Rhodes.

Bryn: I've been asked to address how DecisionSupportService Modules are different from operations generally. In general, our metadata is important for searching. Parameters and data requirements are a little different from OperationDefinitions. And we want to support common parameters for all services, with specific differences per-module.

Lloyd: Couldn't this be handled with profiles on OperationDefinition?

Bryn: Then we're back to using profiles and extensions to get this job done. We've tried profiles to describe the data we need, without success.

Lloyd: profiles on basic are painful, but what about on OperationDefinition?

Bryn: we have content in our modules represented using complex extensions that would be difficult to use. Things like "related resource", or "data requirement". If we could avoid complex extensions, this might be possible. But we still would have problem with common parameters across our modules. Currently we allow parameters to be defined on the module, or also within the Evaluate operation.

Grahame: It's not clear to me what "related resources" are. What if the module described more than just the operation, so it included information about what you're invoking, rather than just the process (e.g. what and why you're invoking)? Then the module could refer to an OperationDefinition while still defining the context for the invocation.

Lloyd: I'd still want to see Conformance describing these details.

Bryn: but we want to be able to turn modules on and off dynamically.

Grahame: I'm not sure that changes things. Some information in the ModuleDefinition are things that have come up in our Terminology Service. Some of these also look like DataRequirements and RelatedResources. So I think the scope of DecisionSupportServiceModule has a different scope from OperationDefinition, but there are definite questions about the design.

Lloyd: But we'd want to use OperationDefinition for the parts where it meets the scope, and other pieces that could be addressed by profiling OpDef, or multiple OpDefs, and it's worth exploring how those pieces relate to the general idea of a Service Definition.

Grahame: We don't need to approve this prior to ballot.

Lloyd: Correct. Just prior to publication if it's going to be non-draft.

Grahame: So let's table this, and work through Baltimore to further consider relationship between OpDef, DecisionSupportService, and these metadata. Then we can update the proposal.

Bryn: OK.

Lloyd: Great. We will review that in late September / early October.

Bryn: Can the resource still make it into STU3?

Lloyd: Yes.

Paul: Isn't designing or substantially modifying in September too late?

Lloyd: we can make substantial changes between ballot and publication. During the reconciliation timeframe we decide whether to publish or not, and what maturity levels. We evaluate changes that have occurred, and we can choose between re-balloting, accept the substantive changes and with the original maturity level, or publish without changes, or with a downgraded maturity level, or remove the content entirely.


End of meeting

Lloyd: motions to adjourn?

Josh / Paul

Next Steps

Actions (Include Owner, Action Item, and due date)
Next Meeting/Preliminary Agenda Items

20160810 FMG concall


Back to FHIR_Management_Group

© 2015 Health Level Seven® International

Retrieved from "https://wiki.hl7.org/w/index.php?title=20160803_FMG_concall&oldid=123833"