Stream: Da+Vinci+PDex+Plan-Net
Topic: General Discussions
Josh Lamb (Apr 02 2020 at 00:07):
We can split this up if the stream is too broad, but I thought it would be good for people to have an opportunity to discuss topics outside of work group meetings.
I have a few topics that I have questions about:
1.) The endpoint resource: I am struggling to understand how a published endpoint (e.g. a Organization, PractitionerRole, or Location endpoint) would provide functional use. I would imagine that any published endpoint would need to adhere to an IG in order to receive data in a manageable format and to respond in a predictable way to submitted data. Could this be addressed in a future iteration of the IG?
2.) Overlap of Organization, Practitioner, and PractitionerRole resources between CARIN BB and PlanNet IGs: Since CARIN BB is utilizing US core profiles but the PlanNet IG is further constraining these resource types it is likely that many implementers will reuse these resources between the two IGs. One implementation that I am pondering is to reference a specific instance of a practitioner, organization, or practitionerRole within claims data. I am curious if others have thoughts on how these three resources (or perhaps others) can be shared between the two IG's given that PlanNet will impose more strict restrictions on the profiles than the restrictions present in US Core.
3.) Status restriction of active only on profiles: Does this restriction extend to the "active" boolean flag? Could this be handled through search rather than through profile constraints? The reason behind this suggestion is that a search restriction would allow the profile assertions to remain valid regardless of status. My thought was that claims data would reference the same resources that are delivered through the PlanNet IGs since payers are required to implement both IGs at the same time. Constraining the PlanNet resources to only Active statuses seems like it may limit the versatility of resources that contain the profiles defined in PlanNet.
Let me know if any of my questions need clarification or if I am missing anything.
Saul Kravitz (Apr 02 2020 at 15:47):
Hi Josh,
Your points #2 and #3 seem to conflate the way that you would manage the data internal to your enterprise, with they way you would present the data for different use cases. To use an MVC analogy, you would need your model to support both use cases (and probably many more), but present two different views, one for members in a directory, and one for members as claims dat#R3/R4 Conversion work
re #1: I agree that IG and the limited examples leave a lot of questions regarding how one would use this resource unanswered. I'll try to elucidate with help from @Robert Dieterle
Josh Lamb (Apr 02 2020 at 17:45):
Thanks @Saul Kravitz , I will continue to think this through. I am inclined to agree and I may have to modify my presuppositions i came into this project with.
Josh Lamb (Apr 02 2020 at 17:48):
Question from some others: Would we ever communicate a provider who does not show in a health plan provider directory, who is otherwise active? There are mechanisms where an active provider can request to be omitted from the health plan directory (not sure at this time why a provider would do this).
Saul Kravitz (Apr 03 2020 at 17:35):
This question sounds like (for those of you old enough to remember phone books): Would we ever call an unlisted number?
Yes, but we had to get the phone number through an informal channel.
Josh Lamb (Apr 23 2020 at 15:01):
@Saul Kravitz , minor question, should we have MustSupport flags on Practitioner for Address, Contact, and BirthDate? The health plans may have this info but they would not make it publicly available. I mention contact/address since it is defined as a home address for a Practitioner. Birthdate seems like an unnecessary exposure of PII.
Saul Kravitz (Apr 23 2020 at 15:17):
Hi @josh lamb , Good questions. Will get back to you.
You mean Practitioner.telecom, right? (There is no Practitioner.contact)....
@Robert Dieterle
Josh Lamb (Apr 23 2020 at 15:18):
Yes, telecom, sorry.
Saul Kravitz (Apr 27 2020 at 19:24):
https://jira.hl7.org/browse/FHIR-26941
Josh Lamb (Jun 03 2020 at 18:44):
@Saul Kravitz and @Robert Dieterle, on the accessibility extension (https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-accessibility.html) there is a broken link for the accessibility valueset (http://hl7.org/fhir/uv/vhdir/ValueSet/accessibility).
I wanted to make sure someone knew about this. Thanks!
Josh Lamb (Jun 03 2020 at 18:50):
I am also not sure of the purpose of the newpatientprofile specified here: (https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-newpatientprofile.html). Is the idea to just provide a free form string of text describing the conditions under which a new patient will be accepted?
Saul Kravitz (Jun 03 2020 at 20:02):
Re: broken link. ALready fixed. Will be visible next time the CI build is published. Thanks for pointing it out.
Re newpatientprofile: Based on discussions that happened long before my time as part of the VhDir definition, a decision was made not to attempt to provide a structured definition of the new patient criteria. Some of those criteria would be evident in the associated health care service. For example, a pediatrics service obviously wouldn't target geriatric patients. This is on our agenda for the Thursday VS meeting...if we get to it.
Josh Lamb (Jun 04 2020 at 02:26):
Thanks @Saul Kravitz , One more for you. Are we removing the Must support on Organization.Qualification or redoing the codeset? The codeset is using taxonomies when Licenses and other qualifications seem more relevant to an organization.
Saul Kravitz (Jun 04 2020 at 13:07):
Yes, MS will be removed on the qualification extensions, AND VS will be redone.
The VS is currently NUCC Provider Taxonomy (- a couple of rogue codes) + DegreesLicensesAndCertificates (http://terminology.hl7.org/CodeSystem/v2-0360|2.7)...subject to change by Gail and Rob.
Josh Lamb (Jun 04 2020 at 15:52):
@Saul Kravitz and @Robert Dieterle : Removing qualification extension and references to it from Organization and Practitioner seems like a good move. If we do this, how will we represent the status of the qualification or the states that the qualification is valid?
Saul Kravitz (Jun 04 2020 at 16:38):
Must Support will be dropped. Extension will remain.
Sudheesh Thuruthiyil (Apr 21 2021 at 18:38):
Going through this old thread now because we are implementing FHIR server for a client. The use case is to exclude certain providers from showing up in the provider directory. We would like to use the active flag on the plannet profiles to set to false. It appears you have mandated to have this contain a "True" always. Is there a workaround? Appreciate the help. @Josh Lamb @Saul Kravitz
Saul Kravitz (Apr 22 2021 at 14:58):
Please create new issues with the subject line expressing a summary.
Last updated: Apr 12 2022 at 19:14 UTC
