Guidance on new developments

30 views
Skip to first unread message

Quentin Ligier

unread,
Apr 9, 2021, 4:59:48 PM4/9/21
to ipf-dev
Dear IPF developers,

Following are the next parts I'd like to develop in IPF (if nobody beats me to it).

CH:PHARM-1: This is the Swiss extension to PHARM-1. We're still working on the specifications, but a test implementation could be useful to try and examine it. It introduces the parameter '$XDSDocumentEntryFormatCode' for all queries (instead of in 'FindMedicationList' query only) and the new 'FindMedicationCard' query (which operates in a similar way to 'FindMedicationList', except generating a Swiss medication card instead of a medication list, be it in CDA, FHIR or PDF). Additional values for the parameter '$XDSDocumentEntryFormatCode' are introduced, but that doesn't impact IPF.
Should this be reimplemented as a new query, or merged with PHARM-1? Should the models be reimplemented to support this, or should we move the property 'formatCodes' from the class 'FindMedicationListQuery' to the root class (PharmacyDocumentsQuery)?

PHARM-5: This is an MHD reimplementation of PHARM-1. It should be voted in July by IHE Pharmacy. I've no question about this implementation (yet).

CH:PHARM-5: Same question as above: do we merge this extension with PHARM-5, or do we reimplement it?

ITI-45 (PIXV3 Query) & ITI-47 (PDQV3): I'd like to create two new models (raw/JAXB and simplified) for the query and response, to remove OHT (see the following dedicated note) and EMF dependencies. The Camel converters will also be created.
I need an HL7 DTM parser to manage the date formats. org.openehealth.ipf.commons.ihe.xds.core.metadata.Timestamp would be perfect, but it's in the XDS  module, and it would be weird to import it in the HL7v3 module. Is there another HL7 DTM helper that I can use? Or could we move Timestamp to the HL7 core package?

About OHT: the current OHT dependency is the one maintained by the eHealthConnector (https://gitlab.com/ehealth-connector/oht), which is to be rewritten shortly. One of the explicit rewrite goal is to remove OHT from the dependencies, so it will most probably be abandoned.

ITI-48 (Retrieve Value Set): My colleague needs it, so we'll implement the transaction. Two options are available, the SOAP binding and the REST binding. Should we implement both? If yes, in which module?

Is there any thoughts or comments on these? Thank you for your guidance.

Kind regards,
Quentin Ligier
HUG/CARA

Oliver Egger

unread,
Apr 13, 2021, 2:45:51 AM4/13/21
to ipf...@googlegroups.com, Alexander Kreutz
Hi Quentin

Dear IPF developers,

Following are the next parts I'd like to develop in IPF (if nobody beats me to it).

CH:PHARM-1: This is the Swiss extension to PHARM-1. We're still working on the specifications, but a test implementation could be useful to try and examine it. It introduces the parameter '$XDSDocumentEntryFormatCode' for all queries (instead of in 'FindMedicationList' query only) and the new 'FindMedicationCard' query (which operates in a similar way to 'FindMedicationList', except generating a Swiss medication card instead of a medication list, be it in CDA, FHIR or PDF). Additional values for the parameter '$XDSDocumentEntryFormatCode' are introduced, but that doesn't impact IPF.
Should this be reimplemented as a new query, or merged with PHARM-1? Should the models be reimplemented to support this, or should we move the property 'formatCodes' from the class 'FindMedicationListQuery' to the root class (PharmacyDocumentsQuery)?

PHARM-5: This is an MHD reimplementation of PHARM-1. It should be voted in July by IHE Pharmacy. I've no question about this implementation (yet).

CH:PHARM-5: Same question as above: do we merge this extension with PHARM-5, or do we reimplement it?

Feel free to use it or integrate it directly into IPF (it does also the mapping to CH:PHARM-1).
 

ITI-45 (PIXV3 Query) & ITI-47 (PDQV3): I'd like to create two new models (raw/JAXB and simplified) for the query and response, to remove OHT (see the following dedicated note) and EMF dependencies. The Camel converters will also be created.
I need an HL7 DTM parser to manage the date formats. org.openehealth.ipf.commons.ihe.xds.core.metadata.Timestamp would be perfect, but it's in the XDS  module, and it would be weird to import it in the HL7v3 module. Is there another HL7 DTM helper that I can use? Or could we move Timestamp to the HL7 core package?

About OHT: the current OHT dependency is the one maintained by the eHealthConnector (https://gitlab.com/ehealth-connector/oht), which is to be rewritten shortly. One of the explicit rewrite goal is to remove OHT from the dependencies, so it will most probably be abandoned.

For the mapping from PIXm to ITI-45 we used directly net.ihe.gazelle.hl7v3 which is independent of OHT, see https://github.com/i4mi/MobileAccessGateway/blob/master/src/main/java/ch/bfh/ti/i4mi/mag/pmir/iti78/Iti78RequestConverter.java.
Alexander (cc into this email) has more information if you have additional questions.

Best regards,
Oliver
 

ITI-48 (Retrieve Value Set): My colleague needs it, so we'll implement the transaction. Two options are available, the SOAP binding and the REST binding. Should we implement both? If yes, in which module?

Is there any thoughts or comments on these? Thank you for your guidance.

Kind regards,
Quentin Ligier
HUG/CARA

--
You received this message because you are subscribed to the Google Groups "ipf-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ipf-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-dev/47018c1d-e6bf-473c-87e0-e46c2ed4aa84n%40googlegroups.com.

Dmytro Rud

unread,
Apr 13, 2021, 4:10:27 AM4/13/21
to ipf...@googlegroups.com
Hello Quentin

My 2 cents inside,

Best regards
Dmytro


Am Fr., 9. Apr. 2021 um 22:59 Uhr schrieb Quentin Ligier <quentin...@bluewin.ch>:
Dear IPF developers,

Following are the next parts I'd like to develop in IPF (if nobody beats me to it).

CH:PHARM-1: This is the Swiss extension to PHARM-1. We're still working on the specifications, but a test implementation could be useful to try and examine it. It introduces the parameter '$XDSDocumentEntryFormatCode' for all queries (instead of in 'FindMedicationList' query only) and the new 'FindMedicationCard' query (which operates in a similar way to 'FindMedicationList', except generating a Swiss medication card instead of a medication list, be it in CDA, FHIR or PDF). Additional values for the parameter '$XDSDocumentEntryFormatCode' are introduced, but that doesn't impact IPF.
Should this be reimplemented as a new query, or merged with PHARM-1? Should the models be reimplemented to support this, or should we move the property 'formatCodes' from the class 'FindMedicationListQuery' to the root class (PharmacyDocumentsQuery)?

IMHO, introduction of a new query type qualifies for a new transaction -- simply because of the whole validation machinery, etc.
The redundancy between the two transaction implementations could be minimized by creating an optimal set of commons definitions.
 
PHARM-5: This is an MHD reimplementation of PHARM-1. It should be voted in July by IHE Pharmacy. I've no question about this implementation (yet).

CH:PHARM-5: Same question as above: do we merge this extension with PHARM-5, or do we reimplement it?

ITI-45 (PIXV3 Query) & ITI-47 (PDQV3): I'd like to create two new models (raw/JAXB and simplified) for the query and response, to remove OHT (see the following dedicated note) and EMF dependencies. The Camel converters will also be created.
I need an HL7 DTM parser to manage the date formats. org.openehealth.ipf.commons.ihe.xds.core.metadata.Timestamp would be perfect, but it's in the XDS  module, and it would be weird to import it in the HL7v3 module. Is there another HL7 DTM helper that I can use? Or could we move Timestamp to the HL7 core package?

About OHT: the current OHT dependency is the one maintained by the eHealthConnector (https://gitlab.com/ehealth-connector/oht), which is to be rewritten shortly. One of the explicit rewrite goal is to remove OHT from the dependencies, so it will most probably be abandoned.

ITI-48 (Retrieve Value Set): My colleague needs it, so we'll implement the transaction. Two options are available, the SOAP binding and the REST binding. Should we implement both? If yes, in which module?

It is up to you what to implement :-).  The module should be probably a new one, because the SVS data model is not yet used in IPF.
 
Is there any thoughts or comments on these? Thank you for your guidance.

Kind regards,
Quentin Ligier
HUG/CARA

--

Quentin Ligier

unread,
Apr 13, 2021, 2:47:00 PM4/13/21
to ipf-dev
Hi,

Oliver: thank you for the leads. The Gazelle HL7 library is quite interesting, the JAXB generation is much better than anything I could achieve. Do you happen to know whose in charge of it, or where the code repository is?

Dmytro: Okay, I'll think about how adapting CH:PHARM-1 could be done in the simplest way. For CH:PHARM-5, I think implementing a custom ResourceProvider instead of duplicating the transaction could be a good solution, as has been done with ITI-66 and ITI-67.
And I guess I'll create the module 'ipf-commons-ihe-svs' for ITI-48 (plus camel and spring boot modules).

I'll open separate issues for these parts to discuss specific issues and track implementation progresses.

Kind regards,
Quentin

Oliver Egger

unread,
Apr 14, 2021, 2:37:26 AM4/14/21
to ipf...@googlegroups.com, Nicolas BAILLIET
Hi Quentin

Hi,

Oliver: thank you for the leads. The Gazelle HL7 library is quite interesting, the JAXB generation is much better than anything I could achieve. Do you happen to know whose in charge of it, or where the code repository is?

I found the following link:

I copied in Nicolas from Kereval / IHE Services, maybe he knows who is in charge from the gazelle team.

Best regards,
Oliver
 
Reply all
Reply to author
Forward
0 new messages