project-husky / husky Goto Github PK

With the possibility of requesting PMLC documents with non-active treatments, the generator might receive a list of medication statements for active and non-active treatments. The generator should ignore non-active medication statements.

There are some problems within the generated CDA document "Arztmeldung".

• In the EpimsEntryCaseIdentificationArzt element, the OID 1.2.40.0.34.6.0.11.3.57 is not allowed as a template ID
• In the EpimsEntryNotificationOrganizerArzt element, the OID 1.2.40.0.34.6.0.11.3.56 is not allowed as a template ID
• Some elements are missing in cda document:
  • RecordTarget
  • RealmCode
  • TypeId
  • LanguageCode
  • Title
  • ConfidentialityCode

This tracks the implementation of a validator of CH-EPR SAML assertions -- emitted by the community, not the IDPs. Its to goal is to verify the signature of the assertion against known public keys (provided by the developer), validate some parts of the assertion (as the validity date) and extract common information from it in a simple data structure (we assume the IDP/community have checked these data and we don't try to validate them further).

[x] Implement the assertion validator with OpenSAML 4.
[x] Extract common Swiss information from the assertion.
[ ] Implement JUnit tests.
[ ] Describe the use in the wiki.

A few JUnit tests are implemented, and the code is in use in the eMedication aggregator to test it against real assertions.

Later work:

• The CH:CPI transaction should be implemented to retrieve the current list of the communities' public keys.
• A SignatureTrustEngine should be implemented to keep the public keys updated and provide them to the validator.

This will be needed for the eMedication aggregator when the cross-community is enabled (not quite soon…).

After professional feedback, it has been suggested to merge all the treatments into a single table, in which the reserve treatments will be last, with some sort of separation to distinguish them.

Change to installation guide to better understanding of how to do development and building.

Implementation of husky-emed-ch-cda-narrative

The eMed branch is really not ready for a release because it's still moving so fast. I'll move all eMed-releated code to its own branch.

22-implementation-of-husky-emed-ch-cda-narrative can be merged in the new branch.

It's hard or impossible to understand what the Author class actually does. Some setting where done automatically at construction and serialization is incorrect. E.g., authorSpeciality is add as malformatted attribute to the provide and register metadata, although it is not set at the Author instance. The author and related classes needs some design thinking.

Hl7Dtm.fromHl7 fails complaining about the format not being compliant

Implementation of mappers for transformation between SubmissionSet and DocumentManifest, and DocumentReference and DocumentEntry.

Partially implemented in the MobileAccessGateway:

• Iti66ResponseConverter
• BaseQueryResponseConverter

The PIX API is quite cumbersome. It's not implemented in an intuitive way and currently requires a trial and error approach to get it up and running. The class hierarchy is no longer helpful and some method parameter are obsolet, or must be set multiple times.

The future project for refactoring the husky convenience API shall cover the current PIX and PDQ implementation. A general request builder pattern which applies to all IHE ITI transactions should be used in husky.

There is a change planed on the metadata for 15th april 2023 by eHealth Suisse. After it is added in the legal documents, I (Carole) can provide a new current YAML-File so the ValueSet are up to date.

• New YAML file added in ticket
• Add small manual changes as written in wiki
• run code generator
• check if changed codes can be used.

There are a few branches that have been merged back to master but still exists. These should be deleted, except if they're being reused.

1. DM-Playground-Tests
2. Playground-Tests
3. CH-PixV3
4. CH-RegistryStoredQueryTest
5. CH-Provide-and-Register-with-XUA-
6. feat/austrian_extensions

@ajungwirth, @msmock Is it ok to delete these?

For the Impfmodul we require a maven release package we can download form one of the maven repositories online.

The first line on both:
if (!this.hasCode() && !this.getCode().hasCoding()) return false;
should in fact be
if (!this.hasCode() || !this.getCode().hasCoding()) return false;

The consequences of the wrong code are that for a code without coding (only text), the first line does not return true and then the next line throws a null exception.

e.g. "Medication treatment plan.brief" instead of "Medication treatment plan.brief Document" in ChEmedEprCompositionMtp

Currently, the value set manager only supports the ArtDecor source. We must add the FHIR source.

1. The code namespace must go from org.husky to org.projecthusky.
2. The Maven group id should be changed too.
3. Update the code generator.

I can do it, if needed. Is there some blocking task? I'd like to merge #47 first.

06:01:39.667 [main] INFO org.projecthusky.fhir.emed.ch.epr.validator.ChEmedEprValidatorTest - [INFORMATION][UNKNOWN] Code System URI 'urn:oid:2.51.1.1' is unknown so the code cannot be validated
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 20.861 s <<< FAILURE! - in org.projecthusky.fhir.emed.ch.epr.validator.ChEmedEprValidatorTest
[ERROR] org.projecthusky.fhir.emed.ch.epr.validator.ChEmedEprValidatorTest.validateDocumentBundle Time elapsed: 20.788 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: but was:

Hi,

We are using ConvenienceCommunicationCh to submit document to a Document Registry.

We have concerns about the field ConvenienceCommunication#txnData.

As far we understood, the instance of the field should work only for a single interaction with the Document Registry/Repository.

However, the Spring Bean Scope of ConvenienceCommunicationCh is Singleton.

Therefore, in multi threaded environment, i.e. basic Spring Boot App with REST services, the instance of the txnData field will be shared among many concurrent requests.

This will lead to unexpected changes of the ConvenienceCommunication#txnData from REST request point of view, and therefore failures.

Is my understanding correct?

Shouldn't we prevent concurrent access setting the Prototype Spring Bean Scope for ConvenienceCommunication and ConvenienceCommunicationCh?

Best regards

Many unit tests produce an exception "java.lang.IllegalArgumentException: Unsupported class file major version 62". Seems that some libraries are compiled with java 18, while we require Java 17.

Active ingredients should be added to the PMLC PDF card along with the name. It has been suggested to add it right under the medication name.

See the changes here: hl7ch/ch-emed#241

Ich habe immer wieder Build Probleme mit den Klassen in Husky, in denen in instanceof checks Objekte deklariert werden, z.B.

if (!(o instanceof final IheXon that)) ...

Um trotzdem Tests ausführen zu können muss ich z.B. in IntelliJ "experimentielle Java Features" zulassen. Bei jedem Reload des Maven Projects wird das aber wieder überschrieben.

Wenn es kein Problem von IntelliJ allein ist, dann sollten wir das Problem in Husky lösen (Maven Configuration?) oder auf das Feature (object declaration in if clauses) verzichten.

See ehealthsuisse/EPR-by-example#6

E.g. on a Tomcat Debian:

java.io.FileNotFoundException: /var/lib/tomcat/.fhir/packages/packages.ini (No such file or directory)
[2023-04-24 07:41:55] [crit]     at java.base/java.io.FileOutputStream.open0(Native Method)
[2023-04-24 07:41:55] [crit]     at java.base/java.io.FileOutputStream.open(FileOutputStream.java:293)
[2023-04-24 07:41:55] [crit]     at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:235)
[2023-04-24 07:41:55] [crit]     at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:184)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.utilities.TextFile.stringToFile(TextFile.java:122)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.utilities.TextFile.stringToFile(TextFile.java:132)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.utilities.npm.FilesystemPackageCacheManager.<init>(FilesystemPackageCacheManager.java:128)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.validation.ValidationEngine.getPcm(ValidationEngine.java:976)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.validation.ValidationEngine.initContext(ValidationEngine.java:465)
[2023-04-24 07:41:55] [crit]     at org.hl7.fhir.validation.ValidationEngine$ValidationEngineBuilder.fromNothing(ValidationEngine.java:358)
[2023-04-24 07:41:55] [crit]     at ch.ahdis.matchbox.engine.MatchboxEngine$MatchboxEngineBuilder.getEngineR4(MatchboxEngine.java:108)
[2023-04-24 07:41:55] [crit]     at org.projecthusky.fhir.emed.ch.epr.validator.ChEmedEprValidator.<init>(ChEmedEprValidator.java:51)

https://github.com/CARA-ch/pmp/issues/46

See ahdis/ch-emed-pmp#48

An exception is thrown if a patient has an address without a country.

The following element is returned as the patient's address

<addr>
    <postalCode>4183</postalCode>
    <city>Graz,17.Bez.:Puntigam</city>
    <streetAddressLine>KlosterneuburgerStraße 97</streetAddressLine>
</addr>

In addition, the extraction of house number and street name does not fit.

Hello,

when trying to convert between opensaml assertions and husky internal xua assertions, we encoutered the problem that the SignatureValue is always empty. After some debugging, we could identify that the AssertionBuilderImpl#create(assertion) method is modifying the underlying assertion.

Hope you can provide some fix.

Thanks,
Christian

There is a change planed on the metadata for 1st dezember 2022 by eHealth Suisse. After it is added in the legal documents, I (Carole) can provide a new current YAML-File so the ValueSet are up to date.

• New YAML file added in ticket
• Add small manual changes as written in wiki
• run code generator
• check if two new format codes can be used.

Hi all,

We should decide where to put the boundary between IPF and Husky, particularly for national transaction implementations. Some are in IPF (CH:PPQ, CH:CPI, ...) and a few are in Husky (CH:PHARM-1 and CH:PHARM-5). Not sure if other parts of the code are concerned by that.

I've no strong feeling on this one.
The only thing is that, if we want to move the last two to IPF, we should do it before they make it to a release here, it would be a dumb breaking change.

doing a check with an MTP with a treatment with a state date "2023-09-15T00:00:00+02:00" then the generated date on the PDF was "14/09/2023 22:00" which points to an issue with the time zone handling.
The timestamp on the generated PMLC resource is correct so the problem is only at PDF generation time.

IPF 4.6.0 has been released.
Waiting on Matchbox 3.2.2 to do the upgrade.

Make CdaChEmedValidator thread-safe

• The XPathExpression is thread-safe when using Saxon, not thread-safe when using JAXP/DOM. Not sure if we need to synchronize the evaluation. Maybe use the specific Saxon implementation classes, as it's imported by ph-schematron, and don't use any lock on that part.
• The SchematronResourceXSLTs are not thread-safe. We could implement one lock per document type. Still, it prevents validating multiple documents of the same type at the same time, that could become a performance issue.

The project to port the eHealth Connector to Husky was the first step of all the actions planned for Husky.

The second action pack was to collect all integration tests (against gazelle) to a separate projects to be able to run and extend them without touching and re-building the core code.

This is a high priority task to be organized as soon as possible.

Hey,

I've a question about value set management. We specifically require new type, format and class codes for the eMedication project. Currently, the Java enums are created from ArtDecor value sets, which are copied from the current ordonnances. New codes are needed for implementation, but are quite far from being included in the legal framework. How should we proceed then? I see three possibilities:

1. Manually add them to the enums. Not really clean, since they now contain codes that aren't officially in use.
2. Duplicate these enums in the eMedication package. It's cleaner, but it doesn't work with code that requires the original enums.
3. Create another branch/version that contains the eMedication code and this modification. It requires a bit more work, since it should be kept up-to-date with the main branch.

What do you think?

We could not find a PIX Query Tests which verifies more than the patient ID, i.e., the assigning authority of the PIX Manager is not extracted in the tests.

Later this year, a huge dependency upgrade will be necessary.

• IPF will migrate to v5: see oehf/ipf#414 for status
• Spring v6, v5.3 will EOL on 31 Dec 2024.
• Spring Boot v3, v2.7 will EOL on 18 Nov 2023.
• Camel v4, v3.22 will EOL on Dec 2024.
• CXF v4
• Java 17
• Jakarta EE 9/10
• Tomcat 10.1, Jetty 11, Undertow 2.3.

The new dependency releases are already out, except for IPF 5 and Camel 4. Camel 4 components will migrate as they are ready, so we may need to wait for future v4 releases.

Implementers should prepare for that migration because most of the dependencies will become unsupported at the end of next year.
I guess this could be a new major version, Husky 3. Is there any need to maintain Husky 2 in parallel?

In the vaccination module we need to convert CX codes for EPR SPID and CII codes for authorRoles to the String representation ( "HCP^^^&2.16.756.5.30.1.127.3.10.6&ISO").

I can't find helper methods to do the conversion.

Any help is appreciated.

At least the beta ones. It's time to regenerate the value sets.

Is there a test for Provide and Register Document Set Transaction with the Swiss EPR requirements (XUA Token, Swiss EPR Metadata)?

When installing using the installation guide I end up with a lot of errors in eclipse of type

"The package javax.xml.parsers is accessible from more than one module: , java.xml"

which seems to be related to recursive dependencies declared in the project.

CceDocumentDigester constructor requires all 4 specific digesters as constructor parameters. Usage should be allowed without them, for example to digest only MTP or PMLC documents.