Stream: australia/primary-care
Topic: Nov 2019 Connectathon
Michael Lawley (Nov 10 2019 at 23:23):
Connectathon participant spreadsheet - add yourself, your clients / servers etc
https://docs.google.com/spreadsheets/d/1Kn2pNQS0GpEA4zkQoCewCMgJHToZBu2iZNPdeImdfWs/edit?usp=sharing
Michael Lawley (Nov 10 2019 at 23:48):
http://build.fhir.org/ig/aehrc/primary-care-data-technical/
Deanne Ukovich (Nov 10 2019 at 23:59):
confluence page https://confluence.csiro.au/display/PCDQFPhase2/Primary+Care+Data+Quality+Foundations+-+Phase+2
Richard Townley-O'Neill (Nov 11 2019 at 00:00):
I am unable to connect to https://aehrc.github.io/primary-care-data-technical/
Neither can https://downforeveryoneorjustme.com
Deanne Ukovich (Nov 11 2019 at 00:01):
clinfhir - model from the clinical working group and validator - http://csiro.clinfhir.com/
Deanne Ukovich (Nov 11 2019 at 00:03):
github seems to be working for me @Richard Townley-O'Neill
Grahame Grieve (Nov 11 2019 at 00:05):
Looking at the guide, I'm surprised because I see profiles etc but nothing addresses how exchange actually works. What's the anticipated exchange paradigm(s)?
Deanne Ukovich (Nov 11 2019 at 00:06):
@Richard Townley-O'Neill you have hit on the backup IG in case build.fhir.org was having issues .. the actual IG files are in https://github.com/aehrc/primary-care-data-technical and the IG is at http://build.fhir.org/ig/aehrc/primary-care-data-technical/ don't look at the one hosted by github
Richard Townley-O'Neill (Nov 11 2019 at 00:13):
Thanks @Deanne Ukovich. Those I can get at. :grinning:
I found the backup in @Michael Lawley's post
Grahame Grieve (Nov 11 2019 at 00:14):
@Brett Esler what's a good test patient on your server?
Grahame Grieve (Nov 11 2019 at 00:14):
(BP)
Grahame Grieve (Nov 11 2019 at 00:17):
@Jim Steel the primary care guide doesn't have the package id on the page
Deanne Ukovich (Nov 11 2019 at 00:17):
@Michael Lawley can you please edit your post to point to http://build.fhir.org/ig/aehrc/primary-care-data-technical/ instead of the backup one that is an out of date snapshot
Grahame Grieve (Nov 11 2019 at 00:19):
@Jim Steel also, it's unusual for the canonical URLs to include https://
Grahame Grieve (Nov 11 2019 at 00:22):
@Brett Esler - what would you expect to be returned from this: http://demo.oridashi.com.au:8297/Patient/4BA4B29974331B56E7B2DA67C457688D.2/package.tgz ?
Jim Steel (Nov 11 2019 at 00:24):
@Grahame Grieve Is that convention (http rather than https) written down anywhere, out of interest?
Jim Steel (Nov 11 2019 at 00:25):
It seems to be indirectly at odds with "Systems resolving references to canonical URLs SHOULD first try to resolve the reference using the canonical reference"
Jim Steel (Nov 11 2019 at 00:26):
Hmm, that might not be the right quote
Jim Steel (Nov 11 2019 at 00:26):
Somewhere though there is something that says canonical URLs should resolve
Grahame Grieve (Nov 11 2019 at 00:30):
not written down to my knowledge. it should be resolvable, yes. And it would be perfectly expected for a server to redirect from http:// to https:// - which it should in this case. But an https:// url is conflating method of access with identity - in an http/2.0 world with inplace upgrade to SSL initiated by either client or server, https:// urls start to go away (yay)
Courtenay Farquharson (Nov 11 2019 at 00:42):
Looking at the guide, I'm surprised because I see profiles etc but nothing addresses how exchange actually works. What's the anticipated exchange paradigm(s)?
Hoping we can help eventually. We're a way off still being a couple of months in.
If you want to test our API:
ClientId: E33E5625-C666-46F6-8B2E-741DE2D182FC
ClientSecret: 3B4D7FD83978CC799FF4D8CC72221
The identity url to auth against is: http://id.vybrance.co/core and the token endpoint is http://id.vybrance.co/core/connect/token
The URL for the API is: https://api.vybrance.co/fhir
Request client scope: user/*.read (we're beginning on the SMART stuff!)
Now because we're across locations, our MVP for requesting data from a particular location is to pass in a header in your requests: X-VYBRANCE: a3a21e00-da8f-11e9-9f24-377e14000c1b
We're thinking using an extension to support this, but open to ideas!
Courtenay Farquharson (Nov 11 2019 at 00:47):
Go easy and really keen on some feedback!
Grahame Grieve (Nov 11 2019 at 00:51):
I don't understand the MVP bit
Courtenay Farquharson (Nov 11 2019 at 00:52):
I don't understand the MVP bit
Minimum Viable Product - code for we're fairly new and so when it breaks we'll fix it!
Grahame Grieve (Nov 11 2019 at 00:53):
well, I was asking about the header in general. do clients have to do this? why?
Courtenay Farquharson (Nov 11 2019 at 00:56):
well, I was asking about the header in general. do clients have to do this? why?
To identify which location/practice they'd like to read data from.
Grahame Grieve (Nov 11 2019 at 00:58):
and clients have to provide it?
Courtenay Farquharson (Nov 11 2019 at 00:59):
and clients have to provide it?
At this stage yes. What would have been a better way of doing it?
Alex Metelerkamp (Nov 11 2019 at 01:03):
and clients have to provide it?
At this stage yes. What would have been a better way of doing it?
A motivation for most of our customers is the ability to eventually connect to hundreds or thousands of physical locations, from one API - so the need to be able to specify location in the header
Richard Townley-O'Neill (Nov 11 2019 at 01:07):
Is everyone working in R4?
Deanne Ukovich (Nov 11 2019 at 01:15):
It would be best to use R4 as I don't believe there is a plan to maintain STU3
Grahame Grieve (Nov 11 2019 at 01:17):
@Courtenay Farquharson @Alex Metelerkamp you should define different end-points for different locations rather than a custom header. If, on the other hand, you want to also perform operations across the locations, then you need to track this discussion:
Grahame Grieve (Nov 11 2019 at 01:18):
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Multi-Tenant.20FHIR.20Server
Grahame Grieve (Nov 11 2019 at 01:36):
@Courtenay Farquharson your capability statement doesn't have the smart app launch extensions - see http://hl7.org/fhir/smart-app-launch/StructureDefinition-oauth-uris.html
Grahame Grieve (Nov 11 2019 at 01:36):
Also, your capability statement claims to implement all operations on all resources. Is that actually true?
Courtenay Farquharson (Nov 11 2019 at 01:50):
Also, your capability statement claims to implement all operations on all resources. Is that actually true?
Nope! Need to do that!
Courtenay Farquharson (Nov 11 2019 at 03:11):
Courtenay Farquharson Alex Metelerkamp you should define different end-points for different locations rather than a custom header. If, on the other hand, you want to also perform operations across the locations, then you need to track this discussion:
@Grahame Grieve So that discussion doesn't seem to end anywhere specific? Suggestions of Extension? Suggestion of Header
If we want to eventually search across locations, what's best? Seem extension maybe better?
Grahame Grieve (Nov 11 2019 at 03:13):
that discussion is ongoing (I expect) - that's why I suggested to watch it unfold
Grahame Grieve (Nov 11 2019 at 03:16):
the ideal approach is that it's not the client's business; the OAuth process identifies the context, which identifies the location(s) applicable, and the server just knows this list. The client doesn't need to care at all. When the client creates new resources, it has to reference existing patients/encounters etc that provide the location context. And the client doesn't have the right to create new contexts that are not locationalised (e.g. can't register new patients). In that scheme, the client doesn't need to know about locations
Obviously, there's some circumstances in which these approaches don't work, but the corallary of that is that you must trust the client to be part of your security scheme. WHich is not a happy place to be
Courtenay Farquharson (Nov 11 2019 at 03:37):
Fair enough - I can see a world where you simply request a patient or all patients (eg. /patients) and we return patients across locations (that you have access to - via claims/oAuth)
problem comes in inserting patients... There isnt any way around that except for specifying a destination for it I suppose.
Brett Esler (Nov 11 2019 at 04:08):
@Jim Steel a list of GP fields from pregnancy/delivery/post natal https://confluence.hl7australia.com/display/CHWG/Other+Material%3A+Draft+Obstetrics - does not cover gravida etc.but that is there...
Grahame Grieve (Nov 11 2019 at 04:30):
https://fhir.github.io/auto-ig-builder/builds.html
Last updated: Apr 12 2022 at 19:14 UTC
