Re: FW: A Fresh Look Proposal (HL7)

+1



Jamie Ferguson
Vice President, HIT Strategy & Policy
Fellow, Institute For Health Policy
Kaiser Permanente
1 Kaiser Plaza, 24B, Oakland, CA 94612
jamie.ferguson@kp.org
Office:  1-510-271-5639
Mobile:  1-415-250-0561
Fax:  1-510-267-2164

Executive Assistant:  Kay R. Rucker
kay.r.rucker@kp.org
Office:  1-510-271-5647

NOTICE TO RECIPIENT:  If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents.  If you have received this e-mail in error, 
please notify the sender immediately by reply e-mail and permanently 
delete this e-mail and any attachments without reading, forwarding or 
saving them.  Thank you.




From:   Jim McCusker <james.mccusker@yale.edu>
To:     conor dowling <conor-dowling@caregraf.com>
Cc:     "Hau, Dave (NIH/NCI) [E]" <haudt@mail.nih.gov>, 
"public-semweb-lifesci@w3.org" <public-semweb-lifesci@w3.org>
Date:   08/22/2011 06:41 AM
Subject:        Re: FW: A Fresh Look Proposal (HL7)
Sent by:        public-semweb-lifesci-request@w3.org



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

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