Stream: Argo Patient Lists
Topic: Connectathon Stream
Eric Haas (Sep 10 2020 at 13:36):
connectathon announcements hree....
Carl Anderson (Sep 10 2020 at 13:38):
I've loaded 30+ patients (and connected resources into) http://hapi.fhir.org/baseR4/ - all resources are tagged with:
[{
'system': 'http://hl7.org/Connectathon',
'code': '2020-Sep'
}]
Carl Anderson (Sep 10 2020 at 13:41):
Check out the demo app I've put together here: https://microsoft-healthcare-madison.github.io/patient-lists-demo/
Jason Vogt (Sep 10 2020 at 13:54):
MEDITECH added our server information to the spreadsheet
Carl Anderson (Sep 10 2020 at 14:11):
I'm getting a gateway timeout from the hapi server where I put the data last night. I suspect it's under load, and I'm looking for an alternate host for the demo data.
Eric Haas (Sep 10 2020 at 14:55):
works fine using Postman ... but the base https://fhir-open.stagingcerner.com/beta/dacc6494-e336-45ad-8729-b789ff8663c6/Group is not reachable ... is that correct @Madhur Rajendran
Madhur Rajendran (Sep 10 2020 at 15:01):
Yes, that's correct. We don't support the default list. I just split the base url out from the query parameters.
Josh Mandel (Sep 10 2020 at 15:08):
On HAPI, seems up and working by now (http://hapi.fhir.org/baseR4/Group?_tag=2020-Sep for example is working for me.)
Carl Anderson (Sep 10 2020 at 15:08):
I've added a new field in the app settings to allow the user to enter a bearer token. I just need to insert it into the fetches in the other components. Feel free to view the PR here (and add yourself as a reviewer): https://github.com/microsoft-healthcare-madison/patient-lists-demo/pull/11
Josh Mandel (Sep 10 2020 at 15:09):
@Carl Anderson https://microsoft-healthcare-madison.github.io/patient-lists-demo/ is erroring out for me because it's calling HAPI over http instead of https
Josh Mandel (Sep 10 2020 at 15:09):
Mixed Content: The page at 'https://microsoft-healthcare-madison.github.io/patient-lists-demo/' was loaded over HTTPS, but requested an insecure resource 'http://hapi.fhir.org/baseR4//Group?_tag=http%3A%2F%2Fhl7.org%2FConnectathon%7C2020-Sep&_include=Group%3Amember'. This request has been blocked; the content must be served over HTTPS.
Josh Mandel (Sep 10 2020 at 15:09):
I can work around by hitting "settings" and changing the HAPI server URL to use https, but it'd be good to have a default of https
Carl Anderson (Sep 10 2020 at 15:09):
Josh Mandel (Sep 10 2020 at 15:14):
Nice!
Joshua Smolic (Sep 10 2020 at 15:22):
fetch(${SERVER}/Group?_summary=true&type=person, { headers: { Authorization: 'Bearer xxxxuG40mw==' } })
Carl Anderson (Sep 10 2020 at 15:33):
This is the meat of what I've added to the fetch calls.
// Returns a de-paginated bundle of resources from an initial URL.
export async function drain(resourceUrl, bearerToken, progressCallback) {
const bundles = [];
let url = resourceUrl;
const authorization = {
headers: {
Authorization: `Bearer ${bearerToken}`
}
}
do {
// Fetch a bundle from the URL.
await fetch(url, bearerToken ? authorization : undefined)
.then(response => response.json())
.then(bundle => bundles.push(bundle));
...
Does this look right?
Carl Anderson (Sep 10 2020 at 15:39):
https://microsoft-healthcare-madison.github.io/patient-lists-demo/
Carl Anderson (Sep 10 2020 at 15:39):
The branch version is live - go ahead and give it a try with your server and token.
Joshua Smolic (Sep 10 2020 at 15:43):
https://dev-mtx-interop.meditech.com/v1/ArgoPatientList/R4/
Josh Mandel (Sep 10 2020 at 15:47):
Does this look right?
It looks OK. You should be able to check behavior in the Network tab to make sure it's issuing the headers you expect (e.g., against the HAPI server or against the Meditech server).
Carl Anderson (Sep 10 2020 at 15:48):
@Joshua Smolic is helping confirm against his server. I just need to disable the automatic CapabilityStatement-checking feature...
Josh Mandel (Sep 10 2020 at 15:51):
Hmm, is https://dev-mtx-interop.meditech.com/v1/ArgoPatientList/R4/metadata not working @Carl Anderson , or how is it breaking?
Carl Anderson (Sep 10 2020 at 15:53):
My server settings form wouldn't let you apply changes if it failed to fetch a CapabilityStatement. It was the only other location where I was attempting to fetch from the server, and I hadn't passed the authorization bits through that call.
Carl Anderson (Sep 10 2020 at 15:53):
So, for now, I've disabled that feature (checking CapabilityStatements before enabling the Apply button)
Josh Mandel (Sep 10 2020 at 15:55):
Disabling seems fine, but I'm not sure what the issue was -- I'm able to fetch metadata for that server. Also note that the metadata endpoint should never need authorization.
Carl Anderson (Sep 10 2020 at 15:56):
Ah, and I just noticed when fetching a bundle against hapi over https - the next url will be over http instead of https
Carl Anderson (Sep 10 2020 at 15:56):
Could it be CORS, then?
Josh Mandel (Sep 10 2020 at 15:56):
??? Wow, is that a hapi configuration bug?
Josh Mandel (Sep 10 2020 at 15:57):
If you're having CORS issues with the metadata endpoint, you'll probably have them with the Group endpoint too :-)
Joshua Smolic (Sep 10 2020 at 15:59):
it looks like it was trying to fetch https://dev-mtx-interop.meditech.com/v1/ArgoPatientList/R4//CapabilityStatement, but we are serving it as https://dev-mtx-interop.meditech.com/v1/ArgoPatientList/R4/metadata
Josh Mandel (Sep 10 2020 at 16:11):
Okay that was a bug in the test app. To ask a server what capabilities it supports, we should be querying the metadata end point. @Carl Anderson
Carl Anderson (Sep 10 2020 at 16:20):
I really just wanted a convenient way to see 'is this thing a FHIR server'?
Josh Mandel (Sep 10 2020 at 16:24):
Yeah, that's GET ${thisthing}/metadata
Carl Anderson (Sep 10 2020 at 16:30):
@Madhur Rajendran - this is the code system I had found for characteristics (I think in the hackmd page): http://argonautproject.org/patient-lists/CodeSystem/characteristics
Carl Anderson (Sep 10 2020 at 16:42):
@Josh Mandel - Joshua Smolic confirmed that the bearer token change seems to work against the new code (but fails for other reasons). I'll merge the PR in a few if you don't have any other review. :coffee: :brb:
Madhur Rajendran (Sep 10 2020 at 16:48):
I had a question about the search parameters when searching by characteristic. Right now the confluence page lists the characteristic codes as 'location' 'attributed-to', etc. However, the binding in the FHIR spec seems to be unbound (so we're not guaranteed to have those exact codes).
In addition, it seems like the values in the argonaut valueSet might be different than what the confluence says to use for 1.3 Discovery by Characteristic. i.e. if the search parameter is attributed-to, a code value of attributed-to-organization should not qualify.
I guess my two main questions are:
- Is the argonaut valueSet the valueSet we're using for Group.characteristic.code? (I haven't been able to find a link to the list of values in the value set yet.)
- Should the binding be more restrictive? (since we're focusing on searching by specific values)
Josh Mandel (Sep 10 2020 at 16:57):
Carl Anderson: @Josh Mandel - Joshua Smolic confirmed that the bearer token change seems to work against the new code (but fails for other reasons). I'll merge the PR in a few if you don't have any other review. :coffee: :brb:
Great -- looks good!
Josh Mandel (Sep 10 2020 at 16:58):
However, the binding in the FHIR spec seems to be unbound
Can you share a link and/or screenshot so we're all on the same page here?
Josh Mandel (Sep 10 2020 at 16:59):
Is the argonaut valueSet the valueSet we're using for Group.characteristic.code? (I haven't been able to find a link to the list of values in the value set yet.)
Unless @Eric Haas has formalized this, I don't think it exists yet. For the connectathon, let's focus on just the "code" portion of the Codings, and use:
attributed-to-organization
attributed-to-practitioner
attributed-to-careteam
as Carl has in the sample app.
Josh Mandel (Sep 10 2020 at 17:00):
We'll of course need to work through a complete list, and formalize publication of a valueset as part of our ongoing spec development. But for today/tomorrow, it'd be good if we're all on the same page.
Madhur Rajendran (Sep 10 2020 at 17:05):
@Josh Mandel for the unbound part of the characteristic.code: https://www.hl7.org/fhir/group-definitions.html#Group.characteristic.code clicking on the link for the Terminology takes me to the unbound section of the FHIR spec.
So should I update the value we accept in the characteristic search parameter from 'attributed-to' to 'attributed-to-practitioner'?
Joshua Smolic (Sep 10 2020 at 17:23):
For the characteristic search, I thought 'attributed-to' was fine because the characteristic isn't actually defining what the characteristic is. The characteristic-reference itself links to what would indicate that. And as much as it can be human readable, it's just a reference. So, the server would be responsible for determining how the filter is applied. I think the reason being, if it's a reference to a practitioner, you could return any list the practitioner created, and any he has access to by his organizational affiliations.
Madhur Rajendran (Sep 10 2020 at 17:25):
But the Group search parameters define it as a token search on the Group.characteristic.code, https://www.hl7.org/fhir/group.html#search, so the rules for token search parameters would apply, wouldn't it?
Eric Haas (Sep 10 2020 at 17:40):
@Madhur Rajendran re characteristic they will be an argonaut code system and not formalized yet so you won't see them by trying to resolves and existing code system. . they are listed in the connectathon here: https://confluence.hl7.org/pages/viewpage.action?pageId=86977234#id-202009ArgonautPatientLists-1.3-DiscoverybyCharacteristic
Joshua Smolic (Sep 10 2020 at 17:40):
maybe, but since that is a codableConcept, it's not a single string
Eric Haas (Sep 10 2020 at 17:47):
Joshua Smolic said:
maybe, but since that is a codableConcept, it's not a single string
I won't be but for dev work is OK we don't have a canonical for Argo PL yet ...
Eric Haas (Sep 10 2020 at 17:57):
| Characteristic Code | Char-Value | Value |
|---|---|---|
| location | value-reference | Location/[location_id] |
| attributed-to | value-reference | Practitioner/[practitioner_id] |
| attributed-to | value-reference | Organization/[organization_id] |
| team | value-reference | CareTeam/[careteam_id] |
char code system = 'http://fhir.registry.org/argonaut/CodesSystem/group-characteristic'
Josh Mandel (Sep 10 2020 at 18:11):
OK, so for connectathon @Carl Anderson do you want to align with Eric's list?
Carl Anderson (Sep 10 2020 at 18:12):
Sure. And, admittedly, that part of the demo app isn't done yet.
Josh Mandel (Sep 10 2020 at 18:13):
Great. So for today/tomorrow our app + sample data should align to Eric's list. Longer term, we'll want to review (and I think we'll want to understand whether "attributed-to" is the right phrasing to use for patients that a given provider is following, -- and how it's different from "team"; and to articulate the use case for "attributed-to" an Organization.)
Josh Mandel (Sep 10 2020 at 18:14):
And for today/tomorrow @Eric Haas do you want to leave the "system" off? (Or update "http://fhir.registry.org" to something that doesn't rely on a non-existent "registry.org"?)
Carl Anderson (Sep 10 2020 at 18:15):
RIght now I'm working on resolving Patients from a Group with a bunch of async reference resolutions, since some of the server implementers don't support query bundles.
Eric Haas (Sep 10 2020 at 18:15):
'attributed-to' is taken from bulk data for similar type query
Eric Haas (Sep 10 2020 at 18:16):
@Josh Mandel yes - that system is a stub - since we don't have a canonical base for any of the FHIR artifacts we create
Josh Mandel (Sep 10 2020 at 18:17):
The bulk data use case is different though (attribution of members to health insurance plans, which is generally about much larger populations that user-facing lists)
Eric Haas (Sep 10 2020 at 18:18):
but I think the codes could be the same as in this list is attributed-to dr smith or my clinic or payor b?
Eric Haas (Sep 10 2020 at 18:18):
not as confusing if the same ...
Eric Haas (Sep 10 2020 at 18:19):
and remember this is different from managed-by
Eric Haas (Sep 10 2020 at 18:31):
@Joshua Smolic ` GET https://dev-mtx-interop.meditech.com:443/ArgoPatientList/R4/Group/62d97255-3f5e-4388-81fd-a46c9b2d6196'
Eric Haas (Sep 10 2020 at 18:32):
gives me:
{"resource":"v1/resource/error/_version/1/","detail":"could not route request"}
Joshua Smolic (Sep 10 2020 at 18:32):
GET https://dev-mtx-interop.meditech.com:443/v1/ArgoPatientList/R4/62d97255-3f5e-4388-81fd-a46c9b2d6196'
Eric Haas (Sep 10 2020 at 18:34):
give
{"resource":"v1/resource/error/_version/1/","detail":"could not route request"}
Eric Haas (Sep 10 2020 at 18:36):
Josh Mandel (Sep 10 2020 at 18:52):
Eric Haas: but I think the codes could be the same as in this list is attributed-to dr smith or my clinic or payor b?
Eric Haas: not as confusing if the same ...
It'd be good if you want to take a crack at plain-language definitions for each of these terms, so we can make sure we have common expectations about what's allowed and what it means. I'm not sure the "payor attribution" concept expresses the semantics of "Patients that Dr. Jones is following this weekend", but having draft definitions will make this assessment easier.
Joshua Smolic (Sep 10 2020 at 18:54):
The response from the dev-mtx-interop.meditech.com server for the fullUrl is now correctly including the /v1 on the start of the url.
Eric Haas (Sep 10 2020 at 19:46):
@Joshua Smolic got your server data up and running -- note that patient ashlyn test is listed twice
Joshua Smolic (Sep 10 2020 at 19:47):
@Eric Haas which group came back with the same patient twice?
Eric Haas (Sep 10 2020 at 19:49):
@Joshua Smolic also looks like your server does not support multipleOr for serarch (GET Patient?_id=ID1,ID2,ID3,...)
Eric Haas (Sep 10 2020 at 19:49):
can you confirm that?
Eric Haas (Sep 10 2020 at 19:51):
The Group is that has dupes:
Request: https://dev-mtx-interop.meditech.com:443/v1/ArgoPatientList/R4/Group/62d97255-3f5e-4388-81fd-a46c9b2d6196
Eric Haas (Sep 10 2020 at 19:52):
or batch?
Joshua Smolic (Sep 10 2020 at 19:53):
@Eric Haas correct, it does not support that currently
Jason Vogt (Sep 10 2020 at 20:32):
Here is what I am seeing in the logs
[2020-09-10T19:47:02.802Z apiserver 11 3388 dynamic-router deae423b-8a2f-462b-a12a-6dc260d4334c Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:02.935Z apiserver 11 3388 dynamic-router 75e0b5a9-f76b-4170-a0c9-4c7a3058ca8a Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:03.983Z apiserver 11 3388 dynamic-router 37b316bf-08ee-4c03-ac71-b25a05a08d85 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:04.134Z apiserver 11 3388 dynamic-router 96eaa246-3816-4d21-a2ab-90c375d52ef5 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:05.197Z apiserver 11 3388 dynamic-router d1e3dce0-b4df-42c9-b2da-d741ada6cb1a Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:05.331Z apiserver 11 3388 dynamic-router ade77ea9-1639-4000-b83f-f9c6df424839 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:06.379Z apiserver 11 3388 dynamic-router fad4d66a-8476-48ad-b0e5-faeea5eadff1 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
[2020-09-10T19:47:06.511Z apiserver 11 3388 dynamic-router 2e07932d-3749-4030-99a2-d7560f6c8892 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4/Patient?_id=Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2FFC9F29CC-EE9B-463F-A00C-412CD4461EF4%2C+Patient%2F41B242D8-2F8F-4FD8-8062-ED3F3A588DFC%2C+Patient%2F25D2CD43-F6DB-4D54-8CF6-0ACC9C538C74%2C+Patient%2F9E510C6D-00AC-4CE7-A11E-E067266032CB%2C+Patient%2F2343467D-91C9-4113-A855-435F58D56635%2C+Patient%2F0453ACC3-A1A9-4177-AA91-4B6561E5BACC%2C+Patient%2F95E3732A-8884-425A-B621-7ECEB8393E2F%2C+Patient%2F03017167-9F58-4812-89A7-FB87A442361C%2C+Patient%2FFE5013CF-20CC-4EFE-A937-AE8AE98C8AF5%2C+Patient%2F90DB7338-C328-47F8-928D-8E4D14EC4B06%2C+Patient%2F5D8AC795-782C-4210-8FB8-231F09C7E9CB%2C+Patient%2F9699FA83-DD07-42C0-9CB6-C67652ECF82D%2C+Patient%2F3B20D943-4E3F-4C8B-A54B-9471F316A0F5%2C+Patient%2FFD1BD66E-FA2E-4DAB-B621-36A62B980699%2C+Patient%2F2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\uti
Eric Haas (Sep 10 2020 at 20:35):
OK Meditech groups can be fetched and patient data added using simple fetches here: http://www.healthedata1.co/
Eric Haas (Sep 10 2020 at 20:46):
Welcome to sunny California! ... Noon yesterday:
Jason Vogt (Sep 10 2020 at 21:02):
[2020-09-10T20:58:08.682Z apiserver 6 5984 dynamic-router 7ce86dbb-9027-4f65-8ae7-2905ba088063 Error] error occurred while processing request:Error: could not route "v1/ArgoPatientList/R4Patient/2793C80D-0042-4A65-B6A7-50435B979BB0"
at routeApi (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:122:11)
at RoutingTable_1.routingTable.then (C:\Program Files (x86)\MEDITECH\RestAPI\source\util\Url.ts:55:33)
at process._tickCallback (internal/process/next_tick.js:68:7)
Carl Anderson (Sep 10 2020 at 21:14):
@Jason Vogt @Joshua Smolic - I have a fix deploying at the moment.
I'm now canonicalizing all links being fetched from the api.drain function to remove extra double slashes.
export async function drain(resourceUrl, bearerToken, progressCallback) {
const bundles = [];
let url = resourceUrl.replace(/([^:]\/)\/+/g, "$1");
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I believe this will fix the api calls (except for maybe the /metadata call.
Carl Anderson (Sep 10 2020 at 21:15):
@Eric Haas - that looks like Pacifica
Eric Haas (Sep 10 2020 at 22:03):
group ID for Goup with Q and QA extensions: 1171742 on both HAPI and Grahame's Server ( brought to you by Isaac's (Epic) team
Eric Haas (Sep 10 2020 at 22:12):
resourceType: Group
id: '1171742'
meta:
versionId: '3'
lastUpdated: '2020-09-10T21:56:49.830+00:00'
source: '#MBXE4zYjaCGYtSjS'
tag:
- system: 'http://hl7.org/Connectathon'
code: 2020-Sep
extension:
- url: 'http://registry.fhir.org/argonaut/patientlistsquestionnairev1'
valueReference:
reference: Questionnaire/1169270
identifier:
- system: 'http://example.org'
value: dba0a9f9-82cb-4d42-ad92-3250756a9420
active: true
type: person
actual: true
name: ICU List
managingEntity:
reference: Organization/example-organization-2
display: Dairyland Hospital
member:
- entity:
extension:
- url: >-
http://registry.fhir.org/argonaut/patientlistsquestionnaireresponsev1
valueReference:
reference: QuestionnaireResponse/1169472
identifier:
system: 'http://example.org'
value: '456'
display: Name = Daniel Crimson (MRN = 456)
inactive: false
- entity:
extension:
- url: >-
http://registry.fhir.org/argonaut/patientlistsquestionnaireresponsev1
valueReference:
reference: QuestionnaireResponse/1171740
identifier:
system: 'http://example.org'
value: '567'
display: Name = Peter Silie (MRN = 567)
inactive: false
- entity:
extension:
- url: >-
http://registry.fhir.org/argonaut/patientlistsquestionnaireresponsev1
valueReference:
reference: QuestionnaireResponse/1171741
identifier:
system: 'http://example.org'
value: '901'
display: Name = Caleb Cushing (MRN = 901)
inactive: false
Eric Haas (Sep 10 2020 at 22:17):
I fixed the last extension is was in the wrong place ( or was it? ) in member vs entity.
Notice they only have identifiers and not references to patients:
I think we should require references to simplify search
Eric Haas (Sep 11 2020 at 00:37):
also I think our form should be flat to make the rendering maneagable
Eric Haas (Sep 11 2020 at 03:23):
and I've implemented 3.3 here in my app....
Eric Haas (Sep 11 2020 at 13:06):
but broke the rest sigh...
Carl Anderson (Sep 11 2020 at 13:53):
Good morning, PL participants! While the hapi server is having it's morning cup of coffee, we thought we'd start an informal breakout session to cover some of the discussion topics outlined in the confluence page: https://confluence.hl7.org/display/FHIR/2020-09+Argonaut+Patient+Lists
Carl Anderson (Sep 11 2020 at 13:54):
We'll probably start in about 10 minutes, so make your way to Whova and join the Zoom meeting.
Annie Yin (Sep 11 2020 at 14:37):
@Carl Anderson Resources with ids 1465519 and 1465520 are the ones that don't have characteristic.exclude populated
Annie Yin (Sep 11 2020 at 14:48):
Also just pinged the Cerner server and none of the entries have characteristic.exclude filled
Jason Vogt (Sep 11 2020 at 14:55):
Jason Vogt (Sep 11 2020 at 14:57):
@Annie Yin Would you like to try the MEDITECH endpoint? We can chat you the token for access
Josh Mandel (Sep 11 2020 at 15:12):
FYI @Carl Anderson I just added a "feature" request at https://github.com/microsoft-healthcare-madison/patient-lists-demo/issues/16 to clarify real vs canned data in the demo app.
Annie Yin (Sep 11 2020 at 15:14):
@Jason Vogt Yeah definitely, was just going to message you for credentials
Carl Anderson (Sep 11 2020 at 15:41):
(deleted)
Carl Anderson (Sep 11 2020 at 15:44):
@Annie Yin - I updated those two groups characteristics to include "exclude": "false"
Madhur Rajendran (Sep 11 2020 at 16:31):
Annie Yin
Also just pinged the Cerner server and none of the entries have characteristic.exclude filled
I updated it, they should have exclude filled out now.
Eric Haas (Sep 11 2020 at 17:38):
I will be creating summary slides live
Jason Vogt (Sep 11 2020 at 17:39):
We have a the search by just characteristic working if any wants to check it out
https://dev-mtx-interop.meditech.com/v1/ArgoPatientList/R4/Group?_summary=true&type=person&characteristic=location
Annie Yin (Sep 11 2020 at 18:05):
@Carl Anderson @Madhur Rajendran thanks!
Annie Yin (Sep 11 2020 at 18:07):
@Madhur Rajendran just fetched and getting errors because Group resource ids aren't strings
Eric Haas (Sep 11 2020 at 19:09):
slides are here: https://hackmd.io/DRTZx4jlRIWqpean8sLVEQ
Madhur Rajendran (Sep 11 2020 at 19:14):
seems like the meeting just ended?
Sam Echevarria (Sep 11 2020 at 19:15):
Try refreshing--should be back now!
Eric Haas (Sep 11 2020 at 19:26):
back on line now
Madhur Rajendran (Sep 11 2020 at 19:30):
I updated the endpoint to use the new 'value-reference' search parameter (instead of characteristic-reference). The ids should also be returned as strings now.
Eric Haas (Sep 13 2020 at 20:11):
I big thanks to all our Patient Lists participants. i consider is a very successful connectathon track for the the first-time out!
Last updated: Apr 12 2022 at 19:14 UTC
