FHIR Infrastructure Minutes WGM 201805

From HL7Wiki
Jump to navigation Jump to search

FHIR Infrastructure 2018 May Cologne WGM Minutes

Return to FHIR Infrastructure Minutes

Agenda

Attendees

A comprehensive list for the WGM can be seen here: (TODO: extract from http://bit.ly/fhiri after WGM).

Monday Q1

Chair: Ewout Kramer

Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)


Tracker Items

Prepared MOTION for wed may 16 Q2: "Document the MIME-type parameter as a way to describe the version of the resource in the MIME package. Grahame Grieve/Chris Grenz: 37-0-0"

Straw poll about using "Meta.fhirVersion" versus using "Meta.profile": 8 in favor of "fhirVersion", about 18 for a <profile> based approach.

Below is the example we discussed:

  Content-type: application/fhir+xml;fhirVersion=3.0
  <Patient fhir-version="3.0" xmlns="hl7.org/fhir">
    <meta>
      <profile value="http://hl7.org/fhir/DSTU2/StructureDefinition/Patient" />
      <profile value="http://hl7.org/fhir/StructureDefinition/Patient%7C1.0" /> 
      <profile value="http://hl7.org/fhir/StructureDefinition/Patient%7C4.0" />
      <profile value="http://hl7.nz/fhir/StructureDefinition/OurNationalPatient%7C1.2.1" /> 
      <fhirVersion value="3.0" />
    </meta>
  </Patient>
  {
   "resourceType" : "Patient",
   "fhir-version" : "3.0",
   "status"...
  }

Monday Q2

Chair: Ewout Kramer

Attendance sheet: http://bit.ly/fhiri (to be turned into a PDF after meeting)


Tracker Items

  • 16957 - Discussed whether GET and POST support should both be required on search
  • 16369 - Discussed semantics of "significant figure"-based equality operations when searching for decimal, integer, and quantity values



MOTION

We believe that it is important to support POST so that clients can manage their own security as required, and therefore we believe that it is important that servers continue to offer POST. Allowing servers to offer either GET or POST reduces interoperability.

Kevin Shekleton/Joshua Mandel: 27-0-0


MOTION

  • We will document the naming rule, so going forward, the search parameters will be consistent. We will also look at the less mature resources to align parameter names to the naming rule when still possible.
  • Due to the fact that a) this change has big consequences for existing implementations this late in the process, b) only the system parameters (starting with underscore) have a different naming pattern, which though not optimal is not enough to warrant breaking the existing implementations
  • We need to describe that we use "sensible casing": not have two search parameters that only differ by case - so the difference does not really matter.

Christiaan Knaap/Joshua Mandel: 26-0-1