Page Comparison

...

Sprint to extend some of the "read only" APIs, to finalize unit/integration testing for existing functionality, to extend the interface, to develop additional loaders, and to begin developing editing capabilities.

Fleshing out APIs

• TODO: Customizable launch-page content (e.g. disclaimer) through html partial, ng-include, and config file variableFinish implementing dui/code calls in ContentServiceRestImpl for child and root routines
• TODO: Fill in the ContentClientRest calls for new Tree REST APIs
• TODO: Write integration testing for new Tree calls (TreesForQuery, TreesForConcept, ChildTreesForConcepte.g. ComponentTrees, ComponentTreesForQuery, ComponentTreeChildren, ComponentTreeRoots)
• TODO: Revise unit testing of TreeJpa
• Consider adding a "configure" routine to all "handlers" so they can configure themselves after they are all instantiated (e.g. if they need access to a metadataservice or a contentservice to function properly)
• BUG: lower relevance of suppressible data in queries.
• BUG: support ability to search with quotes, e.g. "heart disease"
• mojo test suite for RRF-single, plus terminology remover
• DONE: Hierarchy -rest layer adds a dummy top for merging 
• DONE: Clients should handle null parameters properly
  
  • BAC: handle for content, metadata, project, security
  • Make a RootClientRest with a precondition check for null or blank
• Finalize REST service for a general concept query (e.g. lucene query, HQL query, or SQL query)
  
  • DONE: Must start with "SELECT " and not contain ";"
    
    • provide appropriate error message via exception if not
  • DONE: Execute the query but check the object type of the first result
    • if doesn't match expected type, fail with an exception.
  • Use timeout => 

  • query.setHint("javax.persistence.query.timeout", timeout);

• Implement NewConceptMinRequirementsCheck and "validation service"
  • Validation check
    • validate(Concept), validate(Atom), validate(Code), validate(Descriptor), validateMerge(Concept,Concept)
  • Validation service (Rest, ClientRest, RestImpl)
    • pre-cache validation handlers (see how this works in MetadataService, etc).
    • validateConcept  /validate/cui/ (PUT) ConceptJpa
      • load all validation handlers and call each validate Concept) method.
    • validateAtom  /validate/aui/ (PUT) AtomJpa
    • validateDescriptor ...
    • validateCode  ...
    • validateMerge /validate/cui/merge/{cui1}/{cui2} - GET
  • DefaultValidationCheck
    • validate atom whitespace
    • validate that a concept has at least one atom and at least one "hierarchical" relationship (to something that exists)
    • update config.properties to use this check
  • Organize validation checks into packages and create classes
    • com.wci.umls.server.jpa.services.validation (DefaultValidationCheck)
    • com.wci.umls.server.jpa.services.validation.umls (NewConceptMinRequirementsCheck)
      • concept has at least one atom and at least one hierarchical rel 
    • com.wci.umls.server.jpa.services.validation.snomed (NewConceptMinRequirementsCheck)
      • see term server project
  • Create an integration (jpa) tests for the validation layer (e.g. put in spreadsheet, normal use, degenerate use, edge cases, etc).
• Properly implement terminology remover functionality (e.g. content service rest.removeTerminology).  The content and the metadata objects need to be removed in the right order so as to avoid foreign key constraint errors. (e.g. attributes, definitions, semantic types, tree positions, transitive relationships, relationships, atoms, then atom classes - something like that).  For metadata I think terminology/rootTerminology is the only dependency (remove root terminology first).
  • Then update the mojo test case to remove the terminology (currently commented out)
• Finish RF2 loader implementation, test on mini smomed
  • create separate config project for this (e.g. "prod-snomedct").
  • load and depoy to snomed.terminology.tools
  • classifier?

User Interface Enhancements

• TODO: Customizable launch-page content (e.g. disclaimer) through html partial, ng-include, and config file variable
• Show additional stuff: fully defined, for relationships inferred vs. stated
• For SNOMED change labels - find a way to do this based on metadata (e.g. general metadata entries)
  • Atoms -> descriptions, attributes -> properties
• Add subset member and subset member attribute info to UI (e.g. for SNOMED)
• Add features for "deep" relationships when browsing UMLS.    
  • Need a generalized way to know when to use this
  • it is definitely only for "concept"
  • It may be that if any "atoms" of the concept don't match the terminology, then we show it.
• DONE: Tree positions (in report itself)
• IN PROGRESS: Tree browser widget (searchable) (as alternative to "search", e.g. use a tab)
• Websocket (for a WebsocketWorkflowListener)
• Advanced search (uses "search criteria" or "general query" mechanisms)
• Mobile-friendly and other style issues
  • For "definitions" use "..." for long definition values.
  • Check on style of "filter" boxes in mobile experience
  • Add a "hide non-English" button if there are atoms with language !='ENG'
  • Need improvements to filtering (e.g. misaligned quotes, extra punctuation, lots of things don't quite work right)
    • also the delay-lookup can be a bit awkward - I think tabbing-out or hitting return to trigger filtering is better and more consistent experience

...