20160406 - Meeting minutes, Wednesday April 6th 2016 - Task force Terminology Server

Owned by michele.foucart
Last updated: Apr 07, 2016 by Marco Bernardini
3 min read

 

Estimated: 15:00 to 16:00 CET.

Performed:  CET.

Agenda

  1. Objective of the meeting( Target: implementation of TSAM sync)
  2. Current situation, status
    1. fix current TSAM sync vs develop a new one
  3. Must have features for the new tsam sync
    1. CTS2 compliant
    2. decoupling from any implementation of TS
    3. decoupling from LTR implementation
      1. impacts on LTR db changes
    4.  CRON vs listener ( for db syncronization)
  4. Definition of next steps
  5. Definition of test environments(NCP - A, NCP - B)

Location

  • AdobeConnect:

http://ec-wacs.adobeconnect.com/openncp/
Room Passcode:  markus.kalliola or michele.foucart
------------------------------------------------------------------------------------------------
If you have never attended an Adobe Connect meeting before:
Test your connection: http://ec-wacs.adobeconnect.com/common/help/en/support/meeting_test.htm
Get a quick overview: http://www.adobe.com/products/adobeconnect.html
Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
------------------------------------------------------------------------------------------------

Marco Bernardini

Giorgio Cangioli

S

michele.foucart

Support documents:

/wiki/spaces/ncp/pages/77758510 : 3 documents:


  •  
  • D3.9.1 Appendix A
  • WP3 9  specifications TSAM
  • TSAM CTS2 mapping:  a comparison made at the epSOS time between the LTR structure and the CTS2 data

Meeting Notes:

  1. Objective of the meeting( Target: implementation of TSAM sync)
  2. Current situation, status
    1. fix current TSAM sync vs develop a new one
    2. current TSAM linked to product Carecom + not CTS2 compliant. Even difficult to test TSAM sync. From the code of TSAM sync: heavily tight to product Carecom, so a big part of it would be replaced
      1. Plan is to develop a new TSAM sync (looks easier to build a new component than to adapt current. But this is open question, with our level of kx)?
      2. Giorgio Cangioli: current TSAMsync gets info from Health term server to the LTR. If we are ablo to fill the content of LTR with expected values that allow the other components...TSAMsync is the one interacting with the terminology. (TSAM is another component)
      3. If we act on LTR db, will only impact...verify capabilities of TSAM and Transformation manager
      4. There are constraints LTR structure - redesign of LTR db,
  3. Must have features for the new tsam sync


    1. CTS2 compliant
      1. use dortmund implementation or other REST interface?
        1. functional vs technical conformance to CTS2
          1. a lot of implementation of functional specs are not necessarily technically interoperable
    2. decoupling from any implementation of TS
      1. we will need anyway to customize the interface with a TS
        1. First step might be to implement following FHD functional implementation, later on  we might think about other
          1. Approach: Reproduce the old TSAM sync with FH dortmund
          2. Simplified interface, then reimplement or redefine it in the future
        2. What is the importance of impact? May have to build a new layer...not necessarily to start from scratch again
    3. decoupling from LTR implementation
      1. impacts on LTR db changes
    4. We could start defining what is the core with FH to have the overview of the number of operations that are needed => Marco Bernardini needs to check all the tables involved into the mapping berween FH and LTR
      1. LTR stores only value sets. But Marco sees that there are also code systems? Does Marco have the full version or a small version?
        1. It triangle to code systems, but does not record the full code system
      2. to be able to understand where are the differences
    5.  Updates CRON vs listener (for db syncronization)
      1. Goal is to avoid querying TS for updates, when it is not necessary
      2. tsamsync re-update all the LTR, problems because it failed the process when failure during the update => modifying a bit to be able to download only changes, healthcare specific
      3.  ref also to 20160405 - Meeting minutes, Tuesday, April 5th March, 2016 - OpenNCP Steering Committee ("Check the database structure of the LTR, needs to be optimized" ); but probably not linked
      4. extensions?
      5. CTS2 way to do that?
    6. First phase:



  4. Next steps
    1. What are the ops we need to have the LTR table filled correctly
    2. For each ops, see the table/services involved
    3. having a clear mapping
    4. clarify what table are needed for each ops, having a clear mapping, highlighting which services we need
      1. before querying actual data
  5. Definition of test environments(NCP - A, NCP - B)