Fwd: [EXTERNAL]: Re: PMIR testing at Connectathon

[Lynn Felhofer]

Dear ITI Tech,

The following question has been raised by participants who are preparing to test PMIR at the IHE NA Connectathon next week, specifically regarding the [ITI-94] Subscribe to Patient Updates transaction and how a Subscriber 'disables' a subscription.   

In PMIR, we say:

Sec 3.94.4.4 Enable/Disable Patient Subscription Request/Response Message,

A Patient Identity Subscriber can enable or disable a subscription on the Patient Identity Registry by accessing the Location returned by the Subscribe to Patient Updates Response as defined at https://www.hl7.org/fhir/http.html#update on the Subscription Resource. This can be used to temporarily disable the subscription by changing the status to “off” or re-enable a subscription by changing the status to “requested.”  

A Patient Identity Registry shall disable a subscription when the status is “off.” 

The Patient Identity Registry shall handle changes with a status of “requested” as per Section 3.94.4.1.3.

3.94.4.5 Delete Patient Subscription Request/Response Message 

A Patient Identity Subscriber can delete a subscription from the Patient Identity Registry by 875 accessing the Location returned by the Subscribe to Patient Updates Response as defined at https://www.hl7.org/fhir/http.html#delete on the Subscription Resource. 

Based on the text in green, I have written a test step instructing the Subscriber to disable an existing subscription on the PMIR Registry by setting the status to "off".   In the email exchange that follows below, someone has pre-tested my instructions on Graham's server, which returns an error....see details that follow.

Do we need to update PMIR Sec 3.94.4.4?    Other thoughts?

Thanks in advance on your guidance on how we should test this part of PMIR next week.

Lynn

---------- Forwarded message ---------

Hmmm, note this from https://www.hl7.org/fhir/subscription.html that supports Ron’s theory:

 

An appropriately authorized client can use search and/or history operations to see what subscriptions are currently active on the server. Once the subscription is no longer desired, the client deletes the subscription from the server.

The server may retry the notification a fixed number of times and/or refer errors to its own alert logs. If the notification fails, the server should set the status to 'error' and mark the error in the resource. If the notification succeeds, the server should update the status to "active again. If a subscription fails consistently a server may choose set the subscription status to off and stop trying to send notifications.

Thanks,
Ben

 

 

Subject: [EXTERNAL]: Re: PMIR testing at Connectathon

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

 

---

Hi Lynn,

 

Thanks for the email.

 

I was just working on getting this setup and have already encountered our first "issue".

 

I am getting my subscriptions setup against Grahame's R4 test server at http://test.fhir.org/r4/, making sure that I can create, update, and delete subscriptions as per the test scripts documented in Gazelle.

 

When I attempt to update the existing Subscription on Grahame's test server to set the Subscription.status to "off" it returns the following error:

 

{
  "resourceType": "OperationOutcome",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Subscription status must be \"requested\", not off</p></div>"
  },
  "issue": [
    {
      "severity": "error",
      "details": {
        "text": "Subscription status must be \"requested\", not off"
      },
      "diagnostics": "(00000000052083C8){FHIRServer.exe} [00000000056093C8] Unknown function at TMethodImplementationIntercept + $5160D58\r\n(0000000005AE1BAC){FHIRServer.exe} [0000000005EE2BAC] Unknown function at TMethodImplementationIntercept + $5A3A53C\r\n(0000000005AE3AE0){FHIRServer.exe} [0000000005EE4AE0] Unknown function at TMethodImplementationIntercept + $5A3C470\r\n(000000000004B717){FHIRServer.exe} [000000000044C717] Unknown function at __dbk_fcall_wrapper + $2E157\r\n(000000000004C00B){FHIRServer.exe} [000000000044D00B] Unknown function at __dbk_fcall_wrapper + $2EA4B\r\n(00000000000115D6){FHIRServer.exe} [00000000004125D6]\r\n(0000000000011611){FHIRServer.exe} [0000000000412611]\r\n(00000000052083C8){FHIRServer.exe} [00000000056093C8] Unknown function at TMethodImplementationIntercept + $5160D58\r\n(0000000003A9C930){FHIRServer.exe} [0000000003E9D930] Unknown function at TMethodImplementationIntercept + $39F52C0\r\n(0000000000C26457){FHIRServer.exe} [0000000001027457] Unknown function at TMethodImplementationIntercept + $B7EDE7\r\n(00000000058E1CE7){FHIRServer.exe} [0000000005CE2CE7] Unknown function at TMethodImplementationIntercept + $583A677\r\n(00000000058D6F36){FHIRServer.exe} [0000000005CD7F36] Unknown function at TMethodImplementationIntercept + $582F8C6\r\n(00000000058D2F0A){FHIRServer.exe} [0000000005CD3F0A] Unknown function at TMethodImplementationIntercept + $582B89A\r\n(00000000058F6F39){FHIRServer.exe} [0000000005CF7F39] Unknown function at TMethodImplementationIntercept + $584F8C9\r\n(00000000006EDB39){FHIRServer.exe} [0000000000AEEB39] Unknown function at TMethodImplementationIntercept + $6464C9\r\n(00000000006EF49B){FHIRServer.exe} [0000000000AF049B] Unknown function at TMethodImplementationIntercept + $647E2B\r\n(0000000000456C99){FHIRServer.exe} [0000000000857C99] Unknown function at TMethodImplementationIntercept + $3AF629\r\n(0000000000454CAA){FHIRServer.exe} [0000000000855CAA] Unknown function at TMethodImplementationIntercept + $3AD63A\r\n(000000000045994B){FHIRServer.exe} [000000000085A94B] Unknown function at TMethodImplementationIntercept + $3B22DB\r\n(0000000000458AEB){FHIRServer.exe} [0000000000859AEB] Unknown function at TMethodImplementationIntercept + $3B147B\r\n(0000000000139683){FHIRServer.exe} [000000000053A683] Unknown function at TMethodImplementationIntercept + $92013\r\n(000000000001219D){FHIRServer.exe} [000000000041319D]\r\n(00000000000074D4){KERNEL32.DLL} [00007FFBF04084D4] BaseThreadInitThunk + $14\r\n(0000000000050821){ntdll.dll   } [00007FFBF1981821] RtlUserThreadStart + $21\r\n"
    }
  ]
}

 

This leads me to believe that perhaps the purpose of the Subscription.status attribute is for the requestor to only be able to set the value to "requested" and then the Server is able to use the other codes ("active", "error", "off").  I can't find where this is described this way in the spec, but Grahame's test server is definitely behaving this way.

 

Perhaps you can bring this up with the IHE PMIR team and have them cross-check with Grahame?

 

Thanks!

 

Ron

[Luke Duncan]

I wanted to reply quickly, but I’ll do some testing on the HAPI server when I have a little more time to see what it does.  But this is the information from the specification:

 

http://hl7.org/fhir/subscription-definitions.html#Subscription.status

A client can only submit subscription resources in the requested or off state. Only the server can move a subscription from requested to active, and then to error. Either the server or the client can turn a subscription off.

 

Luke Duncan | Assistant Director, Digital Health

IntraHealth International | Because Health Workers Save Lives.

t. +1 (919) 313-9621 | ldu...@intrahealth.org | He/Him Pronouns

--
You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CAJ8LWqa1ArpVNKwrQ_LFSd0Td%2Bfjt-2ibcatvUUCNKvuLvdKCA%40mail.gmail.com.