Updated to the SHR recommendation

Hi all,

We have received some feedback from the community around the SHR recommendations. These comments and changes have been made in the recommendations document available here: https://wiki.ohie.org/display/SUB/Shared+Health+Record+options+and+recommendation

Please could you read through this document and if you have any more comment or suggestions I’m sure the community would be very willing to hear them.

Thanks all for your comments so far.

Cheers,

Ryan

···


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

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 :slight_smile:

Best regards,
Odysseas

···

On 08/01/2013 08:41 AM, Ryan Crichton wrote:

Hi all,

We have received some feedback from the community around the SHR recommendations. These comments and changes have been made in the recommendations document available here: https://wiki.ohie.org/display/SUB/Shared+Health+Record+options+and+recommendation

Please could you read through this document and if you have any more comment or suggestions I'm sure the community would be very willing to hear them.

Thanks all for your comments so far.

Cheers,
Ryan

--
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org <mailto:ryan@jembi.org>
--
You received this message because you are subscribed to the Google Groups "Shared Health Record (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Odysseas Pentakalos, Ph.D., PMP
Chief Technology Officer
SYSNET International, Inc.
2930 Oak Shadow Drive
Oak Hill, Virginia 20171
mailto:odysseas@sysnetint.com
(703) 855-2029

Hi Odysseas,

Thanks for this great content. I found this really useful and the blog posts by Graham Grieve very interesting.

I do think that pure HL7 v3 is not sound like a very strong option at this point. FHIR, on the other hand, I’m liking more and more.

To me it seems that what we need is a more general standard than what the IHE profiles allow as the IHE profile are very use case specific. We would want to store arbirary information for a patients record not just specific docuemnts. I don’t see IHE standards that can do that (I’m happy to hear other suggestions!). The best options seems to be either HL7 v2 or the new FHIR standard. I’m going to be exploring FHIR a little more over the coming days so I can help us understand it more clearly.

What do other in the community think about these great points that Odysseas has raised.

Cheers,

Ryan

···

On Thu, Aug 1, 2013 at 4:59 PM, Odysseas Pentakalos, Ph.D. odysseas@sysnetint.com wrote:

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 :slight_smile:

  Best regards,

  Odysseas




  On 08/01/2013 08:41 AM, Ryan Crichton wrote:

Hi all,

      We have received some feedback from the community around

the SHR recommendations. These comments and changes have been
made in the recommendations document available here: https://wiki.ohie.org/display/SUB/Shared+Health+Record+options+and+recommendation

      Please could you read through this document and if you have

any more comment or suggestions I’m sure the community would
be very willing to hear them.

Thanks all for your comments so far.

Cheers,

Ryan


Ryan
Crichton

                  Software

Developer, Jembi Health Systems | SOUTH
AFRICA

                  Mobile:

+27845829934 | Skype: ryan.graham.crichton

                  E-mail: ryan@jembi.org

  You received this message because you are subscribed to the Google

Groups “Shared Health Record (OpenHIE)” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to openhie-shr+unsubscribe@googlegroups.com.

  For more options, visit [https://groups.google.com/groups/opt_out](https://groups.google.com/groups/opt_out).
-- Odysseas Pentakalos, Ph.D., PMP
Chief Technology Officer
SYSNET International, Inc.
2930 Oak Shadow Drive
Oak Hill, Virginia 20171
mailto:odysseas@sysnetint.com
(703) 855-2029

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org