ITS WGM Minutes 2011 Jan

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

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

Q2

Joint with Structured Docs

Q3

Chair: PK Scribe: AS

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

Q4

Did not meet

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														×