Stream: ihe
Topic: MHD
John Moehrke (Nov 03 2017 at 20:02):
I have uploaded a set of StrutureDefinition and ImplementationGuide for MHD. pointers also in the IHE wiki for MHD http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide
John Moehrke (Nov 03 2017 at 20:03):
Comments and improvements welcome.... Thanks to @Ardon Toonstra who did the prototyping for me.
Simone Heckmann (Nov 12 2017 at 20:48):
deleted... I was looking at the wrong slice...
Simone Heckmann (Nov 12 2017 at 20:52):
I don't think "fullURL" is going to work as a slicing discrimiator for Bundle.entry...
Simone Heckmann (Nov 12 2017 at 20:55):
I think it should be resource.id (Type)
Simone Heckmann (Nov 12 2017 at 20:55):
...or rather resource.id (Profile)
Simone Heckmann (Nov 12 2017 at 21:12):
Because of this:
pasted image
I think it'd be safe to fix entry.request.method to "POST" for all slices
Simone Heckmann (Nov 12 2017 at 21:13):
How did you manage to set entry.resource to 1..* !? O.o
The base spec allows only 0..1. Is that a Simplifier/Forge bug? That shouldn't be possible...
Simone Heckmann (Nov 12 2017 at 21:14):
Bundle.total can go away, it's not permitted on transactions
Simone Heckmann (Nov 12 2017 at 21:21):
Are there any circumstances under which an instance may carry a modifierExtension and still be compliant with MHD? If not, they should all be 0..0
Simone Heckmann (Nov 12 2017 at 21:42):
A general question about cardinalities: e.g. DocumentReference.created is set to 0..0, meaning, it's explicitly forbidden and every instance that carries a 'created' element will fail validation. Is that the intention here? Or is that just saying that MHD doesn't need the 'created' element?
If so, then I'd suggest something like this
- everything that's required in MHD is set to 1..1 (or an invariant)
- everything that's used in MHD but not required gets a 'mustSupport' flag
- eveything that's not used in MHD is left unchanged
- everything MHD explicitly forbids is set to 0..0
I agree that that's not an exact match for the 'mustSupport' semantic, but then again the spec itself says that every profile needs to specify what 'mustSupport' means in it's particular context...
René Spronk (Feb 05 2018 at 09:23):
Why is DocumentManifest a required resource in MHD? I can see why it would be required if one uses the "XDS on FHIR" option (because of legacy requirements in XDS.b and ebRM), but if one does NOT use that option, why use DocumentManifest ? After all, the aim is to make things as easy as possible for a client.
John Moehrke (Feb 05 2018 at 13:18):
All of the IHE defined Document Sharing mechanisms include the equivalent of DocumentManifest. It is there to express what and why of the transaction. In push use-cases it is the equivalent of the message header. Which use-case are you most worried about? Publication or Consumption? It is effectively not requirement on the consumption side. On the publication side it is a minimal burden. Please explain your concern.
René Spronk (Feb 05 2018 at 14:08):
If I explain MHD to someone who knows FHIR, but knows nothing of XDS, I have a hard time explaining as to why DocumentManifest is a required resource when submitting a document as a mobile client. It's essentially provenance, which may, or may not be applicable in a given context.
In the context of the MHD "XDS on FHIR" option it makes sense to use it, if only because (as you say) all other IHE defined doc. sharing profiles use it. However, if we don't have that context, what's the unique selling point for including it mandatorily ?
John Moehrke (Feb 05 2018 at 14:33):
So the main message is that the DocumentManifest is what explains why the Bundle is being pushed. It is, like the paper manifest in a cardboard box.
John Moehrke (Feb 05 2018 at 14:34):
I can understand the confusion in that specific audience. They likley would be more comfortable with a MessageHeader... right? (or, I suspect from your messaging posts that they are confused on messaging too)...
John Moehrke (Feb 05 2018 at 14:37):
lastly, the degenerate form is rather small and easy to fill out. So it isn't technically hard to do. They are just focused on what appears within their small frame-of-reference to be unnecessary. This is addressed by reminding them that it is a multiple re-usable standard.
René Spronk (Feb 05 2018 at 14:43):
k. On HTTP redirects in MHD - I would assume a common use case would be a Document Responder upon recieving a GET for a certain Binary? Or what would the best example be in your mind?
John Moehrke (Feb 05 2018 at 15:17):
the most likely is OAuth...
René Spronk (Feb 05 2018 at 16:01):
Mm - I'm not enough of an Oauth expert to get the hint, could you elaborate a bit?
John Moehrke (Feb 05 2018 at 16:07):
so when a Resource Server receives a simple HTTP GET without an OAuth token, it will redirect the client back to the OAuth service that it trusts.
John Moehrke (Feb 05 2018 at 16:08):
The other redirect invisioned is related to where the URL in the DocumentReference is possibly something like an on-demand, or defered-creation... it is just good to remind clients that they should follow redirects, so we did.
Grahame Grieve (Feb 05 2018 at 19:37):
Im not really understanding, from the explanation, why not to use Composition and/or provenance
John Moehrke (Feb 05 2018 at 20:01):
@Grahame Grieve I don't understand? Which part of MHD are you asking about? Certainly a DocumentReference can point at a FHIR Document.
Grahame Grieve (Feb 05 2018 at 20:02):
the DocumentManifest part
John Moehrke (Feb 05 2018 at 20:04):
so DocumentManifest was created specifically to mirror XDS SubmissionSet. Which is a different scope than Composition. Composition, if I understand correctly, is the main Resource inside a FHIR Document. Where DocumentManifest is a manifest on a package (bundle) of DoumentReference that point at documents. Where documents is inclusive of FHIR documents, but also includes CDA, CCR, PDF, DICOM, and anything else that has a mime-type.
Grahame Grieve (Feb 05 2018 at 20:06):
that's not a meaningful difference. Composition is for describing a set of changes to a record, along with a text narrative
John Moehrke (Feb 05 2018 at 20:07):
okay. but it still is the prime part of a FHIR document... right?
Grahame Grieve (Feb 05 2018 at 20:08):
yes, but so? the question isn't "is it used for something else?" but "should it be used for this?"
John Moehrke (Feb 05 2018 at 20:08):
I am not against a reasoned re-design of the DocumentManifest, DocumentReference, and Composition.... but last time StructDocs looked at this, they concluded there were three clear different scopes.
Grahame Grieve (Feb 05 2018 at 20:08):
did we write it down somewhere
John Moehrke (Feb 05 2018 at 20:09):
I think within the FHIR spec, each has a scope definition... I can't track everything.. you tell me
René Spronk (Feb 06 2018 at 08:43):
To me DocumentManifest feels more like Provenance-resource-on-a-bundle-which-contains-DocumentReferences than Composition. "Who & when uploaded this bunch of DocumentReferences" ? John would probably also say "why", but I'm scratching my head as to what attribute expresses that. However, looking at composition ans its definition it may actually fit the requirements. Probably a CP or workitem for StrucDoc to look at that.
René Spronk (Feb 06 2018 at 08:49):
@John Moehrke there's not a lot of wording in the FHIR spec as to when redirects would be a useful mechanism. On-demand/deferred-creation URLs would certainly be an example. Especially in an environment where one has multiple FHIR endpoints it would be nice to provide some guidance to architects as to when they should use redirects as part of the overall solution.
René Spronk (Feb 06 2018 at 10:20):
On another issue: I'm testing a MHD implementation, with the XDS on FHIR option, ITI-67 query, and the contained Patient resource in the response contains data from sourcePatientId and sourcPatientInfo only. So patientId is not present anywhere in the response. I'm querying for patientId 123, but yet that value is nowhere to be found in the response.
Should patientId be present in the contained Patient resource as one of the patient ids?
René Spronk (Feb 06 2018 at 10:49):
.. where DocumentReference.subject can not reference a Patient resource other than a contained resource.
John Moehrke (Feb 06 2018 at 18:56):
In MHD DocumentReference.subject is 1..1 and must point at a non-contained Patient. That Patient might be in the Bundle, might be available via PDQm, or simply be on a FHIR Server.
John Moehrke (Feb 06 2018 at 18:57):
in MHD the DocumentReference.context.sourcePatientInfo is 1..1 and MUST point at a contained Patient.
John Moehrke (Feb 06 2018 at 18:59):
No one says anything about why redirects should be followed, they just need to be followed... to say anything about on-demand/deferred in FHIR would be improper, as FHIR is agnostic to IHE. To say it in MHD would be to have included those use-cases in the scope of MHD, which is not true. MHD never intended to support those additional use-cases. The fact that current thinking is that when we think about it we will utalize http redirect is just current thinking.. so that is why you see nothing said about it... because it has not yet been prioritized.
René Spronk (Feb 09 2018 at 08:25):
In a "XDS on FHIR": may/should the 'gateway' between FHIR and XDS map OIDs to URIs (and vv) for ease of use by FHIR apps?
John Moehrke (Feb 19 2018 at 13:27):
There are many things like this that are left unsaid in the current MHD profile, so that "Trial Implementation" can inform us how it would be best be specified. It was not clear if this specific re-writing was useful, desired, detrimental, or not important.
Roland Riepel (Mar 14 2018 at 13:36):
While working through the MHD specs a few questions popped up:
- Considering a mapping to XDS, why can a DocumentReference resource have more than one content element?
- Why is the Content.attachment.data element not used to carry the document byte stream?
- In the spec, the DocumentManifest.text element ist mapped to a SubmissionSet field of the same name. This field is not specified in the SubmissionSet meta data. Is this just a typo and it should be mapped to the SubmissionSet's comments field?
René Spronk (Mar 14 2018 at 14:08):
why can a DocumentReference resource have more than one content element?
Looking at the spec I can only guess the following: A document (or copies thereof) may be located at multiple locations, or a document may have multiple expressions (formatCodes, e.g. a document may be available both as CCDA as well as a onother CDA format or version thereof). Both may make sense in the general FHIR resource. Whether or not they make sense in MHD is another question.
John Moehrke (Mar 14 2018 at 15:36):
The DocumentReference.content issue around 0..* vs 1..1 is a recognized CP. The conformance resources published by IHE have already indicated 1..1
John Moehrke (Mar 14 2018 at 15:40):
The DocumentReference.content.attachment.data is carries the document bits within the DocumentReference. This is not the model of IHE Document Sharing family (e.g. XDS, XCA, XDR, XDM, etc). In the IHE Document Sharing family the Metadata is communicated independent of the bits. This enables the receiving actor the ability to further sort, search, filter, manipulate the metadata before the choice to request the document. The common use-case is that the metadata needs further analysis and human intervention to choose the few documents that are to be downloaded. The .data element is thus not consistent with this separation of metadata from content; and it forces a base 64 encoding thus expanding the document size greatly.
John Moehrke (Mar 14 2018 at 15:44):
Yes DocumentManifest.text --> SubmissionSet.comment
John Moehrke (Mar 14 2018 at 15:48):
I do have some corrections to the published conformance resources that I will be pushing soon. The MHD specification (normative) has a set of Change Proposals (CP) that I am working through. Sorry for the delays
Roland Riepel (Mar 15 2018 at 10:18):
The DocumentReference.content.attachment.data is carries the document bits within the DocumentReference. This is not the model of IHE Document Sharing family (e.g. XDS, XCA, XDR, XDM, etc). In the IHE Document Sharing family the Metadata is communicated independent of the bits. This enables the receiving actor the ability to further sort, search, filter, manipulate the metadata before the choice to request the document. The common use-case is that the metadata needs further analysis and human intervention to choose the few documents that are to be downloaded. The .data element is thus not consistent with this separation of metadata from content; and it forces a base 64 encoding thus expanding the document size greatly.
Makes sense ;-)
Thank you for your replies, answered all my questions.
Jens Villadsen (Sep 05 2018 at 07:45):
I have a comment and a question for the MHD profile:
Comment: A client of mine asked me why we would choose to make an MHD 'frontend' (XDS on FHIR) for various systems and clients that hadn't previously integrated to an XDS environment. The arguments for choosing to expose MHD and not XDS may be subjective, but the essence is that my client thought MHD was ONLY suitable for Mobile use - aka. smart phones and what not, because it is called Mobile access to Health Documents.
Now for the question: How should an MHD with the XDS on FHIR option provide support for deprecation of document entries - as one would do in ITI-57? I can't seem to find any place where it is mentioned. My current best guess is to inspect the bundle in ITI-65 for DocumentReferences for statuses that are 'superseded' or 'entered in error'. Now if that goes for all DocumentReferences I can keep it in a single ITI-57 transaction AFAIK and keep it consistent. Another option would be to provide a separate FHIR operation doing that. Any thoughts?
Grahame Grieve (Sep 05 2018 at 07:46):
that's the intent of status
Jens Villadsen (Sep 05 2018 at 07:49):
Yes I can imagine. But as the MHD is with the XDS on FHIR option, I would like to keep my transactions consistent so that I don't need to call both an ITI-41 AND an ITI-57 for a single ITI-65. That would leave me in a fuzzy state if only one of the transactions passes through
Grahame Grieve (Sep 05 2018 at 07:55):
I don't know what that means, and I'm too lazy to look it up...
Jens Villadsen (Sep 05 2018 at 08:29):
ITI-41 = create and update, ITI-57 = delete ... roughly - @John Moehrke , could you perhaps shed some light on this?
Jens Villadsen (Sep 05 2018 at 08:47):
or @Oliver Egger ?
John Moehrke (Sep 05 2018 at 12:24):
@Jens Villadsen The use-case that was brought to IHE was simply the use-cases for XDS. This did not include Metadata Update. If there is a market need for that, then now is a good time to propose a new work item to do the profiling work.
John Moehrke (Sep 05 2018 at 12:25):
Now through Sep 21 is the open call for new work item proposals https://healthcaresecprivacy.blogspot.com/2018/08/open-call-for-ihe-work-item-proposals.html
John Moehrke (Sep 05 2018 at 12:33):
As to the misunderstanding about the word "Mobile". You can point them to the explanation for this term in the first paragraph of the MHD profile. This is where we explain why it is not a term used to limit the deployment . If you have a recommendation for a different word or indication, I am happy to consider it. Right now IHE needs an indication for profiles that are the exact same use-cases but for which one is FHIR based. The big distinction between FHIR and other healthcare standards is the high availability of programmatic support on mobile platforms. Further, MHD is just an API definition, it has not defined any backbone infrastructure, relying on XDS or XCA.
Jens Villadsen (Sep 05 2018 at 13:37):
@John Moehrke I can't say if there is a global market need for it. I can just say that I need it in my project and I will go forward with my suggested approach mentioned earlier on as it is not described anywhere else and it fits my case. As to the wording about "Mobile" - we've already had some discussions about that and you know where I stand - and I'm not surprised to experience that only the headline is read. Instead of "Mobile" a suggestion could be "RESTful access to Health Documents" or "FHIR access to Health Documents".
John Moehrke (Sep 05 2018 at 13:49):
Putting the proposal forward is the best way to learn if others are interested...
Jens Villadsen (Sep 05 2018 at 13:50):
@John Moehrke What about my suggested alternative names?
John Moehrke (Sep 05 2018 at 13:52):
RESTful and FHIR are solutions... The profile name, and use-case need to be in terms of the problem they solve. Thus the use-cases for MHD recognize that XDS/XCA/etc exist, and that the problem space that is unfulfilled is the environment described as 'mobile'. That same statement using "RESTful" or "FHIR" is just a religious war -- "unfulfilled environment is the RESTful world"... simply religious wars are not helpful.
Jens Villadsen (Sep 05 2018 at 13:55):
I thought that MHD only recognizes the XDS/XCA/etc with the XDS on FHIR option? Or am I wrong?
John Moehrke (Sep 05 2018 at 14:03):
the XDS on FHIR option is specifically an indication only for the MHD Responder and Recipient. It is an indication that the implementation 'can' be an API to XDS environments. This option is an indication only for these two actors. The Document Source and Document Consumer do not have these options in their scope. This option was added as an "IHE Integration Statement" declaration of capability. The fact this option exists does not mean the absence of the option is an indication of 'anti-XDS'.
Jens Villadsen (Sep 05 2018 at 14:04):
right
Jens Villadsen (Sep 05 2018 at 14:05):
So RESTful, simple, FHIR, light, slim, easy (insert more names here) are not acceptable - but mobile (even though its called smart phones - should there be a binding to the so-called constrained devices with multiple cores) is ok? It could have been called 'smart' but that could cause confusion with the SMART project.
Jens Villadsen (Sep 05 2018 at 14:05):
All I'm saying is that the term "Mobile" causes confusion for people only reading headlines
Jens Villadsen (Sep 05 2018 at 14:06):
and there are almost trillions of such people
Jens Villadsen (Sep 05 2018 at 14:08):
Mobile is not the problem that is trying to be solved - it is the lack of WS support and what comes with it
John Moehrke (Sep 05 2018 at 14:12):
I never said that simple, light, slim, easy were a problem...
John Moehrke (Sep 05 2018 at 14:14):
I suspect though that those terms would be equally confused as not powerful, not complete, not comprehensive
Jens Villadsen (Sep 05 2018 at 14:19):
How about 'Fluent'?
Simone Heckmann (Sep 06 2018 at 07:13):
How about "awesome"? Thats unambiguous.
aXDS = awesome Document Exchange, aPDQ = awesome Patient Demographic Query :sunglasses:
Jens Villadsen (Sep 06 2018 at 07:17):
Ha! - Thats why I chose 'Fluent' .... it's really not that flavoured
Stefan Lang (Sep 06 2018 at 09:44):
@Simone Heckmann because "awesome" sounds so similar to "awful"? :joy:
John Moehrke (Sep 06 2018 at 11:47):
Im likeing the direction of fluent... more like that. The point is to emphasize the positive, not to denegrate the predicisor.
Josh Mandel (Sep 06 2018 at 17:42):
"2020". It's a solution from the future! Will never go out of date! (??). And has delightful connotations of keen "20/20" vision.
Jens Villadsen (Sep 06 2018 at 17:48):
"2020". It's a solution from the future! Will never go out of date! (??). And has delightful connotations of keen "20/20" vision.
- famous last words
Simone Heckmann (Sep 06 2018 at 17:53):
PDQ++ :D
Jens Villadsen (Sep 06 2018 at 18:01):
Mock me all you want - the current naming strategy has failed as the intended message is not understood due to the fact that people only read the headlines. The sooner that is fixed, the better
Jens Villadsen (Sep 06 2018 at 18:02):
:robot_face:
Josh Mandel (Sep 06 2018 at 18:07):
To be clear, my example was not meant to be mocking discussion here! Naming is hard, and it has to be a little fun too :-)
John Moehrke (Sep 06 2018 at 18:07):
This is not a personal attack on anyone. It is an assault on the IHE "Mobile" naming convention. I, as the author of that "Mobile" choice, am happy to see this discussion as I really would like something better. I too would love to see a better choice
Jens Villadsen (Sep 06 2018 at 18:08):
Agreed - no harm done
Stefan Lang (Sep 06 2018 at 18:08):
Just leave the "m"/"M" and redesignate it to "modern"?
John Moehrke (Sep 06 2018 at 18:08):
I would have stolen @Josh Mandel term "SMART" had I not been completely fearful of him
Jens Villadsen (Sep 06 2018 at 18:09):
I just almost saw a national architecture go down the drain because the readers didn't understand 'Mobile'
John Moehrke (Sep 06 2018 at 18:10):
did my article yesterday help? https://healthcaresecprivacy.blogspot.com/2018/09/mhd-as-api-to-xca.html
Jens Villadsen (Sep 06 2018 at 18:17):
Just leave the "m"/"M" and redesignate it to "modern"?
no, IMHO. If the profile is to survive e.g. 4 years, it won't feel modern at that time
Stefan Lang (Sep 06 2018 at 18:18):
mature? ;-)
Jens Villadsen (Sep 06 2018 at 18:19):
mature? ;-)
That would probably be something you would coin to the XDS profile, IMHO
Jens Villadsen (Sep 06 2018 at 18:20):
And 'mature' for a profile that is 'trial' seems a bit weird
Stefan Lang (Sep 06 2018 at 18:20):
right.
Just brainstorming :-)
Jens Villadsen (Sep 06 2018 at 18:25):
of course ... I've had this discussion with @John Moehrke for a while now ... and I kinda get where he would like this to end without knowing the answer
Jens Villadsen (Sep 06 2018 at 18:26):
you need a name that does not 'insult' the existing paradigm but at the same time emphasizes that this is a new way of doing it
Jens Villadsen (Sep 06 2018 at 18:27):
without compromising the quality
John Moehrke (Sep 06 2018 at 18:31):
yup... and also not a technology word, but rather a use-case benefit word.
John Moehrke (Sep 06 2018 at 18:32):
Would be fantastic if it was a "M" word... changing acronyms is harder than changing the word the acronym refers to
Stefan Lang (Sep 06 2018 at 18:32):
Would be fantastic if it was a "M" word... changing acronyms is harder than changing the word the acronym refers to
That's what I was thinking of ... but it makes it even harder
John Moehrke (Sep 06 2018 at 18:33):
I already tried "Moehrke"... and the pronunciation "Murky" isn't good either
Jens Villadsen (Sep 06 2018 at 18:35):
http://wordfinder.yourdictionary.com/words-that-start/m
Stefan Lang (Sep 06 2018 at 18:36):
I was to come up with RESTful[HD|XDS|something else], but that's a technical term
Stefan Lang (Sep 06 2018 at 18:37):
madcap?
Jens Villadsen (Sep 06 2018 at 18:37):
We already went there and @John Moehrke thinks that it is too fixed to the solution ...
Stefan Lang (Sep 06 2018 at 18:39):
"minimal" (in the sense of: "one standard does it all")?
Jens Villadsen (Sep 06 2018 at 18:40):
its good .... but its a bit flavoured
Jens Villadsen (Sep 06 2018 at 18:40):
'Minimal Access to Health Documents' ...
Stefan Lang (Sep 06 2018 at 18:40):
:D ok
Stefan Lang (Sep 06 2018 at 18:41):
moving away from "M": lightweight (as in: LDAP followed DAP)?
John Moehrke (Sep 06 2018 at 18:43):
also the "M" must be just as usable in PDQm, PIXm, QEDm, etc... that is a profile that otherwise exists, and now has a FHIR format.... Not all IHE profiles that use FHIR, just those where an equivilant profile already exists and there is a need for a FHIR variant.
Stefan Lang (Sep 06 2018 at 18:43):
Just have to ensure IHE never comes up with something like "Lightweight Structured Documents" :joy:
Jens Villadsen (Sep 06 2018 at 18:43):
Haha
Jens Villadsen (Sep 06 2018 at 18:46):
also the "M" must be just as usable in PDQm, PIXm, QEDm, etc... that is a profile that otherwise exists, and now has a FHIR format.... Not all IHE profiles that use FHIR, just those where an equivilant profile already exists and there is a need for a FHIR variant.
If that is a 'hard' requirement you might as well suffix all the profiles with ' on FHIR'
Stefan Lang (Sep 06 2018 at 18:47):
modest? Possibly too ambigous
Stefan Lang (Sep 06 2018 at 18:49):
micro?
John Moehrke (Sep 06 2018 at 18:50):
modest... never considered FHIR to be all that modest...
Elliot Silver (Sep 06 2018 at 18:53):
Micro seems to be just as unlikely to be adopted for a national system as mobile.
Stefan Lang (Sep 06 2018 at 18:54):
Well, then "massive" :D
Stefan Lang (Sep 06 2018 at 18:56):
mettled?
Simone Heckmann (Sep 06 2018 at 19:01):
„Smart“ goes against the rule not to denigrate the predecessors. Because every profile that isn’t smart is consequently a „dumb“ profile :D
Simone Heckmann (Sep 06 2018 at 19:03):
Putting an i in front of stuff was a thing for a while but then again having both iXDS and XDSi will be super confusing :)
Simone Heckmann (Sep 06 2018 at 19:04):
Especially since technically you could also have iXDSi
Simone Heckmann (Sep 06 2018 at 19:05):
Why do you even still name your profiles? Just assign an OID! There: problem solved. You’re welcome.
Elliot Silver (Sep 06 2018 at 19:05):
Actually, we went with WIA instead of an MHD version of XDS-I. So, that would give us, iWia, which is the sound I make on a rollercoster.
Jens Villadsen (Sep 06 2018 at 19:05):
So there's PDQ .... and PDQv3 ....then why not PDQvF?
Simone Heckmann (Sep 06 2018 at 19:10):
Since FHIR‘s selling point is easy implementation, why not „XDS for dummies“?
Stefan Lang (Sep 06 2018 at 19:11):
I consider that denigration of the successor :D
Jens Villadsen (Sep 06 2018 at 19:11):
Since FHIR‘s selling point is easy implementation, why not „XDS for dummies“?
tell that to national authorities ....
Stefan Lang (Sep 06 2018 at 19:12):
so, "easy" must be left out because the old one would then be "hard" ...
Jens Villadsen (Sep 06 2018 at 19:12):
yes
Jens Villadsen (Sep 06 2018 at 19:12):
same argument goes for lightweight
Stefan Lang (Sep 06 2018 at 19:12):
But why not lightweight?
Jens Villadsen (Sep 06 2018 at 19:12):
:D
Stefan Lang (Sep 06 2018 at 19:12):
Really?
Simone Heckmann (Sep 06 2018 at 19:13):
XDS - the next generation
Jens Villadsen (Sep 06 2018 at 19:13):
Really?
really .... that would say that the predecessor is heavyweight
Simone Heckmann (Sep 06 2018 at 19:13):
... to boldly go where no document has gone before.
Stefan Lang (Sep 06 2018 at 19:14):
Sure. And in 10 years, when we all do WATHR instead of FHIR, "XDS Voyager"
Simone Heckmann (Sep 06 2018 at 19:15):
Historically, the generation before the next generation went boldly too, so no denigration here.
Stefan Lang (Sep 06 2018 at 19:15):
Actually, even today Kirk is more bold than Picard :joy:
Jens Villadsen (Sep 06 2018 at 19:15):
trekkies ....
Stefan Lang (Sep 06 2018 at 19:16):
... says the man who begged for a QHUL sticker :D
Simone Heckmann (Sep 06 2018 at 19:16):
:vulcan_salute:
Jens Villadsen (Sep 06 2018 at 19:16):
YES!
Jens Villadsen (Sep 06 2018 at 19:16):
so QHD
Jens Villadsen (Sep 06 2018 at 19:16):
QHUL access to Health Documents
Stefan Lang (Sep 06 2018 at 19:16):
agreed.
Make it so!
Jens Villadsen (Sep 06 2018 at 19:17):
aye aye
Simone Heckmann (Sep 06 2018 at 19:17):
Q‘ap‘la or something
Stefan Lang (Sep 06 2018 at 19:18):
Just browsing my boQwl' ...
Jens Villadsen (Sep 06 2018 at 19:19):
we might continue this on one of the social channels ... i think ;)
Patrick Werner (Sep 06 2018 at 19:19):
bMHD. b for blockchain, that will impress national authoroties :grinning:
Jens Villadsen (Sep 06 2018 at 19:19):
HAHAHAHA!
Jens Villadsen (Sep 06 2018 at 19:20):
and then the next gen: bMHD.b
Jens Villadsen (Sep 06 2018 at 19:20):
right .... this is going nowhere .... can't we just call it HD on FHIR?
Stefan Lang (Sep 06 2018 at 19:24):
mem - catalog
meQ - to burn
meq - to think logically
Stefan Lang (Sep 06 2018 at 19:24):
:joy:
Simone Heckmann (Sep 06 2018 at 19:26):
Honestly, if the plan is to extend MHD in the future to cover the full scope of XDS I‘d much rather have the clearly stated by calling it XDSsomething. That’ll help people in seeing it as a peer and not something different/minor.
Stefan Lang (Sep 06 2018 at 19:26):
100% agreed.
Simone Heckmann (Sep 06 2018 at 19:27):
I want people to accept it as an alternative not just an appendix.
Stefan Lang (Sep 06 2018 at 19:27):
Just "XDS on FHIR", "PDQ on FHIR", ...
Jens Villadsen (Sep 06 2018 at 19:27):
makes sense ... and leaves little room for misinterpretation
Jens Villadsen (Sep 06 2018 at 19:29):
and now to something completely different: why does DocumentReference not contain a field for repoId if it is intended to mimic DocumentEntry?
Simone Heckmann (Sep 06 2018 at 19:34):
RepoID being the ID of the repository in which to find the document? I guess that’s because in REST the url referencing the Binary with the content is nuff said in terms of where to find it...?
Jens Villadsen (Sep 06 2018 at 19:41):
I chose to encode it into the url ... which basically mimics what you said
Jens Villadsen (Sep 06 2018 at 19:42):
so the case is and MHD with XDS on FHIR option ...
Jens Villadsen (Sep 06 2018 at 19:42):
and MHD facade to an XDS infrastructure ...
Jens Villadsen (Sep 06 2018 at 19:44):
the only way to carry both the uniqueId and repoId is to merge them together as the masterIdentifier ... it just doesn't feel that clean
Jens Villadsen (Sep 06 2018 at 19:45):
wait a minute ...
Simone Heckmann (Sep 06 2018 at 19:48):
Isn’t the repoID just the baseurl of the server that hosts the document? Except it’s an url instead of an oid which happens all the time when „translating“ from XDS to MHD?
Simone Heckmann (Sep 06 2018 at 19:49):
Though I don’t really know. Just guessing...
Jens Villadsen (Sep 06 2018 at 19:54):
so since its a facade ... the url needs to point back to the facade ....
Jens Villadsen (Sep 06 2018 at 19:55):
not to the actual repo
Jens Villadsen (Sep 06 2018 at 19:55):
which means that the information of the repo needs to be carried all the way back to the client
Jens Villadsen (Sep 06 2018 at 19:56):
so that the client can ask for the resource in question ... without knowing anything specific about what repo the content is hosted at
Jens Villadsen (Sep 06 2018 at 19:57):
which means it is natural to encode it in the url
Jens Villadsen (Sep 06 2018 at 19:57):
at least if you prefer a stateless design
Jens Villadsen (Sep 06 2018 at 19:57):
which most sane people tend to favour
John Moehrke (Sep 06 2018 at 20:21):
we did talk at the time that XDS.a became XDS.b so this is clearly XDS.c.. but that doesn't cover the fact that MHD is also an API to XCA, and also does simple push (XDR).
John Moehrke (Sep 06 2018 at 20:22):
and .c doesn't work for PDQm, PIXm, QEDm, etc...
John Moehrke (Sep 06 2018 at 20:22):
then there are the profiles that put the 'm' in front.. mCDS (aka mHPD)...
Jens Villadsen (Sep 06 2018 at 20:23):
does it have anything to do with android or iOS? no .... so don't use the 'm'
John Moehrke (Sep 06 2018 at 20:35):
just so all can understand.. the Mobile is an indication of a specific kind of environment for which SOAP, complex / large XML, or custom protocols like HL7 v2/v3, or DICOM DIMSE; are problematic, where the platform stack prefers http REST and JSON... That is the scope of these 'm' profiles. What is problematic is when people misunderstand that those platform technologies do scale to very large. The large scale overlaps with REST vs SOAP, the small mobile platform does NOT.
Nick Hatt (Sep 06 2018 at 21:10):
Crazy question - Is there any specific reason that IHE profiles need to be acronyms? I feel like they generally keep people away from IHE even though there is quality and important specification there.
Elliot Silver (Sep 06 2018 at 21:18):
@Nick Hatt , agree, the acronyms force them away from IHE towards HL7, FHIR, and SMART. Oops, nope, those are acronyms too. Towards DICOM, Doh! Towards SNOMED and LOINC. Doh! Doh! Maybe they decide to stay away from healthcare specific and stick with general purpose standards like HTTP, TCP/IP, SOAP, SAML, TLS, OASIS. Doh! Doh! Doh! Doh! Doh! Doh! Ah, screw it, I'm going with something simple and self explanatory like OAuth.
Elliot Silver (Sep 06 2018 at 21:28):
But seriously, this discussion isn't really about using "m"; it's about using "mobile". And the reason we write MHD, PDQ and XDS is that those are a lot easier to type and say than "Mobile Access for Healthcare Documents", "Patient Demographics Query" and "Cross-enterprise Document Sharing". We need a name that describes what it is, we have too many profiles to give each one a snazzy brandname (Is it any clearer to say "Have you heard about DocShare(tm)? It uses the IHE WhoDat(r) profile to find patients"), brand names will confuse people between standards and products, and people are used to TLAs. I don't think the acronym is the problem.
Nick Hatt (Sep 06 2018 at 21:34):
@Elliot Silver Thanks for walking back the sarcasm. This conversation started with how IHE profiles are designed around use cases. It's a valuable approach. By the nature of focusing on use cases it should include non-technical people. Even for developers seeing references to documents like ITI TF Supplement XCA TI immediately makes the specs seem more complex than they actually are.
Nick Hatt (Sep 06 2018 at 21:36):
I'm not saying burn it all down, just that spelling things out can be helpful to the mission. I'll throw "XDS with FHIR characteristics" in as a comedy option.
John Moehrke (Sep 07 2018 at 00:13):
I repeat... I as the owner of this Mobile mess... Welcome all of this, jokes, sharasm, and the realistic suggestions. I have no problem explaining, as long as it goes to understanding. Bring it on...
John Moehrke (Sep 07 2018 at 20:04):
FYI: IHE has released some Webinars that I recorded for them: Document Sharing, MHD, and mXDE -- https://www.ihe.net/resources/webinars/#iti
Jens Villadsen (Sep 11 2018 at 13:43):
are there any lambda functions available anywhere for doing the tedious conversion between DocEntry's and DocReferences?
Jens Villadsen (Sep 11 2018 at 14:06):
http://build.fhir.org/documentreference-mappings.html#xds specifies a mapping between DocRef and DocEnt. More specifically DocumentEntry.type is listed as mapping to DocumentReference.type. However DocumentEntry.type's are stable and on-demand - That does not seem to be a great fit for http://build.fhir.org/valueset-c80-doc-typecodes.html - is that really intended?
John Moehrke (Sep 11 2018 at 14:09):
That is a bug in the FHIR spec. Can you submit a change request to gForge?
John Moehrke (Sep 11 2018 at 14:14):
There is no element in FHIR DocumentReference as equivalent to DocumentEntry.type. Nothing but stable has been brought to IHE as a work item, although there is nothing that prevents a DocumentReference from pointing at $document endpoint. Meaning, the FHIR DocumentReference has not found a need to express stable vs on-demand as unique things.
Jens Villadsen (Sep 11 2018 at 14:15):
There is no element in FHIR DocumentReference as equivalent to DocumentEntry.type. Nothing but stable has been brought to IHE as a work item, although there is nothing that prevents a DocumentReference from pointing at $document endpoint. Meaning, the FHIR DocumentReference has not found a need to express stable vs on-demand as unique things.
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17863
John Moehrke (Sep 11 2018 at 14:17):
thanks
Grahame Grieve (Sep 11 2018 at 21:13):
are there any lambda functions available anywhere for doing the tedious conversion between DocEntry's and DocReferences?
Sounds like a good connectathon track: define an interface for this, and test it
Jens Villadsen (Sep 11 2018 at 21:15):
are there any lambda functions available anywhere for doing the tedious conversion between DocEntry's and DocReferences?
Sounds like a good connectathon track: define an interface for this, and test it
Let me rephrase - are there any lambda functions available anywhere for doing the tedious conversion mappings described for most resources?
Grahame Grieve (Sep 11 2018 at 21:18):
not that i know of. are you talking about inter-version mappings? or something else? only R2/R3 mappings are well enough defined to turn into lambda functions, and I'm close to having them as web apis, but not as lamdbas
Jens Villadsen (Sep 11 2018 at 21:21):
My case here is between models - eg. CDA and FHIR, XDS and FHIR, v2 and FHIR .... and so on
Jens Villadsen (Sep 11 2018 at 21:21):
you know ... bridging standards so that we can all get on with our lives .... ;)
Grahame Grieve (Sep 11 2018 at 21:24):
none of those have a sufficiently well defined mapping for someone to write a master transform and package it in a lambda
Jens Villadsen (Sep 11 2018 at 21:25):
http://build.fhir.org/documentreference-mappings.html#xds
Jens Villadsen (Sep 11 2018 at 21:25):
seems sufficient to me
Jens Villadsen (Sep 11 2018 at 21:29):
same with http://build.fhir.org/documentmanifest-mappings.html#xds
Jens Villadsen (Sep 11 2018 at 21:30):
and http://build.fhir.org/composition-mappings.html#cda
Grahame Grieve (Sep 11 2018 at 21:44):
those are not enough. the transforms between the data types are incomplete.
Jens Villadsen (Sep 11 2018 at 21:46):
incomplete works for me .... I was looking for something that did the grunt work - I'm fine by doing the last details my self
Jens Villadsen (Sep 11 2018 at 21:46):
what data types are you thinking about?
John Moehrke (Sep 12 2018 at 15:18):
Grahame if you have functions for HL7 v2 datatypes to FHIR datatypes; then these can be used in XDS. AS the Native XDS elements are just using HL7 v2 datatypes like II, CX, etc...
Grahame Grieve (Sep 12 2018 at 22:32):
we don't have functions for that
Grahame Grieve (Sep 12 2018 at 22:32):
some ... indeterminate... mappings
John Moehrke (Sep 13 2018 at 13:00):
so most of the DocumentReference <-> DocumentEntry mappings are simple deterministic (some are hard - Author). What do I need to do to start building more detailed mappings than we have in the FHIR DocumentReference mapping table today?
Grahame Grieve (Sep 14 2018 at 23:31):
there's 2 ways to build more detailed mappings. Once is to use a ConceptMap, and do the mappings at the primitive level
Grahame Grieve (Sep 14 2018 at 23:31):
e.g. for each primitive leaf in the source, say what the primitive element is in the destination
Grahame Grieve (Sep 14 2018 at 23:32):
that works well if there's no structural change, or data transformations, or conditionality in the mapping
Grahame Grieve (Sep 14 2018 at 23:32):
if there's any of those - and I expect there will be - then you have to step up to a StructureMap to express the mapping
Jens Villadsen (Dec 16 2018 at 18:56):
@John Moehrke regarding the mapping table on http://build.fhir.org/documentreference-mappings.html, more specifically DocumentEntry.availabilityStatus? Where does DocumentEntry.availabilityStatus.Submitted go to and where does DocumentEntry.availabilityStatus.Approved? Are both equal to DocumentReferenceStatus.Current?
John Moehrke (Dec 17 2018 at 13:48):
@Jens Villadsen There are only two defined StatusType values within IHE: Approved and Deprecated (See ITI TF Volume 2a: 3.18.4.1.2.3.6). There are other ebrim values, but they have no defined use in the IHE profiles, thus their meaning is undefined even in DocumentEntry. These are mapped in MHD Table 3.67.4.1.2.1-1.
Jens Villadsen (Dec 17 2018 at 14:52):
@John Moehrke It would be useful to have that mapping specified in http://build.fhir.org/documentreference-mappings.html#xds
John Moehrke (Jun 05 2021 at 02:36):
MHD 4.0.1 - Trial Implementation - is formally released https://profiles.ihe.net/ITI/MHD/index.html
Brendan Keeler (Jun 09 2021 at 11:47):
Very cool.
It would be sweet to include mimeType as a parameter in MHD DocumentReference queries, since that's notably missing from XDS / XCA queries
John Moehrke (Nov 10 2021 at 11:05):
Mobile Access to Health Documents (MHD) - Rev. 4.0.2. This revision updated the publication to use the new Implementation Guide template. No new functionality was added.
https://profiles.ihe.net/ITI/MHD/index.html
René Spronk (Mar 05 2022 at 17:36):
Is it assumed that content.attachment.url is allowed to be a reference to a contained resource with the DocumentReference resource (e.g. a contained Binary) ? I see an example of this on one of the public testservers.
The entire point of not allowing attachment.data seems to be that the blob and its metadata are separated, thus a url pointing to a contained resource should not be allowed.
John Moehrke (Mar 06 2022 at 18:49):
I never thought of that trick. The intent was to recognize that the Document Sharing family all have the document and metadata as independent objects. If you bind them into one (DocumentReference with data) then it can NOT be carried outside of FHIR. So the constraint is to make it the most compatible (we call this Karen's cross).
John Moehrke (Mar 06 2022 at 18:50):
The binary url also has the advantage of being able to use http negotiate when retrieving it. The .data method only supports that which was published in the form it was published, and it is made bigger by base64 encoding
René Spronk (Mar 07 2022 at 07:33):
Perhaps MHD should be updated to disallow the use of a contained Binary..
John Moehrke (Mar 07 2022 at 13:14):
@René Spronk can you put in a github issue for that? Links to methods of commenting are at the bottom of the specification.
René Spronk (Mar 16 2022 at 11:21):
DocumentReference.securitylabel states the following:
A set of Security-Tag codes specifying the level of privacy/security of the Document. Note that DocumentReference.meta.security contains the security labels of the "reference" to the document, while DocumentReference.securityLabel contains a snapshot of the security labels on the document the reference refers to.
When would these NOT be the same ? Why would metadata of the blob have a different sensitivity than the blob itself ?
John Moehrke (Mar 16 2022 at 11:58):
When knowing that the document exists is not sensitivity exposing, but the content of the document is sensitivity exposing.. See J#32581 which is awaiting approval in OO, waiting on inperson request by Lloyd
The distinction recognizes that the document may contain sensitive information, while the DocumentReference is metadata about the document and thus may not be as sensitive as the document. For example: a psychotherpy episode may contain highly sensitive information, while the metadata may simply indicate that some episode happened.
John Moehrke (Mar 16 2022 at 12:01):
yes, it is unusual. Would be improper when using .data. The main problem is that an external URL, does not have a .meta.security; so this security/privacy tag needs to live somewhere. Yes the .url might point at a FHIR resource, but that is not a mandate.
René Spronk (Mar 16 2022 at 12:03):
Thanks. I agree with the suggestion to add clarification as to when they could be different. I have no problems with it existing in two places for two different purposes, as long as its clear that there are two different reasons for having these two options.
John Moehrke (Mar 16 2022 at 12:04):
feel free to add your comment to the jira ticket
René Spronk (Mar 16 2022 at 12:05):
As for referenceIdList (in XDS.b) mapping to DocumentReference-uncontained option, those would be context.related (placer order number, filler order number aka accession number) ?
René Spronk (Mar 16 2022 at 12:20):
In the latest R5 build, there is no MasterIdentifier in DocumentReference. So which of the Identifiers should act as a master in its stead ?
John Moehrke (Mar 16 2022 at 12:50):
if you look at the XDS metadata mapping, you will see that DocumentEntry.uniqueId is now in DocumentReference.content.identifier -- BUT, J#32584 is calling for that element to be eliminated with the justification that the document uniqueId is just another business identifier for the DocumentReference instance.. presuming that they are the same thing... I am trying to fight that, but need support.
René Spronk (Mar 16 2022 at 13:31):
ImageReference.identifier is the same as the study instance UID in DICOM. So why could DocumentReference.identifier not be a CDA identifier ? And yes, a new document or DICOM study [if assigned a new identifier, which depends on business rules around updating which differ between specifications] would require a new ImageReference or DocumentReference.
John Moehrke (Mar 16 2022 at 13:33):
good perspective. need more community feedback like this.
René Spronk (Mar 16 2022 at 13:40):
As for referenceIdList (in XDS.b) mapping to DocumentReference-uncontained option, those would be context.related (placer order number, filler order number aka accession number) ? The 'uncontained' option seems to indicate that nothing-at-all could be contained, whereas uncontainment would probably make most sense for patients, authors, but not for context.related, where 'SHOULD be uncontained' is probably the best one can go for.
(I'm trying to map my XDS.b and XDS-I examples from my courses to MHD, hence my flurry of questions..)
John Moehrke (Mar 16 2022 at 13:45):
Uncontained is not compatible with XDS, hence why the XDS on FHIR option calls for the containment. The uncontained is more appropriate for an MHDS environment that would have a Provider directory that would persist organizations, practitioner, etc... when these things are persisted in a community directory, they do not need to be copied into each DocumentReference.
René Spronk (Mar 16 2022 at 13:55):
MHD nor MHDS are set in stone - looking at the context of the countries where MHD(S) is likely to be used (in Europe, e.g. Germany, Switzerland, Netherlands, Scandinavia) I can make an educated guess as to what they'd be able to 'uncontain' (MHDS-like) versus what things are likely to be contained. A DocumentReference, within hospital [affinity domain] A, may very well have a reference to a uncontained [and fully populated] ServiceRequest, whereas upon communication to another hospital [or affinity domain] that same ServiceRequest will have to be included as a contained [minimalistically populated] resource.
Uncontained (in my book) doesn't necessarily clash with XDS.b, given that a transformation (by some software agent) is possible.
John Moehrke (Mar 16 2022 at 14:04):
anything is possible, interface engines have lived a long life and will continue to live a long life..
the role of IHE is to set constraints such that there is best possibility for interop out-of-the-box.
René Spronk (Mar 17 2022 at 08:18):
Looking at DocumentReference, it would make sense to harmonize it (to some degree) with (the 'header of') DiagnosticReport.
XDS.b has referenceIdList, which is a powerful way to enable searching on all sorts of Ids, quite often encounterId or accessionNumber (order number). The problem with 'related' in DocumentReference is that it's not searchable, and a bit of a dustbin for leftover non-explictely-referenced stuff.
If we look at DocumentReference purely from a FHIR perspective such harmonization would be useful - I understand the aim to remain compatible with XDS.b as far as possible, but that doesn't mean we can't enhance the functionality of DocumentReference. Right?
John Moehrke (Mar 17 2022 at 11:31):
correct.
Last updated: Apr 12 2022 at 19:14 UTC
