There's so much the goes on at a standards meeting like this, some of which is relevant to the meeting itself, and a good portion of which is also related to other activities that the different groups are engaged with across the healthcare standards space.
Today's post is just a compilation of several bits of information that I've come across this week.
Two HIE's in Connecticut are using XDS. A friend of mine who is involved in Health Information Exchanges in Connecticut reported to me that two exchanges there, one in Western Connecticut (Danbury) and the other in Central Connecticut (Hartford) are using XDS and the HITSP C48 specifications. I'll be adding those to the Where in the World is XDS Map shortly once I get more details.
The QRPH workgroup is working on the development of the Public Health Case Reporting profile. This profile comes out of a workshop that several IHE members including myself participated in, as I reported here in the Making of an IHE Profile, and later in Part 2 on that same topic. The the profile proposal developed in that workshop resulted in active work on a new profile. They've run into what I call the "Clinical Decision Problem" in Healthcare IT. This particular problem is one I've encountered in several different interoperability scenarios, including Public Health Alerting (See HITSP T81), Chronic Care Coordination (see IHE Care Management Profile), Clinical Decision Support (See the IHE Request for Clinical Guidance Profile) and now in Public Health Case Reporting.
The problem is simply that we have a standards gap in the representation of decision making processes and guidelines for care. I think the right answer is to develop a structured document to represent a guideline that brings in aspects of HL7 Structured Document Architecture and Clinical Decision Support. However, currently scheduled work in HL7 in the Clinical Decision Support and Structured Documents workgroups are necessary antecedents to this project, so there may be some delays in bringing this about. We resolved the problem the same way that it has been solved in other situations, which is to make the description of the clinical decision support logic outside the scope of the profile. We simply ensure that one of the actors is responsible for making the clinical decision based on information that it obtains through one or more interoperable transactions, and responding with the appropriate result depending upon what decisions were made. In this particular example, we are thinking that it should be possible to determine whether a case report is required depending upon the content of a CCD-based clinical document, and if so, then returning a case report form that would generate the appropriate CDA based document to report on the case. This would occur using the IHE Request Form for Data Capture profile.
IHE PCC is developing it's first workflow profile. This is an interesting profile to work on (I'm the editor for it). Basically the profile is bringing together content from six different domains (PCC, PCD, LAB, RAD, ITI and QRPH), across 21 different profiles (XDS, PIX, PDQ, PAM, XD-LAB, LTW, SWF, SINR, APE, APS, APL, APHP, LDHP, LDS, MDS, NBS, NDS, PPVS, and MCH). It sounds very complex, I think the Perinatal Workflow does a great deal to simplify coordination of perinatal care.
Since a picture paints a thousand words (or in this case, 2083 as I've counted them), I'll provide just a brief overview of what we are considering.
One of the purposes of Workflow Profiles is to adopt a common approach to identifiers. For Perinatal Workflow, is there any thought being given to an Episode of Care identifier for the pregnancy and birth? In DICOM, we added such an Episode of Care ID to be able to link the various ultrasound studies that may be done within a pregnancy. The Perinatal Workflow would be an opportunity to profile the use of this ID to link all the clinical data accumulated.
ReplyDelete