A Profile for Define-XML
As the CDISC XML Technologies team finalizes Define-XML v2.1
for internal review an old debate has re-surfaced: how much should the
Define-XML specification focus on the regulatory submissions use case versus
providing a more general specification that works for a broader set of use
cases. As a standard that provides metadata to describe tabular datasets,
Define-XML can be used to describe legacy datasets as well as datasets included
for submissions. Define-XML has also been used as a specification for datasets.
However, Define-XML became the most widely implemented ODM-XML based standard
due its role as a required element of regulatory submissions. The importance of
ensuring that Define-XML files included in a submission are complete and
accurate makes a compelling case for adding rules that specifically target this
use case at the risk of reducing its usefulness in other contexts.
Having recently participated in the September HL7 FHIR connectathon
in Baltimore, MD it strikes me that the notion of profiling, as it is described
for FHIR resources, would provide a good solution for Define-XML. Profiling is
where the base resources are adapted for specific use cases. The FHIR
specification describes a growing set of base resources that can be used in
many different healthcare contexts making FHIR a “platform specification.” It
is expected that the platform specification will require adaptations in the
form of profiles to meet the needs of specific use cases. Profiles can be used
to both constrain and extend resources. They describe the rules that specify
which data fields are required vs. optional and which coding systems are used
in the stated context. Validators ensure that a specific resource instance
conforms to the profile.
Creating Define-XML as a “platform specification” useful
across a broad range of use cases, while also creating a regulatory submission
profile and implementation guide would seemingly be an ideal solution. As a
platform specification Define-XML can be effectively used across a range of use
cases. The definition of a regulatory submissions profile would permit the implementation
of a comprehensive set of rules effectively adapting Define-XML for use in
submissions without concern that these rules are limiting the usefulness of the
base standard.
HL7 FHIR profiling: http://www.hl7.org/fhir/profiling.html
Blog post from David Hay: https://fhirblog.com/2015/07/26/creating-and-using-fhir-profiles/
Interesting thoughts...
ReplyDeleteFHIR has always been concipated as an 80/20 solution, having a core set of resources that can be used worldwide and leaving the remaining 20% as "extensions" to account for local circumstances and conditions. For example, core-FHIR does not implement the concept of "race", as there is no worldwide consensus about what "race" exactly means and especially not which races there are.
This profiling has a long tradition within HL7. Even in HL7-v2, we have the so-called "Z-Segments" allowing for extensions that only have local validity, within a single hospital, organization, or country.
Essentially, Define-XML is already an extension and restriction (of ODM) at the same time. But we can surely think about how define-XML can be adapted in such a way that it can be also be used in the non-regulatory context. This can indeed be done by different implementation guides for different use cases, probably in combination with several Schematrons for easy and transparent validation.
HL7-CDA i.m.o. went too far in this. Essentially only a framework was delivered, forcing implementers of real use cases to write hundreds of pages of Implementation Guides. For example, the Austrian ELGA Laboratory Report Implementation Guide is 122 pages and builds upon the "general" Implementation Guide which is 226 pages. Also, the Schematrons that come with these implementations are very complicated.
Of course, Define-XML is much less complicated, and several implementation guides for several use cases with different schematrons are very well realizable.