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 LigierHUG/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.
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 LigierHUG/CARA
--
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-dev/6805e9cc-1444-4e66-9680-1d32922c69acn%40googlegroups.com.