- From: Jim McCusker <james.mccusker@yale.edu>
- Date: Mon, 22 Aug 2011 09:39:46 -0400
- 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>
- Message-ID: <CAAtgn=SnOowYkC_ugBe_t3havuJxio0kjXVhhhYgzW2G=_AEnA@mail.gmail.com>
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
Received on Monday, 22 August 2011 13:40:36 UTC