IHE Cardiology Retrieve Parseable InformationYear 2 (formerly known as “Registry Data”) Jan 10, 2005 Rev 0.1

IHE Cardiology Page 2 Retrieve Parseable Information: Problem Statement The initial Profile Proposal discusses the need to gather data from a variety of information sources. This functionality has broad application in clinical systems, and is not restricted to data registries. In Year 1, Cardiology extended the IT Infrastructure RID profile to provide parseable information in the initial response (list of studies). By taking the next logical step, RID could be extended so that the final response is also parseable. This would provide all of the capability needed for an actor to request and gather information needed for clinical documentation, data registries, and other related activities.

IHE Cardiology Page 3 Actors Similar to the “Display” actor in “Retrieve ECG for Display” in current Cardiology TF 1:5.1 Similar to the “Information Source” actor in “Retrieve ECG for Display” in current Cardiology TF 1:5.1

IHE Cardiology Page 4 Transactions Derived from Retrieve ECG List [CARD-5] in Cardiology-TF 2:4.5 XML, LOINC, ?? Others?? May be desirable to have options such as “just the latest” or “all”. Extends (but is somewhat analogous to) Retrieve ECG Document for Display [CARD-6] in Cardiology-TF 2:4.6 XML The Information Source should just return the data points that meet the request; it is up to the receiving system (Information Integrator) to decide how to handle the results.

IHE Cardiology Page 5 Request Information for Parsing: Scenario A clinical documentation system (Information Integrator Actor) is collecting information related to a cardiac catheterization encounter. The data will be included in the cath report, as well as in the data set subsequently submitted to the ACC-NCDR®. Information about serum creatinine is requested from a laboratory information system (Information Source). A list of time-stamped values is returned. The clinical documentation system selects the specific lab result most appropriate to its application and: Sets the value in the cath report Derives the values of ACC-NCDR data elements 439 (creatinine determined on admission) and 440 (Last Creatinine).

IHE Cardiology Page 6 In Scope / Out of Scope One major limitation in this approach is the existence and use of suitable data dictionaries that describe information of interest. Suitable “pre-coordinated” terms should be used where they exist. FeatureIn/Out Specification of information (such as lab tests) for which clear data dictionaries exist In Extension of data dictionaries to describe additional (pre-coordinated) terms Out Creation and maintenance of templates of informationOut

IHE Cardiology Page 7 Phased Approach Begin with individual pieces of information in Year 2, using existing data dictionaries with suitable pre- coordinated terms Consider extending this to use “panels” or “templates” for future years Consider methods of fully specifying requests using several terms (example, “serum level” plus “xyz” if there is no standardized pre-coordinated term for “serum xyz level”

IHE Cardiology Page 8 Open Issues Should it be possible (and is it necessary) to do a “broadcast” to discover Information Sources? Do requests for information need to be targeted for a single information source, or can they be broadcast? How can we create a “template” (a set of information that is needed), rather than requiring a long list of individual transactions? This may be impractical to maintain. Need to respect technical limitations in the length of a URL string used in a query. Is the RID transaction model the best to use as a base?