This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Tooling Eco-system"

From HL7Wiki
Jump to navigation Jump to search
Line 4: Line 4:
  
 
= Terminology Tooling Ecosystem =
 
= Terminology Tooling Ecosystem =
 +
 +
A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?
  
 
* Terminology Service (see [[http://hl7.org/fhir/terminology-service.html official definition]])
 
* Terminology Service (see [[http://hl7.org/fhir/terminology-service.html official definition]])
Line 23: Line 25:
  
 
* Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals?  (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )
 
* Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals?  (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )
 
 
  
 
= Conformance / Design Tooling Ecosystem =
 
= Conformance / Design Tooling Ecosystem =

Revision as of 23:40, 8 March 2016

This page describes the FHIR tooling eco-system

Note that the FHIR tooling eco-system is a set of disparate tools that are linked by the conformance resources.

Terminology Tooling Ecosystem

A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?

  • Terminology Service (see [official definition])
    • CRUD on code systems, value sets, concept maps & naming systems
    • expansion / lookup / validation / translation / closure
    • cds-hook catalogue: reference value set, reference display code
    • implementations: Health Intersections, Apelon, Art-Decor, VSAC, ??
  • Terminology registry (does this need to be a terminology service too?)
    • curated publication, voting/comment/review (see collaborative review IG below)
    • implementations: Health Intersections, Furore?, trifolia?
  • Code System / Value Set / Concept Map Editor
    • find resource(file / registry)
    • display / edit them / preview outcomes (speculative evaluation)
    • import / export from other formats - excel, csv, ?...
    • save resource (file / registry - e.g. publish)
    • implementations: Health Intersections, Apelon, VSAC, Art-Decor, PenRad

Open Issues:

  • Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals? (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )

Conformance / Design Tooling Ecosystem

  • Conformance Service
    • CRUD on StructureDefinition, Conformance, OperationDefinition, SearchParameter, ImplementationGuide, TestScript, DataElement
    • Operations: $generate-snapshot, $questionnaire (for profiles), $publish (for ImplementationGuide), $compare (StructureDefinitions, OperationDefinitions, Conformance)
    • cds-hook catalogue: reference StructureDefinition | DataElement
    • candidates: Health Intersections, Furore?
  • Testing Service
    • Test servers
    • test clients
    • Candidates: TouchStone, Crucible
  • Conformance Registry
    • curated publication
    • voting/comment/review
    • candidates: Furore
  • Profile Editor
    • details...
  • Data Element Editor (is this different to Profile Editor?)
  • Conformance Statement Editor
  • OperationDefinition Editor
  • Search Parameter Editor (?)

Conformance Registries are recommended to implement the Server Actor in the FHIR Colloborative Review Implementation Guide

Open issues

  • Will need a good way to manage external files too - Basic resources with ad-hoc narrative for security, use-cases, etc; ability to manage Binaries for images, etc.
  • Doesn't the publication tooling fall into this too? "$publish" seems a tad light-weight to represent everything that's involved in that process
  • Should we be including reference implementation generation too?
  • When dealing with voting/comment/review of content, is that only profiles & IGs, or does it include the core spec too?