Date: June 12, 2018
Jose Costa Teixeira
Co-Chair: Hans Buitendijk
Scribe: Hans Buitendijk
- Agenda Review
- Cologne Summary
- We used the attached slides to summarize discussion in Cologne leading to today's decision.
- Device Kind vs. Instance
- There are primary ways to proceed with Device resource:
- Option One - Leave it as one resource and profile Kind and Instance for specific use cases.
- Option Two - Split the resource in two to recognize the variances, while still referencing Kind from Instance
- Slides referenced:
- Slide 3 highlights the perspective that leans towards Option One as much of the data for an Instance would actually be data on the Kind. It would be very easy to understand that Type on the diagram clearly would be Kind, and Identifier would clearly be Instance, but where you do draw the line if you want to separate? Profiles can focus on Kind vs. Instance focused data needs.
- Slide 4 suggests where to draw that line when you separate the resources, where Slide 5 highlights the basic structure.
- From the Cologne discussion there were some questions on how to point to a "fuzzy" Device Kind when you know the type, could perhaps describe it, but don't know the actual Device Kind. Thus a DeviceInstance may have either a clear DeviceKind reference, or have a more descriptive reference. It is not clear whether that is actually needed there, or just on the Observation/Procedure/etc. when there is a need to know about a DeviceInstance. That remains TBD.
- Slide 7 highlights the various data examples that would be on one vs. other.
- It must be clear that the current Device attribute list would not be sufficient to address all use cases around devices. E.g., sterilization requirements (on Kind) and actual sterilization records (on Instance) are currently not included. However, this concern is independent of splitting/combining.
- Slide 6 highlights that when Kind is separated from Instance, that as there are multiple instances of Instance, only one Kind instance is need (assuming all share the same DeviceKind ofcourse). If Kind and Instance would be combined, then effectively for every instance all the applicable Kind data would be replicated onto each instance.
- It was noted that in the case of a typical HPD use case, there only would be one Instance with Kind, so it would be unnecessary overhead to have two resources to represent that.
- But in other use cases the data duplication would be a concern. Parallel examples of specimen containers were used that demonstrated that typically when one manages one definition and multiple instances against that definition that combining them causes challenges.
- Motion to separate Device into DeviceKind and DeviceInstance. Kathy Walsh, Jose Costa Teixeira
- Proposal by Brian Reinhold that there should not be duplicate attributes between the two resources, other than the reference.
- Kathy did not accept that proposal and rather discusses that separately. While there is general interest to only have a reference, want to run through the data specifically to make sure there is nothing left that should be duplicated.
- Against: 0; Abstain: 6; In Favor: 5
- Next Steps
- We will schedule 1-2 more meetings (Hans, Chris, John) to define the attribute list for either resource based on what is currently in the Device resource.