Hi Ryan,
Thanks for sharing the documentation of the work the group is
doing on the SHR. I am very interested in the work you guys are
doing and would love
to attend the calls but I just don't have the time to do so.
Here are a couple of comments I would like to share with the group
for your consideration.
1. I would think twice moving forward with a pure HL7v3 solution.
From listening to the call, I can tell that everyone is familiar
with the weaknesses of
the pure HL7v3 approach but the following article from one of the
architects of HL7v3 who is now one of the main architects of FHIR
describes his
perception of the issues with HL7v3:
http://www.healthintersections.com.au/?p=476 . The title of the
article is "Hl7 needs a fresh look because v3 has
failed. Notice that I use the word pure HL7v3 because that is
different from the constrained use of HL7v3 as the data model for
CDA documents
within XDS messages.
2. We did some work on another project with FHIR over the past 6
months and it looks like a great option. It is very easy to pickup
so, it would
be easily adopted in the environments in which we plan to deploy
OpenHIE, yet, it preserves some of the strengths of the HL7v3
standard
through its support for the RIM and its requirement of coding data
elements to medical terminologies. We built a small prototype to
demonstrate
the exchange of problem lists in an interoperable way and it was
very easy to accomplish this within the limited amount of time we
had. I must
warn you though that this is a very early standard and it is
continuously changing. Some of the resources we were using in our
prototype simply
disappeared in a later release of the standard. The people behind
the standard indicate though that things should stabilize after
September once
FHIR standards undergoing the HL7 ballot process.
3. I like the IHE standards and see the value in them but in my
opinion they have holes in their coverage of the full spectrum of
healthcare IT
transactions. Exchanging granular clinical data via a CDA document
is possible but it is not the ideal approach and in an environment
where the
transaction rates that the system must handle are very high and
where users need access to components of a CDA, composing and
decomposing these
documents is load intensive. This is just something to keep in
mind. OpenEMPI supports both HL7v2 and HL7v3 and if you were to
look at the two
messages side-by-side that achieve the same goal in the two
standards, both within the same IHE profile, you would be amazed
at the sheer size
of the HL7v3 message.
4. I am not sure of the schedule or cost constraints of your
effort but I would propose that you prototype alternative
approaches before making
a decision. The devil is in the details with these decisions so,
prototyping a given approach and comparing it with the other
options would provide
tremendous insight that reading through documentation and
specifications will not give you. If you would like to look at the
FHIR prototype we
implemented, we would be happy to share it with you.
This email turned out to be a lot longer than I expected it to be
so, thanks for reading if you got this far 
Best regards,
Odysseas
On 08/01/2013 08:41 AM, Ryan Crichton wrote: