FHIR Infrastructure Minutes CC 20180917

FHIR Infrastructure Conference Call 3:00PM Eastern Time (Date above)

Return to FHIR Infrastructure Minutes

Agenda

• Approve Minutes Prior Meeting on 09/10

Attendees

• Lloyd McKenzie (chair/scribe)
• Grahame Grieve
• Rick Geimer
• Brett Marquard
• Joe Lamy
• Rob Hausam
• Yunwei Wang

Joined late

• Sean McIlvenna
• Ewout Kramer
• Bryn Rhodes
• Pegeen Ladeau

Minutes approval

• Motion to approve Minutes Prior Meeting on 09/10 - Rick/Grahame: 6-0-0

Implementation Guides

Sean, Ewout, Bryn, Pegeen join ===ImplementationGuide changes:

• ImplementationGuides should support declaring multiple FHIR versions and point to artifacts that apply to different versions of FHIR. Publication tooling should support multiple versions of IGs
  • ImplementationGuides that span versions will share a lot of content (value sets, narrative, capability statements, etc.)
• ImplementationGuide.fhirVersion -> 0..* and update definition to be clear that it's what the ImplementationGuide targets
• Business rule that ImplementationGuide.fhirVersion maxOccurs =1 if ImplementationGuide.manifest is present
• Add ImplementationGuide.definition.resource.fhirVersion 0..* - indicates the FHIR Version(s) this artifact is intended to apply to. Invariant that this element can't contain any FHIRVersion not present in ImplementationGuide.fhirVersion. Also have a business rule that this cannot conflict with the StructureDefinition.fhirVersion

Add an extension to StructureDefinition to indicate past versions the StructureDefinition also applies to

• Grahame will ballot that we need to rename ImplementationGuide.definition.package to avoid confusion w/ NPM packages
• Will add a usage note that it is possible to have an IG that declares one version that imports an IG that declares an older version. It is up to the importing IG to determine whether it's safe/appropriate to reference the older resources from the new IG.

Added as [18050]

ImplementationGuide packages

Alternative #1:

---

hl7.fhir.example <-- matches canonical URL

• no resources
• dependences on .r2, .r3, rX
• no resources

hl7.fhir.example.r2

• dependencies on hl7.fhir.core#1.0.2 + hl7.fhir.example.rX
• r2 specific content (includes the IG resource)

hl7.fhir.example.r3

• dependencies on hl7.fhir.core#3.0.1 + hl7.fhir.example.rX
• r3 specific content (includes the IG resource)

hl7.fhir.example.rX

• dependency on hl7.fhir.core#1.0.2 + hl7.fhir.core#3.0.1
• content that applies to both versions in 3.0.1 format (must be the same)

Alternative #2:

---

hl7.fhir.example

• dependencies on hl7.fhir.core#1.0.2 + hl7.fhir.core#3.0.1
• \package - content that applies to both versions in r3 format (must be the same) <-- package.json in there
• \r2 - r2 specific content in r2
• \r3 - r3 specific content in r3

Alternative #3:

---

hl7.fhir.example

• dependencies on hl7.fhir.core#1.0.2 + hl7.fhir.core#3.0.1
• \package - content that applies to both versions in r3 format (must be the same) <-- package.json in there
• \r2 - r2 specific content in r2 (includes the IG resource)
• \r3 - r3 specific content in r3 (includes the IG resource)

hl7.fhir.example.r2

• dependencies on hl7.fhir.org#1.0.2 + hl7.fhir.example.rX
• \package: r2 specific content + content that applies to both versions in 1.0.2 format (must be the same)

hl7.fhir.example.r3

• dependencies on hl7.fhir.org#3.0.1 + hl7.fhir.example.rX
• \package - r3 specific content + content that applies to both versions in 3.0.1 format (must be the same)

Alternative #4

---

hl7.fhir.example

• dependencies on hl7.fhir.example.r2 and hl7.fhir.example.r3
• \package - only package.json <-- package.json in there

hl7.fhir.example.r2

• dependencies on hl7.fhir.org#1.0.2
• \package: r2 specific content + content that applies to both versions in 1.0.2 format (must be the same)

hl7.fhir.example.r3

• dependencies on hl7.fhir.org#3.0.1
• \package - r3 specific content + content that applies to both versions in 3.0.1 format (must be the same)

Version of IG for authoring

Grahame commits to writing the IG conversion code to support converting ImplementationGuide to and from

Pre-processing

Use-cases for pre-processing as part of publication:

• inject resources into the "pages" list for generating ToC, breadcrumbs and manifest (Grahame will add a way to do that)
• incorporate "common" parameters into the IG (e.g. file folders, what artifacts to generate, etc.). Grahame will document how this is done.
• differentiate what pages get generated for different "types" of StructureDefinitions - Move discussion to Zulip

There will be a call next week. Grahame will not join.

Adjournment

17:16 Eastern