Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Information Architecture (EIA)

I strongly believe VistA modernization must first-and-foremost focus on the requirements-specifications of the DOD-VA iEHR Platform’s Virtual Patient Record (VPR) information model, which supports the user experience GUI, clinical decision support (CDS), evidence-based medicine (EBM) and information exchanges across the DOD and VA; where, the VPR must have appropriate context, privacy and security meta-data tagging, as presented in the 2010 PCAST report; and, the VPR must support semantic web technologies, and the Resource Description Framework (RDF) format in particular.

2013 has a focus on the Data Interoperability Accelerators (DIA) efforts; where, there are seven data domains that are initially targeted for delivery in December 2013 and which directly support 2014 iEHR Informatics Integration and Interoperability Platform (i3P). These were determined to be both the most important data domains clinically, as well as the most important to provide terminology normalization in national standards – for purposes of improved clinical displays and clinical decision support capabilities. These seven domains are:

  1. Medications
  2. Allergies
  3. Lab Results
  4. Documents/Notes (encounter/visit notes, discharge summaries, operative reports, etc.)
  5. Immunizations
  6. Problem Lists
  7. Vital Signs

These seven domains are also included in the required data for transitions of care designated by the Office of the National Coordinator for Health IT (ONC) and the Department of Health and Human Services (DHHS) in their regulations for Meaningful Use Stage 2 (MU2), 2014 Certified Electronic Health Record Technology (CERT). Additionally, MU2 regulations require:

  • Demographics, including
    • identifying and contact information, plus
    • race, gender, ethnicity, preferred language
  • Encounter Diagnoses (inpatient and outpatient)
  • Social History (in particular, Smoking Status)

Further, MU2 regulations require that this health information be exchanged using the HL7 Consolidated Clinical Document Architecture (C-CDA) Implementation Guides for the Continuity of Care Document (CCD); where, C-CDA is being addressed by the VLER project.

2016 Final Operating Capability (FOC) Phase has an emphasis on flushing out the iEHR data domains and/or capabilities; additionally, it must support all the high-value data domains that are MU2 optional parts of the CCD, to include:

  • Procedures
  • Providers (including Provider Type)
  • Payers
  • Plans of Care
  • Family History
  • Advance Directives
  • Functional Status

It should be noted that the DoD and VA have worked directly with the ONC and the various standards development organizations to define these data elements and standards. Consequently, there are very few additional high-priority data domains beyond these Transitions Of Care-oriented national standards, noted above.

Further and reflecting this consistency of requirements, all of these data domains (save Functional Status and Advance Directives) are being shared in one or more of the current data sharing mechanisms (FHIE, BHIE, CHDR, VLER), and are planned to be added into the new DIA data services.

One major addition, however, to the above data domains is medical imaging. While it is perhaps less pressing in routine cases, the actual images taken earlier in the case of a severely wounded warrior/patient, for example, can be critical to proper transition and subsequent care. While network connectivity and bandwidth constraints, for example, have prevented many organizations from sharing medical imaging, the DoD and VA have made important strides in sharing medical images between the departments. Another potential addition is Veterans Benefits adjudication data; where timely adjudications might be facilitated by some additional, yet-to-be-specified data domains and elements.

In conclusion, the subset of the data that is considered “must share” includes:

  1. Identity information and other demographics
  2. Medications
  3. Allergies
  4. Lab Results
  5. Documents/Notes (encounter/visit notes, discharge summaries, operative reports, etc.)
  6. Immunizations
  7. Problem Lists
  8. Vital Signs
  9. Procedures
  10. Social History
  11. Encounter Diagnoses (inpatient and outpatient)
  12. Medical Imaging

Your thoughts?

Note: This is a repost of an earlier post directed to a wider audience

like0

Comments

VPR - EBM enablement

Srinidhi Boray's picture

Absolutely, it is a great idea to get better understanding of the requirements, especially the vision of the VA - DoD interoperability including the mission outcomes to be reached. There is similar activity just started looking at EU - US Healthcare Interoperability. Link to site below. Challenges dealt wll be similar to VA and DoD inetegration and interoperability. 

Standards and Interoperability Framework (EU - US Efforts)

http://wiki.siframework.org/Interoperability+of+EHR+Work+Group

At this point of time Dr. Barry Robson's paper on interoperability who was part of the PCAST efforts is accepted as one of the reference material. VPR, just by additional data integration etc will not turn into EBM. It requires development of a completely new capability that needs to be developed by algorithminc architecture schemes such as probabilistic inference. And, when working with large sets of structured and unsturured data developing inferenced knowledge sets involves machine learning and such techniques before data mining is applied to millions of records. 

Following links provide better understanding on the ideas being proposed 

 

A Universal Exchange Language for Healthcare 

http://quantalsemantics.com/documents/MedInfo13-RobsonCaruso_V6.pdf

Discussion on Architecture as an ecosystem response that can turn VPR (iEHR) into EBM and more - The QEXL Approach

http://ingine.wordpress.com/2013/08/16/the-qexl-approach-universal-healthcare-interoperability-based-on-probabilistic-ontology/

Discussion on theory that develops the algorithm driven by Universal Exchange Language - Q-UEL

http://ingine.wordpress.com/2013/08/22/quantitative-semantic-algebra-by-dr-barry-robson/

Dr. Barry Robson's paper referenced on S&I Framework

http://wiki.siframework.org/file/detail/CIBMRobson86.pdf

 

like0

VPR-EBM enablement, interoperability, and scope of medical data

Barry Robson's picture

I believe that we really need to think at least  10  years ahead, and obviously certainly 5.  The list “Identity information and other demographics” etc.  is a rather restricted list. Back in 2004, our original GMS/ClaMS messaging system

http://www.ncbi.nlm.nih.gov/pubmed/15473681; http://xml.coverpages.org/Robson-GMSL200410.pdf

 that was popular with the OASIS/XML community  http://xml.coverpages.org/ni2004-10-11-a.html .  It was a messaging system that shipped and integrated the action of a variety of EHR  formats including HL7 pipe/hat and XML CDA records, DICOM medical  images,  DNA, genomic and proteomic information,  and immunological data including principal epitopes of  pathogens and vaccines etc. to which the patient was exposed, as well as applications to use all these,  and http://www.ncbi.nlm.nih.gov/pubmed/15822903  extended that to its own rich set of medical data categories.  

The Q-UEL that Srinidhi refers to was in some part to overcome GMS/ClaMS  restrictions that the records in standards that it carried were still the legacy form of the records. This restricted scalable “Big Data” mining of them, which needs crisp event-attribute-value constructs, and the degree of  granularity required for PCAST disaggregation and fine grained consent and authority mechanisms. Q-UEL or not,  “Big Data” mining is required to discover new associations and correlations but importantly to generate EBM and Clinical Decision Support Rules, as well as for epidemiological alerts and secure trace-back. We ultimately do need to think in terms of the order of a billion EHRs across the US and Europe.  Add to that that a Q-UEL  design feature was that the artifact tags are readable (when decrypted) by a physician by email and phone text  if the IT infrastructure is impaired. We learned the potential need this for GMS at IBM  in NYC on 9/11, but GMS required a step to render the legacy records  readable, and any step is vulnerable in a large scale disaster.

VistA  doesn’t really directly meet many of  these requirements,  in my opinion, so it certainly needs to liaise with a universal second language. But it will still have to be able to describe a broad set of clinical data in order to communicate all that may be needed.

like0

W3C Linked Data Standard: The UEL of Healthcare

Rafael Richards MD, MS's picture

Excellent topic. 

Although DOD prefers to think in terms of acquisitions of static products, or creating large  (static) requirements, Gartner's 2007 report says   "CDOs must recognize that CPR systems are not static products, but must continually evolve and improve. CDO executives must realize that implementation will be an ongoing and evolving process as CPR systems develop through multiple generations — from simple results reporting tools to complex, fully integrated systems that support the full range of care delivery services."

I  therefore agree  with your assessment that the way forward to manage the  (above) multitude of constantly changing models in healthcare is to use a model-flexible, schema agnostic approach, and use web-scale web-standard technology.   This metadata tagged approach is what the PCAST reqport recommended.

This approach is well described in OSEHRA's  RFI response for the  VA-DoD MEDCIS  "go to"  cloud based platform based on RDF. 

http://vista.caregraf.info/papers/VistACloudEHRS.html

An overview of healthcare data as Linked Data is also here:

http://vista.caregraf.info/papers/HealthDataIsLinkedData.html

SInce the submission of the MEDCIS response, work has been started  by Harvard and the W3C Semantic Web  Healthcare and Lifesciences Group to convert known MU models such as CCDA to RDF. 

http://smartplatforms.org/2013/07/introducing-the-smart-c-cda-collaborative/

VistA also is RDF-enabled, thanks to the open source community (WorldVistA).  VistA can store and publish RDF natively as a core function written in MUMPS.  Note the Harvard SMART project listing  WorldVistA,  the MU-Certified, Open-source,  SMART-enabled EHR.

http://smartplatforms.org/smart-enabled-hit/

As you mentioned, exposing and projecting the VPR model  and other  to RDF  would  put all of these models (VistA, CCDA, VPR, etc.)  and data into one, single 'data space'.  Technically, this is straightforward, as there are hundreds of tools for converting RDBMS  and other data sources to RDF.

http://www.mkbergman.com/sweet-tools-simple-list/

With Linked Data, the schemas become irrelevant,  the semantics are surfaced,  and we  have systems speaking the same language.  We also have extensive tooling (above) to manage the semantics and ontologies.  Every data element from any system is uniquely identified (URL), queryable (SPARQL), and available using modern, secure, web protocols (VPN, SSL, HTTPS, etc.).    Will we run out of URL space for this kind of web-based data storage approach?

With IPv6 at 128 bits, or about 3.4×1038 addresses, I don't think so.

Cheers

Rafael

 

Non-healthcare use of Linked Data:

UK Government:  http://data.gov.uk/linked-data

US Government: http://data-gov.tw.rpi.edu/wiki

Google: Knowledge Graph:  http://en.wikipedia.org/wiki/Knowledge_Graph

BBC: http://www.bbc.co.uk/blogs/bbcinternet/2012/04/sports_dynamic_semantic.html

Oracle: http://www.oracle.com/technetwork/database-options/spatialandgraph/overview/rdfsemantic-graph-1902016.html

 

 

 

 

 

 

like0

Yes, Semantic Web technology is the way forward....

Tom Munnecke's picture

I really think that the RDF/OWL Semantic Web/Linked Data approach is the best way forward towards the interoperability issues we are facing.  The PCAST report advocates a data-centric model with tagged metadata, and the development separate language for universal exchange.

As Steve pointed out in a previous OSEHRA thread:  DoD DCMO Mandates BPMN to RDF and OWL Semantic Technologies: See a Business Perspective YouTube Video at http://www.youtube.com/watch?v=pkhj2sTPlbk  See a Technical Perspective YouTube Video at http://www.youtube.com/watch?feature=player_embedded&v=OzW3Gc_yA9A#t=0s ,where the DoD DCMO mandate for Semantic Web technologies is discussed

And as Raphael pointed out, the VistA and CHCS data dictionaries are already very similar to RDF technology, as prototyped in Conor''s Semantic VistA work http://semantichealthcare.net

I held a workshop last June on "RDF as a Universal Health Language" with former Navy SG Adm Harold Koenig, Kaiser Permanente CMIO John Mattison, Google dir of research Peter Norvig, Sci Fi author Vernor Vinge, and others: See videos of the talks at http://www.youtube.com/playlist?list=PLt-A972QBADVyxzo9yhgz87R9QVrWUkrb

I also attended a workshop in San Francisco on the same topic: here are the presentations: http://www.youtube.com/playlist?list=PLt-A972QBADUZZK9tIzNhDSPb6gv-Uvog  David Booth's presenation is probably the best introduction to the topic.

I also held a workshop at the W3C's offices at MIT: http://www.new-health-project.net/2013/04/23/report-on-semantic-health-workshop-at-mit-april-19-20-2013/

I've come to the conclusion that we are at a tipping point to make a radical shift in our health IT thinking - and Semantic technology is going to be the trigger.  It offers a simpler, cleaner, more regular approach to the complexities of communicating health information.

An analogy might be to imagine the public library before the web and Google.  Books were stacked in linear sequence on shelves, coded by a predefined coordinate system (Dewey Decimal, for example), and indexed by a card catalog.  Books were exchanged through inter library loans.  Expanding the capacity of the library meant a bigger building, parking lots, staff, and utility bills.

The web and Google turned this all upside down.  URLs were just a chaotic mess of identifiers, there was no "Dewey Decimal" system to the web.  Google gave us a single search bar that could find things through context, not predefined structures.  Information was exchanged via linkage, not "exchanges."  The more people used Google, the smarter it got, attracting more people.  Google (probably) uses latent semantic indexing, detecting the semantics of the information based on the basis of the information it ingests, using perhaps millions of dimensions, rather than a single "Dewey Decimal" dimensional approach.

Bumping up to a "meta" level of thinking about health information is the way out of the complexity catastrophe we are facing.

like0

Yes, Semantic Web technology is EXACTLY the way forward....

Barry Robson's picture

I could not agree more. This is precisely the position we have taken, and have been coding for, ever since the call of the President's Council of Advisors in Science and Technology call in 2010 for "an XML-like Universal Exchange Language for healthcare". This is what the document that Srinidhi refers to, i.e. the document placed as first opening  reference to the problem in the Standards and Interoperability EU-US initiative to link medical information across Europe and the USA:

“Suggestions for a Web Based Universal Exchange and Inference Language for Medicine”.

http://wiki.siframework.org/file/view/UELRobson102corrections.pdf/451304614/UELRobson102corrections.pdf

The huge caveat is that EBM metrics and the artifact input to clinical decision support systems must be inherently probabilistic statements, because like much of life, medicine is filled with uncertainty, while the Semantic Web is primarily not probabilistic. Where it is, it does not carry all the required probability information. Nonetheless we need to combine the measures derived by data mining from many clinical records, as probabilistic summary statements of knowledge, with both more-or less certain and less certain medical knowledge which will be on the Semantic Web. The elegant solution, though, is an XML extension that embraces OWL and RDF representation on a more readable and more mathematically formal basis. All these aspects are analyzed discussed extensively in the above document (it is a preprint of the paper to be published by the long-standing journal Computers in Biology and Medicine and appears on the S&I reference materials by permission of the Chief Editor).

like0

VPR - needs higher order of ontology representing Knowledge

Srinidhi Boray's picture

To all the valuable architectural points made especially in the direction of semantics would like to draw attention to following few points and extend the discussion into additional much desired requirements, that extends the interoperability into systemic capabilities, such as EBM.

 

1. DoD EA and semantics! video is interesting. However, the semantics and ontology stops short at the data relationships established by semantic significance. It does not account for formation of knowledge sets, which occur by dynamic  coalescence  of the data continuously emerging from different systems. This also results into model of the phenomenon that is independent of the schema. This point was raised by Rafeal Richards. The coalescence formations keep developing on the characteristics of the discovered knowledge sets. This dynamic behavior generatively develops as more and more data gets processed. To make the semantics effective, combination of linguistic semantics and probabilistic inference is disccused, such that probabilistic inference working on techniques such as Bayesian and beyond - Dirac notations ( to overcome a cyclic formation of knowledge and also allow for bidirectional knowledge sets both from etymology to outcomes and in opposite direction).

2. To realize probilistic inference additional Universal Exchange and Inference language/ notations which is XML like is suggested (QUEL). From the investigation of the MUMPS, the way data structure exists, it appears that there is a close match with the structure adopted in the development of the universal language. This coincidence is probably owing to the way medical information emerges in the healthcare value chain and having its own peculiar information structure.

3. The developments of generative knowledge sets, requires knowledge stewardship and governance for its better curation. This means dealing with large pattern sets emerging for ever growing large VPR data size. To create knowledge sets by discernments, machine learning is recommended.

4. The algorithmic scheme achieved by the combination of probabilistic inference, linguistic semantics and machine learning, all together lead the curated knowledge sets into knowledge mining. All these work against the large uncertanity that inherently exists in the large data sets.

5. To account for the enterprise architecture view for VPR - a holistic architecture (QEXL) utilizing NoSQL and Hadoop sort infrastructure is proposed. The dominant feature of such an architecture that facilitates in the creation of the dynamic knowledge sets driven by probabilistic inference (algebra) can be characterized as probabilistic ontology. This ontology realized is certainly higher orders than that discussed by DoD EA semantics and ontology.

 

Thanks

Srinidhi Boray

like0

Dr. Barry Robson's response

Srinidhi Boray's picture

 

I could not agree more. This is precisely the position we have taken, and have been coding for, ever since the call of the President's Council of Advisors in Science and Technology call in 2010 for "an XML-like Universal Exchange Language for healthcare". This is what the document that Srinidhi refers to, i.e. the document placed as first opening  reference to the problem in the Standards and Interoperability EU-US initiative to link medical information across Europe and the USA:“Suggestions for a Web Based Universal Exchange and Inference Language for Medicine”.http://wiki.siframework.org/file/view/UELRobson102corrections.pdf/451304614/UELRobson102corrections.pdfThe huge caveat is that EBM metrics and the artifact input to clinical decision support systems must be inherently probabilistic statements, because like much of life, medicine is filled with uncertainty, while the Semantic Web is primarily not probabilistic. Where it is, it does not carry all the required probability information. Nonetheless we need to combine the measures derived by data mining from many clinical records, as probabilistic summary statements of knowledge, with both more-or less certain and less certain medical knowledge which will be on the Semantic Web. The elegant solution, though, is an XML extension that embraces OWL and RDF representation on a more readable and more mathematically formal basis. All these aspects are analyzed discussed extensively in the above document (it is a preprint of the paper to be published by the long-standing journal Computers in Biology and Medicine and appears on the S&I reference materials by permission of the Chief Editor). Posted for Dr. Barry Robson 
like0

Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Info

Srinidhi Boray's picture

 

 

Ignore...repost by mistake

like0

RDF is a data model; XML is a serialization format.

Rafael Richards MD, MS's picture

There is some discussion here with RDF and XML (or XML like structures)  as if they are in the same category. 

RDF and XML both attempt to address the problem of enabling different programs and different computers to communicate effectively with each other. In its own way, each takes an important step towards a universal lingua franca for data. This similar goal of creating a means for any system to communicate with any other is the basis for the confusion. 

However, there is much more to it than that.

A Serialization Format vs. a Data Model

There are, broadly speaking, two problems when parsing a file or data sent over a network. The first is simply being able to read the data in—to translate the series of bytes on disc into logical data. The second is to do something intelligent with that data, such as display it in on the screen. XML solves the first of those problems, and RDF solves the second of them.

This brings us to the major foundational difference between XML and RDF. XML is primarily a serialization format (we'll define this in a little more detail in a minute), while RDF is primarily a data model. From the beginning they are meant to serve two distinct purposes.

 

RDF vs. XML: An Analogy

Consider the book A Christmas Carol.  You can purchase it in paperback or in hardcover. You can purchase it as part of a Dickens collection or on its own. I read it by having chunks emailed to me every single day

, and you might read it on your Kindle or iPad.

Yet every one of those formats is still somehow the same book. The fact that it can be paper or electricity doesn't fundamentally change the book itself.

For example, let's say that I have two copies of A Christmas Carol: one in braille and one in regular print. Are they the same book?

From the point of view of RDF they absolutely are the same book. The book's meaning is what matters in RDF. The information represented by RDF retains its self-same meaning regardless of its underlying format. If you save RDF file in Turtle or RDF/XML

it's still the same information. Braille or print: it's the same book.

From the point of view of XML they are not the same book. A person who cannot read braille cannot consume one of the two. The representation format is what matters in the XML world.

In this analogy, RDF represents the informational content of the book; XML is a choice of delivery mechanism (Braille or print). Both parts matter, for sure, but they are two different things.

 

XML: Meant for Serialization

A serialization format is a way to encode information so that when it's passed between machines it can be parsed. In fact, the popularity of XML is due to its addressing the problem of too many file formats. For years, the first thing any programmer would do when creating a new program (for image editing, word processing, data storage…anything at all!) would be to create a way to save its data to disc.

The challenge was that any other program that wanted to read the file would have to special code for reading just that file in. Remember back before Word was the absolute dominant word processor? There were dozens of programs, and not all of them could read each other's files. Even different versions of Microsoft Word couldn't read each other's files!

Aside: Now, the technically astute know that XML itself has multiple serializations. Microsoft Word, for example, serializes XML in a binary format, whereas most XML is serialized as text. For our purposes we're ignoring this nuance since it doesn't affect the overall point.

RDF: A Data Model

RDF, in contrast, is a data model, which is an abstract set of rules for representing information. That, unfortunately, is not a great definition, so let's make it clearer by making some more analogies!

  • As in the book example, the serialization is they physical format of data, while the data model is the way to represent the book's inherent meaning.
  • The serialization is like the grammar of a language, while the data model is the informational content behind words.
  • The serialization is the word "green" spoken aloud in English, while the data model is a way to define the concept of "Green" such that it is unambiguous whether you say "Green" or "Verde" or think about the color of a leaf.

RDF is used to define objects and concepts and relationships between them, so hopefully this makes sense. If not, it might be worth reviewing these concepts (see links below): .

Simply put, in the RDF world, it doesn't matter how you send the data over the wire. Popular RDF serializations include:

  • Turtle
  • N3
  • RDFa (RDF embedded in HTML)
  • RDF/XML

See the last one? There is a way to represent RDF in XML! That is, if you have a parser that can read XML, it can read RDF/XML! There is no better proof that the two are not competing ideas than the existence of RDF/XML in the first place.

 

Comparing the XML Technology Stack to the Semantic Web Technology Stack

There is more to a data model than the model itself. How you interact with it (the query language) and how to describe it (the schema language) are incredibly important aspects in terms of practical usage.

The Semantic Web is a set of technologies for representing, storing, and querying data. XML too has a family of related technologies for representing, storing, and querying data.

We focused on RDF vs. XML since that is a specific topic that seems to come up very often. Other things worth looking into as nontrivial differences are SPARQL vs XQuery, and OWL vs  XML Schema.

To sum up:

  • XML is concerned with serialization
  • RDF is concerned with informational content

Thus the two technologies, though related, address two distinct problems. The existence of RDF/XML itself proves that they are not meant to compete.  XML is for document serialization.  It has no intrinsic data model; that model must be external.  RDF is for data atomic semantic data description, and has an *intrinsic* data model.   In other words,  RDF data is self-describing and self contained.  XML data is not, and must rely on some external data model.

While the PCAST report did mention XML or some other metadata tagging system,   what it  actually described, almost to the letter,  is RDF.

 

For a more detailed discussion go to these sites, which I have quoted above, see the linke below:

http://www.cambridgesemantics.com/semantic-university/rdf-vs-xml

http://www.cambridgesemantics.com/semantic-university/rdf-101

 

 

like0

RE: XML is a serialization format

Barry Robson's picture

>> “In fact, the popularity of XML is due to its addressing the problem of too many file formats. For years, the first thing any programmer would do when creating a new program (for image editing, word processing, data storage…anything at all!) would be to create a way to save its data to disc”

Apart from the small quibble  that one should perhaps say a" heirachy format", again, I couldn’t agree more. And the last thing we want is an XML-based Clinical Decision Support application reading the wrong XML and misinterpreting it as something relevant and wrong. Even XML developers thought it right that ‘-‘  should not be allowed in tag names in case an application thought that a subtraction was wanted. XML designers realized that they had no control over applications, good and bad, that could circulate and taken on trust. With a billion future EHRs across Europe and the US and many more cross-transactions, and trillions of statements of knowledge on the Semantic Web, silly mistakes will happen. Not often perhaps, but the patient whom it effects may see things at a different level of seriousness.

What is needed is an XML-extension that has a specific computational/algebraic meaning that applications should adhere to. XML itself, of course, imposes none such. I really don’t want to keep promoting Q-UEL per se: it is principles that are important. But the reason for public Q-UEL tags having the tag name starting <Q-UEL… is precisely because the ‘-‘ is illegal in XML tag names. As you note, OWL/RDF can be represented in XML, and there is nothing wrong with something looking XML-like as familiarity reduces developer errors. I nonetheless like the example of English and French:  we clearly see that one is not the other because there are words illegal or unidentifiable to a non-French English human listener, or a listener listening in English mode, that jam processing, although thanks to William the Conqueror a lot of words are almost the same…but not exactly with the same meaning. So thus I know when I am in told in French that my telephone is deranged, I recognize it is French and I do not conclude that my telephone is insane or possessed by the devil, and when my colleague tells me that he is desolate at missing the meeting, I know that he does not need counseling. These natural languages have their own laws, which speakers and listeners recognize.  In contrast, the laws of XML are just too darned slack. OK, we can have a specific embodiment of XML that applications needing it should recognize, but we still can’t control all developers, and pushing a “very specific embodiment” argument to the limit, it needn’t be exactly XML.  For our medical purposes, I think XML needs an overhaul anyway.

like0

Unifying Semantic Technologies and Clinical Systems

Barry Robson's picture

I may be a little out of date here and there is, for example, a lot of MUMPS code out there, and a lot of skunk works on that and related matters at varying levels of visibility. But my understanding of the ecosystem is this. The VA’s VistA HL7 still does not provide fluid and deep tools to map VistA EHR representation directly back and forth between HL7 pipe/hat (and indeed HL7 CDA) medical data representation. VistA and HL7 representations therefore coexist at relatively surface, parallel level. Blue Button, developed by the VA in collaboration with HHS and Defense, does empower patients by providing a simple method to view and transmit their health information. However, Peter Levin, the VA's chief technology officer, said that the Blue Button represented “a very thin thread and tenuous link to VistA”. Health Level Seven announced in January 2013 the release of a CCD to Blue Button transform Tool. The tool allows conversion of information already available in the existing HL7 CCD format into a Blue Button ASCII text format. However, CCD is a very US-orientated perspective as a constraint on HL7 CDA form, and not so translatable to the Standards and Interoperability EU-US international initiative.

 

In my view there are strong theoretical guidelines to what is needed. We need amongst another few things the general artifact form

<subject expression | relationship expression | object expression>

as a semantic triple form to which RDF/OWL is readily inter-converted, and the expressions are logical or other expressions for which the arguments are like XML attributes, but with an extended attribute metadata language such that these attributes  are in effect, MUMPS global variable data structure assignments. It would seem easy to automatically convert MUMPS source

set ^home(^captain(^ship("1ST FLEET", "BOSTON" ,"FLAG")))="PORTSMOUTH"

(a classical MUMPS example) to  be miscible with exchange artifacts with a MUMPS-like attribute structure. For example a Q-UEL artifact tag would be created on a global variable file as

set ^home(^captain(^ship("1ST FLEET", "BOSTON" ,"FLAG")))="<Q-UEL home:=captain:=ship:=(‘1ST FLEET’, BOSTON, FLAG) | is | PORTSMOUTH Q-UEL>"

I should of course therefore  justify my rather negative comment on VistA. The VistA implementation of MUMPS makes the counterparts almost unreadable not only to physicians if we lose part of the infrastructure in a disaster, but also hinders developers who do NOT typically “memorize the manual and never work from source examples”.  But software can still do much of the conversions.

 

Ideally, we also need the <..|..|…> to be usable as a constant or variable in an inference/reasoning program where it has a defined probabilistic meaning, and conversely to be calculable as an expression <vector| operator | vector> so that we can handle probability distributions of medical values on local strong determining factors like age = 0,1,2,3,4,… We also need these <..|..|…> structures to themselves be attributes in other <..|..|..> tags so that we can have semantic multiples as triples in context, parsed sentence structures, and inference networks.

My personal view is this. There is already a widely used scientific standard for expressing observations and measurements and drawing inference from them that handles all this, which is held to be universally applicable on all scales if you see the trick, and which has been used to enormous effect for decades.  What is off-putting PR for many folks is that Dirac worked out all the essential specs in his Dirac notation and Clifford-Dirac calculus for quantum mechanics and particle physics in the 1920s-1930s. The trick is to see that we aren’t necessarily interested in inference about waves and the weirdness that implies:  “The methods of theoretical physics should be applicable to all those branches of thought in which the essential features are expressible with numbers”. Paul A. M. Dirac, Nobel Prize Banquet Speech, 1933). Dirac was  almost certainly modestly referring to his extensions to physics  via his notation and algebra as further extensible to  a quantitative semantics of human language and thought, because repeatedly   he excluded poetry and  (more controversially) economics as subjective. Sadly, there is not much under the sun that is new.  Or happily, since doing the design for a universal exchange language that is based on a handful of fundamental unifying principles would otherwise seem a daunting task.

like0

Grateful for the link

Barry Robson's picture

I am grateful to a pointer to http://vista.caregraf.info/fmql to explore how one might express that FMQL approach in, and convert to, something like Q-UEL. I hadn’t previously set up any prescription process in exactly this particular FMQL-mapped way, and I did this quickly by hand following Q-UEL rules, recommendations, and preferences (in this case as a stand-alone tag attribute reflecting an event-attribute-value approach) so please forgive any errors, or misinterpretations of the source. In also add a very few more basic bits of information in the artifact that I would like to see in practice. Obviously there are several ways to achieve the same general results and still map to FMQL; much work to be done here. Note that since I groan a bit about raw record readability by humans, then to be fair I don’t like traditional  Latin/Greek medical abbreviations too much either, readability by developers, patients etc being a preferable design principle for me. That is not a fundamental data representation issue of course.

<Q-UEL-PRESCRIPTION:=‘order entry and results reporting’:= www.qexl.org/prescription_3/

patient:=‘Aiden Ataguy’:=www.qexl.org/US_Patient_Reg189958822/

and provider:=(center:=‘Outpatient Site FMQL Clinic’:= www.qexl.org/US_MedCenter_Reg8411/, (physician, prescriber):=’ James Kildare’ :=www.qexl.org/US_MD _Reg74356/)

and  Rx:=(simvastatin:=code:=(NDC:=000006-0749-54,   VA:=4010153) :=www.qexl.org/simvastatin/,   tablets(number):=90, tablet(mg):=40, ‘prescriber instruction’:= (literally:=‘Take one tablet by mouth every evening’, formally:=(tablets:=1  by:=mouth  with:=water(presumed)  ‘when (local patient time 24 hour clock)’:=18.00+/-6  ) ))

and Rx#:=‘800018 (Mar 5  09:11:03  2002  local)’   

and  fills:=(‘earliest possible’:= ‘Mar 5  09:11:03  2002  local ‘,  ‘next possible’:= ‘Apr 5 24:00:00 2002 local’, ‘last possible’:= ‘March 6 24:00:00 2003 local’)

and ‘patient status’:=code:=SC:=(‘not exempt from copayment’, ‘days supply’:=30 refills:=11, renewable):=www.qext.org/Verify_Status_US_Patient_Reg189958822_ US_MD _Reg74356_Rx#:=800018/

and order:=initiated

and ‘prescribing status’:=expired

and  ‘GMT minus local time(hours)’:=7 and zone:=constant

triggered:=www.qexl.org/ triggered_3/ |

dispensing:=(ordered:=10, ‘unit price($)’:=0.80, available,  delivery:=’window pickup’) and times:=(login:=’ Mar 5  13:50:17  2002  local’,  fill:= ‘Mar 5  13:51:02  2002  local’,  ‘last dispensed’:= ‘Mar 5  14:13:17  2002  local)’,  ‘label:= ‘Mar 5 13:50:27 2002 local’, release:= ‘Mar 5 13:50:42 2002 local’))

and  copies:=1

and counseling:=(given, understood)

and  (pharmacist,  enterer, printer, counselor):=’Nancy Devillers’:=www.qexl.org/ US_Pharmacist_ Reg101740/,

and  order:=converted

and  ‘dispensing status’:=expired

and ‘refill status’:=open

and ‘GMT minus local time(hours)’:=7 and zone:=constant

and tagtime:=‘Mar 5 20:50:43 2002 GMT’

Q-UEL-PRESCRIPTION>

like0

Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Info

Barry Robson's picture

Tom,

Many thanks for this. It may help greatly. MUMPS makes great sense to me but VistA, I'd like to love, but it is not so easy. There seems a link between VistA data thing to Dirac's known and perhaps lesser known manipulation rules, which has a mapping to operations in natural subject-verb-object languages anyway, so that should keep me entertained for a while anyway!

I completely agree on getting rid of incumbent thinking and going for a green field and rethinking basic principles. And reading the PCAST report, I get that sense out of it, too.

A Cambridge meeting would be great. I am on a working epidemiologist (and professor) stint down in the tropics right now, so that may be a blocker, but I may be able to get away for a couple of days, or make a leave for a special trip to the UK that dog-legs via MA if it were a bit later in the month.

I just got back from a UK meeting with Bob Coecke who runs the large (I think 40 people) quantum symbolics and language group at Oxford University's Computer Science Department, and Professor Peter Hines at the University of York, who did the application-to-ontology work while in Bob's group in relation to QM and natural language. Peter joined our QEXL universal exchange language research consortium this morning. These Oxford folks are involved with Google.

Point is, quantum theoretic semantics is not seen as such a weird field anymore (darn it). What I was doing, that they were not, is to use Clifford-Dirac algebra to put the probabilities in, whereas their system is larger in concept than standard Hilbert space, and has some good ideas. One of them is that while I am "bog standard" in having <A| relationship |B> (except perhaps for the generalized twistor concept that embeds them), they have <C|...|D>, <E|..F> etc around the same relationship but poking out in different dimensions at right angles to <A| relationship |B>.

Barry

-----Original Message-----
From: Tom Munnecke <munnecke@gmail.com>
To: Barry Robson <robsonb@aol.com>
Cc: VistA: VA Next-Gen Planning <vista-next-gen-planning@groups.osehra.org>
Sent: Fri, Sep 20, 2013 10:15 am
Subject: Re: [vista-next-gen-planning] Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Information Architecture (EIA)

I'm running for a plane, but would like to throw in a few points...

Barry, I suggest that, rather than looking at VistA from a hard-coded perspective (setting MUMPS variables), look at the semantics of the data dictionary (Conor's semantic VistA) http://vista.caregraf.info/ perhaps look at MUMPS as a virtual machine language, implementing the semantics of the data dictionary. I would also encourage looking at JSON (What Tim Berners-Lee calls "the next XML")... it is quite similar to the original VA Filegram protocols with which I had thought to integrate VistA and CHCS back in the old days.

Raphael, re: comprehending previous posts: I think we have a fundamental problem in today's medical informatics, and that is, we don't have the intellectual paraphernalia to deal with the complexity of the problems we are facing (or, alternatively, the tools that the industry is using are forcing a "Humpty Dumpty" approach that is impossible to integrate... it decomposes faster than we can compose solutions, which is great for the systems integration contractors trying to put Humpty back together again.

This is a very deep issue, and I think we need to do some "clean slate" thinking to figure it out. I don't think that it is going to be resolved by "encumbered" thinkers - who have a stake in preserving the present. Here's some workshop videos on a category theory perspective of medical informatics: http://www.youtube.com/watch?v=ofzMBKbNe2U and here are my comments for a "Project Clean Slate" http://www.youtube.com/watch?v=AdcplGqY7Rc

I think that is very appropriate that we reexamine our foundational thinking before "paving the cowpaths" of all the complexity of today's perversely incentivized system.

And this is about the third time this week that Paul Dirac's thinking has come up... which I have previously enjoyed, myself. LOTS of stuff to think about here. My preferred way of working through these issues is to hold small, conversational workshops, or salons, in a format I call "Slow Conversations."

I'll be in Cambridge, (Ma) in early December... and am thinking of holding a workshop about this kind of stuff... any interest? (I'll likely be doing others in a more climate-friendly San Diego, as well.) This is part of a series of workshops I'm developing for the New Health Project, which hopefully will get some funding to help make them happen.

On Fri, Sep 20, 2013 at 5:38 AM, Barry Robson <robsonb@aol.com> wrote:

>> “In fact, the popularity of XML is due to its addressing the problem of too many file formats. For years, the first thing any programmer would do when creating a new program (for image editing, word processing, data storage…anything at all!) would be to create a way to save its data to disc”
Apart from the small quibble that one should perhaps say a" heirachy format", again, I couldn’t agree more. And the last thing we want is an XML-based Clinical Decision Support application reading the wrong XML and misinterpreting it as something relevant and wrong. Even XML developers thought it right that ‘-‘ should not be allowed in tag names in case an application thought that a subtraction was wanted. XML designers realized that they had no control over applications, good and bad, that could circulate and taken on trust. With a billion future EHRs across Europe and the US and many more cross-transactions, and trillions of statements of knowledge on the Semantic Web, silly mistakes will happen. Not often perhaps, but the patient whom it effects may see things at a different level of seriousness.
What is needed is an XML-extension that has a specific computational/algebraic meaning that applications should adhere to. XML itself, of course, imposes none such. I really don’t want to keep promoting Q-UEL per se: it is principles that are important. But the reason for public Q-UEL tags having the tag name starting <Q-UEL… is precisely because the ‘-‘ is illegal in XML tag names. As you note, OWL/RDF can be represented in XML, and there is nothing wrong with something looking XML-like as familiarity reduces developer errors. I nonetheless like the example of English and French: we clearly see that one is not the other because there are words illegal or unidentifiable to a non-French English human listener, or a listener listening in English mode, that jam processing, although thanks to William the Conqueror a lot of words are almost the same…but not exactly with the same meaning. So thus I know when I am in told in French that my telephone is deranged, I recognize it is French and I do not conclude that my telephone is insane or possessed by the devil, and when my colleague tells me that he is desolate at missing the meeting, I know that he does not need counseling. These natural languages have their own laws, which speakers and listeners recognize. In contrast, the laws of XML are just too darned slack. OK, we can have a specific embodiment of XML that applications needing it should recognize, but we still can’t control all developers, and pushing a “very specific embodiment” argument to the limit, it needn’t be exactly XML. For our medical purposes, I think XML needs an overhaul anyway.

--
Full post: http://www.osehra.org/content/joint-dod-va-virtual-patient-record-vpr-ie...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3071

like0

Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Info

Barry Robson's picture

P.S. In the cirumstances I should emphasize that I am very enthusiatsic about preserving VistA, but to do so I think some deeply thought-out translators are required to bridge those gaps that I mentioned.

Barry

-----Original Message-----
From: Robsonb <robsonb@aol.com>
To: munnecke <munnecke@gmail.com>
Cc: vista-next-gen-planning <vista-next-gen-planning@groups.osehra.org>
Sent: Fri, Sep 20, 2013 11:46 am
Subject: Re: [vista-next-gen-planning] Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Information Architecture (EIA)

Tom,

Many thanks for this. It may help greatly. MUMPS makes great sense to me but VistA, I'd like to love, but it is not so easy. There seems a link between VistA data thing to Dirac's known and perhaps lesser known manipulation rules, which has a mapping to operations in natural subject-verb-object languages anyway, so that should keep me entertained for a while anyway!

I completely agree on getting rid of incumbent thinking and going for a green field and rethinking basic principles. And reading the PCAST report, I get that sense out of it, too.

A Cambridge meeting would be great. I am on a working epidemiologist (and professor) stint down in the tropics right now, so that may be a blocker, but I may be able to get away for a couple of days, or make a leave for a special trip to the UK that dog-legs via MA if it were a bit later in the month.

I just got back from a UK meeting with Bob Coecke who runs the large (I think 40 people) quantum symbolics and language group at Oxford University's Computer Science Department, and Professor Peter Hines at the University of York, who did the application-to-ontology work while in Bob's group in relation to QM and natural language. Peter joined our QEXL universal exchange language research consortium this morning. These Oxford folks are involved with Google.

Point is, quantum theoretic semantics is not seen as such a weird field anymore (darn it). What I was doing, that they were not, is to use Clifford-Dirac algebra to put the probabilities in, whereas their system is larger in concept than standard Hilbert space, and has some good ideas. One of them is that while I am "bog standard" in having <A| relationship |B> (except perhaps for the generalized twistor concept that embeds them), they have <C|...|D>, <E|..F> etc around the same relationship but poking out in different dimensions at right angles to <A| relationship |B>.

Barry

-----Original Message-----
From: Tom Munnecke <munnecke@gmail.com>
To: Barry Robson <robsonb@aol.com>
Cc: VistA: VA Next-Gen Planning <vista-next-gen-planning@groups.osehra.org>
Sent: Fri, Sep 20, 2013 10:15 am
Subject: Re: [vista-next-gen-planning] Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Information Architecture (EIA)

I'm running for a plane, but would like to throw in a few points...

Barry, I suggest that, rather than looking at VistA from a hard-coded perspective (setting MUMPS variables), look at the semantics of the data dictionary (Conor's semantic VistA) http://vista.caregraf.info/ perhaps look at MUMPS as a virtual machine language, implementing the semantics of the data dictionary. I would also encourage looking at JSON (What Tim Berners-Lee calls "the next XML")... it is quite similar to the original VA Filegram protocols with which I had thought to integrate VistA and CHCS back in the old days.

Raphael, re: comprehending previous posts: I think we have a fundamental problem in today's medical informatics, and that is, we don't have the intellectual paraphernalia to deal with the complexity of the problems we are facing (or, alternatively, the tools that the industry is using are forcing a "Humpty Dumpty" approach that is impossible to integrate... it decomposes faster than we can compose solutions, which is great for the systems integration contractors trying to put Humpty back together again.

This is a very deep issue, and I think we need to do some "clean slate" thinking to figure it out. I don't think that it is going to be resolved by "encumbered" thinkers - who have a stake in preserving the present. Here's some workshop videos on a category theory perspective of medical informatics: http://www.youtube.com/watch?v=ofzMBKbNe2U and here are my comments for a "Project Clean Slate" http://www.youtube.com/watch?v=AdcplGqY7Rc

I think that is very appropriate that we reexamine our foundational thinking before "paving the cowpaths" of all the complexity of today's perversely incentivized system.

And this is about the third time this week that Paul Dirac's thinking has come up... which I have previously enjoyed, myself. LOTS of stuff to think about here. My preferred way of working through these issues is to hold small, conversational workshops, or salons, in a format I call "Slow Conversations."

I'll be in Cambridge, (Ma) in early December... and am thinking of holding a workshop about this kind of stuff... any interest? (I'll likely be doing others in a more climate-friendly San Diego, as well.) This is part of a series of workshops I'm developing for the New Health Project, which hopefully will get some funding to help make them happen.

On Fri, Sep 20, 2013 at 5:38 AM, Barry Robson <robsonb@aol.com> wrote:

>> “In fact, the popularity of XML is due to its addressing the problem of too many file formats. For years, the first thing any programmer would do when creating a new program (for image editing, word processing, data storage…anything at all!) would be to create a way to save its data to disc”
Apart from the small quibble that one should perhaps say a" heirachy format", again, I couldn’t agree more. And the last thing we want is an XML-based Clinical Decision Support application reading the wrong XML and misinterpreting it as something relevant and wrong. Even XML developers thought it right that ‘-‘ should not be allowed in tag names in case an application thought that a subtraction was wanted. XML designers realized that they had no control over applications, good and bad, that could circulate and taken on trust. With a billion future EHRs across Europe and the US and many more cross-transactions, and trillions of statements of knowledge on the Semantic Web, silly mistakes will happen. Not often perhaps, but the patient whom it effects may see things at a different level of seriousness.
What is needed is an XML-extension that has a specific computational/algebraic meaning that applications should adhere to. XML itself, of course, imposes none such. I really don’t want to keep promoting Q-UEL per se: it is principles that are important. But the reason for public Q-UEL tags having the tag name starting <Q-UEL… is precisely because the ‘-‘ is illegal in XML tag names. As you note, OWL/RDF can be represented in XML, and there is nothing wrong with something looking XML-like as familiarity reduces developer errors. I nonetheless like the example of English and French: we clearly see that one is not the other because there are words illegal or unidentifiable to a non-French English human listener, or a listener listening in English mode, that jam processing, although thanks to William the Conqueror a lot of words are almost the same…but not exactly with the same meaning. So thus I know when I am in told in French that my telephone is deranged, I recognize it is French and I do not conclude that my telephone is insane or possessed by the devil, and when my colleague tells me that he is desolate at missing the meeting, I know that he does not need counseling. These natural languages have their own laws, which speakers and listeners recognize. In contrast, the laws of XML are just too darned slack. OK, we can have a specific embodiment of XML that applications needing it should recognize, but we still can’t control all developers, and pushing a “very specific embodiment” argument to the limit, it needn’t be exactly XML. For our medical purposes, I think XML needs an overhaul anyway.

--
Full post: http://www.osehra.org/content/joint-dod-va-virtual-patient-record-vpr-ie...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3071

like0

Re. Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise

Barry Robson's picture

Apologies that I hadn’t realized that responding to Tom’s emails was also a posting! Rest assured that we wish to preserve VistA and all the work put into it. That’s the name of the game here. My personal preference for working with a source that is trivially human readable (and of generating UEL artifacts that are so, for all the development and disaster scenario reasons stated) does not stop access at the very readable FMQL level, and I already sketched out on this page what a UEL artifact in an EAV (event-attribute-value) kind of representation might look like (done “warts and all”, as Cromwell said to his portrait painter). That’s as it is to my taste, at least.  That includes a preference for partitioning content perhaps more crisply into <event A| triggered | event B> constructs where possible and appropriate, not to mention <event A | triggers | event B actual values pending>.

In addition to that I have asked our team to look not only at that, but at JSON.  As stated in the manuscript at the S&I intuitive site that Srinidhi first mentioned, and linked, our UEL suggestions include going beyond SNOMED  etc. standard nomenclature and crisp ontologies, but apply with the same goals to everyday language, with the further befit of mapping out to non-English natural language in international artifacts.  As also shown in that manuscript, we also have more fundamental interests in how Dirac’s better and lesser known algebraic rules link to natural and artificial languages and data and knowledge representation.  As far as data and knowledge represntation and “dimensions of meaning” go there is a project QUELIC, but as a kind of “common speech SNOMED” we are working with Avner Levy’s continuing development of Kodaxil.  As Avner reports, Kodaxil's structure followed JSON / REST since day 2. JSON allows using words as plain text with minimal tagging { strings } and that's exactly what K does, is (plus contexts). Kodaxil can use JSON serializers - although Avner  wrote his own that as well as JSON can use K objects (quantity, identity, ratio, ...). He also notes that There are many tools to 'jasonify', which in JSON lingo is known as 'stringify'. That will all hopefully  become clearer to me as I investigate actual medical JSON source, but I can certainly already see that JSON, like MUMPS global (and local) variable data construct  expressions, is not only human-readable but can map directly to our suggestions via their extended attribute metadata language AML.

 I’d like to share some design features here.  One reason that AML can capture these slight or significant variants is because it can not only represent a tree graph of ontological structure pointing left or right, but also a general graph structure (with cyclic paths). We needed that early on for representing chemical molecules anyway!  (http://www.ncbi.nlm.nih.gov/pubmed/21538091 - but note here also our interest in our artifacts as interacting heterogeneous automata). Another reason for a broad AML is that attributes as innermost objects map to both use of our tags in an XML-like structured document manner and the nesting of tags as attributes within tags (the metastatement or in general so-called twistor structure, in analogy to physics’ use of their analogues of our tags as Dirac dual spinors). Esoteric stuff perhaps, but the design feature here importance is that it gives data representation closure from innermost to outermost, allowing breakout from points in the cycle to capture different data representations as well as our own.

Again, only suggestions for the community to maybe think about as far UELsof any kind are concerned; it is more directly the A.I. toolkit benefits that motivate tag design here, for inference and medical decision support.

 
like0

Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Info

Srinidhi Boray's picture

Want to add our interest piqued when Tom made an interesting assertion of creating roadmap for VistA transformation by the employ of algebra and importantly such an approach has potential to save Billions of dollars touted for the VistA transformation including achieving VA - DoD interoperability.

For Barry's reference - Letter from Tom that has created much discussion in the industry.
Open Letter to Chuck Hagel: DoD still doesn’t know what the hell they are doing

http://munnecke.com/blog/?p=1929

From above blog
<<<<<Similarly, we could build a health information space that that allowed this kind of sharing ( with enhanced patient privacy and security), as an intrinsic of being part of the common information space. This move to a higher level of abstraction is a bit like thinking of things in terms of algebra, instead of arithmetic. Algebra gives us computational abilities far beyond what we can do with arithmetic. Yet, those who are entrenched in grinding through arithmetic problems have a disdain for the abstract facilities of algebra. The DoD is rejecting the Uplift model, instead succumbing to the “Humpty Dumpty Syndrome” – breaking things into pieces, and then trying to integrate them again. >>>>

Thx…SB

On Sep 21, 2013, at 2:37 PM, Barry Robson <robsonb@aol.com> wrote:

> Apologies that I hadn’t realized that responding to Tom’s emails was also a posting! Rest assured that we wish to preserve VistA and all the work put into it. That’s the name of the game here. My personal preference for working with a source that is trivially human readable (and of generating UEL artifacts that are so, for all the development and disaster scenario reasons stated) does not stop access at the very readable FMQL level, and I already sketched out on this page what a UEL artifact in an EAV (event-attribute-value) kind of representation might look like (done “warts and all”, as Cromwell said to his portrait painter). That’s as it is to my taste, at least. That includes a preference for partitioning content perhaps more crisply into <event A| triggered | event B> constructs where possible and appropriate, not to mention <event A | triggers | event B actual values pending>.
>
> In addition to that I have asked our team to look not only at that, but at JSON. As stated in the manuscript at the S&I intuitive site that Srinidhi first mentioned, and linked, our UEL suggestions include going beyond SNOMED etc. standard nomenclature and crisp ontologies, but apply with the same goals to everyday language, with the further befit of mapping out to non-English natural language in international artifacts. As also shown in that manuscript, we also have more fundamental interests in how Dirac’s better and lesser known algebraic rules link to natural and artificial languages and data and knowledge representation. As far as data and knowledge represntation and “dimensions of meaning” go there is a project QUELIC, but as a kind of “common speech SNOMED” we are working with Avner Levy’s continuing development of Kodaxil. As Avner reports, Kodaxil's structure followed JSON / REST since day 2. JSON allows using words as plain text with minimal tagging { strings } and that's exactly what K does, is (plus contexts). Kodaxil can use JSON serializers - although Avner wrote his own that as well as JSON can use K objects (quantity, identity, ratio, ...). He also notes that There are many tools to 'jasonify', which in JSON lingo is known as 'stringify'. That will all hopefully become clearer to me as I investigate actual medical JSON source, but I can certainly already see that JSON, like MUMPS global (and local) variable data construct expressions, is not only human-readable but can map directly to our suggestions via their extended attribute metadata language AML.
>
> I’d like to share some design features here. One reason that AML can capture these slight or significant variants is because it can not only represent a tree graph of ontological structure pointing left or right, but also a general graph structure (with cyclic paths). We needed that early on for representing chemical molecules anyway! (http://www.ncbi.nlm.nih.gov/pubmed/21538091 - but note here also our interest in our artifacts as interacting heterogeneous automata). Another reason for a broad AML is that attributes as innermost objects map to both use of our tags in an XML-like structured document manner and the nesting of tags as attributes within tags (the metastatement or in general so-called twistor structure, in analogy to physics’ use of their analogues of our tags as Dirac dual spinors). Esoteric stuff perhaps, but the design feature here importance is that it gives data representation closure from innermost to outermost, allowing breakout from points in the cycle to capture different data representations as well as our own.
>
> Again, only suggestions for the community to maybe think about as far UELsof any kind are concerned; it is more directly the A.I. toolkit benefits that motivate tag design here, for inference and medical decision support.
>
>
> --
> Full post: http://www.osehra.org/content/joint-dod-va-virtual-patient-record-vpr-ie...
> Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
> Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3071

like0

Re. "Open Letter to Chuck Hagel"

Barry Robson's picture

Actually I think Tom's letter is one of the most powerful documents since the December 2010 PCAST report. They may not look the same, but they are two sides of the same golden coin.It is hard believe that the "patient ethos" has lost out to the "bureaucrat ethos" (and I am a US Citizen!!!).  I have some hopes also  in the S&I EU and US initiative. I doubt it was only for continuity of care of  US citizens travelling abroad (and vice versa) but also that it may uncover a truly UEL type of solution, and tap the ingenuity of the Europeans in sharing between different countries. I recall EU 1984 COM Final, the first formal and widespread  use of the word "bioinformatics",  an EU  grant soliciation in response to a memo from the White House to the EU that that Europe was falling behind the USA and Japan in biotechnology. But Europe was multisected by nations, hence  Hence bioinformatics and the "Laboratoires sans murs" strategy. I would not exactly say that the tables are turned, but, EU-US project is a great test bed "en principe". However, with folks like Tom speaking out, we have a chance to put our own house in order...and from within.

like0

Re. "Open Letter to Chuck Hagel"

Barry Robson's picture

Correction, I think the EU response was in 1980...pretty sure. Oddly,  Google is quiet on the matter. But the point remains. Bring down the walls.

like0

Getting VistA to write and read “Esperanto”

Barry Robson's picture

I understand that some of my collaborators and colleagues can read from VistA but so far I have focused on HL7-CDA-like sources  and how to get  them into a granular EAV form,  as Q-UEL as a universal second language (but of course it could be any kind of  IT version of Esperanto).  So I need to engage Q-UEL at a deeper level with VistA. So someone correct me if I’m wrong on the following.

To summarize so far, at least as far as get it , it is almost trivial to write in a UEL from VistA particularly thanks to FMQL. However, to go further than simply a reformatted copy, one needs  to reorganize VistA data  into the kinds of structures that that I think are needed by  diverse listening applications in the US and including in at least Europe, and especially by EBM and CDS systems.  They will look very like the example tag artifact I posted on prescription (if I get my way). But it does mean that that a “ghost rewriter” is required ofr VistA  for each domain. Stephen lists some 12 core domains, which clearly break down to subdomains,  but it is not the end of the world to write such a finite number of  converters.

The bigger challenge is of course to get Q-UEL information content, or some such UEL, expressed in VistA.  As far as I understand, we hear you VistA, but you don’t hear us so well. We can subscribe but not submit, at least not flexibly and deeply. Of course, I could write what anyone thinks at a glance is VistA, and I bet it would be legal VistA. So say we have to arm up, and go in.  Folks say it looks a bit like Hamburger Hill. It obviously requires a deep specialist knowledge and understanding to find anything, and it is hard for a developer to read it when you do. However, this kind of example snippet  below doesn’t indicate that this cynicism is entirely justified for VistA itself…

:

;GMRCSS=To Service   GMRCPROC=Procedure Request Type

 ;GMRCURG=Urgency     GMRCPL=Place Of Consultation

 ;GMRCATN=Attention   GMRCINO=Service is In/Out Patient

 ;GMRCPNM=Patient Name  GMRCDIAG=Provisional Diagnosis

 ;GMRCERDT=Earliest Appr. Date

 ;GMRCPROS=Prosthetics Service y/n

N GMRCSS,GMRCPROC,GMRCURG,GMRCPL,GMRCATN,GMRCINO,  GMRCDIAG,LN,GMRCRESP,GMRCERDT,GMRCPROS,IDX

 K ^TMP("GMRCR",$J,"ED") S GMRCLNO=1

 I $L($P(^GMR(123,+GMRCO,0),"^",12)) S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="  CURRENT STATUS: (Not Editable): "_$P(^ORD(100.01,$P(^(0),"^",12),0),"^",1),GMRCLNO=GMRCLNO+1

 S GMRCD=0 F  S GMRCD=$O(^GMR(123,+GMRCO,40,"B",GMRCD)) Q:'GMRCD  S GMRCDD="" F  S GMRCDD=$O(^GMR(123,GMRCO,40,"B",GMRCD,GMRCDD)) Q:'GMRCDD  D

 .I $P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",2)=19 S LN=0 D

 ..N GMRCPERS,GMRCTX

 ..I '$D(^GMR(123,+GMRCO,12)) D

 ...S GMRCPERS=+$P($G(^GMR(123,+GMRCO,40,GMRCDD,0)),"^",5)

:

..because at least  somewhere it tells you what GMRCSS etc mean. So I don’t think it is such a million miles away from my example of generating a Q-UEL data structure from MUMPS, and more importantly doing the reverse.  

I therefore  didn’t  quite understand the criticisms of VistA. That’s of course except mine on a human direct readability, but that is maybe just because I’m stupid  and couldn’t get past Green Book 2,  “Bob goes to the Beach” in primary school.  Therefore  the  real catch, I am guessing, is not VistA per se.  The real catch is that I presumably need to  write the VistA such that  established VistA apps could use what Q-UEL wrote. Otherwise, unless the apps are really smart, they would be looking in the wrong places and choking.  At first glance,  one way to see it  that we are given an excellent  FMQL File Manager  Query Language,  but  FileMan is essentially a frozen template for data entry.  It  does  not as far as I can see have an accepted have a generally applicable  FMSL File “Manager Submission Language”  to match VistA’s intrinsic scope and power.  We are fixed to FileMan developers’ view of the world.  But in the end,  an FMSL would also have to deliver what the apps can use.  It would not get rid of the app problem.  Therefore,  my guess is  that the problem never was VistA, but the apps.

To allow a future diversity of input and output apps for something that is a source code and addressed directly would  naturally trigger the notion that refactoring is needed.  By formal  definition, that  usually means generalize type, encapsulate fields, componentize, class- extract, humanize, and re-ontologize  (move data up and down between superclasses and subclasses). It also includes “polymorphasize”, i.e. apply polymorphism.  In some ways that’s the most embracing.  Basically of course it means a single algebraic and/or value interchange with between different types,  by using types whose operations can also be applied to values of another type.  

 

To my taste,  a good approach here was our  original  intended design feature in GLOBAL (Ball, J, et al. . "A Polymorphic Programming Environment for the Chemical Pharmaceutical and Biotechnology Industries", Chemical Information Systems - Beyond the Structure Diagrams. Eds. D. Bawden and E. M. Mitchell, Ellis Horwood Press, 1990, 107-123), and used in http://www.ncbi.nlm.nih.gov/pubmed/2099743.  The key feature I am thinking of here, however,   is very  simple to implement  in any code and probably  not so novel these days, describable as  “run time transformation step  outsourcing”.  It applies to new code and in the above studies that was an Expert System coded in GLOBAL, but it is also an “erode the code” strategy for preexisting code, because we can do the following for bits we wish to replace. Any difficult transform operation function or object is initially filled, or for code refactoring replaced by, an object that  invokes not code but a connection to a human expert. This person does the operation manually,  using his/her brain as the program required, and completes the gap in the workflow, but then he/she or his/her “knowledge engineer” writes code in a convenient high level meta-algorithm/protocol  language  to do the job automatically, and then that gets invoked automatically. Or semi-automatically – the means having sub-operations that also invoke a human expert, and so on.  If such code consistently “passes the Turing test” by an indistinguishable good result, ok. That approach is best for large teams. If I did VistA converters  myself, I am the available poor closest to domain expert and knowledge engineer, so I am tempted to  just hack out the direct code myself. But then maybe one day someone will complain that the converter needs refactoring, and probably it will be me 5% of the way through.

I know the above approach looks trivial and silly. I know it because in my six years at T. J. Watson as the Strategic Advisor to IBM Research and five years as CSO IBM Global Healthcare, Pharmaceutical, and Life Sciences, they listened to quite a few things I said, but developing systems by “run-time transformation step outsourcing” was never one of them. Well, IBM is a pretty big and complex place and I shouldn’t say that they were not doing it somewhere, so apologies to IBM for the groundless presumption. But the point is, either way,  that the standard reply to MY statement was “We are essentially doing that already”.  And when I looked, it wasn’t exactly so.  Even writing code with temporary filler gaps so it runs and assigning programmers to fill them is not exactly the same thing.  But the real deal has worked for me as an extreme coding tactic to get a complex job done fast, and it is likely the approach I’d take. Maybe that’s just because at least  I almost got to the end of “Bob goes to the Beach” with a ruler, saying the words out loud,  and giving meaning  to one phrase at a time!  (almost the same thing as runtime- transformation outsourcing, really).

like0

Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Info

Barry Robson's picture

No problem Tom. I shall be quiet till I hear from you. Your special insight into all this is greatly appreciated.

-----Original Message-----
From: Tom Munnecke <munnecke@gmail.com>
To: Barry Robson <robsonb@aol.com>
Cc: VistA: VA Next-Gen Planning <vista-next-gen-planning@groups.osehra.org>
Sent: Wed, Sep 25, 2013 10:36 am
Subject: Re: [vista-next-gen-planning] Joint DOD & VA Virtual Patient Record (VPR) iEHR Enterprise Information Architecture (EIA)

these are all great comments, and I plan to reply to them after I have time to compose a response after a little vacation. coming soon.

On Sun, Sep 22, 2013 at 11:05 AM, Barry Robson <robsonb@aol.com> wrote:

I understand that some of my collaborators and colleagues can read from VistA but so far I have focused on HL7-CDA-like sources and how to get them into a granular EAV form, as Q-UEL as a universal second language (but of course it could be any kind of IT version of Esperanto). So I need to engage Q-UEL at a deeper level with VistA. So someone correct me if I’m wrong on the following.
To summarize so far, at least as far as get it , it is almost trivial to write in a UEL from VistA particularly thanks to FMQL. However, to go further than simply a reformatted copy, one needs to reorganize VistA data into the kinds of structures that that I think are needed by diverse listening applications in the US and including in at least Europe, and especially by EBM and CDS systems. They will look very like the example tag artifact I posted on prescription (if I get my way). But it does mean that that a “ghost rewriter” is required ofr VistA for each domain. Stephen lists some 12 core domains, which clearly break down to subdomains, but it is not the end of the world to write such a finite number of converters.
The bigger challenge is of course to get Q-UEL information content, or some such UEL, expressed in VistA. As far as I understand, we hear you VistA, but you don’t hear us so well. We can subscribe but not submit, at least not flexibly and deeply. Of course, I could write what anyone thinks at a glance is VistA, and I bet it would be legal VistA. So say we have to arm up, and go in. Folks say it looks a bit like Hamburger Hill. It obviously requires a deep specialist knowledge and understanding to find anything, and it is hard for a developer to read it when you do. However, this kind of example snippet below doesn’t indicate that this cynicism is entirely justified for VistA itself…
:
;GMRCSS=To Service GMRCPROC=Procedure Request Type
;GMRCURG=Urgency GMRCPL=Place Of Consultation
;GMRCATN=Attention GMRCINO=Service is In/Out Patient
;GMRCPNM=Patient Name GMRCDIAG=Provisional Diagnosis
;GMRCERDT=Earliest Appr. Date
;GMRCPROS=Prosthetics Service y/n
N GMRCSS,GMRCPROC,GMRCURG,GMRCPL,GMRCATN,GMRCINO, GMRCDIAG,LN,GMRCRESP,GMRCERDT,GMRCPROS,IDX
K ^TMP("GMRCR",$J,"ED") S GMRCLNO=1
I $L($P(^GMR(123,+GMRCO,0),"^",12)) S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=" CURRENT STATUS: (Not Editable): "_$P(^ORD(100.01,$P(^(0),"^",12),0),"^",1),GMRCLNO=GMRCLNO+1
S GMRCD=0 F S GMRCD=$O(^GMR(123,+GMRCO,40,"B",GMRCD)) Q:'GMRCD S GMRCDD="" F S GMRCDD=$O(^GMR(123,GMRCO,40,"B",GMRCD,GMRCDD)) Q:'GMRCDD D
.I $P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",2)=19 S LN=0 D
..N GMRCPERS,GMRCTX
..I '$D(^GMR(123,+GMRCO,12)) D
...S GMRCPERS=+$P($G(^GMR(123,+GMRCO,40,GMRCDD,0)),"^",5)
:
..because at least somewhere it tells you what GMRCSS etc mean. So I don’t think it is such a million miles away from my example of generating a Q-UEL data structure from MUMPS, and more importantly doing the reverse.
I therefore didn’t quite understand the criticisms of VistA. That’s of course except mine on a human direct readability, but that is maybe just because I’m stupid and couldn’t get past Green Book 2, “Bob goes to the Beach” in primary school. Therefore the real catch, I am guessing, is not VistA per se. The real catch is that I presumably need to write the VistA such that established VistA apps could use what Q-UEL wrote. Otherwise, unless the apps are really smart, they would be looking in the wrong places and choking. At first glance, one way to see it that we are given an excellent FMQL File Manager Query Language, but FileMan is essentially a frozen template for data entry. It does not as far as I can see have an accepted have a generally applicable FMSL File “Manager Submission Language” to match VistA’s intrinsic scope and power. We are fixed to FileMan developers’ view of the world. But in the end, an FMSL would also have to deliver what the apps can use. It would not get rid of the app problem. Therefore, my guess is that the problem never was VistA, but the apps.
To allow a future diversity of input and output apps for something that is a source code and addressed directly would naturally trigger the notion that refactoring is needed. By formal definition, that usually means generalize type, encapsulate fields, componentize, class- extract, humanize, and re-ontologize (move data up and down between superclasses and subclasses). It also includes “polymorphasize”, i.e. apply polymorphism. In some ways that’s the most embracing. Basically of course it means a single algebraic and/or value interchange with between different types, by using types whose operations can also be applied to values of another type.

To my taste, a good approach here was our original intended design feature in GLOBAL (Ball, J, et al. . "A Polymorphic Programming Environment for the Chemical Pharmaceutical and Biotechnology Industries", Chemical Information Systems - Beyond the Structure Diagrams. Eds. D. Bawden and E. M. Mitchell, Ellis Horwood Press, 1990, 107-123), and used in http://www.ncbi.nlm.nih.gov/pubmed/2099743. The key feature I am thinking of here, however, is very simple to implement in any code and probably not so novel these days, describable as “run time transformation step outsourcing”. It applies to new code and in the above studies that was an Expert System coded in GLOBAL, but it is also an “erode the code” strategy for preexisting code, because we can do the following for bits we wish to replace. Any difficult transform operation function or object is initially filled, or for code refactoring replaced by, an object that invokes not code but a connection to a human expert. This person does the operation manually, using his/her brain as the program required, and completes the gap in the workflow, but then he/she or his/her “knowledge engineer” writes code in a convenient high level meta-algorithm/protocol language to do the job automatically, and then that gets invoked automatically. Or semi-automatically – the means having sub-operations that also invoke a human expert, and so on. If such code consistently “passes the Turing test” by an indistinguishable good result, ok. That approach is best for large teams. If I did VistA converters myself, I am the available poor closest to domain expert and knowledge engineer, so I am tempted to just hack out the direct code myself. But then maybe one day someone will complain that the converter needs refactoring, and probably it will be me 5% of the way through.
I know the above approach looks trivial and silly. I know it because in my six years at T. J. Watson as the Strategic Advisor to IBM Research and five years as CSO IBM Global Healthcare, Pharmaceutical, and Life Sciences, they listened to quite a few things I said, but developing systems by “run-time transformation step outsourcing” was never one of them. Well, IBM is a pretty big and complex place and I shouldn’t say that they were not doing it somewhere, so apologies to IBM for the groundless presumption. But the point is, either way, that the standard reply to MY statement was “We are essentially doing that already”. And when I looked, it wasn’t exactly so. Even writing code with temporary filler gaps so it runs and assigning programmers to fill them is not exactly the same thing. But the real deal has worked for me as an extreme coding tactic to get a complex job done fast, and it is likely the approach I’d take. Maybe that’s just because at least I almost got to the end of “Bob goes to the Beach” with a ruler, saying the words out loud, and giving meaning to one phrase at a time! (almost the same thing as runtime- transformation outsourcing, really).

--
Full post: http://www.osehra.org/content/joint-dod-va-virtual-patient-record-vpr-ie...
Manage my subscriptions: http://www.osehra.org/og_mailinglist/subscriptions
Stop emails for this post: http://www.osehra.org/og_mailinglist/unsubscribe/3071

like0