This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "20120209 arb minutes"

From HL7Wiki
Jump to navigation Jump to search
m
 
(2 intermediate revisions by the same user not shown)
Line 10: Line 10:
 
-->
 
-->
 
=ARB - Meeting February 2, 2012=  
 
=ARB - Meeting February 2, 2012=  
{{:ARB Logistics}}
 
  
 
==Agenda==
 
==Agenda==
Line 16: Line 15:
 
#Agenda approval
 
#Agenda approval
 
#Minute Approval
 
#Minute Approval
 +
##DAM discussion
 +
NOTE: SOA discussion is put off to the future, it is kept here until I get a place to put it.
 
#Discussion with SOA revision of the HSSP boilerplact to align with SAIF:
 
#Discussion with SOA revision of the HSSP boilerplact to align with SAIF:
 
##Ken Rubin: We started to undertake a revision of the boilerplate  to align with SAIF, but frankly that lost some steam.  The latest we have is here:
 
##Ken Rubin: We started to undertake a revision of the boilerplate  to align with SAIF, but frankly that lost some steam.  The latest we have is here:
Line 31: Line 32:
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 ArB Work Group  Meeting Minutes''' <br/>
 
| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 ArB Work Group  Meeting Minutes''' <br/>
 
'''Location:  [[20100722_arb_minutes#logistics| Telcon]]'''
 
'''Location:  [[20100722_arb_minutes#logistics| Telcon]]'''
| width="50%" colspan="3" align="left" style="background:#f0f0f0;"|'''Date: 2011MMDD'''<br/> '''Time: 4:00pm U.S. Eastern'''
+
| width="50%" colspan="3" align="left" style="background:#f0f0f0;"|'''Date: 20110209'''<br/> '''Time: 4:00pm U.S. Eastern'''
 
|-
 
|-
| width="10%" colspan="1" align="right"|'''Facilitator'''
+
| width="10%" colspan="1" align="right"|       
| width="35%" colspan="1" align="left"|Charlie Mead        
 
 
| width="25%" colspan="1" align="right"|'''Note taker(s)'''
 
| width="25%" colspan="1" align="right"|'''Note taker(s)'''
 
| width="30%" colspan="1" align="left"|[[User:Ajulian | Julian, Tony]]
 
| width="30%" colspan="1" align="left"|[[User:Ajulian | Julian, Tony]]
Line 77: Line 77:
 
|colspan="2"|NEHTA
 
|colspan="2"|NEHTA
 
|-
 
|-
|.||[[User:Ocasiw01 | Ocasio, Wendell]]     
+
|X||[[User:Ocasiw01 | Ocasio, Wendell]]     
 
|colspan="2"|Agilex Technologies
 
|colspan="2"|Agilex Technologies
 
|-  
 
|-  
Line 108: Line 108:
 
|-  
 
|-  
 
|}
 
|}
 +
 +
==Minutes==
 +
#Call to order
 +
#Agenda Approval
 +
#Minute Approval
 +
#DAM!
 +
##Charlie and Cecil have been communicating about a DAM.  Cecil's statement is that it is a domain. There are multiple implementation instances that come out from a DAM.  Terminology binding is at the implementation instance.  We need to be specific about what a domain is?
 +
##Lorraine:  The artifact definition people have stated that you dont bind terminology.
 +
##Charlie: It is importatant to state why - that it contains multiple concepts.  Even a unified domain may be expressed in multiple instances.
 +
##Jane: Different processes need different levels of granularity.
 +
##Charlie: The people who control the model were being asked to specify the domain terminology binding.  There needs to be consistent traceability from the top to the bottom.  You should not bind context specific items at the conceptual level.  Where you have commonality across the domain binding the treminology is acceptable.  We need to be specific that a domain has inherent in it multiple context's. 
 +
##Charlie:  Another issue with BRIDGE was how much is at conceptual level, and how much at the logical level.  Serializable is at the logic level.  BRIDGE wanted to do data-type bindings.  There are some big issues we need to be specific about.  Another issue is does a DAM live in multiple perspectives.
 +
##Lorraine: We have been binding some data-types at the conceptual level, e.g. business types.
 +
##Ron: DAM by definition cannot be the derived products at the logical level.  In a domain like LAB, we deal with the messaging aspects.  Do we need a conceptual representation?  Yes!  DAM is all about framing of the context or effect of the persuit.  You can have a DAM that is re-used in other projects.
 +
##Ron: There are multiplicities of context depending on the usage.
 +
##Zoran: Is the domain eprescribing?
 +
##Jane: We organize the actions around a topic that is drawn from a domain, to accomplish a particular objective.  The context is bigger or smaller depending on the purpose.  The domain may be the environment in which you must work.
 +
##Ron: Pharmacy is a domain, eproscribing is a context in that domain.  There are hierarchies of topics.
 +
##Wendell: Does the DAM need to be part of a bigger DAM?
 +
##Charlie: Interesting poing.
 +
##Wendell: We are creating statements about what we want to do with the dam, that are not part of the definition.
 +
##Jane: We have some who have created a small dam, and merged multiple topic dams into one dam.
 +
It is hard to harmonize.
 +
##Ron: This happens all of the time. 
 +
##Charlie: If the domain has a single context, you still need a DAM.  In that world, there are things that you couldn't or shouldn't do in a multiple context model.
 +
##Ron: The problem is that if you treat is as single context, you cannot expand.
 +
##Charlie: Value sets are not bound until the artifacts are available. The ISM does not dictate a process, e.g. fill out the rows sequentially.  We should not confuse when something is added by who added it.
 +
##Jane: If you start at the logical, then you fill out the rest.
 +
##Wendell: Is this for HL7 use, or a larger sense?
 +
##Charlie: One of the thngs we need to stress is that defining the semantics of the DAM does not provide representation. 
 +
##Wendell: What does the IF say about it?
 +
##Cecil: We did not use the word DAM, Lloyd was against it.
 +
##Wendell: SAIF does not define it?
 +
##Ron: No.
 +
##Cecil: CD defines conceptual model.  The IF only deals with the information perspective, not the entire DAM.
 +
##Charlie: The HL7 Board has asked definition of a DAM, so that they can release them freely.  Some people on the TSC are concerned about what a DAM is - we want a definition so we can be consistent on labelling of a DAM, and cover traceability across levels.
 +
##there are many DAM's already created.
 +
##Wendell: Are some incorrectly labelled as dam's?
 +
##Cecil:  You would not want to do that - the TB dam defines binding of value sets and their linkage in their DAM.
 +
##Wendell: That is bad why?
 +
##Cecil: That makes it an implementation model.
 +
##Wendell: What if it helps me to understand it if there is binding?
 +
##RP: You can state logical examples of binding, and physical implementations.  It creates a benchmark that you can use - and allows others to discover whether you are discussing things others care about.
 +
##Cecil: It is a bad thing - the TB model developers where thinking about it as a specimen.  At the top level it is great - as you work your way down, you find the bindings limit the implementation. So it is not usable for any other thing.
 +
##Wendell: We are not only defining, but also providing prescriptions.  In the end it will say what fits the guidelines it will be free, and in HL7 you should do it this way, not that way.
 +
##Ron: We should define what artifacts are a part of the DAM.  Where is the line you cross between the DAM and the instance?  For HL7 the question is where do you stop?
 +
##Lorraine: It is not a line in the sand - the transition to building something is the best test.  The Medication model was binding realm-specific codes.
 +
##Wendell: Whatever we come up with should be part of the HL7 IG?
 +
##Lorraine: Yes.
 +
##Charlie: Austin and John have said yes.
 +
##Wendell: We should use CD terms.  Why would you say that it is anything other than conceptul?
 +
##Jane: DAMS were balloted, then held as a standard using the same topic area.
 +
##Wendell: Like TB
 +
##Jane: BRIDGE was intended to do this.  This is another solution of modeling where multiple uses would derive.
 +
##Wendell: The number 1 reason that the conceptual exists is a DAM.  On the domain side, the strict definition is not as important.
 +
##Ron: The attributes of the domain are required.
 +
##Cecil: We cannot define a domain.  It is the concensus of a group for a particular problem space, reusable across the artifacts of that space. 
 +
##Jane: We have the same conversation about realm.
 +
##Cecil: The TB domain should cover care, research, etc.  the Cardiology DAM was restricted to interventional cardiology.
 +
##Charlie: The DAM needs an explicit definition of the boundaries.
 +
##Ron: Domain: Any topic where there are multiple perspectives, and multiple entry points.  If it is more specific, you have a topic.  Ignoring the broader aspects causes a problem.
 +
##Jane: It leaves a limit on the participants, e.g. TB DAm was done by research.  They had not included others, so there is not enough representation for the declared scope.  If you are tempted to get to value set bindings, you are narrowing a domain, unless you have participation of everyone who will use the domain.
 +
##Charlie: You are confusing conceptualizing with ...
 +
##Jane: You need to recognize when to bind the data-types at the conceptual domain, you are limiting the scope.
 +
##Charlie: It is not you are at the logical level, you are at a limited contextual level.
 +
##Cecil: There is confusion.  At the upper level you may specify a value-domain.
 +
##Wendell: I am not sure there is an easy test.
 +
##Ron: I am more interested about what it is NOT.  The scope of the domain may be extremely broad, or not that broad.  You are describing information rendered in a way to guide the creation of artifacts to be rendered in that domain.  The models need to be sufficient to understand your topic without instantiating anything.  We should not contaminate the models by introducing things too early that will prevent usage.
 +
##Lorraine: It does not preclude a DAM where the othere artifacts exist.
 +
##Ron: Yes.  You may have a bunch groups saying "We dont have a DAM - How do I get one?"  You will have to reverse-engineer.
 +
##Patrick: Then you will find the thing you missed.
 +
##Wendell: Are you not allowed to use RIM artifacts in a DAM?
 +
##Lorraine: There is sterotyping.
 +
##Charlie: We need to define a DAM at the CD level, and see how the fits HL7.  We should correctly use CD terms.
 +
##Wendell: Since we dont have a definition in the CD, are we missing something that will allow us to define at the IG level?  Which are definition, and which are things we want to use in HL7?
 +
##Charlie: TSC wants something they can govern in HL7.
 +
##Ron: Our definition should have external relevance, but meet what HL7 wants to do with it.
 +
##Charlie: It does not have to be retrograde compatable.
 +
##Wendell: We can define constraints that HL7 needs to apply.
 +
##Charlie: We need to root our definition in CD terminology.
 +
##Ron: Can someone do this?
 +
##Charlie: As a set of bullet points.  I will try to do so.
 +
##Ron: Charlie: I would recommend 5-6 bullet points, and spit to the group.
 +
##Zoran: Maybe the point that Andy raised would be a place to start.
 +
#Adjourn at 5:00pm U.S. Eastern [[User:Ajulian|Tony Julian]] 22:00, 9 February 2012 (UTC)
  
 
==Minutes==
 
==Minutes==

Latest revision as of 22:22, 9 February 2012

ARB - Meeting February 2, 2012

Agenda

  1. Call to order
  2. Agenda approval
  3. Minute Approval
    1. DAM discussion
NOTE: SOA discussion is put off to the future, it is kept here until I get a place to put it.
  1. Discussion with SOA revision of the HSSP boilerplact to align with SAIF:
    1. Ken Rubin: We started to undertake a revision of the boilerplate to align with SAIF, but frankly that lost some steam. The latest we have is here:
    2. SFM
    3. See also
      1. SFM Boilerplace
      2. Producing SFM Overview
  2. Other business and planning for the next meeting
  3. Adjournment


Meeting Information

HL7 ArB Work Group Meeting Minutes

Location: Telcon

Date: 20110209
Time: 4:00pm U.S. Eastern
Note taker(s) Julian, Tony
Attendee Name Affiliation
X Bond,Andy NEHTA
X Constable, Lorraine Constable Consulting Inc.
X Curry, Jane Health Information Strategies
. Dagnall, Bo HP Enterprise Services
. Grieve, Grahame Health Intersections Pty Ltd
X Hufnagel, Steve U.S. Department of Defense, Military Health System
X Julian, Tony Mayo Clinic
X Loyd, Patrick ICode Solutions
. Lynch, Cecil Accenture
X Mead, Charlie National Cancer Institute
X Milosevic, Zoran NEHTA
X Ocasio, Wendell Agilex Technologies
X Parker, Ron CA Infoway
. Quinn, John Health Level Seven, Inc.
. Guests
.
. Legend
. Present
. Absent
Quorum Requirements Met: Yes

Minutes

  1. Call to order
  2. Agenda Approval
  3. Minute Approval
  4. DAM!
    1. Charlie and Cecil have been communicating about a DAM. Cecil's statement is that it is a domain. There are multiple implementation instances that come out from a DAM. Terminology binding is at the implementation instance. We need to be specific about what a domain is?
    2. Lorraine: The artifact definition people have stated that you dont bind terminology.
    3. Charlie: It is importatant to state why - that it contains multiple concepts. Even a unified domain may be expressed in multiple instances.
    4. Jane: Different processes need different levels of granularity.
    5. Charlie: The people who control the model were being asked to specify the domain terminology binding. There needs to be consistent traceability from the top to the bottom. You should not bind context specific items at the conceptual level. Where you have commonality across the domain binding the treminology is acceptable. We need to be specific that a domain has inherent in it multiple context's.
    6. Charlie: Another issue with BRIDGE was how much is at conceptual level, and how much at the logical level. Serializable is at the logic level. BRIDGE wanted to do data-type bindings. There are some big issues we need to be specific about. Another issue is does a DAM live in multiple perspectives.
    7. Lorraine: We have been binding some data-types at the conceptual level, e.g. business types.
    8. Ron: DAM by definition cannot be the derived products at the logical level. In a domain like LAB, we deal with the messaging aspects. Do we need a conceptual representation? Yes! DAM is all about framing of the context or effect of the persuit. You can have a DAM that is re-used in other projects.
    9. Ron: There are multiplicities of context depending on the usage.
    10. Zoran: Is the domain eprescribing?
    11. Jane: We organize the actions around a topic that is drawn from a domain, to accomplish a particular objective. The context is bigger or smaller depending on the purpose. The domain may be the environment in which you must work.
    12. Ron: Pharmacy is a domain, eproscribing is a context in that domain. There are hierarchies of topics.
    13. Wendell: Does the DAM need to be part of a bigger DAM?
    14. Charlie: Interesting poing.
    15. Wendell: We are creating statements about what we want to do with the dam, that are not part of the definition.
    16. Jane: We have some who have created a small dam, and merged multiple topic dams into one dam.

It is hard to harmonize.

    1. Ron: This happens all of the time.
    2. Charlie: If the domain has a single context, you still need a DAM. In that world, there are things that you couldn't or shouldn't do in a multiple context model.
    3. Ron: The problem is that if you treat is as single context, you cannot expand.
    4. Charlie: Value sets are not bound until the artifacts are available. The ISM does not dictate a process, e.g. fill out the rows sequentially. We should not confuse when something is added by who added it.
    5. Jane: If you start at the logical, then you fill out the rest.
    6. Wendell: Is this for HL7 use, or a larger sense?
    7. Charlie: One of the thngs we need to stress is that defining the semantics of the DAM does not provide representation.
    8. Wendell: What does the IF say about it?
    9. Cecil: We did not use the word DAM, Lloyd was against it.
    10. Wendell: SAIF does not define it?
    11. Ron: No.
    12. Cecil: CD defines conceptual model. The IF only deals with the information perspective, not the entire DAM.
    13. Charlie: The HL7 Board has asked definition of a DAM, so that they can release them freely. Some people on the TSC are concerned about what a DAM is - we want a definition so we can be consistent on labelling of a DAM, and cover traceability across levels.
    14. there are many DAM's already created.
    15. Wendell: Are some incorrectly labelled as dam's?
    16. Cecil: You would not want to do that - the TB dam defines binding of value sets and their linkage in their DAM.
    17. Wendell: That is bad why?
    18. Cecil: That makes it an implementation model.
    19. Wendell: What if it helps me to understand it if there is binding?
    20. RP: You can state logical examples of binding, and physical implementations. It creates a benchmark that you can use - and allows others to discover whether you are discussing things others care about.
    21. Cecil: It is a bad thing - the TB model developers where thinking about it as a specimen. At the top level it is great - as you work your way down, you find the bindings limit the implementation. So it is not usable for any other thing.
    22. Wendell: We are not only defining, but also providing prescriptions. In the end it will say what fits the guidelines it will be free, and in HL7 you should do it this way, not that way.
    23. Ron: We should define what artifacts are a part of the DAM. Where is the line you cross between the DAM and the instance? For HL7 the question is where do you stop?
    24. Lorraine: It is not a line in the sand - the transition to building something is the best test. The Medication model was binding realm-specific codes.
    25. Wendell: Whatever we come up with should be part of the HL7 IG?
    26. Lorraine: Yes.
    27. Charlie: Austin and John have said yes.
    28. Wendell: We should use CD terms. Why would you say that it is anything other than conceptul?
    29. Jane: DAMS were balloted, then held as a standard using the same topic area.
    30. Wendell: Like TB
    31. Jane: BRIDGE was intended to do this. This is another solution of modeling where multiple uses would derive.
    32. Wendell: The number 1 reason that the conceptual exists is a DAM. On the domain side, the strict definition is not as important.
    33. Ron: The attributes of the domain are required.
    34. Cecil: We cannot define a domain. It is the concensus of a group for a particular problem space, reusable across the artifacts of that space.
    35. Jane: We have the same conversation about realm.
    36. Cecil: The TB domain should cover care, research, etc. the Cardiology DAM was restricted to interventional cardiology.
    37. Charlie: The DAM needs an explicit definition of the boundaries.
    38. Ron: Domain: Any topic where there are multiple perspectives, and multiple entry points. If it is more specific, you have a topic. Ignoring the broader aspects causes a problem.
    39. Jane: It leaves a limit on the participants, e.g. TB DAm was done by research. They had not included others, so there is not enough representation for the declared scope. If you are tempted to get to value set bindings, you are narrowing a domain, unless you have participation of everyone who will use the domain.
    40. Charlie: You are confusing conceptualizing with ...
    41. Jane: You need to recognize when to bind the data-types at the conceptual domain, you are limiting the scope.
    42. Charlie: It is not you are at the logical level, you are at a limited contextual level.
    43. Cecil: There is confusion. At the upper level you may specify a value-domain.
    44. Wendell: I am not sure there is an easy test.
    45. Ron: I am more interested about what it is NOT. The scope of the domain may be extremely broad, or not that broad. You are describing information rendered in a way to guide the creation of artifacts to be rendered in that domain. The models need to be sufficient to understand your topic without instantiating anything. We should not contaminate the models by introducing things too early that will prevent usage.
    46. Lorraine: It does not preclude a DAM where the othere artifacts exist.
    47. Ron: Yes. You may have a bunch groups saying "We dont have a DAM - How do I get one?" You will have to reverse-engineer.
    48. Patrick: Then you will find the thing you missed.
    49. Wendell: Are you not allowed to use RIM artifacts in a DAM?
    50. Lorraine: There is sterotyping.
    51. Charlie: We need to define a DAM at the CD level, and see how the fits HL7. We should correctly use CD terms.
    52. Wendell: Since we dont have a definition in the CD, are we missing something that will allow us to define at the IG level? Which are definition, and which are things we want to use in HL7?
    53. Charlie: TSC wants something they can govern in HL7.
    54. Ron: Our definition should have external relevance, but meet what HL7 wants to do with it.
    55. Charlie: It does not have to be retrograde compatable.
    56. Wendell: We can define constraints that HL7 needs to apply.
    57. Charlie: We need to root our definition in CD terminology.
    58. Ron: Can someone do this?
    59. Charlie: As a set of bullet points. I will try to do so.
    60. Ron: Charlie: I would recommend 5-6 bullet points, and spit to the group.
    61. Zoran: Maybe the point that Andy raised would be a place to start.
  1. Adjourn at 5:00pm U.S. Eastern Tony Julian 22:00, 9 February 2012 (UTC)

Minutes