Stream: ihe
Topic: ITI profiles
John Moehrke (Feb 11 2017 at 08:07):
ITI domain has 5 profiles. Each of them are on DST2, and will simply be updated to STU3 in the coming month (MHD, PDQm, ATNA, PIXm, and mACM). There is some question of if mACM use of CommunicationRequest is still the right solution. There is some question if PIXm should evaluate and use te Patient MPI mechanism. Please provide constructive/critical comment
Frank Oemig (Feb 23 2017 at 12:59):
hello, I am not sure how to use the MHD profile, or, in other words, whether it is correct what we have currently defined. The profile tells me, that XDS.documentEntry.creationTime should be mapped to MHD.documentReference.indexed and that MHD.documentReference.created should not be used. According to my understanding I would have expected that XDS.documentEntry.creationTime is mapped to MHD.documentReference.created because this is the information about the creation of the document. MHD.documentReference.indexed is the information when the DocumentReference Resource instance has been created. Where am I wrong? thx regards Frank
John Moehrke (Feb 23 2017 at 15:33):
Hi Frank, You are not wrong, and this is why both are in trial state; as we need feedback. It does seem that XDS.documentEntry.creationTime is assigned to the wrong FHIR element. It should be DocumentReference.created. I note that the mapping on the FHIR DocumentReference is also incorrect. I think I can fix FHIR under Quality fixes this week. MHD needs a CP, which we will fix this summer when we align with STU3.
John Moehrke (Feb 23 2017 at 15:43):
Frank Oemig (Feb 23 2017 at 16:16):
ok, good, so, using the right entries would be in favor of this correction then, right?
John Moehrke (Feb 23 2017 at 16:18):
corrections are always welcome. Thanks
Jens Villadsen (Aug 20 2018 at 07:30):
@John Moehrke Reading the text @ https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) it sounds like MHD is primarily for resource constrained devices - because of the use of FHIR. I disagree. The use of FHIR makes a lot of things more simple and the typical frameworks that are used in interaction with FHIR are more lightweight - but FHIR is suited just as much on the backend of large enterprise systems
John Moehrke (Aug 20 2018 at 12:35):
@Jens Villadsen reading a summary wiki page is not like reading the full specification. Summary specifications tend to be less complete. We explain this more fully in the formal specification.
Jens Villadsen (Aug 20 2018 at 14:59):
I agree.
Jens Villadsen (Aug 20 2018 at 14:59):
But does that justify the content?
Elliot Silver (Aug 20 2018 at 17:44):
IHE already has defined general mechanisms for sharing documents: XDS and XCA. In general, non-constrained devices are capable of using those mechanisms. On the other hand, more constrained devices are unable to use those mechanisms, or the overhead required to use them is obviously a non-starter on a constrained device. Thus, MHD expands IHE's solution space into an area previously not addressed: constrained devices.
Does that mean that non-constrained devices won't see benefits using MHD? No, they might, but the benefit is less clear cut, and they were supported with the previous mechanisms, so it is less important to emphasize this capability.
Jens Villadsen (Aug 20 2018 at 18:15):
I guess that depends on how you 'measure' the benefit - avoiding memory hungry SOAP serializers is beneficial on all platforms - big as small, as well as saving CPU cycles traversing (overly) complex structures (especially) when running (FaaS) in the cloud.
John Moehrke (Aug 20 2018 at 18:16):
Let me quote @Elliot Silver
"Does that mean that non-constrained devices won't see benefits using MHD? No, they might, but the benefit is less clear cut, and they were supported with the previous mechanisms, so it is less important to emphasize this capability."
John Moehrke (Aug 20 2018 at 18:17):
so... there is no statement that MHD is not helpful to everyone... just that it is more helpful to those that are constrained... You seem to be wanting to read this fact as an inverse fact.
Jens Villadsen (Aug 20 2018 at 18:19):
My point is that it is helpful to everyone
John Moehrke (Aug 20 2018 at 18:19):
In practice there are organizations that are fully capable of using the classic SOAP, but are choosing to implement MHD... One example that went public lately is CommonWell and new partners.
John Moehrke (Aug 20 2018 at 18:20):
It is not helpful to those that have already implemented XCPD/XCA, or those that have a SOAP toolkit and no REST toolkit.
Jens Villadsen (Aug 20 2018 at 18:21):
depends on how their CPU cycles are billed
John Moehrke (Aug 20 2018 at 18:21):
not really... you are grasping
John Moehrke (Aug 20 2018 at 18:22):
I have no problem clarifing this.. .but I am not about to tell hundreds of working organizations that they must throw away the investment... all for a few cpu cycles?
Jens Villadsen (Aug 20 2018 at 18:22):
they shouldn't throw it away if it works for them
John Moehrke (Aug 20 2018 at 18:24):
so then, do you have a recommendation for how this can be said better?
Jens Villadsen (Aug 20 2018 at 18:28):
that (FHIR) is usually less resource demanding than SOAP because of the more intensive wrapping?
John Moehrke (Aug 20 2018 at 18:29):
Is that a statement of fact, or a question?
Jens Villadsen (Aug 20 2018 at 18:32):
touché - ... that would be my not-so-scientific presumption
Jens Villadsen (Aug 20 2018 at 18:42):
which I guess is something you agree on since the text says its a good fit for constrained devices or what?
John Moehrke (Aug 20 2018 at 18:45):
The availability of RESTful toolkits is indeed far easier on constrained environments. Tying to get a SOAP stack onto an iPHone or Android is possible, but hard. I don't think that is a question, and is indeed the message... That does not mean the opposite is false, there is no meaning on the opposite.
Jens Villadsen (Aug 20 2018 at 18:50):
im just saying its beneficial to all platforms and because of that I wouldn't highlight one platform over another as it is beneficial to both
Jens Villadsen (Aug 20 2018 at 18:51):
I would highlight that one stack is more lightweight than the other
Jens Villadsen (Aug 20 2018 at 18:52):
that is my postulate
John Moehrke (Aug 20 2018 at 18:52):
the word 'lightweight', or 'beneficial', or 'best', are all subjective.
John Moehrke (Aug 20 2018 at 18:53):
subjective is a fine thing to be in marketing material, not useful in a standard.
Jens Villadsen (Aug 20 2018 at 20:11):
im not selling anything - and I agree. But I can imagine that MHD is less byte-verbose on the wire than XDS and maybe as a consequence serialization frameworks are less mem hungry. I would call that lightweight (being objective about it) without feeling that I had to sell anything.
Simone Heckmann (Aug 23 2018 at 08:39):
IMO the major advantage of MHD over XDS lies not so much in the comparison of the two profiles alone.
If you chose to implement MHD, you can also implement all the related Profiles (PIX/PDQ/ATNA) using one - and only one - technology stack. You don't have that option with XDS. I think that that is a point that could be more emphasized because it's definitely relevant to implementers, regardless of their platform and it's probably something that isn't obvious to people who are new to the specification.
John Moehrke (Aug 23 2018 at 12:17):
Yes @Simone Heckmann that is a point that I have made. This is very important for the Source or Consumer actors. Which is why these profiles are first being introduced as API to existing systems. This API consistency enables new apps. When viewed this way one is not "throwing the baby out with the bath water". One gets the benefit for Apps, while not invalidating the investment already in the infrastructure.
Last updated: Apr 12 2022 at 19:14 UTC
