PCD RTM 2008-12-03 WebEx: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
ToddCooper (talk | contribs)
m Updated minutes
Efurst (talk | contribs)
m Next Meeting: move to archive
 
(3 intermediate revisions by one other user not shown)
Line 76: Line 76:
| '''General Term Development Discussion''' <br>- Group
| '''General Term Development Discussion''' <br>- Group
| '''Status/Discussion:'''
| '''Status/Discussion:'''
        (Paul) group / focus on:   
:* Paul reiterated that the group should focus on (in priority order):  reported monitored parameters, reported settings ("read only configs"), Waves, ..., Alarms, Control parameters .  In other words, in order to make the problem set more tractable, the universe of possible parameters should be organized by application data type.
                          reported monitored parameters
:* The order/priority should be based on what clinicians want to see on their charts!
                          reported settings ("read only configs")
                          Waves
                          ...
                          Alarms
                          Control parameters  
                (IOW - break down by data type to make the problem more tractable)
                This order is based on what would a clinician want to see on a chart - as a first order priority
               
        Note:  "index" - better to add the arithmetic expression related to this or at least some of the key
                properties (e.g., "...per BSA")
        (Dain) Purpose of collecting the data...
                1) For the HIS/Charting
                2) Research purposes
                3) Forensics ("black box")
                ??? Is there a way of indicating the intended "purpose" of the parameter, e.g., by including "setting" / "monitor"
                          at the start of the term so that the goal can be quickly determined?
                Re. index formulae - this can be specified / formalized in the vent OR in an external information system.  Should
                          accommodate both.
        (Paul)
                Could combine Observation & Settings under the same set of yellow columns ... as a TYPE of data
                Could add discriminator re. the use of the parameter
                For indicies - maybe a reference to the liturature


        (Dain) Airway pressure - where measured?
:* NOTE: In the case of an "index", the underlying arithmetic expression or at least some of the key properties should be identified (e.g., "...per BSA"). This index formulae could be specified either in the device or an external information system. Both approaches should be supported.
                (Paul) indicate measurement site information
                          (Dain) is this the role of the device or the CIS?  (sometimes in machine / sometimes by clinician /
                                  sometimes by clinician entered into device...)
                (Ken) measurement method also important (optional attribution ... but should be available)
                (Jan) adding a methodological column would be very helpful (transductive <Functional> statistical)


        Rosetta (Paul)
:* Steven reiterated the need to focus on the '''''clinical purpose''''' for which the data is being collected.  For example,
                Add another column "RefID 2" as a working space
::: 1. For the HIS/Charting
                (Jan) take the key terms from the rosetta to identify what we should target as a first order priority
::: 2. Research purposes
::: 3. Forensics ("black box")


        Steve - What are clinicians actually recording on charts todayWe should factor in workflow as a key factor
:* Question:  Is there a way of indicating the intended "purpose" of the parameter (e.g., by including "setting", or "monitor" etc.)Is there a method for indicating the intented "purpose" of the parameter (e.g., by including "setting" / "monitor" at the start of the term so that the goal can be quickly determined?
                toward prioritization of what is supported.
::- (Paul) Could combine Observation & Settings under the same set of yellow columns ... as a TYPE of data; Could also add a discriminator regarding the use of the parameter.  For indicies - maybe a '''''reference to the liturature''''' where more complete documentation is available.
::- Also, episodic / "spot" measurements vs. continuous trend streams should also be captured along with the intended usage.
::- Question:  Why differentiate between episodic & continuous?  Paul:  the information is handled / communicated differently ... in other words, there are varying data handling / management issues that need to be addressed.


        <thc> How to capture & factor in workflow w.r.t. terminology
:* Question:  Airway pressure measurement site - how is this captured?
                Jan: Terminology vs. information model
::- (Paul) There are mechanisms to indicate measurement site information, both pre- & post-coordinated
                Todd: Heuristics re. when this clinical context information is folded into the term vs. in the info model?
::- (Dain) Is this the role of the device or the CIS?  (sometimes in machine / sometimes by clinician / sometimes by clinician entered into device...)
::- (Ken) measurement method also important (optional attribution ... but should be available)
::- (Jan) adding a methodological column would be very helpful (transductive <Functional> statistical)


        ["stat" - ??? <don't have a clue what Jan meant> ]
:* This usage characterization should be captured in the Rosetta.  Paul) Add another column "RefID 2" as a working space


        episodic / "spot" measurements vs. continuous trends - should also capture this class of numeric data (episodic & continuous)
:* Question:  How to document & derive terminology from clinical workflow?
 
::-  (Jan) Terminology vs. information model
        Why differentiate between episodic & continuous?  Paul:  the information is handled / communicated differently ... IOW
::- (Todd) We should capture heuristics regarding when this clinical context information is folded into the term vs. in the info model
                data handling / management


'''Decisions/Issues:'''
'''Decisions/Issues:'''


'''Action(s):'''
'''Action(s):'''
:* (Paul) Add another column "RefID 2" to provide for the HL7-mangled-RefID's (as a WIP space).


|-
|-
Line 134: Line 112:
| '''Planning Discussion''' <br>- Group
| '''Planning Discussion''' <br>- Group
| '''Status/Discussion:'''
| '''Status/Discussion:'''
        Focus on numeric parameters (esp. what is charted...)
:* There was a general discussion regarding the group's strategy for going forward.
        Complete core mindmap of semantic architecture
        Update table:
                Add functional discriminator column (e.g., energy per breath, indexed per BSA, body weight)
                IOW 5th row discriminators ... next set of columns (min / max / ...)
                Observation & Setting same YELLOW color
                Support "measurement site" (pre/post coordination)
                Add a "clinical" column
        Update RTM tables with "RefID 2" column + "measurement site" column


'''Decisions/Issues:'''
'''Decisions/Issues:'''
:* Complete core mindmap of semantic architecture
:* Focus on numeric parameters (esp. what is charted...) first
:* Update table:
:::- Add functional discriminator column (e.g., energy per breath, indexed per BSA, body weight)
:::- IOW 5th row discriminators ... next set of columns (min / max / ...)
:::- Observation & Setting same YELLOW color
:::- Support "measurement site" (pre/post coordination)
:::- Add a "clinical" column (what do clinicians need, intended usage of the term, etc.)
:* Update RTM tables with "RefID 2" column + "measurement site" column


'''Action(s):'''
'''Action(s):'''
Line 162: Line 141:




''(Reviewed & approved by PCD RTM Vent TG '''''<tbd>''''')">''
''(Reviewed & approved by PCD RTM Vent TG [[PCD_RTM_2008-12-17_WebEx | 2008-12-17]])''




[[Patient Care Device | PCD Home]]
[[Patient Care Device | PCD Home]]
[[Category:PCD Meeting]]
[[Category:PCD Meeting Archive]]

Latest revision as of 12:42, 28 April 2009

(Vent TG Main Page)

Meeting Purpose

IHE PCD Rosetta Terminology Mapping (RTM) Ventilator Task Group regular discussion meeting. See the Proposed Agenda below for specific topics.

WebEx Information

Topic: IHE PCD RTM Vent TG

Date: Wednesday, December 3, 2008

Time: 12:00 pm, Eastern Time (GMT -05:00, New York)

Duration: 120 Minutes


Note: Specific web & phone informaiton will be provided via e-mail to group members.

Contact Manny Furst for more information.

Proposed Agenda

(No advance agenda published)

Attachments / Materials

(no attachments)


Minutes

Participants

Chair/Host: Todd Cooper
Steven Dain, Robert Flanders, Brad Lunde, Ken Marks, John Rhoads, Paul Schluter, Jan Wittenber


Discussion

Item Topic Discussion
1 Introductions & Agenda Review
- Chair
Status/Discussion:
  • (No advance agenda published)

Decisions/Issues:

Action(s):

2 Approval of Minutes
- Chair
Status/Discussion:

Decisions/Issues:

Action(s):

3 Vent Term Model Review
- Jan Wittenber
Status/Discussion:

Decisions/Issues:

Action(s):

4 General Term Development Discussion
- Group
Status/Discussion:
  • Paul reiterated that the group should focus on (in priority order): reported monitored parameters, reported settings ("read only configs"), Waves, ..., Alarms, Control parameters . In other words, in order to make the problem set more tractable, the universe of possible parameters should be organized by application data type.
  • The order/priority should be based on what clinicians want to see on their charts!
  • NOTE: In the case of an "index", the underlying arithmetic expression or at least some of the key properties should be identified (e.g., "...per BSA"). This index formulae could be specified either in the device or an external information system. Both approaches should be supported.
  • Steven reiterated the need to focus on the clinical purpose for which the data is being collected. For example,
1. For the HIS/Charting
2. Research purposes
3. Forensics ("black box")
  • Question: Is there a way of indicating the intended "purpose" of the parameter (e.g., by including "setting", or "monitor" etc.)? Is there a method for indicating the intented "purpose" of the parameter (e.g., by including "setting" / "monitor" at the start of the term so that the goal can be quickly determined?
- (Paul) Could combine Observation & Settings under the same set of yellow columns ... as a TYPE of data; Could also add a discriminator regarding the use of the parameter. For indicies - maybe a reference to the liturature where more complete documentation is available.
- Also, episodic / "spot" measurements vs. continuous trend streams should also be captured along with the intended usage.
- Question: Why differentiate between episodic & continuous? Paul: the information is handled / communicated differently ... in other words, there are varying data handling / management issues that need to be addressed.
  • Question: Airway pressure measurement site - how is this captured?
- (Paul) There are mechanisms to indicate measurement site information, both pre- & post-coordinated
- (Dain) Is this the role of the device or the CIS? (sometimes in machine / sometimes by clinician / sometimes by clinician entered into device...)
- (Ken) measurement method also important (optional attribution ... but should be available)
- (Jan) adding a methodological column would be very helpful (transductive <Functional> statistical)
  • This usage characterization should be captured in the Rosetta. Paul) Add another column "RefID 2" as a working space
  • Question: How to document & derive terminology from clinical workflow?
- (Jan) Terminology vs. information model
- (Todd) We should capture heuristics regarding when this clinical context information is folded into the term vs. in the info model

Decisions/Issues:

Action(s):

  • (Paul) Add another column "RefID 2" to provide for the HL7-mangled-RefID's (as a WIP space).
5 Planning Discussion
- Group
Status/Discussion:
  • There was a general discussion regarding the group's strategy for going forward.

Decisions/Issues:

  • Complete core mindmap of semantic architecture
  • Focus on numeric parameters (esp. what is charted...) first
  • Update table:
- Add functional discriminator column (e.g., energy per breath, indexed per BSA, body weight)
- IOW 5th row discriminators ... next set of columns (min / max / ...)
- Observation & Setting same YELLOW color
- Support "measurement site" (pre/post coordination)
- Add a "clinical" column (what do clinicians need, intended usage of the term, etc.)
  • Update RTM tables with "RefID 2" column + "measurement site" column

Action(s):

6 Next Meeting
- Chair
Status/Discussion:

Decisions/Issues:

  • Next meeting 2008.12.17

Action(s):

Next Meeting

2008-12-17 Vent WebEx Session


(Reviewed & approved by PCD RTM Vent TG 2008-12-17)


PCD Home