Antitrust Statement

Professional Associations, such as HL7, which bring together competing entities are subject to strict 
scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote 
fairness in competition and, as such, supports laws against monopoly and restraints of trade and their 
enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is 
responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of 
the Governance and Operations Manual (GOM).

Agenda

Attendees

Lloyd McKenzie

Frank McKinney
Neelima Karipineni
Josh Mandel
XFred Dennis
Oliver Egger
Rick GeimerXFred Marsh
Patrick Murta

Yunwei Wang

XGino CanessaXPaul ChurchX
Alberto S Llanes
Grahame GrieveXPaul Denning
Alex Goel
Jeff Brown
Reece Adamson
Alex Kontur
Jeffrey Danford
Rachel E FoersterX
Alexander ZautkeXJeff Helman
Reece Adamson
Bas van den HeuvelXJohn Conley
Ricardo Quintano
Brett Marquard
John Moehrke
Richard EttemaX
Brian PhinneyXJoseph LamyxRob HausamX
Brianna Mathiowetz
Josh Bagley
Robin Poirier
Bryn Rhodes
Keith Carlson
Ruby NashX
Carl Anderson
Kenneth MyhraXRyan Moehrke
Chandrakant Bhoslay
Kyle BinnsXSid Bhatt
Chris Shawn
Marco Visser
Vadim Peretokin
Christiaan Knaap
Mark KramerXVassil PeytchevX
Cooper Thompson
Marten Smits
Ward Weistra
Daniel Gottlieb
Mary Winter
Wes Barker
Didi Davis
Melisa CokerXWilliam Zack
Eric Daley
Michael Abensur
Xiaomin Xu
Eric HaasXMichael Donnelly


Eric Heflin
Michelle Barry


Ewout Kramer
Mohammad Jaffari








Christopher BrancatoX



Minutes Approval

Tracker Items

FHIR-31964 - Getting issue details... STATUS

  • Persuasive with Mod
  • Motion: Grahame Grieve/Rick Geimer: 17-0-0

FHIR-33945 - Getting issue details... STATUS

https://jira.hl7.org/browse/FHIR-33945 – extensive discussion captured in Proposal; will revisit next week


FHIR-34060 - Getting issue details... STATUS

The ability to generate search results early or late in a transaction (depending on POST vs GET) is not a desired feature. Today, Grahame's implementation and also Firely server handle GET and POST differently.


For operations, it's even harder to come up with consistent rules, since some operations are more like reads, and others are more like writes.

Grahame: maybe we should ban POST-based search in transactions, since the use cases for POST-bases search (e.g., logging of query params) don't apply when wrapped in a bundle. Meanwhile, operations cross boundaries; they're not necessarily just "about" a single resource, so rules like "If any resource identities (including resolved identities from conditional update/delete) overlap in steps 1-3, then the transaction SHALL fail." don't really fit.

Bas: consider three creates (one for Patient, then Encounter, then Procedure), with references across them. For the references to work out, the order matters.

Grahame: this is supported today, using resolution within the transaction request Bundle.

Bas: we already have examples today when the order of execution does matter – e.g., multiple "creates" and an Operation that reads them

Do any clients depend on this behavior? Hard to know, but we can ask whether clients are OK if we   Josh Mandel 

  1. prohibit (or recommend against) POST-based search in transaction Bundles

Graham: The key point here is that "The outcome of processing the transaction SHALL NOT depend on the order of the resources in the transaction."

Gino Canessa  will raise the question to zulip




Publication Request for FSH

Motion: FHIR-I approves moving ahead the the publication step for FHIR Shorthand

Mark Kramer / Gino Canessa

Motion passes: 18-0-0


Adjournment

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date