Stream: implementers
Topic: Software as a Device
Jose Costa Teixeira (Mar 26 2019 at 20:38):
Is anyone using Device / DeviceDefinition to describe software or software components?
Grahame Grieve (Mar 26 2019 at 20:56):
I was at one stage, and would again if I was maintaining an app registry
Lloyd McKenzie (Mar 26 2019 at 21:02):
@Jose Costa Teixeira Did you mean DeviceDefinition? (Don't think we have DeviceInstance)
Jose Costa Teixeira (Mar 26 2019 at 21:22):
Yes, DeviceDefinition.
Jose Costa Teixeira (Mar 26 2019 at 21:26):
I presume that since DeviceDefinition is the definitional part, I would use DeviceDefinition to say "this is what my software does".
Is that also the right one to express IHE actors (systems that have a definition, must support a couple of transactions, ...)
Jose Costa Teixeira (Mar 26 2019 at 21:26):
is there no overlap with capabilityStatement (when used to express capability?) Just to make sure
Lloyd McKenzie (Mar 26 2019 at 21:41):
I don't have a strong feel for where/if DeviceDefinition will fit into the software space. CapabilityStatement is much more descriptive from a FHIR software perspective.
Jose Costa Teixeira (Mar 26 2019 at 21:55):
so if we want to define an IHE actor, seems we have 2 choices: either an actor is defined by a DeviceDefinition which is conformant to a CapabilityStatement, or the actor IS a CapabilityStatement. latter sounds better but i must play with it
John Moehrke (Mar 27 2019 at 13:02):
what is the value added by the DeviceDefinition there? Asked another way, What is missing in CapabilityStatement for describing an IHE Actor? I agree DeviceDefinition is needed to describe software, but an IHE Actor is an abstraction specific to Interoperability requirements. I think if we could identify the gap, it could be used to improve CapabilityStatement. Or where that gap is necessary functional or non-functional requirements we can define the tipping point for when a CapabilityStatement alone is not sufficient. Is that the thinking?
Lloyd McKenzie (Mar 27 2019 at 15:31):
It may be that CapabilityStatement should point to DeviceDefinition in place of the 'software' element to capture name, version, releaseDate. Though it turns out there's no home for releaseDate and the only extra stuff I see there that might be relevant are manufacturer and perhaps language.
John Moehrke (Mar 27 2019 at 15:46):
That is a use-case for CapabilityStatement for a kind of Instance or Capability. I think Jose is focused on "Requirements", which is the IHE-Actor form of CapabilityStatement. In this case it is an abstraction, not an instance or a functionally complete capability. Hence why I am wondering what is missing for an IHE-Actor when CapabilityStatement is kind of Requirements.
Lloyd McKenzie (Mar 27 2019 at 16:00):
Software isn't about an instance, it's about a "kind" of software. The typical description we've provided is "shrink-wrapped". Though I agree that wouldn't meet the need for a specification. I'm not sure it makes sense to use DeviceDefinition for something that, in EHR equivalant terms, would be like saying "I have a device that can measure systolic and diastolic blood pressure" without differentiating whether it's cuff-based, involves pressure sensors in the blood stream or uses some other totally different technology.
Jose Costa Teixeira (Mar 27 2019 at 18:00):
I want to make some sense of the possible overlap from the monday discussion.
If CapabilityStatement is ok for us to define a "thing" that has a series of functionalities, that is fine; if we need to consider extensions, that is also fine, and if we need to use DeviceDefinition (which is still Maturity 0), that would also work.
Jose Costa Teixeira (Mar 27 2019 at 18:05):
It may be that CapabilityStatement should point to DeviceDefinition in place of the 'software' element to capture name, version, releaseDate. Though it turns out there's no home for releaseDate and the only extra stuff I see there that might be relevant are manufacturer and perhaps language.
There's .version, which I'd say is more common/better than Release Date.
Brian Postlethwaite (Apr 03 2019 at 10:40):
There is also the Endpoint resource, which covers more than just FHIR systems, and also includes the usages of the system, not just the capabilities. e.g. Clinical record, Patient Administration Record, Client Portal, Radiology system, referrals triage, XDS Repository, HL7v2 gateway, DICOM-RS ...
Getting the granularity of that description will have to build over time, and don't know that this is in the Device/DeviceDefinition either.
Will be discussing some of this on the PA call today/tomorrow.
Jose Costa Teixeira (Apr 03 2019 at 11:22):
Ok so we have 3 options to select from.
Jose Costa Teixeira (Apr 03 2019 at 11:26):
endpoint seems interesting, not sure if it is a) an instance (e.g. this endpoint from this provider which conforms to an IHE profile), b) a definition (e.g. the IHE actor) or c) if that distinction matters.
Jose Costa Teixeira (Apr 03 2019 at 11:27):
@Brian Postlethwaite can you please post results you find interesting here? I will bring up any ideas to the workflow call next monday.
Brian Postlethwaite (Apr 03 2019 at 11:37):
This is an instance, its pointing at a real thing that you would be expected to access.
Its the directory entry that says that this origanization is exposing its v2 server here for example.
Jose Costa Teixeira (Apr 03 2019 at 11:37):
ok then it seems that we are down to 2 for defining an IHE actor
Jose Costa Teixeira (Apr 03 2019 at 11:41):
...for now :)
Last updated: Apr 12 2022 at 19:14 UTC
