Scott,

I appreciate the feedback and this has added clarity. One comment on your note:

[SMR-_* _This may need Frank’s input.  In the simplest sense, FHIR’s API design for queries follows the HTTP query model:  posting a GET message to an endpoint (your PDMP system) with appropriate security and query parameters (e.g., patient, dates); assuming the query is accepted and valid, the endpoint returns an HTTP response with the result represented in JSON FHIR resources.  Still based on that model, I have seen IGs that describe a 2-step process where the initial query “queues up” the data on the server but the result data is not sent to the requester.  The initial query response includes an identifier (e.g., a GUID for the results) and the responder does a second HTTP request (with the GUID) to retrieve the data.  I think that may match what you are asking for, but we need to discuss further.{*}]

I think the two-call system is important to consider. That is how 99% of our integrations work today as we have moved everyone off of NCPDP connections.

Thanks for taking the time to clarify.

Gayle

From: Scott Robertson <scott.robertson@pocp.com>
Sent: Tuesday, August 29, 2023 5:44 PM
To: Donaldson, Gayle [Pharmacy] <Gayle.Donaldson@ks.gov>; Frank McKinney <frank.mckinney@pocp.com>
Subject: RE: FHIR Project Feedback

Hello Gayle,

Thank you for your questions.  I have inserted my responses, although some of your concerns may require discussion by the group: that I’m missing your point; that there are additional perspectives; and/or that changes to the IG may be needed – either clarification, additions, or deletions.  This is part of the process we are going through to identify and resolve issues.

-Scott

Scott Robertson, PharmD RPh

PDMP on FHIR Project Facilitator

310-200-0231 | scott.robertson@pocp.com

From: Donaldson, Gayle [Pharmacy] <Gayle.Donaldson@ks.gov>
Sent: Tuesday, August 29, 2023 9:27 AM
To: Scott Robertson <scott.robertson@pocp.com>; Frank McKinney <frank.mckinney@pocp.com>
Subject: FHIR Project Feedback

Hello,

Below are questions submitted by the Kansas PDMP for further clarification and consideration in development of the FHIR standard. This work is still relatively unclear to me, so some questions may or may not be on track with the proposed work. We would request written responses to these questions and clarifying points even if you are planning to answer them during a webinar. Thank you.

.......

• Request type must be reported in the request elements. 99% of our integrations do not use NCPDP connections and therefore report multiple request types – first calls to queue up the data and second calls to record an executed search. We need to be able to distinguish between these request types in our audit trails in order to accurately report usage data for federal grants and state performance measures.

[SMR-_* _This may need Frank’s input.  In the simplest sense, FHIR’s API design for queries follows the HTTP query model:  posting a GET message to an endpoint (your PDMP system) with appropriate security and query parameters (e.g., patient, dates); assuming the query is accepted and valid, the endpoint returns an HTTP response with the result represented in JSON FHIR resources.  Still based on that model, I have seen IGs that describe a 2-step process where the initial query “queues up” the data on the server but the result data is not sent to the requester.  The initial query response includes an identifier (e.g., a GUID for the results) and the responder does a second HTTP request (with the GUID) to retrieve the data.  I think that may match what you are asking for, but we need to discuss further.{*}]