Skip to Content
Hello blog visitors, sorry it took a long break to the follow-up blog.   In this blog I would like to share our studies of understanding standards with you.  Our understanding of standardHealthcare Standards are already existing and being used for a long time in the entire healthcare world.  However the use of the standards is different from hospital to hospital and this causes large integration cost. One example would be HL7; there is a Z-Segment in HL7 message segments which originally provides a flexibility of using HL7 message, and it is exactly this flexibility that causes the complexity of the message exchange among hospitals.  So in this case HL7 standard does not fully help how to use the standard.  IHE (Integrating Healthcare Enterprises)is different, because it provides the integration profiles based on healthcare standards like HL7. The focus of IHE is to recommend the healthcare vendors to implement their solutions in a common integration “way&#148. Vendors shall know which Integration Profiles will be supported by their products, which roles the products play in the Integration Profiles. IHE defines the typical healthcare use cases with some basic standard message transactions for that role in that Integration Profile, which shall be supported by the products.  In this way IHE simplifies the cross enterprise integration, guide the healthcare vendors how to use standards on a process-oriented way. For customers IHE statement is becoming one of their criteria when they acquire products.  Our StudySAP’s Enterprise Services and Netweaver technology provide the customers and partners an open and flexible process-oriented platform. This platform is also the backbone in supporting standards.  Standard means not only the standard message, but also standard service content. To define the Healthcare Enterprise Repository Services, we have leveraged the possible resources to help us understand the standard processes. Our start points were: talking to partners, customers, learning from the standard organization, which is in our case IHE.    We have compared the business scenarios and process from our Healthcare Solution Maps with the IHE Integration Profiles. Please see the following slide as a first result. imageOur understanding of Standards – After our studyIHE has comprehensive Integration Profiles which cover 10 healthcare domains, however some of the typical business scenarios which from our point of view would be very important are still need to be supplemented. For example: Billing, Resource and Supply Chain Planning, Logistic and so on.   SAP healthcare based on ERP powerful functions supports the processes from resource and logistic planning to patient treatment and patient management; most of them are currently not described in IHE.  At the end we focused first on the IT-Infrastructure domain and the Patient Administration Management (PAM), Patient Demographic Query (PDQ) profiles, which could be supported by the Enterprise Services and Netweaver Platform.   Our study showed us, IHE has provided a very good chance to gather healthcare vendors together, to use the standards, to share their experiences to optimize using of standards. The Integration Profiles with basic standard message granularity are good guidelines for vendors; however there are still a lot to do to complete the healthcare scenarios. SAP as one of the active healthcare service providers with his long experiences and many successful stories in healthcare industry, SAP shall and will play more active in the IHE, to help us to follow up the standard, to share our experience and knowledge with other healthcare providers.  The nextWe would like to invite you to our Healthcare BPX forum, see the link SAP for Healthcare , to share your opinions and experiences with us. My colleagues and I would be happy to meet you there.  In the next blog I would like to tell you some of our experiences about how the SAP Enterprise Services enable healthcare standards.  I hope to see you next time! Jing
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Rene Spronk
    Whilst it it easy to define a standard for a 10mm nut & bolt – its exact dimensions, and the tolerances in size expressed in micrometers.

    Now if even something that simple has a “tolerance”, try standardizing (describing in a standardized fashion) a process in healthcare. Even healthcare providers don’t agree on most processes nor on the data that should be conveyed within the process. As such standards like HL7 and DICOM will always have lots of optionalities (tolerances) build in.

    The IHE profiles narrow the area of tolerance to a more acceptable agree, but it’s definitely still there. IHE has been most successfull in those workflows that are pretty standardized around the world, e.g. the 80% use-case of a planned radiology examination.

    Any healthcare messaging standard will need to be tailored to fit the local requirements. One can create country or workflow specific workflows such as created by IHE, the english NHS or the Finnish national infrastructure, but those will still leave open some areas that need to be localized further.

    It’s easy to describe an unambiguous specification if the thing being described has unambiguous characteristics. If we want to have standardized messages/services, we’ll need to standardize workflows and procedures first. Work on a standardized EHR did start around 1964 and still physicians don’t agree as to what should be in it. In the meantime, we implement those standards that offer us the possibility of localization. That’s as good as it gets – and whatever the quirks HL7 and DICOM have a proven track record.

    -René

    (0) 
    1. Claudius Metze
      Hi Rene,

      I think you made some good points here. I also believe that any “standard” to improve interoperability or improve process efficiency will ultimately require standardized semantics.

      We can certainly define technical definitions for any given data element and create technical connections between all kinds of systems but if people or systems have a different interpretation of this data the quality of communication still may be low.

      To me it’s a bit like with English as the universal business language. It’s great to have it, but it alone does not ensure that people really understand each other…and to stay in the picture…even if we agree on a universal language we want to keep our cultural identity sometimes. Thus we need something which can be localized or in a broader sense something flexible which can be adopted along some dimensions. Country specifics are certainly one example, but there are others: roles, size, domains etc.

      Looking back at the history of communication capabilities I think we can certainly state for the vast majority of “standards” that they work quite well in terms of technical qualities (performance, reliability, etc.) but still lack behind when in comes to semantic interoperability. And while you’re right that we will need to standardize the “content” first in order to create a successful specification I still believe that there is some hope…

      With SOA and the more business driven methodologies behind, I believe IT can offer Business more help than ever. Technology advances, uses more business terms, gets more and more flexible and adaptive and thus bridges the gap between business and IT.

      One of the overall observations I have made when comparing traditional integration technologies and the resulting “standards” with SOA, was that Business Process Experts are integrated in the design process from the beginning and that the resulting communication patterns seem to be a better fit to human behavior.

      Best regards
      — Claudius

      (0) 

Leave a Reply