hundreds of duplicate ignite endpoints

[Tim Harsch]

Hello,

   I've been working with the data in the Github repo for Ignite Endpoints that is publicly available. Thanks to recent updates that are a lot of new endpoints and a new format for representing the endpoints.   While working with the data I noticed that some endpoints have the same name, and same address but have multiple endpoint URLs.  In some cases there are 4 or 5 duplicate entries per provider.  I can't see how these endpoints differ from each other, other than the URLs, and as such, I don't know how to direct our users to the proper system.

I'd really appreciate it if someone can help me understand these duplicates.

The complete list of duplicates can be found in this CSV file that I created after getting the data into a database table and writing some SQL to come up with the list.  Most of the data from the JSON is present, and you can clearly see the issue when looking at the spreadsheet:

https://github.com/timharsch/ignite-endpoints/blob/dstu2_duplicates/millennium_patient_dstu2_endpoints.duplicates.csv

Your help is appreciated!

Thanks,

Tim

[Michele Mottini]

See also https://github.com/cerner/ignite-endpoints/issues/13 

  - Michele

  CareEvolution

[Andrew Fagan (Cerner)]

Every entry in the endpoint list represents a FHIR enabled Millennium domain. While some appear as duplicate because of names and address, the clients have multiple domains which is why you see multiple entries in the list. There are many reasons for a client to have multiple domains.  For example, larger regionally separated clients will have domains localized to a region or a client may expand through merger/acquisition adding to their domain total. While we are working on a better way to convey how Cerner clients have divided their implementation across multiple domains, there is not a consistent divide and the best way to understand the differences is to work with the health system directly. 

Andrew (Oracle Cerner)

[Tim Harsch]

Thank you Andrew!  I appreciate you taking the time to shed some light on the topic.

I can see why providing a consistent way to describe how a health system has partitioned their domains would be a difficult thing to include in the ontology of the endpoints JSON.  I'll look forward to Cerner's improved methods of describing provider domains.  In the mean time, I'm sure I'll come up with some work around way to disambiguate these servers for our users.

While I appreciate your suggestion to work directly with health systems to better understand the differences in the domains, with the current information provided today that's nearly impossible.  The address information provided in the endpoints list is certainly a welcomed addition, but I suspect more often than not the address is either the main office location for a provider, or the front door to a large facility for health care and provides the consumer only with a sense of where the facility is located.  It's not likely a good jumping off point to find a human, or help service, behind the server... or an avenue for working with the provider when clarity is needed on the system.   Even the login screens for the system are generally no help in this regard, since they only offer the login inputs and usually no other links to guide user's attempting to access the system.  Perhaps a future version of Cerner login screens and/or endpoints JSON can provide improved contact details for the managing organization, giving the user's of these systems a way to reach out when help is needed, or servers are down, etc.

Thanks for again for the insights.

Tim