Stream: fmg
Topic: Device Naming Challenge
Hans Buitendijk (Jun 28 2018 at 19:24):
I caught up on yesterday's FMG minutes on DeviceDefinition Resource Proposal. Generally understood on the need to further explore relationship with other definitions (substance/medication), but that raises a challenging progression from the current Device to where we want to end up.
Currently we have one resource, Device, that covers both the "instance" and "kind" aspect. During OO/HCD discussions the conclusion was to split that and as part of that the desired naming is DeviceDefinition and Device. That would mean that the current Device would scoped down to just focus on the "instance" aspect, including removal of certain data elements that only make sense as part of DeviceDefinition.
If we need to wait until we have clarity on relationship between DeviceDefinition and other definitions that may yield some other overarching construct (not just a common pattern), then we cannot accommodate use of current Device in "kind" mood/mode.
Additionally, if we need to preserve current Device until that is sorted out, how do we go about naming during the transition?
- Rename current Device to "DeviceOld" or "GeneralDevice" and introduce the new DeviceDefinition and Device resources as intended.
- Revisit renaming Device so we introduce DeviceDefinition and DeviceInstance, and then deprecate current Device when sufficiently equivalent.
- Start with DeviceDefinition until settled, then rescope Device.
Using a name other than "Device" for the final resource for the instance representation is not desirable and inconsistent (e.g., Specimen, SpecimenDefinition, Observation, ObservationDefinition).
Thoughts on how best to progress this change, starting with R4?
Lloyd McKenzie (Jun 28 2018 at 19:33):
That wasn't our understanding. We thought DeviceDefinition was equivalent to MedicationKnowledge. I'm not thrilled with the notion of spliting instance and kind because I don't think a lot of systems make that split. Have you confirmed that all implementers can handle distinguishing between the two? Is there a need beyond modeling purity to make the change?
Brian Postlethwaite (Jun 28 2018 at 21:04):
And while doing that review, check if resources that reference device will also need to reference DeviceDefinition too.
e.g. Reference(Device), Reference(DeviceDefinition), Reference(Device|DeviceDefinition)
Hans Buitendijk (Jun 28 2018 at 21:10):
Actually, between OO and HCD the feedback is that separating makes sense. Hence the motions and acceptance of those.
Yes, Device would need Reference(DeviceDefinition). Other resources may just need Reference(Device), others may need Reference(DeviceDefinition), while some may need Reference(Device|Definition).
Regarding Lloyd's comment, are you suggesting to collapse all resources that have a split of definition vs. instance and use some other indication to understand which one it is?
Brian Postlethwaite (Jun 28 2018 at 21:19):
Thanks for confirming that Hans, exactly what I meant.
Lloyd McKenzie (Jun 29 2018 at 06:00):
Definition and Event are clearly managed separately by most systems. For instance vs. kind, the boundary isn't nearly as clear. A system might just capture "kind" information and 30 seconds later do an update that adds "lot" or even "serial number" which suddenly transitions the "kind" into an "instance" - which is easy to do if they're the same resource but very difficult if they're different resources.
Lloyd McKenzie (Jun 29 2018 at 06:01):
What was the implementation driver for the split? I.e. How does splitting the resource make things easier for implementers or address implementation issues?
Hans Buitendijk (Jun 29 2018 at 16:06):
What do you see as the difference between Definition and Event vs. Instance and Kind? What is really the conceptual difference other than an apparent labeling? I never understood this instance vs. kind labeling as I can understand an instance of a resource (definition, request, event, etc.), but in the other context, an instance (physical presence) or event (it actually happening) is effectively the same: it's there. either one can be vague (only information on kind, vague recollection of date/time) or precise (serial number, actual date/times). If you know you had a physical about a year ago, we record an observation with somewhat vague information, yet still can refer to ObservationDefinition. So really consider what really the difference is between ObservationDefinition vs. Observation, SpecimenDefinition vs. Specimen, PlanDefinition vs. Care Plan (as one instantiation of that), etc. DeviceDefinition vs. Device is no different. There is certain use cases that are driven based on SpecimenDefinition (e.g., ordering tests that need to understand what/how/etc. to collect in the way of a specimen). As one gets to know more about the event/instance, data can be added/refined, but that does not require it to start as a kind/definition.
Lloyd McKenzie (Jun 29 2018 at 16:53):
Act definitions (protocols, order sets, etc.) are always maintained and persisted completely separately from events (actual encounters, observations, medication administrations, etc.). On the other hand systems that deal with orders frequently don't distinguish between "kinds" of entities and instances of them. So the question is why we're splitting the resource. If it's driven by implementer requirement (and we're confident that the vast majority of implementers won't have an issue with the split), that's ok. But I'm not clear what the requirement is. But we shouldn't do it for reasons of modeling purity.
Hans Buitendijk (Jun 29 2018 at 21:16):
So when you do catalog maintenance, LIVD, orderable items, you would not persist DeviceDefinitions? Since when? That happens all the time, all over. If everything is part of a combined Device, you'll have to figure out what really are the definitions, and what are the real (as fuzzy as they may be) devices. That's not a modeling purity issue.
Lloyd McKenzie (Jun 30 2018 at 02:14):
You'll certainly capture "types" of devices as well as physical instances - but systems often group them together. Some things will have lot and serial number, others won't. There's a separate thing which is the "device knowledge" resource - it represents the full details about the design of the resource, what it's intended for/allowed for, regulatory rules, etc.
Hans Buitendijk (Jul 02 2018 at 18:03):
I believe we then are very inconsistent as XYZDefinition and XYZKnowledge are seemingly used interchangeable. If you can clarify the intended distinction as to when to use one or the other, that perhaps can clarify whether we actually should be using DeviceKnowledge, and perhaps need to change ObsevationDefinition, PlanDefinition, SpecimenDefinition and others to ObservationKnowledge, PlanKnowledge, and SpecimenKnowledge, as it surely starts to sound like that when stating "full details about the design of the resource, what it's intended for/allowed for, regulatory rules, etc." In the process, the difference between instance, kind, definition, knowledge would help since they are being mixed, yet by some to be four different concepts.
Lloyd McKenzie (Jul 02 2018 at 18:12):
On the "action" side of things, we have Definition, Request and Event. (Things that map to Act in the RIM). On the 'Entity' side (meds, devices, specimens, substances) we typically just have a single resource that covers both instance and kind and reflects what's captured and shared during the day-to-day use of the entity. We're starting to introduce "knowledge" resources that provide formal definitions, regulatory aspects, indications & contraindications, associated processes, etc. Of course, at the moment we have 5-6 resources that compose the Medication "knowledge" side and some harmonization/collapsing seems likely to occur. We also have SpecimenDefinition where it's not clear whether it's trying to cover the "knowledge" side of things or it's just trying to split the "instance" from the "kind" in the day-to-day representation of Specimen.
Last updated: Apr 12 2022 at 19:14 UTC
