Stream: subscriptions
Topic: US CMS Rule Notificaitons
David Pyke (Sep 11 2020 at 20:49):
The US CMS Rule released this year (it seems like so long ago) requires that the patient name, practitioner name and organization name be part of the notification payload. Has any thought gone into how that might be accomplished through the SusbscriptionStatus or other means?
Lloyd McKenzie (Sep 11 2020 at 20:58):
Having a Patient reference on the SubscriptionStatus seems like a not-horrible idea from a patient access control/compartmentalization perspective. If that happened, you could stick the name in Reference.display. What practitioner and organization do they want the name of?
David Pyke (Sep 11 2020 at 20:59):
The practitioner part of a condition/encounter/etc and the organization sending the notification.
Lloyd McKenzie (Sep 11 2020 at 21:00):
There are a lot of practitioners on encounter and quite a few other resources
Lloyd McKenzie (Sep 11 2020 at 21:01):
And those individuals might not have anything to do with the event that led to the notification...
David Pyke (Sep 11 2020 at 21:01):
Yes, so either the notificaiton becomes a complex bundle or the names need to be added to a SubscriptionStatus
Lloyd McKenzie (Sep 11 2020 at 21:02):
It also means that "identifier only" or "ping only" becomes impossible, because the patient name (especially when combined with provider name) would be sensitive.
David Pyke (Sep 11 2020 at 21:03):
Right, so under CMS, you must send PHI and then everything goes bad. This might be needing part of USCore to profile SubscriptionStatus or the notification bundle
Vassil Peytchev (Sep 11 2020 at 21:21):
Umm, to me that sounds like a complete perversion of Subscription notification. I look at the CMS Rule as a functional requirement - the information must get to the other side. When you you use a subscription notification, it is the responsibility of the recipient to fetch the information based on the notification, it is not a requirement to stuff everything into a ping.
David Pyke (Sep 11 2020 at 21:22):
The Rule seems to clearly state this must be part of the notification. CMS was likely thinking that we'd all use V2 msssages
Vassil Peytchev (Sep 11 2020 at 21:23):
Functional requirement vs. technical implementation.
David Pyke (Sep 11 2020 at 21:23):
Yes, the requirement states that it must include these three datapoints. How you get them there is not mentioned. You can wrap them on a pigeon leg but they must be included in the notification
Jenni Syed (Sep 11 2020 at 22:13):
I don't think we would put actual resources on SubscriptionStatus:
Jenni Syed (Sep 11 2020 at 22:13):
1). those bundle up many notifications... some that won't have a patient at all.. some that will have many patients... some that have other types of personas instead
Jenni Syed (Sep 11 2020 at 22:14):
2) I would rather put provide that as the "related" in the bundle if requested by the subscriber
Jenni Syed (Sep 11 2020 at 22:15):
similar to Lloyd's question here: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Subscription.20notifications.20with.20'includes'
Jenni Syed (Sep 11 2020 at 22:17):
Also, those are very often fields that are set in the display field for a reference (vs even requiring the "include")
Jenni Syed (Sep 11 2020 at 22:18):
so it may not even need the include... ?
Jenni Syed (Sep 11 2020 at 22:18):
It is interesting that it would not allow for id only...
Gino Canessa (Sep 11 2020 at 22:33):
I agree with Jenni that these don't belong in the SubscriptionStatus element. They are not meta-information about the subscription or message, but part of the payload (e.g., some subscriptions will have them, others will not).
I would guess that we need to ensure we define how to do chaining or graphs of resources (since it also includes 'diagnosis where not prevented by local law', which is not something you can add a single field for).
I'd also say that we may want to revisit the channels to see if an additional channel type makes sense in the core spec - something that offers asymmetric encryption and/or some other security to make this more feasible.
David Pyke (Sep 12 2020 at 13:22):
Why put in the whole resource when only the names are needed?
Gino Canessa (Sep 12 2020 at 16:55):
Generally, my thoughts stem from the fact that the target of subscriptions is not "2020 ONC Rules". There are a lot of use cases across a lot of regions, and fixing core components to match (today's) rules of a particular country feels off. My goal is to ensure there are mechanisms to allow for this in a way flexible enough that when next year's rule comes out we don't have to redesign the resource to make it work. Same with requirements from other regions.
Additionally, we've established that demographic information in a notification is payload data. If we start adding payload fields to header information, we are back in the same situation (everyone will want the fields for their use case).
Beyond those, many implementers have strongly expressed concerns over sending PHI over the current channels. Many use cases ask for things like source, destination, etc. to be available during every hop. Enforcing the line between header (no PHI) and payload (PHI) leaves more flexibility for things like encrypted payloads with non-encrypted headers.
Vassil Peytchev (Sep 12 2020 at 19:15):
I think is not appropriate to mix FHIR Subscription Notifications with functional requirements on notifications as business objects. Functional notifications, i.e. transmitting the information that an event has occurred, and the related circumstances, can be implemented using various mechanisms.
If the mechanism is FHIR Messaging, then you have one step transmission using the FHIR Message to encompass the fact that there was an event of interest, and all the related circumstances of the event as determined by the sender.
If the mechanism is FHIR Subscriptions, you have two-step transmission, where the first step is the FHIR Subscription Notification, indicating the event has occured, and the second (and potentially more) step(s) involve the retrieval of all the related circumstances as determined by the consumer, and here is where the minimal functional requirements need to be translates as requirements for the sender to provide the FHIR RESTfull API access to the resources satisfying these minimal requirements. Yes, within FHIR subscriptions you have the options of id-only vs. other types of content in the notification, but the fundamental point here is that CMS Rule Notifications as business/functional requirements are fully met with this two-step transmission (including id-only notifications).
David Pyke (Sep 12 2020 at 19:20):
How is requiring a fetch of additional information fulfilling the requirement that the notification have those three data points?a The notification doesn't have them, you are required to fetch them as a second step? The CMS Rule states that the notification have the data points, not that they are available through extra work.
Vassil Peytchev (Sep 12 2020 at 19:39):
Because the CMS Rules notification is a business requirement, that can be met by a variety of methods. The Implementation Guide's job is to describe the method, including the technical requirements to satisfy the business requirement. You can think of the CMS Rule notification as an IHE transaction that has two parts - POSTing the notification, and GETing the relevant information.
David Pyke (Sep 12 2020 at 20:51):
The Rule states: " sends notifications that would have to include the minimum patient health information (which, as noted above, would be the patient’s name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis);" Having them not include that information but it being available for retrieval is a very loose interpretation of the Rule. I'm not sure that CMS would approve of your interpretation.
Vassil Peytchev (Sep 12 2020 at 23:49):
Having them not include that information but it being available for retrieval is a very loose interpretation of the Rule.
That is only "half interpretation" - the IG specifies, and subsequent certification tools need to test both:
- the sender properly sends a FHIR Subscription Notification
- the sender has the required data available for retrieval
and
- the receiver accepts an appropriate FHIR notification
- the receiver automatically retrieves the required and any additional data available.
This is not a "loose interpretation" - it is the translation of a business requirement into a technical specification. The main reason for pursuing a FHIR Subscription based implementation, is to build upon the RESTful capabilities already present in the source systems (and to create/expand them where they are lacking). If it weren't for that, why not create a $adt-notification operation, define the payload, and move on?
Josh Mandel (Sep 14 2020 at 00:41):
I agree with a lot of the analysis here, but I would note that including auxiliary data is certainly in scope for what we would like to be able to accomplish with subscriptions. This is the concept of an inclusion list or graph that we would like to make sure we leave room for, even if we don't standardize it in R5.
Eric Haas (Mar 03 2021 at 17:56):
I am going to hijack this thread to ask if anybody is planning to or actually going using FHIR Subscriptions (namely the R4 Backport) vs say V2 messaging to meet this Rule. By anybody, I mean any Health System Vendor either as a publisher or subscriber. The reason I am asking is that the Da Vinci Notifications project has been considering adding this specific use case in an updated IG, but so far it we have not noticed a push for it from the community.
David Pyke (Mar 03 2021 at 18:34):
Carequality used aspects of the backport for their Push notifications use case. So far, there hasn't been a lot of interest from the community.
Last updated: Apr 12 2022 at 19:14 UTC
