Implementing HL7v2 and FHIR in SOA architectures
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,737 vues
The journey to HL7 FHIR enabled next generation unified healthcare product platform with seamless support for HL7v2, HL7 CDA and FHIR
Recommandé
Recommandé
Contenu connexe
Tendances
Similaire à Implementing HL7v2 and FHIR in SOA architectures
Similaire à Implementing HL7v2 and FHIR in SOA architectures (20)
Dernier
Dernier (20)
Implementing HL7v2 and FHIR in SOA architectures
- 1. The Benefits and Challenges of implementing HL7v2 in SOA Victor CHAI Member of Technical Sub-committee HL7 Singapore
- 2. Why I want to talk about this topic • It all started with a question I received during one of the HL7 technical subcommittee meeting where one member asked – “… a standard based XML payload for SOA services and the ability for easy transformation of HL7v2 messages to that XML” – That was also one of the reasons that I started my own blog to share my knowledge and experience in healthcare interoperability http://healthinterconnect.blogspot.sg/2011/08/using-hl7v2-in-soa.html
- 3. Gist of the Question • Shared SOA service that is able to process/consume both HL7v2 message and XML based message • Standards based payload for SOA service
- 4. Is this topic still relevant today • HL7v2 is still widely used here and abroad US Meaningful Use Requirements on Content Exchange - Both HL7v2.5 and HL7 CDA Source: http://www.corepointhealth.com/sites/default/files/whitepapers/hl7v2-v3-evolution.pdf
- 5. What concrete example I will use here • The EHR product I have personally architected and implemented 7 years ago • The intent is to share what is still useful and relevant today • “New” challenges surfaced and the improvement
- 6. Key Architecture Requirements • A unified multi-purpose health record platform for rapid application development – – – – PHR EHR Health Assessment Health Tracker (Adobe Flex) 1/2
- 7. Key Architecture Requirements • Supports standards based exchange format – HL7v2 and HL7 CDA • Different protocols – – – – MLLP for HL7v2 SOAP Web Service Restful Service HTTP • Also needs to support proprietary format 2/2
- 8. Challenges of HL7v2 in SOA • There is no or limited out-of-box programming support for parsing and composing HL7v2 message • A special TCP based protocol – MLLP - Minimal Lower Layer Protocol (MLLP) • And others such as Sequencing and Threading
- 9. HL7v2 Integration Engine was used • Use HL7v2 Integration Engine HL7v2 Message • Validates and parses incoming HL7v2 message and transform to XML encoded HL7v2 • OracleAQ was used between B2B and Integration Layer HL7v2 B2B Gateway Oracle AQ Message Control and Transformation Service Integration Layer
- 10. What was used for service payload • Standards based service payload? XML encoded HL7v2 Message HL7v2 Message – Such as HL7 CDA, adopt and adapt? • Or others? B2B Control Layer Oracle AQ Message Control and Transformation Service Integration Layer
- 11. A simplified CDA based payload • Based on HL7v2 CDA R2 as shown on the right • Simplify underlying data type and structure for more flexible parsing and processing
- 12. How to support HL7v2 wire format • XLST transforms the parsed XML encoded HL7v2 message to Service payload format
- 13. How to support HL7 CDA R2 wire format • Transform different types of records to corresponding section in HL7 CDA R2
- 14. My past architecture design recap • Standards-based Service Payload • One shared service supports multiple client friendly format & protocol – HL7v2 message – HL7 CDA – Or proprietary format
- 15. The ‘new’ challenge • Do we copy and paste the external content into our site page, or we simply use URL link to reference the external content when we build a web site? • Why it is important? – Prevent information proliferation, and avoid obsolete information – There is no need to fetch all at one go, the requester can „follow’ the path to navigate to the needed information – Each app can focus on managing its own information, and relies on reference to build up network of information
- 16. The new approach – RESTful design • Treat each data entity as a native resource which behaves likes a web page, users can create/update/delete a resource • Each resource has a unique identifier, and reference to other dependent resources
- 17. HL7 FHIR – Why? • Strong foundation in Web standards– XML, JSON, HTTP, Atom, OAuth, etc. • Support for RESTful architecture style and also seamless exchange of information using messages or documents Source: http://www.hl7.org/implement/standards/fhir/summary.htm
- 18. HL7 FHIR – Fast Health Interoperable Resources • “Resource “ is unit of transactional data such as patient and MedicationPrescription that is stored or exchanged resource type • Easily accessible - http://server.org/resources/patient/S1234567H endpoint identifier
- 19. HL7 FHIR - A network of resources MedicationPrescription Encounter Patient Prescriber Medication
- 20. How FHIR improves the design • Use HL7 FHIR as straight-through resource API and internal object model • There is no intermediate transformation
- 21. HL7 FHIR – A Sample Resource Definition
- 22. HL7 FHIR – How to implement • Step 1 – Download Resources classes from HL7 site – http://www.hl7.org/implement/standards/fhir/ – Download either Java, C# or Delphi • Use your favorite IDE and RESTful Web Services framework e.g. Jersey – Implement RESTful resource
- 23. HL7 FHIR – A few lines of code only! These are just for validation only
- 24. FHIR enabled architecture Messaging and Document based Integration Lightweight Restful Service
- 25. Summary • “ If you want to go fast, go alone. If you want to go far, go together” • Learn from standards, adopt and adapt! – http://www.hl7.org.sg/ – http://www.hl7.org/fhir
Notes de l'éditeur
- Even though my presentation title is “the benefits and challenges of implementing HL7v2 in Service Oriented Architecture”, here I am not going to spend much time on the benefits, rather I will spend most of the time on the challenges, the simple reason is that if your SOA implementation is not able to reuse whatever IT assets you have built over the years, that what’s the point of trying to be SOA. Secondly I will share what I have learned over the years on how to appropriately leverage standards in tackling the challenge, make the software architecture more resilient, and ultimately bring down the overall integration cost
- I have been thinking hard on what the exact topic I’d like to share here so that the audience will find it really useful and practical, you can apply it in your day-to-day work. Then one day I looked at my own blog which I have not actively blogging for the past one year due to heavy work commitment, then I saw my first post which was about two years ago, one of the HL7 SG technical sub-committee member asked me this question, ““… a standard based XML payload for SOA services and the ability for easy transformation of HL7v2 messages to that XML”I thought this is useful and still relevant, and I found my answer at that time was incomplete, so here I am taking this opportunity to fully explain and share my thoughts.
- Just to recap the gist of the questions posed here1) Shared services to support different wire format requirements, e.g. HL7v2, HL7 CDA or even proprietary format2) Standards based payload for the shared services
- A lot of ancillary systems within hospitals are still widely using HL7v2, and most of them not yet be able to support XML based exchange format yetAs we can see, even US MU still mandates HL7v2 as one of the exchange format besides HL7 CDA
- What I am going to talk through here is my own journey of architecting and developing the EHR product suite more than 7 years ago, why I made certain decisions at that time, and looking back, how I can improve. Just like the quote as shown on the right, we can’t solve the problems by using the same kind of thinking we used when we created them
- Next two slides, I just briefly share the high level architecture requirements, so all of us here get a sense on what kind of product I was architecting, and provide a business context for the technical decisions I made over the timeOn this slide, the key requirement is that this product suite should not be individual monolithic applications in which business capabilities are implemented and buried inside every application that requires them, the key is service centric instead of application-centric design
- Second, it needs to support standards exchange format such as HL7v2 and HL7 CDA, as these two are the pre-dominant exchange format most COTS product support
- For XML support, it is more straightforward, programming is easy, the library for handling XML is built-in. However to support pipe line separated HL7v2 message, There is no or limited out-of-box programming support for parsing and message construction2) HTTP which is more friendly for programming than MLLPWhen using MLLP, an HL7 message must be wrapped using a header and trailer (also called a footer) to signify the beginning and end of a message. These headers and footers are usually non-printable characters that would not be shown in the actual content of an HL7 message.3) Sequencing<No need to talk about the below>HTTP implementations are commonly multi-threaded, particularly in HTTP server implementations. This can present a risk that messages will be processed in a different order than the one in which they were generated. Because message sequence is often important in HL7 v2.x transactional messaging, implementers should consider how to ensure that messages are processed sequentially. The HL7 sequence number protocol may be used in this case. For certain types of data transactions between systems the issue of keeping databases synchronized is critical. An example is an ancillary system such as lab, which needs to know the locations of all inpatients to route stat results correctly. If the lab receives an ADT transaction out of sequence, the census/location information may be incorrect. Although it is true that a simple one-to-one acknowledgment scheme can prevent out-of-sequence transactions between any two systems, only the use of sequence numbers can prevent duplicate transactions
- So how do we solve those HL7v2 challenges I mentioned just now, the solution is, as most of us will reach the similar conclusion, is to make use of HL7v2 integration engine so that I can concentrate on building the core shared services instead of spending time on these plumbing work. just for your info, I used Oracle b2b gateway which supports industry message payload such as HL7v2, EDI and ebXML etc.V2 message comes into B2b gateway, internally it performs message validation and then transform XML encoded format, and then pumps into integration layer via messaging queue.
- Now the HL7v2 message has been transformed into XML encoded v2 message internally, what should be used to define service payload to consume and process the incoming HL7v2 message?I have two options at that time, one is to create service payload based on HL7 CDA – it is XML based HL7 exchange format for sharing clinical documents such as discharge summary, progress notes and OT notes, or I can just ignore what is out there, and create my own?
- After internal discussion, the conclusion is middle ground, As you can see on the right, this is the general structure of CDA. I am not going to walk through CDA in detail, but just want to brief mention that each CDA document contains multiple sections of data, each section contains certain type of data such as medication list, problem list, or alerts and allergies, and it supports both structured and unstructured data. So we found this general structure is quite useful and we can keep it.Yet we simplified the underlying data structure to make the programming easier.And the simplification is mostly for ease of programming in thick client apps and mobile apps where programming support is not so rich as in sever wide programming.
- Now the service payload has been defined, the processing of HL7v2 message is just straightforward, simple XSLT transformation as shown on the right, you might no be able to see it clearly, but no worry, you will be able to access my slides after the event.
- For external communication with other EMR products which supports HL7 CDA, it is also very straightforward, since the internal object model is loosely based on HL7 CDA, it is nearly straight-through mapping
- Earlier I mentioned that first part of the presentation I will walk through the architecture I personally designed and implemented 7 years ago, second part I also would like to share with all of you the refreshed design with the latest development in technologies and interoperability standards space. Before moving on to the refreshed design, lets first take a look at what kind of new challenge I am facing, or as a matter of fact many of us are facing even though we may claim the solution is service oriented architecture design, but in the end it seems just like a bunch of web service, there does not seem to have real benefits of adopting SOA at all.Typical approach we used in integration project so far, be it “messaging” or SOA integration, it just “moving” data across. So why we want tomove data across, I can think of two reasonsFirst reason is that the application can easily locate the data if it is within its own backyard, Second reason is that it gives us the perception that it is faster if the data is within the application. Though those are valid reasons, but is there any better way to satisfy these requirements without moving data across, also for these messaging or service integration, the client needs to remember each service endpoint in order to make request, is there any way that we do not need to remember every service endpoint, once the client have gained access to the entry point service, the client is able to figure out what additional services the application provides?Lets use an another analogy to look at the problem and kind of solution we are going to apply here
- So what’s the benefits of adopting RESTful design,REST is built on top of the HTTP protocol – the same protocol you use when requesting a web page in your browser.Decouple service client and service providerAllows service provider application to advertise new capabilities by putting new references in the responses. If the client developers are keeping an eye out for unknown references then these references can be a trigger for further exploration.Okay it looks like a neat design, so anything I can leverage? There seems be one emerging HL7 standard we can leverage, that is HL7 FHIR – Fast Health Interoperability Resources.
- Why?. It natively supports XML, JSON and Atom. Also supports both traditional messages and document based exchange, and RESTful architecture style.The Atom Syndication Format is an XML language used for web feeds, while the Atom Publishing Protocol (AtomPub or APP) is a simple HTTP-based protocol for creating and updating web resources.
- So what is exactly FHIR. FHIR solutions are built from a set of modular components called “Resources”. These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternativesAnd “Resources” hashas a known identity (a url) by which it can be addressed as you can see on the screencontains a set of structured data items as described by the definition of the resource typecontains a human-readable representation of the content of the resource, just like HL7 CDA
- This is a sample of MedicationPrescription resource and its dependent resources such as encounter, patient, prescriber and medication
- This is an example of MedicationPrescription resource definition. Each resource definition contains a UML diagram as seen here. It is simple and easy to understand for developers and clinicians. Each resource definition also provides the corresponding XML schema definition
- As you can see here, implementing HL7 FHIR is so simple, just few lines of code which are mostly annotation. This is a sample URL to retrieve Patient resource of patient ID “1234567”. Now lets look at the corresponding annotationGET – represents this is for http getPATH – indicates the patterns of the URL pathProduces – specify it supports both XML and JSON wire format
- Now lets put all together, this is the FHIR enabled design. On the top, the application uses FHIR restful services for integration, and on the left, it uses messaging and document based integration which typically uses SOAP based web service integration
- Before I end my talk, I’d like to dismiss two extreme and dangerous mindsets about standards,Standard is panacea, you plug into the socket, it will just magically work. This is consultant talkStandard is useless, I should create my own one, it is faster for my implementation. Just remember the service you build is for others to consume, if we keep on creating proprietary format, yet it may be faster for you, but for users who is going to consume the services, the proprietary format is total alien and much more obscure than standards one which is at least scrutinized by so many ppl. Just remember “ If you want to go fast, go alone. If you want to go far, go togetherLastly, if you want to find out more, you can always go to HL7 site to check it out.