Objective of the meeting( Target: implementation of TSAM sync)
Current situation, status
fix current TSAM sync vs develop a new one
Must have features for the new tsam sync
CTS2 compliant
decoupling from any implementation of TS
decoupling from LTR implementation
impacts on LTR db changes
CRON vs listener ( for db syncronization)
Definition of next steps
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. ------------------------------------------------------------------------------------------------
TSAM CTS2 mapping: a comparison made at the epSOS time between the LTR structure and the CTS2 data
Meeting Notes:
Objective of the meeting( Target: implementation of TSAM sync)
Current situation, status
fix current TSAM sync vs develop a new one
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
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)?
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)
If we act on LTR db, will only impact...verify capabilities of TSAM and Transformation manager
There are constraints LTR structure - redesign of LTR db,
Must have features for the new tsam sync
CTS2 compliant
use dortmund implementation or other REST interface?
functional vs technical conformance to CTS2
a lot of implementation of functional specs are not necessarily technically interoperable
decoupling from any implementation of TS
we will need anyway to customize the interface with a TS
First step might be to implement following FHD functional implementation, later on we might think about other
Approach: Reproduce the old TSAM sync with FH dortmund
Simplified interface, then reimplement or redefine it in the future
What is the importance of impact? May have to build a new layer...not necessarily to start from scratch again
decoupling from LTR implementation
impacts on LTR db changes
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
LTR stores only value sets. But Marco sees that there are also code systems? Does Marco have the full version or a small version?
It triangle to code systems, but does not record the full code system
to be able to understand where are the differences
Updates CRON vs listener (for db syncronization)
Goal is to avoid querying TS for updates, when it is not necessary
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