Comments invited to discuss which features are important to users and why.
Could we have a URL also please, if there is a publicly facing test server available, or link to source / download?
Capability | Ontoserver | SnoChillies Server ( NZ ) | Terminz (NZ exemplar) | (SNOMED International) | Snow Owl | STS (PHAST) |
|---|---|---|---|---|---|---|
| Test endpoint | https://r4.ontoserver.csiro.au/fhir https://stu3.ontoserver.csiro.au/fhir | https://valentiatech.snochillies.com/fhir | https://terminz.azurewebsites.net/fhir | https://snowstorm-alpha.ihtsdotools.org/fhir/metadata?_format=json https://dev-snowstorm.ihtsdotools.org/fhir/metadata?_format=json | https://topaze.phast.fr/resources-server/api/fhir Uses basic authentication: user = Connectathon pass = Fhir_Connectathon1 | |
| Source Code | https://github.com/IHTSDO/snowstorm | https://github.com/b2ihealthcare/snow-owl | ||||
| Supported FHIR Version(s) | R4 (FHIR version 4.0.1) | STU3 | R4 (FHIR version 3.3.0) | R4 | R4 | R4 |
| Explicit SNOMED CT support | Y - supports multiple concurrent Editions and Versions | Y | Y | Y | Y - single edition, multi-edition, multi-extension deployments, more info here: https://docs.b2i.sg/snow-owl/index-2 | Y |
| Implicit SNOMED CT ValueSets | Y - Refset and Isa and ECL (R4) | Y - Refset and Isa | Y - Refset and Isa and ECL | Y - Refset and Isa and ECL (R4) | Y - Refset and Isa and ECL (R4) | Y (full, IsA, ECL, Refset) |
| Implicit SNOMED CT ConceptMaps | Y - Historical, Inactivation Indicators, READ CTV3 map, ICD-O map, Australian Substance map, and ARTGID map. Others configurable at deploy time | N | N | Y - Historical, Inactivation Indicators, READ CTV3 map, ICD-O map, ICD-10 | Y - Historical, Inactivation Indicators, READ CTV3 map, ICD-O map, ICD-10, and any maps created runtime | N |
| ValueSets defined using ECL | Y - all features of v1.4 including cardinality constraints | N | Y - all features of v1.3 - including cardinality constraints - except concrete values | Y - v1.3 | Y - all features of v1.6, including concrete values, cardinality constraints, and custom unofficial filters (https://github.com/b2ihealthcare/snomed-ecl) | Y - all features of v1.3 except concrete values |
| Create/Read/Update/Delete of FHIR CodeSystems | Y | Read only | Read only | Read only | Read-only, CUD via dedicated REST API and authoring environment | Y: CRUD |
Create/Read/Update/Delete of FHIR ValueSets | Y | Read only | Read only | Read only | Read-only, CUD via dedicated REST API and authoring environment | Y: CRUD |
| Create/Read/Update/Delete of FHIR ConceptMaps | Y | Read only | Read only | Read only | Read-only, CUD via dedicated REST API and authoring environment | Y |
| Able to expand ValueSets defined in terms of arbitrary (known) FHIR CodeSystems using filters | Y | Y | Y | Y | Y | Y |
| Support for other well-known code systems | LOINC, CLAML (including ICD 10, OPCS, ICPC 2), OWL (including HPO) | LOINC, ICD 10 | LOINC, NZULM/NZMT, RXNORM (limited) | N | LOINC, ICD-10/AM/CM/UK/CA, ATC, OPCS | LOINC, EDQM Standard terms, ICD-10 (in process) |
| Search of FHIR CodeSystems | Y | Y | Y | N | Y | Y |
| Search of FHIR ValueSets | Y | Y | Y | N | Y | Y |
| Search of FHIR ConceptMaps | Y | Y | Y | N | Y | Y |
| SMART on FHIR support | Y | N | N | N | N | N |
$lookup | Y | Y | Y | Y | Y | Y |
| $expand | Y | Y | Y | Y | Y | Y |
| $validate-code | Y | Y | Y | N | Y | Y |
| $subsumes | Y | Y | Y | N | Y | Y |
| $closure | Y | Y | Y | N | Y | Y |
| $find-matches | Y - FHIR spec is lacking clear definition of semantics | N | partially for SCT - operation definition incomplete | N | N | N |
| $translate | Y - includes several implicit algorithmic maps | Y ( Read Code, ICD 10, LOINC, NZPOC | Y | Y | Y | Y |
| SNOMED post-coordination support | Y | N | N | N | N | N |
| Support for close-to-user form post-coordinated expressions? | N | N | ||||
| Support for normal-form post-coordinated expressions? | Y | N | ||||
| Y | N | N | N | ||
| Y | N | N | N | ||
| Y | N | N | N | ||
| Y | N | N | N | ||
| Y | N | N | N | ||
| N | N | N | N | ||
| Y - no special additional support, but PCEs can be included in a ConceptMap and used in $translate as-is | N | N | N | ||
Support for the ExpansionProfile resource | N | N | N | N | N | N |
| Support for CodeSystem.supplements (R4) | Y - display, designations, and properties can also include post-coordinated expressions | N | Y - partial | N | Y - display, designations, properties | Y - display, designations, properties |
| Support for the NamingSystem resource | Y including $preferred-id | Y (including the $preferred-id operation) | N | Y | Y | |
| Support for the TerminologyCapabilities resource (R4) | Y | Y | N | Y | Y | |
Support for the StructureDefinition resource | Y - SCRUD | N | N | N | ||
| Support for the Bundle resource | Y - SCRUD | Y (e.g. for accepting batches of $validate-code and $translate requests) | Y - read-only, CUD via dedicated REST API | N | ||
| Support for other FHIR Resource types | OperationDefinition - Read only AuditEvent - Create only | Location & Organization (Read-Only support for NZ Health Provider Index Facilities & Organizations). | Definitional resources for catalogs of healthcare products and services: ActivityDefinition, PlanDefinition, ObservationDefinition, SpecimenDefinition, Composition, ChargeItemDefinition | |||
| $validate | Y - All resource types | N | N | N | N | |
| $convert | XML to/from JSON STU3 → R4 | |||||
| Additional to FHIR | Content syndication via ATOM | CUD API, syndication between servers using official release packages, dedicated authoring environment for content management | ||||
| Security | OAuth2 including SMART-on-FHIR Resource-level protection using FHIR security labels | Fully customizable resource access management, filtering and security |
4 Comments
Michael Hosking
This is a great summary of capabilities, thank you for putting this together.
Once this page has been developed to include a reasonable number of vendors. This page could be published on a single "Vendor Capability Comparison" page on snomedinside.org. I think this would be hugely valuable for organisations to understand the differences and capabilities.
If this page were to be published in a publicly available SNOMED site, I feel that there should be an additional column summarise/explain (with an example) the capability in plain English from the perspective of a user interface and for secondary data use (for audiences who are non-technical)
Michael Lawley
Abdul Rauf I've added some more detail rows to the table to help gather more information. As Snochillies is the only server so far to have post coordination support it would be great to get more detail about how it behaves for each of the operations.
Abdul Rauf
Michael Lawley, post coordination is implemented without FHIR formatting.
For more detail please visit following URL.
URL: https://snochillies.com
Thanks
Michael Lawley
Thanks Abdul Rauf, does that mean that there's no support for post coordination via the FHIR APIs? The table above is meant to capture what is available via FHIR only.