Stream: Da Vinci/plan-net-connectathon
Topic: Is there a canonical representation for a Statewide Coverage
Saul Kravitz (Sep 11 2020 at 14:35):
1) As in the examples -- create a Location instance with the State specified, and possibly a GeoJSON
2) In the reference, include the state name (or 2 char symbol) in the display/reference strings
Should one of these be the canonical approach?
Saul Kravitz (Sep 11 2020 at 16:02):
@Robert Dieterle
Saul Kravitz (Sep 11 2020 at 18:04):
#1 is preferred -- since it is not subject to interpretation by a 3rd party querying the data.
#2 required the 3rd party to understand the encoding of the display/reference strings.
Saul Kravitz (Sep 14 2020 at 22:26):
Added implementation note in Location, Network, InsurancePlan, and HealthcareService.
Kristin Ashby (Sep 16 2020 at 23:22):
@Saul Kravitz In the Insurance Plan (or Network).coverage area refer to the provider coverage area or the eligiblity? Example: Medicare elig is county by county, but the providers are nationwide. How should we return coverage area in this instance? Noted: coverage area is also present under InsurancePlan.plans.coverage area.
Saul Kravitz (Sep 17 2020 at 00:35):
@Robert Dieterle @Gail Kocher
Robert Dieterle (Sep 17 2020 at 02:50):
Network.coverage area refers to the geographic area the network covers
InsurancePlan.coverage area refers to the geographic area where the plan is available
A plan may be for all of a state, but the network may only be for part of the state.
BTW Medicare ffs is nationwide but a provider is only available in the state(s) where the have a valid license
Kristin Ashby (Sep 22 2020 at 20:56):
@Robert Dieterle Another question, we have found that Medicare eligibility is by both County and State. How do we map InsurancePlan.coveragearea to allow 3rd Party apps to search available plans by coverage area when both state and county should be specified? Can we link in both through the reference.
Robert Little (Sep 23 2020 at 21:28):
Good afternoon @Saul Kravitz @Robert Dieterle , I would like to see if there is any way to include a collection of insurancePlan references into PractitionerRole & OrganizationAffiliation resources. I have completed some analysis of customer data on our end and noticed that we have, at least one customer, that has a national network that supports their Medicare line of business. In our case, this national network does not directly tie into the list of Networks provided by the plan. In this case, it’s more of an inferred network that is applied when a search is conducted in our application via the Product/Plan the member has. The other thing we are noticing is, in some cases, there are over 90 Networks that make up a single Product/plan. The concern for this is around managing those 90+ networks and system load when the member or third-party system is trying to conduct a search.
Saul Kravitz (Sep 23 2020 at 21:38):
@Gail Kocher
Saul Kravitz (Oct 01 2020 at 14:57):
@Robert Little
Is there a reason you can't combine the 90+ networks into a single (or a smaller number) of networks?
If not, the client will need to iteratively query using a subset of the networks (first 10, next 10, etc).
Robert Little (Oct 01 2020 at 15:12):
Good morning @Saul Kravitz , we do that already with our Plan's/Product's. We combine any number of networks into a single value for searching purposes and relevance to the member. However, the way the IG is written, we need to search by network and not Product which is why we are running into this problem.
Saul Kravitz (Oct 02 2020 at 15:17):
@Robert Little So you are saying that in your model the association of practitioners/organizations to a network, is essentially an association to a product? In Plan-Net (as per VhDir) the association between InsurancePlan (product with associated plans) to Networks is potentially many-to-many.
Robert Little (Oct 02 2020 at 16:18):
Good morning @Saul Kravitz , The Product to Network relation on our side can be many to many but here is what we normally tend to see in the data we get from our customers:
image.pngProduct_Code/Plan Product_Name Network_Code Network_Name
P123456 Product Name_1 N12365 Network Name_0
P123456 Product Name_1 N12366 Network Name_1
P123456 Product Name_1 N12367 Network Name_2
P123456 Product Name_1 N12368 Network Name_3
P123456 Product Name_1 N12369 Network Name_4
P567891 Product Name_2 N12368 Network Name_3
P567891 Product Name_2 N12369 Network Name_4
PC123456 Product Name_3 Net1563 Network Name_5
In this relationship, we also have for some customers a National network attribute that infers that Product has a form of national data to support it. On our application, when the user searches on the Product/Plan, we are able to pull in all the local providers as defined by the Network to Product mapping and then infer the National Providers outside of the area covered by local providers.
Saul Kravitz (Oct 02 2020 at 18:37):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
