Minutes of the XML TC

Minutes of the XML TC HL7 Winter Working Group Jan 2000

(Action items are in RED.)

1 JAN 24, 2000 TSC MEETING...... 2

2 JAN 25, 2000 TUES AM...... 2

2.1 PRE-BREAK: OVERVIEW / UPDATES / NAME AND CHARTER CHANGE...... 2 2.2 POST-BREAK: JOINT MEETING WITH IMSIG...... 3 3 JAN 25, 2000 TUES PM...... 3

3.1 PRE-BREAK: PRA BALLOT RECONCILIATION...... 3 3.2 POST-BREAK: PRA BALLOT RECONCILIATION...... 3 4 JAN 26, 2000 WED AM...... 3

4.1 PRE-BREAK: LEVEL TWO / DOCUMENT ONTOLOGY...... 3 4.2 POST-BREAK: MEETING WITH M&M TC...... 4 5 JAN 26, 2000 WED PM...... 4

5.1 PRE-BREAK & POST-BREAK: HARMONIZATION WITH MEDICAL RECORDS...... 4 6 JAN 27, 2000 THURS AM...... 5

6.1 PRE-BREAK: RECONCILIATION ISSUE, NEW PRA ISSUES...... 5 6.2 POST-BREAK: WITH CQ ON XMI...... 5 7 JAN 27, 2000 THURS PM...... 6

7.1 PRE-BREAK: WITH CQ...... 6 7.2 POST-BREAK: NEW PRA PROPOSALS...... 6 8 M&M EVENING MEETING...... 9

9 JAN 28, 2000 FRI AM...... 10

9.1 PRE-BREAK: CEN DISCUSSION...... 10 9.2 POST-BREAK: LOGISTICS / PLANNING...... 10 1 Jan 24, 2000 TSC Meeting  XML SIG was advanced to TC status, with the caveat that we review our mission/charter and our name to the satisfaction of the Architectural Review Board prior to the Cleveland meeting in May, 2000.

2 Jan 25, 2000 Tues AM

2.1 Pre-break: Overview / Updates / Name and Charter change Attendees: Liora Alschuler, Paul Biron, Bob Dolin, Rachael Sokolowski, Karen Keeter, Bob Moe, Calvin Beebe, Mike Cassidy, Joe Foster , Helen Gurevich, Teri Johnson, Carl Adler, Laura Migas, David King, John Meek, Tom Lincoln, Kai U Heitmann, Charles Young, Vassil Peytchev, John Majerus, Sandy Boyer, Craig Luce, John Silva, Bill Drummond, Leo Fogarty, Joachim Dudek, Andrew Hinchley

 Brief history of the SIG, which was advanced to TC at last night's TSC meeting.  Introductions of attendees  Review objectives and agenda for the week.  Will need to review our mission/charter and our name  W3C update (Paul Biron):  W3C Schema working group plan for next week in Berkley is to close all open issues in order to move to "candidate recommendation" status. Hopefully all open issues can be closed, but there are quite a few.  W3C progression of recommendations: working draft --> proposed recommendation (period of review) --> can move to candidate recommendation status (Schema working group asks for implementers to test and give feedback - things that aren't well known until tested. Will probably request 4-6 months in this status. This will hopefully make the next stage much shorter) --> proposed recommendation --> recommendation (final state).  Dec 17th working draft is "feature complete", but the way those features are implemented may vary.  Digital Signature group (joint group with IETF) - Would be useful to plan a session at the Cleveland meeting to get a more thorough update on this. Should include SIGAQP, Security, etc.  Packaging Working Group - Early in the groups inception still. Charter includes a determination of how to package a document with an included image such that standard browsers could display. (As opposed to linking to a binary image file.)  Query Working Group - Currently there is no HL7 representative to this group. Not entirely clear that HL7's needs won't be met with the current group's makeup. Joachim Dudeck feels that querying messages on remote servers should be done in XML and should be part of the Query groups scope, and that it is not currently being addressed. Paul states that the group is not charted to develop an XML syntax to exchange SQL queries.  Discussion of charter / mission / name change  Main activities have been: education, XML-ITS, and PRA  Issues raised in TSC meeting:  XML is a syntax, a technology, therefore not a suitable name for a TC.  Overlap in scope / need to clarify this with the Architectural Review Board - CQ, Medical Records. TC's - some cut across domains (CQ, M&M) while others are centered around a functional domain (PAFM). The XML TC covers both - because we define the clinical document and we customize the ITS by using the MDF99 somewhat differently.  "XML" in our name helps increase attendance, but may need to be removed in order to meet ANSI rules. Could consider "markup", etc. "XML" in our name may be misleading - attendees are looking for XML for messages, for instance. 2.2 Post-break: Joint meeting with IMSIG Attendees: Liora Alschuler, Paul Biron, Bob Dolin, Rachael Sokolowski, Karen Keeter , Bob Moe, Calvin Beebe, Mike Cassidy, Joe Foster, Helen Gurevich, Teri Johnson, Carl Adler, Laura Migas, David King, John Meek, Tom Lincoln, Kai U Heitmann, Charles Young, Vassil Peytchev, John Majerus, Sandy Boyer, Craig Luce, John Silva, Bill Drummond, Leo Fogarty, Joachim Dudek, Andrew Hinchley

(Please the PRA Ballot Reconciliation document for greater detail.)

 Unique-identifier  Current PRA requires contatenation of clinical_document_header.id + clinical_document_header.version_nbr.  There is no provision in PRA to guarantee that two parallel systems don't generate the same version_nbr at the same time - therefore, even the concatenation cannot be guaranteed unique.  Alternatives:  clinical_document_header.id is of type II  change parent_id to point to (0..*) parent_OID  values of change_cd also can include "append" (or do we leave change_cd as is, and add some other attribute to capture the nature of the parent-child relationship?)  add an attribute clinical_document_header.local_id  type  optionality

 Relationship to DICOM and other standards  Made revisions to PRA Reconciliation package to reflect our relationship to DICOM.

3 Jan 25, 2000 Tues PM

3.1 Pre-break: PRA Ballot reconciliation  Discussed PRA ballot : reconciliation of comments: editorial, scope, clarity issues.

3.2 Post-break: PRA Ballot reconciliation  Discussed PRA ballot : reconciliation of comments: editorial, scope, clarity issues.

4 Jan 26, 2000 Wed AM

4.1 Pre-break: Level Two / Document ontology Attendees: Liora Alschuler, Bob Dolin, Sandy Boyer, Jeff Blair, Mike Cassidy, Carol Broverman, Helen Gurevich, Vassil Peytchev, Ed Jones, Ton Lincoln, Joe Foster, Elliot Loh, John Silva, John Majerus, Carl Adler, Craig Luce, Calvin Beebe, Angelo Rossi Mori, Gerard Freriks, Leo Fogarty, Rachael Sokolowski, Ed Hammond, Stan Huff, Paul Biron, Eddie Feather, Rau Nyman, Karen Keeter, Joe Estrada, Carols Sanroman, Kenzo Gushiken, Bill Drummand, Stewart Haight.

Rachael Sokolowski - ASTM E31 report - DTDs for different document types. (Report of workshop) - analyzed documents of varying types, comparing section names. Based on this analysis, build draft DTDs. Bob Dolin raised question - how do section labels overlap with observation contexts and observations themselves. For instance, the label "contrast agent and dose" or the label "date.of.previous.study" - how do these labels overlap with the observations and the context of those observations within PRA Level One (where we can't assume any semantics of the contents) and PRA Level Three, where we could potentially inherit context from the section labels. Liora - Discussion of comparison with HCFA 1500. Angelo - cannot establish a coherence between section labels and observations contained in that section. Calvin Beebe - document type vs. need for service procedure code(s). Mayo may use very generic clinical document types, and would like to specify service(s) in the header. Mayo's notion of a document type is that is equates to a DTD, including the sections included within. Discussion around difference between post-coordination and use of more generic document type code along with a field for service(s) being documented. Will vendors understand the code phrase data type? Post-coordination (use of code phrase) has in the past been foreign. Stan Huff - multiple different axes are independently important when looking for documents. Each of the meaningful parts should be carefully identified. Angelo - document category, and perhaps 1000-2000 document types. Stan - most systems don't differentiate service from report of that service. Bob - Use generic document types as per Mayo, assume that document type prescribes the DTD. If we use the service code, it doesn't necessarily impact the DTD. If the intent is that the service does impact the DTD, it should be pre-coordinated in to a document type. If the intent is to apply template(s), should they also be part of the document type (and therefore prescribe the DTD)? Calvin - the problem is all the existing document types out there. Does the document type prescribe the contents of the document? Or should the service prescribe the contents of the document? Stan - will be hard / impossible to fully specify the allowable sections by document type. Bob - Consider document type to be semantically equivalent to document-type plus service. In other words, report-of-CT-of-head is equal to document- type="ct-report", service="CT-of-head", which is equivalent to post-coordination "ct-report :: documents- service CT-of-head". In either of these cases, we may have at best a prescribed list of coarsely grained specifications. Liora - implication of using service code in header for classification of document types? Stan - proposes just the use of the single field, and not the separate field for service. Utilize the hierarchy to determine the coarser granularity. Use the most specific document type you know. Would prefer not to post-coordinate, but to pre-coordinate within LOINC. Angelo - if everyone uses different lists, this won't work. Contingent on, say, adoption of list by LOINC. Stan - LOINC is and will take this on. Liora - we need to summarize our requirements as a result of this discussion. Bob - Relationship between value of clinical_document_header.type_cd, the DTD of the document, and templates used is a bit fuzzy still. Stan - has a proposal on this. Also has created a document that specifies radiology report names within LOINC. May be that clinical_document_header.type_cd really means "this is a documentation of a service of type", and then you just use the service code period.

4.2 Post-break: Meeting with M&M TC Attendees: Liora Alschuler, Paul Biron, Bob Moe, Rachael Sokolowski, Leo Fogarty, Andrew Hinchley, Calvin Beebe, Craig Luce, John Majerus, Elliot Loh, Ted Klein, Tom Lincoln, Ed Jones, Yasser Alsafadi, Kevin Chalk, Helen Gurevich, Jason Williams, Carol Broverman, Mike Cassidy, Jeff Blair, Sandy Boyer, Rau Nyman, Chris C. Smith, Daniel Trainor, Carl Adler, Bill Drummond, Dav A. Eide, Kenzo Gushiken, Ron DiMiceli, Ed Larson, Dean Bidgood, Gerard Freriks.

 RIM Harmonization / ballot comments requesting new RIM attributes or vocabulary  Ted Klein - This is new ground. TCs have stated that RIM 0.94 does have all fields that are part of V2.x, plus more. RIM is an artifact that enables the construction of messages, and will continue to evolve. RIM 1.0 will be "frozen". Open M&M issue is how to change things, and how to change things once messages are derived from a RIM version. Another issue being considered is how to add include fields in a specification that are not yet in the RIM. May be possible to enumerate the type of notes - such as "proposed", etc.

 PRA Level One Body UML model was discussed. Ways to modify it were discussed. No clear action plans for bringing the model to harmonization were yet determined.

5 Jan 26, 2000 Wed PM

5.1 Pre-break & Post-break: Harmonization with Medical Records Attendees: Harry Rhodes, Bob Dolin, Liora Alschuler, Bebbie Stillman, Mike Ball, Bob Anders, Tom Lincoln, Kelly Nabours, Jeremy Smith, Dave Feinberg, Eileen Koski, Ron DiMireli, Bob Moe, Rachael Sokolowski, Paul Biron, Wayne Tracy, Sandy Boyer, Anne Shanney, Craig Luce, Calvin Beebe, Andrew Hinchley, Gerard Freriks, Leo Fogarty, Tony Seeger, Ken Rubin, Joe Foster, John Leslie, Bill Drummond, Carl Adler, Art Bechtel.

(Please the PRA Ballot Reconciliation document for greater detail.)

 Unique document ID Recognition that clinical_document_header.id is of type Instance Identifier, therefore must change with revisions. We can change the data type such that it is not II (and change attribute name per stylistic guidelines). And need a true "id" of type II. parent.id (target of parent association) - target includes both id's. Both identifiers are required. (In the case of replacements, where the local.id may be null, only will have the "id", and the local.id will be null - so, required, but not mandatory.)

Will examine use cases for having a child with multiple parents, along with role class.

 Wayne's ballot comments PRA becomes PRAF - "F" is for Framework.

 Anne's ballot comments Will review revised document, but tends to feel that major issues were addressed. 1 - resolved by change to PRAF 2,3 - resolved by description of super-structure / inclusion of need for MDM construct. 4 - resolved by a combination of the above two. 5,6,7 - resolved by the reorganized structure.

 RIM Harmonization proposals Will continue to work on this. Woody will work on state diagram for clinical documents. Will need to formulate specific harmonization proposals based on agreements reached.

6 Jan 27, 2000 Thurs AM

6.1 Pre-break: Reconciliation issue, New PRA issues Attendees: Liora Alschuler, Bob Dolin, Gerard Freriks, John Majerus, Ed Jones, Craig Luce, jCarl Adler, Calvin Beebe, Al Figler, Yasser Alssafadi, Charles Young, Tom Lincoln, Fred Behlen, Alfredo Tirado- Ramos, Sridhar Iyengar, Vassil Peytehev, Mike Cassidy, Andrew Woyak, Chris Melo, Fred Bernhardt, Eddie Feather, Petten Ihabwnen (?spelling), Garry Johonson, Jeremy Smith, Kai U. Heitmann, Michel Dautevil, John Walton, Bill Drummond, Paul Biron.

 Response to Al, Fred's comments were completed (see reconciliation package).

 Codification of document sections in PRA Level One - proposal by Bob Dolin. Some issues raised include: Rather then section.cd, container.cd which is equally applicable to sections and other containers. The need to differentiate from, say, coded_entry needs to be clear. Need to evaluate more closely how coded_entry would work here.

6.2 Post-break: With CQ on XMI (See also, CQ Meeting Minutes) Sridhar's presentation on XMI, MOF. (See powerpoint presentation for details) 7 Jan 27, 2000 Thurs PM

7.1 Pre-break: With CQ  PRA and use of V3 data types Should the V3 data type DTD go to ballot? Gunther's current document needs to be updated, and revised into more of a "standard"-like document. Paul Biron volunteers to help work on this. We would also include both the DTD and the approach to deriving the DTD. Consensus that the V3 data type DTD should be normative. Need to differentiate the abstract data types, and the ITS-specific implementation. Need to be sure that the data type DTD in the PRA ballot are clearly shown to be global V3 data types. CQ is responsible for normative data type. Depending on timing issues, PRA may wind up putting V3 data type DTD as a non-normative appendix.

 Sending PRA documents in V2.3 messages Consensus to use MIME encoding. Will work on the exact values off line, and add necessary values to HL7 V2.4 tables in time for ballot.

 V2.3.1 XML ITS Use of MS "smart quote characters" in the HL7 database. Would prefer to remove these smart quotes from the database, although if this isn't practical, can do minor technical corrections to the DTD generation algorithms.

 V2.4 XML ITS Are there any new chapters that would require changes to the structure of the HL7 Database? Perhaps 0O1 and 0O2 - may need the ability to represent a choice by way of new character.

 V3 XML ITS Removing intervening classes - should be okay so long as the association names are different. This is not "flattening", but rather, removal of intervening classes from which no attributes are used in the current specification.

7.2 Post-break: New PRA Proposals Attendees: Ed Jones, Garry Johnson, John Majerus, Carl Adler, Calvin Beebe, Bill Drummond, Fred Behlen, Mike Cassidy, Fred Bernhardt, Bob Dolin.

Return to coded section discussion.

 Codification of document sections in PRA Level One.  Proposal: Add the ability to unambiguously assign a code from a standard coding scheme to a document section.

 Rationale: (1) Standard coding schemes are creating codes for document sections. Document sections are also specified within HL7. We need to have the ability to indicate the code for a document section. For now, local implementations will have to agree on the domain of allowable codes. (2) As PRA Level Two moves towards the creation of a document ontology, and we want to link a particular document type to a particular set of document sections, we will need to have a method for codifying sections. (3) The code for a document section should be optionally repeatable, since there may be the need to code a section with codes from more then one standard coding scheme.

 Specifics:

change this: to this:

add this:

 Example:

change this:

to this:

Seems to be a need to codify all containers, not just sections. Better to use a CD rather then repeating if the intent is to have, say, a LOINC code and a Mayo code. Feeling is to add this to the caption. change this: to this: - this is an "XML Mixed Content model". The "HL7 Processing Rule" would state the lack of repeatability. caption_cd is optional, non-repeatable, of type CD.

Consensus of the 10 members - 10 approved.

 Clarification of target ID for originator and confidentiality  Proposal: Rename the attributes serving as the target IDs for originator and confidentiality to add further clarity to PRA.  Rationale: The XML DTD only enforces that an IDREF point to some valid ID within the document. We want to be unambiguous in explaining exactly which ID value(s) are the correct targets of body- atts "originator" and "confidentiality". For PRA Header element "clinical_document_header.confidentiality_status_cd", there are no nested components, so it is pretty clear. But PRA Header element "originator" and PRA Header element "originating_device" each have a nested element "id". Is the target ID the ID of "originator" or is the target ID the ID of the nested element?  Specifics:

Change this:

To this:

Change this:

To this:

At a minimum, need to clarify the exact target of the IDREF(S) anywhere they are used in PRA. The above approach seems to require more manual maintenance, and therefore, the proposal is withdrawn. Pointing to the ID attribute of the following elements:  clinical_document_header.confidentiality_status_cd  originator  originating_device

The current representation of originating_device seems to be incorrect and needs to be reviewed.

8 M&M Evening Meeting Described where PRA differs from MDF99, and discussed M&M issues encountered.

 Header Issues  Flattening intervening classes - needs further discussion.  Use of "( )?" construct in all content models - Wes agrees that this is not necessary if the containing element is Mandatory, and will revise tooling accordingly.  XML element naming conventions used by PRA:  RIM Attributes: XML element name equals the RIM attribute name, except where the RIM attribute's data type is CV or CD, in which case the XML element name prepends the class name onto the RIM attribute name. (X-ref Wes's email on .nm, which can be of two different data types.) M&M Suggestion: Prepending the class name is ITS-specific. The HMD doesn't need to necessarily contain it. Alternatively, consider adding an "XML element name" column (along with the naming conventions)?  RIM Associations: XML element name equals the name of RIM associations. In those cases where the target of the association is semantically more meaningful than the association name, and where there is only one path by which one can traverse to the target class, the XML element name equals the name of the target class. M&M Suggestion: This can be considered ITS-specific. Consider adding an "XML element name" column (along with the naming conventions)?  Representation of sets: Sets and RIM associations with >1 cardinality are modeled as follows:  An association with >1 cardinality:  FOO has-zero-to-many (0..n) BAR:  FOO has-one-to-many (1..n) BAR:  An attribute with SET : FOO.id is of data type SET :  if attribute is optional:  if attribute is required:  Repeatable data type components are modeled in this manner as well.  How to model an originating device? (within scope lab automation) - talk to Gunther  Adding a "proposed" item to the balloted HMD? Described our approach.  Harmonization issues (These issues were discussed in joint session with Med Rec on 1/26/2000.)  clinical_document_header  clarification of "id" as a true II.  addition of a local.id  target of recursive association includes the true "id"  ?? new association to recipient - needs further analysis.  ?? delete some attributes - needs further analysis.  address open issues  state diagram

 Body Issues  HBD - representation of "or" groups: contains_A_or_B which is of type A or of type B : Need to somehow make specific reference to A or to B - need to show that, say, A was previously defined, or to say that B can recurse. (Can only currently represent choice for gen-spec?).  Preparation of UML model of PRA Level One body.

 V3 Data Type issues  Logistics of balloting V3 data types, as a follow on to today's discussion with CQ. M&M Decision: Need to ballot the abstract piece and need to separately ballot the ITS (which includes the DTD). These will be balloted under the auspices of CQ. Leave in the V3 data type DTD in the PRA as a non-normative appendix, and reference the current ballot.

9 Jan 28, 2000 Fri AM

9.1 Pre-break: CEN discussion Attendees: Carl Adler, Sandy Boyer, Bob Moe, Dick Harding, Alfredo Tirado-Ramos, Yasser Alsafadi, Gary Dickinson, Mike Cassidy, Bob Dolin, Liora Alschuler, Leo Fogarty, Angelo Rossi Mori, Harry Rhodes, Tom Lincoln, John Majerus, Calvin Beebe, Steve Wagner, Paul Biron.

Brief reports of previous sessions from yesterday.

Leo Fogarty's presentation: XML, EHCR, PRA, and U.K.: Method of transferring whole records between systems. (See accompanying powerpoint presentation "Minutes.Leo Fogarty CEN Presentation.ppt".)

Q&A session: EHCR transfers the chart as a message. Is there a CEN structure that corresponds to a "PRA document" - is this a "composition"? Angelo feels that this is the closest approximate match.

Potential areas for PRA / CEN collaboration  Compare CEN metadata to PRA Header, recognizing that the RIM is the focal point of harmonization.  Compare / contrast CEN link specification with PRA link requirements.  How can a PRA document be properly contained in a CEN structure - what is the proper place to place it?  Compare CEN to PRA, for instance:  What CEN structure most closely correlates with the "PRA document"?  What CEN structure most closely correlates with the PRA section (and other containers)?

9.2 Post-break: Logistics / planning  Mission / charter - needs to be cleared by the ARB prior to Cleveland.  Ballot - would prefer to go for full membership ballot. Time-wise, may need to have ARB (or TSC vice-chair) approval. The next meeting is 5/22. If we want to have 2 weeks for reconciliation, the next ballot would need to close by ~5/8, and therefore the call for ballot needs to be issues ~3/6. Therefore, if we want to move forward to full membership ballot, we would need to have approval to do so by 3/6. If the ARB needs ~2 weeks to review, then we should have a package for them in ~3 weeks. But at a minimum should proceed to at least committee-level ballot again.

Return to

Seems to be a need to codify all containers, not just sections. Better to use a CD rather then repeating if the intent is to have, say, a LOINC code and a Mayo code. Feeling is to add this to the caption. change this: to this: - this is an "XML Mixed Content model". The "HL7 Processing Rule" would state the lack of repeatability. container_cd is optional, non-repeatable, of type CD. rename "caption_cd" to "container_cd" and need to be sure that all uses of the word "container" include sections, and all other types of containers - section, paragraph, list, item, table.

These are the elements that contain a caption tag in the current PRA Level One Body DTD:

Tentative schedule for Cleveland meeting, May 2000, coming under separate cover.

--- end of minutes ---