SDPi Actor Renaming Evaluation (from DCC discussion)

[ToddCooper]

Section Number

TF-0 Appendix A: Actors + TF-1 profile actor sections, figures and tables.

Priority

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

Issue

IHE DCC review of the SDPi 1.0 Public Comment draft on 2023.03.28 included the question of whether inclusion of "SOMDS" or "BICEPS" in the actor names was too profile-specific, included profile tech content in an intentionally generalized actor name and thus they should be generalized with the differentiation being assigned when they are used in a specific profile. In other words, when they are realized as an "AIPO" tuple.

See the attached Word document that captures comments / considerations from Kevin O'Donnell. SDPi-Suggestions-20230326 KOD1 THC2.docx

Proposed Change

The results of the DCC review on 2023.03.28 was to update the descriptions - making them much simpler and clearer - but to defer consideration and finalization of any actor renaming until after publication of the Trial Implementation version. Primarily due to the need to have the TI published and announced and demonstrated at the HIMSS'23 Interoperability Showcase mid-April (in a couple weeks).

To advance this discussion, the following resolution actions are proposed:

1. Establish a preferred set of names for the actors being considered (See the attached document for a starting point)
2. Determine the value propositions & "costs" for keeping the names as they are defined in SDPi 1.0
3. Determine the value propositions & "costs" for renaming the actors per the table in (1)
4. Evaluate the impact of changing the actor names across the specification & implementation ecosystem TODAY (assuming the changes could be implemented relatively soon.

See Kevin O'Donnell's proposals and comments in ... SDPi-Suggestions-20230326 KOD1 THC2.docx

[ToddCooper]

Factor in:

1. IHE "AIPO" tuples (Actor + Integration Profile + Profile Options)
2. Question: Is this analogous to the original FHIR 80/20 Rule ... which it "out grew"? Is AIPO out-of-date?

[ToddCooper]

From the 2023.06.01 CA & Tooling discussion ... per the question #'s above:

1. Preferred Names?

   • Not directly discussed; will address on the SDPi Friday call 02.06.2023

2. Value for keeping the same?

   • Names are understood by implementation community + correlate with underlying SDC_ terms ... but not tech specific
   • We are used to them ... they are what they are because they made sense ... so need a pretty good reason to change now!
   • Clearly differentiated from other Actors in the TF-0 Appendix A Actors list + grouped together as related

3. Value for changing?

   • To meet the unwritten (?) actor naming guidelines for generic terms (though these are in conflict with existing actors like Provider)
   • Perhaps be more aligned with The IHE Way (though as noted above, this could be very anachronistic at this point)

4. Impact?

   • Impact NOW is minimal: maybe 1/2 day editorial changes in the AsciiDoc source, DEV.SDPi wiki changes
   • Impact WILL BE significant after requirements are loaded (via the generated JSON file) into a requirements management tool such as DOORS

Question: Why prefer one over the other?

1. Will it impact general understanding of those who are familiar with IHE specifications and thus adoption?
   • For the SDC/SDPi+FHIR team, a part of the issue is that we are so much into the standards & implementations that we have a hard time understanding the value and broader community impact on ADOPTION with either of the actor naming options
   • This group had no strong feeling one way or the other ... but need to decide NOW and not after these names are baked into product implementation (tooling, software, document
   • Note: At DCC meeting, @MartinKasp strongly advocated for keeping them as they are.

Next Steps: Evaluate "options" & close issue on SDPi Friday call 01.06.2023.

[ToddCooper]

From the 2023.06.02 SDPi Friday discussion:

1. Group reviewed the notes from the 1 June meeting (see details in previous comment)
2. DCC Governance - "Gentlemen's Agreement" to be a good IHE citizen / domain neighbor; in other words, there is no formal "veto" power BUT we should seriously and honestly consider all feedback from the leadership group
3. Discussion (see participants from linked notes above):

• Group spent considerable time honestly looking at the alternatives and weighing the value of changing / not changing & impact (who has to do what ... and for what benefit)
• This included the suggestions from Kevin's document (see attached) as well as other alternatives, including greater simplifications
• Group looked up current IHE TF General Introduction content both in the main sections around Actors & Transactions + the Appendix A Actor browsing (via the GMM). This proved to be somewhat of a mixed bag of examples + terms like "Provider" or "Service Provider" were so generic and in some cases confusingly so.
• Alternatives like Medical Device Service Provider (and other variations) provided little additional value (if any) over a simple SOMDS architectural contextualization of the actor
• Even chances from SOMDS ACM Gateway to ACM Gateway or simply Gateway was seen as negatively impacting understandability and thus adoption & use of the specifications
• After discussion of all the various alternatives and rationales, it was decided that this simplification to more generic actor names is not helpful and actually negatively impacts understanding, adoption and implementation of the actor implementations. In other words, the COST to change is reduced understanding of these actors and their use in profiles

DECISION: Keep actor names as published in SDPi 1.0.

[ToddCooper]

Reopening issue per discussion in the SDPi Friday 2023.06.23 meeting

[ToddCooper]

Discussion Notes from SDPi Friday 2023.06.23 Meeting:

After yet another review of the topic, the group agreed that the actor names could be made more "user friendly" - user being those in healthcare IT who will be reviewing and acquiring products implementing the SDPi specifications. Specific plans include:

1. Remove "SOMDS" and consider spelling out alternatives, for example:

• Device Content Creator / Consumer
• Device Service Provider / Consumer
• Medical Device Alert Gateway

2. To simplify "gateway" actors, one alternative might be to include Device Service Gateway or Device Alert Gateway and then utilize actor OPTIONS to indicate whether it is FHIR or ACM or DEC etc. Thus the profiles would have a single "gateway" actor between the SOMDS / SDPi ecosystem and the rest of the world
3. Consider reducing the number of actors - to reduce complexity, though not necessary

@ToddCooper will prepare a proposal for the Lübeck Workshop in July, with updates / finalization planned for release 1.2.

[kenjfuchs]

We should be consistent concerning whether we use "Device" or "Medical Device". It was never an issue for the DEC profile where we have DOR and DOC and not MDOR and MDOC. Personally I have no preference.

…

On Fri, Jun 23, 2023 at 11:21 AM ToddCooper ***@***.***> wrote: Discussion Notes from SDPi Friday 2023.06.23 Meeting <https://confluence.hl7.org/display/GP/Gemini+2023-06-23+SDPi+Friday>: After yet another review of the topic, the group agreed that the actor names could be made more "user friendly" - user being those in healthcare IT who will be reviewing and acquiring products implementing the SDPi specifications. Specific plans include: 1. Remove "SOMDS" and consider spelling out alternatives, for example: - Device Content Creator / Consumer - Device Service Provider / Consumer - Medical Device Alert Gateway 1. To simplify "gateway" actors, one alternative might be to include Device Service Gateway or Device Alert Gateway and then utilize actor OPTIONS to indicate whether it is FHIR or ACM or DEC etc. Thus the profiles would have a single "gateway" actor between the SOMDS / SDPi ecosystem and the rest of the world 2. Consider reducing the number of actors - to reduce complexity, though not necessary @ToddCooper <https://github.com/ToddCooper> will prepare a proposal for the Lübeck Workshop in July, with updates / finalization planned for release 1.2. — Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARWCJB3CWIWYJC5WNYQUN73XMWYAVANCNFSM6AAAAAAWK4CZDQ> . You are receiving this because you were assigned.Message ID: <IHE/DEV. ***@***.***>

[ToddCooper]

We should be consistent concerning whether we use "Device" or "Medical Device". It was never an issue for the DEC profile where we have DOR and DOC and not MDOR and MDOC. Personally I have no preference.
…
On Fri, Jun 23, 2023 at 11:21 AM ToddCooper @.> wrote: Discussion Notes from SDPi Friday 2023.06.23 Meeting https://confluence.hl7.org/display/GP/Gemini+2023-06-23+SDPi+Friday: After yet another review of the topic, the group agreed that the actor names could be made more "user friendly" - user being those in healthcare IT who will be reviewing and acquiring products implementing the SDPi specifications. Specific plans include: 1. Remove "SOMDS" and consider spelling out alternatives, for example: - Device Content Creator / Consumer - Device Service Provider / Consumer - Medical Device Alert Gateway 1. To simplify "gateway" actors, one alternative might be to include Device Service Gateway or Device Alert Gateway and then utilize actor OPTIONS to indicate whether it is FHIR or ACM or DEC etc. Thus the profiles would have a single "gateway" actor between the SOMDS / SDPi ecosystem and the rest of the world 2. Consider reducing the number of actors - to reduce complexity, though not necessary @ToddCooper https://github.com/ToddCooper will prepare a proposal for the Lübeck Workshop in July, with updates / finalization planned for release 1.2. — Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARWCJB3CWIWYJC5WNYQUN73XMWYAVANCNFSM6AAAAAAWK4CZDQ . You are receiving this because you were assigned.Message ID: <IHE/DEV. @.>

I agree, but along the lines of how simple we should get - keeping "Device" has value (e.g., Device Alert Provider or Device Alert Service Provider) since if we just say Alert Source or Alert Provider etc. there is all sorts of confusion as to the differentiation between general clinical alerts (your lab result is ready, or Mr. Fuchs is waiting in Room 3B).

And personally I like keeping "Service" in the name vs. reusing something like "Observation" because generally speaking, we mean more than devices saying what data they have.

I'd be OK with dropping the "Medical" part of the actor names but keeping that on the transaction names, since the PKP requirements will mostly be attached to transactions.

QUESTION: What about leveraging "actor names" in the use case descriptions? Currently those are written with generic actors and then we correlate them as appropriate in the profile specific use case sections.

[ToddCooper]

See notes from Developer's Workshop 2023.07.18 (Tuesday)