These minutes include the minutes of the HISPP/MSDS/JWG: Modeling, as well as the minutes of the QA/DM Technical Committee JOINT MODELING WORKING GROUP SUMMARY OF MEETING May 17-18, 1993 Attendees: George Beeler, Ted Lau, Debbie Hess, Mark Shafarman, Auden Forrey, Abdul-Malik Shafir, Mark Tucker, Alton Brantley, Margie Stahler, Laurema Rei, Chuck Meyer, Eric Swanson, Muhammad Asomi, Holley Davis, Santosh Gandhi, Bob Evola, Wayne Johnson, Steve Wagner, Brian Romano, David Smith, Rita Altamore, Bob Hearn, Scott Belmont, Douglas Benn, Buck Locke, Doug Marquis, Norman Daoust, Wayne Tracy, Wm (Billy) Salter (wsalter@bbn.com), Glen Johnson, Gary Dickinson, Lee Barrett (X12 N insurance:X.400:Telemail-Aetna-AL), John May, Tom O'Brian, Robert Dorfman, Russell Hynds, Mead Walker, Jim Hoath, Jack Harrington, Clem McDonald, Ed Hammond Representatives: George Beeler (MEDIX) Mead Walker (HL7) Aden Forrey (ASTM) A. Objective: It was restated that the meeting was to address the issue of message standards unification. B. The group reviewed and endorsed the 4 requirements brought forward from the Orlando meeting of ASTM, HL7, and MEDIX, summarized as follows: 1. Need for a common data model framework or metamodel. 2. High level object model to rationalize the MSDS partitioning. 3. Shared, common data model accepted by the various message standards bodies. 4. Message development process by various standards bodies, with conflict resolution/model conformance by some committee. C. The object-oriented methodology of Coad-Yourdon was reviewed and endorsed as the provisional working method for the session. D. The draft of the Outline for a Version 3 Framework, and the metamodel of the messaging standard domain contained therein, was used to conceptually clarify an approach to message standards development. Over the course of the meeting, through an emphasis on data orientation divorced from process/event, computational, and messaging orientation, the following general agreement was reached: That the portion of the messaging metamodel representing the "object view" roughly defines the structure and content of the data model to be shared by the standards bodies. Issues of attribute optionality and events, among other "extensions" to the data model, are conceived to be a part of each standards-body specific messaging metamodel. E. The data view metamodel was reviewed in detail. There is broad agreement that the following object classes are part of the common domain: Subject Area, Class&Object, Attribute, Instance Connection, Structure, and Attribute Domain. Agreements and open issues relative to these entities are itemized in the full minutes of the meeting. A draft proposal to resolve remaining issues will be developed and circulated. F. A high level object model of the healthcare domain was described interactively. G. The process of how to proceed with the various standards organizations was discussed. It is recommended that MSDS sanction joint modeling activities. H. Action Items: Publish summary of meeting (herein) Publish minutes of meeting Draw & describe high level objects outlined during meeting Draft object model metamodel document Common data model (one level deeper) at next HL7 meeting The HL7 QA/DM Technical Committee met on Thursday, May 20 The disucussion covered a number of topics as indicated below: The issue of a CASE tool for HL7 Jim Fry stated that he leans towards System Architect (Popkin Assoc.) as opposed to OOA (Coad &Yourdon) because System Architect has a more robust data dictionary. On the other hand, it was stated, If MEDIX is the responsible one, why not have them support the data dictionary. On the other hand, we need to be able to accept the model from MEDIX in machine readable form. The group posed the following questions: Which tool should we buy How many should be bought? Should we have one per chapter? Perhaps we should get a $100 Coad & Yourdon (this is the demo version which allows models with a limited number of objects for the chapter chairs? After discussion, we agreed that the issues are mainly organizational not technical, and that not resolving them is the main factor that has been ham-stringing HL7's forward progress in this area. Perhaps the tool choice should be made at a HISPP level. On the other hand, the way HISPP/MSDS has worked, we can't expect it to provide us direction for which CASE way to go. Several proposals emerged in the course of the discussion: We should get try to get direction from HISPP/MSDS/MEDIX. (We agreed to contact HISPP//MEDIX to see their direction, and to see if they have any firm deadlines.) The committee should raise these organizational issues with the HL7 chapter chairs; we need to know how HL7 plans to use the tool, before we get one or even make a tool choice. Dave Marotta proposes, proposes that the group approach the HL7 Executive committee with the suggestion that it buy a tool, and get a small group to use the tool to blast out a model that will be usable as a high-level model. Once this is done, the domains of that high-level model be used as a basis for dividing up the HL7 tech committees to get the work done. This would imply that we re-order HL7 by object subject area instead of by groups of trigger events. The chapters should be re assigned by domain instead of functionally. Dave added that he doesn't see any reason to get a tool until we know how to use it. As far as getting individual tools for each technical committee, how can we give a group a tool unless they have included in it the parts of the common model that they need? He had some concrete suggestions for the HL7 Working Group. What if we just have breakout sessions on model contents at the next several meetings? Alternatively, divide up technical committees by the high level objects. Specifically: for a year, do nothing but data model in small groups divided by high-level object. At the end, we could get together and critique the outcome. Why not pick an object for the next DM committee and do a discussion on it and try to develop the attributes. Due to the small size of the group, we recorded these proposals but didn't vote on them. QA of version 2.2 The group decided that there was no basis for this committee to take a formal role in QAing 2.2. V2.2 was not based on a specified framework, therefore no is no basis for formal review on the part of the QA committee. Since V2.2 is backwards compatible, there isn't any opportunity to call for or suggest structural changes. We could try to improve definitions and the like, but changes for such things as definitions should be the responsibility of domain experts. They really aren't in the scope of the QA committee. At the same time, individual members of the committee should be available to help review the V2.2 draft as members of the Working Group as a whole. We touched on the modeling framework. There was little discussion. Essentially the group felt that, the HISPP/MSDS/JWG was moving this effort forward. For us, the time is to model, not to talk about modeling. Gary Dickinson raised a more general point for developing the HL7 model To do messages you have to know the application boundaries. HL7 has done well where those boundaries are well known; it is starting to have a hard time where the application boundaries are undefined. In the long run, the hardest job is to define the application boundaries. Therefore, we need the Global data model, but we need to define subsets of the model corresponding to the individual applications. When two applications send one message to another, they need to consider as contents of the messages, those objects which belong to the junction of the two subsets. Dave Marotta make another suggestion based on but going farther then his initial remarks He suggests that HL7 needs to consider a radical approach. The suggestion is that HL7 extend its scope and consider not only the interfaces between applications, but interfaces within a single application domain. Insert the bitmap "minmay93.bmp" here. Dave feels that with a trigger event you have no idea of what the recipient of the application will do. He argues for an API concept in which there is an expectation that the receiving application will do something with the message and will send a return code indicating what it will do. Dave is suggesting that today's V3 process is trying to fill out the right column below, while the left column is the proper goal. V3.0 Marotta's Vision rigorous data model relational 3NF normalized data model trigger events Remote Procedure Calls and Application Program Interface data flows specified inputs and outputs Boolean return codes: Y/N fully functional return codes. E.g., I heard you I did it (this is what I did) I didn't do it (this is why) Note that to Dave the distinction between a trigger event and an API is that with the trigger event the sender is left unsure of what the receiver did with the message, where with the API the receiver takes on the obligation to tell the sender what it did. We are throwing out these ideas for consideration for the Working Group, not including them as proposals from the QA/DM committee.