Stream: genomics / eMerge Pilot
Topic: performer
Larry Babb (Apr 14 2019 at 18:31):
The genomics report profile appears to limit the "performer" to Organization only. We will need the responsible party to be the authorizing practitioner, typically a geneticist acting on behalf on the performing laboratory, so we may need PractionerRole. In any case the v4.1 of DiagnosticReport allows the same set of Reference types Practitioner, PractitionerRole, Organization and Careteam, whereas the genomics report profile does not.
The performer is the party responsible for the contents of the report (the authorizing party that signs of on the clinical report) and the resultsInterpreter it an additional player in that activity as well, these could be and will likely be one in the same for the emerge case.
Larry Babb (Apr 14 2019 at 18:42):
I also noted that performer is the primary party responsible for the results of the test. ResultsIntepreter is described as "might not be the same as the party that takes responsibility for the test".
I do think the way the DiagnosticReport resource in v4.1 current build has it specified is much more appropriate. In that model you can have 0..* performers which can be Practitioners, PractitionerRoles, Organizations or CareTakers in combo. And you can still call out the primary result interpreter to make sure it is clear who did the interpretation. This way you can both assign responsibility to the lab+practitioner for the clinical results and still identify the practitioner that takes responsibility for the results.
Joel Schneider (Apr 15 2019 at 06:32):
May be worth filing a GForge ticket to discuss DiagnosticReport performer and resultsInterpreter.
Bret H (Apr 15 2019 at 12:17):
+1 @Larry Babb within the GForge please refer to the zulip chat so folks can find it.
Kevin Power (Apr 15 2019 at 14:36):
I think this is a better question for #Orders and Observation WG ?
Patrick Werner (Apr 15 2019 at 14:54):
i can see your point @Larry Babb and i also think that R5 handles this better than R4.
From the IG side we could:
- loosen the restriction of performer to allow: Practicioner, PraciticionerRole and Organization
- add a Extension (backPort of ResultsInterpreter) should be part of the core spec at some point as new data fields normally are getting core extension in older FHIR versions for backwards compatibility.
Kevin Power (Apr 15 2019 at 15:26):
From the IG side we could:
- loosen the restriction of performer to allow: Practicioner, PraciticionerRole and Organization
Good point Patrick, we can just "back patch" the R5 change into our IG. We can undo it in the future when we build against R5.
Patrick Werner (Apr 15 2019 at 15:47):
@Larry Babb do you want to open a gforge tracker item on this?
Larry Babb (Apr 16 2019 at 19:20):
@Mullai Murugan and I are working on assessing this further with compliance officers. We will raise it in our upcoming "emerge mapping decision" meetings for those that can attend and inform the final decision for us.
Patrick Werner (May 04 2019 at 21:19):
a quick update on this issue: i just got back on this topic and realised that there were no changes from R4 -> R5 and we already have everything we need. The performer is just to restricted in our profile.
Mullai Murugan (May 08 2019 at 15:52):
After some discussion with our internal compliance group, we have reached the conclusion that the performer should be Organization for our use cases. At this point, the current draft spec will work for us. Thank you all for the feedback and discussion.
Larry Babb (May 09 2019 at 11:52):
While I agree that the current constraint that CG is putting on "performer" works for our needs. I still do not understand why CG reports would limit the ability to have the same options for "performers" as the default Resource. I would recommend that the CG group re-address this or clarify in their documentation the reasoning behind preventing other Diagnostic.perform types other than Organization.
Bret H (Aug 21 2019 at 03:24):
Check out the US CORE observation profile. It has a good example of how to get performer in as a slice.
Kevin Power (Aug 21 2019 at 03:32):
I can double check but I think this has been resolved. We removed the constraints we had on performer.
Last updated: Apr 12 2022 at 19:14 UTC
