Re: A Fresh Look Proposal (HL7)

Hi, Dave,

 >>>Is there a REST mechanism to expose RDF data?
There is a Linked Data API specification available which supports the
creation of simple RESTful APIs over RDF triple stores.

http://code.google.com/p/linked-data-api/wiki/Specification

-Guoqian


Guoqian Jiang, Ph.D.
===========================================
Assistant Professor of Medical Informatics
Division of Biomedical Statistics & Informatics,
Mayo Clinic College of Medicine
200 First Street, SW,
Rochester, MN, 55905
Tel: 1-507-266-1327
Fax: 1-507-284-0360
Email: jiang.guoqian@mayo.edu
===========================================


On 9/17/11 1:32 PM, "Hau, Dave (NIH/NCI) [E]" <haudt@mail.nih.gov> wrote:

> Back to "forget the plumbing" and focus on the content, how would you define a
> unit of content for a particular purpose (e.g. a blood pressure reading) in
> OWL and/or RDF?  This would correspond to an archetype or Detailed Clinical
> Model (DCM), and would be a subset of the domain ontology(s).
>  
> I also came across the hData effort which seems very promising:
>  
> http://www.projecthdata.org
>  
> They are proposing a REST mechanism for transport (with some basic HTTP based
> security as well), and a generic content format (hData Record Format) that's
> primarily XML based currently, but potentially could be adapted to carry RDF
> payload.  (The REST mechanism claims conformance to the OMG RLUS profile, with
> a semantic signifier linking the data to the information model.  IMHO this
> could potentially be adapted to use RDF instead, that's linked to concepts in
> an OWL model.)  Is there a REST mechanism to expose RDF data?
>  
> - Dave
>  
>  
>  
> 
> From: Jim McCusker [mailto:james.mccusker@yale.edu]
> Sent: Monday, August 22, 2011 9:40 AM
> To: conor dowling
> Cc: Hau, Dave (NIH/NCI) [E]; public-semweb-lifesci@w3.org
> Subject: Re: FW: A Fresh Look Proposal (HL7)
>  
> 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 <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 <tel:%2B1-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 <tel:%2B1-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
> 
> 
>