Understanding XDS metadata - IHE re-documentation effort

I am republishing an email written by Lynn Felhofer to the XDS Implementer mailing list, as it is a fantastic explanation of the new IHE IT Technical Framework - Volume 3 update.

Metadata Purposes

Now available, the 2013 version of the IHE IT Infrastructure Technical Framework v10 Final Text are published on the IHE web site.   

A copy of the announcement is included at the end of this note.  New Trial Implementation supplements were published last week.

One of the initiatives taken on by the IT Infrastructure Technical Committee in 2013 is to improve the documentation of metadata associated with XDS and related profiles. 

The metadata specification in ITI Technical Framework Volume 3 Section 4 (ITI TF-3:4) was originally authored in support of only the XDS profile. The organization, approach, and editorial style were restricted to support of a single profile within a single IHE domain.  Since that time, many IHE profiles have made use of the metadata defined by XDS, often called 'XDS Metadata' or 'XD* Metadata'.  Some profiles have made small adjustments in the use of metadata to accommodate the needs of the environments the profiles are designed to support.  These adjustments, as well as Change Proposals incorporated over time, led the contents of Section 4 to become hard to comprehend, especially for those not implementing XDS.

In 2013, ITI TF-3:4 is rewritten. The update started by moving all content in ITI TF-3 somewhere within the current organizational scheme.  Once moved, content was revised to improve understanding and adjust for redundancy.  Whenever possible, the content from ITI TF-3 was kept as written, just moved to a new organizational structure.  In many cases, the original text was found to be imprecise and more specific text was developed.  

No technical requirements are changed or extended as part of this re-documentation effort.

This re-documentation effort focuses on:

• Adding a conceptual overview of the metadata that is profile- and technology-independent. This is done in section 4.1.
• Re-organizing the rest of the content in section 4 to support profile/transaction-independent descriptions followed by profile and transaction-specific content.
• Adding clarifying material to section 4 in the form of UML diagrams and additional explanatory text where focus group and public comment feedback indicated they would be most useful.
• Clarifying statements that can be tested at Connectathon as SHALL statements, and disambiguating implementation guidance statements with SHOULD or MAY statements.

This approach limits implications outside of ITI TF-3 as much as possible but allows for future extensions and additions.

Re-organizing the content results in sections and tables getting new numbers.  In order to ease transition, frequently-reference tables, eg the Data Types table, are labeled to include the both the new previous table number, e.g. "Table 4.2.3.1.7-2: Data Types (previously Table 4.1-3)".  ITI Technical Committee members have also reviewed existing Technical Frameworks and supplements across domains and have tried to ensure that references into ITI TF-3:4 have been updated with new section or table numbers in these documents published in 2013.

The ITI Technical Committee believes that the specification of "Metadata used in Document Sharing profiles" in ITI TF-3:4 is improved.   Use the current version of this and all technical framework documentation in your implementation work this year!  If you find errors or have suggestions for improvements, please send an email to iticomments@googlegroups.com or submit a Change Proposal.

Finally, with the publication of the new Technical Framework, the terms "XDS metadata" and "XD* metadata" are replaced with "Document Sharing metadata".  We will give those who sleep with Volume 3 under their pillow some time to adjust.

- Lynn Felhofer

  IHE Technical Project Manager - ITI domain

IHE IT Infrastructure Technical Framework Volumes Published  The IHE IT Infrastructure Technical Committee has published the following Technical Framework Volumes as of September 27, 2013: Volume 1 (ITI TF-1): Integration Profiles Volume 2a (ITI TF-2a): Transactions Volume 2b (ITI TF-2b): Transactions (cont.) Volume 2x (ITI TF-2x): Appendices A through W and the Glossary Volume 3 (ITI TF-3): Contains Section 4 (Cross-Transactions Specifications) and Section 5 (IHE Content Specifications) The profiles contained within these volumes may be available for testing at subsequent IHE Connectathons. The documents are available for download at http://ihe.net/Resources/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/ITI_Public_Comments/.

Vocabulary Standards make poor User Interfaces

There are many articles written on the poor user interface experience that clinicians have with Electronic Health Records. One out yesterday from the Washington Post did a good job of explaining the problem. The user interface simply overwhelms the clinician.

Too often I hear this attributed to poor interoperability standards. This leap of logic is simply not correct. The problem is that too often, interoperability standards overly influence the user interface. Note the opposite is also true, too often user interface incorrectly influences interoperability standards. This happens when we forget that the purpose of an interoperability standard is to achieve interoperability between systems, not to enable interoperability with humans. This is especially true when applications are designed around RESTful interfaces, but is not a fundamental problem with RESTful, just poor design.

The problem identified is one of medical knowledge structure. This is a hugely rich space, that is we have a huge amount of medical knowledge. Medical knowledge is not the same as Health Information. Medical knowledge is the organization of biomedical, clinical, epidemiological, and social-behavioral sciences as well as the application of this knowledge to patients. Medical knowledge is all that stuff that clinicians learn in school. Medical knowledge is what vocabularies aid with defining.

The medical knowledge space is scientifically organized, that is it is organized in a way that makes good scientific sense. This organization is good for managing a comprehensive vocabulary. Such ontology view of vocabulary helps make sure the vocabulary is complete and not overlapping. It works good for technical interoperability. It is good for computer processing.

This ontology is not the best organization for the user interface, for workflows like the exam room. A different view of the knowledge space should guide user interface. This perspective must come from the 'use' of the knowledge perspective. The medical professional societies need to come up with one or more ways to 'use' the knowledge space.

These ‘use’ perspectives do come from some medical professional societies. We need to include them in the Meaningful Use discussion. For example, I have worked with the guidance given by the American Congress of Obstetricians and Gynecologists (ACOG) when we worked on an IHE Antepartum Profiles (includes the following profiles) - Antepartum Education (APE), Antepartum Laboratory (APL), Antepartum History and Physical (APHP), and Antepartum Summary (APS). These IHE profiles work on the technical Interoperability level, but more to the point ACOG works hard to define the user experience and expected outcomes.

We should make sure we include “Medical Professional Society”, and their “Standards of Practice” when we talk about standards. Technical standards alone are sure to be a poor user experience. I am usually the one reminding people that Security and Privacy are not just technical issues, but require far more in Policy, Physical, and Procedure space. All these spaces are far more than just technical.

Healthcare access control scope constraints on OAuth tokens

Healthcare is rushing toward using RESTful specifications of healthcare objects. The prime defining is being done by HL7 FHIR. Something I am very actively involved in. Protecting these resources, Security and Privacy, is looking to use OAuth given some of it's advantages over other systems. The IHE IUA profile defines how an OAuth token would carry additional attributes to enable server side access control decisions. What the profile does not include is how the scope is set inside the OAuth token.

A scope constraint is a common concept in OAuth and SAML, that is that the token is issued only for a specific subset of information. This subset of information is the 'scope'.

For example how does one request a token for just patient "John Moehrke". This is likely to be more implementation dependent than IHE can profile. Meaning that there might be a different way to do this for FHIR, DICOM, Continua, and others. Because the resources are slightly different. For example the link "John Moehrke" is a URL that could be considered a scope restriction to information about the identity pointed to. But this URL is specific to Google+, and may not be the same URL as "John Moehrke" in the context of Twitter.

Note this example is not pointing toward any specific rule, just pointing toward the identity of the patient for which the requester wants to have access to. The OAuth service makes the decision on if this is a legitimate and authorized scope. If the user has access rights to that scope, then that scope would be included in the OAuth token. If the user does not have the access rights to that scope, then the token is not issued. So this discussion is not about making the decision, it is about how does one describe the scope that you are willing to be constrained to, in a consistent and interoperable way.

Interesting scope concept that Josh Mandel speaks about in his pilot implementation at the FHIR connectathon. Specific comment from Josh at 5:53 in the overall connectathon report-out-video. -- Put the FHIR URL that identifies the specific Patient you are asking about, thus any queries using that token will be constrained by the Resource service to that specific Patient records. For example the OAuth token scope on that patient would be seen as an implied patient query parameter (regardless of the query parameters provided).

This would be too specific for IHE IUA profile, but would be a very useful FHIR profile of the IHE IUA profile. Note this could certainly be done just as well with SAML (aka the IHE-XUA profile).

Access Control (Consent enforcement)

• Advanced Access Controls to support sensitive health topics
• Policy Enforcing XDS Registry
• Healthcare Metadata
• Texas HIE Consent Management System Design
• IHE - Privacy and Security Profiles - Access Control
• Data Classification - a key vector enabling rich Security and Privacy controls
• Healthcare Access Controls standards landscape
• Handling the obligation to prohibit Re-disclosure
• Access Controls: Policies --> Attributes --> Implementation
• IHE - Privacy and Security Profiles - Document Encryption

IHE IT Infrastructure Technical Framework Supplements Published

This just crossed my desk. This is the latest in Trial Implementation supplements from the IT Infrastructure. For my audience this is a revision to MHD to acknowledge the harmonization work ongoing with HL7 FHIR; and the Trial Implementation of Internet User Authorization (IUA) -- the OAuth profile.

IHE IT Infrastructure Technical Framework Supplements Published for Trial Implementation The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for Trial Implementation as of September 20, 2013: Care Services Discovery (CSD) Cross-Enterprise Document Workflow (XDW) Document Metadata Subscription (DSUB) Healthcare Provider Directory (HPD) Internet User Authorization (IUA) Mobile access to Health Documents (MHD)  These profiles may be available for testing at subsequent IHE Connectathons. The documents are available for download at http://ihe.net/Resources/Technical_Frameworks/. Comments on all documents are invited at any time and can be submitted at http://ihe.net/ITI_Public_Comments/.

IHE-ATNA and HL7-FHIR.SecurityEvent -- recording a Disclosure

An Accounting of Disclosures is a report that a Patient has the right to get. This report includes all the touches of their data that are outside some set of rules. In the USA these rules are defined in HIPAA, and mostly exclude just about everything. But, an Accounting of Disclosures is still a Right. I have covered the fact that an Accounting of Disclosures is only informed by IHE-ATNA audit log, mainly because few of the events that the rules say need to be recorded are mediated by Healthcare IT technology.

I am working on a FHIR application that one could use to record that a Disclosure has happened. This is defined in ASTM-2147, generally we need to know:

• Who did the disclosure, 
• What patient was involved (multiple patients, would be done as multiple audit entries), 
• what data was involved (multiple identifiable data would be multiple audit entries), and 
• why was the disclosure done. 

There is some other information that some circumstances would call for:

• Who is the custodian of the data (the official organization responsible), and
• Who authorized the release (if not the patient, or policy)

This brings up the question of how do I put this information into an IHE-ATNA Audit Log message. Well, the IHE-XUA profile put a minimal pattern of this IHE-ATNA event for recording that a Disclosure happened. I will expand on it a bit here, and likely in a new Change Proposal. The HL7 PASS Audit service also defined this Disclosure event. So, much of what I am doing is just bringing things together.

Some Standards work still needed:

It appears that some new codes need to be created. It isn't very clear what is the best organization to do this, but I always like going back to the core standards organization simply to keep everything nicely together. So I would tend to go back to DICOM.

First, we need an EventTypeCode that indicates that this event was a confirmed "Disclosure", as distinct from Export" events that are need to be looked at to see if they are part of normal treatment workflows.

• EV(“Disclosure”, “HIPAA”, “Privacy Disclosure”) 
• EV(“Disclosure”, http://www.gpo.gov/fdsys/pkg/CFR-2007-title45-vol1/xml/CFR-2007-title45-vol1-sec164-528.xml, “Privacy Disclosure”) 
• EV(“Disclosure”, “urn:lex:us:federal:codified.regulations:2010;34.cfr.345”, “Privacy Disclosure”) 
• EV(“IHE0006”, “IHE”, “Privacy Disclosure”) 

It is not clear if the rest of this is the right values. specifically the identity of the  custodian and the authorizing agent. I pulled values from the role vocabulary in ASTM-1986. I couldn't find these in ISO-21298. I don't have easy access to the roles in SNOMED.

There also appears to be other work that I have uncovered that needs clarifications in IHE-ATNA, DICOM, and now FHIR.

ATNA - Accounting of a Disclosures audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110106, DCM, “Export”)
	EventActionCode	M	“R” (Read)  for Export
	EventDateTime	M	not specialized
	PurposeOfUse	M	why was the data disclosed
	EventTypeCode	M	EV(“Disclosure”, “HIPAA”, “Privacy Disclosure”)
ActiveParticipant - Releasing Agent (1)
ActiveParticipant - Custodian (0..1)
ActiveParticipant - Authorizing Agent (0..1)
ActiveParticipant - Receiving Agent (1)
Audit Source (1)
ParticipantObject – Patient(1)
ParticipantObject – Data (Document) released(1)

Releasing Agent AuditMessage/ ActiveParticipant	UserID	M	Identity of the human that initiated the Disclosure.
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	M	“true”
	RoleIDCode	M	EV(110153, DCM, “Source”)
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address, as available
Custodian  (if known) AuditMessage/ ActiveParticipant	UserID	U	not specialized
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	M	“false”
	RoleIDCode	M	EV("Health Records", ASTM1986, "Health Information Management")
	NetworkAccessPointTypeCode	NA	not specialized
	NetworkAccessPointID	NA	not specialized
Authorizing Agent (if known) AuditMessage/ ActiveParticipant	UserID	U	not specialized
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	M	“false”
	RoleIDCode	M	EV("Patient Advocate", ASTM1986, "Patient Advocate")
	NetworkAccessPointTypeCode	NA	not specialized
	NetworkAccessPointID	NA	not specialized
Receiving Agent AuditMessage/ ActiveParticipant	UserID	U	not specialized
	AlternativeUserID	U	not specialized
	UserName	U	not specialized
	UserIsRequestor	M	“false”
	RoleIDCode	M	EV(110152, DCM, “Destination”)
	NetworkAccessPointTypeCode	M	“1” for machine (DNS) name, “2” for IP address
	NetworkAccessPointID	M	The machine name or IP address, as available
Audit Source AuditMessage/ AuditSourceIdentification	AuditSourceID	U	not specialized.
	AuditEnterpriseSiteID	U	not specialized
	AuditSourceTypeCode	U	not specialized
Patient     (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (Person)
	ParticipantObjectTypeCodeRole	M	“1” (Patient)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(2, RFC-3881, “Patient Number”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized
Data (Document) Released (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (System)
	ParticipantObjectTypeCodeRole	M	“3” (report)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(9, RFC-3881 , “Report Number”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The value of <ihe:DocumentUniqueId/>
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized

FHIR SecurityEvent - Disclosure 

That is the complex and complete definition using the IHE-ATNA table. We now have a RESTful implementation of this in HL7 FHIR. So what does one of these look like in FHIR. The advantage, or disadvantage, of FHIR  is that it does allow you to cheat. Given that it has left constraints to profiles, such as IHE, it leaves almost everything optional. It further provides mechanisms for simple text to be used where  coded values are defined. Thus I can make a very simple FHIR message, that really doesn't carry the same meaning, but does get across the educational purpose. Note that I am still working on this, so will update this as I get it corrected.

<SecurityEvent xmlns="http://hl7.org/fhir">

  <event>

    <type>

      <coding>

        <system value="http://nema.org/dicom/dcid"/>

        <code value="110106"/>

        <display value="Export"/>

      </coding>

    </type>

    <subtype>

        <coding>

            <system value="HIPAA"/>

            <code value="Disclosure"/>

            <display value="HIPAA disclosure"/>

        </coding>

    </subtype>

    <action value="R"/>

    <dateTime value="2013-09-17T14:24:00-06:00"/>

    <outcome value="0"/>

  </event>

  <participant>

    <!-- Source Participant, the Releasing Agent -->

    <role>

      <coding>

        <system value="http://nema.org/dicom/dcid"/>

        <code value="110153"/>

        <display value="The sender of the data"/>

      </coding>

    </role>

    <userId value="INSERT_USERNAME"/>

    <requestor value="true"/>

  </participant>

  <participant>

    <!-- Destination Participant, the Receiving Agent -->

    <role>

      <coding>

        <system value="http://nema.org/dicom/dcid"/>

        <code value="110152"/>

        <display value="The destination of the data"/>

      </coding>

    </role>

    <userId value="INSERT_RECIPIENT"/>

    <requestor value="false"/>

  </participant>

  <source>

    <!-- Source of Audit event -->

    <identifier value="Johns Accounting of Disclosures Application"/>

  </source>

  <object>

    <!-- ParticipantObject - Patient -->

    <identifier value="INSERT_PATIENT_NAME"/>

    <name value="INSERT_PATIENT_NAME"/>

    <type value="2"/>

    <lifecycle value="6"/>

  </object> 

  <object>

    <!-- ParticipantObject - what was disclosed -->

    <lifecycle value="11"/>

    <type value="4"/>

    <identifier value="INSERT_DESCRIPTION_OF_DATA"/>

    <name value="INSERT_DESCRIPTION_OF_DATA"/>

  </object>

</SecurityEvent>

Conclusion

This is just how to record that a Disclosure has happened. I have yet to work out how a report can be made. I suspect this should be somewhat easy, especially with FHIR. I can just query on the SecurityEvent with the patient that I want to report on, looking for Export / Disclosure events. Then I just extract out the specific fields. More complex will be to handle someone being more complete with their Disclosure auditing.

The playing with this has uncovered a bunch of little things. It appears that I have uncovered there needs to be clarifications in IHE-ATNA, DICOM, and now FHIR.