Stream: Da Vinci PAS
Topic: Submit PA bundle and expect 'pending'?
John Silva (May 13 2021 at 02:10):
@Gary Gryan When we submit a PA bundle to the Mitre PAS server it appears that we are always getting a "disposition": "Granted" and "outcome":"complete". Is there some way to post a bundle that will return a "disposition": "Pended" to test the execution path for polling? (what would be expected in the ClaimResponse when a PA is "Pended". the outcome = "queued" or a particular reviewAction.valueCode?
If there is a way to create and POST a bundle that would create the "Pended" state, is there a mechanism to then move this ClaimResponse to "Granted" ? (Is there one of the /debug endpoints on the server that allows changing the state of a ClaimResponse?)
Benjamin Langley (May 13 2021 at 12:45):
Hi John, we have a rudementary rules engine to determine whether items are approved or not. Right now it looks like Home Blood Glucose Monitor (http://www.ama-assn.org/go/cpt 82947) should always come back as pending. Give that a try and let me know if it works
John Silva (May 13 2021 at 17:23):
@Benjamin Langley thanks! I was starting to feel like no one was participating in this track. ;-)
We've also noticed some other 'inconsistencies' and problems with some of the sample patient resource data (and Questionnaire/Library) we're using from this Github site: https://github.com/HL7-DaVinci/CDS-Library
I suppose we can bring up some of these concerns at 'read out' -- unless there's a better place (time) to do that.
Benjamin Langley (May 13 2021 at 17:25):
I don't see a reason to wait, might as well bring it up now! I only work on the PAS side of the house but I'll loop in @Larry Decelles who leads the DRLS project and works with those resources in the CDS-Library
Larry Decelles (May 13 2021 at 17:58):
@John Silva are you able to enumerate the inconsistencies and problems you are seeing with the patient data?
Larry Decelles (May 13 2021 at 17:59):
@John Silva we'd be happy to help out.
John Silva (May 13 2021 at 18:45):
I've run into a few both in patient data (resources) and profiled resources. I'll have to put together a list but I haven't yet -- we're just trying to get something working first.
One example, one of the samples for DeviceRequest (order) uses this for the code system: https://bluebutton.cms.gov/resources/codesystem/hcpcs. - I was informed that it should probably be using http://terminology.hl7.org/CodeSystem/HCPCS. (but the profile for CRDDeviceRequest only specifies an (example) code system so theoretically the bluebutton one is OK. I've also run into problems with the naming of some of the Library resources because when used as an Id it's not legal. This happens with the CDS_Connect_Commons_for_FHIRv400. (I noticed this when I took the JSON Library-R4-CDS_Connect_Commons_for_FHIRv400.json and convert it to .fsh with GoFSH. Subsequently running the generated fsh file through Sushi complains about the "_" being illegal in an FHIR Id.)
John Silva (May 13 2021 at 18:53):
@Benjamin Langley - one of the other things I was thinking of was that the PAS Server implementation have a method, e.g. .../debug/ClaimResponse?updateState=granted&id=<ClaimResponseId>. (or whatever the correct state values are -- which I'm not clear - which property and what are the state values that logically determine 'Approved', 'Denied', or 'Pending'). This would then allow a tester to be able to POST their PA bundle and then, using the returned ClaimResponseId, be able to manually set it to "Approved' so that they can test their polling or Subscription mechanisms? [I was just searching through the reference implementation code for the PA server to see where this is done, i.e. setting the state to "Pending" but haven't found it yet.]
Benjamin Langley (May 13 2021 at 18:55):
@John Silva that's an interesting idea. Right now pended requests are automatically added to a scheduler and then approved after 60 seconds. So you can still test your polling/subscription mechanisms
Benjamin Langley (May 13 2021 at 18:57):
As for the official location you have ClaimResponse.outcome which can be queued, complete, error or partial. To determine whether it is approved or denied you need to look at each item: ClaimResponse.item.extension(reviewAction).extension(reviewActionCode). The disposition you are looking at is a string property and we populate that based on those other factors
John Silva (May 13 2021 at 19:15):
Ah, an automatic (scheduled) change from Pending to Approved. (related Q - how hard would it be for us to have the E0424 code for Home O2 Device the one that is set to pending?). So, for an approved request would we expect outcome=complete and then disposition="Granted" or do we have to iterate through every item to see the reviewActionCode? (I assume these codes are X12 codes; I can't seem to find these in the profile documents unless I'm looking in the wrong place.)
Benjamin Langley (May 13 2021 at 19:18):
I can easily set the rule for Home Oxygen to be pending (we've been having a slight deploy issue to Logica though so even if I make the change now it may not get updated on the server - I'll let you know when its updated). As for your other questions - in our implementation that is how you can tell it is approved but it is not required to have disposition="Granted". To work with any implementation then yes, you would need to check the reviewActionCode for each item (and yes these are X12 HCR01 codes)
Last updated: Apr 12 2022 at 19:14 UTC
