Activity for Peter Kranich
-
Peter Kranich modified a comment on ticket #206
So, there are the following situations with @ext:MustUnderstand and the consumer does not understand the extension: Situation | Parent | Child | Rule 1.) | false | false | consumer can use parent and child element 2.) | false | true | consumer can use parent but must ignore child element 3.) | true | false | consumer must ignore the parent and child element 4.) | true | true | consumer must ignore the parent and child element (same as 3.) If this is the correct interpretation of TR1342, I'm fine...
-
That clarifies it for me. Thanks!
-
So, there are the following situations with @ext:MustUnderstand and the consumer does not understand the extension: Situation Parent Child Rule 1.) false false consumer can use parent and child element 2.) false true consumer can use parent but must ignore child element 3.) true false consumer must ignore the parent and child element 4.) true true consumer must ignore the parent and child element (same as 3.) If this is the correct interpretation of TR1342, I'm fine with it.
-
Thanks for the change - that makes the statement much clearer.
-
Not clear what the individual purposes in the list mean
-
This is not what I meant with "Describe response from provider.". What I meant is shall the provider just reject the connection, or shall it allow the connection, return a meaningful error code and then close the connection.
-
Note that the pysiological range has no direct relationship to the alert range but can be used as a guideline for it. In my opinion, the reason for the physiological range is mainly for display purposes (e.g. inital scaling of a trend diagram). Since the physiological range is dependent on the patient category, I could imagine 2 options: 1.) the physiological range will automatically change when the patient category is changed at the device 2.) each metric has a list of physiological ranges - one...
-
IEEE 11073-10101 not referenced
-
Intended Use: Participant key purposes (3)
-
Intended Use: Participant key purposes (2)
-
Intended Use: Participant key purposes (1)
-
Typo: MEDCIAL IT-NETWORK
-
6.1.5 Ranges: clarification on Pre-Sets and Settings
-
TR0240: Ranges for Pre-Sets and Settings
-
Confused Support column with Status column
-
TR0257: not clear what ActivationDuration indicates?
-
How do indicate a stopped/interrupted measurement?
-
TR0239 this is a potential risk when not consider patient category
-
DeterminationPeriod only for waves?
-
Settings shall set DeterminationTime?
-
Confusing timestamp / mode / etc. requirements
-
Provide a DeterminationTime for Ongoing measurements?
-
Accuracy class of measurements
-
ConceptDescription for enumerated values
-
Risk of erroneous messages
-
When LifeTimePeriod is not set should Consumer consider risk?
-
Why is DeterminationTime not mandatory?
-
DeterminationTime property not part of the list
-
DeterminationTime should consider internal latency
-
Other means to validate device connection
-
Definition of appropriate use
-
List of supported certificate attributes/options
-
Definition of metric usage dependent on SafetyClassification
-
Change Disclaimer Wording
-
Localization of texts
-
Inconsistent use of @MustUnderstand
-
Definition of a ContextStateValidator
-
Required patient identifier up to the responsible organization
-
UDI on MDS level
-
Additional 11073 nomenclature standards
-
MDIB sequence relative order - why is this important?
-
UDI is not explained in the acronyms section
-
Which requirements must be listed?
-
What to do when exceeding the # of participant requests?
-
Time zone should be part of the log message entry
-
Log message requirements
-
Handling ambiguous location contexts
-
Differentiate between use model requirements and technical requriements
-
More information about inferred Participant Ensemble Context
-
Reference System: meaning of different SDC implementation
-
System clocks synchronized to commen time source
-
"Should" requirements only listed when implemented!?
-
Duplicate acronym "XML" w/ identical descriptions
1
Gen AI apps are built with MongoDB Atlas
Atlas offers built-in vector search and global availability across 125+ regions. Start building AI apps faster, all in one place.
Try Free →