FHIR Chat · NPM package system · tooling

Stream: tooling

Topic: NPM package system

Nick Freiter (Dec 11 2019 at 15:25):

We are working on a tool for creating IGs and we want to be able to download FHIR packages and place them in the user's cache given the canonical name of a package that is declared as a dependency. As far as we can tell the IG publisher does this, but it isn't totally clear to us how. Is there some central repository for getting these packages? Additionally we've heard that packages.fhir.org will "soon" be used for package management. Is this coming soon enough that we should just wait until that is operational rather than implementing a solution that'll be out of date soon?

Lloyd McKenzie (Dec 11 2019 at 15:57):

@Grahame Grieve

Vadim Peretokin (Dec 11 2019 at 17:00):

• @Martijn Harthoorn

Grahame Grieve (Dec 11 2019 at 21:07):

yeah you don't want to reproduce my hack workarounds for not having packages.fhir.org. I'm going to transit to that as soon as this round of publication is done

Grahame Grieve (Dec 11 2019 at 21:08):

btw, have you seen the publication requirements?

Grahame Grieve (Dec 11 2019 at 21:08):

oh - but... note: there are two special versions "dev" and "current" which are not and will not be resolved using packages.fhir.org

Nick Freiter (Dec 12 2019 at 15:18):

Thanks for the response. This is for SUSHI by the way, the reference implementation command line tool for FHIR Shorthand. So if packages.fhir.org is what will be used, is there documentation around using that?

I have seen documentation about packages here: https://confluence.hl7.org/display/FHIR/NPM+Package+Specification and here: https://confluence.hl7.org/display/FHIR/FHIR+Package+Cache, but I'm not sure if those pages are the "publication requirements".

If "dev" and "current" are not going to be resolved using packages.fhir.org, how would one handle a package with those versions?

Ward Weistra (Dec 12 2019 at 16:18):

Hi @Nick Freiter, packages.fhir.org, currently the same as packages.simplifier.org, is up and running. You can also use our command line tool Torinox to install packages to your FHIR cache (~/.fhir) or validate against them: https://simplifier.net/docs/torinox/Install. That's using a .NET library to work with the packages endpoint, which will likely become open source.

There's not much documentation on building on the package registry yet, but I'd be happy to work with you on that. What I know is that you can find the list of available package versions at https://packages.simplifier.net/hl7.fhir.us.core/. And then you can download the actual package versions from the URLs listed there, like https://packages.simplifier.net/hl7.fhir.us.core/3.1.0. Any other endpoints you need?

The URLs you mentioned are indeed the package spec. @Grahame Grieve might also have been referring to the IG publication requirements: https://confluence.hl7.org/display/FHIR/FHIR+Implementation+Guide+Publishing+Requirements

I guess we've limited the amount of imported packages from HL7 to stable ones right now, because these keep being overwritten? @Martijn Harthoorn

Nick Freiter (Dec 12 2019 at 16:36):

Thanks Ward! It looks like those endpoints are exactly what we were looking for, so that's a huge help.

Grahame Grieve (Dec 12 2019 at 19:35):

@Ward Weistra have you actually documented the packages.fhir.org interface yet?

Grahame Grieve (Dec 12 2019 at 19:37):

@Nick Freiter

• "dev" means your local build - so look in the local package cache for a version "dev" and fall back to "current". the IG publisher pushes a "dev" into your package cache when it builds

• "current" means to resolved based on the json behind this page: https://fhir.github.io/auto-ig-builder/builds.html (rather than using packages.fhir.org)

Grahame Grieve (Dec 12 2019 at 19:39):

and other version should be fetched from packages.fhir.org though I currently have a mess in place until I get to that

Ward Weistra (Dec 16 2019 at 16:00):

@Grahame Grieve I don't think we have. We'll have to add it to simplifier.net in any case, but would you prefer a place on the confluence too?

Nick Freiter (Dec 16 2019 at 17:06):

@Grahame Grieve when you say that "current" is resolved using the json behind https://fhir.github.io/auto-ig-builder/builds.html, I am a little confused by what that means. Is it similar to packages.fhir.org, where the URL can be combined with the canonical name of the package to get an endpoint that can be used to download a current version of the package? Or does one have to follow the link on https://fhir.github.io/auto-ig-builder/builds.html to the relevant package and then download the current version from there?

Grahame Grieve (Dec 16 2019 at 19:32):

@Ward Weistra yes, on confluence would be good.

Grahame Grieve (Dec 16 2019 at 19:37):

@Nick Freiter how it works is that you access https://build.fhir.org/ig/qas.json. then, you sort that by date, and then iterate that json array from most recent to oldest to find either the package-id or canonical url that you are looking for the #current package for, and then fetch the package from https://build.fhir.org/ig/[repo]/package.tgz

Grahame Grieve (Dec 16 2019 at 19:38):

I'll add that to the documentation once @Ward Weistra etc have documented packages.fhir.org on confluence

Nick Freiter (Dec 16 2019 at 19:43):

Ah ok, that makes sense, thanks for the help!

Ward Weistra (Feb 04 2020 at 12:48):

@Grahame Grieve It's not on the Confluence yet, but here's the documentation for packages.simplifier.net (which currently equals packages.fhir.org): https://simplifier.net/docs/package-server

Ward Weistra (Feb 04 2020 at 12:48):

I can copy what's relevant to the Confluence. Feedback already welcome.

Grahame Grieve (Feb 07 2020 at 10:22):

thanks for the doco. One important addition: the ability to subscribe to the package registry and learn about any new packages it has. Can we have a _lastUpdated that runs with no other parameters?

Grahame Grieve (Feb 09 2020 at 20:03):

also, what does prerelease actually do? - what part of the package is it based on?

Grahame Grieve (Feb 09 2020 at 20:04):

given the proposed definition of Package version response, I presume that means that the normal response only returns the latest package versions?

Grahame Grieve (Feb 09 2020 at 20:04):

@Ward Weistra

Grahame Grieve (Feb 09 2020 at 20:09):

seems to me that the search should also include Url in the json response

Grahame Grieve (Feb 09 2020 at 20:45):

the response for http://packages.fhir.org/catalog?name=core suggests that we really need a parameter for 'serious=true' or something so that the weird experimental stuff in simplifier doesn't show up

Grahame Grieve (Feb 09 2020 at 20:47):

http://packages.fhir.org/catalog?name=corezxxx

I think that this should return an empty search, not a 404

Grahame Grieve (Feb 09 2020 at 21:00):

the API has a weird mix of casing on names. e.g. upper camel case on search, lower camel case on versions

Grahame Grieve (Feb 09 2020 at 21:01):

why not return fhirVersion on the versions end point?

Grahame Grieve (Feb 09 2020 at 21:02):

in fact, why not just always return name + version + fhirversion + description + url?

Grahame Grieve (Feb 09 2020 at 22:15):

a more serious issue: in the future, there will be FHIR packages that reference multiple FHIR versions, not just a single one

Grahame Grieve (Feb 09 2020 at 22:16):

also, I thought that there was going to be a 'get all dependencies' operation?

Ward Weistra (Feb 10 2020 at 12:05):

Thanks for the feedback @Grahame Grieve, I'll look at it with the team.

Grahame Grieve (Feb 11 2020 at 03:00):

Also, what mime type will we use for .tgz? application/tar+gzip ?

Grahame Grieve (Feb 14 2020 at 04:51):

one more: the search needs to return the date of the package so the results can be sorted in case there is more than one match for a canonical URL

Grahame Grieve (Feb 20 2020 at 04:35):

I've updated the package registry so that instead of listing which packages feeds are allowed to contain, it lists package patterns that are restricted to particular feeds.

Grahame Grieve (Feb 20 2020 at 04:36):

  "package-restrictions" : {
    "hl7.fhir.*" : ["http://hl7.org/fhir/package-feed.xml", "http://fhir.org/packages/package-feed.xml"],
    "hl7.tx.*" : ["http://terminology.hl7.org/package-feed.xml"],
    "fhir.*" : ["http://fhir.org/packages/package-feed.xml", "http://fhir.org/guides/package-feed.xml"],
    "hl7.au.fhir.*" : ["http://hl7.org.au/fhir/package-feed.xml"]
  },

Grahame Grieve (Feb 20 2020 at 04:36):

let me know if that's a problem - I think you're not currently implementing that part @Martijn Harthoorn

Grahame Grieve (Feb 20 2020 at 12:50):

@Ward Weistra further, the search has to return the canonical URL as well

Ward Weistra (Feb 20 2020 at 17:19):

Time for some responses :slight_smile: @Grahame Grieve

One important addition: the ability to subscribe to the package registry and learn about any new packages it has. Can we have a _lastUpdated that runs with no other parameters?
one more: the search needs to return the date of the package so the results can be sorted in case there is more than one match for a canonical URL

Agree with the intent. Is this a search parameter for 'give me packages updated after X'? Or a field in the returned package/package version?

also, what does prerelease actually do? - what part of the package is it based on?

It's about the Semver versioning of the package. Anything 1.2.3 is ready for release anything 1.2.3-something isn't.
Eg. https://packages.fhir.org/acme.base.r4 only has a prerelease package version. Thus https://packages.fhir.org/catalog?name=acme.base.r4&prerelease=true returns one result, https://packages.fhir.org/catalog?name=acme.base.r4&prerelease=false returns none. The effect will be more obvious once version parameter is implemented.

given the proposed definition of Package version response, I presume that means that the normal response only returns the latest package versions?

No, without the version parameter it just returns one entry for each package entity, not a specific version. Next you could see what versions are available with https://simplifier.net/docs/package-server/VersionListing and pick the highest (dist-tags has latest). With the version parameter it returns one entry for each package version, so multiple entries per package entity.

seems to me that the search should also include Url in the json response

Which URL would you like? self url for the query you've done? Or url per package/package version? Both could be a convenience, but also easily constructed right now.

the response for http://packages.fhir.org/catalog?name=core suggests that we really need a parameter for 'serious=true' or something so that the weird experimental stuff in simplifier doesn't show up

Well, that's what the default of prerelease=false is for. And reserved namespaces like hl7.*. But this is something every package registry with user generated content has (NPM, PyPi, etc.).
We can do better education of what the impact is of making a non-prerelease package, but we can't do manual curation of what is and what isn't up to our standards.
We also at some point use information like 'how often do people depend on this package' to order the results (especially when using Elastic).

http://packages.fhir.org/catalog?name=corezxxx
I think that this should return an empty search, not a 404

Correct, we'll fix that.

the API has a weird mix of casing on names. e.g. upper camel case on search, lower camel case on versions

Correct, we'll harmonize that. NPM seems to use lowercase: http://registry.npmjs.com/-/v1/search?text=fhir&size=20

why not return fhirVersion on the versions end point?
Grahame Grieve: in fact, why not just always return name + version + fhirversion + description + url?

Because that endpoint was trying to stay aligned with npm conventions, like on http://registry.npmjs.com/fhir/ or http://registry.npmjs.com/fhir/1.0.2. But we'd be OK with adding/deviating. But we should then probably also document our deviation on https://confluence.hl7.org/display/FHIR/NPM+Package+Specification

a more serious issue: in the future, there will be FHIR packages that reference multiple FHIR versions, not just a single one

Our tools do not support this within one package version (it's ok within a package name, for different package versions to have different FHIR versions), we only store the first fhirVersion encountered.
We also think it's undesirable within one package version. Eg. Forge for example only supports one FHIR version per application. Double FHIR versions will break using this package. Same for our other tools.
The package spec also states: "So this should only be seen in old balloted packages".

I thought that there was going to be a 'get all dependencies' operation?

Perhaps we'll offer this as a extra feature at some point, but for now that's easy to get iteratively. Get dependencies for package, get dependencies for their packages, etc.

what mime type will we use for .tgz? application/tar+gzip ?

We currently use application/tar+gzip when returning the package on https://packages.fhir.org/acme.base/0.0.2. NPM seems to use application/octet-stream when GETing https://registry.npmjs.org/fhir/-/fhir-1.0.2.tgz. Stick with application/tar+gzip?

I'll discuss the canonical and package patterns with @Martijn Harthoorn.

Grahame Grieve (Feb 20 2020 at 20:33):

Is this a search parameter for 'give me packages updated after X'? Or a field in the returned package/package version?

Definitely "give me packages updated after X" - for now, I'm doing http://packages.fhir.org?lastUpdated=[xml-date]

Grahame Grieve (Feb 20 2020 at 20:33):

what does prerelease actually do

ok we need to add that to the documentation

Grahame Grieve (Feb 20 2020 at 20:35):

No, without the version parameter it just returns one entry for each package entity

but it includes Description and FHIRVersion, which are Package version specific. So what are these other than the latest version?

Grahame Grieve (Feb 20 2020 at 20:36):

Which URL would you like? self url for the query you've done? Or url per package/package version?

Url per package version

Grahame Grieve (Feb 20 2020 at 20:38):

Well, that's what the default of prerelease=false is for.

I don't see how prerelease=false makes any difference to that query

Grahame Grieve (Feb 20 2020 at 20:38):

Correct, we'll harmonize that. NPM seems to use lowercase

yes lowercase please

Grahame Grieve (Feb 20 2020 at 20:39):

But we'd be OK with adding/deviating.

great. I'm ok to add extra stuff as a deviation. And it turns out I can't function with Url in there

Grahame Grieve (Feb 20 2020 at 20:39):

But we should then probably also document our deviation on https://confluence.hl7.org/display/FHIR/NPM+Package+Specification

I think it should be a separate page. I'll add a page for the package server documentation

Grahame Grieve (Feb 20 2020 at 20:40):

Our tools do not support this within one package version

Well, you'll have to, because that's coming. but irrespective of your tooling limitation, the API can't be limited like that

Grahame Grieve (Feb 20 2020 at 20:40):

We also think it's undesirable within one package version

I don't like it either, but that doesn't make it something that goes away

Grahame Grieve (Feb 20 2020 at 20:42):

The package spec also states: "So this should only be seen in old balloted packages".

where's that? I can't find it.

But what will only be seen in is FHIR Versions that aren't in the enumeration

Grahame Grieve (Feb 20 2020 at 20:42):

Stick with application/tar+gzip?

yes

Ward Weistra (Feb 24 2020 at 14:39):

Grahame Grieve said:

No, without the version parameter it just returns one entry for each package entity

but it includes Description and FHIRVersion, which are Package version specific. So what are these other than the latest version?

Fair point, I'll check

Ward Weistra (Feb 24 2020 at 14:43):

Grahame Grieve said:

Which URL would you like? self url for the query you've done? Or url per package/package version?

Url per package version

OK, but low priority. As said this can be easily constructed: <package endpoint>/<package name>/<package version>

Ward Weistra (Feb 24 2020 at 14:47):

Grahame Grieve said:

Well, that's what the default of prerelease=false is for.

I don't see how prerelease=false makes any difference to that query

prerelease=false excludes all package versions where the user has indicated it's not ready for the public. If they don't indicate that correctly we could possibly educate better what the impact of that is, but I think we'll have to accept there will be different types of packages in there and work on ways of surfacing the best. We can't vet every package of an open community other than on technical correctness.

Ward Weistra (Feb 24 2020 at 14:54):

Grahame Grieve said:

But we'd be OK with adding/deviating.

great. I'm ok to add extra stuff as a deviation. And it turns out I can't function with Url in there

I assume you mean without instead of with. Can't you build it by the above convention?

Ward Weistra (Feb 24 2020 at 15:07):

Grahame Grieve said:

The package spec also states: "So this should only be seen in old balloted packages".

where's that? I can't find it.

But what will only be seen in is FHIR Versions that aren't in the enumeration

Well, seems I got that from the old https://wiki.hl7.org/FHIR_NPM_Package_Spec#Package_manifest.
But that came from an edit of yours that never made it to Confluence since it was done after migration: https://wiki.hl7.org/w/index.php?title=FHIR_NPM_Package_Spec&type=revision&diff=166860&oldid=166839.
fhirVersions parameter didn't make it to https://confluence.hl7.org/display/FHIR/NPM+Package+Specification#NPMPackageSpecification-Packagemanifest at all.

Can you elaborate on in what case this will appear? When a user started building on a pre-release version of the FHIR spec (eg 4.3) that, before the user published the package (because packages can't be changed after), was officially approved as being the new stable release of the FHIR spec (eg 5.0)?

Grahame Grieve (Feb 24 2020 at 19:39):

this can be easily constructed

yes. I'll do that

Grahame Grieve (Feb 24 2020 at 19:41):

I assume you mean without instead of with

yes, you're right

Grahame Grieve (Feb 24 2020 at 19:46):

but in fact, what I can't live without is the canonical URL (not the package download URL)

Grahame Grieve (Feb 24 2020 at 19:46):

got that from the old https://wiki.hl7.org/FHIR_NPM_Package_Spec#Package_manifest.

oops. I hope I haven't done that much.

Grahame Grieve (Feb 24 2020 at 19:52):

but you're conflating 2 issues. fhirVersions does explicitly allow for multiple versions, but it is not the only way for multiple versions to appear

Grahame Grieve (Feb 24 2020 at 19:55):

fhirVersions will appear when the package is not based on any maintained version of the spec - so the pre-release versions e.g. 4.2.0 (current r5 candidate) if an IG is published based on that

Grahame Grieve (Feb 24 2020 at 19:55):

multiple versions is planned for the future, and will be possible whether fhirVersions is populated or not

Grahame Grieve (Feb 24 2020 at 19:55):

"dependencies": {
    "hl7.fhir.r3.core": "3.0.2",
    "hl7.fhir.r4.core": "4.0.1"
 },

Ward Weistra (Feb 25 2020 at 12:36):

OK thanks, so fhirVersions in the package manifest is optional and only filled when a package depends on a non-final FHIR spec version which doesn't have a package. Normally the FHIR Version(s) are derived from the dependencies on core packages.
Why is this dependency on multiple FHIR Core versions going to happen in the future? Shouldn't these project/IG/package maintainers just maintain both a non-deprecated r3 and r4 version of their project/IG/package side-by-side, rather than rolling them into one?

Grahame Grieve (Feb 25 2020 at 19:41):

we had a discussion in the lead up to publishing R4 when we changed ImplementationGuide.fhirVersion cardinality from 1..1 to 1..*. A typical IG contains a great deal of content that is the same for both versions (and the % will increase over time). Consensus in the room was that implementers might want to maintain both a non-deprecated r3 and r4 version of their project/IG/package side-by-side but there were real advantages to having a single IG

Grahame Grieve (Feb 25 2020 at 19:41):

but the tooling doesn't support it yet

Lloyd McKenzie (Feb 25 2020 at 20:58):

The problem is we often have URLs that point to stuff inside a file - and the syntax for that uses '#'

Chris Moesel (Feb 25 2020 at 21:07):

(deleted)

Ward Weistra (Feb 26 2020 at 09:51):

Lloyd McKenzie said:

The problem is we often have URLs that point to stuff inside a file - and the syntax for that uses '#'

You probably meant that to go here: https://chat.fhir.org/#narrow/stream/179239-tooling/topic/Supporting.20resource.20instance.20versions

Ward Weistra (Feb 26 2020 at 10:13):

Grahame Grieve said:

we had a discussion in the lead up to publishing R4 when we changed ImplementationGuide.fhirVersion cardinality from 1..1 to 1..*. A typical IG contains a great deal of content that is the same for both versions (and the % will increase over time). Consensus in the room was that implementers might want to maintain both a non-deprecated r3 and r4 version of their project/IG/package side-by-side but there were real advantages to having a single IG

OK thanks for the background. I wonder what those advantages were and if they warrant the added complexity. It feels like a software project depending on multiple versions of a language/framework, which seems like a recipe for disaster and hard to support in tooling.
But perhaps we can nonetheless index it in Elastic, when time comes, and show it in the API.

Grahame Grieve (Feb 26 2020 at 11:28):

well, it's a case of moving the deck chairs around

Chris Moesel (Feb 26 2020 at 14:58):

I share @Ward Weistra's concerns about supporting multiple versions of the same conformance resources in a single IG. I expect it will introduce a lot of complexity. That said, just so I understand the scope of the proposed capability -- would this still only allow a single version of a resource per FHIR version, or would it also allow multiple versions within the same FHIR version (e.g., support MyR4PatientProfile version 1.0.0 and MyR4PatientProfile version 2.0.0 in the same package)?

Grahame Grieve (Feb 26 2020 at 17:21):

it depends. Some examples might be applicable to multiple versions. Terminology resources probably will be. But profiles won't be. The point is that there is that complexity already

Martijn Harthoorn (Mar 06 2020 at 13:31):

Grahame, the package server reports these issues with the feed:
feed item hl7.fhir.us.Davinci-drug-formulary-0.2.0 is actually version 0.1.0, which was already on the server.

Martijn Harthoorn (Mar 06 2020 at 13:31):

feed item hl7.fhir.us.qicore-3.0.1 is actually version 2.0.0 (according to package.json) and is already on the server.

Martijn Harthoorn (Mar 06 2020 at 14:06):

feed item hl7.fhir.uv.bulkdata-0.1.0, contains a packages with the name 'hl7.fhir.us.bulkdata'

Grahame Grieve (Mar 06 2020 at 21:03):

feed item hl7.fhir.us.Davinci-drug-formulary-0.2.0 is actually version 0.1.0

crap. that's a manual error by Lynn

Grahame Grieve (Mar 12 2020 at 03:54):

that should be sorted

Martijn Harthoorn (May 25 2020 at 07:42):

Grahame, some feedback from the package importer:

• listed package hl7.fhir.us.dme-orders-0.1.1, actually contains version 0.1.0
• listed package hl7.fhir.us.qicore-3.0.1 is actually version 2.0.0
• listed package hl7.fhir.uv.bulkdata-0.1.0 is actually hl7.fhir.us.bulkdata-0.1.0

Grahame Grieve (May 25 2020 at 07:43):

I

Grahame Grieve (May 25 2020 at 07:43):

I'll look at it

Martijn Harthoorn (May 25 2020 at 07:47):

And this package: hl7.fhir.us.dme-orders-0.1.0 refers to hl7.fhir.us.core-current. That is not a thing afaik.

Grahame Grieve (Jun 07 2020 at 21:20):

ok fixed

Martijn Harthoorn (Jun 09 2020 at 08:41):

this package is listed as hl7.fhir.us.dme-orders 0.1.1, but contains 0.1.0.

Grahame Grieve (Jun 09 2020 at 11:10):

I thought I fixed this yesterday

Martijn Harthoorn (Sep 10 2020 at 10:03):

There is still one package in the HL7 feed, that is listed as hl7.fhir.uv.bulkdata-0.1.0, but the package manifest claims hl7.fhir.us.bulkdata
The problem being: uv -- us

Grahame Grieve (Sep 10 2020 at 11:12):

where is it listed as uv.bulkdata?

Martijn Harthoorn (Sep 10 2020 at 11:33):

http://hl7.org/fhir/package-feed.xml

Martijn Harthoorn (Sep 10 2020 at 11:34):

<item>
<title>hl7.fhir.uv.bulkdata#0.1.0</title>

<link>http://hl7.org/fhir/us/bulkdata/2019May/package.tgz</link>

Grahame Grieve (Sep 10 2020 at 16:38):

oh. hmm.

Grahame Grieve (Sep 14 2020 at 03:13):

ok fixed.

Ward Weistra (Sep 14 2020 at 13:56):

@Grahame Grieve @Martijn Harthoorn Starter for the call on how to put jurisdiction in package manifest. My proposal:

• Add an optional (cause currently not filled) jurisdiction value to package manifest with value as 2-letter country code from ISO 3166 or UV for universal.

Ward Weistra (Sep 14 2020 at 14:04):

Ah, Grahame, you already created FHIR#28342

Ward Weistra (Sep 15 2020 at 07:52):

@Grahame Grieve Now that ticket has been Resolved, can you help on good example values for jurisdiction?

• urn:iso:std:iso:3166#US (from us.core)
• What would the core FHIR packages have? ?#UV?
• Any other exotic examples?

This will allow us to put some test data in an index to develop the UI, since getting the real data exposed will not be on time for that.

Ward Weistra (Sep 15 2020 at 16:00):

We'd also need a full list of all possible values with mapping to human readable names. Any thoughts how to get that?

Vassil Peytchev (Sep 15 2020 at 16:11):

https://en.wikipedia.org/wiki/ISO_3166-2 ?

Grahame Grieve (Sep 16 2020 at 04:28):

This should do for a list:

Grahame Grieve (Sep 16 2020 at 04:31):

ValueSet-jurisdiction-common.json

Grahame Grieve (Sep 16 2020 at 04:31):

here's an example package.json:

Grahame Grieve (Sep 16 2020 at 04:32):

{
  "tools-version": 3,
  "type": "fhir.ig",
  "license": "CC0-1.0",
  "author": "FHIR Project",
  "version": "1.0.0",
  "name": "hl7.fhir.uv.smart-app-launch",
  "url": "http://hl7.org/fhir/smart-app-launch/1.0.0",
  "canonical": "http://hl7.org/fhir/smart-app-launch",
  "dependencies": {
    "hl7.fhir.r4.core": "4.0.1"
  },
  "fhirVersions": [
    "4.0.0"
  ],
  "jurisdiction": "http://unstats.un.org/unsd/methods/m49/m49.htm#001"
}

Ward Weistra (Sep 16 2020 at 20:09):

Thanks @Grahame Grieve, that will work!

Ward Weistra (Jun 18 2021 at 12:06):

@Grahame Grieve A questions on the precise codes for jurisdiction:

• Above you suggest to use http://hl7.org/fhir/ValueSet/jurisdiction-common, which I documented here: https://confluence.hl7.org/pages/viewpage.action?pageId=35718629#NPMPackageSpecification-Packagemanifest (to apply FHIR#28342)
• However, ImplementationGuide.jurisdiction uses http://hl7.org/fhir/ValueSet/jurisdiction and is even Extensible. Under https://confluence.hl7.org/pages/viewpage.action?pageId=35718629#NPMPackageSpecification-PackageManifestpropertiesforIGs I, for now, added that these values need to align but clearly that won't be possible in all cases. Should we add that if the code is not in http://hl7.org/fhir/ValueSet/jurisdiction-common they should either change it, map it or leave the package jurisdiction empty?

Ward Weistra (Jun 18 2021 at 13:12):

Also, can you confirm you have added jurisdiction to the package.json for every previously published package where you want it, for the one-time exception to reindex those?
(and of course the process in place to add them to new ones)

Grahame Grieve (Jun 19 2021 at 20:34):

since http://hl7.org/fhir/ValueSet/jurisdiction-common doesn't exist, I can only imagine I meant http://hl7.org/fhir/ValueSet/jurisdiction

Grahame Grieve (Jun 19 2021 at 20:34):

ignore any value not in http://hl7.org/fhir/ValueSet/jurisdiction

Grahame Grieve (Jun 19 2021 at 20:37):

yes, Hl7 guides do:

"jurisdiction": "urn:iso:std:iso:3166#US"

Other guides may, if the jurisdiction is declared in the implementation guide

Ward Weistra (Jun 21 2021 at 16:38):

@Grahame Grieve It does exist: https://registry.fhir.org/results?query=%22http%3A%2F%2Fhl7.org%2Ffhir%2FValueSet%2Fjurisdiction-common%22&latestFilter=true

Grahame Grieve (Jun 21 2021 at 19:15):

ok I didn't know about that. Sure, you can use that one - ignore any code not in the common jurisdictions

Ward Weistra (Jun 22 2021 at 16:15):

@Grahame Grieve Perfect, thanks! (And: nice tool, huh, that registry.fhir.org :wink: )

Ward Weistra (Jun 22 2021 at 16:18):

Added: https://confluence.hl7.org/pages/diffpagesbyversion.action?pageId=35718629&selectedPageVersions=10&selectedPageVersions=11

Last updated: Apr 12 2022 at 19:14 UTC