tag:blogger.com,1999:blog-4384692836709903146.post6010576353780870415..comments2024-03-27T09:55:23.143-07:00Comments on Dispatch from the Digital Health Frontier: A Personal Reflection on Standards HarmonizationJohn Halamkahttp://www.blogger.com/profile/04550236129132159307noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4384692836709903146.post-32153912378339832792009-05-30T03:50:33.775-07:002009-05-30T03:50:33.775-07:00John,
Your summary is quite compelling as an over...John,<br /><br />Your summary is quite compelling as an overview. I have been following HL7, ASTM and the CCR,CCD,<br />CDA controversy since its inception. How is it possible that Google went with CCR instead of the<br />"HARMONIZED" CCD. Do they really believe that <br />CCR is a more "correct" use of XML?/<br /><br />Look forward to the Board Meeting on Monday<br />Chris Bickford MD La Jolla/Scrippshealthcbmd4uhttps://www.blogger.com/profile/16515064557864389100noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-8752761209162186112009-05-26T19:43:46.447-07:002009-05-26T19:43:46.447-07:00Perhaps, rather than just an agreed upon format, a...Perhaps, rather than just an agreed upon format, an agreed upon open source enterprise gateway would be the best path to follow. <br /><br />I am planning to download the code and software development kit(SDK)for the CONNECT Gateway which is now becoming available to the public. Three primary elements (described on the Connect Website) make up gateway:<br /><br />"The NHIN Gateway implements the core NHIN services enabling such functions as locating patients at other health organizations within the NHIN, requesting and receiving documents associated with the patient, and recording these transactions for subsequent auditing by patients and others. <br /><br />Other features include authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information. <br /><br />The Enterprise Service Component (ESC) provides default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log and others. <br /><br />Agencies are free to adopt the default enterprise component implementations packaged in the CONNECT ESC or to plug in existing agency implementations of these service components. This component also includes a software development kit (SDK) for developing adapters to plug in existing systems such as electronic health record solutions to turn on information flows to support the secure exchange of health information across the NHIN. This makes CONNECT a platform for participation in health information exchanges. <br /><br />The Universal Client Framework enables agencies to develop end-user applications using the enterprise service components in the ESC. This makes CONNECT a platform for innovation."<br /><br />A hands on CONNECT Seminar is going to be held in Washington, D.C. on June 29th and 30. I hope that a Webcast will be made available for interested persons, like myself, who are unable to attend in person.e-Older Americanhttps://www.blogger.com/profile/02094737800828202693noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-33632173197030109522009-05-26T13:40:46.499-07:002009-05-26T13:40:46.499-07:00John,
Thanks for your leadership in this area. Br...John,<br /><br />Thanks for your leadership in this area. Bringing real-world applications and HITSP leadership to the HIT Standards Committee will be very helpful.<br /><br />The information you shared provides useful context about where the process and the data are leading us. I thought I might add a perspective or two to your comments around Common Data Transport. <br /><br />My company VisionShare supplies connectivity solutions to over 3000 hospitals, 2000 clinics and a host of other entities (long term care, home hospice, billing services, etc.). We have our secure connectivity solutions in more than 9000 locations across the US. They are connected mainly via an HTTPS solution secured by server and client side X.509 certificates. These solutions have also been approved for use in Medicare applications.<br /><br />We have anticipated a national standard for some time now. We were also a member of the CORE Phase II Connectivity Subgroup and participated in those recommendations. CORE Phase II resulted in the specification of two connectivity technology standards: "SOAP+WSDL" and "HTTP MIME Multipart" (i.e., multipart/form-data). <br /><br />At VisionShare we have used a multipart/form-data approach to quickly and cleanly integrate with several trading partners. We've used SOAP in a few instances, but in general have found that integration partners prefer the perceived simplicity of the multipart/form-data approach. We also opened up our network through an X.509 client-cert authenticated REST-based API and have found that, with good detailed technical documentation, integration partners are often able to integrate with no issues or questions (from a large variety of platforms). <br /> <br />While SOAP and WS-* standards have their place (and are heavily favored in the NHIN specs), our experience is that there is a complexity tradeoff that occurs when choosing SOAP and WS-*. In production, virtually 100% of our integration partners have enough in-house knowledge of HTTP(S) and XML to easily comprehend and quickly utilize a REST API. SOAP and WS-* do not seem to share such widespread understanding.<br /><br />We believe that while picking a scalable standard is very important, there will be a very busy body of work for some time, deploying protocol converters, and solutions that allow the integration of new standards with legacy systems.<br /><br />Most importantly we’ve learned that security need not be the enemy of scalability. <br /><br />Best regards,<br />John <br /><br />John Feikema | President & CEO | john.feikema@visionshareinc.comJohnhttps://www.blogger.com/profile/02788460697608169179noreply@blogger.comtag:blogger.com,1999:blog-4384692836709903146.post-35645624036665719422009-05-26T05:41:03.095-07:002009-05-26T05:41:03.095-07:00Its questions like this that make technologies lik...Its questions like this that make technologies like Enterprise Service Buses interesting to me (having just implemented one to bring systems together that don't WANT to speak to each other). <br /><br />I mean, I love standards. I wish more organizations agreed on things and made our lives easier. But that's not the reality I (currently) live in. So I've used Enterprise Service Bus technology to help out.<br /><br />The idea is this: System A and System B both input and output structured data. They both have APIs. They speak in different ways. You CAN write a mapping and messaging layer, but an ESB is like a pre-written map. It sits in the middle and accepts IO in hundreds of different forms. You still have to map the IO, but usually its a simple GUI interface to do so. After implementation, it doesn't matter if the system speaks JSON or SOAP or has its own XML... it just has to be structured. It also means that, combined with a BPM, you can wrap business rules around it.<br /><br />Still, life would be easier if we all used an agreed upon format. But in case we can't, ESBs and other easy-mapping technologies will exist.Bernzhttps://www.blogger.com/profile/16451988884915833897noreply@blogger.com