Stream: argonaut
Topic: provider directory
Brett Marquard (Jul 25 2016 at 20:56):
New stream to for Argonaut provider directory -- we plan to host a virtual connectathon on 8/12 12-5 PM ET following the scenarios here: http://argonautwiki.hl7.org/index.php?title=Argonaut_Provider_Directory_Connectathon
Michael O'Keefe (Aug 04 2016 at 17:38):
What are the expectations for servers and security? Will servers be open, or will the SMART Authentication flow be used?
Brian Postlethwaite (Aug 04 2016 at 21:40):
I would have expected to mostly be open, as at this point we are verifying the data/search requirements and representations.
Josh Mandel (Aug 04 2016 at 22:11):
Agreed, open seems like a good fit!
Brett Marquard (Aug 04 2016 at 23:53):
Yep, for 8/12 we expect all to be open!
Michael O'Keefe (Aug 05 2016 at 13:47):
(deleted)
Michael O'Keefe (Aug 05 2016 at 13:47):
Awesome, thanks!
Abbie Watson (Aug 07 2016 at 15:11):
Can anybody with a Provider directory participate? Do we just need a /metadata route? What if we have DTSU2 endpoints, but haven't implemented the Endpoint resource yet?
Brian Postlethwaite (Aug 07 2016 at 22:13):
Endpoint is a part of the STU3 version of the specification, and I believe the directory connectathon is targetting the new STU3 release.
Brian Postlethwaite (Aug 07 2016 at 22:13):
My server should be available in the next few days
Abbie Watson (Aug 08 2016 at 00:27):
Where exactly is the STU3 spec that includes an Endpoint resource? Endpoint isn't listed in the STU3 Resource List.....
Brian Postlethwaite (Aug 08 2016 at 00:28):
http://hl7-fhir.github.io/endpoint.html
Abbie Watson (Aug 08 2016 at 00:32):
So, are only auto-discoverable servers allowed, then? Did Endpoint wind up as part of the Argonaut spec? I understand how the Endpoint resource is defined; but how is it suppose to be used with the rest of the argonaut spec? List out Endpoints resources in our Conformance statement on the /metadataroute?
Brian Postlethwaite (Aug 08 2016 at 00:37):
I'm chasing up which version of the spec should be used. The page http://argonautwiki.hl7.org/index.php?title=Implementation_Guide#Provider_Directory indicates it should be the May STU3 build, but I believed the scope for this connectathon was to try out the new version.
Abbie Watson (Aug 08 2016 at 00:46):
That's too bad. Probably not going to be able to participate then, as we're still on STU2 and won't have time to upgrade before Fri. Ah well.
Brian Postlethwaite (Aug 08 2016 at 00:49):
Yes, there is no endpoint resource in DSTU2, it was barely in the May STU3 release.
Did you have org/practitioner/location in your current build?
Abbie Watson (Aug 08 2016 at 00:55):
Spread out between two or three apps, yes. They're modularized and already published as packages:
https://github.com/clinical-meteor/?utf8=%E2%9C%93&query=hl7-resource
We already have a Patient Directory up and running, so it would be relatively easy to pull in the org/practitioner/location resources. With test data, even. But reworking the endpoints and authentication... that's beyond the time I have available this week.
Brett Marquard (Aug 08 2016 at 12:30):
i updated the links on the Argonaut PD wiki to point to STU3 (continous build for now)
Michael O'Keefe (Aug 08 2016 at 15:20):
What's the intended location of the Practitioner "telecom and physical address" for the first scenario? Is it the 'telecom' and 'address' attributes on Practitioner, or is it the 'telecom' and 'location' attributes on the 'providerRole'?
Daniel VanderWeyst (Aug 08 2016 at 15:38):
We've put this information in the Location that is referenced from the Practioner.Role. I believe the address on the Practitioner root is intended for a non-role specific address -- such as a home address. We do put the telecom in both places -- in the Location as well as on the Practitioner.Role.
Brett Marquard (Aug 08 2016 at 17:38):
good question, I would expect the telecom of a practitioner at a specific location be sent in Practitioner.role.telecom
Josh Mandel (Aug 08 2016 at 19:53):
Some thoughts on the PD specification from http://argonautwiki.hl7.org/index.php?title=Implementation_Guide#Provider_Directory:
1. For "Retrieve Direct address from Practitioner.role.endpoint", is the idea that you'd fetch all endpoints referenced from a given Practitioner.role, and filter them client-side?
2. I have some cardinality confusion about Practitioner.role: the whole element repeats, but inside, the organization, and code are 0..1, while speciality is 0..*. Meanwhile, the documentation for code is plural ("roles which the practitioner may perform") and the documentation for specialty is singular
Josh Mandel (Aug 08 2016 at 19:54):
Also re: PD: do we have example resources available in the IG, showing a Provider and Direct address (for example)?
Brett Marquard (Aug 08 2016 at 19:57):
1. We are going to discuss in 5 mins requiring the endPoint to be contained. Previously we just discussed requiring support for _include
Josh Mandel (Aug 08 2016 at 20:00):
Cool! (I'll join the call :-))
Greg Meyer (Aug 08 2016 at 20:02):
Josh, give this a hit: http://api.sandboxcernerdirect.com/hpd-service/api2/Practitioner?given=greg
I've been using the HAPI FHIR DSTU3 data structures and serialization (running the latest SNAPSHOT build) over the top of my sandbox directory. This is about as close as I've been able to get.
Josh Mandel (Aug 08 2016 at 20:06):
Thanks @Greg Meyer ! This is most helpful.
The following looks correct but surprising to me:
"address" : "mailto:GREGG.MALMQUIST@directnppes.com",
it's just funny because 1) I'd expect to see this in Practitioner.telecom, and 2) the format with mailto: is different from how the ContactPoint would represent this same info.
Josh Mandel (Aug 08 2016 at 20:08):
Also, for identifier.system: http://hl7.org/fhir/v2/0203 with a "type" of "NPI": this doesn't look right to me. We should work through an example of how to list an NPI.
Greg Meyer (Aug 08 2016 at 20:09):
Yea, the NPI was a quick placeholder. We moved direct addresses from telecom, so the "mailto" prefix fits better inline with the endpoint context.
Josh Mandel (Aug 08 2016 at 20:09):
Is there a rationale for moving "Direct address" but not "phone number" or "fax number"?
Josh Mandel (Aug 08 2016 at 20:10):
Again, just looking at this from the perspective of avoiding surprises.
Greg Meyer (Aug 08 2016 at 20:14):
Direct fit more with concept of an electronic service which seems to be the intent of the endpoint. There's also more fields in the endpoint resource that are helpful with further qualifying the capabilities of a Direct endpoint.
Greg Meyer (Aug 08 2016 at 20:14):
And back to the "mailto:", endpoint field is a URI.
Josh Mandel (Aug 08 2016 at 20:15):
Yeah, I definitely get that you need mailto: in Endpoint.address -- just surprising that it's *different* from the way you do e-mail addresses elsewhere, where this is split into two elements.
Greg Meyer (Aug 08 2016 at 20:16):
gotcha... agree :)
Josh Mandel (Aug 08 2016 at 20:16):
Re: moving "direct address" out of the Practitioner: there's also a data modeling issue. If I have 5 roles, I can have a direct address for each (which is good!) but I can't have a phone number for each (which is bad)??
Josh Mandel (Aug 08 2016 at 20:16):
Oh, never mind, I see there are telecoms inside and outside of "role".
Josh Mandel (Aug 08 2016 at 20:18):
When you talk about "clarifying the capabilities of a Direct endpoint", do you mean like "I can only accept C-CDA documents, and not plain text messages" or something like that, @Greg Meyer ?
Greg Meyer (Aug 08 2016 at 20:19):
Yes. I think the capabilities of the payload and mime types could use some work. Example, payload format is only limited to one entry.
Josh Mandel (Aug 08 2016 at 20:20):
mmm, agreed.
Brian Postlethwaite (Aug 09 2016 at 09:46):
Yes, that capabilites part is the section that needs work, and feedback on what would be wanted foe the US contect.
There are 3 sections in an endpoint resoure:
1. Management information (name, contact details, identifiers, status, managing organisation)
2. Capability/context information (what is this endpoint to be used for)
3. Technical connectivity information (how to actually connec to the the system)
Brian Postlethwaite (Aug 09 2016 at 10:01):
I prefer to use the _include approach rather tnhan the contained approach as it gives the client the choice to be able to ask for it when they want it.
(which is not all the time), and updated to the technical details in the endpoint don;t constitute a version change on the practitioner resource.
Brian Postlethwaite (Aug 09 2016 at 10:04):
@Greg Meyer I also noted that you had some work addresses in the Practitoner, we should really put in an invariant to prevent those from being used. The location on the role is where the work address should we read from. (as they may have multiple addresses)
Greg Meyer (Aug 09 2016 at 12:36):
Good catch @Brian Postlethwaite on the work address; will get it updated this morning.
Thanks
Greg Meyer (Aug 09 2016 at 13:45):
I'm going to take a shot in the dark that implementations that may want to put a FHIR facade over the top of simple provider directories (NPPES for example) are not going to have the concept of a Location resource in their data model. Would a contained Location for the practitioner's work address(es) be the correct approach in this case?
Michael O'Keefe (Aug 09 2016 at 13:53):
According to the 'Contained resources' page on the FHIR spec: "In some circumstances, the content referred to in the resource reference does not have an independent existence apart from the resource that contains it - it cannot be identified independently, and nor can it have its own independent transaction scope. Typically, such circumstances arise where resources are being assembled by a secondary user of the source data, such as a middleware engine. If the data available when the resource is constructed does not include record keys or absolute identification information, then a properly identified resource cannot be assembled, and even if an arbitrary identification was associated with it, the resource could never be the subject of a transaction outside the context of the resource that refers to it."
Michael O'Keefe (Aug 09 2016 at 13:53):
This seems like it would be true for a FHIR portal to NPPES
Michael O'Keefe (Aug 09 2016 at 13:54):
Assuming you're not getting identifying keys for address information from the NPPES data source
Brian Postlethwaite (Aug 09 2016 at 13:54):
I'd actually have thought NPES would be more likley to have organiation location addresses central, rather than duplicated on every practitioner, but maybe I'd don't know enough about NPPES
Brian Postlethwaite (Aug 09 2016 at 13:54):
It is valid though.
Greg Meyer (Aug 09 2016 at 14:01):
NPPES has an organization concept with an address, but keeps a separate (and possibly different) address associated with the practitioner. In the NPPES case, the provider's address would not have an independent identifier for a Location resource.
Thanks for the clarification, @Michael O'Keefe.
Michael O'Keefe (Aug 09 2016 at 17:35):
I know there's been some discussion already of this, but is there a definitive version of the FHIR build that we're using for the Provider Connectathon?
Michael O'Keefe (Aug 09 2016 at 19:19):
Or is it just the latest?
Brett Marquard (Aug 10 2016 at 00:14):
Just the latest...
Brett Marquard (Aug 10 2016 at 00:15):
Today, a participant reached out about the use of Practitioner.role vs the stand alone PractitionerRole resource. on A prior Argonaut call we agreed to use the backbone element Pracitioner.role NOT the proposed resource
Michael O'Keefe (Aug 12 2016 at 17:31):
In the Implementers channel, @Damian J. Kiska had the following question: "During Connectathon: We ran a query against the Organization resource, with a name search, and we received several warnings about "unknown query parameters". Is this expected? It doesn't appear to be valid FHIR XML. We can provide the XML received, if that will help."
Brett Marquard (Aug 12 2016 at 17:42):
@Kevin Paprocki This search returns 'Unknown query paramter'
Brett Marquard (Aug 12 2016 at 17:42):
https://open-ic.epic.com/FHIR-2016/api/FHIR/Connectathon/Organization?name=x
Brett Marquard (Aug 12 2016 at 17:43):
Would have thought it would return no results
Brett Marquard (Aug 12 2016 at 17:58):
all fixed up -- thanks!
Richard Ettema (Aug 12 2016 at 18:06):
GET http://wildfhir.aegis.net/fhir/Organization/393872
Brian Postlethwaite (Aug 12 2016 at 18:28):
(incomplete) Notes/considerations for making PractitionerRole a DomainResource vs BackboneElement
PractitionerRole domain
+ security for updates
+ privacy
+ distributing
+ searching
+ reduced versioning (potentially)
+ referencing externallu/contained
- additional resources required
- more complex, no simple way for querying who a practitioner record “belongs” to, have to use chained search parameters.
PractitionerRole backbone
+ simpler model
+/- resources that reference need to include role also (note – usually do anyway)
Brian Postlethwaite (Aug 12 2016 at 18:28):
Changes that would be required for PractitionerRole domain promotion
Don’t believe that we would change ANY of the references from practitioner to role. All the resources that I checked either didn’t care about the role, or already specified which was used (which is better, as don’t want changes to the PracRole to effect the recording of other resources.
Greg Meyer (Aug 12 2016 at 18:56):
Possible touchstone search criteria for Location, Org, and Practitioner
- address
- address-state
- address-city
- address-postalcode
Greg Meyer (Aug 12 2016 at 20:18):
From the discussion on the directory google group regarding specialty searching, below implements the suggestion on the group post.
Specialty display (text) search: http://api.sandboxcernerdirect.com/hpd-service/api2/Practitioner?specialty:text=Radi
Lloyd McKenzie (Aug 15 2016 at 14:19):
@Michael O'Keefe Connectathon version is the one that opened for ballot on Friday. Unless announced and agreed on the implementers list, no changes after that point will be part of the Connectathon.
Kevin Paprocki (Sep 17 2016 at 16:03):
https://docs.google.com/document/d/18H8p9fBALzhIAqLZ-14GgOcVZx9zg3aUIiKruuT8gqk/edit
Jeff Eastman (Sep 17 2016 at 20:27):
https://mihin.org/wp-content/uploads/2013/04/MiHIN-HPD-SCD-FHIR-API-v14-03-14-16.pdf
Ron Shapiro (Sep 18 2016 at 16:00):
I've got a question about the JSON format. When retrieving Practitioners from different servers, I am seeing a couple of different structures:
{
"resourceType": "Bundle",
"total": 2,
"entry": [
{
"fullUrl": "https://api.sandboxcernerdirect.com/hpd-service/api2/Practitioner/3287356",
"resource": {
"resourceType": "Practitioner",
"id": "3287356",
"contained": [
{
"resourceType": "Endpoint",
"id": "2",
"status": "active",
"name": "FRANK STELLA",
"connectionType": {
"code": "email"
},
"address": "mailto:FRANK.STELLA@directnppes.com"
}
]
}
}
],
"link": [
{
"relation": "self",
"url": "https://api.sandboxcernerdirect.com/hpd-service/api2/Practitioner?_format=json&family=stella"
}
]
}
vs.
{
"resourceType": "Bundle",
"total": 2,
"entry": [
{
"fullUrl": "https://open-ic.epic.com/Interconnect-Encoder/api/FHIR/DSTU2/Practitioner/TsNsRrRWhchaOxyK8hyy7OAB",
"resource": {
"resourceType": "Practitioner",
"active": true,
"id": "TsNsRrRWhchaOxyK8hyy7OAB",
"contained": [
{
"Endpoint": {
"status": "active",
"address": ".KEVINPAPROCKI.3118@open.epic.com",
"connectionType": {
"system": "http://hl7.org/fhir/subscription-channel-type",
"code": "email",
"display": "Email"
}
}
}
]
}
}
],
"link": [
{
"relation": "self",
"url": "https://open-ic.epic.com/Interconnect-Encoder/api/FHIR/DSTU2/Practitioner?_format=json&given=Kevin"
}
]
}
Look at the "contained" resources... in the first, it has a "resourceType" attribute on the contained object, but in the second it has an embedded "Endpoint" object.
Which is the correct way to embed contained FHIR resources?
Jason Walonoski (Sep 18 2016 at 16:06):
The first way.
Brian Postlethwaite (Sep 18 2016 at 21:39):
I've update the googledoc, with the snapshot of what the updated resource looks like.
Can I have some QA on it before I commit to SVN?
Brian Postlethwaite (Nov 18 2016 at 11:06):
Hi All, Not sure how folks are tracking for the connectathon today, but I've posted a branch of the .NET FHIR client to GitHub if anyone wants to try it using that.
https://github.com/ewoutkramer/fhir-net-api/tree/ft-connectathon-jan2017
Brian Postlethwaite (Nov 18 2016 at 11:06):
(Trying madly to get my server up and running for the connectathon)
Eric Haas (Nov 18 2016 at 18:05):
here is my search for GET [base]/PractitionerRole?specialty=[system]|[code]:
Get https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty=[http://nucc.org/provider-taxonomy]|[363LX0001X]
Eric Haas (Nov 18 2016 at 18:09):
Thanks .. yes the brackets duh
Brett Marquard (Nov 18 2016 at 18:18):
NUCC system: http://nucc.org/provider-taxonomy
Brian Postlethwaite (Nov 18 2016 at 18:18):
http://build.fhir.org/search.html#errors
Note that in here it describes what to do in error conditions where you don't handle parameters)
Brett Marquard (Nov 18 2016 at 18:24):
Link to google participation doc
Eric Haas (Nov 18 2016 at 18:26):
Daniel should a wrong system in GET [base]/PractitionerRole?specialty=[system]|[code]: behave the the same as GET [base]/PractitionerRole
e.g. https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty=http://nucc.org|101YP1600X
Daniel VanderWeyst (Nov 18 2016 at 18:27):
@Eric Haas -- Yes, if the system is incorrect, we will ignore the parameter
Daniel VanderWeyst (Nov 18 2016 at 18:27):
(Sorry -- I was on mute when trying to answer your question.)
Daniel VanderWeyst (Nov 18 2016 at 18:27):
Based on the previous discussion, I believe that is the expected behavior -- if it shouldn't be, we can change it.
Eric Haas (Nov 18 2016 at 18:40):
As I wrote the question I realized it is usually the expected behavior.
This returns an empty bundle:
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=pediatrics
I expect a couple of hits
Eric Haas (Nov 18 2016 at 18:41):
also tried
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=Pediatrics
Daniel VanderWeyst (Nov 18 2016 at 18:43):
That may be a bug on our end -- I think we were expecting the NUCC Code rather than the Display text -- I'll work on getting that fixed.
Eric Haas (Nov 18 2016 at 18:44):
K
will try including the provider - do you support that?
Daniel VanderWeyst (Nov 18 2016 at 18:44):
yes
Eric Haas (Nov 18 2016 at 18:54):
include for provider is good. do you always contain endpoint and location?
Eric Haas (Nov 18 2016 at 18:57):
I'm getting a bad syntax error on PractitionerRole when validate let me send you the output
Daniel VanderWeyst (Nov 18 2016 at 19:02):
Yes, we always contain endpoint and location
Eric Haas (Nov 18 2016 at 19:12):
here is the output from the fhir validatoroutput.txt
Daniel VanderWeyst (Nov 18 2016 at 19:13):
We now support specialty:text, but I don't see any examples with pediatrics. Try this though: https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=Pain%20Management&_format=xml
Daniel VanderWeyst (Nov 18 2016 at 19:14):
What request resulted with that output?
Brian Postlethwaite (Nov 18 2016 at 19:25):
Ok, so the TelstraHealth sqlonfhir STU3 test instance build#1 is now up and running at http://sqlonfhir-stu3.azurewebsites.net/fhir and has been seeded with test data from the MiHN test server.
As a first version of the dev build STU3, im sure it will have some bugs ;)
Eric Haas (Nov 18 2016 at 19:26):
how about the &_include=PractionerRole:organization ?
Assume not since i get a 500 error with:
Get https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty=http://nucc.org/provider-taxonomy|208800000X&_include=PracttionerRole:organization
Eric Haas (Nov 18 2016 at 19:26):
although I would expect to behave the same as
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty=http://nucc.org/provider-taxonomy|207RR0500X
Daniel VanderWeyst (Nov 18 2016 at 19:27):
there is a typo in the include, but we should handle it better
Daniel VanderWeyst (Nov 18 2016 at 19:29):
And, the include should just be Organization since this is a search on PractitionerRole, right? You wouldn't need to specify PractitionerRole:Organization, just Organization. I might be wrong here, so let me know.
Daniel VanderWeyst (Nov 18 2016 at 19:30):
I just pushed out a fix for a couple of the errors you were getting. I updated the Endpoint resource based on our conversation and fixed the date/time format issue. Looking into the other issues.
Daniel VanderWeyst (Nov 18 2016 at 19:34):
Looks like there are several errors related to not containing the fullUrl -- do you know where it is looking or what this error means?
Eric Haas (Nov 18 2016 at 19:36):
http://build.fhir.org/bundle-definitions.html#Bundle.entry.fullUrl
Eric Haas (Nov 18 2016 at 19:36):
there is an invarient
bdl-6: On Bundle.entry: The fullUrl element must be present when a resource is present, and not present otherwise (expression on Bundle.entry: fullUrl.empty() xor resource.exists())
Eric Haas (Nov 18 2016 at 19:42):
MMM this works in google browser but not on FIddler?
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty=http://nucc.org/provider-taxonomy|111N00000X&_include=PractitionerRole:organization
Eric Haas (Nov 18 2016 at 19:42):
not happy in xml? only json
Eric Haas (Nov 18 2016 at 19:44):
RE: " You wouldn't need to specify PractitionerRole:Organization, just Organization"
for includes:
'Parameter values for both _include and _revinclude have three parts, separated by a : character:
'The name of the source resource from which the join comes
The name of the search parameter which must be of type reference
(Optional) A specific of type of target resource (for when the search parameter refers to multiple possible target types)'
Eric Haas (Nov 18 2016 at 19:45):
http://build.fhir.org/search.html#include
Daniel VanderWeyst (Nov 18 2016 at 19:46):
Thanks @Eric Haas -- I'll look into correcting these issues.
Eric Haas (Nov 18 2016 at 19:55):
Daniel
This works :
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=Pain%20Management
but this returns an empty bundle ( there are three resources in your Server ):
Daniel VanderWeyst (Nov 18 2016 at 20:12):
fullUrl should now be populated. I'll look into the include issue next.
Daniel VanderWeyst (Nov 18 2016 at 20:12):
And the Gastroenterology issue -- I think I know what might be happening there.
Eric Haas (Nov 18 2016 at 20:12):
Daniel let me know when the server is back up
Daniel VanderWeyst (Nov 18 2016 at 20:13):
it should be up
Eric Haas (Nov 18 2016 at 20:31):
@Brian Postlethwaite the specialty system is http://nucc.org/provider-taxonomy http://build.fhir.org/terminologies-systems.html
Daniel VanderWeyst (Nov 18 2016 at 20:45):
@Eric Haas -- I believe I have corrected the include issues you were experiencing -- can you try again?
Eric Haas (Nov 18 2016 at 20:59):
Sure I was trying the ?specialty:text and still hit or miss
returns and empty bundle but <id value="2227364453001"/> should be returned
works though
Daniel VanderWeyst (Nov 18 2016 at 20:59):
yeah, that is a bigger issue for me to solve
Daniel VanderWeyst (Nov 18 2016 at 21:00):
the issue is that some descriptions match more than one nucc code and the way I quickly implemented this, it is grabbing the first one it finds and doing the search based on that code
Daniel VanderWeyst (Nov 18 2016 at 21:01):
i need to integrate the description based search capability into our underlying search capabilities, but that isn't a quick fix unfortunately
Eric Haas (Nov 18 2016 at 21:02):
&_include=PractitionerRole:organization is working
Eric Haas (Nov 18 2016 at 21:05):
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=Rheumatology&_include=PractitionerRole:organization&_include=PractitionerRole:practitioner
works as well .....great
Eric Haas (Nov 18 2016 at 21:13):
tried the chained search : ?practitioner.identifier=[system]|[code]
but seems not be supported returned the full bundle
Eric Haas (Nov 18 2016 at 21:19):
Also the chained search for ?practitioner.family=[string] works fine but not ?practitioner.given=[string]
Daniel VanderWeyst (Nov 18 2016 at 21:26):
We haven't implemented ?practitioner.identifier=[system]|[code], but I can do that in a bit
Daniel VanderWeyst (Nov 18 2016 at 21:26):
given should work -- let me take a look
Daniel VanderWeyst (Nov 18 2016 at 21:37):
@Eric Haas -- https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?specialty:text=Pediatrics should be working now
Eric Haas (Nov 18 2016 at 21:40):
Great
Eric Haas (Nov 18 2016 at 21:47):
The given name search is working fine too.
https://uiservice-beta.surescripts.net/ArgonautServer/fhir/PractitionerRole?practitioner.given=Kecia
Daniel VanderWeyst (Nov 18 2016 at 21:49):
Awesome!
Eric Haas (Nov 18 2016 at 21:49):
does not?
Daniel VanderWeyst (Nov 18 2016 at 21:49):
Regarding the errors you were seeing in the output.txt -- I think all except the errors related to extentions are resolved?
Daniel VanderWeyst (Nov 18 2016 at 21:51):
I think you meant Rebbecca with two b's
Eric Haas (Nov 18 2016 at 21:51):
Yes I was doing a text search just now and figured that out.
thanks
Daniel VanderWeyst (Nov 18 2016 at 21:52):
Regarding the extensions -- I thought you could use that to extend and include things that are not defined. Or does that only work when both sides have agreed to the extensions?
Eric Haas (Nov 21 2016 at 22:39):
@daniel The extensions are allowed it is a validator problem I didn't have the them in my definitiions file. Kind of explained here
Brian Postlethwaite (Jan 04 2017 at 06:15):
Hi all, thought this might be of interest to this community also.
http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12509
Daniel del Aguila (Jun 16 2017 at 21:29):
Hello
My name is Daniel del Aguila, I am a physician and a student of the Health Informatics Master Program at the Universidad de Chile. Within the Medical Informatics and Telemedicine Center (CIMT, www.cimt.cl). Presently, we are working on a Model for a new, National Healthcare Provider Index (HPI). Our experience with FHIR is still limited, and we are trying to understand the DSTU3 Resource PractitionerRole. We reviewed the Argonaut Provider Directory Implementation Guide and find it very useful.
We understand that the PractitionerRole is useful for an healthcare institution managing their employees in a Hospital Information System. But, from a National HPI point of view, the number of possible PractitionerRoles becomes very high. How do you think this could be implemented in a national level with such a high number of PractitionerRoles? Are there any similar national or big-scale projects being developed or already implemented? Is there anybody out there with experience?
Jim Kreth (Jun 19 2017 at 20:44):
Daniel, both PractitionerRole.code and PractitionerRole.specialty are codeable concepts. You could use either or both to provide information at national level for classifications, then assign your practitioners to one or more roles as you've defined them. PractitionerRole.specialty should clearly be in the realm of a nationally (or internationally) recognized set of specialties. PractitionerRole.code is a bit less well-defined as they typically refer to roles within a hospital setting. I'm not sure they would apply to a national registry.
Brian Postlethwaite (Jul 04 2017 at 03:07):
The Australian National Provider Directory has a very similar structure to this in non-fhir format, and I have a mapping to the FHIR format that is in operation.
It is manageable, but does take work to keep the content current.
There is a US Federal project also defining a similar scope.
The Michigan Health Information Network (MiHIN) has a production dataset of this also.
Elliot Silver (Jul 15 2017 at 00:15):
IHE will be reviewing a new provider directory profile (called mCSD, http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mCSD_Rev1.0_PC_2017_05-17.pdf) next week during their face-to-face meetings. Although the official public comment period is over (http://ihe.net/Public_Comment/#IT) , I am interested in feedback from anyone knowledgeable about the Argonaut provider directory profiling or the US Federal project. Please see the http://wiki.ihe.net/index.php/ITI_Agenda_2016-2017 for the agenda, or contact me or @Luke Duncan for details.
Michelle (Moseman) Miller (Jul 28 2017 at 13:40):
@Brian Postlethwaite or @Brett Marquard A few questions:
1) Any update on these discussions (https://chat.fhir.org/#narrow/stream/implementers/topic/Organization.20.20Relationships and https://chat.fhir.org/#narrow/stream/implementers/subject/provider.20directory), which raised questions like how to represent an insurance/benefit plan as well as which insurance networks a practitioner is in (i.e. which insurance plans the practitioner accepts)?
2) What is the update/status of the OrganizationAffiliation FHIR resource proposal (http://wiki.hl7.org/index.php?title=OrganizationAffiliation_FHIR_Resource_Proposal)?
3) Is Argonaut planning to expand its use cases to search for providers based on which insurance plans they accept?
4) Any WGM quarters planned to address any of the aforementioned topics?
Brett Marquard (Jul 28 2017 at 13:48):
Argonaut PD explicitly kept insurance network participation out of scope. There is an effort being lead by ONC to ballot a healthcare directory, they may include this information. Brian is participating and can comment.
Jay Lyle (Nov 21 2018 at 15:48):
Who else is implementing the provider directory?
John Moehrke (Nov 21 2018 at 16:44):
There is ongoing improvements in IHE on their ProviderDirectory for FHIR too (mCSD). I would really like to see these working together. Is there anyway we can get ONC, Argonaut, and IHE to play nice?
Eric Haas (Nov 21 2018 at 19:53):
We are having a connectathon for vhdir. Next month. That is much broader than the Argo pd
John Moehrke (Nov 21 2018 at 20:24):
I suspect many projects (e.g. Sequoia) are also working through this space. It seems a good idea to come up with some way to work together
Last updated: Apr 12 2022 at 19:14 UTC
