Stream: SDPi+FHIR
Topic: Participant Model
Scott Gearhart (Jun 18 2020 at 15:56):
@Stefan Schlichting @Todd Cooper In comparing the classical DIM (10201) with the BICEPs Participant model (10207), the latter includes RealTimeSampleArray and DistributionSampleArray objects but omits other sample array types included in the DIM, such as the SampleArray and TimeSampleArray objects. Can you explain why? Can all pertinent types of waveform data be represented with the reduced set of Participant model sample array objects (e. g., 12 lead ECG and pressure volume loops)? Thanks
Scott Gearhart (Jun 18 2020 at 16:07):
@Stefan Schlichting @Todd Cooper @Tobias Klotz @David Gregorczyk In our study of the MDIB versioning methodology in 10207 it seems the approach allows for version numbers at every level of element in the MDIB containment tree and there could be multiple version attributes included in every update. If a device communicates every state change of its MDIB to other components within the ICE, it seems like this could potentially create significant additional data to be transmitted and network communications may be overly loaded - particularly if there are relatively many devices on the network. Is there something we are not understanding correctly in this regard. Thanks
Scott Gearhart (Jun 18 2020 at 16:12):
@Stefan Schlichting @Todd Cooper @Tobias Klotz @David Gregorczyk How would the participant model represent data from imaging devices e.g., standard video or ultrasound data?
Stefan Schlichting (Jun 18 2020 at 16:12):
Scott Gearhart said:
Stefan Schlichting Todd Cooper In comparing the classical DIM (10201) with the BICEPs Participant model (10207), the latter includes RealTimeSampleArray and DistributionSampleArray objects but omits other sample array types included in the DIM, such as the SampleArray and TimeSampleArray objects. Can you explain why? Can all pertinent types of waveform data be represented with the reduced set of Participant model sample array objects (e. g., 12 lead ECG and pressure volume loops)? Thanks
Hi Scott, from my perspective all sample array data can be represented. To touch upon your example, the 12 leads of an ECG would be captured as individual RTSA. Pressure volume loops are a UI thing displaying both RTSA using annotations on the inflection points.
Scott Gearhart (Jun 18 2020 at 16:16):
Copy that Stefan - thanks for quick reponse
Stefan Schlichting (Jun 18 2020 at 16:21):
Scott Gearhart said:
Stefan Schlichting Todd Cooper Tobias Klotz David Gregorczyk In our study of the MDIB versioning methodology in 10207 it seems the approach allows for version numbers at every level of element in the MDIB containment tree and there could be multiple version attributes included in every update. If a device communicates every state change of its MDIB to other components within the ICE, it seems like this could potentially create significant additional data to be transmitted and network communications may be overly loaded - particularly if there are relatively many devices on the network. Is there something we are not understanding correctly in this regard. Thanks
You did understand everything correct, there will be a message for every mdib version change, but in order to lower the number of messages send a provider typically updates typically multiple containment tree elements in parallel so that multiple changes to the MDIB result only in one MDIB version number increment and hence one message.
For example, if 50 measurements are updated, there will be 50 state versions of the metrics updated, but the mdib version will be updated only by 1.
Scott Gearhart (Jun 18 2020 at 16:52):
This seems reasonable Stefan. I'll give your response some thought and get back to you if I have other questions. Thanks
Scott Gearhart (Jun 18 2020 at 16:53):
@Jan Rizzuto Jan - see Stefan's responses above
Todd Cooper (Jun 19 2020 at 00:55):
And this is something that we can "profile" in SDPi, and test at connectathons. FWIW - I have heard the same complaint about FHIR being "chatty" ... but similarly - there are poor implementations and fantastic implementations. We'll do our best to encourage the latter!
Last updated: Apr 12 2022 at 19:14 UTC
