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

20110515 arb WGM Orlando Minutes

From HL7Wiki
Jump to navigation Jump to search

Architecture Board May 15-21 2011, Orlando Working Group Meeting

Sunday Q1

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Orlando WGM
Date: 20110515 Time: 9:00am U.S. Eastern
FacilitatorRon Parker Note taker(s)Tony Julian
 
 MemberAffiliation MemberAffiliation
XMead, Charlie ChairNational Cancer Institute XParker, Ron Vice-ChairCA Infoway
.Quinn, John CTO Health Level Seven, Inc. XJulian, Tony SecretaryMayo Clinic
XBond,Andy NEHTAXKoisch, John Guidewire Architecture
XCurry, Jane Health Information Strategies.Loyd, PatrickGordon point Informatics LTD.
.Grieve, Grahame Health Intersections Pty LtdXLynch, Cecil ontoreason LLC
XHufnagel, Steve U.S. Department of Defense, Military Health System XOcasio, Wendell Agilex Technologies
.Shakir, Abdul-Malik Shakir Consulting   
Guests
XHall, FriedaQuest Diagnostics, Inc.Xvan der Zel, MichaelUMCG, the Netherlands
XMilosevic, ZoranNEHTAXPech, BrianKaiser Permanente
Quorum Requirements Met: Yes

Minutes

  • Call to order at 9:00am U.S. Eastern
  • Agenda approved by affirmation
  • Ballot Reconcillation:
  • Cecil: Grahame's comments that the IF describes a model by constraint. If you start to model without a paradigm, you may select your vocabulary before you constrain the model. If I know the domain, I can start anywhere in the stack. I would like to know how you would blend a model by constraint with a model by inheritance.
  • Wendell: Just because a canonical framework has both, does not mean you have to blend them. The models should be in the canonical, and the implementation guide should choose a method.
  • Charlie: Is it your idea if you did not mix the paradigms, would you end up with a dead end?
  • Cecil: In OWL you have to do it by inheritance. When I put the RIM into OWL, I have to work around the way the RIM works, by only taking the mandatory elements of the class's, the fully build out the iheritance. You have to have amodel to start with. You have to have a RIM of some type tostart with. Its doable, but . . . Open EHR is like OWL, without a reference information model - there is no super reference information model - to tie to the HL7 RIM, I would have to do it element by element.
  • Charlie: Open EHR expects you to derive your own model.
  • Cecil: You can do it by inheritance from abstract classes, I can do it, but I am hot sure you will end up with the same outcome.
  • Wendell: You have to give people the tools to solve the problem.
  • Charlie: Some of this needs to be in the introduction.
  • Andy: The introduction has to reflect this.
  • Charlie: It should tell you what the SAIF canonical should give you. There is a Tech editor at NCI who worked on SAIF IG. She understands consistancy, and how it works. She is willing to do the same for the SAIF book.
  • Cecil: The canonical does not have to pick an implementation - but an implementation guide will not.
  • BF Comments: We have a discussion in the BF around specifications. In the SAIF we said that all interoperability is scoped to a subject. One of the things that has gotten lost is using v2, or fully elaborated models. You have to define behaviour within the rules of the community. There is a question on how to conform to the BF. Focusing conformance into a specification is essential.
  • Andy: There is an issue across the frameworks - when you take a set of viewpoints and put into frameworks, you can get inconsistent specifications.
  • John: IF allows localization at any level. HL7 took the RIM as a point of departure. MDA is the bane of the project.
  • Charlie: I thought we discarded MDA.
  • John: People want to see rigorous compliance between perspectives.
  • Ron: "How do I render in MIF" - cant be answered directly from the Canonical.
  • John: At the conceptual level we listed HL7 appliction role as logical and implementable.
  • Jane: There are implied application roles in the EHR functional model.
  • Charlie: Why does canonical include HL7 references.
  • John: We could have left them out.
  • Ron: It is essential that people havge a notion of a conceptual role.
  • Charlie: The canonical does not have to tie to HL7 roles.
  • Ron: Some of the conceptualization are ABOVE the HL7 roles.
  • Zoran: Need to finish discussion on subject specification, ECCF, etc.
  • Charlie: Discussed SAIF with John Quinn - we should go to ballot in September as DSTU.
    • Balloting:
    • July 24 (Sunday) T minus 1 Final Content Deadline
    • July 24 (Sunday) T minus 1 Final Content Deadline Balloting

Sunday Q2

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Orlando WGM
Date: 20110515 Time: 10:30am U.S. Eastern
FacilitatorRon Parker Note taker(s)Tony Julian
 
 MemberAffiliation MemberAffiliation
XMead, Charlie ChairNational Cancer Institute XParker, Ron Vice-ChairCA Infoway
.Quinn, John CTO Health Level Seven, Inc. XJulian, Tony SecretaryMayo Clinic
XBond,Andy NEHTAXKoisch, John Guidewire Architecture
XCurry, Jane Health Information Strategies.Loyd, PatrickGordon point Informatics LTD.
.Grieve, Grahame Health Intersections Pty LtdXLynch, Cecil ontoreason LLC
XHufnagel, Steve U.S. Department of Defense, Military Health System XOcasio, Wendell Agilex Technologies
.Shakir, Abdul-Malik Shakir Consulting   
Guests
XHall, FriedaQuest Diagnostics, Inc.Xvan der Zel, MichaelUMCG, the Netherlands
XMilosevic, ZoranNEHTAXPech, BrianKaiser Permanente
XMcKenzie, LloydHL7 Canada.  
Quorum Requirements Met: Yes

Minutes

  • John Koisch: I tried to respond completely. Come of the questions were clear, and were a good guide to being more explicit. A fair

Line 156- was discussed. Lloyd wants to make sure that there is not an impression that messaging is no longer involved. Concern that membership will not understand that terms used in HL7 previously have shifted meaning - in the document implement discussion of the old meaning and the new meaning.

  • Wendell: no statement in intro about what services-aware means. Just because you have an option to use the concept, does not mean that everyone is required to use it to comply with SAIF.
  • Lloyd: SAIF has evolved from HL7 methodology. People are coming to this who don't know the HL7 methodology. The term storyboard is not the same as community. HL7 storyboards apply to a community, but it is not implied from the storyboard. A storyboard may have an implicit community. Should document the minimum you need to know to understand SAIF.
  • John: We chose to be verbose. The audience for the document - what people will care about are the implementation guides(IG), and the hints we give to the creators of the IG's. Most will not care about the canonical relations. We are trying to be precise, you are looking at the document for general consumption.
  • Lloyd: If HL7 moves to SAIF, I am not comfortable where underlying reference structure is written on language that is less accessible than it could be. There is a tendency to be formal and rigourous around somethings, but not always needed. I think this could be bore accessible, and greater accessibility is important. An implementer may not need to read canonical, and if their initial impression is that it is goblygook and complicated - which is a bad thing for HL7.
  • Steven: It was done hierarchilly -
  • Ron Parker: We need more clarity - such as why have a framework at all? You said we are 5 grade levels above where we should be, which may be right.
  • Lloyd: I am not suggesting that canonical exclude stuff HL7 does not use.
  • Ron: We will work with the group doing the IG to produce a draft HL7 IG as soon as possible.
  • Lloyd: That is part: part too is taking it, running through word, using grammer words, check the reading level, etc - can we simplyfy this? Some places we cant, but in some we can.
  • John: Refering to line 46 of the ballot recon: If you dont include the terms that are there, especially over the MDA stack, you cant do it.
  • Lloyd: HL7 terms are imbeded in artifacts that dont get exposed as the product. SOme of it is in IG territory, some will be common across SAIF IG. There are some things split out in RMODP that dont need to be split in SAIF-C, others will be done in HL7-IG.

Some of the things will be collapsed in IG's that are not required. This is way to complex. What we can collapse in the Canonical we should, and if we cant, we need to explain that there may be collapsed of unneeded things. >>Sentence in Introduction <<

  • John: Original mandate was 10 pages for each section - which we did not follow. This is frustrating community: If you are terse, people complain you need to be more expressive; if you are expressive, someone will want it more terse.
  • Jane: I paraphrased RM-ODP, assuming that the reader did not assume RM-ODP.
  • Lloyd: Yes
  • Jane: Are the pieces a summary of RM-ODP - do we need to go to that level in this document.
  • Lloyd: From rmodp there will be core concepts, there are other concepts are available for use, or implicit for internal creation - that category we can get by with less verbage. IG writer needs to look at them but cannonical reader is overloaded.
  • Charlie: Who is the target audience? People developing IG's. SOme subset of HL7 will have to dig in to develop an IG.
  • Lloyd: That may be your intended audience - but it will not be limited to that. Implementors need to understand context of other environments where they need to interoperate. There maybe 2 documents - one for IG creators, one for those who want to understand the methodology.
  • Charlie: Methodology - is IF based on subtypes or constraints. Canonical is not about methodology, but expressing terms.
  • Lloyd: Stating the things reqired, such as roles, etc are methodology.
  • Charlie: No, components of methodologly.
  • Lloyd: MDF-99 talks about classes, application roles: SAIF-C is defining the methodology by using those artifacts. The sqeuencing and the things sequenced, and why they exist.
  • John: You are assuming a methodology we have now - harmonizing messages and services has been an issue. Lloyd would collapse Flow, operation, and signal. We could collapse. Interface signatures cant be. In an IG you could say "we will ignore flow and signal"
  • Lloyd: Do we need to independently name those things. Operations have patterns. RMODP identifies patterns in operations, and give names to them.
  • John: dont you do that in canonical?
  • Lloyd: we dont use signals.
  • John: We can collapse flows and signals.
  • Lloyd: Specification and signature have a 1..1 relationship - do we need to name them, or deal with them at a higher level.
  • John: You have a contract, part of which is the environmental.
  • Lloyd: my issue is being overwhelmed with - newcomers are overwhelmed.
  • John: Newcomers wont read it.
  • Lloyd: they are - we can make it less scary - by differentiating concepts at different levels. We need to label CORE vs things you may need to know.
  • John: You are conflating MDF-99 with the thought that went behind MDF-99. The scary part will be when someone asks how does this relate to a WSDL. No answer is not better.
  • Lloyd: users should read the Hl7 IG, then the canonical - a challenge is balloting the canonical before the IG is ready. I think we can do some things in canonical that will help those readers whose intention is understanding context, not writing an IG, who want to understanding everything.
  • John: I agree we can tighten up the phrasing, reorganize the document, flesh out what a specifiction means. A use case is a person who has written a conceptual spec, and wants to see how they play out in documents/messages/services.
  • Ron: Canonical is not strictly for IG writers. The whole idea was discoverability and comsumability of HL7 by persons who are not vested in Hl7.
  • Lloyd: DAM's encompass "everything at the conceptual layer", therefore it is not an artifact per se. It is also used to refer to an information model. It is not a useful term.
  • Cecil: In the IF we are explicitly discussing the DAM information model. That DIM is not always implemented conceptually - you can use it as upper level.
  • Lloyd: HL7 has conceptual information model - user friendly UML model, dam does it in rim-speak.
  • Cecil: A DIM is different than a DAM. The DIM part of the DAM is the abstract representation, that has no RIM ties.= I would prefer analysis information model.
  • Ron: Keep DAM for its original purpose. We dont have a name for that bag of stuff that defines the context of the domain. We need more stuff at the conceptual layer.
  • Lloyd: IG will define the bag of stuff. You dont need more than conceptual artifacts. HL7 has grouping structures, SAIF does not.
  • Cecil: Prefixing before useing is not necessary. Will change DAM to Analysis information Model (AIM).
  • Ron: Concept of rims not conceptual - attribution that allows insight that you have enough information about the thing you are discussing. Differentiation from Logical expression to physical.
  • Lloyd: Conceptual is about requirements, and representing structures intuitively. Logical is expressing computably. RIM is not intuitive, does not capture requirements - is is computable - which puts in in logical.
  • Cecil: Discusing design by constraint - it becomes logical model. If discussing design by inheritance, expressing only the core elements/mandatory attributes - is that still logical?
  • Lloyd: In the design Space

Ron: Understand correlations between spaces, and why certain information is needed to understand context. Cecil: a Reference Information Model is the result of an entrerprise information concept model. If you want consistent artifacts, you must have a reference model.

  • Lloyd: a RIM at the conceptual domain is unworkable. It depends on how generic you can make it.
  • Cecil: If you take the core rim classes out, you cant from a design perspective.
  • Ron: Consumer of IM at the enterprise level, i have to map from mine to theirs this kind of stuff -
  • Lloyd: You have to create an analysis information model - there is a question to the level of detail. The amount of information at the Canonical level is small. You would not design by constraint at the analysis level.
  • Andy: Normally, you mash the whole thing together - the set gives you the value: at the logical level, you get individual views. The core of an IG is a logical model.
  • Ron: What is the value of the IF
  • Lloyd: The term RIM needs to refer to a logical enterprise model, an AIM is cool.
  • Cecil: The work done in the ontology community has tried to have an upper level.
  • Lloyd: You can take everything in Healthcare and fit into the RIM - at a high level. That is a succinct artifact.
  • Cecil: Allow us to re-used. Still a reference model, an analysis Reference Information Model.
  • Ron: Excellent conversation.
  • Lloyd: The matrix is more than a solution stack.
  • Ron: Yes. Row 29 "Where's datatype model? We need one at the logical level and probably need one at the conceptual level too. For that matter, we need datatypes at the implementable level as well - and those aren't algorithmically generated."
  • Cecil: we datatype at the abstract level when we discuss acts, etc.
  • Lloyd: We are defining a type.
  • Cecil: when we define that type, we then add the attributes, making it a datatype discussion.
  • Lloyd: Important distinction between class and datatype. Important to type the items in the conceptual model with something other than ISO, which dont exist in the conceptual model.
  • Wendell: In HL7 we have said the attributes specified by datatypes. They need to be specified in a IG. What is a conceptual datatype?
  • Lloyd: They will be conceptual - code, number, text.
  • Cecil: LOINC uses abstract datatypes.
  • Lloyd: Gives you and idea of the thing, without limiting a number to integer, real, etc.
  • Charlie: Speaks to grammers that exist that are related, but not equal.
  • Wendell: we are adding concept of datatype model.
  • Cecil: A datatype model categorizes things into groups.
  • Wendell: you dont want to group. It is not prescriptive.
  • Jane: The datatypes model starts to describe the logical use of the item.
  • Cecil: At abstract you have to define the name for the thing.
  • Lloyd: You have basic constraints at the model - e.g. you cannot add two text objects.
  • Ron: Interface model - No reference to an interface model.
  • Lloyd: CMETS are interface labels bound at specification time, and stubs bound at design time.
  • Stephen: would that not be in the IG?
  • Wendell: What is the concept missing in canonical that you would need to describe in the IG? Can you describe a CMET in the context of the canonical.
  • Lloyd: you are missing the interface. We have stub/templates. There is a UML construct for interface and model.
  • Cecil: A stub references another model, or the potential.
  • Lloyd: before the model is used you must bind the stub. You say you will have classes and attributes.
  • Cecil: it is a behavour.
  • Lloyd: There is a methodology as to when the parameter gets bound or the interface get bound.
  • Cecil: A class?

Adjourned at 11:33 Eastern.

Tuesday Q4

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Orlando WGM
Date: 20110517 Time: 3:30pm U.S. Eastern
FacilitatorRon Parker Note taker(s)Tony Julian
 
 MemberAffiliation MemberAffiliation
XMead, Charlie ChairNational Cancer Institute XParker, Ron Vice-ChairCA Infoway
.Quinn, John CTO Health Level Seven, Inc. XJulian, Tony SecretaryMayo Clinic
XBond,Andy NEHTA.Koisch, John Guidewire Architecture
XCurry, Jane Health Information Strategies.Loyd, PatrickGordon point Informatics LTD.
.Grieve, Grahame Health Intersections Pty Ltd.Lynch, Cecil ontoreason LLC
.Hufnagel, Steve U.S. Department of Defense, Military Health System .Ocasio, Wendell Agilex Technologies
.Shakir, Abdul-Malik Shakir Consulting   
Guests
.Hall, FriedaQuest Diagnostics, Inc..van der Zel, MichaelUMCG, the Netherlands
.Milosevic, ZoranNEHTA.Pech, BrianKaiser Permanente
Quorum Requirements Met: Yes

Minutes

  • Call to order
  • Reframing:

Here is a starting summary of Canonical Book key points (introduced in Introduction, may be elaborated in specific chapters, listed here in no specific order) – comments, edits, etc. welcome (i.e. hoped for):

Mostly stuff to reflect in the intro:

1. Reinforcement of dimensions x perspectives approach and value of that approach over “just ODP” use of dimensions and perspectives as a somewhat conflated notion of ODP Viewpoints : there has to be consistincy across the dimensions, and perspectives, and there may be different grammers for the same perspective: There is not necessarily computational traceability: we need to call out the value of abstraction to the deiverability of interoperability. (Not eveybody wants the same thing - as the deployment context gets larger, or interoperability context increases, you need to be more explicit). You can build an implementation guide for "drive-by-interoperability" easily. An enterprise guide needs to take a lot more into account. We need to disuss how the SAIF bridges the two. People think about design and interoperability together. Need expectations of the document - that is is NOT an IG, only the foundation.

Wendell: consider re-ording with ECCF first - there are concepts in the ECCF that rare discussed in the earlier chapters - when you get to ECCF there is an "AHA".

2. High-level but clear discussion of the goals of SAIF and why the term “Service-Aware” is used: There is a lot of confusion about the word service - John Q specifically wanted us to bring in the services, and what they bring as a sway of thinking. We can draw from T. Erl. Why do we bothere in having the SAIF at all? In the BF there are words that explain the difference between "drive by" and enterprise. (line 1057?) This is teh benefit of an IG. We need to address the question of the relevance of services to a community that is interested otherwise.

A. irrelevant;b: relevant, and you have to address; c. Maybe, maybe not.

3. SAIF canonical is developed solely to direct the development of SAIF-compliant SAIF IGs ? SAIF canonical definition must include specification of how compliance is achieved- the notion that a DSTU or Normative needs conformance. We will provide for September.

4. Discussion around “deployment contexts and interoperability types” as expressed in SAIF IGs, i.e. a SAIF IG can provide an approach to SAIF compliance that is not necessary “all or nothing”


5. SAIF canonical should not be HL7-specific. Can, however, provide – in an Appendix – of HL7 examples of how canonical concepts can be instantiated as HL7-specific constructs, e.g. application roles, information models developed by constraint, etc. We got a good understanding about how to frame the canonical so that you can do an HL7-RIM based, or Open EHR based, but not require either. Be sure to annotate the appendix as non-normative. What is the required level of specification of the building blocks in the IG's? We can state the explicit requirements of a terminology model. You can do the same from a data-type perspective - require distinguishing of semantic types of data. The enumeration of upper levels concepts was short.

6. Notion of “consistent but not necessarily identical grammars” that exist between the three Perspectives Grammers describing the framework? The set of concepts - you will have a different set of concepts at a different level - the grammer for conceptual level is not the same as that for logical. The canonical is the "meta-grammer". Lloyd thinks everything should be specified in UML. You can use different grammers in different perspectives. The IG is written using the grammer in the Cannonical. Zoran: Why do we need to worry about constraints at this level? Because if you say the IF grammer produces models by constraint, you eliminate the ability to generate models by sub-typing/inheritance. We need to express that either is possible, but we may not be able to do both simultaneously. "if you are going to build a SAIF IG, you have to use these grammers". There may be a different set of constructs at the conceptual level vs. the logical level. If the RIM is a model, then the SAIF book should have a metamodel with prescribing the constraints on a model. Wendell, Charlie, and Andy need to resolve this.

7. IF: Discussion of approaches to information modeling must be clear that modeling by constraint (e.g. RIM-based) vs modeling by subtyping (e.g. openEHR) as both consistent. If there are specific contraindications to “combining” the two approaches, these need to be clearly stated

8. BF: See particularly #5 in terms of examples RE lack of historical HL7 Conceptual Perspectives, and #2 in terms of Application Role mapping, etc.

9. ECCF: see #1

10. GF: tie to communities from BF

Jane: There are a form of communities in the GF which the BF assumes.

11. I have developed my conceptual perspective having defined my community, policies, roles, interactions, etc. How does my conceptual perspective play out in a V2 world, V3 world, and “pure” SOA world?

  • Adjournment at 5:00pm

Thursday Q3

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Orlando WGM
Date: 20110519 Time: 1:45pm U.S. Eastern
FacilitatorRon Parker Note taker(s)Tony Julian
 
 MemberAffiliation MemberAffiliation
XMead, Charlie ChairNational Cancer Institute XParker, Ron Vice-ChairCA Infoway
.Quinn, John CTO Health Level Seven, Inc. XJulian, Tony SecretaryMayo Clinic
XBond,Andy NEHTA.Koisch, John Guidewire Architecture
XCurry, Jane Health Information Strategies.Loyd, PatrickGordon point Informatics LTD.
XGrieve, Grahame Health Intersections Pty Ltd.Lynch, Cecil ontoreason LLC
XHufnagel, Steve U.S. Department of Defense, Military Health System .Ocasio, Wendell Agilex Technologies
.Shakir, Abdul-Malik Shakir Consulting   
Guests
.Hall, FriedaQuest Diagnostics, Inc..van der Zel, MichaelUMCG, the Netherlands
.Milosevic, ZoranNEHTA.Pech, BrianKaiser Permanente
Quorum Requirements Met: Yes

Minutes

  • Blank grid is the interoperability template.
  • A template that contains one or more artifacts is an interoperability instance.
  • SAIF is expressing functionality as expressed in interoperability.
  • Need appendix of examples in both releases.
  • There are changes to make to the informative:
  • 1. Clear in our description of the purpose of the canonical, and the relationship to an implementation Guide.(verify in outline)
  • 2. Flush out general notion of what it means to define specifications (what is a grammer). What does traceability mean?
  • + flow and consistancy
  • Late July
  • For DSTU, add how an IG conforms to the canonical - IG must conform to canonical.
  • Clairify definition of grammer, and the sense of it.
  • need to be specific about "service aware".
  • Everyone on the current ArB is participating with the exception of one - Abdul-Malki Shakir. TSC is replacing AMS with Zoran.
  • MMS to remove Abdul-Malik Shakir from the Arb (Steve/Grahame)(6-0-0)
  • MMS to add Zoran Milosevic to the ArB(Grahame/Jane) (6-0-0)
  • JUNE 6: Update Mission and Charter, and resolve the comments.

Thursday Q4

Meeting Information

HL7 ArB Work Group Meeting Minutes Location: Orlando WGM
Date: 20110519 Time: 3:30pm U.S. Eastern
FacilitatorRon Parker Note taker(s)Tony Julian
 
 MemberAffiliation MemberAffiliation
.Mead, Charlie ChairNational Cancer Institute XParker, Ron Vice-ChairCA Infoway
.Quinn, John CTO Health Level Seven, Inc. XJulian, Tony SecretaryMayo Clinic
XBond,Andy NEHTA.Koisch, John Guidewire Architecture
XCurry, Jane Health Information Strategies.Loyd, PatrickGordon point Informatics LTD.
.Grieve, Grahame Health Intersections Pty Ltd.Lynch, Cecil ontoreason LLC
XHufnagel, Steve U.S. Department of Defense, Military Health System .Ocasio, Wendell Agilex Technologies
.Shakir, Abdul-Malik Shakir Consulting   
Guests
.Hall, FriedaQuest Diagnostics, Inc..van der Zel, MichaelUMCG, the Netherlands
.Milosevic, ZoranNEHTAXPech, BrianKaiser Permanente
Quorum Requirements Met: Yes


Minutes

  • All authors should update concept maps, and forward to jane, ensuring consistency with the narrative.
  • Concepts in the narrative dont all have to be in the concept maps:
  • All concepts in the map need to be in the narrative.
  • Line 469 - Is this a healthcare SAIF? The feeling is yes - managing complexity in healthcare.
  • Ballot reconcillation completed for all Negatives
  • Meeting was adjourned at 5:00pm U.S. Eastern

Tony Julian 17:01, 12 May 2011 (UTC)