Re: A Fresh Look Proposal (HL7)

Got it this time, thanks Matthias

David
____________________________________________________

Dr. David J. Wild, djwild@indiana.edu, http://djwild.info
Assistant Professor of Informatics & Computing
Indiana University School of Informatics and Computing
150 S. Woodlawn Rm 330B, Bloomington, IN 47405
Tel. +1 812 856 1848



On Mon, Aug 29, 2011 at 12:06 PM, Matthias Samwald <
matthias.samwald@meduniwien.ac.at> wrote:

> **
> > Unfortunately I'm unable to open the PDF -- could you check the link?
>
> Sorry, the correct link is:
>
> http://samwald.info/res/Samwald_-_Towards_an_interoperable_information_infrastructure_providing_decision_support_for_genomic_medicine_-_MIE2011.pdf
>
> Cheers,
> Matthias
>
>
>
>  *From:* David Wild <djwild@indiana.edu>
> *Sent:* Monday, August 29, 2011 5:18 PM
> *To:* Matthias Samwald <matthias.samwald@meduniwien.ac.at>
> *Cc:* conor dowling <conor-dowling@caregraf.com> ; M. Scott Marshall<mscottmarshall@gmail.com>; Michael
> Miller <Michael.Miller@systemsbiology.org> ; Hau, Dave (NIH/NCI) [E]<haudt@mail.nih.gov>; Jim
> McCusker <james.mccusker@yale.edu> ; John Madden <john.madden@duke.edu> ;
> public-semweb-lifesci@w3.org
> *Subject:* Re: A Fresh Look Proposal (HL7)
>
> Matthias - many thanks for this - I'm very interested in the task force.
> We're just in the very early stages of looking at (i) expanding the
> Chem2Bio2RDF network to include some patient data and (ii) what we might do
> with the integrated data once we do. Particularly interested in clinician
> recommendation systems - e.g. suggesting scholarly publications most likely
> to be of relevance to individual patients (based on their profile) or even
> making predictions of adverse effects.
>
> Unfortunately I'm unable to open the PDF -- could you check the link?
>
> Best wishes
>
> David
> ____________________________________________________
>
> Dr. David J. Wild, djwild@indiana.edu, http://djwild.info
> Assistant Professor of Informatics & Computing
> Indiana University School of Informatics and Computing
> 150 S. Woodlawn Rm 330B, Bloomington, IN 47405
> Tel. +1 812 856 1848
>
>
>
> On Sun, Aug 28, 2011 at 2:03 PM, Matthias Samwald <
> matthias.samwald@meduniwien.ac.at> wrote:
>
>> **
>> If anyone interested in these topics happens to be at the Medical
>> Informatics Europe conference in Oslo the coming days, I will give a talk
>> called *„Towards an interoperable information infrastructure providing
>> decision support for genomic medicine“ *[1] on Tuesday. I plan to discuss
>> ideas about how linked data, RDF/OWL and ontologies could be used
>> to enable personalized/stratified medicine in clinical practice. I am
>> currently also drafting a task force description for the next charter of the
>> HCLS interest group. It would be great to get a broader discussion going!
>>
>> [1]
>> http://samwald.info/publications-etc/samwald.info/res/Samwald_-_Towards_an_interoperable_information_infrastructure_providing_decision_support_for_genomic_medicine_-_MIE2011.pdf
>> [2] http://www.w3.org/wiki/HCLSIG/CDS/Introduction
>>
>> Cheers,
>> Matthias Samwald
>>
>>
>>  *From:* conor dowling <conor-dowling@caregraf.com>
>> *Sent:* Sunday, August 28, 2011 7:26 PM
>> *To:* M. Scott Marshall <mscottmarshall@gmail.com>
>> *Cc:* Michael Miller <Michael.Miller@systemsbiology.org> ; Hau, Dave
>> (NIH/NCI) [E] <haudt@mail.nih.gov> ; Jim McCusker<james.mccusker@yale.edu>; John
>> Madden <john.madden@duke.edu> ; public-semweb-lifesci@w3.org
>>   *Subject:* Re: A Fresh Look Proposal (HL7)
>>
>> Scott,
>>
>>  Dave Hau wrote:
>>> "EHRs make great data warehouses for phenotype mining, for correlating
>>> with genotype.  I think there are a lot of incentives for people to work
>>> together."
>>>
>>>  Conor Dowling wrote:
>>> To me, all of this information goes into one "soup" - in linked data, you
>>> have *one big graph of* medical expression. I don't see the point in
>>> separate *media* for "statements about conditions" and "statements about
>>> condition types".
>>>
>>> I think that you guys are getting to the crux of the matter. Linked data
>>> can help to refine molecular medicine as it's applied in the clinic. That
>>> fusion will help to redefine medicine as 'personalized'.
>>>
>>
>> and this is the goal right? We're not just moving bits around from one
>> patient data silo to another. Any data exported needs to link into a
>> meaningful concept scheme. Linked-data makes it easy to test "linkage": if
>> all you've got is patient data in terms of local codes then it won't link
>> anywhere.
>>
>> Speaking of meaningful: sad thing now is that the US effort to export
>> patient data from clinical data silo's ("meaningful use") is largely
>> meaningless: you get paid to export "unlinked"/local-only data. There was a
>> lot of lobbying to allow as-is patient data exports count as "meaningful",
>> effectively to allow data-dumps pass as interpretable patient records (I
>> wrote a bit on this around "Dr Seuss passes meaningful use": here<http://www.caregraf.com/blog/dr-seuss-passes-meaningful-use>and translate
>> nothing at all<http://www.caregraf.com/blog/dr-seuss-translates-nothing-at-all>
>> ).
>>
>> So when you hear hospital X successfully passed "meaningful use", that
>> their patient data is available beyond their walls, that this represents a
>> brave new world ... it means nothing if your need is clinical data linked to
>> standard schemes for full analysis. Even if you're allowed to access it, the
>> export/data-dump is academic. Shame is, many people think they're doing
>> something meaningful.
>>
>> Conor
>>
>>
>>> --
>>> M. Scott Marshall, W3C HCLS IG co-chair, http://www.w3.org/blog/hcls
>>> http://staff.science.uva.nl/~marshall
>>>
>>> On Sat, Aug 27, 2011 at 6:42 AM, conor dowling <
>>> conor-dowling@caregraf.com> wrote:
>>>
>>>>
>>>>     "I think a SNOMED capable DAM should limit the coordination
>>>>> allowed."
>>>>>
>>>>>
>>>>>
>>>>> ... using SNOMED as your terminology is an implementation detail.
>>>>>
>>>>
>>>> Michael,
>>>>
>>>> one problem with leaving it to implementation is the variety allowed in
>>>> a concept scheme like SNOMED. Take a disorder like Hypercholesterolemia<http://datasets.caregraf.org/snomed#!13644009>:
>>>> and a patient record with ...
>>>>
>>>>               :finding snomed:13644009 # Hypercholesterolemia
>>>>
>>>> another description of the same thing has ...
>>>>
>>>>               :finding snomed:166830008 # Serum cholesterol raised
>>>>
>>>> which is effectively equivalent. The "bridge" is ...
>>>>
>>>>               snomed:13644009 snomed:363705008 snomed:166830008 (More
>>>> here <http://www.caregraf.com/blog/the-problem-with-picking-problems>)
>>>>               # *Hypercholesterolemia* *has definitional manifestation*
>>>>  *Serum cholesterol raised*.
>>>>
>>>> the question is where the bridge goes. Is "has definitional
>>>> manifestation" defined consistently with the predicate "finding" or is it
>>>> part of a completely separate concept model and never bought into play by
>>>> one application?
>>>>
>>>> To me, all of this information goes into one "soup" - in linked data,
>>>> you have *one big graph of* medical expression. I don't see the point
>>>> in separate *media* for "statements about conditions" and "statements
>>>> about condition types".
>>>>
>>>> If in practice - well it's recommended - patient records use SNOMED then
>>>> tying down that expression should be front and center of any clinical-care
>>>> modeling effort. To be useful and implementable, we can't say "use any
>>>> scheme you want" because that's equivalent to saying "you can only do
>>>> trivial reasoning on this information".
>>>>
>>>> Conor
>>>>
>>>>
>>>>>
>>>>>
>>>>> *From:* conor dowling [mailto:conor-dowling@caregraf.com]
>>>>> *Sent:* Wednesday, August 24, 2011 3:26 PM
>>>>>
>>>>> *To:* Hau, Dave (NIH/NCI) [E]
>>>>> *Cc:* Michael Miller; Jim McCusker; John Madden;
>>>>> public-semweb-lifesci@w3.org
>>>>>
>>>>> *Subject:* Re: A Fresh Look Proposal (HL7)
>>>>>
>>>>>
>>>>>
>>>>> DAM: it's good to have a name. Were OWL to be used for them and then
>>>>> other forms derived from that, you'd get the best of both worlds - get into
>>>>> Semantics and move on.
>>>>>
>>>>>
>>>>>
>>>>> One other nuance to throw in for the "model-terminology" match up.
>>>>> SNOMED raises a concern about the degree of "concept coordination" you
>>>>> should or should not do, about what load the terminology should take and
>>>>> what should be left to the model. A simple example is do you allow
>>>>> "disorder: allergy to strawberry" or do you make the model carry "disorder:
>>>>> allergy + allergin: strawberry" or do you allow both expressions? (see:
>>>>> http://www.caregraf.com/blog/there-once-was-a-strawberry-allergy)
>>>>>
>>>>>
>>>>>
>>>>> I think a SNOMED capable DAM should limit the coordination allowed. It
>>>>> should make the model carry qualifiers for severity, for progression, for
>>>>> allergin ... To use it, you would need to normalize these "adjectives" out
>>>>> of any concept.
>>>>>
>>>>>
>>>>>
>>>>> I suppose what I'm saying is that any useful DAM should severely limit
>>>>> alternatives, in a way that goes beyond simple enumerations of permitted
>>>>> values and the nice thing about concept schemes like SNOMED is that this
>>>>> shouldn't be hard to do - crudely in SNOMED it would mean only allowing
>>>>> primitive concepts, the atoms from which compound concepts are made.
>>>>>
>>>>>
>>>>>
>>>>> BTW, this doesn't effect what a doctor sees on a screen - it's a matter
>>>>> of what expressions to use for interoperability. The two issues need to be
>>>>> strictly separated and right now, if you look at how CCDs are viewed,
>>>>> they're thick as thieves,
>>>>>
>>>>>
>>>>>
>>>>> Conor
>>>>>
>>>>> On Wed, Aug 24, 2011 at 2:49 PM, Hau, Dave (NIH/NCI) [E] <
>>>>> haudt@mail.nih.gov> wrote:
>>>>>
>>>>> > the kind of reasoning, i think, that you want to do, conor, would run
>>>>> on top of the information in the HL7 v3 formatted documents to take
>>>>> advantage of, among other things, the linked data cloud.
>>>>>
>>>>>
>>>>>
>>>>> Agree.  Earlier there was a discussion in HL7 on their Domain Analysis
>>>>> Model (DAM) effort - what exactly is a DAM and what it's supposed to do.  I
>>>>> think one possible approach would be to consider these DAMs as ontologies
>>>>> (i.e. conceptual models, knowledge), use OWL in the normative version of
>>>>> these DAMs, then to develop UML models and XSDs from the DAMs to use in
>>>>> applications.  The DAMs can be harmonized with other domain ontologies out
>>>>> there, and promoted for global adoption.  The UML models can be encouraged
>>>>> but not as strictly enforced, while alternatively allowing people to use RDF
>>>>> to tie data directly to concepts in the ontologies / DAMs.
>>>>>
>>>>>
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Michael Miller [mailto:Michael.Miller@systemsbiology.org]
>>>>> *Sent:* Wednesday, August 24, 2011 11:12 AM
>>>>> *To:* conor dowling; Hau, Dave (NIH/NCI) [E]
>>>>>
>>>>>
>>>>> *Cc:* Jim McCusker; John Madden; public-semweb-lifesci@w3.org
>>>>>
>>>>> *Subject:* RE: A Fresh Look Proposal (HL7)
>>>>>
>>>>>
>>>>>
>>>>> hi all,
>>>>>
>>>>>
>>>>>
>>>>> john, very well laid out argument in your email and what i've found in
>>>>> practice (and didn't think that consciously about until i read your email).
>>>>>
>>>>>
>>>>>
>>>>> conor, i agree with your points.   but i find it interesting that OWL
>>>>> is expressed as XML for communication reasons.  XML has become pretty much
>>>>> the de facto standard for 'trading' information.  it's how MAGE-ML was used
>>>>> by the gene expression application i worked on at Rosetta to do import and
>>>>> export.  but the storage and presentation of the information was certainly
>>>>> not XML, the analysis of the data would take forever.  the trick is to make
>>>>> very clear what the extra semantics are and that is well understood for OWL
>>>>> as XML.  when someone wants to use an ontology they've received as an XML
>>>>> document, the first thing to do is transform the information in the XML so
>>>>> that the logic can be run easily (this gets back to john's points)
>>>>>
>>>>>
>>>>>
>>>>> one thing the  clinical genomics group has talked about  is that with
>>>>> the HL7 specs expressed in XML, the important part is that canonical
>>>>> validation applications are written that verify whether a document is
>>>>> conformant with the additional semantics plus provide boiler plate
>>>>> examples.  this allows the developers not to read the docs too closely but
>>>>> understand when they've done something wrong!  (not ideal but works, that's
>>>>> why OWL in XML works, there's a great body of tools)
>>>>>
>>>>>
>>>>>
>>>>> (from dave)
>>>>>
>>>>>
>>>>>
>>>>> "One way would be as Michael suggested, to use ODM for mapping UML to
>>>>> OWL.  But is this mapping to OWL full or to a more computable dialect of
>>>>> OWL?  And would there be notions in UML that are not expressible in OWL and
>>>>> vice versa?  Should we maintain both the UML model and the OWL ontology as
>>>>> normative, or one of the two, and if so, which one?"
>>>>>
>>>>>
>>>>>
>>>>> i think where things get dicey is in the business/logic (there's a good
>>>>> discussion in the spec), so it is probably to a more computable dialect of
>>>>> OWL.  but in practice, the type of information that needs to be 'traded' by
>>>>> HL7 specs tends to be straight-forward information with the controlled
>>>>> vocabularies contributing the extra semantics of how a particular code
>>>>> relates to the patient and the report in the document and also connects out
>>>>> to the larger world.  one thing the clinical genomics group has tried to do
>>>>> is leave open what controlled vocabulary to use (this is something that i
>>>>> think MAGE-OM was one of the first to get right).  normally LOINC is
>>>>> recommended but, in the genomics world it is true things become out of date
>>>>> so to get the right term may require a new CV.  the kind of reasoning, i
>>>>> think, that you want to do, conor, would run on top of the information in
>>>>> the HL7 v3 formatted documents to take advantage of, among other things, the
>>>>> linked data cloud.
>>>>>
>>>>>
>>>>>
>>>>> so i guess what i'm saying here is that using XML as the language of
>>>>> interchange is not a bad thing but that it is expected, and this needs to be
>>>>> made clear, that the XML is almost certainly not the best storage mechanism
>>>>> for the data.
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>> michael
>>>>>
>>>>>
>>>>>
>>>>> *From:* public-semweb-lifesci-request@w3.org [mailto:
>>>>> public-semweb-lifesci-request@w3.org] *On Behalf Of *conor dowling
>>>>> *Sent:* Tuesday, August 23, 2011 5:22 PM
>>>>> *To:* Hau, Dave (NIH/NCI) [E]
>>>>> *Cc:* Jim McCusker; John Madden; public-semweb-lifesci@w3.org
>>>>> *Subject:* Re: A Fresh Look Proposal (HL7)
>>>>>
>>>>>
>>>>>
>>>>>  So Conor if I understand you correctly, you're saying that the
>>>>> current gap that should be addressed in Fresh Look is that the current HL7
>>>>> v3 models are not specified in a language that can be used for reasoning,
>>>>> i.e. they are not OWL ontologies, otherwise publishing value sets would not
>>>>> be necessary because the reasoning could determine whether a particular
>>>>> value (i.e. "object" in your email) would be valid for a particular
>>>>> observation (i.e. "verb).  Is that what you're saying?
>>>>>
>>>>>
>>>>>
>>>>> Dave,
>>>>>
>>>>>
>>>>>
>>>>> exactly - that the patient information model and any recommended
>>>>> terminologies be defined in the same medium and that the medium be capable
>>>>> of capturing permitted ranges, appropriate domains etc. for all predicates:
>>>>> I think a flavor of OWL with a closed-world assumption is the only real game
>>>>> in town but ...
>>>>>
>>>>>
>>>>>
>>>>> One goal (always easier to agree on goals than technologies!) is that
>>>>> an "allergic to allergy" misstep wouldn't happen - there would be no need to
>>>>> read guidance and coders don't read! A meaningful use test would assert
>>>>> permitted ranges (ex/ allergin class:
>>>>> http://datasets.caregraf.org/snomed#!406455002 for a property
>>>>> "allergin").
>>>>>
>>>>>
>>>>>
>>>>> Of course, 'correctness' isn't the only goal or result: transforming
>>>>> between equivalent expressions supported by model+terminology should be
>>>>> possible and promoted (take:
>>>>> http://www.caregraf.com/blog/good-son-jones-diabetic-ma ). And then
>>>>> there's the direct path to decision-support which you mention above.
>>>>>
>>>>>
>>>>>
>>>>> The focus on enforcing syntactic correctness would fade away and the
>>>>> model specifier's demand for greater precision from terminologies should
>>>>> drive improvements there. This is far from new: some HL7 and SNOMED
>>>>> documents identify the need to marry model and terminology but go no
>>>>> further.
>>>>>
>>>>>
>>>>>
>>>>> I think the current meaningful-use CCD has six areas - allergies,
>>>>> problems, procedures ... It would be interesting to try one or two, say look
>>>>> at Kaiser's problem subset from SNOMED and see how a HL7-based OWL patient
>>>>> model and that could work together. There are a lot of pieces in the wild
>>>>> now: they just need a forum to play in.
>>>>>
>>>>>
>>>>>
>>>>> One last thing, slightly off the thread but still on topic I think. I
>>>>> don't see any reason to mix up "human readable" and "machine processable".
>>>>> One possibility for a patient model update, one that bypasses the need for
>>>>> buy-in by everyone, irrespective of use case, is to call out the need for a
>>>>> model of description purely for machine processing, one without the "we'll
>>>>> XSLT the patient record in the doctor's browser". While the current
>>>>> standards lead to human-readable data-dumps, a stricter parallel track could
>>>>> take the best of current standards and re-state them in OWL to deliver
>>>>> machine-processable health data exchange,
>>>>>
>>>>>
>>>>>
>>>>> Conor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I agree OWL ontologies are useful in health informatics because
>>>>> reasoning can be used for better validation, decision support etc.  I'm
>>>>> wondering, is there a need for both a UML type modeling language and OWL (or
>>>>> other logic-based language) to be used simultaneously?  If so, how?  Should
>>>>> OWL be used for representing knowledge, and UML be used for representing
>>>>> application models?
>>>>>
>>>>>
>>>>>
>>>>> One way would be as Michael suggested, to use ODM for mapping UML to
>>>>> OWL.  But is this mapping to OWL full or to a more computable dialect of
>>>>> OWL?  And would there be notions in UML that are not expressible in OWL and
>>>>> vice versa?  Should we maintain both the UML model and the OWL ontology as
>>>>> normative, or one of the two, and if so, which one?
>>>>>
>>>>>
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>
>>>>> ps.  Michael, nice meeting you at the caBIG F2F too!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* conor dowling [mailto:conor-dowling@caregraf.com]
>>>>> *Sent:* Monday, August 22, 2011 12:28 PM
>>>>> *To:* John Madden
>>>>> *Cc:* Jim McCusker; Hau, Dave (NIH/NCI) [E];
>>>>> public-semweb-lifesci@w3.org
>>>>> *Subject:* Re: A Fresh Look Proposal (HL7)
>>>>>
>>>>>
>>>>>
>>>>> >> for each tool-chain, there are some kinds of content that are
>>>>> natural and easy to express, and other kinds of content that are difficult
>>>>> and imperspicuous to express
>>>>>
>>>>>
>>>>>
>>>>> it's the old "medium is the message" and as you say John, it's somewhat
>>>>> unavoidable, But this connection doesn't imply all media are equally
>>>>> expressive.
>>>>>
>>>>>
>>>>>
>>>>> Making XSD/XML the focus for definition rather than seeing it as just
>>>>> one end-of-a-road serialization is limiting because as a medium, it puts the
>>>>> focus on syntax, not semantics. That can't be said of OWL/SKOS/RDFS ....
>>>>>
>>>>>
>>>>>
>>>>> By way of example: you could have a patient data ontology, one that
>>>>> works with a KOS like SNOMED and if an implementor likes XML, there's
>>>>> nothing to stop ...
>>>>>
>>>>>
>>>>>
>>>>>               RDF (turtle) conformant to ontologies/KOS --> RDF/XML
>>>>> ---- XSLT ----> CCD (ex)
>>>>>
>>>>>
>>>>>
>>>>> as a chain. It's trivial. But if you start with lot's of XSL, well you
>>>>> get only what that medium permits and promotes, which is a focus on syntax,
>>>>> on the presence or absence of fields, as opposed to guidance on the correct
>>>>> concept to use with this or that verb.
>>>>>
>>>>>
>>>>>
>>>>> Of course, a verb-object split is comfortable because those building
>>>>> information models can work independently of those creating terminologies
>>>>> but is such separation a good thing? Now, were both to work in a common
>>>>> medium then inevitably ...
>>>>>
>>>>>
>>>>>
>>>>> Conor
>>>>>
>>>>>
>>>>>
>>>>> p.s. the public release by Kaiser of their subsets of SNOMED (CMT) is
>>>>> the kind of thing that will make that KOS more practical. Now what's needed
>>>>> is tighter definition of the model to use with that and similar sub schemes.
>>>>>
>>>>> On Mon, Aug 22, 2011 at 9:03 AM, John Madden <john.madden@duke.edu>
>>>>> wrote:
>>>>>
>>>>> I agree 95% with Jim and Conor.
>>>>>
>>>>>
>>>>>
>>>>> My 5% reservation is that for each tool-chain, there are some kinds of
>>>>> content that are natural and easy to express, and other kinds of content
>>>>> that are difficult and imperspicuous to express (is that a word?).
>>>>>
>>>>>
>>>>>
>>>>> Even this is not in itself a problem, except that it tends to make
>>>>> architects favor some kinds of conceptualization and shun other kinds of
>>>>> conceptualization, not on the merits, but because that's what's easy to
>>>>> express in the given tool.
>>>>>
>>>>>
>>>>>
>>>>> For example, the fact that the decision was made to serialize all
>>>>> RIM-based artifacts as XSD-valid XML meant that hierarchical modeling rather
>>>>> than directed-graph modeling tended to be used in practice. (Even though the
>>>>> RIM expressed as a Visio model has more in common with a directed-graph.) It
>>>>> meant that derivation by restriction was made the favored extensibility
>>>>> mechanism.
>>>>>
>>>>>
>>>>>
>>>>> These choices may not have been the most auspicious for the kind of
>>>>> conceptualizations that needed to be expressed. None of these things are
>>>>> "necessary" consequences of using XSD-valid XML as your language Rather,
>>>>> they are the results that you tend to get in practice because the tool has
>>>>> so much influence on the style that ends up, in practice, being
>>>>> used. (id/idref//key/keyrefs are certainly part of XSD/XML, and make it
>>>>> possible to express non-hierarchical relations, but where in any HL7
>>>>> artifact do you ever see key/keyref being used?? SImilarly, it is possible
>>>>> to derive by extension in XSD, but the spec makes it less easy than deriving
>>>>> by restriction).
>>>>>
>>>>>
>>>>>
>>>>> Or again, the fact that OIDs rather than http URLs were chosen as the
>>>>> identifier of choice isn't in any way dispositive of whether you will be
>>>>> tend to architect with RPC or REST principles in mind. (OIDs and http URLs
>>>>> are actually quite interconvertible.) But I'd argue that if you are a person
>>>>> who tends to think using http URLs, you'll more likely gravitate to REST
>>>>> solutions out of the gate.
>>>>>
>>>>>
>>>>>
>>>>> So, I agree, what's important is the deep content, not the choice of
>>>>> serialization of that content. But a bad serialization choice, coupled with
>>>>> bad tools, can leave architects wandering in the wilderness for a long time.
>>>>> So long, sometimes, that they lose track of what the deep conceptualization
>>>>> was supposed to have been in the first place.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Aug 22, 2011, at 9:39 AM, Jim McCusker wrote:
>>>>>
>>>>>
>>>>>
>>>>> I was just crafting a mail about how our investment in XML technologies
>>>>> hasn't paid off when this came in. What he said. :-)
>>>>>
>>>>> On Mon, Aug 22, 2011 at 9:33 AM, conor dowling <
>>>>> conor-dowling@caregraf.com> wrote:
>>>>>
>>>>> >> The content matters, the format does not.
>>>>>
>>>>>
>>>>>
>>>>> should be front and center. Talk of XML that or JSON this, of RDF as
>>>>> XML in a chain is a distraction - it's just plumbing. There are many
>>>>> tool-chains and implementors are big boys - they can graze the buffet
>>>>> themselves.
>>>>>
>>>>>
>>>>>
>>>>> Central to any patient model rework (I hope) would be the interplay of
>>>>> formal specifications for terminologies like SNOMED along with any patient
>>>>> data information model. What should go in the terminology concept (the
>>>>> "object" in RDF terms) - what is left in the model (the "predicate"). Right
>>>>> now, this interplay is woefully under specified and implementors throw just
>>>>> about any old concept into "appropriate" slots in RIM (I know this from
>>>>> doing meaningful use tests:
>>>>> http://www.caregraf.com/blog/being-allergic-to-allergies,
>>>>> http://www.caregraf.com/blog/there-once-was-a-strawberry-allergy )
>>>>> BTW, if SNOMED is the terminology of choice (for most) then the dance of it
>>>>> and any RIM-2 should drive much of RIM-2's form.
>>>>>
>>>>>
>>>>>
>>>>> This is a chance to get away from a fixation on formats/plumbing/"the
>>>>> trucks for data" and focus on content and in that focus to consider every
>>>>> aspect of expression, not just the verbs (RIM) or the objects (SNOMED) but
>>>>> both.
>>>>>
>>>>>
>>>>>
>>>>> Back to "forget the plumbing": if you want to publish a patient's data
>>>>> as an RDF graph or relational tables or you want a "document" to send on a
>>>>> wire, if you want to query with a custom protocol or use SPARQL or SQL, you
>>>>> should be able to and not be seen as an outlier. Each can be reduced to
>>>>> equivalents in other formats for particular interoperability. The problem
>>>>> right now is that so much time is spent talking about these containers and
>>>>> working between them and too little time is given over to what they contain,
>>>>>
>>>>>
>>>>>
>>>>> Conor
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 22, 2011 at 6:01 AM, Hau, Dave (NIH/NCI) [E] <
>>>>> haudt@mail.nih.gov> wrote:
>>>>>
>>>>> I see what you're saying and I agree.
>>>>>
>>>>>
>>>>>
>>>>> The appeal of XML (i.e. XML used with an XSD representing model
>>>>> syntactics, not XML used as a serialization as in RDF/XML) is due in part
>>>>> to:
>>>>>
>>>>>
>>>>>
>>>>> - XML schema validation API is available on virtually all platforms
>>>>> e.g. Java, Javascript, Google Web Toolkit, Android etc.
>>>>>
>>>>> - XML schema validation is relatively lightweight computationally.
>>>>> Pellet ICV and similar mechanisms are more complete in their validation with
>>>>> the model, but much more computationally expensive unless you restrict
>>>>> yourself to a small subset of OWL which then limits the expressiveness of
>>>>> the modeling language.
>>>>>
>>>>> - XML provides a convenient bridge from models such as OWL to
>>>>> relational databases e.g. via JAXB or Castor to Java objects to Hibernate to
>>>>> any RDB.
>>>>>
>>>>> - Relational querying and XML manipulation skills are much more
>>>>> plentiful in the market than SPARQL skills currently.
>>>>>
>>>>> - Some of the current HL7 artifacts are expressed in XSD format, such
>>>>> as their datatypes (ISO 21090 ; although there are alternative
>>>>> representations such as UML, and there is an abstract spec too from HL7).
>>>>> If we operate with OWL and RDF exclusively, would need to convert these
>>>>> datatypes into OWL.
>>>>>
>>>>>
>>>>>
>>>>> Maybe it'd be worthwhile to get a few of us who are interested in this
>>>>> topic together, with some of the HL7 folks interested, and have a few calls
>>>>> to flush this out and maybe write something up?
>>>>>
>>>>>
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Jim McCusker [mailto:james.mccusker@yale.edu]
>>>>> *Sent:* Sunday, August 21, 2011 6:12 PM
>>>>> *To:* Hau, Dave (NIH/NCI) [E]
>>>>> *Cc:* public-semweb-lifesci@w3.org
>>>>> *Subject:* Re: FW: A Fresh Look Proposal (HL7)
>>>>>
>>>>>
>>>>>
>>>>> I feel I need to cut to the chase with this one: XML schema cannot
>>>>> validate semantic correctness.
>>>>>
>>>>>
>>>>>
>>>>> It can validate that XML conforms to a particular schema, but that is
>>>>> syntactic. The OWL validator is nothing like a schema validator, first it
>>>>> produces a closure of all statements that can be inferred from the asserted
>>>>> information. This means that if a secondary ontology is used to describe
>>>>> some data, and that ontology integrates with the ontology that you're
>>>>> attempting to validate against, you will get a valid result. An XML schema
>>>>> can only work with what's in front of it.
>>>>>
>>>>>
>>>>>
>>>>> Two, there are many different representations of information that go
>>>>> beyond XML, and it should be possible to validate that information without
>>>>> anything other than a mechanical, universal translation. For instance, there
>>>>> are a few mappings of RDF into JSON, including JSON-LD, which looks the most
>>>>> promising at the moment. Since RDF/XML and JSON-LD both parse to the same
>>>>> abstract graph, there is a mechanical transformation between them. When
>>>>> dealing with semantic validity, you want to check the graph that is parsed
>>>>> from the document, not the document itself.
>>>>>
>>>>>
>>>>>
>>>>> The content matters, the format does not. For instance, let me define a
>>>>> new RDF format called RDF/CSV:
>>>>>
>>>>>
>>>>>
>>>>> First column is the subject. First row is the predicate. All other cell
>>>>> values are objects. URIs that are relative are relative to the document, as
>>>>> in RDF/XML.
>>>>>
>>>>>
>>>>>
>>>>> I can write a parser for that in 1 hour and publish it. It's genuinely
>>>>> useful, and all you would have to do to read and write it is to use my
>>>>> parser or write one yourself. I can then use the parser, paired with Pellet
>>>>> ICV, and validate the information in the file without any additional work
>>>>> from anyone.
>>>>>
>>>>>
>>>>>
>>>>> Maybe we need a simplified XML representation for RDF that looks more
>>>>> like regular XML. But to make a schema for an OWL ontology is too much work
>>>>> for too little payoff.
>>>>>
>>>>>
>>>>>
>>>>> Jim
>>>>>
>>>>> On Sun, Aug 21, 2011 at 5:45 PM, Hau, Dave (NIH/NCI) [E] <
>>>>> haudt@mail.nih.gov> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> As some of you may have read, HL7 is rethinking their v3 and doing some
>>>>> brainstorming on what would be a good replacement for a data exchange
>>>>> paradigm grounded in robust semantic modeling.
>>>>>
>>>>>
>>>>>
>>>>> On the following email exchange, I was wondering, if OWL is used for
>>>>> semantic modeling, are there good ways to accomplish the following:
>>>>>
>>>>>
>>>>>
>>>>> 1.  Generate a wire format schema (for a subset of the model, the
>>>>> subset they call a "resource"), e.g. XSD
>>>>>
>>>>>
>>>>>
>>>>> 2.  Validate XML instances for conformance to the semantic model.
>>>>> (Here I'm reminded of Clark and Parsia's work on their Integrity Constraint
>>>>> Validator:  http://clarkparsia.com/pellet/icv )
>>>>>
>>>>>
>>>>>
>>>>> 3.  Map an XML instance conformant to an earlier version of the
>>>>> "resource" to the current version of the "resource" via the OWL semantic
>>>>> model
>>>>>
>>>>>
>>>>>
>>>>> I think it'd be great to get a semantic web perspective on this fresh
>>>>> look effort.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Dave Hau
>>>>>
>>>>> National Cancer Institute
>>>>>
>>>>> Tel: 301-443-2545
>>>>>
>>>>> Dave.Hau@nih.gov
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* owner-its@lists.hl7.org [mailto:owner-its@lists.hl7.org] *On
>>>>> Behalf Of *Lloyd McKenzie
>>>>> *Sent:* Sunday, August 21, 2011 12:07 PM
>>>>> *To:* Andrew McIntyre
>>>>> *Cc:* Grahame Grieve; Eliot Muir; Zel, M van der; HL7-MnM; RIMBAA; HL7
>>>>> ITS
>>>>> *Subject:* Re: A Fresh Look Proposal
>>>>>
>>>>>
>>>>>
>>>>> Hi Andrew,
>>>>>
>>>>>
>>>>>
>>>>> Tacking stuff on the end simply doesn't work if you're planning to use
>>>>> XML Schema for validation.  (Putting new stuff in the middle or the
>>>>> beginning has the same effect - it's an unrecognized element.)  The only
>>>>> alternative is to say that all changes after "version 1" of the
>>>>> specification will be done using the extension mechanism.  That will create
>>>>> tremendous analysis paralysis as we try to get things "right" for that first
>>>>> version, and will result in increasing clunkiness in future versions.
>>>>>  Furthermore, the extension mechanism only works for the wire format.  For
>>>>> the RIM-based description, we still need proper modeling, and that can't
>>>>> work with "stick it on the end" no matter what.
>>>>>
>>>>>
>>>>>
>>>>> That said, I'm not advocating for the nightmare we currently have with
>>>>> v3 right now.
>>>>>
>>>>>
>>>>>
>>>>> I think the problem has three parts - how to manage changes to the wire
>>>>> format, how to version resource definitions and how to manage changes to the
>>>>> semantic model.
>>>>>
>>>>>
>>>>>
>>>>> Wire format:
>>>>>
>>>>> If we're using schema for validation, we really can't change anything
>>>>> without breaking validation.  Even making an existing non-repeating element
>>>>> repeat is going to cause schema validation issues.  That leaves us with two
>>>>> options (if we discount the previously discussed option of "get it right the
>>>>> first time and be locked there forever":
>>>>>
>>>>> 1. Don't use schema
>>>>>
>>>>> - Using Schematron or something else could easily allow validation of
>>>>> the elements that are present, but ignore all "unexpected" elements
>>>>>
>>>>> - This would cause significant pain for implementers who like to use
>>>>> schema to help generate code though
>>>>>
>>>>>
>>>>>
>>>>> 2. Add some sort of a version indicator on new content that allows a
>>>>> pre-processor to remove all "new" content if processing using an "old"
>>>>> handler
>>>>>
>>>>> - Unpleasant in that it involves a pre-processing step and adds extra
>>>>> "bulk" to the instances, but other than that, quite workable
>>>>>
>>>>>
>>>>>
>>>>> I think we're going to have to go with option #2.  It's not ideal, but
>>>>> is still relatively painless for implementers.  The biggest thing is that we
>>>>> can insist on "no breaking x-path changes".  We don't move stuff between
>>>>> levels in a resource wire format definition or rename elements in a resource
>>>>> wire format definition.  In the unlikely event we have to deprecate the
>>>>> entire resource and create a new version.
>>>>>
>>>>>
>>>>>
>>>>> Resource versioning:
>>>>>
>>>>> At some point, HL7 is going to find at least one resource where we blew
>>>>> it with the original design and the only way to create a coherent wire
>>>>> format is to break compatibility with the old one.  This will then require
>>>>> definition of a new resource, with a new name that occupies the same
>>>>> semantic space as the original.  I.e. We'll end up introducing "overlap".
>>>>>  Because overlap will happen, we need to figure out how we're going to deal
>>>>> with it.  I actually think we may want to introduce overlap in some places
>>>>> from the beginning.  Otherwise we're going to force a wire format on
>>>>> implementers of simple community EMRs that can handle prescriptions for
>>>>> fully-encoded chemo-therapy protocols.  (They can ignore some of the data
>>>>> elements, but they'd still have to support the full complexity of the nested
>>>>> data structures.)
>>>>>
>>>>>
>>>>>
>>>>> I don't have a clear answer here, but I think we need to have a serious
>>>>> discussion about how we'll handle overlap in those cases where it's
>>>>> necessary, because at some point it'll be necessary.  If we don't figure out
>>>>> the approach before we start, we can't allow for it in the design.
>>>>>
>>>>>
>>>>>
>>>>> All that said, I agree with the approach of avoiding overlap as much as
>>>>> humanly possible.  For that reason, I don't advocate calling the Person
>>>>> resource "Person_v1" or something that telegraphs we're going to have new
>>>>> versions of each resource eventually (let alone frequent changes).
>>>>>  Introduction of a new version of a resource should only be done when the
>>>>> pain of doing so is outweighed by the pain of trying to fit new content in
>>>>> an old version, or requiring implementers of the simple to support the
>>>>> structural complexity of our most complex use-cases.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Semantic model versioning:
>>>>>
>>>>> This is the space where "getting it right" the first time is the most
>>>>> challenging.  (I think we've done that with fewer than half of the normative
>>>>> specifications we've published so far.)  V3 modeling is hard.  The positive
>>>>> thing about the RFH approach is that very few people need to care.  We could
>>>>> totally refactor every single resource's RIM-based model (or even remove
>>>>> them entirely), and the bulk of implementers would go on merrily exchanging
>>>>> wire syntax instances.  However, that doesn't mean the RIM-based
>>>>> representations aren't important.  They're the foundation for the meaning of
>>>>> what's being shared.  And if you want to start sharing at a deeper level
>>>>> such as RIMBAA-based designs, they're critical.  This is the level where OWL
>>>>> would come in.  If you have one RIM-based model structure, and then need to
>>>>> refactor and move to a different RIM-based model structure, you're going to
>>>>> want to map the semantics between the two structures so that anyone who was
>>>>> using the old structure can manage instances that come in with the new
>>>>> structure (or vice versa).  OWL can do that.  And anyone who's got a complex
>>>>> enough implementation to parse the wire format and trace the elements
>>>>> through the their underlying RIM semantic model will likely be capable of
>>>>> managing the OWL mapping component as well.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> In short, I think we're in agreement that separation of wire syntax and
>>>>> semantic model are needed.  That will make model refactoring much easier.
>>>>>  However we do have to address how we're going to handle wire-side and
>>>>> resource refactoring too.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lloyd
>>>>>
>>>>> --------------------------------------
>>>>> Lloyd McKenzie
>>>>>
>>>>> +1-780-993-9501
>>>>>
>>>>>
>>>>>
>>>>> Note: Unless explicitly stated otherwise, the opinions and positions
>>>>> expressed in this e-mail do not necessarily reflect those of my clients nor
>>>>> those of the organizations with whom I hold governance positions.
>>>>>
>>>>> On Sun, Aug 21, 2011 at 7:53 AM, Andrew McIntyre <
>>>>> andrew@medical-objects.com.au> wrote:
>>>>>
>>>>> Hello Lloyd,
>>>>>
>>>>> While "tacking stuff on the end" in V2 may not at first glance seem
>>>>> like an elegant solution I wonder if it isn't actually the best solution,
>>>>> and one that has stood the test of time. The parsing rules in V2 do make
>>>>> version updates quite robust wrt backward and forward inter-operability.
>>>>>
>>>>> I am sure it could be done with OWL but I doubt we can switch the world
>>>>> to using OWL in any reasonable time frame and we probably need a less
>>>>> abstract representation for commonly used things. In V2 OBX segments, used
>>>>> in a hierarchy can create an OWL like object-attribute structure for
>>>>> information that is not modeled by the standard itself.
>>>>>
>>>>> I do think the wire format and any overlying model should be distinct
>>>>> entities so that the model can be evolved and the wire format be changed in
>>>>> a backward compatible way, at least for close versions.
>>>>>
>>>>> I also think that the concept of templates/archetypes to extend the
>>>>> model should not invalidate the wire format, but be a metadata layer over
>>>>> the wire format. This is what we have done in Australia with an ISO 13606
>>>>> Archetypes in V2 projects. I think we do need a mechanism for people to
>>>>> develop templates to describe hierarchical data and encode that in the wire
>>>>> format in a way that does not invalidate its vanilla semantics (ie non
>>>>> templated V2 semantics) when the template mechanism is unknown or not
>>>>> implemented.
>>>>>
>>>>> In a way the V2 specification does hit at underlying
>>>>> objects/Interfaces, and there is a V2 model, but it is not prescriptive and
>>>>> there is no requirement for systems to use the same internal model as long
>>>>> as they use the bare bones V2 model in the same way. Obviously this does not
>>>>> always work as well as we would like, even in V2, but it does work well
>>>>> enough to use it for quite complex data when there are good implementation
>>>>> guides.
>>>>>
>>>>> If we could separate the wire format from the clinical models then the
>>>>> 2 can evolve in their own way. We have done several trial implementations of
>>>>> Virtual Medical Record Models (vMR) which used V3 datatypes and RIM like
>>>>> classes and could build those models from V2 messages, or in some cases non
>>>>> standard Web Services, although for specific clinical classes did use ISO
>>>>> 13606 archetypes to structure the data in V2 messages.
>>>>>
>>>>> I think the dream of having direct model serializations as messages is
>>>>> flawed for all the reasons that have made V3 impossible to implement in the
>>>>> wider world. While the tack it on the end, lots of optionality rationale
>>>>> might seem clunky, maybe its the best solution to a difficult problem.. If we
>>>>> define tight SOAP web services for everything we will end up with thousands
>>>>> of slightly different SOAP calls for every minor variation and I am not sure
>>>>> this is the path to enlightenment either.
>>>>>
>>>>> I am looking a Grahams proposal now, but I do wonder if the start again
>>>>> from scratch mentality is not part of the problem. Perhaps that is a lesson
>>>>> to be learned from the V3 process. Maybe the problem is 2 complex to solve
>>>>> from scratch and like nature we have to evolve and accept there is lots of
>>>>> junk DNA, but maintaining a working standard at all times is the only way to
>>>>> avoid extinction.
>>>>>
>>>>> I do like the idea of a cohesive model for use in decision support, and
>>>>> that's what the vMR/GELLO is about, but I doubt there will ever be a one
>>>>> size fits all model and any model will need to evolve. Disconnecting the
>>>>> model from the messaging, with all the pain that involves, might create a
>>>>> layered approach that might allow the HL7 organism to evolve gracefully. I
>>>>> do think part of the fresh look should be education on what V2 actually
>>>>> offers, and can offer, and I suspect many people in HL7 have never seriously
>>>>> looked at it in any depth.
>>>>>
>>>>> Andrew McIntyre
>>>>>
>>>>>
>>>>>
>>>>> Saturday, August 20, 2011, 4:37:37 AM, you wrote:
>>>>>
>>>>> Hi Grahame,
>>>>>
>>>>> Going to throw some things into the mix from our previous discussions
>>>>> because I don't see them addressed yet.  (Though I admit I haven't reread
>>>>> the whole thing, so if you've addressed and I haven't seen, just point me at
>>>>> the proper location.)
>>>>>
>>>>> One of the challenges that has bogged down much of the v3 work at the
>>>>> international level (and which causes a great deal of pain at the
>>>>> project/implementation level) is the issue of refactoring.  The pain at the
>>>>> UV level comes from the fact that we have a real/perceived obligation to
>>>>> meet all known and conceivable use-cases for a particular domain.  For
>>>>> example, the pharmacy domain model needs to meet the needs of clinics,
>>>>> hospitals, veterinarians, and chemotherapy protocols and must support the
>>>>> needs of the U.S., Soviet union and Botswana.  To make matters more
>>>>> interesting, participation from the USSR and Botswana is a tad light.
>>>>>  However the fear is that if all of these needs aren't taken into account,
>>>>> then when someone with those needs shows up at the door, the model will need
>>>>> to undergo substantive change, and that will break all of the existing
>>>>> systems.
>>>>>
>>>>> The result is a great deal of time spent gathering requirements and
>>>>> refactoring and re-refactoring the model as part of the design process,
>>>>> together with a tendency to make most, if not all data elements optional at
>>>>> the UV level.  A corollary is that the UV specs are totally unimplementable
>>>>> in an interoperable fashion.  The evil of optionality that manifested in v2
>>>>> that v3 was going to banish turned out to not be an issue of the standard,
>>>>> but rather of the issues with creating a generic specification that
>>>>> satisfies global needs and a variety of use-cases.
>>>>>
>>>>> The problem at the implementer/project level is that when you take the
>>>>> UV model and tightly constrain it to fit your exact requirements, you
>>>>> discover 6 months down the road that one or more of your constraints was
>>>>> wrong and you need to loosen it, or you have a new requirement that wasn't
>>>>> thought of, and this too requires refactoring and often results in
>>>>> wire-level incompatibilities.
>>>>>
>>>>> One of the things that needs to be addressed if we're really going to
>>>>> eliminate one of the major issues with v3 is a way to reduce the fear of
>>>>> refactoring.  Specifically, it should be possible to totally refactor the
>>>>> model and have implementations and designs work seemlessly across versions.
>>>>>
>>>>> I think putting OWL under the covers should allows for this.  If we can
>>>>> assert equivalencies between data elements in old and new models, or even
>>>>> just map the wire syntaxes of old versions to new versions of the definition
>>>>> models, then this issue would be significantly addressed:
>>>>> - Committees wouldn't have to worry about satisfying absolutely every
>>>>> use-case to get something useful out because they know they can make changes
>>>>> later without breaking everything.  (They wouldn't even necessarily have to
>>>>> meet all the use-cases of the people in the room! :>)
>>>>> - Realms and other implementers would be able to have an
>>>>> interoperability path that allowed old wire formats to interoperate with new
>>>>> wireformats through the aid of appropriate tooling that could leverage the
>>>>> OWL under the covers.  (I think creating such tooling is *really* important
>>>>> because version management is a significant issue with v3.  And with XML and
>>>>> schemas, the whole "ignore everything on the end you don't recognize" from
>>>>> v2 isn't a terribly reasonable way forward.
>>>>>
>>>>> I think it's important to figure out exactly how refactoring and
>>>>> version management will work in this new approach.  The currently proposed
>>>>> approach of "you can add stuff, but you can't change what's there" only
>>>>> scales so far.
>>>>>
>>>>>
>>>>> I think we *will* need to significantly increase the number of
>>>>> Resources (from 30 odd to a couple of hundred).  V3 supports things like
>>>>> invoices, clinical study design, outbreak tracking and a whole bunch of
>>>>> other healthcare-related topics that may not be primary-care centric but are
>>>>> still healthcare centric.  That doesn't mean all (or even most) systems will
>>>>> need to deal with them, but the systems that care will definitely need them.
>>>>>  The good news is that most of these more esoteric areas have responsible
>>>>> committees that can manage the definition of these resources, and as you
>>>>> mention, we can leverage the RMIMs and DMIMs we already have in defining
>>>>> these structures.
>>>>>
>>>>>
>>>>> The specification talks about robust capturing of requirements and
>>>>> traceability to them, but gives no insight into how this will occur.  It's
>>>>> something we've done a lousy job of with v3, but part of the reason for that
>>>>> is it's not exactly an easy thing to do.  The solution needs to flesh out
>>>>> exactly how this will happen.
>>>>>
>>>>>
>>>>> We need a mapping that explains exactly what's changed in the datatypes
>>>>> (and for stuff that's been removed, how to handle that use-case).
>>>>>
>>>>> There could still be a challenge around granularity of text.  As I
>>>>> understand it, you can have a text representation for an attribute, or for
>>>>> any XML element.  However, what happens if you have a text blob in your
>>>>> interface that covers 3 of 7 attributes inside a given XML element.  You
>>>>> can't use the text property of the element, because the text only covers 3
>>>>> of 7.  You can't use the text property of one of the attributes because it
>>>>> covers 3 separate attributes.  You could put the same text in each of the 3
>>>>> attributes, but that's somewhat redundant and is going to result in
>>>>> rendering issues.  One solution might be to allow the text specified at the
>>>>> element level to identify which of the attributes the text covers.  A
>>>>> rendering system could then use that text for those attributes, and then
>>>>> render the discrete values of the remaining specified attributes.  What this
>>>>> would mean is that an attribute might be marked as "text" but not have text
>>>>> content directly if the parent element had a text blob that covered that
>>>>> attribute.
>>>>>
>>>>>
>>>>>
>>>>> New (to Grahame) comments:
>>>>>
>>>>> I didn't see anything in the HTML section or the transaction section on
>>>>> how collisions are managed for updates.  A simple requirement (possibly
>>>>> optional) to include the version id of the resource being updated or deleted
>>>>> should work.
>>>>>
>>>>> To my knowledge, v3 (and possibly v2) has never supported true
>>>>> "deletes".  At best, we do an update and change the status to nullified.  Is
>>>>> that the intention of the "Delete" transaction, or do we really mean a true
>>>>> "Delete"?  Do we have any use-cases for true deletes?
>>>>>
>>>>> I wasn't totally clear on the context for uniqueness of ids.  Is it
>>>>> within a given resource or within a given base URL?  What is the mechanism
>>>>> for referencing resources from other base URLs?  (We're likely to have
>>>>> networks of systems that play together.)
>>>>>
>>>>> Nitpick: I think "id" might better be named "resourceId" to avoid any
>>>>> possible confusion with "identifier".  I recognize that from a coding
>>>>> perspective, shorter is better.  However, I think that's outweightd by the
>>>>> importance of avoiding confusion.
>>>>>
>>>>> In the resource definitions, you repeated definitions for resources
>>>>> inherited from parent resources.  E.g. Person.created inherited from
>>>>> Resource.Base.created.  Why?  That's a lot of extra maintenance and
>>>>> potential for inconsistency.  It also adds unnecessary volume.
>>>>>
>>>>> Suggest adding a caveat to the draft that the definitions are
>>>>> placeholders and will need significant work.  (Many are tautological and
>>>>> none meet the Vocab WG's guidelines for quality definitions.)
>>>>>
>>>>> Why is Person.identifier mandatory?
>>>>>
>>>>> You've copied "an element from Resource.Base.???" to all of the Person
>>>>> attributes, including those that don't come from Resource.Base.
>>>>>
>>>>> Obviously the workflow piece and the conformance rules that go along
>>>>> with it need some fleshing out.  (Looks like this may be as much fun in v4
>>>>> as it has been in v3 :>)
>>>>>
>>>>> The list of identifier types makes me queasy.  It looks like we're
>>>>> reintroducing the mess that was in v2.  Why?  Trying to maintain an ontology
>>>>> of identifier types is a lost cause.  There will be a wide range of
>>>>> granularity requirements and at fine granularity, there will be 10s of
>>>>> thousands.  The starter list is pretty incoherent.  If you're going to have
>>>>> types at all, the vocabulary should be constrained to a set of codes based
>>>>> on the context in which the real-world identifier is present.  If there's no
>>>>> vocabulary defined for the property in that context, then you can use text
>>>>> for a label and that's it.
>>>>>
>>>>> I didn't see anything on conformance around datatypes.  Are we going to
>>>>> have datatype flavors?  How is conformance stated for datatype properties?
>>>>>
>>>>> I didn't see templateId or flavorId or any equivalent.  How do
>>>>> instances (or portions there-of) declare conformance to "additional"
>>>>> constraint specifications/conformance profiles than the base one for that
>>>>> particular server?
>>>>>
>>>>> We need to beef up the RIM mapping portion considerably.  Mapping to a
>>>>> single RIM class or attribute isn't sufficient.  Most of the time, we're
>>>>> going to need to map to a full context model that talks about the
>>>>> classCodes, moodCodes and relationships.  Also, you need to relate
>>>>> attributes to the context of the RIM location of your parent.
>>>>>
>>>>> There's no talk about context conduction, which from an implementation
>>>>> perspective is a good thing.  However, I think it's still needed behind the
>>>>> scenes.  Presumably this would be covered as part of the RIM semantics
>>>>> layer?
>>>>>
>>>>> In terms of the "validate" transaction, we do a pseudo-validate in
>>>>> pharmacy, but a 200 response isn't sufficient.  We can submit a draft
>>>>> prescription and say "is this ok?".  The response might be as simple as
>>>>> "yes" (i.e. a 200).  However, it could also be a "no" or "maybe" with a list
>>>>> of possible contraindications, dosage issues, allergy alerts and other
>>>>> detected issues.  How would such a use-case be met in this paradigm?
>>>>>
>>>>> At the risk of over-complicating things, it might be useful to think
>>>>> about data properties as being identifying or not to aid in exposing
>>>>> resources in a de-identified way.  (Not critical, just wanted to plant the
>>>>> seed in your head about if or how this might be done.)
>>>>>
>>>>>
>>>>> All questions and comments aside, I definitely in favour of fleshing
>>>>> out this approach and looking seriously at moving to it.  To that end, I
>>>>> think we need a few things:
>>>>> - A list of the open issues that need to be resolved in the new
>>>>> approach.  (You have "todo"s scattered throughout.  A consolidated list of
>>>>> the "big" things would be useful.)
>>>>> - An analysis of how we move from existing v3 to the new approach, both
>>>>> in terms of leveraging existing artifacts and providing a migration path for
>>>>> existing solutions as well as what tools, etc. we need.
>>>>> - A plan for how to engage the broader community for review.  (Should
>>>>> ideally do this earlier rather than later.)
>>>>>
>>>>> Thanks to you, Rene and others for all the work you've done.
>>>>>
>>>>>
>>>>> Lloyd
>>>>>
>>>>> --------------------------------------
>>>>> Lloyd McKenzie
>>>>>
>>>>> +1-780-993-9501
>>>>>
>>>>>
>>>>>
>>>>> Note: Unless explicitly stated otherwise, the opinions and positions
>>>>> expressed in this e-mail do not necessarily reflect those of my clients nor
>>>>> those of the organizations with whom I hold governance positions.
>>>>>
>>>>>
>>>>> On Fri, Aug 19, 2011 at 9:08 AM, Grahame Grieve <
>>>>> grahame@kestral.com.au
>>>>>
>>>>> > wrote:
>>>>>
>>>>>
>>>>> hi All
>>>>>
>>>>> Responses to comments
>>>>>
>>>>> #Michael
>>>>>
>>>>> > 1. I would expect more functional interface to use these resources.
>>>>>
>>>>> as you noted in later, this is there, but I definitely needed to make
>>>>> more of it. That's where I ran out of steam
>>>>>
>>>>> > 2. One of the things that was mentioned (e.g. at the Orlando
>>>>> > WGM RIMBAA Fresh Look discussion) is that we want to use
>>>>> > industry standard tooling, right? Are there enough libraries that
>>>>> > implement REST?
>>>>>
>>>>> this doesn't need tooling. There's schemas if you want to bind to them
>>>>>
>>>>> > 2b. A lot of vendors now implement WebServices. I think we should
>>>>> > go for something vendors already have or will easilly adopt. Is that
>>>>> the case with REST?
>>>>>
>>>>> Speaking as a vendor/programmer/writer of an open source web services
>>>>> toolkit, I prefer REST. Way prefer REST
>>>>>
>>>>> > Keep up the good work!
>>>>>
>>>>> ta
>>>>>
>>>>> #Mark
>>>>>
>>>>> > I very much like the direction of this discussion towards web
>>>>> services
>>>>> > and in particular RESTful web services.
>>>>>
>>>>> yes, though note that REST is a place to start, not a place to finish..
>>>>>
>>>>> > At MITRE we have been advocating this approach for some time with our
>>>>> hData initiative.
>>>>>
>>>>> yes. you'll note my to do: how does this relate to hData, which is a
>>>>> higher level
>>>>> specification than the CRUD stuff here.
>>>>>
>>>>> #Eliot
>>>>>
>>>>> > Hats off - I think it's an excellent piece of work and definitely a
>>>>> step in right direction.
>>>>>
>>>>> thanks.
>>>>>
>>>>> > I didn't know other people in the HL7 world other than me were
>>>>> talking about
>>>>> > (highrise).  Who are they?
>>>>>
>>>>> not in Hl7. you were one. it came up in some other purely IT places
>>>>> that I play
>>>>>
>>>>> >  5) Build it up by hand with a wiki - it is more scalable really
>>>>> since you
>>>>>
>>>>> wiki's have their problems, though I'm not against them.
>>>>>
>>>>> > 1) I think it would be better not to use inheritance to define a
>>>>> patient as
>>>>> > a sub type of a person.  The trouble with that approach is that
>>>>> people can
>>>>>
>>>>> On the wire, a patient is not a sub type of person. The relationship
>>>>> between the two is defined in the definitions.
>>>>>
>>>>> > A simpler approach is associate additional data with a person if and
>>>>> when
>>>>> > they become a patient.
>>>>>
>>>>> in one way, this is exactly what RFH does. On the other hand, it
>>>>> creates a
>>>>> new identity for the notion of patient (for integrity). We can discuss
>>>>> whether that's good or bad.
>>>>>
>>>>> > 2) I'd avoid language that speaks down to 'implementers'.  It's
>>>>> enterprise
>>>>>
>>>>> really? Because I'm one. down the bottom of your enterprise pole. And
>>>>> I'm happy to be one of those stinking implementers down in the mud.
>>>>> I wrote it first for me. But obviously we wouldn't want to cause
>>>>> offense.
>>>>> I'm sure I haven't caused any of that this week ;-)
>>>>>
>>>>> > 3) If you want to reach a broader audience, then simplify the
>>>>> language.
>>>>>
>>>>> argh, and I thought I had. how can we not use the right terms? But I
>>>>> agree that the introduction is not yet direct enough - and that's after
>>>>> 4 rewrites to try and make it so....
>>>>>
>>>>> Grahame
>>>>>
>>>>>
>>>>> ************************************************
>>>>> To access the Archives of this or other lists or change your list
>>>>> settings and information, go to:
>>>>>
>>>>> http://www.hl7.org/listservice
>>>>>
>>>>>
>>>>>
>>>>> ************************************************
>>>>> To access the Archives of this or other lists or change your list
>>>>> settings and information, go to: http://www.hl7.org/listservice
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *--
>>>>> Best regards,
>>>>>  Andrew                             *
>>>>> mailto:andrew@Medical-Objects.com.au <andrew@Medical-Objects.com.au>
>>>>>
>>>>> *sent from a real computer*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ************************************************
>>>>>
>>>>> To access the Archives of this or other lists or change your list settings and information, go to: http://www.hl7.org/listservice
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jim McCusker
>>>>> Programmer Analyst
>>>>> Krauthammer Lab, Pathology Informatics
>>>>> Yale School of Medicine
>>>>> james.mccusker@yale.edu | (203) 785-6330
>>>>> http://krauthammerlab.med.yale.edu
>>>>>
>>>>> PhD Student
>>>>> Tetherless World Constellation
>>>>> Rensselaer Polytechnic Institute
>>>>> mccusj@cs.rpi.edu
>>>>> http://tw.rpi.edu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jim McCusker
>>>>> Programmer Analyst
>>>>> Krauthammer Lab, Pathology Informatics
>>>>> Yale School of Medicine
>>>>> james.mccusker@yale.edu | (203) 785-6330
>>>>> http://krauthammerlab.med.yale.edu
>>>>>
>>>>> PhD Student
>>>>> Tetherless World Constellation
>>>>> Rensselaer Polytechnic Institute
>>>>> mccusj@cs.rpi.edu
>>>>> http://tw.rpi.edu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>