Stream: implementers
Topic: external data
Brian Postlethwaite (Mar 21 2016 at 00:43):
Looking for feedback from others as to how to model data that came from an external system.
I just want to be able to identify which system content came from (for 2 purposes, so I can know who to go talk to for data quality issues, and also as a consumer of the data, how much confidence I should have in it)
The data in particular that I am looking at is service provider directory information from other systems, and client created content.
Was considering provenance, but this doesn't seem right to me (or the wrong way round).
Grahame Grieve (Mar 21 2016 at 00:50):
what pieces of information do you want?
Brian Postlethwaite (Mar 21 2016 at 00:52):
From the directory space, it will be showing that this content "came from the NHSD" or "came from ConnectingCare" or "came from Melbourne Health Enterprise Directory"
Brian Postlethwaite (Mar 21 2016 at 00:52):
(but with more technical details behind it)
Grahame Grieve (Mar 21 2016 at 00:52):
and what kind of resources are we talking about?
Grahame Grieve (Mar 21 2016 at 00:52):
and what more technical details...
Brian Postlethwaite (Mar 21 2016 at 00:53):
primarily just Organization, Location, Practitioner, HealthcareService
Brian Postlethwaite (Mar 21 2016 at 00:53):
Stuff that you're likely to have a cached set of data locally for content that was sourced from parent directories.
Grahame Grieve (Mar 21 2016 at 00:53):
? I don't understand that
Brian Postlethwaite (Mar 21 2016 at 00:55):
Inside my EHR I have a set of this information that is my internal data, and a set of this that is external to my organization (which today is hand entered in and maintained)
This data can quite easily be sourced externally, and udpated locallay within my EHR's black book of details.
Brian Postlethwaite (Mar 21 2016 at 00:55):
So all the orgs that I interact with to send referrals for example, or pathology locations
Grahame Grieve (Mar 21 2016 at 00:56):
I'm still in the dark as to what more technical details we're talking about (other than just name)
Brian Postlethwaite (Mar 21 2016 at 00:59):
The coded references and endpoint information of the parent FHIR service that this content was retrieved from
Brian Postlethwaite (Mar 21 2016 at 00:59):
What the user sees is just the name, but from a data currency point of view need to know the technical details of the linkage so that if it changes I can keep things in sync.
Grahame Grieve (Mar 21 2016 at 01:00):
how are things kept in sync?
Brian Postlethwaite (Mar 21 2016 at 01:01):
In our case we have logic that processes this as needed, and could be sourced using the subscription service from the FHIR server that had the data.
Grahame Grieve (Mar 21 2016 at 01:01):
I mean, you use identifiers?
Brian Postlethwaite (Mar 21 2016 at 01:01):
Correct.
Brian Postlethwaite (Mar 21 2016 at 01:02):
(Would have to check, but I think we also have the mapping to the resource ID from the source FHIR server in our backend) So it's not a best guess mapping
Grahame Grieve (Mar 21 2016 at 01:02):
so what would happen if one of the contributing orgs changed their end-point?
Brian Postlethwaite (Mar 21 2016 at 01:03):
This is part of that other request incoming with the endpoint resource. So that you can update it.
Brian Postlethwaite (Mar 21 2016 at 01:03):
Yes, Its a variation on the Australian ELS stuff
Brian Postlethwaite (Mar 21 2016 at 01:06):
If you are meaning about the base address on the resources, then this is not the answer to that issue. And this is a wider issue of using external references to other servers (as could be in Patient Reference links, and Person references)
Grahame Grieve (Mar 21 2016 at 01:44):
well, typically, the combination of system + identifier is meant to handle external references
Grahame Grieve (Mar 21 2016 at 01:44):
or maybe I should say, external alignment
Brian Postlethwaite (Mar 21 2016 at 01:45):
I was referring to where we use the Reference datatype with an explicit reference to an external system.
Brian Postlethwaite (Mar 21 2016 at 01:46):
(As can be done with Patient.Link and Person.Link
Grahame Grieve (Mar 21 2016 at 01:47):
well, maybe you need to propose links in a few more resources in order to support the kind of workflows you are porposing. Else if thy arne't common, then you have extensions...
Brian Postlethwaite (Mar 21 2016 at 01:49):
I think in the directory space this will become very common, outside that, not so convinced.
Grahame Grieve (Mar 21 2016 at 01:52):
well, you can propose 'support for directories' as an explicit scope for the resources, and then add what is needed for directory support
Grahame Grieve (Mar 21 2016 at 01:52):
if that's specific focused sub-use of the resources
Brian Postlethwaite (Mar 21 2016 at 01:53):
Thanks, will put it into that context, and may even write up a seperate page to describe how this could all flow together.
Brian Postlethwaite (Mar 21 2016 at 01:53):
(draft for now - and hope to try out stuff in Montreal)
David Hay (Mar 21 2016 at 04:01):
and, for the record, how we did it
Brian Postlethwaite (Mar 21 2016 at 04:04):
Thanks for the link David, very informative, and includes another link to how Rene describes it in his article talking about it too.
David Hay (Mar 21 2016 at 04:06):
you're welcome 
Peter Bernhardt (Mar 21 2016 at 18:07):
@DavidHay Thanks for the blog link, David. FWIW, we've taken a similar approach after review of Provenance and concluding it is too heavy.
David Hay (Mar 21 2016 at 18:29):
Thanks peter - are the use cases the same? can we use the same extensions?
Peter Bernhardt (Mar 21 2016 at 18:39):
@davidhay The use cases are the same - processing incoming data from v2, CDA, claims. I think it makes sense to align on extensions.
Grahame Grieve (Mar 21 2016 at 20:10):
@Peter Bernhardt @David Hay can you be specific about which resource types you were interested in?
Peter Bernhardt (Mar 21 2016 at 21:11):
@Grahame Grieve this would include any resource that can be mapped from v2, CDA, 837 etc. So just about all of them.
Grahame Grieve (Mar 21 2016 at 21:32):
I thought you might say that ;-)
David Hay (Mar 22 2016 at 07:55):
me too I'm afraid - I can get a list of what we currently get but off the kuff it's encounter, labs, procedures, conditions, allergies
Peter Bernhardt (Mar 22 2016 at 15:53):
@Grahame Grieve @David Hay what's the best way to move forward on this? propose a standard extension to the base resource?
Grahame Grieve (Mar 22 2016 at 19:12):
That might be the way to go, yes
John Moehrke (Mar 23 2016 at 20:23):
@Peter Bernhardt - I sympathize with your statement about Provenance being too heavy... I am struggling to control it, but without different people participating in sub-commttee meetings it is only going to get more complex. Please consider sending people to the calls tuesday afternoon 5pm Eastern -- security wg.
Grahame Grieve (Mar 23 2016 at 20:27):
I'm not sure that provenance is the right thing here anyway
Grahame Grieve (Mar 23 2016 at 20:30):
provenance should be detailed. what people want seems to be a dual thing - a pointer to source, and a display for the source.
Grahame Grieve (Mar 23 2016 at 20:31):
so source : Reference(Any), except that the source would not necessarily be an actual resource.
Peter Bernhardt (Mar 23 2016 at 20:55):
@John Moehrke @Grahame Grieve @David Hay Just added change request 9750 for this issue.
Grahame Grieve (Mar 23 2016 at 20:58):
I think we should define a standard extension for resource.meta to allow us to evaluate the idea
Peter Bernhardt (Mar 23 2016 at 20:59):
@Grahame Grieve sounds reasonable.
John Moehrke (Mar 23 2016 at 21:24):
that CP is proposing a very different solution. i was looking for particiaption to make Provenance more realistic.
Grahame Grieve (Mar 23 2016 at 21:56):
sure. I believe in that too
David Hay (Mar 24 2016 at 02:22):
@Grahame Grieve - yes, that is exactly what we're after. Where did this particular resource come from... (in our case, via a v2 message).
René Spronk (Mar 24 2016 at 07:10):
@David Hay (tongue in cheek) associate your resource with a MessageHeader ? You'd know where the resource came from ;-)
David Hay (Mar 24 2016 at 07:47):
great idea! (irony) And I'd use the CDA header (composition) when the data come from a CCDA...
David Hay (Mar 24 2016 at 07:47):
(actually, ultimately there may be merit in those ideas)...
René Spronk (Mar 24 2016 at 08:11):
If you were to post a FHIR-message to / it's exactly what you'd have in your FHIR persistence layer. Nah, that would be too easy, we got to think of something more complex than that.
Peter Bernhardt (Mar 24 2016 at 14:57):
@René Spronk @David Hay MessageHeader occurred to me, too. ;) But yes, this would need to be more generic in order to account for different input streams.
James Butler (Mar 28 2016 at 21:23):
MessageHeader is too specific for the case that David and I are looking at - for starters if the resource content is aggregated from multiple messages then it would be misleading to present the source info in a single MessageHeader, and clumsy to use several. But perhaps there's some common concept of "source" which could be shared between cases.
Last updated: Apr 12 2022 at 19:14 UTC
