Refactor SDPi Specification to be a Standalone Standard

[ToddCooper]

Section Number

Entire document

Priority

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Issue

During the publication of the Gemini SDPi standard in HL7 (see HL7-IHE Gemini Standard: Service-oriented Device Point-of-care Interoperability (SDPi) Technical Framework, Edition 1), there was a desire to make the standard more "standalone" vs. an IHE TF supplement that will eventually go away and be integrated into the IHE DEV TF. This refactoring of the current specification should not require any technical content changes, only editorial, and it should keep the same IHE TF organization (e.g., Vol 1 - 3, actors, profiles, etc.). It should also be easily integratable into the IHE DEV TF as well as accessible on the HL7 space, similar to HL7 FHIR publication.

Proposed Change

Identify the best approach for keeping the current technical content unchanged, but making it integratable into the IHE DEV TF, as well as standalone on the HL7 side. Once agreed by the Gemini MDI team, then update the structure of the document and take it through the IHE and HL7 approval processes.

NOTE: Intent is to have this ready for the May and September HL7 ballot cycles. The current HL7 SDPi Edition 1 STU needs to be updated to Edition 2 by the end of 2026.

[JavierEspina]

2026.01.16 SDPi Call:

• Should be discussed at DEV WGM sessions on Jan 27-29.

• May entail separating some parts into separate document(s)

• We may need to include someone form HL7's TSC.

[JavierEspina]

SDPi Call - 2026.02.13:
next step is to make a slide-deck proposal of the changes to send to Aaron Goldmuntz and Dan Vreeman for review (before drafting a PR here).

[ToddCooper]

@JavierEspina -

1. Aaron & Dan meeting being set up for the HIMSS'26 conference in Las Vegas the week of 8 March to get an "Yes, that works" from both
2. Proposal: Separate out the Standalone SDPi Standard from the SDPi Supplement .. in the same repo ... the "Supplement" will be organized like any supplement, with a rubric for how to integrate SDPi Standalone into the DEV TF (via section allocation and content references) and an introduction that spells out this journey.

This last part may be a challenge: How do we make Supplement references (e.g., to TF-1.12) in one document to the other document? Might be a good question for the IHE DEV AsciiDoc team!

[ToddCooper]

2026.03.11 @ Las Vegas / HIMSS --
Todd explained the approach for "Standalone SDPi" to the Gemini Steering Committee (Aaron Goldmuntz, Jürgen Brandstätter, Dan Vreeman & Diego Kaminker) and received confirmation that this was an excellent approach and that having an initial approach for the May ballot cycle would be perfect. Dan V. pointed out that this hit 3 of the 4 issues from the HL7 TSC, the 4th being "Why AsciiDoc and not IG Publisher?". There is no problem with our approach, but Dan needs a rationale to give to those few voices who think that everything HL7-related should be published using that tool.

[JavierEspina]

2026.03.11 @ Las Vegas / HIMSS -- Todd explained the approach for "Standalone SDPi" to the Gemini Steering Committee (Aaron Goldmuntz, Jürgen Brandstätter, Dan Vreeman & Diego Kaminker) and received confirmation that this was an excellent approach and that having an initial approach for the May ballot cycle would be perfect. Dan V. pointed out that this hit 3 of the 4 issues from the HL7 TSC, the 4th being "Why AsciiDoc and not IG Publisher?". There is no problem with our approach, but Dan needs a rationale to give to those few voices who think that everything HL7-related should be published using that tool.

Let's discuss it after HIMSS, latest on the next SDPi call on March 20, and see if we still have the time to apply it for SDPi 2,4 (scheduled for March 27)... hmmm 🤔 maybe we should discuss before the 20th...