This wiki has undergone a migration to Confluence found Here
Difference between revisions of "December 6, 2011 CBCC Conference Call"
Jump to navigation
Jump to search
Finaversaggi (talk | contribs) m (→Agenda) |
Finaversaggi (talk | contribs) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 21: | Line 21: | ||
#''(5 min)'' '''Other Business''' | #''(5 min)'' '''Other Business''' | ||
==Minutes== | ==Minutes== | ||
| + | Today's meeting focused on mapping out next steps and the agenda for December off-line work. | ||
| + | *Arnon Rosenthal from MITRE joined the call today to gain some familiarity with the group's work. He is an associate of Peter Mork, and is currently focused on the area of consent and privacy. His background is in database formalism. | ||
| + | **As an aside, for more information on database formalism, see: | ||
| + | ***[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CC8QFjAC&url=http%3A%2F%2Facl.ldc.upenn.edu%2FC%2FC90%2FC90-2065.pdf&ei=AJfeTt2WDcKOiAK3h73yCA&usg=AFQjCNFS6N5r8Yf43exC7J3epxfKH9fIIw&sig2=SWoVKzdowfQnvTmCZfGS2Q An Implementation of Formal Semantics in the Formalism of Relational Databases] and | ||
| + | ***[http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCAQFjAA&url=http%3A%2F%2Fmath.mit.edu%2F%257Edspivak%2Finformatics%2Fnotes%2Funorganized%2FCTDB--spivakCurino.pdf&ei=AJfeTt2WDcKOiAK3h73yCA&usg=AFQjCNGz3c3XCMZ8Svvd_oQm93EDbt2GSA&sig2=EHAPiie5qRIeVJt_-Eyvxg Category Theory as a Unifying Database Formalism] | ||
| + | *Richard invited Arnon to present a summary of the projects that he’s working on with Peter and others with respect to ONC sponsored work in the future if that is possible | ||
| + | ---- | ||
| + | December Planning | ||
| + | ---- | ||
| + | *What is the scope of work that is required to produce the Implementation Guide and Reference Implementation? | ||
| + | **A re there gaps in subsets of LOINC and SNOMED codes (meaning they might not exist) that are critical to be there for the core data elements that are being defined? | ||
| + | *Essentially we need to come up with a recommended set of codes to be associated with each of the core data elements that have been called out in our information model; either a finite list of codes or binding the attribute to a code system | ||
| + | *This ballot identifies the contributing stakeholder requirements and document s the rationale behind the inclusion of each element and its constraint | ||
| + | *The purpose is to receive feedback from Behavioral Health stakeholders (ballot reviewers) and to gain consensus on the basic principles and scope of the information for exchange that may be particular although not exclusive, to Behavioral Health providers | ||
| + | *Within the context of this domain analysis model, there are two types of coded attributes: | ||
| + | #Narrowly limited values, not thousands of values - e.g., OMB Race Codes, Gender Identity, Referral Source. For these cases, it is useful to reach consensus on the set | ||
| + | #Impossible to constrain. In this case, we provide guidance only on the coding system, e.g., LOINC. | ||
| + | #* If your favorite assessment doesn’t exist in LOINC and you want to be able to exchange this assessment, you need to obtain a code from LOINC. | ||
| + | *It is difficult to narrow the value set unless there is strong guidance from somewhere; otherwise the included values must come from some requirement somewhere. The values we’ve included as the initial set in this ballot are those that were gleaned from the stakeholder source documents. We’ve also included the rationale for their inclusion | ||
| + | *We are seeking buy-in from BH stakeholders: Is this the right approach, and is there need to exchange a summary of this information in the BH community? | ||
| + | **Richard referred to the Detailed Clinical Models approach. Ioana stressed that the DCM approach requires at least one constraint on terminology for coded elements, although more than one terminology may be recommended as well. This is in keeping with our approach | ||
| + | *This information model enforces consistent application of the requirements. Declaring those constraints clearly in the ballot allows us to get feedback early on | ||
| + | *In the methodology we’ve followed, our initial focus has been to determine what is appropriate for a particular coded concept. and to specify as much as we know about what the coding system should be. **This approach to an initial analysis is not a typical approach (just like DCM), which usually only addresses implementation considerations at a very high level. | ||
| + | ---- | ||
| + | In the final minutes of the meeting, Ioana presented a prototype InfoPath format representation of the current information model to see whether the group thought this form(at) might be a good alternate way for some of the subject matter expert ballot reviewers to review the ballot material. While there was no further decision about whether to use this tool, we discussed the mechanism behind the tool, as well as some details about some of the coded concepts in the model that we reviewed in the form | ||
| + | *Several schemas were generated from the information analysis model. InfoPath allows you to design new forms based on XML schemas | ||
| + | *This approach could provide an easy way for reviewers to validate that we have the appropriate amount of information captured in this iteration of the model. The information is grouped logically (in sections) and where there are finite lists of coded values provided by the stakeholder requirements for certain elements, they can be validated in drop down lists | ||
| + | *Arnon noted that people don’t always agree on the meaning of the term “core” data set | ||
| + | **Some interpret that to mean the minimum amount needed to get something done | ||
| + | **Others interpret core to mean, here are some useful ingredients that many may want to include in their applications | ||
| + | **One needs to be very clear as to the difference because this has been a source of confusion and has limited interoperability | ||
| + | *Ioana pointed out this issue is the source of the optionality that has been permitted in the HL7 standards, as it was difficult to agree on what is mandatory; so most were left optional | ||
| + | **In this analysis, we have included some very objective criteria – SAMHSA grants and other reporting requirements | ||
| + | **However, other concepts are state-specific requirements, not part of the core data. But the methodology provides a framework for extensibility | ||
| + | ---- | ||
| + | Next strategic steps: | ||
| + | ---- | ||
| + | #Identify what we want to elaborate on based on the current content of the DAM | ||
| + | #To further identify value sets and coded concepts, we should refer to section 4.3.1 | ||
| + | *Ioana and Jim to meet to prioritize areas in the model that would benefit from putting a stake in the ground to create more formal bindings to those coded concepts, either extensional or intensional | ||
| + | **This would help surface candidates for creating SNOMED-CT or LOINC value sets; other cases where we provide an open ended set (from some code system) | ||
| + | **Value sets can either be specified by enumeration (extensional) or by definition (intensional) | ||
| + | ---- | ||
| + | Meeting was adjourned at 3:15 PM Eastern | ||
| + | |||
| + | |||
[[Community-Based_Collaborative_Care|Back to CBCC Main Page]] | [[Community-Based_Collaborative_Care|Back to CBCC Main Page]] | ||
Latest revision as of 00:38, 7 December 2011
Contents
Community-Based Collaborative Care Working Group Meeting
Meeting Information
Attendees
- Jon Farmer
- Jim Kretz
- Arnon Rosenthal, MITRE
- Ioana Singureanu
- Richard Thoreson CBCC Co-chair
- Serafina Versaggi
Agenda
- (05 min) Roll Call, Approve Minutes & Accept Agenda
- (50 min) Behavioral Health Draft for Comment ballot discussion
- (5 min) Other Business
Minutes
Today's meeting focused on mapping out next steps and the agenda for December off-line work.
- Arnon Rosenthal from MITRE joined the call today to gain some familiarity with the group's work. He is an associate of Peter Mork, and is currently focused on the area of consent and privacy. His background is in database formalism.
- As an aside, for more information on database formalism, see:
- Richard invited Arnon to present a summary of the projects that he’s working on with Peter and others with respect to ONC sponsored work in the future if that is possible
December Planning
- What is the scope of work that is required to produce the Implementation Guide and Reference Implementation?
- A re there gaps in subsets of LOINC and SNOMED codes (meaning they might not exist) that are critical to be there for the core data elements that are being defined?
- Essentially we need to come up with a recommended set of codes to be associated with each of the core data elements that have been called out in our information model; either a finite list of codes or binding the attribute to a code system
- This ballot identifies the contributing stakeholder requirements and document s the rationale behind the inclusion of each element and its constraint
- The purpose is to receive feedback from Behavioral Health stakeholders (ballot reviewers) and to gain consensus on the basic principles and scope of the information for exchange that may be particular although not exclusive, to Behavioral Health providers
- Within the context of this domain analysis model, there are two types of coded attributes:
- Narrowly limited values, not thousands of values - e.g., OMB Race Codes, Gender Identity, Referral Source. For these cases, it is useful to reach consensus on the set
- Impossible to constrain. In this case, we provide guidance only on the coding system, e.g., LOINC.
- If your favorite assessment doesn’t exist in LOINC and you want to be able to exchange this assessment, you need to obtain a code from LOINC.
- It is difficult to narrow the value set unless there is strong guidance from somewhere; otherwise the included values must come from some requirement somewhere. The values we’ve included as the initial set in this ballot are those that were gleaned from the stakeholder source documents. We’ve also included the rationale for their inclusion
- We are seeking buy-in from BH stakeholders: Is this the right approach, and is there need to exchange a summary of this information in the BH community?
- Richard referred to the Detailed Clinical Models approach. Ioana stressed that the DCM approach requires at least one constraint on terminology for coded elements, although more than one terminology may be recommended as well. This is in keeping with our approach
- This information model enforces consistent application of the requirements. Declaring those constraints clearly in the ballot allows us to get feedback early on
- In the methodology we’ve followed, our initial focus has been to determine what is appropriate for a particular coded concept. and to specify as much as we know about what the coding system should be. **This approach to an initial analysis is not a typical approach (just like DCM), which usually only addresses implementation considerations at a very high level.
In the final minutes of the meeting, Ioana presented a prototype InfoPath format representation of the current information model to see whether the group thought this form(at) might be a good alternate way for some of the subject matter expert ballot reviewers to review the ballot material. While there was no further decision about whether to use this tool, we discussed the mechanism behind the tool, as well as some details about some of the coded concepts in the model that we reviewed in the form
- Several schemas were generated from the information analysis model. InfoPath allows you to design new forms based on XML schemas
- This approach could provide an easy way for reviewers to validate that we have the appropriate amount of information captured in this iteration of the model. The information is grouped logically (in sections) and where there are finite lists of coded values provided by the stakeholder requirements for certain elements, they can be validated in drop down lists
- Arnon noted that people don’t always agree on the meaning of the term “core” data set
- Some interpret that to mean the minimum amount needed to get something done
- Others interpret core to mean, here are some useful ingredients that many may want to include in their applications
- One needs to be very clear as to the difference because this has been a source of confusion and has limited interoperability
- Ioana pointed out this issue is the source of the optionality that has been permitted in the HL7 standards, as it was difficult to agree on what is mandatory; so most were left optional
- In this analysis, we have included some very objective criteria – SAMHSA grants and other reporting requirements
- However, other concepts are state-specific requirements, not part of the core data. But the methodology provides a framework for extensibility
Next strategic steps:
- Identify what we want to elaborate on based on the current content of the DAM
- To further identify value sets and coded concepts, we should refer to section 4.3.1
- Ioana and Jim to meet to prioritize areas in the model that would benefit from putting a stake in the ground to create more formal bindings to those coded concepts, either extensional or intensional
- This would help surface candidates for creating SNOMED-CT or LOINC value sets; other cases where we provide an open ended set (from some code system)
- Value sets can either be specified by enumeration (extensional) or by definition (intensional)
Meeting was adjourned at 3:15 PM Eastern
