- From: Tandy, Jeremy <jeremy.tandy@metoffice.gov.uk>
- Date: Fri, 30 May 2014 10:57:41 +0000
- To: W3C CSV on the Web Working Group <public-csv-wg@w3.org>
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