Open ToddCooper opened 1 year ago
Factor in:
From the 2023.06.01 CA & Tooling discussion ... per the question #'s above:
Preferred Names?
Value for keeping the same?
Value for changing?
Impact?
Question: Why prefer one over the other?
Next Steps: Evaluate "options" & close issue on SDPi Friday call 01.06.2023.
From the 2023.06.02 SDPi Friday discussion:
DECISION: Keep actor names as published in SDPi 1.0.
Reopening issue per discussion in the SDPi Friday 2023.06.23 meeting
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:
@ToddCooper will prepare a proposal for the Lübeck Workshop in July, with updates / finalization planned for release 1.2.
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:
Remove "SOMDS" and consider spelling out alternatives, for example:
- Device Content Creator / Consumer
- Device Service Provider / Consumer
- Medical Device Alert Gateway
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
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 https://github.com/IHE/DEV.SDPi/issues/110#issuecomment-1604437512, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARWCJB3CWIWYJC5WNYQUN73XMWYAVANCNFSM6AAAAAAWK4CZDQ . You are receiving this because you were assigned.Message ID: <IHE/DEV. @.***>
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.
See notes from Developer's Workshop 2023.07.18 (Tuesday)
SDPi Friday 2024.07.26 -- As part of another issue for the SDPi-P Discovery Proxy Option and addition of a new Actor + transaction(s), Todd let Kevin O'Donnell know about the Gemini team discussion ... a year ago!
Still awaiting a response. It will be a topic of discussion in the August 2024 DCC meeting.
Section Number
TF-0 Appendix A: Actors + TF-1 profile actor sections, figures and tables.
Priority
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:
See Kevin O'Donnell's proposals and comments in ... SDPi-Suggestions-20230326 KOD1 THC2.docx