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

ITS WGM Minutes 2011 Jan

From HL7Wiki
Revision as of 07:10, 1 February 2011 by Astechishin (talk | contribs) (→‎Q2)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

ITS - Sydney Australia, WGM January 2011

Co-Chairs

Paul Knapp (PK) Dale Nelson (DN) Andy Stechishin (AS)

Monday, January 10

Q1

Chair: PK Scribe: AS

Discussion of planned activities for the week

Brief discussion of Green CDA and its relationship to ITS WG

Discussion on hData preparations for ArB session.

Agenda updates posted to Wiki and a message sent to the list server

Q2

Chair: PK Scribe: AS

The group produced the following table of specifications:

Project Status Notes
DT Abstract (MnM)
1.0 Norm (2002ish)
1.1 Info (2009/10) -> Norm (?)
2.0 (ISO) Norm (2008/09)
XML ITS 1.0 Norm (2002ish)
1.1 Norm (2008) extensions like SPL
2.0 Norm (2010) {ITS 1.1 + DT 2.0} is it 1.2?
Rim ITS 1.0 Norm (2010)
V2 ITS VBar Norm (80/90)
XML Norm (2002)
UML ITS 1.0 Norm (?) (2005)
hData Record Fmt 1.0 Comment (2011Jan) -> DSTU 2011May -> Norm
Restful API Comment (2011Jan) -> DSTU 2011May -> Norm
Transports
MLLP Norm (2005ish)
Web Services 1.0 DSTU (depr 2004)
2.0 DSTU (2006 not published)
3.0 Norm (stalled) review in May
ebXML 1.0 DSTU (2006ish) ballot Norm 2011May
2.0 Norm (2008 not published)
ISO9446 1 ballot (committee) Park
Uncategorized
Neutral Mapping
Simple ITS
Green CDA
Micro ITS
JSON ITS

The groups decided to create an hData specific PSS letting the ArB determine which WG should own.

At the May, 2011 WGM, ITS will announce that it is looking to deprecate UML ITS and ISO9446 at the September 2011 WGM. Allowing users of the specification plenty of time to raise objections.

Q3

Chair: PK Scribe: AS

hData Record Data Format ballot reconciliation

  • Results recorded in the ballot spreadsheet.

It was generally agreed that adding an RMIM and presenting the document in tradition HL7 v3 format would allow reviewers to better evaluate the content.

Q4

Chair: PK Scribe: AS

hData Record Data Format ballot reconciliation completed details recorded in the ballot reconciliation spreadsheet. Ballot reconciliation of the hData RESTful API started. The RESTful API document will not complete reconciliation at the WGM as commenter have requested to be present when their comments are resolved. these commenters were unable to attend the meeting.

Tuesday, January 11

Q1

Chair: PK Scribe: AS

Quick review of standard set within ITS (see Monday Q2)

It was agreed on the need to schedule necessary re-ballots in the next cycle.

Simple ITS, Green CDA, micro ITS - indirect conformance

The micro ITS needs to be scheduled for discussion on status at May, 2011 WGM

JK identified that the RLUS specification may have relevance to the´. hData record data format

There was a discussion of RIM ITS and its relevance to Services.

Q2

Joint with Structured Docs

Q3

Chair: PK Scribe: AS

Bob Dolin from Structured Doc WG as a guest discussed Green CDA.

Q4

ITS was invited to ArB to discuss where the hData documents fit within the organization, please refer to the ArB minutes

Wednesday, January 12

Q1

Chair: PK Scribe: AS

Robert Worden presented a short update on Neutral mapping project via Webex.

R Worden then spent some time on the UK work on a simple ITS


Q2

Chair: PK Scribe: AS, DN

We (ITS) SPL does not want to adapt changes in DT R2 which would mean a lot of changes. It was agreed they would use R1.1, by trading partner agreement. We have a Norm spec that depends on an Inform spec. It is desired to make it Normative. Grahame objects, and wishes to call it DT 2B.

Is the wires format the same in R2 DT as

At abstract, they are implementing DT R2

Datatypes

Version Abstract Basis Status Notes
1.0 1.0 Normative
1.1 2.0 Informative Normative? 2B?
2.0 2.0 Normative

XMLITS

Version Based on Status
1.0 DT 1.0 Normative
1.1 DT 1.0 Normative
2.0 DT 2.0 Normative

Tooling

Version ITS DT
1.0 1.0 1.0
1.1 1.1 1.1 2.0 2.0 2.0

Which ballot are we talking about JK: redo it using ISO datatypes in a correct way. GG: But that breaks their non-backwards compatibility chain. DN: Has HL7 guaranteed BW compatibility? GG: V2 yes, V3 semantic only. PK: We need to think about what the organization should be doing. Perhaps a straw vote. 1.1->Normative 0 1.1->2Minus 3

Should Normative docs stand on Informative docs: No.

UUID

Issue is in the schema, not the spec. If we were to change the schemas, this is a tech correction. PK: UUID Abs 1 & 2 said UC. If it says case insentive, then we my just have a case in the later schema is incorrect. JK: It is transform away. Can SPL provide the transform? PK: require everyone to do local fixes. PK: We have been consistently wrong, and we finally got it right. Do we force everyone to clean it up or do we fix in a future version? GG: All say comparisons are case insensitive.

Version Abstract ITS Schema
1.0 Upper Mixed Mixed
1.1 Mixed Mixed
2.0 Upper Upper Upper (annotate)

GG: Should be TC that 1.0 and 2.0 Abstract are wrong

Motion: The Abstract Datatypes 1.0 and 2.0 descriptions of UUID being upper case be changed to mixed case. (GB, AS) 8/0/1

Action: That GG amend the Abstract Data types, and all associated artifacts.

Motion: (GG/AS) 9-0-0 (1) Do not want to make DT 1.1 backwards compatibility track normative (2) We will if asked by TSC, but want to know how we will avoid maintaining two streams going forward. (3) If it goes normative we will give it an R2 label,

Q3

Did not meet

Q4

Did not meet

Thursday, January 13

Q1

Did not meet

Q2

Chair: PK Scribe: DN

The 3 year plan was agreed upon.

Q3

Did not meet

Q4

Chair: PK Scribe: AS

AS described at some length the Message Builder Project sponsored by Canada Health Infoway for enabling vendors in the Canada.

GB described JSON and how it came into being. There was discussion on whether an ITS had to be 'verifiable' or if the conformance rules could be applied against converted forms, during run-time, et cetera. The group had some interest and believe there may be a use for a JSON ITS, however, it was agreed that if an ITS should be created it should be explicit where the authors thought the ITS was applicable and where the ITS was not.

Attendees

Name Initials Email Monday Tuesday Wednesday Thursday
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Andy Stechishin AS andy.stechishin@gmail.com × × × × × × ×
Dale Nelson DN dale.nelson@squaretrneds.com × × × × × × × × ×
Paul Knapp PK pknapp@pknapp.com × × × × × × × × × ×
Gerald Beuchelt GB beuchelt@mitre.org × × × × × × × × × ×
Hoylen Sue HS hoylen.sue@nehta.gov.au × × × × × × ×
Philip Wilford PW philip.wilford@nehta.gov.au × × × ×
Azmi Hashim AH azmi@viamed.com.my × ×
Lloyd McKenzie LM lloyd@lmckenzie.com ×
John Koisch JK jkoisch@guidewirearchitecture.com × ×
Juha Mykkanen JM juha.mykkanen@uef.fi ×
Bob Dolin BD ×
Stephen Royce SR stephen.royce@nehta.gov.au × × × ×
Sarah Gaunt SG sarah.gaunt@nehta.gov.au × ×
Grahame Grieve GG grahame@healthintersections.com.au ×
Vincent Macauley VM vincent@macauleysoftware.com ×
Gavin Morris GM gavinm@kestrel.com.au ×