Tuesday, August 19, 2014

Performance vs Privacy

Sadly this week we hear about a HUGE breach of Patient Identities. This did NOT NEED TO HAPPEN!!!
200 Hospitals Hit Affecting 4.5 Million Patients (August 18, 2014) Tennessee-based Community Health Systems (CHS) says that intruders accessed its system over a three-month period earlier this year, compromising patient names, addresses, and Social Security numbers
(SSNs) of 4.5 million people. The company maintains that medical and financial information was not affected. CHS operates more than 200 hospitals in 29 US states. The company claims that the attacks emanated from China. Information in CHS's Securities and Exchange Commission
http://www.darkreading.com/community-health-systems-breach-atypical-for-chinese-hackers/d/d-id/1298095?
http://www.bbc.com/news/technology-28838661http://bits.blogs.nytimes.com/2014/08/18/hack-of-community-health-systems-affects-4-5-million-patients/http://www.computerworld.com/s/article/9250464/About_4.5M_face_risk_of_ID_theft_after_hospital_network_hacked?taxonomyId=17http://www.theregister.co.uk/2014/08/18/hospital_chain_claims_chinese_hackers_stole_45_million_user_details/

There are two models of patient record locator service (RLS). That is, how do I learn of all the locations that have patient data for the specific patient I am interested in. This is more important today where patients have had many home cities, patients travel on business and pleasure, and specialty healthcare practices are easy to get specialist care. The two models of location discovery are very different and carry very different Privacy impacts.

Federated Identity Knowledge Discovery:

If Privacy was most important, a Federated Identity Knowledge Discovery model would be used. This is the model that IHE has defined for Cross-Community Access exchanges (XCA). The Cross-Community Access (XCA) is the model defined for federating multiple regional exchanges. The XCA model defines the XCPD Profile, as explained by Karen earlier in my blog.


That is a model where one discovers the locations that have data on a given patient when you need to know. This model does not try to pre-coordinate patient identities as the identities are created and updated. This model, when the patient is seeking care, asks everyone if they know of the specified patient. As such this model does mean the answer might take a long time to come back, and might be missing some locations that didn't respond in time or didn't have enough data to make an exact match.

The failure to match due to not enough information isn't unique to this model, but this model does make these failures more likely as the match does need to be made quickly.

The failures to match can also be detected as the patient can indicate the various locations they know of, and if the results seems to be missing those locations more refined query can be done. In this case the refinement would be based on the patient knowledge of how they were known at the time they were cared for in that location.

The bigger problem with Federated Identity Knowledge Discovery is that the response time is potentially many minutes long, and really is not deterministic as to when one has all the responses from everyone.

Centralized Identity Knowledge

The second model is to centralize all knowledge about the patient. This is the model that IHE has defined for use with in an XDS Health Information Exchange. The solution that IHE defines for a regional exchange. Note that not all regional exchanges should use XDS, one can actually make a federation exchange using XCA within a region. So you could use the above model. However within a region one often has many instances of the Patient visiting multiple sites within that region. So the benefits of Centralized Identity Knowledge might be worth the risk.

The Centralized Identity Knowledge model leverages HL7 “ADT” – Admit, Discharge, Transfer. Which is actually more than just those three verbs. In the Centralized Identity Knowledge model we use the IHE Profiles of PIX and PDQ. In these models whenever a new patient identity is created somewhere, knowledge of that patient identity is forwarded to some central authority. Similar when that patient is registered at a site, discharged, transferred. Similar when mistakes in the identity are corrected, including Merge or Link events. All of these actions on the Patient Identity are forwarded to the central authority. This central authority is receiving identity information from ALL of the sites participating in the Health Information Exchange, and will do a match of identity as it receives the identity knowledge.

This model, can also involve humans when the matching algorithm detects a potential match. The human can do some research and fix the match as needed. So this model is often seen as more accurate. Less prone to False-Positive and False-Negative matches.

One advantage of this is that it is easy for hospitals to simply copy their ADT feed and send it to the Centralized Identity Knowledge store. The hard processing is centralized.

The biggest advantage of the Centralized Identity Knowledge is that the “Cross-Reference” is known well in advance of someone needing to know. So a Patient Record Location Service call is very quick and deterministic. This model is best when Performance is most important. We hear much about how unlikely Doctors are to wait a few seconds.

The Privacy disadvantage is that ALL patients are known in a centralized database. This is regardless of if the information is needed ever. Think about a patient that never has moved, always sees the same doctor, never needs the HIE service. Thus a breach of this database breaches ALL Centralized Identity Knowledge.

On the positive side, the Centralized Identity Knowledge is just identities, no medical information is needed in this database. However that is not to say it doesn't also get centralized.

Patient Centric

There is another model, and that is that the Patient mediates all information flow. This is the model where the patient is the only one that knows who all have interacted with them. This is where the patient provides all the information. This is also the model where the system totally fails if the patient is in an emergency situation. The patient can also better hide information they don’t want to share, which is a privacy benefit, but a potential risk to patient safety and quality of care.

Conclusion

I hear of new exchanges being put together that choose to use the Centralized Identity Knowledge method. Their excuse is that it is faster, which it is. They also point out that it is easier to get quality results, which is somewhat true. 

Privacy Matters. It is important to consider Privacy and Security up front. They are way too often left to an after-thought. It is when they are left to an after-thought that they become burdensome and are seen as nothing but trouble. When one considers Privacy and Security up front, they can be enablers of workflows and most importantly things that make the Patient happy. 

Is waiting a bit longer for a query to happen, followed with a discussion with the patient really that hard for Healthcare Provider -- Professionals?

Nationwide Health Exchange (HealtheWay).

I will note that the Federated Identity Knowledge Discovery is the model that is used by the NwHIN-Exchange, now known as HealtheWay. Thus this breach did NOT come from here, and couldn't.



Tuesday, August 5, 2014

IHE Digital Signature Profile - updated -- Need COMMENTS

The IHE Digital Signature (DSG) profile has been updated. Well it is out for Public Comment through the IHE Change Proposal system -- Ballot 24 -- as Change Proposal 412.


IF YOU ARE AN IHE MEMBER, PLEASE COMMENT!!!! We need constructive comments on this proposal. It was not intended to be a breaking change, but reality is that there is no unified understanding of what the old DSG supplement was defining. The old DSG supplement must be considered fundamentally broken. So this CP must be considered a breaking change.

The goal of Change Proposal 412 is four very important things, none of them are related to failures of the original.
  • The original supplement was written before IHE had a concept of a Content Profile, so it was never written this way. Now that we have a concept, we can write it in a way that is more readable. There was also some loose-ends related to the now deprecated NAV profile.
  • The current supplement template has some other formatting requirements. Actually we also needed to do proper section number reservation and management. So many simple 'editorial' needs.
  • The original only supported a Detached signature, where the content was managed in an XD* environment and the linkage to the signature was done by the XDS Association type "SIGN". This is still needed but we also need an Encapsulating signature that can be used where no XD* is available to hold the things together, so encapsulating signature is an outer envelop of the Digital Signature that holds the signed document inside.
  • The digital signature standard has been updated and now includes everything we needed. So we now specify XAdES-L-T, which brings inside the certificate and a timestamp; and we utilize the CommitmentTypeIndication for Purpose Of Signature. Thus we just bind in a vocabulary specific to Healthcare needs.
  • We did not include the new CDA digital signature. This is not because it isn't useful or interesting, but more because that would have been a very different technology. Those that want this profiled by IHE, should bring a New Work Item Proposal to profile it.

I have had this Change Proposal on my plate since I wrote that it was needed back in 2009. It didn't happen because there simply was not enough use of Digital Signatures in healthcare. However now there is more interest, driven by some Anti-Fraud use-cases.

The main problem with Digital Signatures is NOT the standards, it is the Policies and overhead in issuing proper Digital Identity (PKI). Once there are Digital Certificates issued for the purpose of Digital Signatures, then there are many use-cases that can be enabled. However that first justification of the costs is very hard to do, and somehow combining justifications just never seems to happen.

Review the proposed new supplement as Change Proposal 412.



The changes to the IHE DSG profile are significant should be considered a breaking-change from the original DSG supplement published in 2009. The DSG supplement has remained in “Trial Implementation” since 2009. Breaking changes during “Trial Implementation” are proper and should be expected.
The Document Digital Signature (DSG) profile is a Document Content profile that provides general purpose methods of digitally signing of documents for communication and persistence. This method can be used within a Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD). There are three methods of digital signature provided: Encapsulating (An encapsulating signature is a signature approach that encapsulates the signed content within the signature syntax.), and Detached (manifest).

Electronic documents are being increasingly relied upon in healthcare. Signatures have been a part of the electronic documentation process in health care and have traditionally been indicators of accountability.  Reliable exchange of data between disparate systems requires a standard that implements non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

This second revision of the DSG supplement addresses the following:
  • Puts the profile into the current supplement template
  • Puts the profile into the current Document Content format
  • Adds Encapsulating signature, which is especially useful when Document Sharing are not used. For example: RFD based output.
  • Update the signature standards: XaDES specifically that now includes profiles for Long-Term signatures

Other Digital Signature Blog Posts

 

Monday, July 28, 2014

PDQm - Patient Demographics Query as Mobile API

The IHE ITI committee last week approved the Patient Demographics Query for Mobile (PDQm) profile go forward to Trial Implementation. This puts it on track for testing at the USA Connectathon in Cleveland. This is the first Profile of the new FHIR core standard. Both are in a trail state, so it is possible things will change. But these both are based on very mature concepts.

The executive summary is that this is a very minimal profile of the HL7 FHIR Patient resource. Two items have been made mandatory, where the FHIR spec leaves them potentially optional. One extension was added to support the pediatrics use-case that is an option in PDQ. Otherwise it is a simple FHIR 'GET' transaction, aka Query, that returns a Bundle (aka Atom Feed) of the resulting matching entries.

Use-case for PDQm

 The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.
  • The functionality is identical to the PDQ Profile described in the ITI TF-1:8. The differences are transport and messaging format of messages and queries. The profile leverages HTTP transport, and the JavaScript Object Notation (JSON), Simple-XML, and Representational State Transfer (REST). The payload format is defined by the HL7 Fast Health Interoperable Resources (FHIR) draft standard.
Using these patterns, the PDQm Profile exposes the functionality of a patient demographics supplier to mobile applications and lightweight browser applications.

The following list provides a few examples of how PDQm might be leveraged by implementers:
  • A health portal securely exposing demographics data to browser based plugins
  • Medical devices which need to access patient demographic information
  • Mobile devices used by physicians (example bedside eCharts) which need to establish patient context by scanning a bracelet
  • Web based EHR/EMR applications which wish to provide dynamic updates of patient demographic information such as a non-postback search, additional demographic detail, etc.
  • Any low resource application which exposes patient demographic search functionality
  • Any application using the MHD Profile to access documents may use PDQm to find an appropriate patient identifier
  • This supplement is intended to be fully compliant with the HL7 FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with existing PDQ and PDQv3 Profiles.
Currently the HL7 FHIR standard is in “Draft Standard for Test Use” (DSTU) and may experience a large amount of change during this phase. Readers are advised that, while the profiled components in this supplement may not accurately reflect the most recent version of the FHIR standard, implementations of PDQm will be tested as specified in this supplement. Changes to the FHIR DSTU will be integrated into this supplement via the formal IHE Change Proposal (CP) process.

Using the FHIR Patient resource, IHE needed only profile two elements. IHE sets the patient name and identifier as mandatory, whereas the core FHIR allows them to be empty. This is the FHIR Patient Resource as it is used by PDQm.

FHIR Patient Resource ++ 

This is the definition for the Patient Resource contained within the Query Patient Resource response message. The purpose of the definition is to describe the data elements relevant for this transaction. It is a restriction of the Patient Resource found in chapter 5.1.2 of the FHIR standard. For the complete FHIR definition of this Resource please see ITI TF-2x: Appendix W


Pediatrics Demographic Option

PDQm has usecases to support new-born that have not been fully identified, and thus require that the mother’s maiden name be included in their Patient resource. This was introduced to PDQ with a Pediatrics Option. This use-case is not currently supported by the FHIR DSTU, so IHE has extended the Patient resource to include this. IHE will be bringing the use-case to HL7 for proper handling (recognizing that it is most likely the mothers name, not the mother’s maiden name that is desired).

...
"extensionDefn" : [
  {
       "code" : "mothersMaidenName",
       "contextType" : "resource",
       "context" : [ "Patient" ],
       "definition" : {
              "short" : "Patient's mother's maiden name",
              "formal" : "The name of the patient's mother",
              "min" : 0,
              "max" : 1,
              "type" : [
                     {
                           "code" : "HumanName"
                     }
              ],
              "isModifier" : false
       }
  }
]
...


PDQm as a RESTful API to a mature PDQ and PIX environment.


 
PDQm can be viewed as an API to a classic PDQ or PDQ v3 environment. Same PDQ use cases and interactions, using the FHIR encoding for the transaction from the mobile consumer. This diagram shows an implementation of a gateway that converts the PDQm into a normal PDQ transaction via a gateway.






PDQ attributes 

The following table shows the attribute mapping between PDQ, PDQ v3, and PDQm.

Abstract Field
PDQ
PDQ HL7v3
PDQm
Identifier List                                    
PID.3 and PID.18
Id
identifier
Name(s)
PID.5 and PID.9
Name
name
Date / Time of Birth
PID.7
birthTime
birthDate
Gender
PID.8
administrativeGenderCode
gender
Address(es)
PID.11
Addr
address
Telecommunications Address(es)
PID.13 and PID.14
Telecom
telecom
Language(s) of communication
PID.15
languageCommunication
communication
Marital Status
PID.16
maritalStatusCode
maritalStatus
Non-Medical Identifiers
PID.19 and PID.20
asOtherIds
identifier
Death Date/Time
PID.29
deceasedTime
deceasedDateTime
Mother’s Maiden Name
PID.6
personalRelationship.name
See ITI TF-2c: 3.78.4.2.2.2
Patient Birth Order
PID.25
multipleBirthOrderNumber
multipleBirthInteger

PDQ Query Parameters


And the query parameters, mapped between the three

Abstract Parameter
PDQ
PDQ HL7v3
PDQm
Identifier List
@PID.3 and @PID.18
livingSubjectId
Identifier
Name
@PID.5
livingSubjectName
given and family
Date / Time of Birth
@PID.7
livingSubjectBirthTime
Birthdate
Gender
@PID.8
livingSubjectAdministrativeGender
Gender
Address
@PID.11
patientAddress
Address
Domains to be Returned
QPD-8
otherIDsScopingOrganization
See ITI TF-2c:3.78.4.1.2.4
Mother’s Maiden Name
@PID.6
mothersMaidenName
mothersMaidenName.given and mothersMaidenName.family
Patient Telecommunications Addresses
@PID.13
patientTelecom
Telecom

The result of a query is a “Bundle”, which for XML encoding is derived in FHIR from the standards based ATOM feed.

Examples


Here is a sample Query, in HTTP form, requesting JSON format be returned, all Male patients with the Given name “John” and the Family name “Smith”.

GET http://pdm-sample:8080/iti-y1/Patient?_format=application/json+fhir&gender=M&family=Smith&given=John&count=10
User-Agent: Fiddler
Host: pdq-sample:8080

Here is a sample result.  Amazingly there is only one John Smith.

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json+fhir; charset=UTF-8
Content-Length: 2683
Date: Sun, 06 Apr 2014 20:38:23 GMT
Expires: Sat, 05 Apr 2014 20:38:20 GMT

{
  "resourceType" : "Bundle",
  "title" : "Search results for resource type Patient",
  "id" : "urn:uuid:c179d5bd-e81e-4fe0-981a-46f6c6588f",
  "link" : [
    {
      "href" : "http://pdm-sample:8080/iti-y1/Patient?_format=application/json+fhir&gender=M&family=Smith&given=John&count=10",
      "rel" : "self"
    }
  ],
  "updated" : "2014-04-06T20:38:23Z",
  "totalResults" : "1",
  "entry" : [
    {
      "title" : "Patient \"1\"",
      "id" : "http://pdm-sample:8080/iti-y1/Patient/1",
      "link" : [
        {
          "href" : "http://pdm-sample:8080/iti-y1/Patient/1",
          "rel" : "self"
        }
      ],
      "updated" : "2014-03-11T20:34:55Z",
      "content" : {
        "resourceType" : "Patient",
        "text" : {
          "status" : "generated",
          "div" : "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<div xmlns=\"http://www.w3.org/1999/xhtml\">John Smith (Male) - 1974-12-25</div>"
        },
        "identifier" : [
          {
            "use" : "usual",
            "system" : "urn:oid:1.2.36.146.595.217.0.1",
            "value" : "12345",
            "assigner" : {
              "display" : "Acme Healthcare"
            }
          }
        ],
        "name" : [
          {
            "use" : "official",
            "family" : [
              "Smith"
            ],
            "given" : [
              "John",
              "James"
            ]
          },
          {
            "use" : "usual",
            "given" : [
              "James"
            ]
          }
        ],
        "telecom" : [
          {
            "use" : "home"
          },
          {
            "system" : "phone",
            "value" : "+1(202)555-6474",
            "use" : "work"
          }
        ],
        "gender" : {
          "coding" : [
            {
              "system" : "http://hl7.org/fhir/v3/AdministrativeGender",
              "code" : "M",
              "display" : "Male"
            }
          ]
        },
        "birthDate" : "1974-12-25",
        "deceasedDateTime" : null,
        "address" : [
          {
            "use" : "home",
            "line" : [
              "123 Main St. West Unit 33"
            ],
            "city" : "Chicago",
            "state" : "IL",
            "zip" : "00000"
          }
        ],
        "managingOrganization" : {
          "display" : "ACME Medical Centres"
        },
        "active" : true
      },
      "summary" : "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<div xmlns=\"http://www.w3.org/1999/xhtml\">John Smith (Male) - 1974-12-25</div>"
    }
  ]
}

 

Conclusion

IHE won't be the only one to profile FHIR. This supplement helps give synergy between the two PDQ flavors, providing a new flavor. The advantage of this new flavor is that applications can more easily process it. It doesn't really make the server job easier

Blog References on mHealth