a) Specification presentation > TSAM-sync (adaptation for CTS2 compliance) - continuation

• Relevant for implementation;

• Platform independent and Platform Specific;

• The document states the WHAT to be implemented >  https://service.projectplace.com/pp/pp.cgi/r891876139

• The HOW to be implementeded > http://informatics.mayo.edu/svn/trunk/cts2/

• SOAP implementation

• If this

• REST implementation (real implementation)

• If this: devlopment framework: http://informatics.mayo.edu/cts2/index.php/REST

• spec/psm/rest/html/cts2.html

• 1) Please give me all the value sets used in epSOS;

• 2) Then we take the valuesets and then we select the active ValueSets version - provide the members of the valueSet;

• 3) Get detail about that Concept/Entity

• Includes Tranlation as well as other information (e.g. designation);

• 3.5.3 EntityDescriptionReadService

• 3.5.3.1 read

• 4) Get full details about the code system and codesystem version > http://serverRoot//codesystem/{codesystemid} (using previously obtained ID in step 3)

• 3.5.7 CodeSystemVersionCatalogReadService

• 3.5.8 CodeSystemCatalogReadService

• 5) Handle possible mapping (What the code system to map?)

• Request all the map that may be used for epSOS in a specific country;

• Request the CURRENTLY EFFECTIVE MAP version that need to be used in epSOS (current version of the MAP);

• 6) Request detail about the MAP that will include:

• MAPSET (relation between the SOURCE code and the TARGET code);

• What can be removed from a CTS2 Query (in order to reduce complexity) and be managed externaly (e.g. filters);

• ?) What has been updated,  so that we can sync only the modifications (in order to improve the efficiency of the sync process);

• CTS2 Development framework: http://informatics.mayo.edu

• /cts2/

• framework/

• REST implementation (real implementation): http://informatics.mayo.edu/

• cts2/

• index.php/REST

• HSSP (HL7 + OMG) CTS2 Specifications 

• CTS2 and HL7 SFM (Service Functional Model : functional specification )

• The  following sections describe how the CTS2 Platform Independent  Model  (PIM) aligns with the HL7 Service Functional Model (SFM): http://informatics.mayo.edu

• /

• cts2/

• index.php/CTS2_and_HL7_SFM

• CTS2 OMG© (Platform Indipendent Model and Platform Specific Model (including also the REST Platform Specific Model): http://informatics.mayo.edu/svn/trunk/cts2/spec/psm/rest/html/cts2.

• html

• LexEVS -  is the central EVS terminology server, developed by the Mayo Clinic with NCI and other support. 

• https://wiki.nci.nih.gov/display/LexEVS/LexEVS

• https://wiki.nci.nih.gov/display/LexEVS/LexEVS+6.0+CTS2+Guide

• [to CareCom] If, and in case, what they are able to support of the OMG CTS2 REST implementaion   Does HealthTearm support CTS2? REST Implementation?

• Mayo Clinic > 

• PHAST (= Ana Estelrich) > 

• To  the topic of TSAM sync adoption, as the structure of LTR (Local terminology Server) won't change,  there will be no changes in TM or TSAM module. We are out of the

• game  ;-).

• However, maybe you will have to face with filling LTR database.

• As  we've designed the original LTR, if you need some explanations what are current tables and attributes and why it is as it is, I would be

• glad  to help (I hope my memory still reaches such a long time ago).

• TSAM-sync > is the only component that need to be modified;

• Are the DAOs the only part of the current implementation that we can reuse?

• What documentation is there on what it is build today, how it works, in order to extend the current implementation?

• https://code.google.com/p/epsos-common-components/source/browse/userdoc-environment/EPSOS-TSAM-Synchronizer.pdf?repo=tsam-sync (Design Specification)

• LTR Database

• Already build a diagram (the current database schema)

• Man Power Available:

• SE: Oct: 4-8h week;

• Gnomon: Oct & mid Nov: few hours available;

• PT: 1 person per Month > Oct. / Nov. / Dec.

• Start MRO Development;

• FI: ??

• ?? Who else is available for collaborating in the development team??

• > 20h Portal > Add support for searching this kind of Documents

• > 20h CDA display Tool > Make sure it is compatible with the MRO CDA document or need extension.

• > 16h Protocal Terminators: client side: Add differentiation in the classcode (Service Wrapper)

• > 16h Protocal Terminators: server side: extend the national interface for search MRO documents (new method)

• > 32h Integration tests (mock objects and IHE validators - MRO validator available)

• > 24h Documentation, for updating the thw wiki and integration guide

• Sprint: Start 15Oct > Ends by 28Oct;

• It is possible to collect all the transaction messages into an XML file.

• Norbert would like to present up to the next F2F Meeting a refined approach to QA. This approach icudes a semi-sync conversation process (messaging) between NCP A NCP B (incl NC MOCK!) artifact and remote Gazelle services.

• Kostas has wrtitten a LOG4J config file that already grabs the messages and store them in a database

• This mechanism can be re-used to obtain the messages in order to validate them (in the CI environment automated process);

• It can also be adopted officially as a common way to obtain the messages in a PPT or PAT scenario;

b) 5º PPT slot - progress monitoring