Publishable write

[lmd59]

Summary

Implement/ensure publishable artifact repository minimum write capabilities (Publish, Retire, Archive) as defined in the CRMI IG here.

New behavior

• Checks conditions for create/update to ensure the data matches the requirements for publish/submit and retire/revise capabilities in the spec.
• Adds delete operation and checks conditions for archive/withdraw capabilities in the spec
• Adds a transaction bundle script that coerces the resource statuses to active before posting the bundle to the server

Code changes

• Adds an AUTHORING environment variable to toggle between an authoring and publishable artifact repository
• Updates the README CRUD section
• Adds the db:postBundle script for a POST transaction bundle upload option, and refactors dbSetup.ts to share functionality so that the db:postBundle script can work similarly to the db:loadBundle script.
  • Does some refactoring of the use of the DetailedEntry type for this
• Updates capability statement to show delete archive/withdraw capabilities
  • Capability statement updates taken from: https://build.fhir.org/ig/HL7/crmi-ig/CapabilityStatement-crmi-authoring-artifact-repository.json.html
  • Question: This capability statement is currently an authoring definition. Should we have the capability statement change based on the AUTHORING environment variable?
• Adds db operation and server endpoint for DELETE operations for both LibraryService and MeasureService
• Updates BaseService to enforce spec requirements on transaction bundle entries
• Adds checkFieldsFor* check functions to inputUtils to enforce spec requirements
  • Question: The spec states for retire "The artifact must be in active status and update is only allowed to change the status to retired and update the date (and other metadata appropriate to indicate retired status)." Is there any other metadata we should allow to update for the retire functionality?
  • Adds and updates tests for BaseService (transaction bundle handling), LibraryService, and MeasureService

Testing guidance

• npm run check
• Set the AUTHORING environment variable to false in your local .env file to test publishable-limited capabilities.
• npm run start:service
• Run db:postBundle, example npm run db:postBundle {bundle path}
  • Default assumes that the server is running on http://localhost:3000/4_0_1, or you can specify a server path as an additional argument on the end
• Test out the capabilities and limitations listed in the README for the publishable repository server (and authoring if it makes sense) using Insomnia
  • Can see added jest tests for more specific examples of things to test

[elsaperelli]

I still need to test the CRUD operations, but I am finding a potential issue with the postBundle functionality. When I do npm run db:postBundle {may-connectathon-2024 bundle directory}, it seems to upload significantly less Libraries than when I use our old ./directory-upload script (83 vs. around 400 Libraries). I am pretty sure we want around 400 Libraries because of the whole "child artifacts do not have a lifecycle outside of their parents" specification.

[lmd59]

https://hl7.org/fhir/uv/crmi/artifact-lifecycle.html#artifact-identity has a great rundown of artifact identity (thanks for sharing it @elsaperelli!)
This is making me think about how the distinctions between publish and retire should be applied (or other create vs update distinctions).

If we do a PUT to [url base]/id and something with that id already exists, then we currently enforce the retire checks. If not, it enforces the publish checks. But what if there's a FHIRHelpers version 1 and a user tries to publish a FHIRHelpers version 2 using PUT. These have different canonical identities because they have different versions, but they have the same id, so the server would end up running the retire checks. Should we allow a user to PUT to publish that version 2? The FHIR spec generally seems to allow PUTs for creates, so it feels like we should support that. But the /id path format implies checking of the id and not the canonical identifier.

[elsaperelli]

Some small comments and I noticed that the transaction bundle upload still isn't working correctly- looks like the Measures are not being uploaded because they have draft status. Do we want to coerce them to active like we do in dbSetup?

[elsaperelli]

I think some of these are reused, maybe define them at the top of this file like the others?

[lmd59]

Because artifacts must conform to the Shareable spec https://hl7.org/fhir/uv/crmi/StructureDefinition-crmi-shareablemeasure.html with url, version, description, and title at cardinality 1..1 for CRMIShareableMeasure and CRMIShareableLibrary...
Should our _elements implementation also be keeping those as required elements?

[elsaperelli]

Woo! Lgtm!