Stream: inferno
Topic: Reference in Provenace
Lakshmi Bhamidipati (Mar 21 2021 at 01:11):
Hello,
In Provenance, since the reference to an Author(Practitioner) and an Organization can be external to our EHR system, can I display the reference as a "Contained resource"? Instead of using a relative URL to the resource?
I have the name and NPI of the practitioner and resource.
Thank you.
Robert Scanlon (Mar 21 2021 at 14:08):
The references are for the "US Core Practitioner" and "US Core Organization" profiled version of the resources specifically, which I believe means you cannot have a contained reference for those resource types. Our tests may be more flexible than that right now, and may only require you to demonstrate that you can support non-contained references there (vs. requiring only non-contained references), but I'd have to check. @Brett Marquard @Eric Haas what does FHIR/US Core say about it now?
Eric Haas (Mar 21 2021 at 14:49):
we added revised language surrounding containment in the balloted version here: http://build.fhir.org/ig/HL7/US-Core/general-guidance.html#contained-resources. In general don't use contained resources.
Lakshmi Bhamidipati (Mar 22 2021 at 01:16):
Thank you. So a contained resource cannot be a US Core Practitioner or a US Core Organization? If I have a name and an NPI, isn't the data sufficient to represent the resource? The link above says "If referencing a contained resource in a US Core Profile, the contained resource SHOULD be a US Core Profile if a US Core Profile exists for the resource type. ". The reason I am asking this is to represent the "last hop" provenance data when data is coming into our system through an HIE for say Labs. In that case, I need to represent the external Organization and external Practitioner in the provenance resource. I am not sure how to create a relative reference to it.
Yunwei Wang (Mar 22 2021 at 13:37):
I don't know your internal design. If server can save those as contained resource, why server cannot save those as regular FHIR resource?
Robert Scanlon (Mar 22 2021 at 14:28):
In that case, I need to represent the external Organization and external Practitioner in the provenance resource. I am not sure how to create a relative reference to it
Probably an extremely naive question but bear with me: when ingesting from an HIE, why not check to see if the organization/practitioner with that NPI is already a resource in your system, and if it is, point the reference to that resource? And if not, create a new resource?
Lakshmi Bhamidipati (Mar 22 2021 at 16:01):
Thank you @Robert Scanlon @Yunwei Wang . Our FHIR server does not have the ability to POST resources. It is a facade that GETs data from our EHR system and outputs FHIR resources. When we make a request to say Practitioner/<id>, we look to see if such a practitioner with the <id> is present in our database and then we get the related information such as NPI, name, address etc. When we don't have information related to the organization or practitioner in our database, I was wondering if we can reference using a contained resource.
Lakshmi Bhamidipati (Mar 22 2021 at 16:04):
Yunwei Wang said:
I don't know your internal design. If server can save those as contained resource, why server cannot save those as regular FHIR resource?
I wasn't planning on saving the contained resource, just creating a FHIR response with the data.
Yunwei Wang (Mar 22 2021 at 16:37):
I remember there were several discussions on #implementers stream about how to handle reference as an information broker/middle-man. A broker should be able to handle client's request though it does not hold the resource itself.
Robert Scanlon (Mar 22 2021 at 17:54):
When we don't have information related to the organization or practitioner in our database, I was wondering if we can reference using a contained resource
This is confusing to me, because you do have name & NPI, which is information related to the organization & practitioner. You just mean that you are not currently storing it like your other Practitioner/Organization information that you expose via the Practitioner/[id] and Organization/[id] queries, right? Or am I misunderstanding.
Lakshmi Bhamidipati (Mar 22 2021 at 18:25):
Robert Scanlon said:
When we don't have information related to the organization or practitioner in our database, I was wondering if we can reference using a contained resource
This is confusing to me, because you do have name & NPI, which is information related to the organization & practitioner. You just mean that you are not currently storing it like your other Practitioner/Organization information that you expose via the Practitioner/[id] and Organization/[id] queries, right? Or am I misunderstanding.
Sorry for the confusion. You are correct. We are storing this information in the database (as part of provenance for HIE system records), just not in our organization and practitioner table. I have to take it back to our team and mention that this data needs to be part of Organization and Practitioner tables so that they can be accessed by FHIR as a reference. Your input and comments were helpful. Thank you!
Santosh Pai (Mar 24 2021 at 15:50):
Thanks. We will look at our server and the API manager in front of it.
Lakshmi Bhamidipati (Apr 02 2021 at 15:13):
@Eric Haas - In reference to your reply related to contained resources in Provenance, the link that that you pointed to says " If referencing a contained resource in a US Core Profile, the contained resource SHOULD be a US Core Profile if a US Core Profile exists for the resource type.". Bear with me... :) If say I create a contained resource of type Organization or Practitioner in a Provenance resource, is it invalid even though Organization and Practitioner are US core profiles? The reason I ask is that while it is not impossible for us to implement saving Organization and Practitioner when data (like Lab results) is being received from an external organization, the implementation is not ideal. The reason being, we are supposed to display provenance data as-is from an external system. Extracting the organization/practitioner data from the provenance info and storing it in an organization table in order to create a FHIR logical reference may break the integrity of the provenance data. Thanks!
Robert Scanlon (Apr 06 2021 at 18:54):
Sorry I missed your update! From a g10 certification test tool perspective, if use of contained resources is "just" strongly discouraged (and not strictly disallowed) then the automated ONC g10 certification test tool shouldn't fail you outright, unless ONC provides additional requirements on top of the specifications. But ONC recently updated their CCG to provide leniency with respect to externally-originated and legacy data:
Information originating from the (g)(10)-certified Health IT Module must conform to the requirements included in the criterion, but legacy information and information from outside systems is not required to be mapped to the United States Core Data for Interoperability (USCDI) “Applicable Standards” and the US Core IG terminologies and value sets.
The question you asked in implementers may get a different response from a human-review "test" perspective though (does NPI counts as 'identifying' information?). I'm curious if anyone says anything.
I should have asked you this up front: does Inferno FAIL you today if you used contained resources for those elements in Provenance? I would have thought that our tests would have allowed this, but perhaps there is something in there that blocks it. Could you provide a sample resource for me to try?
Lakshmi Bhamidipati (Apr 07 2021 at 01:47):
@Robert Scanlon - I didn't implement it yet, so I don't know if the tool will fail. Prior to implementing, I wanted to make sure I was doing it right. I just read the replies in Implementers stream and it looks like the consensus is not to have contained resource. I am probably unable to explain this properly, but the reason I am leaning towards "contained" is from what my interoperability/HIE resource is telling me that when provenance data comes from an external system with an NPI, Name etc.. that information may or may not be correct. In sense, it is possible that an NPI could point to an incorrect organization because there is a bug in the external system. But our system is supposed to display the provenance data as is; Hence I cannot take that incorrect NPI-name combination and store it in a master table to use as a reference. I don't know how likely this occurs, but that's what I was told.
Robert Scanlon (Apr 07 2021 at 13:52):
Yes, I can understand all the practical issues involved here. Introducing dirty data into an area that your systems very much rely on being validated & correct could be problematic. And I can see provenance metadata being a lot more messy than the 'regular' data being exchanged, because it is of less practical importance -- making sure that data is accurate isn't free, and is validating/deduping/etc this particular information how you want to be spending limited resources?
Robert Scanlon (Apr 07 2021 at 14:12):
I can think of plenty of technical solutions that present a 'correct' FHIR interface while keeping this data separate behind the scenes so it doesn't mess up existing rules about what is stored in your master practitioner table. For example, you could format your ids in such a way that you know to look for Practitioner/provenance-XYZ over in the provenance store, and just parse out the practitioner information of the XYZ provenance record and send it back. Or for a more FHIR-aligned method, store provenance information about that newly created practitioner itself, so you know that it comes from a highly dubious source (the HIE), and then upgrade existing systems to pay attention to provenance information so they can filter out untrusted sources if necessary. All of this is complexity though. And I can't say what makes sense for your product technically given your users / business / goals / etc.
Robert Scanlon (Apr 07 2021 at 14:29):
My general feeling, today, is that if you work around this issue on the facade level (either by using contained resources, or by doing some fancy ID parsing and routing), instead of migrating your systems to be closer to 'native fhir', you'll probably be accruing some technical debt. However, taking on technical debt might be the right choice for your product. It buys you time and lets you see if FHIR continues to gain momentum before making a bigger investment in aligning your systems internally to fhir.
Lakshmi Bhamidipati (Apr 07 2021 at 15:15):
@Robert Scanlon - I appreciate your detailed reply. We are leaning towards this suggestion of yours - "you could format your ids in such a way that you know to look for Practitioner/provenance-XYZ over in the provenance store, and just parse out the practitioner information of the XYZ provenance record and send it back". Just that the implementation is a little messy with our current provenance data storage (but doable) :) Which is why I wanted to see what the FHIR community has to say. Thank you!
Robert Scanlon (Apr 07 2021 at 15:27):
Yeah, I worry a little bit that we are encouraging workarounds for compliance sake that functionally do not provide any value from a semantic interop perspective. I suppose it is slightly better syntactically, since there is more consistency if nobody uses 'contained' resources here (it is easier for clients if they can always expect a URL to follow instead of knowing to look for contained resources too). But now you are going to have lots of duplicated practitioners exposed out of the /Practitioner endpoint... since /Practitioner/100 may be the same as /Practitioner/provenance-4594, and /Practitioner/provenance-4352344 and /Practitioner/provenance-324234dd... which doesn't seem right.
Lakshmi Bhamidipati (Apr 07 2021 at 15:30):
Exactly!
Robert Scanlon (Apr 07 2021 at 16:12):
So what clients may gain in slightly simpler parsing rules they pay for when they do a practitioner search by NPI. All of the sudden they will be given all of these duplicate phantom practitioner records that only exist because they are linked from provenance records. You could choose to simply not search those provenance-practitioner records in the NPI search (or simply forget to because the data is now in two spots, not one), but then you run afoul of FHIR by not exposing that data because technically you have it.
Lakshmi Bhamidipati (Apr 07 2021 at 17:14):
ah, yes. That could a problem. The consuming app won't be able to search using NPI for provenance (external) practitioners or organizations because we will be ignoring them in search; just read will be supported for this particular type of practitioner/organization. Something for us to consider. Thank you.
Last updated: Apr 12 2022 at 19:14 UTC
