FHIR Chat · Connectathon Provider Directories · implementers

Stream: implementers

Topic: Connectathon Provider Directories

Brian Postlethwaite (May 07 2016 at 15:07):

Hey All, if you're doing Provider Direcrtory/Scheduling stuff, please ask your questions here!

Ron Shapiro (May 07 2016 at 15:13):

Thanks Brian

Ron Shapiro (May 07 2016 at 15:14):

Any servers have any hints for querying their "Provider Directory" for Practitioner or HealthcareService resources?

Michael Donnelly (May 07 2016 at 15:27):

https://open-ic.epic.com/Argonaut-Unsecure/api/FHIR/Connectathon/Practitioner?name=argonaut

Brian Postlethwaite (May 07 2016 at 15:28):

In the DSTU2 space there is a server provided by Michigan Health Information Network (MiHN) that has some good data to test with at:
http://52.72.172.54:8080/fhir/home

Brian Postlethwaite (May 07 2016 at 15:34):

Example query to search for organizations in the city of chicago
http://52.72.172.54:8080/fhir/baseDstu2/Organization?address-city=chicago

Brian Postlethwaite (May 07 2016 at 16:18):

Example query for Practitioner with a family name starting with an
http://52.72.172.54:8080/fhir/baseDstu2/Practitioner?family=an

Ron Shapiro (May 07 2016 at 16:26):

@Michael Donnelly , what are other search options that can be used other than 'name'?

Michael Donnelly (May 07 2016 at 16:27):

Hang on, I'll take a look

Michael Donnelly (May 07 2016 at 16:27):

A bunch of variants of name, but they aren't any more interesting.

Michael Donnelly (May 07 2016 at 16:27):

And specialty, but we don't have the mapping yet

Michael Donnelly (May 07 2016 at 16:28):

But you can do it by text - I'll get you a URL

Michael Donnelly (May 07 2016 at 16:30):

https://open-ic.epic.com/Argonaut-Unsecure/api/FHIR/Connectathon/Practitioner?specialty=internal+medicine

Brian Postlethwaite (May 07 2016 at 18:06):

The current argonaut work covering practitioner is here:
http://argonautwiki.hl7.org/index.php?title=Practitioner

Michael Donnelly (May 07 2016 at 18:44):

I updated our practitioner to contain the locations at the practitioner level

Michael Donnelly (May 07 2016 at 18:44):

Please take a look at your convenience. https://open-ic.epic.com/Argonaut-Unsecure/api/FHIR/Connectathon/Practitioner/TVWI.AzHs7ngn.kPyaQJ5DAB

Scott Brown (May 07 2016 at 19:38):

We now have a server running that is available on the Web. Here is the URL: http://argo.eastus.cloudapp.azure.com/ArgonautServer/

Brian Postlethwaite (May 07 2016 at 20:16):

Example Direct address extension for the Practitioner role telecom

Brian Postlethwaite (May 07 2016 at 20:16):

<telecom> <extension url="us-direct"> <valueBoolean value="true" /> </extension> <system value="email" /> <value value="jargonaut4751@open.epic.com" /> </telecom>

Brian Postlethwaite (May 07 2016 at 20:32):

Hi Team, Here is a more complete example of a practitioner resource for Argonaut, thoughts?

<Practitioner xmlns="http://hl7.org/fhir">
    <id value="argoprac" />
    <identifier>
        <use value="usual" />
        <system value="PROVID" />
        <value value="50jyx0" />
    </identifier>
    <active value="true" />
    <name>
        <use value="usual" />
        <text value="Jason Argonaut, MD" />
        <family value="Argonaut" />
        <given value="Jason" />
        <prefix value="Dr" />
        <suffix value="MD" />
    </name>
    <gender value="male" />
    <practitionerRole>
        <organization>
            <display value="open.epic.com sandbox" />
        </organization>
        <specialty>
            <coding>
                <system value="http://www.nucc.org/" />
                <code value="207P00000X" />
                <display value="Emergency Medicine" />
            </coding>
            <text value="Emergency Medicine" />
        </specialty>
        <telecom><system value="phone" /><value value="608-555-0001" /></telecom>
        <telecom>
            <extension url="us-direct">
                <valueBoolean value="true" />
            </extension>
            <system value="email" />
            <value value="jargonaut4751@open.epic.com" />
        </telecom>
        <telecom><system value="fax" /><value value="608-555-0002" /></telecom>
        <location>
            <display value="Madison General Hospital" />
            <reference value="Location/mgh" />
        </location>
    </practitionerRole>
    <!-- Communications would go here where the practitioner speaks languages other than the organizations default language (where used) -->
</Practitioner>

Grahame Grieve (May 07 2016 at 20:33):

where's the extension?

Brian Postlethwaite (May 07 2016 at 20:34):

Extension on the telecom has a dud extension url, need to get that agreed. But base content structure is here

Ron Shapiro (May 07 2016 at 20:49):

The MiHIN server uses a different extension, not sure of the background for theirs, but it is different that the one you are proposing.

    "entry":[
        {
            "fullUrl":"http://52.72.172.54:8080/fhir/baseDstu2/Practitioner/Practitioner-18716",
            "resource":{
                "resourceType":"Practitioner",
                "id":"Practitioner-18716",
                "extension":[
                    {
                        "url":"http://org.mihin.fhir.extension.electronic-service",
                        "valueReference":{
                            "reference":"ElectronicService/ElectronicService-8479",
                            "display":"Natalie.H.Zavala@direct.mihintest.org"
                        }
                    }
                ],
                "name":{
                    "family":[
                        "Zavala"
                    ],
                    "given":[
                        "Natalie",
                        "Huynh"
                    ],
                    "suffix":[
                        "MD"
                    ]
                },
                "telecom":[
                    {
                        "system":"phone",
                        "value":"616.555.9834",
                        "use":"home"
                    }
                ],
            },
        }

Michael Donnelly (May 07 2016 at 20:52):

Should this be a prefix? <suffix value="Dr" />

Brian Postlethwaite (May 07 2016 at 20:59):

Thanks Michael, updated.

Brian Postlethwaite (May 07 2016 at 21:00):

Thanks Ron, we had a quick discussion on this, and yes. I believe we will need more discussion on this as we move into the endpoint review.

Ron Shapiro (May 08 2016 at 14:06):

In the contexts of a healthcare worker searching for another provider (eg. for a referral) or a patient looking for a specialist, it is important to be able to search by:
- partial name (family or given)
- exact name (family or given)
- specialty
- address-city
- address-postalCode (with distance)

Ron Shapiro (May 08 2016 at 14:06):

After performing various queries of the servers, I have the following observations to make:

Ron Shapiro (May 08 2016 at 14:06):

Ron Shapiro (May 08 2016 at 14:06):

Ron Shapiro (May 08 2016 at 14:07):

Ron Shapiro (May 08 2016 at 14:07):

Questions for discussion:

1) Shouldn't both partial and exact name searches always be supported?
2) Shouldn't specialty searches always be supported? Should they be supported by text only or would searching by specialty codes also be helpful?
3) Shouldn't proximity searches be triggered by postal code instead of latitude and longitude? One could argue that it is trivial to find lat/long for postal code and so the client could just as easily discover the lat/long for a postal code as the server.

Michael Donnelly (May 08 2016 at 14:19):

If you want to try provider directory download from Epic: https://open-ic.epic.com/Argonaut-Unsecure/api/FHIR/Connectathon/Practitioner?name=*&_count=200

Kevin Paprocki (May 08 2016 at 14:30):

<entry>
<resource>
<Location>
<identifier>
<system value="http://www.surescripts.com/location"/>
<value value="106"/>
</identifier>

Kevin Paprocki (May 08 2016 at 14:30):

vs this

Kevin Paprocki (May 08 2016 at 14:30):

<contained>
<Location>
<id value="T9Np20ZWMtZTYwVIkYwX7RLOH-9j7Qbu.tpr1cueEWYUB"/>

Brian Postlethwaite (May 08 2016 at 14:43):

Michael, for that download can you do it without the wildcard? seems strange

Brian Postlethwaite (May 08 2016 at 14:44):

Not sure what you're asking there Kevin, the Identifiers collection are business identifiers, the Id is the system assigned unique ID, could consider it the primary key in that system.

Brian Postlethwaite (May 08 2016 at 14:44):

Contained resources its just unique inside the resource

Brian Postlethwaite (May 08 2016 at 15:13):

Hey team, remember to update the results spreadsheet with what you got done during the day and a half!
https://docs.google.com/spreadsheets/d/1gAnNmyurFDopLYJakQOtXWYGxvuoiDn49n8qRI5mlb4

Scott Brown (May 08 2016 at 15:43):

Ron, the Surescripts server did implement address-city and address-state searches, and the search works fine, so I'm not sure what you did.

Ron Shapiro (May 08 2016 at 15:48):

Scott, can you provide examples? Perhaps I just couldn't find the right city/state to use

Michael Donnelly (May 08 2016 at 15:51):

@Brian Postlethwaite It works without the wild card now. https://open-ic.epic.com/Argonaut-Unsecure/api/FHIR/Connectathon/Practitioner?_count=200

Ron Shapiro (May 08 2016 at 15:54):

I found some cities and states that worked... had to just use trial and error though, since the address information is not returned (embedded in Location resource, I suppose)

Scott Brown (May 08 2016 at 15:55):

Ron, we use state postal abbreviations (CT, GA, etc.) The city names are pretty obscure so I can see why didn''t find any ("Merrillville") In _include add "practitioner:practitionerRole.location" and then do an open search and you will see all the address at the end.

Michael Donnelly (May 08 2016 at 15:55):

Anyone interested in volume testing with our server?

Michael Donnelly (May 08 2016 at 15:58):

I've got 10k records there now, but if you want more I can easily generate them.

Scott Brown (May 08 2016 at 15:58):

We have speciallties in our search too, but you have to include the system. You can try "http://www.nucc.org|208800000X"

Scott Brown (May 08 2016 at 15:59):

I think we could tweak it default to NUCC codes.

Scott Brown (May 08 2016 at 16:11):

Ron, in regard to your (very good) discussion points. 1) I think it should depend upon the conformance statement. (That said our conformance document does say we support exact searches... whoops :) 2) It certainly makes sense to have always them. 3) Zip code or city/state searches are much harder (and slower) to do, because they require geographic resolution of the parameters to lat/long. I see no reason to require a search engine to have to do georesolution, as it a capability which is not related to the data itself.

Scott Brown (May 08 2016 at 16:15):

Daniel informs me that we now default to NUCC codes in our specialty searches . :) So "208800000X" will now work.

Michael Donnelly (May 08 2016 at 16:18):

@Kevin Paprocki and @Brian Postlethwaite are both trying the download.

Brian Postlethwaite (May 08 2016 at 16:21):

And currently downloaded 17601 practitioner records (give or take ;))

Brian Postlethwaite (May 08 2016 at 16:21):

pasted-image.png

Brian Postlethwaite (May 09 2016 at 15:34):

Hi all!.

Brian Postlethwaite (May 09 2016 at 15:35):

Just a forward notice that we will have a session talking about the Provider directory resources on Wednesday in Q1

Brian Postlethwaite (May 09 2016 at 15:36):

Please come along to discuss things, including Endpoint, and the PractitionerRole changes, and what it might be like to extract the PractitionerRole into its own resource.
http://hl7-fhir.github.io/endpoint.html
http://hl7-fhir.github.io/practitionerrole.html

Michael Donnelly (May 09 2016 at 20:04):

Added: http://wiki.hl7.org/index.php?title=FHIR_Agenda_201605_WGM#Wed_Q1

Michael Donnelly (May 10 2016 at 14:11):

What should our next move be on this? Epic's UGM falls right near the next HL7 WGM, so we won't be able to attend the FHIR Connectathon this fall, and likely few of us will be at HL7 at all. Can we continue Provider Directory Connectathon work virtually?

Brian Postlethwaite (May 10 2016 at 19:04):

Yes Michael, I would like to do this actively and virtually over the next few months, and we can keep challenging the spec to get things straight, and revise on the PA calls, and where we need extensions cover in the Argonaut calls.

Kevin Paprocki (May 10 2016 at 19:06):

Agreed, we'll also likely get more participants (e.g. Cerner) if we do it virtually since it's a lower barrier of entry

Kevin Shekleton (May 10 2016 at 19:35):

The Cerner person working on provider directory had a conflict and wasn't able to make it to the Connectathon last weekend in Montreal. I'm checking with him if he can make it to Baltimore (as long as he doesn't have a conflict I'm sure he will)

Kevin Shekleton (May 10 2016 at 19:35):

With that being said, I'm sure he'd participate virtually too

Michael Donnelly (May 11 2016 at 12:21):

I'd like to have calls to keep us on track. How late in the day could we do it (US time)? Brian is 15 hours ahead of Madison, Kansas City, and Minneapolis.

Brian Postlethwaite (May 12 2016 at 13:27):

Do you have the geo data in there to be able to do the near and near-distance?

Michael Donnelly (May 12 2016 at 14:15):

We have geo data, but we haven't tried to implement location-based searching yet. I balked at parsing location in a search parameter.

Brian Postlethwaite (May 12 2016 at 14:20):

I'll try and get my server updated for it soonish (or maybe after my holiday)

Michael Donnelly (May 12 2016 at 16:12):

We're discussing what a location based provider search would look like. If I want to find providers in Madison, WI 53703, would it look like this: Practitioner?location.city=Madison&location.state=WI&location.postalcode=53703

Michael Donnelly (May 12 2016 at 16:13):

And if not, what should it look like?

Michael Donnelly (May 12 2016 at 16:13):

@Kevin Paprocki , @Sean Moore , and I have been discussing it.

Josh Mandel (May 12 2016 at 16:18):

That looks correct. Of course, you could leave out some of those params, too.

Michael Donnelly (May 12 2016 at 16:19):

True. In most cases, postalcode alone would do just as well there.

Kevin Paprocki (May 12 2016 at 16:20):

To add to that question, would a location+practitioner based query like that find practitioners that have references to (what I'll call) standalone locations *and* practitioners that have (what I'll call) local location resources that match those criteria (and those latter references would be found in the contained element within the practitioner resource)

Michael Donnelly (May 12 2016 at 16:21):

Until a bundle is created, is there a distinction between a contained resource and a "standalone"?

Josh Mandel (May 12 2016 at 16:22):

It should match any locations referenced in Practitioner.practitionerRole.location. I'm not sure what you mean by "standalone" vs "local" @Kevin Paprocki . Do you mean external vs. "contained" references?

Kevin Paprocki (May 12 2016 at 16:22):

yes

Josh Mandel (May 12 2016 at 16:23):

So, the correct behavior for a server is to index based on the details of whatever is referenced from Practitioner.practitionerRole.location. Doesn't matter if that reference in the instance data looks like

• "reference": "Location/123" or
• "reference": "#myPrivateLocation"

Kevin Paprocki (May 12 2016 at 16:24):

I wasn't sure how to make the distinction between resources that are contained, and not contained. Thus local and standalone, respectively.

Kevin Paprocki (May 12 2016 at 16:24):

great! that was the answer I was looking for :). Thanks Josh

Michael Donnelly (May 12 2016 at 16:25):

In the database, I don't believe thee *is* a distinction.

Michael Donnelly (May 12 2016 at 16:25):

The distinction appears when we return the results. (@Josh Mandel , please keep me honest)

Josh Mandel (May 12 2016 at 16:25):

Depends on your database of course (e.g. in SMART's server we have a resource table where we populate an extra resource row for an "external" resource, but not for a "contained" resource. But we populate our index the same in both cases.)

Grahame Grieve (May 12 2016 at 16:26):

have you looked at the 'near' search parameter on Location?

Kevin Paprocki (May 12 2016 at 16:26):

great, that's what I was expecting/exactly what we want.

Michael Donnelly (May 12 2016 at 16:27):

@Brian Postlethwaite , does this jibe with your expectations?

Josh Mandel (May 12 2016 at 16:29):

I think near is mis-specified. There's a weird interaction between near and near-distance.

Josh Mandel (May 12 2016 at 16:30):

And the intended units for near-distance are also totally unclear. I think we'd need a different kind of search parameter (like, location instead of token) to get this right.

Grahame Grieve (May 12 2016 at 17:48):

well, I've never implemented it, and to my knowledge neither has anyone else

Grahame Grieve (May 12 2016 at 17:48):

so we can change it whatever we want - let's do that

Michael Donnelly (May 12 2016 at 19:57):

What will it look like, then?

Grahame Grieve (May 12 2016 at 20:20):

what do you want it to look like?

Ron Shapiro (May 13 2016 at 02:52):

There is one implementation of near and near-distance here.
Example usage here.

Brian Postlethwaite (May 13 2016 at 04:17):

@Josh Mandel with a query that uses chained syntaxes, would you expect that to drill into the contained resource?

Brian Postlethwaite (May 13 2016 at 04:18):

So from your example some data inside the content in #myPrivateLocation?

Brian Postlethwaite (May 13 2016 at 04:20):

And would you expect that a client referring to the locaton ID #myPrivateIdentifier to acutally be something that you would filter on?
Every single contained resource in the server could have that value, is it is meaningless outside the resource (its just referring to the contained content in the resource)

Brian Postlethwaite (May 13 2016 at 04:25):

I might not have this syntax quite right, but this is something that I would expect you could do.
http://fhir.healthintersections.com.au/open/Location?near=143.12,-38.4&near-distance=10|km&organization.name:exact=HL7%20International
The near distance is a token so can be used in the Quantity Type (oops, this was meant to be a quantity search type!)
If this was a contained Organiation on the location, would you expect this search to work?

Brian Postlethwaite (May 13 2016 at 04:26):

@Michael Donnelly , sorry, not quite. See my notes above.

Brian Postlethwaite (May 13 2016 at 04:26):

(and yes the error that we should fix, but for now could use the token to provide the units)

Josh Mandel (May 13 2016 at 15:01):

My claim was that searching by Practitioner with a contained location should work (i.e. GET /Practitioner?location.near={}). I wasn't saying that contained orgs should be visible to GET /Organization?.

Josh Mandel (May 13 2016 at 15:06):

I also think I haven't correctly explained the issue with near and near-distance: it is that they interact, instead of acting as independent filters on a result list. This goes counter to how FHIR search params work in every other case. In other words, it's meaningless to supply just a near-distance.

Brian Postlethwaite (May 14 2016 at 19:00):

Yep, understand the near-distance issue you're talking about. Suggestions?
(I was ok with it) Its more like the query=mpi on patient where the other paramters provide the information, or calling an expand operation with just query params, not posting the parameters object.

Last updated: Apr 12 2022 at 19:14 UTC