Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
1 Proposed work item: Pathology and Laboratory Medicine (PALM) Structured Reporting (SR) Profile for Clinical Data Capture and Reporting across Multiple Domains Proposal editors: Raj C. Dash, MD, François Macary, Phast, and JD Nolen, MD, PhD, MSPH Version: 1.0 Date: April 6, 2016 Domain: PaLM 2 The Problem The anatomic pathology structured reporting (APSR) profile in its current incarnation provides a flexible model for capture of text based data but is inherently based on the traditional structure of a surgical pathology report and envisions capture of the information associated with the processing of only surgical tissues. Other use cases that include Cytology, Autopsy, Molecular Pathology, Flow Cytometry, etc. do not fit well into the model. The goal of this proposal is to facilitate more scalable content creation while ensuring robust data interchange across multiple use cases in the domain of pathology and laboratory medicine. The PALM-SR profile will provide the tools and framework but does not necessarily focus on content creation. Various adopters / vendors could create their own versions of structured reports covering a specific use case/domain. Multiple versions for the same domain might exist. All of these may look and behave completely differently with a different sequence of fields, different number of data fields, and different requirements and validation for each field. The PALM-SR would tie all of the versions together and unify data elements that are common across all those instances of structured reports built using various tools, but all conforming to the PALM-SR profile. There are many aspects to consider (e.g. language metadata, presentation metadata, coding systems, a national or international registry for data elements, etc). I believe this profile represents a natural evolution of the structured reporting framework beyond the use case of surgical pathology. Three specific requirements must be explicitly addressed by the profile. 1. Data element repository with the appropriate tags, metadata, context and vocabulary binding (which could be choices of appropriate vocabulary based on country) etc 2. Business rules / specific guidelines for specific use cases (at the domain / organization / country / regional level) on what elements need to be used 3. Data exchange format specifications 3 Key Use Cases Use case #1 – connecting an LIS to multiple downstream EHR systems The PALM-SR will facilitate interchange of data between a pathology laboratory information system (LIS) and other electronic health record (EHR) systems. These EHR systems may be hospital systems, physician office EHRs, or billing systems. Multiple transfers of data may occur over time for the same specimen or multiple specimens grouped into a “case” as incremental content is validated in the source system or as error corrections occur. Use case #2 – Uploading data to a central registry (e.g. LIS to Cancer Registry) The PALM-SR will facilitate interchange of data between a pathology laboratory and a central registry by representing data (e.g. expressing tumor characteristics) in an optimal manner for data interchange across systems. The profile should define those elements required to appropriately facilitate interchange of data but should not define the content itself. For example to facilitate interchange between an LIS and cancer registry, the presence of a field describing the type of tumor (e.g. tumor type: invasive ductal carcinoma) should not be defined by the profile. This type of content should be generated by the developers (or ideally the users) of source systems that implement the profile. The profile should define metadata important for data interchange to include inclusion of stylesheet elements, reference to a standard terminology (e.g. SNOMED CT), reference to a local or national common data element registry (e.g. caDSR), and profile-defined elements such as optionality, cardinality, visibility, mutual exclusivity, applicability of units of measure, applicability of reference ranges, whether the data field represents part of a calculation, etc. Many examples of source system derived content should be considered so that the metadata and representation capabilities of source system data are adequately defined. For a cancer registry use case, source system generated content would typically include organ and procedure specification, tumor type, tumor grade (which may be calculated from component scores), extent of involvement of a specified organ, nodal involvement, and spread beyond the organ of origin. For the tumor grading value set, a specific grading schema may be documented via constraints in the underlying content standard. The transfer of information may occur continuously or in batch mode at periodic times. In some cases newer data may override older data waiting to be transferred (e.g. multiple negative microbiology culture result reports). Such data distillation may occur prior to transmission to minimize the processing burden within the central registry. Use case #3 – Reviewing pathology history data for a patient cared across multiple facilities in a region The PALM-SR will facilitate interchange of data between systems for the purposes of patient care. Prior PALM result history is often critical to the interpretation of current testing. A PALMSR enabled system should be able to make a request of a form manager in another system for transfer of historical data for a single patient. This will facilitate aggregation of pathology and laboratory observations and results across multiple EHR and/or LIS systems for the care of a single patient. The identifying information for the patient must be known and security considerations addressed in order to fulfill the request but the mechanism for this interaction is out of scope for the PALM-SR profile. What is in scope for the PALM-SR profile is the possibility of tagging clinical data in such a way that it can be easily aggregated in this way for rapid review of historical review. For example, the diagnosis field may be the only section of interest to display in a historical summary view. The PALM-SR profile should define a mechanism for tagging data so that the relevant fields can be selected by developers (or end users) of information systems that implement the profile. Use case #4 – Collating specialized testing data across multiple laboratories within the same health system for the care of a single patient As our healthcare system evolves to leverage more sophisticated testing and provide more targeted care for disease specific conditions, the need for collating related test information becomes critical to provide precise and accurate diagnostic conclusions and therapeutic options. PALM-SR content should be able to be linked together in a precise manner to facilitate the construction of an integrated structured report. A simple example here is the relationship between a Pap smear report and the associated HPV DNA result. Only the integrated result set provides sufficient information for treatment of a patient but the testing process often occur asynchronously in different performing laboratories. Use case #5 – Aggregating data based on disease specific conditions (across many patients) The PALM-SR should provide a mechanism for normalizing data prior to storage when necessary to facilitate high performance data queries across large cohorts of patients. Data elements should be adequately described utilizing adequate metadata and data elements IDs appropriately assigned within a global registry of healthcare data elements (GROHDE). Proactive robust indexing of data in this fashion will facilitate rapid and accurate retrieval of relevant information across large cohorts of patients. Use case #6 - Representation of lab results in patient summaries Some of the observations produced by an anatomic or clinical pathology laboratory are relevant for the coordination and continuity of care, and therefore are candidate to be included in a patient summary. The scope of the PaLM domain includes specifying the structured representation of laboratory observation results for secondary use. Europe and the US want to align their respective templates of patient summaries in order to support the continuity of care across the Atlantic. To this end, the joint project “Trillium Bridge II” intends to define an extended international patient summary, which could contain laboratory results. A European citizen needs care provision while staying in the US, or vice versa. This care provision is to be secured by the query and retrieval by the care provider, of the patient summary available in the home country of the patient. This summary may contain laboratory observations relevant for the care delivery. Examples of such results are: ABO blood group, last known INR for a patient under anticoagulation therapy, viral serologies (HIV, HCV, etc), last HbA1c for a diabetic person. Use case #7 – Representation of pathology reports using an open standard that facilitates data sharing and clinical decision support Current pathology report production, transport, and display suffers from tight coupling between the content and the style of pathology reports, which is at odds with growing structured documentation requirements (eCC checklists and beyond) and absent or unscalable decisionsupport interactions between anatomic pathology and the rest of lab (e.g. genomics). With the emergence of FHIR resources across the HIT provider base, the SMART app framework coupled with CDS hooks provides a robust, interoperable, and extensible solution to these challenges. One possible area of focus is on the presentation layer for anatomic pathology reports. Either via the Diagnostic Report resource or another resource TBD (say an Anatomic Case Resource that pulls all case data), a SMART app could present an anatomic pathology case to EMR clinicians with a required (pathologist-driven) format along with optional presentation modes (that may be clinician or clinical specialty driven). CDS hooks can drive clinical behavior to follow-on tests via other focused SMART apps such as those that might reflex appropriate molecular tests to confirm the diagnosis, establish prognosis, or guide therapy. 4 Standards and Systems This IHE profile speaks to a set of actors, transactions for data requests and responses (complete, partial, incremental or redacted) possibly under the umbrella of RDF form based transactions, and a mechanism for representing data elements in a predictable and expressive manner. This representation is accomplished through a templating mechanism that uses underlying standards (CDA, FHIR, SNOMED CT, LOINC) for content representation. The profile is designed to facilitate the creation (capture) of content by implementers of the profile in such a way that the data elements and the manner in which they are to be presented are appropriately communicated to a downstream system. The scope of the profile therefore is focused on those elements (metadata, constraints, etc.) required to ensure high fidelity exchange of laboratory and pathology related observations and results created by end users and laboratory instruments. Some content not in scope for the profile is described in the use cases to illustrate how the profile can appropriately accommodate data representation and interchange. The content in scope for the profile may include data as well as metadata insofar that it is required to facilitate high fidelity capture, persistence, normalization, exchange, and presentation of pathology and laboratory data across systems. The current CCDA patient summary specified for the Meaningful Use program in the US enables the inclusion of laboratory test results whereas the current patient summary defined by the EU for cross-border eHealth does not. The “Trillium Bridge II” project intends to specify an international patient summary including laboratory results, convertible into the US one. FHIR resources: HL7-backed approach to RESTful web services for healthcare IT. An example service, the diagnostic report is available at http://www.hl7.org/fhir/diagnosticreport.html SMART Apps: A lightweight web framework that allows for interoperable apps to be deployed across the HIT landscape (http://smarthealthit.org/) CDS Hooks: A "hook" type implementation of decision support leveraging modal (SMART app) and non-modal processes for interoperable clinical decision support (https://github.com/cdshooks/cds-hooks-wiki/wiki) 5 Discussion This project is an opportunity to re-affirm that PaLM is the natural group to define the representation of laboratory observation results for any project. This work item will rely on the base standards as usual in IHE, and therefore should have good coordination with HL7 Int, the Regenstrief Institute and IHTSDO. The SMART project (http://smarthealthit.org/an-app-platform-for-healthcare/about/) defines a health data layer that builds on the emerging FHIR (Fast Healthcare Interoperability Resource) API and resource definitions. FHIR provides a detailed set of “core” data models, but in order to support diverse requirements across varied regions and use cases, SMART applies a set of “profiles” that provide developers with expectations about the vocabularies that used to express medications, problems, labs, and other clinical data. Additionally, SMART standards outline a robust authorization model for apps based on the OAuth standard, providing a key component that enables innovation while keeping patients and providers in control of their data. Finally, through the SMART Genomics and SMART CDS Hooks efforts, the SMART project is taking the lead on defining the next generation of FHIR based standards for the clinical use of genomic data and the integration of clinical decision support into provider workflows. Also to be considered is the current Structured Data Capture (SDC) profile. This profile has reached relative maturity with implementation flavors existing in both HL7 v2 and HL7 FHIR. The profile was developed and continues to be focused on research, clinical trial data capture, and public health reporting. Discussion with key members developing that profile has indicated that there are opportunities for expansion of the SDC profile. Rather than inventing a new profile, it may be possible to leverage the existing SDC profile and APSR v2.0 technical framework to more quickly achieve the goals of this profile. The SDC profile boasts strong public & private community participation with over 280+ individuals participated in the Initiative Launch Webinar and approximately 200 Registered Community Members; 50+ regularly participate in weekly meetings. In addition to the NIH and AHRQ, strong federal partner engagement and participation exists with the FDA (CDER/CDHR), CMS (esMD), CDC, and SAMSHA. This proposal there recommends use of SDC as the initial framework for all IHE “structured data capture”, recognizing that augmentation is required for “reporting”. Existing work in the APSR and XD-LAB would remain as SDC v2.0 form templates. The profile could leverage DEX for a common metadata CDE registry and for ontology mapping (e.g. SCT coding). SDC would no longer represent just “structured data capture” but “structured data management” with some of the following goals and challenges: Goal: increase visibility and resources devoted to structured data profile development Goal: create a more complete profile to support vendor implementation of a more useful product Challenge: establishing buy-in Challenge: garnering resources for profile augmentation Challenge: ownership / scope and coordination (co-ownership of SDC between QRPH and IHE – PALM?)