Re: A Fresh Look Proposal (HL7)

Dave,

these words ...

>> *below* would correspond to the RDF triples for the data, which would be
annotated to concepts in the knowledge *layer* i.e. the DAMs,

"layer" and "below" brought me back to the references to "media" from many
mails ago. In linked-data or broadly graphs, there's no up or down, no neat
"layer" - there's just an accretion of facts. There's no "model" vs
"terminology", just assertion after assertion: some are of type, some of
thing, some broad, some so precise they're dead ends, but the medium doesn't
lend itself to spatial metaphors I think. It's more ball-of-wool than
division-of-labor.

On that note, along with much else, Matthias' paper shows just how many
parallel efforts in medical modeling there are out there, many overlapping
in places, some redundantly. The nice thing about getting everyone into a
common space is that the unique aspects, the valuable "why we should care"
attributes, would jump out as one scheme clearly covers areas unforeseen
elsewhere. Were all to get into a 'creative commons' then truth will out. Of
course, if each hides out in its own room then ...

>> "Development of policy and access control enabling proprietary Linked
Data complementing the public Linked Data to be exchanged in limited
partnerships."

as you say Dave, "well done", as this is key to putting the "security bear"
back in its cage.

Conor

On Mon, Aug 29, 2011 at 1:46 PM, Hau, Dave (NIH/NCI) [E] <haudt@mail.nih.gov
> wrote:

> Matthias, thanks for the paper.  Please keep us posted on the new CDS task
> force within HCLS.  I would be interested in participating.****
>
> ** **
>
> I agree with your statements in the paper (Section 1.1) where you mentioned
> the collaborative nature of this effort involving multiple SDOs and
> organizations such as HL7, W3C HCLS, and organizations reviewing current
> evidence and publishing recommendations about pharmacogenetics such as CPIC
> and EGAPP.  As one of the first steps, I think a harmonized semantic
> framework for reasoning among the different organizations would be a great
> start, such as incorporating rigorous logic-based reasoning into the HL7
> DAMs as we've been discussing.  I think a wider cross-participation between
> HL7 and W3C HCLS would be very beneficial for this reason.****
>
> ** **
>
> In Figure 1, it seems that there is a direct feedback loop for "data and
> concept mining" directly into the knowledge server.  In light of Section
> 1.1, I was wondering if it may be more pragmatic to have the results of data
> mining go to the evidence/recommendation organizations like CPIC first, have
> them review the data and draft concrete recommendations, then feed the
> recommendations back to clinical practice and patient care.****
>
> ** **
>
> Conor, I agree the current Meaningful Use stage 1 does not produce much
> data that's semantically rich enough for data mining or knowledge discovery.
> But I believe stages 2 and 3 will focus more on the secondary use aspects of
> EHR data. Specifically, I think various parts of the HIT Standards Committee
> (such as Stan Huff's metadata analysis power team) are looking at the
> content part, how to harmonize the content standards to maximize secondary
> use, such as knowledge discovery, comparative effectiveness, quality
> improvement, personalized medicine etc.  Getting the providers to start
> using EHRs in stage 1 would be a good start, but not the final destination
> as you mentioned.****
>
> ** **
>
> Michael, I agree the DAMs represent the knowledge layer, and the RMIMs will
> be developed from the DAMs where the message formats will come from.  I
> guess in semantic web speak, the RMIMs and below would correspond to the RDF
> triples for the data, which would be annotated to concepts in the knowledge
> layer i.e. the DAMs, which hopefully would be harmonized with other
> reference domain ontologies out there as well, so there is no concept
> inconsistency for the user to worry about.****
>
> ** **
>
> Incidentally, even though the new HL7 Resources for Health effort being
> proposed, would bring about improvements to v3 in various aspects, I don't
> think enough attention has been paid to validating or examining the semantic
> framework based on RIM, to describe in details the step-by-step process you
> would follow to perform logic-based reasoning on RIM-based semantics.  I
> think such a detailed analysis would be very helpful in harmonizing HL7
> semantics to the latest semantic web standards and technologies, in the
> direction described by the counter-challenge to HL7 from this 2010 paper
> from the Buffalo team:****
>
> ** **
>
> http://precedings.nature.com/documents/3960/version/2****
>
> ** **
>
> - Dave****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Matthias Samwald [mailto:matthias.samwald@meduniwien.ac.at]
> *Sent:* Sunday, August 28, 2011 2:03 PM
> *To:* conor dowling; M. Scott Marshall
>
> *Cc:* Michael Miller; Hau, Dave (NIH/NCI) [E]; Jim McCusker; John Madden;
> public-semweb-lifesci@w3.org
> *Subject:* Re: A Fresh Look Proposal (HL7)****
>
> ** **
>
> 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****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
>
>
> ****
>
> ** **
>
> ** **
>
> ** **
>