Stream: ihe
Topic: IHE Connectathon - use of FHIR
John Moehrke (Mar 15 2017 at 20:52):
Notice of a mHealth Plugfest being held at the EU IHE Connectathon http://connectathon.ihe-europe.net/mhealth-plug-thon-announced
Reinhard Egelkraut (Apr 13 2017 at 15:44):
Hi,
during this years IHE Europe CAT in Venice there was some time to reflect on the experiences of the participants concerning the testing of the FHIR related profiles. Some of the key results of this discussion were:
- that it might be a good idea to combine the profiles PIXm and PDQm into one profile
- to make a differentiation within the MHD profile if MHD is used with a XDS environment in the back or without
@Jens Villadsen, @Oliver Egger, @Patrick Mangesius feel free to add further points, since you had a much deeper look into the matter.
It will be interesting to see how IHE is going to proceed here in detail.
And most of the implementers are of course curious about the upcoming switch of the IHE FHIR profiles to STU3 :)
Elliot Silver (Apr 13 2017 at 19:55):
@Reinhard Egelkraut, you wrote:
It will be interesting to see how IHE is going to proceed here in detail
The direction of the IHE here is based on the feedback and involvement of the community.
I think you're asking for a named option to identify the MHD backend. Can you expand on what the benefit would be? As discussed at the Connectathon, IHE ITI is looking at updates to the their profiles, and such additional information informs our decisions.
Jens Villadsen (Apr 14 2017 at 21:48):
There is lots of work to be done regarding IHE and FHIR, as I see it, ie:
1) Upgrading to STU3
2) Create FHIR conformance profiles so that conformance can easier be machine-verified
3) Revisit current profiles - especially PIXm and MHD and apply inputs from CAT
Elliot Silver (Apr 16 2017 at 05:21):
Hi @Jens Villadsen. All three of those are in progress or being evaluated. I know we have feedback from EU CAT which we have started to go over.. With respect to PIXm, I don't know what particular feedback you have in mind, but it addresses confidentiallity concerns that PDQm and the current FHIR MPI operations don't, so we can't merge it into PDQm.
Jens Villadsen (Apr 16 2017 at 12:15):
@Elliot Silver - PIXm over PDQm could be done with an extension to PDQm so that the returned Patient Resource only included identifiers. You would then gain the feature of not having to maintain to separate interfaces and PDQm could be considered an extension of PIXm which it is in FHIR terms. Keeping these features separate in FHIR does not make sense.
Jens Villadsen (Apr 16 2017 at 18:32):
Actually - it could be spec'ed (conformance profiled) as two different Patient Resources where the PDQm could extend the PIXm. Each hosted on different Endpoints. Regardless - both should use the Patient Resource already which is not the case today
John Moehrke (Apr 17 2017 at 11:46):
that would need to be brought in as a new work item next year. That is too radical of a change for a CP. It would be a good second "Trial Implementation", to see which one gets more implementation.
Elliot Silver (Apr 17 2017 at 16:26):
Agree that it is probably too signfiicant a change for a CP, but that doesn't mean we shouldn't investigate. I think keeping PIXm and PDQm as separate profiles has value as the use cases are distinct; but that doesn't mean that the solutions couldn't be made closer. Our work so far hasn't uncovered a more complementary solution, so, Jens, I'd be interested in seeing details if you have something in mind for what this looks like.
Patrick Mangesius (Apr 20 2017 at 15:07):
@Elliot Silver The main topic here was not to identify the different backends. It was more respecting there different requirements. An example would be a for submitting documents there are systems that can work with a rather small amount of Metadata. However to register a document in an XDS environment there is a larger list of required fields, that other systems might not need. Currently the only option for an implementer who wants to achieve this mapping is either extend the parameters or work with a large set of default values, which is often not possible or not really practicable in a non-demo setting. Therefore it was discussed, that one option would be to have a separate profile or version, that clearly outlines the XDS binding. Having a layer of Fhir, MHD and MHD XDS that put more and more requirements the higher you are getting in the stack
John Moehrke (Apr 20 2017 at 16:04):
The intention I had for MHD is that the MHD profile itself would impose very few constraints; yet when MHD servers are grouped with appropriate XDS actors that the constraints of XDS can cause warning/error responses by the MHD server back to the MHD client. The advantage of this is that MHD can then be used in a non-XDS environment without modification of the MHD profile. The additional advantage is that XDS can change the XDS constraints and they magically appear in MHD indirectly. ---- The question I have is, given that warning/response (including FHIR operationOutcome) is supported, what is a substantive problem with this model??? I understand some failuremodes, but they are detectable and can be managed.
Christian Ohr (Apr 24 2017 at 07:01):
The only problem is that this intention is not clearly expressed... Vol 1 has some intentional phrases like "The proxy might be expected to fill in any necessary missing metadata information", but this is very vague. Vol 2 and Vol 3 (like in Table 5.4.1.1-1) do not use any constructs like e.g. a "XDS-Grouping/Backend option" to enforce this intention: e.g. define what should happen is content required for XDS is not provided to the proxy layer etc.
John Moehrke (Apr 24 2017 at 13:47):
@Christian Ohr can you explain what you want to assure doesn't happen? Knowing this will help me set the requirements more actionable. Is it a case that MHD server side are not passing through all the XDS information? Is it clients are not providing all the XDS information and the server doesn't know what to do about it? Is it something else?
Christian Ohr (Apr 24 2017 at 15:45):
I want to avoid situations where both integration partners follow the transaction specification but are nevertheless unable to integrate properly.
When grouping the Document Recipient and Document Source actors like advertised in MHD 33.6.1, you obviously need to translate between FHIR and XDS and vice versa. However, there is a number of attributes that are mandatory in XDS (Table 4.3.1-3) but optional in FHIR. This is a potential problem for ITI-65.
For some attributes you can use default values (DocumentEntry confidentialityCode) or generate values (uniqueId, submissionTime), but for others this is at least difficult (DocumentEntry: practiceSettingCode, facilityTypeCode, classCode; SubmissionSet: contentTypeCode, sourceId; Folder: title, codeList). This makes it hard for MHD/XDS proxies to integrate out-of-the box with Document Sources that are not able to (or willing to) provide values for these attributes.
At the CAT we therefore briefly discussed adding a "XDS grouping" option to ITI-65 for both Document Source and Document Recipient that makes these attributes mandatory in the respective FHIR resources.
John Moehrke (Apr 24 2017 at 16:44):
okay, so I could see how adding an Option to the MHD DocumentRecipient to indicate that it will require the higher requires of XDS. But, even if this option existed, it must still have the ability to handle a Document Source that fails to provide all the elements desired. This is today allowed by a DocumentRecipient, to throw an error that it wants more elements than were provided.
John Moehrke (Apr 24 2017 at 16:45):
Note: MHD does require the DocumentRecipient to validate against the XDS/XCA/XDR requirements...
John Moehrke (Apr 24 2017 at 16:45):
"The Document Recipient shall also verify the FHIR resource elements for consistency with the Document Sharing metadata requirements as specified for attributes ITI TF-3: Table 4.3.1.1-3. If necessary for processing, the Document Recipient shall retrieve Resources referenced by absolute URLs in the FHIR Bundle Resource."
Christian Ohr (Apr 25 2017 at 07:04):
With such an option It would be just much clearer that the document recipient actually expects XDS conformance and that it would return a 4xx + OperationOutcome for any violation. The note you added actually implies this, but then again it clearly contradicts with the FHIR cardinalities explicitly listed in Table 5.4.1.1-1.
John Moehrke (Apr 25 2017 at 14:14):
I put the option in last night. Please feel free to review and comment to me. IHE ITI upates to STU3 can be found at ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr15-2017-2018/Technical_Cmte/Workitems/STU3updates/
Christian Ohr (Apr 26 2017 at 06:26):
Great, this makes things much clearer. Though I didn't quite get the need of having two options; both are targeted as bridging FHIR to XDS
Christian Ohr (Apr 26 2017 at 06:44):
Regarding PIXm: what @Jens Villadsen had in mind was that the following queries are equivalent:
PDQm: /Patient?identifier=urn:oid:1.2.3|4711&identifier=urn:oid:1.2.4|&_elements=identifier
PIXm: /Patient/$ihe-pix?sourceIdentifier=urn:oid:1.2.3|4711&targetSystem=urn:oid:1.2.4
I wonder if the scope of PDQm could just be made broader so that it also covers the use cases of PIXm, making PIXm eventually obsolete.
If we keep PIXm for a while, we should look at error case 3: it requires a 404 response together with a Parameters resource. Usually, error responses in FHIR may only contain OperationOutcome.
Jens Villadsen (Apr 26 2017 at 07:03):
@Christian Ohr - or as an alternative, profile a PIXmPatient that only contains identifiers and extend that profile for PDQm as PDQmPatient with the extra attributes contained in PDQm having them hosted on separate endpoints to ease discretion/security
Christian Ohr (Apr 26 2017 at 07:16):
Dunno... PDQm requires mostly a standard Patient resource, so that a patient returned by PIXm' would rather be a restriction thereof, setting the cardinalities of all attributes but identifier to 0..0. I'm not very familiar with FHIR profiling, though.
Jens Villadsen (Apr 26 2017 at 07:54):
Right ... constraints only goes one way so extending a PIXm might not be the way to go. So what about two different Patient profiles instead?
John Moehrke (Apr 26 2017 at 12:08):
You guys seem to just want PDQm... it already can be used to get cross-references. It allows query by ID, or query by demographics, or both... The results you get are based on the server knowledge of the patients, and might be Patient resources with multiple identifiers; or might e multiple Patient that are different identifiers but are related because they were 'linked'. So all that you want to change PIXm into; is already availble in PDQm. Just ignore PIXm.
Jens Villadsen (Apr 28 2017 at 09:22):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
