FHIR Chat · Copying content from duplicate stream

Stream: ihe

Topic: Copying content from duplicate stream

Josh Mandel (Apr 01 2019 at 20:40):

IHE FHIR profiles > Use of contained resources in mHD Feb 06, 2018

Theo Stolker: Hi all,

I did implement an MHD client and found out that it promotes the use of contained resources, see https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf, section 4.5.1 Metadata Object Types mapped to FHIR
...
Some Document Sharing Metadata attributes must be treated as ‘contained’ FHIR Resources.
These are indicated using “Note 1”, and use of the word ‘contained’ in the Notes column of
Table 4.5.1.1-1. The details of the FHIR ‘contained’ mechanism is found at
http://hl7.org/fhir/STU3/references.html#contained.

Reading https://www.hl7.org/fhir/domainresource-definitions.html#DomainResource.contained I find the description above controversial at least.

Also, given that the FHIR specification provides clear alternatives through the search include mechanism in a reply Bundle, I am wondering if this was discussed before and couldnt be done in a more acceptable way.

Is there anyone involved in the creation or review of the MHD profile that can comment on this?

Thank you,

Theo.

René Spronk: @Theo Stolker From a discussion in the IHE stream I now understand the reason to be that they wish to preserve the exact data as known at a specific point in time. Hence the use of contained resources.
The Reference data type should support references to historic versions (the http://build.fhir.org/references.html page doesn't specifically address this), so IMHO MHD should also allow for references to historic versions of a resource.

IHE FHIR profiles > IHE MHD profiles Dec 10, 2018

Ardon Toonstra: Relocated a couple of my questions from this Zulip chat to here. @John Moehrke

1. I assume that the Provide Comprehensive DocumentReference profile (a.k.a. XDS on FHIR) states the minimum requirements for indexing something in typical XDS network. Is this assumption correct?
2. A patient cannot be an author of the document. Is this intended?
To represent a patient providing a document (image), should we provide our own codes, and the patient information for the following mandatory elements?
- .context.facilityType
- .context.practiceSetting
- .context.sourcePatientInfo (this would be duplicate information from .subject: one bundled the other contained)

3. Why is the .content.attachment.language mandatory? A suggestion what to do if the content is an image?
4. The profile Provide Document Bundle contains a Bundle.meta.profile (http://ihe.net/fhir/tag/iti-65) with 1..1 which does not match the profile URL. This makes validating against the profile hard. Shoudn't this be a 1..2 or 2..2. Or the url's that match.
Hope someone could shed some light on these questions!

Ardon Toonstra: I forgot question number 5:
What happend to the DocumentManifest in the profile "Provide Document Bundle? It is not included in the profile, nor is a slice for Patient which should be included because of the 1..1 of DocumentReference.subject which should be referenced and bundled

John Moehrke: 1. Yes. It would be best to approach the conformance resource in the context of the Implementation Guide text (IHE MHD Profile), so that the context you seek is clear. Yes this specific structureDefinition is intended to be used in the Provide transaction when the publication is into an XDS environment (XDS on FHIR). In publishing one must provide the required metadata elements of the XDS profile.

John Moehrke: 5. that looks like a bug. thanks. I will fix it. I am updating MHD now to FHIR R4 so can fix this in the coming months.

John Moehrke: 2. there should be no restriction that a patient can't be an author in XDS or MHD. I will record this as a bug that needs to be fixed. It does appear in the MHD normative text. Sorry. This is the kind of things we find during Trial Implementation.

John Moehrke: 2... the facilityType, practiceSetting, and sourcePatientInfo are not manditory. But it would likely be good to fill them out. For example the facilityType vocabulary has only an example valueSet. Thus any codes can logically be used. If publishing into an XDS community it is possible that one would need to use only codes recognized by that Affinity Domain.

John Moehrke: 3. the language is not required of the normative MHD profile, nor of the core FHIR specificaiton. So it is simply a mistake in the informative conformance resources. I will fix that as part of our update to FHIR R4

John Moehrke: 4. I suspect you are describing something I am not fully understanding. It is true that IHE started defining conocal URI long time ago for this transaction. In the R4 version of MHD this will likely be closer to a resolveable URI, but it is not clear yet what IHE will be able to support.
However, I suspect you comment is not on the format of the URI, but on something else that I am not understanding. Can you explain a bit more?

Ardon Toonstra: Thank you for the answers and bug reports! More than normal to find issues using a Trial implementation. However, we are and will remain for quite some time on STU3. Is it possible to created fixes for the STU3 version of the IHE MHD profiles? I am unhappy to ‘break open’ the profiles and govern our own version while we state to use IHE MHD.

Ardon Toonstra: Regarding 4. the mentioned profile states this:

While the profile canonical url is http://ihe.net/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Comprehensive

Ardon Toonstra: To see what the problem is, here an example which I try to validate against that profile: validation output

John Moehrke: okay, yes that I intend to fix. This is simply the issues created as a specification evolves.

John Moehrke: some of the fixes can be done to the STU3 versions. These will be maintained for a period of time. We have these in github, and would welcome a pull request. https://github.com/IHE/fhir

Ardon Toonstra: Good news! Firstly, I will work out my use case a bit further, afterwards you may expect pull requests from me.

IHE FHIR profiles > DocumentReference and XDS Mar 06

Espen Stranger Seland: Posted in fhir/documents, but this stream is probably the right one. Please have a look:
https://chat.fhir.org/#narrow/stream/179270-fhir.2Fdocuments/topic/DocumentReference.20and.20XDS/near/160085486

IHE FHIR profiles > 5 IHE Profiles updated to R4 Mar 11

John Moehrke: MHD, mCSD, PDQm, and QEDm are now available in R4 compliance. Add Appendix Z, and mXDE. https://healthcaresecprivacy.blogspot.com/2019/03/ihe-produces-profiles-using-fhir-r4-for.html

IHE FHIR profiles > IHE MHD profiles Mar 19

René Spronk: I'm looking at the following use case: create a FHIR doc using $document, provide&register via classic XDS.b. Challenge is the mapping of uniqueId. MHD states it provides guidance in appendix ITI 2x E.3, however that section doesn't exist in the current 2x appendix.
It seems I'd have to somehow either stuff the generated urn:uuid into uniqueId (which must be an OID AFAIK), or replace the UUID generated by $document by an OID..

John Moehrke: That use-case has not been brought to IHE to document, hence why you don't find any IHE documentation on it.

John Moehrke: the appendix you seek is a standalone Supplement -- Appendix Z (yes it has E in it too, but titles are so hard to keep short).

John Moehrke: ITI is accepting new work item proposals every month, for potential selection every quarter. https://wiki.ihe.net/index.php/ITI_Continuous_Development

René Spronk: OK, so there won't be anything to go on (for this scenario).
I'll have to go back to XDS vol 3 to see what the exact requirements are for doc uniqueId... "SHOULD be OID, but may be UUID (RFC4122) or URI." So a simple urn:uuid: should suffice, no new functionality would be required.

John Moehrke: The $document concept is closer to an XDS onDemand... right?

John Moehrke: But the big problem is that a $document is an operation using POST.. and a DocumentReference.content.attachment.url is a GET

John Moehrke: so I don't see a logical way to marry DocumentReference with $document operation to deliver the content

René Spronk: We're talking cross-purpose here: the simplified version of my use-case is that a) somehow I have generated a FHIR Document, b) I need to register it with classic XDS.b. That specific use case is easy, my question was solely related to the use of a UUID as a XDS.b uniqueId.

René Spronk: About the on-demand scenario (which is not my current use case): an operation which results in 1 single resource can be invoked using a GET. See http://build.fhir.org/operations.html#executing - so I don't see any issues with that scenario either.

IHE FHIR profiles > Nature of a Document Mar 20

René Spronk: "sharing clinical records in the form of documents" - that's the purpose of XDS. Is there a formal definition somewhere as to what a "document" is?

FHIR has excellent features for dynamic documents like '$current medications' or '$current conditions' (as List entries in Composition $document). To some this would be 'sections' in a document with a wider scope, to others these would be standalone documents.
What are the characteristics of a section (e.g. from a CCDA, or the IPS) which could NOT be seen as a standalone medical document?

The Dutch LSP (national infrastructure) uses [the equivalent of] XDS-Documents defined as FHIR Bundles (not document bundles, but generic bundles, each expressing the rough equivalent of a section in CCDA/IPS). Would that be an XDS document? if not, why not?

IHE FHIR profiles > IHE MHD profiles Mar 21

John Moehrke: There is not a requirement that uniqueId be a UUID.. where do you find that? I suspect you have found a typo? There is a requirement that the entryUUID is a UUID, but that is th

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Copying content from duplicate stream · ihe

Stream: ihe

Topic: Copying content from duplicate stream

Josh Mandel (Apr 01 2019 at 20:40):