RE: Updates to the use-case document

Hi - Ivan and I were happy to remove the HL7 use case. Do any of the team feel otherwise inclined?

Thanks, Jeremy

{snip}

> > >>> Regarding the health informatics use case (HL7)
> > >> <http://w3c.github.io/csvw/use-cases-and-requirements/#UC-
> > >> HealthLevelSevenHL7>, further information from Eric Prud'hommeaux
> > >> indicates that HL7 might be more than we can (or want to) cope
> with.
> > >> See an excerpt from his email [1] where you'll see an example
> > included.
> > >> From what I can see, this is _NOT_ regular tabular data. OK, so
> the
> > >> "microsyntax" in each field is complicated but it can be worked
> > >> out, but the real issue to me is that the rows are not uniform -
> > >> they
> > have
> > >> different numbers of fields. Furthermore, it appears that the data
> > is
> > >> parsed according to a specific set of rules defined in a "table"
> > >> and without this table there's no way to label the parsed
> attributes.
> > >>>
> > >>> I propose that we review this in more detail to see if we should
> > >> include this use case. Personally, I don't think it adds anything
> -
> > >> except to illustrate that row-oriented data can be more
> complicated
> > >> than our tabular data model! I propose to drop this use case.
> > >>>
> > >>
> > >> ... or keep it as to illustrate exactly what you just said: a
> > warning
> > >> to the reader that row-oriented data does not necessarily mean
> CSV!
> > >> (Either way is fine with me, I would go with the flow.)
> > >>
> > >> Ivan
> > >
> > > Personally, I think the effort to establish a "proper" action
> > oriented, narrative style use case is not inconsiderable ... we don't
> > have any examples at the moment &, taking my experience with DwC-A,
> to
> > construct the use case properly means understanding the data format
> to
> > a reasonable level. At this time, I simply don't have the capacity to
> > follow through on this. Seems like nugatory work to me; best avoided.
> > >
> >
> > I do not have a problem with that. Let us nuke it! :-)
> 
> Done! Or at least agreed between you and I. Given that I will not make
> the call this week, I'll ask JeniT/DanBri to add a "do we all agree to
> remove the HL7 UC from the doc" item. Jeremy
> 
> >
> > Ivan
> >
> > > Jeremy
> > >

{snip}


> > >>>
> > >>> ---
> > >>>
> > >>> [1] Email from Eric Prud'hommeaux, 21-May
> > >>>
> > >>> [a potential narrative for the use case ...] John Doe is being
> > >>> transferred from a one clinic to another to recieve specialied
> > care.
> > >> The machine-readable transfer documentation includes his name,
> > >> patient ID, his visit to the first clinic, and some information
> > about
> > >> his next of kin. The visit info (and many other fields) require
> > >> microparsing on the '^' separator to extract further structured
> > >> information about, for example, the referring physician.
> > >>>
> > >>> [on the HL7 data format ...]
> > >>>> I think you want to give up on this one because the message
> > >>>> format
> > >> is
> > >>>> hilariously complex and requires a ton of extra info to parse.
> > >>>> For instance, the header in the first line of
> > >>>>
> > >>>>
> > >>
> > MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457
> > >>>> MSH||
> > >>>> MSH|D|2.5|
> > >>>> PID||0493575^^^2^ID
> > >>>> PID||1|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254
> > MYSTREET
> > >>>> PID||AVE^^MYTOWN^OH^44123^USA||(216)123-4567|||M|NON|||
> > >>>> NK1||ROE^MARIE^^^^|SPO||(216)123-
> > 4567||EC||||||||||||||||||||||||||
> > >>>> NK1|||
> > >>>> PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN
> > >>>> PV1||O|MYLASTNAME^BONNIE^^^^||||||||||
> > >>>>
> > PV1||O|||2688684|||||||||||||||||||||||||199912271408||||||00237685
> > >>>> PV1||O|||2688684|||||||||||||||||||||||||199912271408||||||3
> > >>>>
> > >>>> says that the rest must be parsed with V2.5 tables (I think
> > >>>> you'll
> > >> see 2.2 to 2.6 in the wild).  The data is oriented in rows, so I'm
> > >> not sure how applicable CSV techniques would be. It's also 3 or
> > maybe
> > >> 4 dimentional ("^~\&" being the declared separators for the fields
> > >> within fields in this particular document).
> > >>>>
> > >>>> The V2.5 table tells you how to parse the rest of the fields,
> e.g.
> > >> the PID field, which happens to include subfields like lastname
> and
> > >> firstname ("DOE" and "JOHN" respectively). Without that table,
> > >> there's no way to know how to label the parsed attributes.
> > >>>
> > >>
> > >>
> > >> ----
> > >> Ivan Herman, W3C
> > >> Digital Publishing Activity Lead
> > >> Home: http://www.w3.org/People/Ivan/
> > >> mobile: +31-641044153
> > >> GPG: 0x343F1A3D
> > >> WebID: http://www.ivan-herman.net/foaf#me
> >
> >
> > ----
> > Ivan Herman, W3C
> > Digital Publishing Activity Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > GPG: 0x343F1A3D
> > WebID: http://www.ivan-herman.net/foaf#me
> >
> >
> >
> >
>

Received on Friday, 30 May 2014 10:58:14 UTC