FHIR Chat · Davinci Pdex Plan Net

Stream: implementers

Topic: Davinci Pdex Plan Net

Yengibar Manasyan (Jun 08 2020 at 21:43):

@Saul Kravitz from where we can find information about _include, _revinclude, and _has parameters? I want to understand what reference parameters must support them.

Saul Kravitz (Jun 09 2020 at 18:04):

Should be in the capability statement. CapStmt is a work in progress. I can say with confidence that it WILL CHANGE.

Aleksandr Teterin (Jun 12 2020 at 16:37):

@Saul Kravitz

There is the following PlanNet practitioner sample.
https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/Practitioner-practitioner1.json.html

Extract.
"coding" : [ { "system" : "http://terminology.hl7.org/CodeSystem/v2-0360|2.7", "code" : "MD", "display" : "Doctor of Medicine", "userSelected" : true } ]

As far as I see the system should contains only the Defining URL http://terminology.hl7.org/CodeSystem/v2-0360 without “|2.7” addition.
Is that correct?

Saul Kravitz (Jun 12 2020 at 19:57):

I'm looking into the right way to reference this....stay tuned. @Robert McClure

Igor Sirkovich (Jun 12 2020 at 20:48):

@Saul Kravitz, I believe this should be:

"coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/v2-0360",
            "version" : "2.7",
            "code" : "MD",
            "display" : "Doctor of Medicine",
            "userSelected" : true
          }
        ]

Saul Kravitz (Jun 12 2020 at 21:33):

Right. I probably don't need the version constraint in the IG or in the examples.

Robert McClure (Jun 15 2020 at 17:16):

@Saul Kravitz As a rule, we should NOT be referencing versions of value sets or code systems unless a specific code that is needed is currently inactive, but even then there are variances that could change that recommendation. In essence, ask if there is an issue but don't include version information in examples or the spec.

Yengibar Manasyan (Jun 19 2020 at 17:14):

@Saul Kravitz

In the network search parameter for InsurancePlan resource the target is Organization.

Meanwhile, if you check the InsurancePlan structure definition network field is a reference pointing to Network.
Is there an issue?

Saul Kravitz (Jun 19 2020 at 18:14):

Network is a profile on Organization, not a resource. So the target resource is Organization.

Yengibar Manasyan (Jun 26 2020 at 21:19):

@Saul Kravitz
Why network has a property partOf which refers to Organization with cardinality 1..1? A Network always must be part of an Organization, I don't clearly understand it.

Yengibar Manasyan (Jun 30 2020 at 20:39):

@Saul Kravitz ?

Saul Kravitz (Jun 30 2020 at 20:43):

@Robert Dieterle ?

Saul Kravitz (Jun 30 2020 at 21:14):

Here is my non-authoritative take: "A Network refers to a healthcare provider insurance network. A healthcare provider insurance network is an aggregation of organizations and individuals that deliver a set of services across a geography through health insurance products/plans. A network is typically owned by a payer."

The partOf is constrained to 1..1, because (I think), a network is always associated with a payer. The only reference available in the Organization resource that can refer to an organization is partOf. I think that is why partOf is 1..1, but I would need to Bob Dieterle to confirm. If it was a trivial question I would have answered more quickly ;-)

Robert Dieterle (Jun 30 2020 at 21:38):

Correct -- a payer (or some organization) contractually assembles a network. It does not actually "own" the network. The cardinality is 1..1 because provider networks do not just organically form. Any number of Insurance products/plans can point to (reference) a specific network.

Yengibar Manasyan (Jul 01 2020 at 15:05):

Thank you @Saul Kravitz and @Robert Dieterle

Yengibar Manasyan (Jul 27 2020 at 17:07):

@Saul Kravitz
In PlanNet Capability Statement in searchInclude for Practitioner resource there are these parameters:
"Practitioner.practitioner-identifier-assigner",
"Practitioner.practitioner-qualification-issuer",
"Practitioner.practitioner-qualification-wherevalid-location"

Shouldn't these be like this?
"Practitioner.identifier-assigner",
"Practitioner.qualification-issuer",
"Practitioner.qualification-wherevalid-location"

Saul Kravitz (Jul 27 2020 at 17:39):

I'm still cleaning up the CapStmt....
Thanks for the feedback...will take a look..

Yengibar Manasyan (Jul 28 2020 at 15:55):

@Saul Kravitz
For some reference search parameters, I see contains chaning parameter. Isn't it an issue? I can't find such a field or search parameter in the reference resources.

Alexander L (Jul 28 2020 at 19:34):

Hello All,
I've downloaded current JSON definitions of the IG and now trying to understand why search params in the Capability Statement do not match with SearchParameters json files.
I can see that some resources have very limited amount of search parameters in the Capability Statement, e.g. Practitioner has only 1, Location has 4. At the same time, there are 10 search parameters for Practitioner and 12 for Location in the SearchParameter jsons, published in the same archive.
What is the source of truth?

Lloyd McKenzie (Jul 28 2020 at 19:38):

Where are you finding SearchParameters json files? The CapabilityStatement defines what a given type of system needs to support. SearchParameters define what's theoretically possible

Alexander L (Jul 28 2020 at 19:42):

@Lloyd McKenzie I downloaded "JSON definitions" from here https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/downloads.html
The archive contains SearchParameter-*.json files. Are you saying that there is no mistake in Capability Statement and those extra search parameters should not be supported?

Lloyd McKenzie (Jul 28 2020 at 19:43):

I wouldn't say "should not" I would say "need not". I can't say whether there's an error or not, only that it's legitimate to be different.

Alexander L (Jul 28 2020 at 19:51):

@Lloyd McKenzie thank you for the clarification. @Saul Kravitz could you please confirm that there is no mistake and Plan Net implementation should support only those parameters which currently specified in the CapabilityStatement?

Alexander L (Jul 28 2020 at 20:53):

@Saul Kravitz Also there are some discrepancies in Capability Statement which make impossible to work with the IG automatically. For example, Endpoint resource in the Capability Statement has the following search parameter:
{
"name": "managing-organization",
"definition": "http://hl7.org/fhir/us/davinci-pdex-plan-net/SearchParameter/plannet-endpoint-managing-organization",
"type": "reference"
}

But there is no such SearchParameter definition. There is a similar one, "endpoint-organization", but it has different name and url.

Saul Kravitz (Jul 28 2020 at 20:56):

Updating search parameters to bring. into line. with Capability Statement today.

Yengibar Manasyan (Jul 29 2020 at 17:37):

Yengibar Manasyan said:

Saul Kravitz
For some reference search parameters, I see contains chaning parameter. Isn't it an issue? I can't find such a field or search parameter in the reference resources.

Yengibar Manasyan (Jul 30 2020 at 15:32):

@Saul Kravitz ?

Saul Kravitz (Jul 30 2020 at 16:16):

Help me figure this out. Are you saying that the search parameter chain includes a field that isn't in the capability statement? Or vice versa?
I am far from the world's leading expert on Capability Statements, so I'm interested in feedback.

Yengibar Manasyan (Jul 30 2020 at 21:23):

@Saul Kravitz for example, HealthcareService resource has a reference search parameter coverage-area. In addition, there are identifier and contains chained parameters (info is taken from SearchParameter-healthcareservice-coverage-area.json), so users can do searches like this: {baseUrl}/HealthcareService?coverage-area.contains=something. I think contains chained parameter must be deleted from there (and from lots of other search parameters as a chained parameter). What do you think?

Saul Kravitz (Jul 31 2020 at 14:42):

I deleted contains from the chain list of the two coverageArea search params (InsurancePlan and HealthcareService).
Most of the other contains are in the modifier, not the chain list, so I think they are OK.
Further feedback welcomed. Thanks!

Saul Kravitz (Jul 31 2020 at 14:42):

@Yengibar Manasyan I deleted contains from the chain list of the two coverageArea search params (InsurancePlan and HealthcareService).
Most of the other contains are in the modifier, not the chain list, so I think they are OK.
Further feedback welcomed. Thanks!

Yengibar Manasyan (Jul 31 2020 at 20:25):

@Saul Kravitz first let me thank you for your quick replies and help!!!
I see in the IG last version we have just 45 search parameters. When we started using this IG there were 110+ search parameters. I hope these search parameters are not removed by mistake. When do you think we will get the final/release version of this IG? Maybe or how we can help you with it?

Saul Kravitz (Jul 31 2020 at 22:24):

@Yengibar Manasyan We have received very little feedback, so I'm grateful for every scrap.

The Balloted STU for Plan-Net added to VhDir's generous set of search parameters. We decided to trim it back to the essentials to reduce implementer burden. So, the current capability statement should be pretty close to the way it will be published. It is currently under review, so if you have feedback on missing search parameters, please share.

The technical portion of the IG should be pretty close to finished at this point. What remains is adding examples of how the profiles SHOULD be used to enable consistent query, and close review. The way you can best contribute is to send feedback on the search parameters, capability statement, or any of the other technical artifacts. Once the examples are included, comments on those will be very valuable.

Yengibar Manasyan (Aug 01 2020 at 02:55):

@Saul Kravitz
I have found a couple of issues in capability statements (CapabilityStatement-davinci-pdex-plan-net.json file) :

In the searchInclude and searchRevInclude properties, there are formatting issues, sometimes there are extra spaces and/or \n symbols. E.g. " \nOrganization.endpoint". Also sometimes there are minor case issues like: " insurancePlan:coverageArea".
searchRevIncludes mostly repeats searchIncludes, I wasn't able to find any real searchRevIncludes listed in CS. I guess it's better to delete all searchRevIncludes for now.
As it's mentioned in the FHIR documentation both _include and _revinclude are based on search parameters, rather than paths in the resource. You can check it here: http://hl7.org/fhir/search.html#revinclude. I believe this means that all includes and revIncludes must be listed as reference search parameters. But instead, in most cases, there are no such search parameters and sometimes there are includes which clearly are paths: e.g. " InsurancePlan:plan.network". I think all reference search parameters must be added with necessary definitions (e.g. expressions which will show the paths) and then in the includes must be specified search parameter names instead of paths.

Saul Kravitz (Aug 02 2020 at 20:56):

I think I nailed the spaces and \n issue
I fixed the reverse includes the way they were intended. Always a challenge to wrap my brain around those.
I think these are correctly specified.... see http://hl7.org/fhir/us/core/STU3.1/CapabilityStatement-us-core-server.json.html for comparison...I'm using the same toolkit (by Eric Haas).
```
  "searchInclude" : [
      "MedicationRequest:medication"
    ],
    "searchRevInclude" : [
      "Provenance:target"
    ],
```

Keep those comments coming. Very helpful!
The capStmt in the CI build has been updated.

Yengibar Manasyan (Aug 04 2020 at 15:56):

@Saul Kravitz
Thank you for the fixes.
I have a few minor comments.
Please check these: " InsurancePlan:ownedBy", " insurancePlan:coverageArea", " InsurancePlan.endpoint", " \nOrganization.endpoint", " \nOrganizationAffiliation:participatingOrganization", " PractitionerRole:organization", " PractitionerRole:healthcareservice", " PractitionerRole:network", " PractitionerRole:endpoint".

Could you please try to search them and remove extra spaces, \n and capitalize the letter i for insurancePlan:coverageArea?

Saul Kravitz (Aug 04 2020 at 19:35):

Thanks...willdo

Saul Kravitz (Aug 04 2020 at 21:59):

Should be fixed now. Added some code to strip whitespace in the script that builds the CapStmt....looks like it got 'em all. Rebuilding the CI build now.
THX

Yengibar Manasyan (Aug 10 2020 at 18:28):

@Saul Kravitz
I still think that the FHIR documentation is very specific about includes. This is copy/paste from the documentation: Both _include and _revinclude are based on search parameters, rather than paths in the resource, since joins, such as chaining, are already done by search parameter.
You can also find it here: http://hl7.org/fhir/search.html#revinclude.

Is there someone who participated in the creation of FHIR standard to whom we can ask this question?

Saul Kravitz (Aug 10 2020 at 19:04):

Are you referring to this IG? If so, that is not intentionally an issue in Plan-Net. My intent was to ensure that there was a matched set of include/revinclude and searchParams. Where is the mismatch between includes and searchParams?
It is definitely an issue in the CarinBB IG.... @Yengibar Manasyan

Saul Kravitz (Aug 10 2020 at 19:13):

The general question is whether it is required to support the use of the search parameter without the include. I read it the way you read it, that if you want to support _include, you need to support the use of the same search parameter without an include. Others disagree. On this IG it should not be an issue, since my intent is to implement our shared understanding (quoting chapter and verse, as you did above). The IG publisher does not provide any negative feedback for violating our shared understanding of the FHIR standard.
@Yengibar Manasyan

Yengibar Manasyan (Aug 10 2020 at 19:16):

@Saul Kravitz I'm talking about this IG. I agree that you can have multiple reference search parameters, but not all of them can be allowed to be included. Meanwhile, all includes and revincludes must have their appropriate search parameters and they must match by their names. I assume we agree on this, if not please correct me. I also will go over the includes and revincludes and try to highlight all not matching values.

Yengibar Manasyan (Aug 10 2020 at 19:25):

@Saul Kravitz
Here is a list of invalid includes:
HealthcareService:coverageArea - it must be HealthcareService:coverage-area
HealthcareService:providedBy - can't find appropriate search parameter
InsurancePlan:administeredBy - it must be InsurancePlan:administered-by
InsurancePlan:ownedBy - must be InsurancePlan:owned-by
InsurancePlan:coverageArea - can't find appropriate search parameter
InsurancePlan.endpoint - can't find appropriate search parameter
Location:managingOrganization - maybe it must be Location:organization?
Location.partOf - it must be Location.partof
OrganizationAffiliation:primaryOrganization - it must be OrganizationAffiliation:primary-organization
OrganizationAffiliation:participatingOrganization - it must be OrganizationAffiliation:participating-organization
OrganizationAffiliation:healthcareService - maybe it must OrganizationAffiliation:service?
Practitioner:endpoint - can't find appropriate search parameter
PractitionerRole:healthcareservice - maybe it must be PractitionerRole:service?

BTW In CS Organization partof and endpoint search parameters are duplicated, could you please remove the duplicated ones?

Saul Kravitz (Aug 11 2020 at 14:58):

Not matching by their names is just my sloppiness -- apologies. My excuse is that there is really no validation on this beyond eyeballing it.
I'll fix these. Thanks for pointing this out.

Saul Kravitz (Aug 11 2020 at 18:11):

Everything you pointed out should be addressed at this point in the CI build. Thanks @Yengibar Manasyan again. Your feedback in priceless.

Yengibar Manasyan (Aug 11 2020 at 18:41):

@Saul Kravitz thank you!
Could you please fix this one as well?
InsurancePlan:coverage-area - can't find the appropriate search parameter.

Saul Kravitz (Aug 11 2020 at 19:07):

I think I had a typo, it may appear as InsurancePLan:coverage-area.
I pushed a fix.

Yengibar Manasyan (Aug 11 2020 at 20:02):

@Saul Kravitz thank you so much for very quick replies and fixes!
I have found another small issue, could you please check HealthcareService:provided-by revinclude? Seems we don't have such kind of search parameter, maybe it's HealthcareService:organization?

Saul Kravitz (Aug 11 2020 at 22:40):

@Yengibar Manasyan Fixed and pushed. Do you catch my sloppiness by visual inspection? Even with the mistakes it passes validation...sigh...THX. You've spared me the embarrassment of publishing a junky CapStmt. Look forward to buying you a beer one day.

Yengibar Manasyan (Aug 12 2020 at 14:42):

@Saul Kravitz thank you. I found them by visual inspection. Don't worry, I know it's hard to manage it. It would be great to have a drink with you.

Alexander L (Aug 20 2020 at 14:22):

Hi @Saul Kravitz, I noticed some inconsistency in searchInclude & searchRevInclude formatting in the Capability Statement. Sometimes resource name and param name are separated with ., sometimes with :, e.g.
"searchInclude": [
"Location:endpoint",
"Location:organization",
"Location.partof"
]
Could you please fix it? We are using this IG for some automatic processing, and that causes issues right now

Saul Kravitz (Aug 20 2020 at 15:11):

Thanks! Will fix...

Saul Kravitz (Aug 20 2020 at 15:11):

It should be colon-separated, right?

Alexander L (Aug 20 2020 at 16:32):

Yes, I believe so. In the US Core IG, it is colon-separated.

Alexander L (Aug 20 2020 at 16:37):

@Saul Kravitz, do you plan to release current version, so it will be available for download with the fixed version number like 0.1.0? http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml

Looks like there are a lot of changes which we performed since 0.1.0

Saul Kravitz (Aug 20 2020 at 16:51):

0.1.0 was the balloted version -- fixed
intervening versions are numbered 0.2-....
When we publish -- working to make this ASAP -- the STU1 will be 1.0. (fixed)

Saul Kravitz (Aug 20 2020 at 17:01):

Just pushed updated to capability statement. You should see it in the build shortly. Thanks for the correction. I don't have tools to validate the content of the capability statement in any meaningful way. Previous readers found a lot of issues based on eyeballing it, so glad you are using tools to keep me honest.

Alexander L (Aug 20 2020 at 17:02):

Thank you for the quick fix!

Kapil Bharti (Aug 20 2020 at 17:45):

Patient Access API- Can Terminated/Inactive members request their data via Third party applications leveraging Patient Access API?

Saul Kravitz (Aug 20 2020 at 18:30):

@Kapil Bharti probably best to pose questions via the davinci pdex plannet stream.....

ANyways, your question relates to interpretation of the CMS rule, so is outside of the scope of the IG.

Yengibar Manasyan (Sep 17 2020 at 15:18):

@Saul Kravitz could you please confirm that there is no missing data extension in Plannet like this one?
http://hl7.org/fhir/us/core/general-guidance.html#missing-data

Jason Teeple (Sep 21 2020 at 20:47):

Yengibar Manasyan said:

Saul Kravitz could you please confirm that there is no missing data extension in Plannet like this one?
http://hl7.org/fhir/us/core/general-guidance.html#missing-data

And can you confirm the version history? The latest IG version doesn't appear to be correct. Shows 0.1.3, was previously 0.3.0.

Yengibar Manasyan (Oct 05 2020 at 14:23):

@Saul Kravitz ?

Saul Kravitz (Oct 05 2020 at 14:28):

Hi @Yengibar Manasyan . I had numbered the versions incorrectly, and corrected that error. Current version is 0.1.3.

Will respond re missing-data. @Robert Dieterle

Aritra Kundu (Oct 19 2020 at 11:32):

Hi Team,

Was trying to send Coverage Plan resource to locally created HAPI FHIR server instance and getting the below error. I have installed all the required structure definitions and extensions. But still facing the same. Any help would greatly be appreciated. You can get the payload from here: http://hl7.org/fhir/us/Davinci-drug-formulary/List-covplanV1002.json.html

{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation Outcome</h1><table border=\"0\"><tr><td style=\"font-weight: bold;\">ERROR</td><td>[List, Line 1, Col 2]</td><td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-MarketingURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-SummaryURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-EmailPlanContact-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-Network-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-PlanIDType-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t</table>\n\t</div>"
},
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-MarketingURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-SummaryURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-EmailPlanContact-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-Network-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-PlanIDType-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
}
]
}

Aritra Kundu (Oct 19 2020 at 13:40):

Aritra Kundu said:

Hi Team,

Was trying to send Coverage Plan resource to locally created HAPI FHIR server instance and getting the below error. I have installed all the required structure definitions and extensions. But still facing the same. Any help would greatly be appreciated. You can get the payload from here: http://hl7.org/fhir/us/Davinci-drug-formulary/List-covplanV1002.json.html

{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h1>Operation Outcome</h1><table border=\"0\"><tr><td style=\"font-weight: bold;\">ERROR</td><td>[List, Line 1, Col 2]</td><td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-MarketingURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-SummaryURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyURL-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-EmailPlanContact-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-Network-extension is not allowed to be used at this point (allowed = e:; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t\t<tr>\n\t\t\t\t<td style=\"font-weight: bold;\">ERROR</td>\n\t\t\t\t<td>[List, Line 1, Col 2]</td>\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t<td><pre>The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-PlanIDType-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])</pre></td>\n\t\t\t\t\t\n\t\t\t\t\n\t\t\t</tr>\n\t\t</table>\n\t</div>"
},
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-MarketingURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-SummaryURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyURL-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-EmailPlanContact-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-Network-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
},
{
"severity": "error",
"code": "processing",
"diagnostics": "The extension http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-PlanIDType-extension is not allowed to be used at this point (allowed = e:*; this element is [[List])",
"location": [
"List",
"Line 1, Col 2"
]
}
]
}

@Lloyd McKenzie could you please help me with this.

Lloyd McKenzie (Oct 19 2020 at 14:50):

I don't know why you're getting the error, but I also don't know why PDex is defining the scope of all of these extensions as "*".

Saul Kravitz (Oct 21 2020 at 21:06):

The examples in the IG validated in their day with this context (as generated by CIMPL).
Is the validator getting finicky in its old age?

Saul Kravitz (Oct 21 2020 at 21:06):

@Chris Moesel

Chris Moesel (Oct 21 2020 at 21:09):

Once upon a time, our old tooling CIMPL used * as a wildcard in context. I don't recall well, but I suspect that there wasn't a lot of documentation on how to do it (and frankly, there still isn't) -- and we probably found some example somewhere that used * and assumed it was right (especially since validators did not complain at the time).

Lloyd McKenzie (Oct 21 2020 at 21:11):

says "this extension is allowed to be used in any context at all". There are some extensions where that's valid, but it's not what you generally want. And where it's not what you want, defining it that way means that the validator won't catch when you put the extension in places where it's not intended to be.

Chris Moesel (Oct 21 2020 at 21:13):

@Lloyd McKenzie -- in an offline conversation, @Saul Kravitz indicated that some validators (and people) are saying that * is not valid at all. So I was responding under the impression that * is actually invalid (rather than just not-best-practice).

Chris Moesel (Oct 21 2020 at 21:16):

In the absence of an author providing a specific Extension context, our tooling supplies the widest context possible. SUSHI does this too, but it uses [{ "type" : "element", "expression" : "Element" }] instead of the expression with *. I think we also found that in some examples somewhere, but if that's the wrong way to say "allowed anywhere" then we'd appreciate the feedback. I understand it's not good practice, but I believe it is valid and is really the only sensible default if an author does not provide a more specific context.

ryan moehrke (Oct 21 2020 at 23:40):

I see no mention of context in the extensibility page of the spec, nor any mention of wildcards in the (lackluster) descriptive text of StructureDefinition.context nor in the slightly more helpful definitions of the codes bound to StructureDefinition.context.type http://www.hl7.org/fhir/valueset-extension-context-type.html
which when i read the definitions looks to either have to match a ElementDefinition.id or Extension URI (i assume exactly) or use fhirPath which also has no mention of wildcards, and only uses * as a sign for multiplication.
unless my assumption of exact matching is misguided I don't see how * as a wildcard could be valid at all.

Lloyd McKenzie (Oct 22 2020 at 02:33):

It was. I think you now need to say 'Element'.

Yengibar Manasyan (Oct 22 2020 at 14:43):

@Saul Kravitz in the IG there are some search parameters that are listed in definitions JSONs but are missing in the capability statement.
Could you please check it?
There is a list of search parameters:
InsurancePlan->type
Organization->covrage-area
Practitioner->family
Practitioner->given

Saul Kravitz (Oct 22 2020 at 14:53):

Thx. Will check!

Saul Kravitz (Oct 23 2020 at 12:40):

Hi @Yengibar Manasyan :
I added to the capability statement:

- InsurancePlan:type
- Practitioner:family
- Practitioner:given

THis was in the CapabilityStatement, and in the IG:

- Organization:coverageArea

So, in v0.1.5 the CapStmt should be consistent with definition.json.

Thanks again for your careful review!

Yengibar Manasyan (Oct 23 2020 at 15:43):

@Saul Kravitz thank you for your quick response. Could you please fix the expression for InslurancePlan::name search parameter as well?
From name | alias to InslurancePlan.name | InslurancePlan.alias

Saul Kravitz (Oct 23 2020 at 16:01):

Why? Since alias is not a MS element, I'm tempted to just make it 'name'.

Yengibar Manasyan (Oct 23 2020 at 16:20):

I'm not 100% sure, but I think at least they must be consistent. You can check Organization::name search parameter, there we have Organization.name | Organization.alias. Unfortunately, I don't know what MS element means, that's why I can't comment on that part. Overall I think these are paths or expressions, even if you have 2 paths or expressions they must be consistent with other ones.

Saul Kravitz (Oct 23 2020 at 17:18):

But some of the search parameters don't have fully qualified field names...
I think the search parameter works as is, since our reference client allows search based on Organization name.
Are you having a problem with that search parameter on your server?

Saul Kravitz (Oct 23 2020 at 17:22):

MS element are elements marked as "Must Support" in the IG, see https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/implementation.html#must-support-1 . If an element has neither minimum cardinality >0, nor flagged as Must Support, the element is not expected to be provided by servers ur used by clients.
image.png
name is required (1..1)
alias is not required and not MS (0..1)

Yengibar Manasyan (Oct 23 2020 at 20:47):

Each expression must uniquely identify a field in a resource. Could you please bring an example of a non fully specified field name? In my opinion (I can be wrong) expressions must be identical, even the cardinality of the alias is 0..* it still has a concrete path and I don't see a reason why it shouldn't be InsurancePlan.alias. There are multiple other search parameters for the optional fields, I guess it's normal.

James Derrickson (Oct 26 2020 at 15:05):

For the OrganizationAffiliation profile - field Identifier - should it reflect the identifier for the participating (member of) Organization that performs the role (NPI) , the Parent Organization (TAXID) , or an identifier that is specific to their affiliation?

Lloyd McKenzie (Oct 26 2020 at 15:33):

@Brian Postlethwaite (Would probably be good to make the definition clearer too.)

Carie Hammond (Oct 26 2020 at 21:34):

Question - in the Plan-Net IG, Location.managingOrganization is a 0..1 cardinality, though the Capability Statement indicates that searches by managing.Organization must be supported. If an implementation is not supporting Location.managingOrganization at all, are they out of conformance b//c they should or should they simply not return that element at all and if they get a search request on a managingOrganization, simply reply with a not found? Or other guidance? Thx.

Lloyd McKenzie (Oct 26 2020 at 22:07):

Location.managingOrganization is flagged as mustSupport - that means that to comply, the system must be able to populate managingOrganization and send it at least some of the time. Cardinality reflects what must be in every single instance. Something being optional from a cardinality perspective doesn't mean that you don't have to support it.

Lloyd McKenzie (Oct 26 2020 at 22:07):

Obviously if you're searching by managingOrganization and the location doesn't have one/the organization isn't known, you won't find matches on those locations

Carie Hammond (Oct 26 2020 at 23:29):

Thanks Lloyd - that is clarifying.

James Derrickson (Oct 27 2020 at 18:49):

Lloyd McKenzie said:

Brian Postlethwaite (Would probably be good to make the definition clearer too.)

Any clarifying statement?

James Derrickson (Oct 27 2020 at 19:09):

We are using a valid code from the NUCC Taxonomy but we are getting a validation error on OrganizationAffiliation specialty - our code seems to line up with the examples in the implementation:

Sample of JSON:

"specialty" : [
{
"coding" : [
{
"system" : "http://nucc.org/provider-taxonomy",
"code" : "3336M0002X",
"display" : "Mail Order Pharmacy"
}
]
}

This is the error received:
FAILURE: 1 errors, 0 warnings, 1 notes
Error @ OrganizationAffiliation.specialty[0] (line 35, col6) : None of the codes provided are in the value set http://hl7.org/fhir/us/davinci-pdex-plan-net/ValueSet/SpecialtiesVS (http://hl7.org/fhir/us/davinci-pdex-plan-net/ValueSet/SpecialtiesVS), and a code from this value set is required) (codes = https://taxonomy.nucc.org#3336M0002X)
Information @ OrganizationAffiliation.specialty[0].coding[0] (line 37, col10) : Code System URI 'https://taxonomy.nucc.org' is unknown so the code cannot be validated

This is the validation script we used
mfortuna@USMBP16mfortuna Desktop % java -jar validator_cli.jar Test.json -version 4.0.1 -ig https://build.fhir.org/ig/HL7/davinci-pdex-plan-net -profile http://hl7.org/fhir/us/davinci-pdex-plan-net/StructureDefinition/plannet-OrganizationAffiliation

any insight ? All looks like it aligns with the example : https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/branches/master/OrganizationAffiliation-PharmChainAffil3.html

Daniel Venton (Oct 28 2020 at 13:08):

Are you sure your sample and the error are correlated? The sample has URI "system" : "http://nucc.org/provider-taxonomy", but the error says found: 'https://taxonomy.nucc.org'

Robert McClure (Oct 28 2020 at 20:58):

@James Derrickson I suspect you have the wrong code system canonical url in your sample. NUCC, as defined by HL7 HTA, has a canonical url of http://nucc.org/provider-taxonomy. And yes, that 404s

Yengibar Manasyan (Oct 30 2020 at 13:26):

@Saul Kravitz in Plan Net we don't have conformance expectations for modifiers. In some other IGs search parameters definitions, I see fake properties _modifier where we can find conformance expectations. Meanwhile, when I don't suggest adding that _modifier field, I want to clarify conformance expectations for the modifiers. As far as search parameters have conformance expectations and all of them right now are SHALLs, does it mean when we implement s search parameter we shall/have to implement specified modifiers for them as well?

Saul Kravitz (Oct 30 2020 at 13:33):

Modifiers, e.g., contains?

Get Outlook for iOS<https://aka.ms/o0ukef>

Yengibar Manasyan (Oct 30 2020 at 14:06):

@Saul Kravitz Yes. Specifically :above and :below modifiers for references. Should we support them or it's up to us? In other words when a search parameter (e.g. Endpoint->organization) has conformance expectation SHALL and had above and below modifiers, does it mean that these above and below modifiers as well have SHALL conformance expectation?

Todd Kovalsky (Oct 30 2020 at 14:23):

Hi - Everyone - thanks for putting this all together for the community. I was curious to know if there is a resource that gives guidance on how implementers can use the IGs to test the payer solutions for compliance? A compliance checklist of sorts, would be amazing :grinning_face_with_smiling_eyes:

Saul Kravitz (Oct 30 2020 at 14:32):

Contains seem reasonable. Above/below not. I'll drop the above/below on the references. The other modifiers are necessary for query (e.g., contains), but these are not in the directory context.

Jason Teeple (Oct 30 2020 at 16:12):

Saul Kravitz said:

Contains seem reasonable. Above/below not. I'll drop the above/below on the references. The other modifiers are necessary for query (e.g., contains), but these are not in the directory context.

Would this be true for the CARIN BB as well?

Yengibar Manasyan (Nov 05 2020 at 15:45):

@Saul Kravitz for Organization->coverage-area search parameter I see contains chained parameter. Is it a mistake or from where I can find info about Location->contains search parameter?

Saul Kravitz (Nov 05 2020 at 16:02):

Hi Yengibar, We dropped the Location:contains search parameter. I'll remove the contains chained parameter to restore consistency. Thanks for your comment.

Regards,
Saul

Yengibar Manasyan (Nov 05 2020 at 18:34):

Hi @Saul Kravitz thank you for getting back to me so quickly and for your support! In some cases, I see similar situations, when we don't have a search parameter for a resource, but we have a chained parameter. For example, you can check PractitionerRole->service and OrganizationAffiliention->service search parameters, both search parameters have identifier chained parameters, but HealthcareService doesn't have identifier search parameter. Maybe we must add identifier search parameter to HealthcareService or remove identifier from the chained parameter? If yes I can try to provide you full list of chained parameters for which we don't have appropriate search parameters.

Saul Kravitz (Nov 05 2020 at 18:40):

If you can provide me with a list of conflicts, I will address. Much thanks

Get Outlook for iOS<https://aka.ms/o0ukef>

Yengibar Manasyan (Nov 05 2020 at 19:14):

@Saul Kravitz this is the list of chained search parameters which doesn't have appropriate search parameters (please note that I may have spelling issue here, everything is handtyped and I hope that I didn't miss anything):
Endpoint->organization.identifier
HealthcareService->coverage-area.identifier
HealthcareService->endpoint.identifier
HealthcareService->endpoint.connection-type
HealthcareService->location.identifier
HealthcareService->organization.identifier
InsurancePlan->administreted-by.identifier
InsurancePlan->coverage-area.identifer
InsurancePlan->owned-by.identifer
InsurancePlan->owned-by.identifer
Location->endpoint.identifier
Location->endpoint.connection-type
Location->organization.identifier
Location->partof.identifier
OrganizationAffiliation->endpoint.identifier
OrganizationAffiliation->endpoint.connection-type
OrganizationAffiliation->location.identifier
OrganizationAffiliation->network.identifier
OrganizationAffiliation->participating-organization.identifier
OrganizationAffiliation->primary-organization.identifier
OrganizationAffiliation->service.identifier
Organization->coverage-area.identifier
Organization->coverage-area.contains
Organization->endpoint.identifier
Organization->endpoint.connection-type
Organization->partof.identifier
PractitionerRole->endpoint.identifier
PractitionerRole->endpoint.connection-type
PractitionerRole->location.identifier
PractitionerRole->network.identifier
PractitionerRole->organization.identifier
PractitionerRole->practitioner.identifier
PractitionerRole->service.identifier

Saul Kravitz (Nov 05 2020 at 19:20):

Thx. I’ll take care of these.

Get Outlook for iOS<https://aka.ms/o0ukef>

Yengibar Manasyan (Nov 16 2020 at 15:38):

@Saul Kravitz have you had a chance to check my comments from my previous message?

Saul Kravitz (Nov 16 2020 at 15:47):

We addressed your (good) comments, no?

Yengibar Manasyan (Nov 16 2020 at 16:12):

@Saul Kravitz I mean my last comment about chained search parameters which doesn't have appropriate search parameters. Where or when it was addressed? Last commit which I see is 0.1.7 where nothing is done related with chained parameters.

Saul Kravitz (Nov 16 2020 at 20:09):

Hi @Yengibar Manasyan -- sorry, take a look at https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/branches/v0.1.8/ .
It hasn't been released as CI build, pending final approval, but I expect it to be released as such.

Yengibar Manasyan (Nov 16 2020 at 20:17):

Hi @Saul Kravitz , just checked this branch: https://github.com/HL7/davinci-pdex-plan-net/tree/v0.1.8
Looks good, thank you again for taking care of these issues for me!!!

Yengibar Manasyan (Nov 18 2020 at 15:27):

Hi @Saul Kravitz, seems accidentally you have added C4BB (I assume Carin BB) to Plan Net: fsh/ig-data/input/resources/capabilitystatement-c4bb.json. Could you please delete it?

Saul Kravitz (Nov 18 2020 at 16:38):

Sigh. Thanks for watching out for me. Deleted. Rebuilding now.

Hoddy Mahon (Nov 24 2020 at 18:26):

James Derrickson said:

For the OrganizationAffiliation profile - field Identifier - should it reflect the identifier for the participating (member of) Organization that performs the role (NPI) , the Parent Organization (TAXID) , or an identifier that is specific to their affiliation?

@James Derrickson has this been answered? what did you do?

Hoddy Mahon (Nov 24 2020 at 18:27):

what is the difference between “partOf” on the Organization profile vs “participatingOrganization” on the OrganizationAffiliation profile?

Lloyd McKenzie (Nov 25 2020 at 23:09):

@Brian Postlethwaite Organization.partOf really should have a usage note that explains the difference or at least points to the OrganizationAffililation differentiation. @Hoddy Mahon, the best description of the difference is here: https://build.fhir.org/organizationaffiliation.html#bnr

Hoddy Mahon (Dec 01 2020 at 15:46):

thank you Lloyd!

Saul Kravitz (Dec 01 2020 at 16:32):

I don't disagree with @Lloyd McKenzie on the need for more documentation.

organization.partOf reflects hierarchy/composition of organizations. See the relationship between http://build.fhir.org/ig/HL7/davinci-pdex-plan-net/Organization-HamiltonClinic.html and http://build.fhir.org/ig/HL7/davinci-pdex-plan-net/Organization-Hospital.html .

OrganizationAffiliation is really about the organization identified through the participatingOrganization reference -- "Organization that provides/performs the role (e.g. providing services or is a member of)" -- rather than the organization reference -- "Organization where the role is available". The other references in OrganizationAffiliation affiliate the participatingOrganization with healthcareServices, networks, locations, etc and describe its role.

Vibin_chander (Dec 02 2020 at 12:21):

Hi is it 'must' that we should follow Davinci pdex profiles strictly for Provider directory API implementation? as a part of CMS rule?

Kyle Brew (Dec 07 2020 at 14:50):

Hi @Saul Kravitz or others - quick question about Plan Net searches. So I see in the IG the section on representing the data and searches - http://build.fhir.org/ig/HL7/davinci-pdex-plan-net/implementation.html#representing-and-searching-provider-directory-data

I'm wondering what the API search queries the server must support look like in practice. For instance for the first row, General Search, Pharmacy > HealthcareService.category, HealthcareService.specialty > Location, network, what would an example query search look like for that row?

Apologies if this was previously discussed but I didn't see it in the stream above.

Saul Kravitz (Dec 07 2020 at 16:07):

@Kyle Brew -- good question. The best/only way to see the queries in action is via the client reference implementation, which unfortunately is off the air for now. Stay tuned. We are working to get it back up.

Kyle Brew (Dec 07 2020 at 16:36):

@Saul Kravitz - understood we'll stay tuned. In the meantime, could you just describe a simple example of searching a HealthcareService by category and location? Would that require the server to support _revinclude to get from HealthcareService to referenced Location resources ? Or maybe totally off base there

Saul Kravitz (Dec 07 2020 at 17:02):

These are the queries used by the reference client:
1) searching for pharmacies by network, specialty:
https://davinci-plan-net-ri.logicahealth.org/fhir/Location?_has:OrganizationAffiliation:location:network=Organization/plannet-network-HPID010000&_has:OrganizationAffiliation:location:role=pharmacy&_has:OrganizationAffiliation:location:specialty=3336C0003X&_revinclude=OrganizationAffiliation:location
This requires some filtering of the returned locations due to the limits of reverse chaining.
2) Searching for hospitals near a zipcode via 'general':
https://davinci-plan-net-ri.logicahealth.org/fhir/HealthcareService?_include=HealthcareService%3AprovidedBy&_include=HealthcareService.location&location.address-postalcode=06095%2C06040%2C06074%2C06101%2C06160%2C06088%2C06043%2C06028%2C06248%2C06108%2C06232%2C06156%2C06155%2C06183%2C06238%2C06105%2C06154%2C06118%2C06109%2C06120%2C06106%2C06066%2C06016%2C06115%2C06161%2C06041%2C06029%2C06103%2C06033%2C06025%2C06073%2C06114%2C06112&service-category=hosp"
3) Searching for an Anesthesiologist in a zipcode within a network:
https://davinci-plan-net-ri.logicahealth.org/fhir/PractitionerRole?_include=PractitionerRole:practitioner&_include=PractitionerRole:location&location.address-postalcode=01508,01550,01566&network=Organization/plannet-network-HPID010000&specialty=207L00000X

Kyle Brew (Dec 07 2020 at 23:30):

Perfect - thank you @Saul Kravitz - very helpful

Anirudh Choudhary (Dec 14 2020 at 18:39):

Jennifer Grill (Apr 08 2021 at 18:34):

Vibin_chander said:

Hi is it 'must' that we should follow Davinci pdex profiles strictly for Provider directory API implementation? as a part of CMS rule?

Did you ever get a response to this question?

Nathan Loyer (Aug 06 2021 at 15:01):

This is still an issue in two of the capability statement examples. Inferno is testing with values like "Location:organization" and not "Location.organization" so that is what we intend to follow.

Nathan Loyer (Aug 06 2021 at 15:04):

sorry I was responding to this from search results, I didn't realize there were so many other messages in here. I should start a new thread. For context I was responding to this message
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Davinci.20Pdex.20Plan.20Net/near/207527468

Mike Sabin (Nov 24 2021 at 17:25):

Was there a replacement project or effort for CIMPL?

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Davinci Pdex Plan Net · implementers

Stream: implementers

Topic: Davinci Pdex Plan Net

Yengibar Manasyan (Jun 08 2020 at 21:43):

Saul Kravitz (Jun 09 2020 at 18:04):

Aleksandr Teterin (Jun 12 2020 at 16:37):

Saul Kravitz (Jun 12 2020 at 19:57):

Igor Sirkovich (Jun 12 2020 at 20:48):

Saul Kravitz (Jun 12 2020 at 21:33):

Robert McClure (Jun 15 2020 at 17:16):

Yengibar Manasyan (Jun 19 2020 at 17:14):

Saul Kravitz (Jun 19 2020 at 18:14):

Yengibar Manasyan (Jun 26 2020 at 21:19):

Yengibar Manasyan (Jun 30 2020 at 20:39):

Saul Kravitz (Jun 30 2020 at 20:43):

Saul Kravitz (Jun 30 2020 at 21:14):

Robert Dieterle (Jun 30 2020 at 21:38):

Yengibar Manasyan (Jul 01 2020 at 15:05):

Yengibar Manasyan (Jul 27 2020 at 17:07):

Saul Kravitz (Jul 27 2020 at 17:39):

Yengibar Manasyan (Jul 28 2020 at 15:55):

Alexander L (Jul 28 2020 at 19:34):

Lloyd McKenzie (Jul 28 2020 at 19:38):

Alexander L (Jul 28 2020 at 19:42):

Lloyd McKenzie (Jul 28 2020 at 19:43):

Alexander L (Jul 28 2020 at 19:51):

Alexander L (Jul 28 2020 at 20:53):

Saul Kravitz (Jul 28 2020 at 20:56):

Yengibar Manasyan (Jul 29 2020 at 17:37):

Yengibar Manasyan (Jul 30 2020 at 15:32):

Saul Kravitz (Jul 30 2020 at 16:16):

Yengibar Manasyan (Jul 30 2020 at 21:23):

Saul Kravitz (Jul 31 2020 at 14:42):

Saul Kravitz (Jul 31 2020 at 14:42):

Yengibar Manasyan (Jul 31 2020 at 20:25):

Saul Kravitz (Jul 31 2020 at 22:24):

Yengibar Manasyan (Aug 01 2020 at 02:55):

Saul Kravitz (Aug 02 2020 at 20:56):

Yengibar Manasyan (Aug 04 2020 at 15:56):

Saul Kravitz (Aug 04 2020 at 19:35):

Saul Kravitz (Aug 04 2020 at 21:59):

Yengibar Manasyan (Aug 10 2020 at 18:28):

Saul Kravitz (Aug 10 2020 at 19:04):

Saul Kravitz (Aug 10 2020 at 19:13):

Yengibar Manasyan (Aug 10 2020 at 19:16):

Yengibar Manasyan (Aug 10 2020 at 19:25):

Saul Kravitz (Aug 11 2020 at 14:58):

Saul Kravitz (Aug 11 2020 at 18:11):

Yengibar Manasyan (Aug 11 2020 at 18:41):

Saul Kravitz (Aug 11 2020 at 19:07):

Yengibar Manasyan (Aug 11 2020 at 20:02):

Saul Kravitz (Aug 11 2020 at 22:40):

Yengibar Manasyan (Aug 12 2020 at 14:42):

Alexander L (Aug 20 2020 at 14:22):

Saul Kravitz (Aug 20 2020 at 15:11):

Saul Kravitz (Aug 20 2020 at 15:11):

Alexander L (Aug 20 2020 at 16:32):

Alexander L (Aug 20 2020 at 16:37):

Saul Kravitz (Aug 20 2020 at 16:51):

Saul Kravitz (Aug 20 2020 at 17:01):

Alexander L (Aug 20 2020 at 17:02):

Kapil Bharti (Aug 20 2020 at 17:45):

Saul Kravitz (Aug 20 2020 at 18:30):

Yengibar Manasyan (Sep 17 2020 at 15:18):

Jason Teeple (Sep 21 2020 at 20:47):

Yengibar Manasyan (Oct 05 2020 at 14:23):

Saul Kravitz (Oct 05 2020 at 14:28):

Aritra Kundu (Oct 19 2020 at 11:32):

Aritra Kundu (Oct 19 2020 at 13:40):

Lloyd McKenzie (Oct 19 2020 at 14:50):

Saul Kravitz (Oct 21 2020 at 21:06):

Saul Kravitz (Oct 21 2020 at 21:06):

Chris Moesel (Oct 21 2020 at 21:09):

Lloyd McKenzie (Oct 21 2020 at 21:11):

Chris Moesel (Oct 21 2020 at 21:13):

Chris Moesel (Oct 21 2020 at 21:16):

ryan moehrke (Oct 21 2020 at 23:40):

Lloyd McKenzie (Oct 22 2020 at 02:33):

Yengibar Manasyan (Oct 22 2020 at 14:43):