Download 1 Proposed work item: Pathology and Laboratory

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?)