@Grahame Grieve , you mentioned that had rewritten tx.fhir.org . Will this be available to others to deploy terminology servers? Is so, when? Thx :slight_smile:

it's available now. https://github.com/HealthIntersections/FHIRsmith

Do you intend to publish it as a npm package?

It looks like the vsac updates are not yet part of tx.fhir.org ? I still need to include the vsac package.

yes, not done yet

Do you intend to publish it as a npm package? i don't know. would that be useful?

I've got an existing docker container I'd like to add the server to, and that seems like it would be an easy way to do it.

I've got a bunch of questions about the server, but I'll give you a few days to recover from the WGM first.

An NPM package for all the tooling added here would be useful for sure.

I do not understand how it would work as an NPM package. It needs configuration, data, so on

no, I educated myself, but I have to rework things so that it can be made to work

If you’re doing it do me, I have other questions about whether my uses are feasible.

ok sure, ask away

I’m was looking at publishing our internal IGs to an internal NPM repo, but IG Publisher can’t handle the signed S3 urls for the packages that the repo provides (discussed elsewhere). I’m assuming Publisher will have no issues fetching packages from the FHIRsmith package server. Is a local package repo within your vision? (The default configuration at least seems to be as a package.fhir.org clone.) Do you see any challenges with my plan? Right now, the server retrieves the package-feeds from a URL. For the setup I envision, reading it from a specified file would be easier. I suspect we’d have no more than 1 or 2 internal feeds, so managing them through config makes sense. I’m thinking this package server would help with the challenges I’m running into publishing an internal template. I tried setting up a package module-only system. It looks like you need config for other modules, even if they are configured as disabled. The publisher module appears to be a way to provide a “local build” on-demand service. It don’t replicate the auto build server functionality, and doesn’t provide an way to simplify milestone publication. The target here is freeing authors from needing to set up a publisher environment. Correct?

I’m was looking at publishing our internal IGs to an internal NPM repo, but IG Publisher can’t handle the signed S3 urls for the packages that the repo provides (discussed elsewhere). I’m assuming Publisher will have no issues fetching packages from the FHIRsmith package server. Is a local package repo within your vision? I hadn't thought of it, but sure, that should work. Do you see any challenges with my plan? no? I’m thinking this package server would help with the challenges I’m running into publishing an internal template. maybe. I'm not making any promises. It looks like you need config for other modules, even if they are configured as disabled. well, you need enabled : false. not more. The publisher module appears to be a way to provide a “local build” on-demand service. It don’t replicate the auto build server functionality, and doesn’t provide an way to simplify milestone publication. The target here is freeing authors from needing to set up a publisher environment. Correct? no that's for Lynn and I, to move actual publishing to a cloud build service. it's only 1/3 done yet. or less

It looks like you need config for other modules not any more

Thanks.

ok it's published as both NPM package and docker from the pipelines now

Cool. Thanks. Did you get the GitHub issue about versions figured out?

which github issue?

https://github.com/HealthIntersections/FHIRsmith/issues/32 — but looking at the prankster.json it looks like you did update it to match the release version.

Package.json.

Looks like you can close that issue now.

Thanks, that’s really helpful.