Stream: implementers
Topic: CapabilityStatement representing multiple software products
Cooper Thompson (Oct 05 2020 at 14:38):
We've gotten the request to align our CapabilityStatement.software.name values with the products listed in the CHPL. Our issue is that we have one CapabilityStatement (i.e. one FHIR server) for our entire suite of products, and CapabilityStatement.software is 0..1. I submitted FHIR#28909 to open up that cardinality, but I was wondering if folks had other options. @Brett Marquard @Eric Haas Would a US Core extension be an option? This isn't required for certification, but it sounds like it could be useful until R5 (assuming we open up the cardinality on software).
Lloyd McKenzie (Oct 05 2020 at 14:49):
The name is a string - if you want to say "All xxx products", you can
Cooper Thompson (Oct 05 2020 at 15:41):
For CHPL matching, we'd probably need a delimited string. So yeah, we could comma delimit it, but... gross. The request we got was basically to use CapabilityStatement.software for discrete matching against another (non-FHIR) system where the composite "identifier" is the product name and version.
Lloyd McKenzie (Oct 05 2020 at 16:13):
CapabilityStatement.software isn't expected to be computable. The intention is to use it to advertise the capabilities of a shrink-wrapped product. The typical situation certainly isn't that multiple products are guaranteed to share the exact same behavior. And if they did, they'd presumably still each host their own statement. So I don't see shifting the cardinality as a likely thing.
Eric Haas (Oct 05 2020 at 17:55):
if you want an extension log a tracker, I have not used Capstatements for defining software requirments so I can't really comment on the issue.
Brett Marquard (Oct 05 2020 at 17:57):
I bet Cooper's situation of a single FHIR server (one CapabilityStatement) covering multiple 'shrink-wrapped' products is quite common. Call it a multi pack'. Extension on us core is fine for now.
Cooper Thompson (Oct 05 2020 at 19:26):
@Lloyd McKenzie I think the problem is defining what exactly a software product is. The CapabilityStatement currently seems to think that the overall EHR is the product (using EHR as an example). However within an EHR there are multiple sub-products like scheduling, billing, inpatient, outpatient, etc.). Some product listings track at the sub-product level (specifically, the ONC's CHPL).
I'm fine with a US Core extension for now, but I do think loosening the cardinality on CapabilityStatement.software is a good thing to consider, as it enables representing the different real-world scenarios.
Also, to my knowledge we don't use shrink-wrap for our products. It's mostly electronic delivery these days.
Cooper Thompson (Oct 05 2020 at 19:37):
I created FHIR#28935 for the US Core extension.
Matt Mayer (Oct 06 2020 at 12:50):
I assume that the pattern of having multiple software products represented by a single endpoint is going to be quite common. Do the CapabilityStatement.instantiates and/or CapabilityStatement.imports fields already cover this problem?
Lloyd McKenzie (Oct 06 2020 at 14:34):
If you're talking about a specific endpoint, then you're generally not using 'software' at all.
Cooper Thompson (Oct 06 2020 at 14:53):
@Lloyd McKenzie I don't follow your comment about not using software on a specific endpoint. Can you elaborate?
Lloyd McKenzie (Oct 06 2020 at 15:29):
If you're talking about a specific endpoint, then you'll have CapabilityStatement.implementation. While you're allowed to also include CapabilityStatement.software, it's not necessary. CapabilityStatement.software is primarily used when CapabilityStatement.kind is 'capability', not 'instance'.
Cooper Thompson (Oct 07 2020 at 20:11):
CapabilityStatement.implementation is also all 0..1, so it also doesn't let you specify that your FHIR Server implementation is serving data from multiple products. But I think software makes more sense than implementation for what we are trying to express. The software would be (name = Epic Inpatient, version = May 2020) and (name = Epic Outpatient, version = May 2020) (since the implementation covers both products), and the implementation would be (description = instance of Epic software deployed at Healthcare System A). Since the single implementation supports two software products, software needs to be 0..*.
Cooper Thompson (Oct 25 2021 at 13:21):
For FHIR#28909, were there reasons other than making a normative change that FHIR-I had for rejecting the change? The recommendation was to make a standard extension, which seems like a bad precedent. "Replacing" fields with an extension if we don't want to make improvements to normative content seems like a slippery slope that could lead to a future state where we just use extensions for everything and ignore the base (effectively deprecated) base resource properties (I'm exaggerating for effect).
Lloyd McKenzie (Oct 25 2021 at 14:15):
Locking into backward-compatibility has benefits and draw-backs. FMG is looking at how we can minimize the circumstances like this (non-repeating element turns out to need repetitions) going forward. However, there's not much we can do about resources that are already normative.
Last updated: Apr 12 2022 at 19:14 UTC
