Requirements

[joeflack4]

Description

This is a holding place for top-level requirements, based on the "TIMS FHIR Terminology Server Requirements" google doc. If individual issues are made for each of requirements, issues should be made and linked to here.

General tasks

• [ ] 1. Finalize the "TIMS FHIR Terminology Server Requirements" google doc.
• [ ] 2. Finalize the requirements here based on (1).
• [ ] 3. Make individual GitHub issues for some/all of these requirements as necessary.

Requirements

Foundational Server Functionality

• [x] 1. both the XML and JSON FHIR formats.
• [x] 2. the READ and SEARCH interaction for CodeSystem, ValueSet and ConceptMap
• [ ] 3. the capabilities interaction with absent mode parameter or a mode parameter value of 'full' returning a CapabilityStatement resource which includes the following elements:
• [ ] 4. the capabilities interaction with a mode parameter value of 'terminology' returning a TerminologyCapabilities resource
• [ ] 5. FHIR Terminology Servers SHALL support specified operations
• [ ] 6. Vulcan TS Functional Requirements
• [ ] 7. SSSOM extension to FHIR ConceptMap(2) Resource (related: 1, 2, 3, 4)

Needed Terminology Server Content

• [ ] 1. Reference Terminology / vocabulary Content
• [ ] 2. Value Set Support / Management
• [ ] 3. Maps / Map Sets
• [ ] 4. Local Code Management
• [ ] 5. Vulcan Content requirements

End user requirements

Google doc: End user requirements AKA TIMS (Terminology Information Management System - aka JHU+CU ontology engineering groups) Requirements

• [ ] 1. Finalize mechanism to transform OWL ontologies and load into FHIR HAPI server
• [ ] 2. Grab any version of an ontology
• [ ] 3. Closure over multiple inheritance
• [ ] 4. SSSOM style equivalence mappings to be provisionable and well documented in the services return (related: 1, 2, 3, 4)
• [ ] 5. Closure
• [ ] 6. Synonym expansion
• [ ] 7. STRETCH goal
• [ ] 8. FHIR infrastructure, resources, services, spec, processes
• [ ] 9. Terminology content
• [ ] 10. Value set content and management
• [ ] 11. Mapping content and management
• [ ] 12. Projects, deliverables, or clients
• [ ] 13. Autocomplete on search

Additional requirements not in google doc

• [ ] #27

Additional info

Inspiration: Requirements for other terminology servers

1. THO (Terminology . Hl7 . Org)
2. Netherlands Context: Davera 2022/11/17: As indicated in many prior conversations, the TSMG has been working toward defining the requirements for a central terminology server resource to support the THO / UTG processes. Attached is a requirements document from our TSMG member representing the Dutch national requirements for a terminology server. This information will be among those compiled to fill-out the requirements for the TSMG statements. Request for Information for a HL7 International Terminology Server.xlsx

Useful links

1. "TIMS FHIR Terminology Server Requirements" google doc.
2. HL7 terminology server minimum requirements (2) (3)
3. TIMS Services Matrix
4. TIMS context diagram & slides (includes roles & possible user stories)
5. CTS2 functions that can be implemented in FHIR
6. http://fhir.org/guides/stats/ - Terminology IG / server index. Good source of IGs and content that we might want to load into TIMS server. May include some of what we could use for this issue.
7. TIMS agenda for 2022/10/28 has good requirements for Jan Milestone.
8. Google doc: End user requirements

Related

1. 52: Should use this (possibly w/ unit tests as well) as a means to verify and communicate that requirements have been met.

[joeflack4]

@putmantime Hey Tim. During our discussion about CompLOINC, I was thinking about how you might be able to contribute to TIMS if/when time provides. I think it would be very helpful if you could pick out some of the requirements here and create issues to expand upon them, prioritizing requirements you know the most about / are most interested in.

You could then (i) hover over the line of text in this GH issue and select the icon that appears on the right (says "Convert to issue) when you hover over it, and make an issue. Then (ii) think through the requirement from an engineering perspective, and flesh out the issue with how to fulfill / implement it, and provide anything else you think might be helpful (e.g. links to articles / documentation, code examples, etc).