Section 7 Mappings

While this section spells out existing data field mapping situations (at minimum values), it does not outline what FHIR is proposing for required data or mapping.

[SMR-_* _the mappings are not normative content.  Mappings show how the proposed FHIR resource elements correspond to data elements in the other standards.  This provides insight into the nature of the data (as in your comment on state license number for pharmacists) and traceability for troubleshooting.{*}]

Considerations that should be made from existing NCPDP, PMIX, etc., mappings:

• Requester identifier needs to accommodate a state license number for pharmacists without NPIs and the VA health system, which allows nurses to access PDMPs through the VA EMR. All requester identifiers must be unique, so pharmacy NPIs or other placeholders cannot be used in place of individual identifiers.

[SMR-_* _FHIR can accommodate any number of different identifiers, including multiple types of identifiers from one organization (an employee number and a practitioner ID from an organization) and the same kind of identifier from different organizations (e.g., state licenses from different states).  Regarding the query request, the requestor does need to be uniquely identified (authentication) and verified as an allowed user (authorization) – which are part of Security (which references US Core) and likely needs additional text to explicitly address your concern{*}]

• Requester role must be included in the request elements. Authorization for access to the PDMP is granted by each state after careful consideration of each registrant. The requester role needs to be captured to ensure provider authorization requirements are being met for access to data by appropriate role types.

[SMR- Authentication can include Role.  It’s not apparent in the IG as the Security discussion refers to US Core.  Generally, FHIR IG don’t repeat “established and reused” content to minimize the need to update multiple IGs when an underlying capability is updated.  However, points of concern, such as this, can and should be included in our IG, while still referring to US Core for the technical details.

 __ 

Related: US Core for Authentication and Authorization focus on OAuth 2 and SMART.  The group needs to discuss if this is viable, or another Authentication scheme is needed.]

• Response type needs to be included in the response elements. We need to know whether the request was successful, had an error, found data, etc. This helps us identify if there are issues within the integration producing a high number of errors and helps us with compliance and investigative work to be able to access our audit trail to identify whether a search was successful and/or produced data.

[SMR-_* _The FHIR query response model includes the query in the reported response along with either errors or the found data.  I think this points to the need for examples, and some additional narrative.{*}]

Gayle Donaldson

Assistant Director

Kansas Board of Pharmacy

800 SW Jackson, Suite 1414

Topeka, KS 66612

(785) 608-1023