Browse by Tags

• CCR
• CHF
• Events
• HCE
• HealthVault
• IHE
• MS-HUG
• Open XML
• PHR
• Security
• WCF

• Designing HealthVault’s Data Model

  It’s been about a month now since we released HealthVault and we heard a lot of great feedback from the industry. Pretty much everyone in Health has an opinion on HealthVault :-) I also saw some interesting debate regarding how HealthVault addresses the big elephant in the room: compliance with existing standards. I have been involved in the standards community in healthcare for a long time and contributed first hand to several of the standards that are adopted today, including the ASTM CCR, HL7 and the IHE Interoperability Profiles. We have demonstrated in the past strong support for standards in healthcare and we are committed to the idea of interoperability based on standard protocols and data formats. I talked to Sean Nolan, our Chief Architect for HealthVault, about the philosophy behind the data model design and I asked him to give a brief explanation. Here is what he had to say: Wherever possible, we are using existing standards both for interchange in and out of HealthVault as well as within it. Many of our data types draw directly from standards such as the ASTM CCR, the IndivoHealth project and soon the HL7 CDA/CCD. Some of the data types we needed in order to support our partners’ applications where not readily available in the standards community. In those cases, for example for the “aerobic exercise” data type, we have worked in concert with clinical and application partners to make sure that we capture the right information. We are not the domain experts – our partners are, and we are leveraging their expertise to help us build up the dictionary of HealthVault types. Our decisions around data type definitions are driven by four key principles: 1. Interoperable. When designing our information model, we try to do our best to make our data types interoperable with industry standards in actual use. Each individual data type generally represents a superset of the correspondent industry standards data type. This way we enable our partners to more easily take the information stored in HealthVault and populate a standard ASTM CCR or HL7 CDA XML document or to take an existing ASTM CCR or HL7 CDA XML document and populate the atomic HealthVault data. 2. Inclusive. When designing the HealthVault data model we had to strike a balance between fully structured data and unstructured information. This is in line with a number of the industry standards that allow, for example, dates to be represented as the string “when I was a kid”. Our types are designed to be as inclusive as possible - with the ability to capture structure when it is available, but still take in the data when structure is missing. Our use of “coded values” is one example - we allow simple text strings for things like lab results, but if LOINC codes or similar are available we handle them as well. This does make life somewhat harder for application developers - but ultimately we believe it is well worth the added complexity. This philosophy is also expressed in other parts of the system - for example, we support the ability for people to fax information into their records. An image of your immunization history isn’t as good as structured data - but it sure is better than not having it at all. 3. Just in Time. If the data types you see in the HealthVault today seem a bit arbitrary, it is due to how we approached their design with our early partners. Our data model is growing as we work with partners fluent in various domains. For example, we got help on our fitness types from Polar, and learned a great deal from J&J Lifescan when it came to blood glucose measurements. 4. Independent. As much as possible, we have tried to keep application development simple by eliminating relationships across data items. For example, for medication we store the information on the prescribing physician in the data item rather than as a pointer to another data item describing the physician. Managing data integrity across partners would be a huge problem if we had a real normalized schema behind the HealthVault system. Our goal has been to allow expression of those connections but never rely on their existence for data integrity. Our types also allow each vendor to add “extensions” of their own making to item data – so to the extent that we are missing certain fields, they can be added – and the industry can rally around those extensions if it makes sense. We’re also working on a process for partners to submit these extensions for inclusion in the HealthVault base types. We appreciate the richness of the clinical formats developed by the standards community. This is the reason that when we take data from external sources, we keep the original available as a single package that can be shared and managed just as any other type can be. In addition to this, we support through our API the ability to extract of the component pieces of those items and - when appropriate -store them into more discrete types. I strongly suggest you download our SDK from the HealthVault MSDN Developer Center and have a look at the data types. Also, if you spend enough time looking at the SDK, you’ll see “traces” :-) of how we support ASTM CCR and HL7 CDA CCD: And I hope this helps explain our thinking and some of the principles behind the design HealthVault, please keep providing us with precious feedback! Posted Sunday, November 04, 2007 1:51 PM from The Healthcare IT Blog | 0 Comments Filed under: Standards, HL7, HealthVault, CCR

• Using Office Open XML in Health

  We have just published a whitepaper on the use of Office Open XML in Health at the address below: Using Office Open XML Formats to Support Electronic Health Records Portability and Health Industry Standards Abstract: Empowering patients and consumers to exchange Electronic Health Records securely is a big debate in the health industry across the globe. Learn how to use Office Open XML Formats and custom XML formats to exchange data securely. This particular scenario shows the use of Health Level Seven (HL7) Clinical Document Architecture (CDA) to represent the Electronic Health Record in an industry standard format. It also shows how to include the data in a secured document, based on Office Open XML Formats, for portability across multiple care providers. The paper comes with sample code that is very easy to install and test with minimal requirements on the machine to help illustrate the concept outlined in the whitepaper. I also want to point out an entry on Oliver Bell's blog about a similar topic. Posted Tuesday, October 23, 2007 6:28 PM from The Healthcare IT Blog | 1 Comments Filed under: Standards, Security, HL7, PHR, Open XML

• MS-HUG TechForum - IHE XDS.b Reference Implementation

  We had a fairly well attended session and the objective of providing an overview of the Health Connection Engine (HCE) and IHE XDS.b reference implementations was achieved, although with the time we had I could not get into a lot of detail. We have talked about the HCE in the past so I'll try to focus on the IHE aspect in this post. Background on IHE and XDS Integrating the Healthcare Enterprise (IHE) is an organization operating in the Health Information and Communication Technology area. The main purpose of IHE is to create Interoperability Profiles that simplify integration scenarios in healthcare. The IHE profiles are grouped in Technical Frameworks that address the business scenarios and the transactions that are used to implement those scenarios. Most of the times IHE ends up profiling the use existing standards such as HL7, DICOM, Web Services and so on. The final product, the Integration Profile, tells implementers of IHE-compliant solutions how to use those standards to allow for better interoperability. IHE started working in the IT Infrastructure domain about 4 years ago and taking on challenges of how to do Patient Identity Cross-Referencing (PIX), Enterprise User Authentication (EUA), Patient Demographic Query (PDQ) and many other. Arguably one of the most successful IHE profiles is Cross-Enterprise Document Sharing or XDS. The profile focuses of the publication, storage and retrieval of documents for the purpose of exchange within a network of trusted participants (Affinity Domain). One of the issues that came up with XDS as the underlying standards evolved was to keep it updated to the current ones to allow for a simpler implementation and maintainability. For this purpose IHE decided to release a new version of the IHE XDS called XDS.b. I have been working with IHE since November of 2006 to release this new version of XDS and I am the author and editor of that Integration Profile. IHE XDS.b was released for trial implementation in August 2007 and will be tested at the 2008 IHE Connect-a-thon and demonstrated at the 2008 HIMSS Interoperability Showcase in Orlando, FL. If everything works out, IHE XDS.b will be released in June 2008 and integrated within the IHE IT Infrastructure Technical Framework. IHE XDS.b Integration Profile XDS.b was designed with a strong focus on interoperability and co-existence with XDS.a, minimizing where possible the changes that people implementing XDS.a had to go through if they decided to move to XDS.b For that reason, XDS.a and XDS.b can co-exist, although some level of translation needs to happen. XDS.b implements the same business scenario as XDS.a, only the technical implementation is different. On the implementation of the business scenario and the transactions we have a number of changes: All transactions reference ebXML Registry Information Model 3.0 All transactions require SOAP 1.2 Optionally support SOAP 1.1 All transactions require WS-Addressing All transactions have WSDL defined IHE ITI Technical Framework Volume 2, Appendix V: one WSDL per Actor per Integration Profile MTOM is required for attachments Document content is within the s:Body in an element of type xs:base64Binary for MTOM support IHE has dropped support for the not-widely-used "off-line" mode while we work on a a-synchronous web services paradigm. IHE also updated XDS.b to allow for both HL7v2 and HL7v3 Patient Identity Feeds. This option makes sense for environments where one of the HL7 messaging standards is prominent with respect to the other. More details on what's new in XDS.b compared to XDS.a is available on the deck posted on SkyDrive: For more information on how to get XPS to work on your machine, check my previous post. IHE XDS.b Reference Implementation Most of the available implementations of the IHE XDS.a (the current XDS profile) were built on the Java platform. We decided, based on the feedback from customers and partners, to work on a reference implementation for the new XDS.b profile on the Microsoft platform. As part of this process we will be taking this reference implementation to the 2008 IHE Connect-a-thon and test it for interoperability with other XDS.b implementations to make sure that the profile is implemented correctly. The reference implementation will then be released to the community as an open source project on Codeplex under the Microsoft Permissive License (MsPL). In our implementation we use Windows Communication Foundation (WCF) for the Web Services implementation (SOAP, WS-Addressing, MTOM) and SQL Server 2005 for the Registry and Repository. What you find on Codeplex today is work in progress and I will be updating the site shortly with some instructions on how to deploy and test the implementation. If you're interested in working with us on the implementation or just to provide some feedback feel free reach out to me. We really welcome your feedback and help on this. Posted Tuesday, August 21, 2007 5:43 PM from The Healthcare IT Blog | 0 Comments Filed under: Standards, Events, CHF, HL7, HCE, MS-HUG, IHE, WCF