Skip to content
This repository has been archived by the owner on Apr 8, 2024. It is now read-only.

FHIR Bridge code refactoring proposals/ideas #442

Open
subigre opened this issue Aug 27, 2021 · 10 comments
Open

FHIR Bridge code refactoring proposals/ideas #442

subigre opened this issue Aug 27, 2021 · 10 comments
Assignees

Comments

@subigre
Copy link

subigre commented Aug 27, 2021

Background

The current FHIR Bridge codebase is becoming bigger and it is sometimes hard to organize/find/maintain the code.
In addition, we use a lot of third-party librairies and the dependency management is becoming very hard.

The following non-exhaustive list contains some ideas/proposals for the next code refactoring in order to improve the development, testing and maintenance.

Maven multi-module project

The project structure should be re-think in order to organize the codebase using different modules:

  • fhir-bridge-camel
  • fhir-bridge-fhir
  • fhir-bridge-app
  • fhir-bridge-openehr
  • fhir-bridge-converters
  • fhir-bridge-core
  • fhir-bridge-utils
  • ...

Define custom transactions

We should think about defining a list of transactions like IHE is doing: ITI-65, ITI-68, etc.

  • FB-01 - Provide Observation
  • FB-02 - Provide Condition
  • FB-03 - Provide DiagnosticReport
  • ...

This could also help to:

  1. Better organize the code
  2. Use the same approach than IPF
  3. Keep consistency to include existing IHE transactions
  4. Improve existing wiki documentation
@subigre subigre changed the title Switch to a Maven multi-module project FHIR Bridge code refactoring proposals/ideas Aug 27, 2021
@SevKohler
Copy link
Contributor

SevKohler commented Aug 27, 2021

In addition:

  1. Adding a Fileless test case support for the mapping tests.
  2. Splitting converters into CODEX and HIGHMED converters
  3. cleaning up the tests files (lots of duplicates)
  4. updating the robot tests (since thats why these are duplicated)
  5. Updating Postman
  6. clean up of dead imports

@subigre
Copy link
Author

subigre commented Sep 1, 2021

@subigre
Copy link
Author

subigre commented Sep 2, 2021

  • Relation between subject.identifier <-> PatientId <-> EHR ID

@SevKohler
Copy link
Contributor

SevKohler commented Sep 9, 2021

@subigre pls no google coding style, i would prefer the one we have currrently (at least for the tabulators), or do you have any other preferences ?

@SevKohler
Copy link
Contributor

¨WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.javers.common.reflection.JaversMember (file:/home/severink/.m2/repository/org/javers/javers-core/5.14.0/javers-core-5.14.0.jar) to field java.lang.Enum.name
WARNING: Please consider reporting this to the maintainers of org.javers.common.reflection.JaversMember
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release¨
FIx this it occurs when executing the tests of patient in icu

@SevKohler
Copy link
Contributor

What is with the JUNIT test that tests coding codes (terminology server), i think we can delete those.

@subigre
Copy link
Author

subigre commented Oct 5, 2021

  • Use next final release of openEHR_SDK instead of develop-SNAPSHOT

@SevKohler
Copy link
Contributor

Add exception catcher for timeconverter, since the bride does not show if an error occurs

@SevKohler
Copy link
Contributor

provide script to autoupdate opts and profiles via just entering the urls
autogeneration of paragon files as script

@subigre
Copy link
Author

subigre commented Oct 20, 2021

Converters used in conversion API should always:

  • be stateless
  • throw a ConversionException (when the FHIR resource could not be processed)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants