FHIR Chat · SMART Web Messaging - ballot comment reconciliation

Stream: smart

Topic: SMART Web Messaging - ballot comment reconciliation

Carl Anderson (Dec 09 2020 at 17:14):

Cross posting from FHIR-I
Following up from Monday's call - I've put together a sign-up form for future SMART Web Messaging ballot triage calls. Please sign up in you're interested in attending so I can pick a good time to meet.
https://docs.google.com/forms/d/179EGYzc3PBfYMPDJarF2078rIlGbX7S8VuzN4WaRINE/edit?usp=sharing

Carl Anderson (Dec 10 2020 at 18:05):

Err, I meant to send a link to fill out the form, not edit it. Ignore the link above - this is the one you want: https://forms.gle/g2kWwjBCR1sbfmjdA

Carl Anderson (Jan 06 2021 at 16:54):

FAYI - there will be a meeting on Friday to discuss some of the open ballot comments. X-post: https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Today's.20call/near/221791098

Carl Anderson (Feb 02 2021 at 21:45):

Re: Discussion on Handshakes

image.png

How does this look @Josh Mandel @Bas van den Heuvel @Matt Varghese for an example SVG to be included in the IG?

Matt Varghese (Feb 02 2021 at 21:49):

Why does scratchpad.create have a responseToMessageId value set? It's not a response..

Carl Anderson (Feb 02 2021 at 21:52):

Right - I don't remember addressing that in the discussion in the last meeting. I just used the messageId of the handshake response in the example.

Carl Anderson (Feb 02 2021 at 21:53):

Does it make more sense to set it or leave it unset? If we want to require a handshake be completed before each message, I can see an argument for requiring responseToMessageId for all messages except the initial handshake.

Carl Anderson (Feb 02 2021 at 21:54):

image.png
An example with uuids...

Carl Anderson (Feb 02 2021 at 22:16):

I could leave it unset for now, and then create a separate issue to discuss at the next call. If that makes the most sense.

Josh Mandel (Feb 02 2021 at 22:36):

In terms of flow, looks good! In terms of implied structure, the diagram makes me think that "status.handshake" will appear over the wire as a JSON key, which I don't think is right (should be a "messageType", sibling to "messageId")

Carl Anderson (Feb 02 2021 at 23:02):

@Josh Mandel - totally correct. I took some liberties with the diagram labels. But it would be essentially this:

targetWindow.postMessage({
  "messageId": "b72e6e52-1956-4353-ab5e-36129011f3ee",
  "messageType": "status.handshake",
  "payload": {
...
  }
}, targetOrigin);

A better way to put it into the diagram might be:

{
  "messageType": "status.handshake",
  "messageId": "b72e6e52-1956-4353-ab5e-36129011f3ee",
  "payload": {}
}

Carl Anderson (Feb 02 2021 at 23:04):

I'll fiddle. I've been reading through the options on sequencediagram.org.

Carl Anderson (Feb 02 2021 at 23:06):

What about the issue of setting the responseToMessageId for all messages that aren't handshake 'SYN' messages?

Carl Anderson (Feb 02 2021 at 23:41):

image.png
I think this is an improvement.

Matt Varghese (Feb 03 2021 at 02:17):

@Carl Anderson , responding to your question - I'm not saying each message should be preceded by a handshake. Rather that the app MUST handshake before using other messages. So in my opinion, the responseToMessageId referring to the handshake is not necessary for the subsequent message.

Carl Anderson (Feb 03 2021 at 19:52):

@Matt Varghese - I think we should bring this up again for finalization / clarification at this week's call. From what I can gather from the notes (and the discussion in the recording) - it's still not clear whether we voted to include the handshake before each message, or once per session (or something else).

Here's what I have in the notes, anyway.

Bas: Propose that we add a "status.handshake" as a new request message type
  * Request message has no required body params
    * Empty object
    * Extensions allowed
  * Response message has optional body params
    * error: optional
    * extensions allowed

Motion: Bas van den Heuvel (per description above) / Matt Varghese
Discussion
  * how often will this be called? Whenever the app wants (from app perspective); EHR respondes whenever it receives a message
  * What if the app "navigates to a new app"?  Will discuss separately.

Carl Anderson (Feb 03 2021 at 19:54):

Also, it's still not clear to me whether it's wrong to include a handshake response messageID as a responseToMessageId in a scratchpad.* or ui.* message. At the very least we should clarify in the IG what is expected.

Matt Varghese (Feb 03 2021 at 19:58):

@Carl Anderson Fair enough. What I said is my view and what I understood from the call.
I fully understand your concern of it not being on the notes - so we can discuss again.
Is the ballot review a standing meeting? I don't have any calls I'm tracking..

Carl Anderson (Feb 03 2021 at 19:59):

It is a standing meeting, yes. Let me find the link...

Carl Anderson (Feb 03 2021 at 19:59):

http://hl7.org/concalls/CallDetails.aspx?concall=52801

Carl Anderson (Feb 03 2021 at 19:59):

You can import the .ics for this to your calendar (but remember to modify it to recur weekly)

Josh Mandel (Feb 03 2021 at 20:45):

the app MUST handshake before using other messages.

From discussion (Bas said this clearly, I recall), client can call handshake whenever it wants to (or never); server's job is to respond when it receives one. We can review/discuss Fri.