Stream: IPA
Topic: Focus and scope
Mikael Rinnetmäki (Sep 15 2021 at 18:05):
We had a short discussion with @John Moehrke on the Patient Empowerment WG call on the role of the IPA. I believe John was saying that IPA is just about finding and profiling the core set of resources that will work with implementations around the globe. Whereas for me, the major thing is the access part, and I can see use cases for a harmonized rules for app authentication even if the content returned by the server ends up being CDA or HL7v2 or whatever.
Mikael Rinnetmäki (Sep 15 2021 at 18:06):
To better formulate that I made a pull request to the Github repo, https://github.com/HL7/fhir-ipa/pull/14. Happy to discuss here or there.
John Moehrke (Sep 15 2021 at 18:06):
that scope sounds more like SMART-on-FHIR
Mikael Rinnetmäki (Sep 15 2021 at 18:08):
Well, to me the point is that we should be able to say that SMART on FHIR is the mechanism you use to get your data. As it currently already says in http://build.fhir.org/ig/HL7/fhir-ipa/branches/main/access.html#gaining-access-to-a-patient-record.
Mikael Rinnetmäki (Sep 15 2021 at 18:08):
And that is a (or, for me, the) key building block of IPA.
Mikael Rinnetmäki (Sep 15 2021 at 18:14):
The key driver for this approach is the messages I hear from here in Finland and from Denmark: it is unlikely that the implementations currently filled with CDA and HL7v2 data will map that data into FHIR resources, at least in the short term. And for me it is more valuable to get the data to patients soon, regardless of the format, rather than waiting for some years until an implementation supporting the FHIR mapping is available. And the even worse scenario is that implementers deem IPA as not suitable for them because they are not willing to do the resource mapping, and therefore ditch any plans to use SMART too...
Mikael Rinnetmäki (Sep 15 2021 at 18:17):
Or, without an IG, they might stick to SMART, but everyone would end up implementing their own flavors on it. It is clear that there will be different approaches to app accreditation, for instance. But I'd like to see an attempt to harmonize those on some level, for instance a Nordic profile instead of a Finnish, a Danish, a Norwegian, and a Swedish implementation.
John Moehrke (Sep 15 2021 at 18:30):
IHE does have that covered -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
John Moehrke (Sep 15 2021 at 18:33):
that said... I am just another peer on this project. IPA will end up doing what the community desires. I simply am not a fan of re-inventing solutions that already exist.
Brett Marquard (Sep 15 2021 at 19:11):
I thought IPA would include content and access...
John Moehrke (Sep 15 2021 at 20:37):
I think the main topic is if IPA will constrain the kind of content at all.
John Moehrke (Sep 15 2021 at 20:37):
if there is no constraint on the content, then I say that this is what SMART-on-FHIR already expresses.
John Moehrke (Sep 15 2021 at 20:38):
if there are constraints... which the current effort is to determine what the minimal viable set of FHIR resources will be...
Mikael Rinnetmäki (Sep 16 2021 at 06:10):
Fair enough, @Brett Marquard, and I fully support that. The challenge for me is that some implementers in this part of the world seem to be interested in opening data for patient access, but are less willing to go all the way with mapping their data to FHIR. Hence my proposal for a very generic base level spec that specifies access, and then profiles for content on top of that.
Mikael Rinnetmäki (Sep 16 2021 at 06:12):
@John Moehrke , I feel I'm really poor at skimming through IHE documents for some reason. Can you please point me to the part of the white paper that explains an implementer that if you want to open access to data for patient apps, you shall use SMART?
John Moehrke (Sep 16 2021 at 11:17):
IHE does not use SMART. IHE has had an OAuth profile (IUA) well before HL7 decided to profile OAuth in the SMART spec. The two are closely aligned, but distinct. And MHD can be used with SMART.
The paper I pointed you at has a whole section 7 dedicated to the concept - https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#7-security-and-privacy
John Moehrke (Sep 16 2021 at 11:20):
Is the point you are asking for is that DocumentReference be included in the core set, so as to enable access to historic (and FHIR) documents? I would agree with this, I have agreed with the inclusion in current us-core. I have worked with them to make the us-core use of DocumentReference as close to aligned with MHD as I can (I have failed because I am just one voice). I am not against this in IPA, I just want it to be respectful of current implementation guides that are intended to cover the space.
Brett Marquard (Sep 16 2021 at 13:33):
@John Moehrke Do you have a current list of alignment issues between MHD and US Core DocumentReference? I don't recall any 'conflicts'
John Moehrke (Sep 16 2021 at 13:39):
hmm, I am proven wrong on that point. I just looked and see no conflict, infact it seems more aligned than I expected...
Brett Marquard (Sep 16 2021 at 13:43):
Maybe another totally naïve question -- Has anyone done a gap analysis of IUA vs SMART?
John Moehrke (Sep 16 2021 at 13:48):
There is an assessment inside the IUA explaining the intentioned difference in scope. To that point, end-users (practitioners or patients) are not in primary scope for IUA, and they are clearly primary scope for SMART. So i have taken the position of recommending SMART when the use-case is an end-user application, and IUA for B2B where federated identity and tokens are more used. Thus the overlap is biggest between IUA and bulk-data SMART... THIS said, there is now major overlap in the new HL7 "udap" work item that overlaps with both of them.
John Moehrke (Sep 16 2021 at 13:50):
the fhir spec mentions both IUA and SMART in addition to HEART -- http://hl7.org/fhir/security.html#authentication
John Moehrke (Sep 16 2021 at 13:51):
As I have asked many times... CR are welcome in both fhir core, and IHE. I (as HL7 security wg co-chair) do NOT think that enough attention have been given to these topics, there is not enough input from practical reality, there are too few providing feedback and recommendations.
Last updated: Apr 12 2022 at 19:14 UTC
