Stream: Da Vinci/plan-net-connectathon
Topic: Optum
Saul Kravitz (Jan 14 2021 at 21:16):
@David Clowers
I confess that our reference implementation provides poor diagnostic output to the user, but I've been poking around within the debugger to understand some odd behaviors.
I'm getting "{\n \"resourceType\": \"OperationOutcome\",\n \"issue\": [ {\n \"severity\": \"error\",\n \"code\": \"processing\",\n \"diagnostics\": \"Multiple values detected for non-repeatable parameter 'type'. This server is not configured to allow multiple (AND) values for this param.\"\n }, {\n \"severity\": \"information\",\n \"code\": \"informational\",\n \"diagnostics\": \"TrackingUuid = 76051679-4576-4617-98ee-f2a743c3d3c3\"\n } ]\n}""
From the query https://appnameformularlyconnectathonjan2021.azurewebsites.net/R4/Organization?_summary=count&type=prvgrp,fac"
1) shouldn't this be specifying an OR, not an AND based on the syntax?
2) The search parameter says multiple and and or are required.... http://hl7.org/fhir/us/davinci-pdex-plan-net/SearchParameter-organization-type.html
This causes the front panel of our app to report that there are zero Organizations, since the query is for all type values that are not ntwk, which is hot to differentiate networks from other organizations.
Also, some queries fail:
https://appnameformularlyconnectathonjan2021.azurewebsites.net/R4/Organization?_id=H1045033000
Returns with Invalid request: The FHIR endpoint on this server does not know how to handle GET operation[Organization] with parameters [[_id]]
Ditto for Get of Insurance plans, Locations by _id. So, I suspect this is a general configuration issue.
David Clowers (Jan 14 2021 at 21:24):
Our understanding per the IG was that the way to differentiate between Organization and Network was by using the profile parameter in the endpoint, i.e.:
Organization: {host}/Organization?_profile=http://hl7.org/fhir/us/davinci-pdex-plan-net/StructureDefinition/plannet-Organization
Network: {host}/Organization?_profile=http://hl7.org/fhir/us/davinci-pdex-plan-net/StructureDefinition/plannet-Network
Thus we only filter by one type in Provider, 'prvgrp'. If we should change our implementation to allow for multiple search parameters for .type, we can look into updating this, but just wanted to confirm first whether we should be using this approach or the approach with the profile param.
Saul Kravitz (Jan 14 2021 at 21:56):
Hi @David Clowers -- I think there are two things intermingled:
1) how to differentiate Plannet-Network profiles of Organization from Plannet-Organization profiles
2) Conforming to the search interface to the IG. The search parameter Organization:type requires the ability to do ANDs(multiple instances of the search parameter) and ORs (a comma separated list).
Re #1: Indeed the only way to differentiate between the two profiles was by searching on _profile for a long time. @Lloyd McKenzie taught me that this was very poor form, so we changed things so that the Organization.type field is used to differentiate the two, with Network profiles required to have type=ntwk, and the Organization profile requiring one of the allowed types fac,bus,prvgrp,payer,atyprv.
David Clowers (Jan 14 2021 at 22:12):
@Saul Kravitz Thanks for this feedback and clarification. We will take a look at updating this in our service.
David Clowers (Jan 14 2021 at 22:15):
One more clarification...does that mean we can deprecate the profile parameter entirely?
Saul Kravitz (Jan 14 2021 at 22:17):
As per https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/CapabilityStatement-plan-net.html#resource--details it is not required.
David Clowers (Feb 09 2021 at 01:18):
@Saul Kravitz @Dave Hill Not sure if this is the best place to ask this question, but since it's related to one of our Connectathon 26 findings, here goes. Does this mean we should also look at deprecating the _profile parameter for Formulary as well? Currently our implementation still uses this for routing.
David Clowers (Feb 09 2021 at 01:19):
And if so, what should be used in its place?
Saul Kravitz (Feb 09 2021 at 13:28):
Hi @David Clowers
The _profile search parameter is not required. See http://hl7.org/fhir/us/davinci-drug-formulary/CapabilityStatement-usdf-server.html#behavior
Please expand on "Currently our implementation still uses this for routing."
Isn't the resource type (MedicationKnowledge) sufficient for routing?
David Clowers (Feb 09 2021 at 19:16):
@Saul Kravitz The current IG seems to imply that the _profile parameter is required, so this is how our implementation is currently working.
See this section: http://build.fhir.org/ig/HL7/davinci-pdex-formulary/#anticipated-client-queries
The profiles are actually CoveragePlan and FormularyDrug, based on the List and MedicationKnowledge resources respectively. So our understanding of the implementation is that the _profile parameter is required to route these requests to the proper resources. Is this not the case?
Example request headers per the IG:
GET [base]/List?_profile=http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-CoveragePlan
GET [base]/MedicationKnowledge?_profile=http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyDrug&DrugPlan=myPlanID
Saul Kravitz (Feb 09 2021 at 19:42):
Hi @David Clowers . I think you have found a bug in the IG that reflects our thinking when the authors were young and naive.
I'm going to create a tracker to eliminate the _profile= from all of those example queries.
https://jira.hl7.org/browse/FHIR-31031
FHIR queries are directed at the Resource that is profiled, as you note. So FormularyDrug queries are actually queries against MedicationKnowledge resources, and CoveragePlan queries are queries against List resources. Using the _profile search parameter constrains the returned data to instances that declare conformance to the profile through the meta.profile field. Populating this field is not required for conformance to the IG, so there is no reasonable expectation that a server would populate that field. (I'm a fan of populating that field, but I'm in the minority.)
GET [base]/List. This would return all List instances, including those that represent CoveragePlan
GET [base]/MedicationKnowledge?DrugPlan=myPlanID. This would return all MedicateKnowledge that are supported by the DrugPlan search parameter, and that instance matches the provided PlanID. DrugPlan is only supported for the FormularyDrug profile.
Last updated: Apr 12 2022 at 19:14 UTC
