20110623 arb minutes

ArB Agenda/Minutes

Agenda

1. Call to order
2. Approval of Agenda
3. Approval of Minutes June 16, 2011
4. Canonical SAIF
6. Other business and planning for next meeting
7. Adjournment

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Telcon		Date: 20110623 Time: 4:00pm U.S. Eastern
Facilitator	Tony Julian	Note taker(s)	Tony Julian
Attendee	Name	Affiliation
X	Bond,Andy	NEHTA
X	Curry, Jane	Health Information Strategies
.	Grieve, Grahame	Kestral Computing
X	Hufnagel, Steve	U.S. Department of Defense, Military Health System
X	Julian, Tony	Mayo Clinic
X	Koisch, John	Guidewire Architecture
.	Loyd, Patrick	Gordon point Informatics LTD.
X	Lynch, Cecil	ontoreason LLC
.	Mead, Charlie	National Cancer Institute
.	Milosevic, Zoran	NEHTA
.	Ocasio, Wendell	Agilex Technologies
.	Parker, Ron	CA Infoway
.	Quinn, John	Health Level Seven, Inc.
.	Guests
.	Laskso, Lynn	HL7 Staff
Quorum Requirements Met: No

http://wiki.hl7.org/index.php?title=Arb_meeting_schedule#Teleconferences

Minutes

1. Call to order
2. Agenda Approval
3. Minute Approval
4. Canonical SAIF
   1. Jane: If we assume people are reading sequentially, do we need to include in a chapter concept map things in previous CMAPS? We need to be sure there are not new definitions if a concept is reused.
   2. John: So, the BF map I sent you yesterday their is a hierarchy - core set, then levels, and leaves on branches - for the BF the distinctions are clear. Maybe in the earlier chapter keep to the core, and second level - so for the chapters you would have a few points of sameness. For the BF we told the story that the BF is Heracles.
   3. Janel: Sometimes we qualify the concept, other times we don't. We need to qualify them in detail - we have a conflict between readability - not all CMAPS use the same naming convention. I think this makes a difference in producing the OWL content that is analyzed.
   4. Cecil: There are two ways - we could use the same names, and if the relationships are available in a terminology, e.g. snored. Else we can determine if the relationships are the same, we leave the names, and change the URI underneath.
   5. Jane: You use a camel-case technique with no spaces.
   6. Cecil: OWL will not allow spaces.
   7. Jane: I need to do it now.
   8. Cecil: If you put the name in protege with spaces in it, it will add underscores. You can change them later to classify them as needed.
   9. Jane: Case of end-user readability.
   10. Cecil: The URI is nonsensical. There is a RDFS label that give it a human readable name.
   11. Jane: Standardize on readability - change your names for readability.
   12. Cecil: OWL will re-generate.
   13. Jane: We are using as a guide for readers.
   14. Cecil: You want to change my names to user-friendly.
   15. Jane: Yes
   16. Cecil: Do you want to be able to process automatically?
   17. Jane: The goal is to process automatically. Will the underscores be a problem?
   18. Cecil: Then it violates recommended OWL naming conventions. To be compatible with the privacy and security they will use camel-case. OWL users don't use spaces.
   19. Jane: I have no problem with camel-case. We need to do it consistently - the key concepts need to be in a single map, with a subset for the chapters, so we can see how the stuff is glued together. How important is this to the end-user readability? There is stuff in par en used as qualifier - not what you would end up with.
   20. Cecil: I would change mine to what is human readable. I will review, and change the underlying Uri's to create consolidated OWL files. Do what is most useful for the end consumers.
   21. Jane: I will modify every ones if there are spelling errors, or wrong relationships, a matter of the arrows, and note for discussion. It is taking longer than estimated.
   22. Jane: I am used to enterprise architectures as being 4 - can I take system architecture, and adding information and application.
   23. Steve: That is fine.
   24. Jane: That is TOGAF, and you are doing DOGAF. Pulling system architecture out to show the data is not owned by the systems than manage it. Consistent with TOGAF.
   25. Steve: I would concur.
   26. Jane: Aligned with IF.
   27. Steve: That is why I agree. You saw the updated figure, based on my work with Charlie, the one in Charlie's introduction.
   28. Jane: I am looking at Andy's comments, and Charlie's comments against Andy's comments.
   29. Steve: That change will not change anything.
   30. Jane: We take the stack word out, it changes the pictures. It needs to be hierarchically archived. I will ship out an image for critique.
   31. Jane: Still waiting on Charlie?
   32. John: Issue - the issue of specification on the list. Moving the word interoperability specification to the SAIF Canonical. Where the concept is partitioned. Are we in agreement that those three are on the table.
   33. Steve: At the canonical level you have a interoperability specification template, at the GI level you have the stack.
   34. John: I am good with that - but we have been sensitive about using the terms at different levels. I don't want to do a re-write to re-write again.
   35. Steve: My understanding Charlie was trying to differentiate the GI from the canonical.
   36. Andy: I thought we agreed that the canonical and GI would talk about interoperability template.
   37. Jane: We are dropping stack, and referring to GI material.
   38. Steve: At the instance level a stack is a synonym. If you choose not to use it that is fine. Not a strong position, just my interpretation of Charlie's intent.
   39. Jane: We should get clarification from Charlie via e-mail.
   40. John: I sent a e-mail laying out the core issue, Jane or Steve might want to respond. It sounds like we have the concepts straight - we have the placeholders in our head, it is simply the naming conventions. I would like to see resolution.
   41. Jane: If we have IS as the general term, the template associated with the GI, laying out the artifacts and relationships. The IS Instance is an application of the template to the problem.
   42. John: Why not use specification template at the upper level, not interoperability template?
   43. Steve: If top level is template, what is middle.
   44. John: For canonical you would say specification template, for the GI you would have interoperability, service, and end-point.
   45. Cecil: If you call canonical level the template, it looks like the logical is the level for the template. Each is a template for the next level. Canonical is meta-template, logical is template, GI is specification. If we are going to have a constrained template, we are talking about meta-types. IF we are not worried about the user who wants standard ways to refer to templates. We have other templates in HL7. We need consistency within our artifacts - and consistency within HL7. We will have to think about the name again.
   46. Steve: What would be more consistent with Hal7?
   47. Cecil: Hl7 has templates as well - at the logical level. If we were going to name our canonical view a template, it would not be what the HL7 template is calling templates.
   48. John: Our canonical view is a framework. We model it with x elements with cardinalities.
   49. Steve: Works to call it a interoperability specification framework, the logical is a template, the instance is a stack.
   50. John: That is what the grounding in the grammar is supposed to explain - that relationship is necessary. You can talk with clarity at the three levels.
   51. Jane: Can we call it instance - specification instance - that is concrete. Stack is a set o building blocks constrained in a certain way as understood by technical architects. Not all instances will be down to the implementation level. You can stop at any level, and not have any stacks, ie technical stuff, in there.
   52. Steve: That is a good hierarchy - it makes sense. Send to Charlie, and put the burden on him.
   53. Jane: Formally move to remove the word STACK. I will use that criteria as we pull the concept maps together. I have all my questions answered.
   54. Cecil: My world hunger questions have not been answered.
   55. Tony: I will communicate this to Charlie

1. Other business and planning
2. Adjourment
   1. Meeting adjourned at 4:40pm U.S. Eastern

Tony Julian 20:49, 23 June 2011 (UTC)