Friday, April 2, 2021

IHE Mobile Access to Health Documents (MHD) - Implementation Guide

Public Comment now open until May 2.  - The main purpose of this release is to author and publish the MHD Profile using the Implementation Guide Publisher format. There are breaking changes, so this is a new version.  (See below: Significant changes since MHD Version 3.2)




IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The ITI Technical Committee has published the following updated supplement (in HTML vs. PDF form) for public comment from April 2 through May 2, 2021:
Mobile Access to Health Documents (MHD) - Rev. 4.0.0

The document is available at https://profiles.ihe.net/ITI. Comments submitted by May 2, 2021 will be considered by the IT Infrastructure Technical Committee in developing the trial implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

Thursday, April 1, 2021

A good hot beverage on #FHIR

Given that #FHIR heats a hot beverage.
 
Dave Pyke and I collaborated on a FHIR Implementation Guide on how to brew a good hot beverage, following RFC-2324 from April 1st 1998 -- see the our "Hot Beverage FHIR Implementation Guide"




Tuesday, March 30, 2021

Elitism is Vaccine Credentials Passport

 A Vaccine Credential or Passport is an important effort to get society moving again, but it could really result in elitism that we really should not accept.

Vaccine Credentials fundamental use-case 

There are appropriate uses of a Vaccine Credential or Vaccine Passport. I am not arguing against proof of vaccine for International Air travel, or admission requirements for school or college. These have been in place and are working fine. They often are simply self-declarations, or are unprovable printed vaccine forms. These cases also are handled at a pace that allows for exceptions to be made. These are handled at a pace that allows for assistance to be given to achieve the proper vaccine levels. These are successful in spite of the fact that there is no world-wide self-validating Vaccine Credential. These will continue to succeed without a self-validating Vaccine Credential.

Vaccine Credential at scale need

COVID-19 has uncovered a "need" for a self-validating Vaccine Credential. That is a credential that can be used at point-of-entry, that carries TRUE/FALSE level facts, that can be proven to be valid / legitimate, and can be proven is linked to the subject identity.  This all without exposing unnecessary medical or identity facts - #Privacy.

This need comes from the scale, and not the fundamental use-case. As I state above the fundamental use-case is handled today, and that solution could absorb COVID-19 just fine. The fundamental use-case does not need to scale.

So, what is the scale problem? The scale problem is when the fundamental need is applied to ALL public and private gatherings. This includes Trains, Buss, Tram. This includes sporting events, entertainment events, political events. This includes dining, dancing, partying. This includes leisure, work, hotels. This scale applies to everything outside your house... well, it might apply at your own front door when others come visiting. So, you might be the bouncer-at-the-door.

The scale problem is the "bouncer-at-the-door" needs a very fast and accurate true / false fact to allow you into the event/facility; or to reject you.

Vaccine Credentials Considerations

What I am worried about is a technical solution becoming a tool to show elitism. This worry should not be used to prevent the technical solution from being created. I am actively involved in three different efforts to define a Vaccine Credential / Passport. I think it is important to design these solutions as best as possible. They need to address as many requirements as possible. They need to be privacy preserving. They need to work for those without technology. They need to be fast. They need to be robust. They need to be as resistant to falsification as possible.  I am actively engaged (wish I had more time).

What I am worried about is those that can't obtain the COVID-19 vaccine being shut out of participating in society without any ability to plea their case. I am specifically worried about society failing to get these people vaccinated, and the cases where the vaccine can't safely be given. These people are being treated as a lesser-class of people, they are not part of the elite class.

There are activities that are being proposed to requiring a Vaccine Credential to participate that are basic survival. Grocery store, Bus, and other. This is the scale that worries me the most.

Not the solution for vaccine deniers

I am not liking that people are not vaccinating. I certainly want everyone to get a vaccine. I got mine as soon as I could. I don't want to be in the presence of people who willingly refuse vaccine. I simply think that requiring a Vaccine Credential everywhere is not the way to get these people to get the COVID-19 vaccine.  These people will not react well to a Vaccine Credential mandate. These people will dig in harder. A Vaccine Credential is not the solution to vaccine deniers. Some will never be able to be convinced, they will always be a risk across society. Many simply need time to see the safety and effectiveness themselves. Some are needing information and access to the vaccine.

Some legitimate concerns

  • medical conditions that put the subject at risk (allergic reaction)
  • spouse or parent that objects to vaccines (subject would be endanger if vaccinated)
  • police (subject has reason to be arrested)
  • protected-identity (subject needs to stay non-identified. witness protection)
  • no identity available (subject has no formal identification due to age or events)

some reasonable worries

  • concerns with the safety given the "emergency use authorizations". This will eventually pass
  • access to vaccines. The young and healthy have not been allowed to get the vaccine. Some regions are struggling with getting the vaccine, or putting in place the facilities
  • outreach - there are people that have not yet understood the situation or the opportunity
I had a much more exhaustive list, but lost it... so please feel free to comment if you have some other legitimate concerns

Conclusion

I am pointing out a management problem, a problem that technology can't solve. I will continue to work on the technical solution. But I am very concerned about the elitism that will come from having the technical solution, and using it at the scale being proposed.

Thursday, March 11, 2021

Healthcare use of Identity level of assurance

There is discussion going on in the FHIR chat on this topic. I wanted to capture details as it seems that most of the problem is getting everyone understanding the same thing. The discussion is specific to an open system for recording and showing that an individual has received a COVID-19 immunization. (see HL7 effort on vaccination credentials and  broader outreach). There are other COVID-19 immunization trancing efforts, the above just is the one I am most closely working with.   

The summary is that there is likely good valid use for having a IAL like vocabulary to be used in Patient.meta.security to indicate to which level of assurance was this identity proofed. This because it is not uncommon to have some patients able to bring a government issued picture ID like a passport or REAL-ID, where other patients will not have this kind of an identifier, and other patients might have nothing, and others that are completely un-identifiable.

Where the use of an AAL vocabulary is theoretically useful as an attribute of the Immunization.subject binding to the Patient; but this is not as obviously needed. More realistic is that the whole of the Immunization resource (Immunization.meta.security) could hold an integrity confidence value. But event that is not likely to be needed as the system likely has a required assurance needed before ever giving an immunization and thus there is not a need to indicate the assurance as all records will be at the same level by policy.

Basics of Assurance Levels

There are two concepts that are very important and important to understand. I will use NIST 800-63, but the overall use-case is not a USA specific thing. The use of NIST here is simply because the discussion was USA specific, and the NIST specification are easily accessible. I welcome someone providing me the ISO equivalent, but ISO is too expensive and hard to access.:

Note I am not going to address FAL, thus the key concepts are IAL and AAL.

Wrong but useful

Very important to recognize that NIST 800-63 is focused on Remote connection using IT technologies. Where as much of what I am going to address in healthcare is not exactly only scoped to this. However the use of the Vaccine Credential is a remote access use, but in that use-case we are focused on data assurance levels, not user assurance levels. So there is dissonance, but it is the best I have to use as a model.... as George Box said, All models are wrong, but some are useful.

IAL is broken down into three conceptually defined levels 

  • IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such (including attributes a Credential Service Provider, or CSP, asserts to an RP).
  • IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
  • IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

AAL is broken down into three conceptually defined levels

  • AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
  • AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
  • AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

Note that NIST only defines these conceptually. NIST does not define them tighter as the tighter definitions would need to be cast within a Policy, Procedure, and Technical space. The Levels are useful, but they are not explicit. This is most easy seen with the AAL definitions.

The NIST 800-63 specification is very easy to read, and understanding of the distinction between IAL, AAL, and FAL are very important. Please do not continue without understanding the distinction between IAL and AAL.

Use of Assurance Levels in healthcare workflow

The use-case that I will use for illustration here is a standalone system that is recording COVID-19 immunizations. I am not going to say that this is a good use-case, but it helps focus on the impact of IAL and AAL. So in this use-case there are three important activities.
  1. getting the Patient identification information.
  2. recording the immunization that was given to the patient
  3. relying-party using the immunization credential to allow the patient to do something
Note that there is other steps and considerations that I am not covering: medical, safety, procedural, cleanliness, etc. So, yes I presume that the patient will be asked about allergies, that the immunization site will be cleaned, etc... 

Step 1: getting the Patient identification information:

In step 1, there will be some Patient identification information captured. I am also not addressing the process of looking up the patient to see if they exist already, vs creating a new, vs resolving duplicates, etc... that is important, but I am focusing on specifically how SURE is the system that the human present is the one described by the Patient resource that will be used in step 2. So some data are requested of the Patient, some process is used to confirm that the identifications presented are valid and appear to be the patient. Likely the Patient is physically present, and that some government issued picture identification is provided. Thus, it is not hard to have a procedure that gets to IAL3, but some patients might not have a government picture identification. Thus the need to record "to which level of assurance was the patient proofed at the time the Patient resource was created or selected?"

An IAL is a statement of this "proofing" level of assurance. This level is persistent statement. Meaning the next day the FACT of this IAL is still true. Because the IAL is a proofing of identity.  Note that step one could have been done ahead of time, via online portal or phone or other methods. 

Step 2: recording the immunization that was given to the patient:

In step 2 is specific to some activity, such as administering the vaccine. For example, the step 1 proofing might have been done the prior hour, the prior day, or the prior month. But Step 2 is needed to be done at the time the vaccine is being administered. 

Note that some argument that NIST 800-63 is focused on IT concepts, and not physical acts. However I think that it is not specifically focused on IT activities. Certainly it is used mostly regarding IT concepts. There is certainly some application of AAL to physical access (door locks), and in this immunization an activity.

So when the vaccine is administered there are many other things going on other than Authenticating the patient. Indeed in medicine there is a concept of "The Five Rights". One of the Five is to confirm that you have the "Right Patient", which is a step to make sure you are not giving a medication (vaccine) to the wrong patient. Typically this process step is the nurse looking at the wrist ID band. However the step is done, this is an "Authentication" step. Thus the question of how sure are you that you have the right patient?

This making sure you have the Right Patient at this activity of giving an immunization is based on the strength of the identity of the patient. So it is true that step 2 is based on step 1.

Step 3: relying-party using the immunization credential to allow the patient to do something

Step 3 is unusual to talk about in healthcare, but is ultimately the goal of an immunization credential. The whole purpose of this is to enable the patient to carry on life as normal because they have evidence that they are free from infection. Above I am only addressing the case where a vaccine has been given, but the overall also includes some means for lab test results as well.

So at this point the relying party might need a light-weight or moderate-assurance; as the event is a family event or an event where risk is low; but the relying party might be needing a very high assurance such as an international flight. The relying party does need additional security mechanism to prove that they are authorized to get the patients immunization credentials, and also that the results only go for that purpose. I am not addressing these classic security topics. They are significant, just not on the topic of this article.

The relying party would like a clear and simple result. Thus they don't want to get complex listing of the methods used to provision or authenticate the patient; they want a simple YES or NO. Thus they need a value similar to the three IAL values. 

Some relying parties might want to know the methods used, so it might not hurt to also have a second vector recorded which is the method used.

The relying-party is very unlikely to care about the step 2 assurance at each immunization. Not because it isn't important, but because it is less important overall.

IAL of the Patient Resource.

Both step 1 and 2 are important to step 3. overall. The question is if they both must be recorded in the FHIR resources.. I had given the example of (2) being part of the process behind the Five Rights. If your procedure is strict, then recording that you followed the procedure with a (2) kind of record is not needed. The same can be said for (1), for example if a Patient Registry requires that the patient was highly proofed before they were given a Patient record, then the Patient resource does not need a (1).

So it is important to understand which of these is going to be variable within your data. If you know that (1) is going to vary within your data, then you need a way to record which value of (1) each Patient resource has been proofed at. If you know that (2) is going to vary within your data, then you need a way to record the (2) for each reference.

Step 1 can be handled with the Patient.meta.security with a valueSet of IAL vocabulary. This seems appropriate as it is "meta" about the contents of the "Patient" resource. The vocabulary is unclear, but the concept is clear. An IG specific vocabulary (which the vaccine-credentials project seems to be doing) seems reasonable.

AAL of the link between Immunization and Patient

Seems that if 2 is variable, then this needs an extension on the Immunization.patient element to indicate the AAL of the patient binding to the Immunization activity. This would need a different vocabulary, as AAL is different from IAL. (Even though NIST 800-63 uses numbers for both).

Further (2) is not security meta about the content of the Immunization.patient element; it is specifically an AAL of the linkage confidence. Thus this is not a general extension carrying .meta.security at the element level (which is a task that DS4P is likely to add). The AAL need is different.

General method of recording confidence of References

This (2) might be first needed in this Immunization use-case, but one could see that this is generalizable such that any Reference anywhere in FHIR might need some evaluation of level of assurance that the reference value given is absolutely correct.  Further in FHIR a reference is a technical term referring to Reference datatype, but the concept of a reference also includes all uses of the Identifier datatype (which is included in the Reference but sometimes stands alone). So the concept is needed on both Reference and Identifier datatype.

We surely expect that any Reference in FHIR is always highly sure, we all know mistakes happen. We all know that sometimes an Identifier is recorded without high assurance, like the Patient brought in a photocopy of their passport.  What is not clear is if there is a true generalized need for the FHIR DataType Identifier/Reference to add a core extension for tracking the confidence of the reference values.  This might be a useful exercise, and as an extension would not be too invasive.

Conclusion

So, now that I have elaborated about the need for (1) and (2) theoretically... which ones are actually needed in the vaccine use-case, and which ones might be more generally needed? These both seem unusual to be needed as values, vs simply being baked into procedure/policy.

The IAL at the Patient level seems realistically needed, given that some individuals already have high assurance identifiers such as Passport or Real-ID that can be used during provisioning of the Patient resource; where as clearly other patients will not have this, and realistically there are others that will have nothing to base the identity proofing activity upon.. So Patient.meta.security does seem useful.

Where as the AAL of the binding between Immunization and the Patient seems more theoretical, and the use of "The Five Rights" tend to elevate the confidence to a high level. Thus it seems this is mostly theoretical, thus not urgently needed. This is not to say it isn't ever going to be needed. Just not the main focus need today.

With IAL on Patient; there seems to be a need for two evaluation vectors. A policy vector much like IAL from NIST, this policy vector states a conclusion made at the time the activity happened. This IAL like value would consider policy, procedures, technology, evidence, etc... A second vector would be more concrete, there should be a valueset of codes that identify current-practices. This vector on the Patient would support the IAL value, but would also allow a relying-party to more dynamically adjust their reliance on the assurance level. 

Tuesday, March 9, 2021

IHE is on #FHIR

 This was just reported in an IHE-Europe news letter. I wanted to stress it here as I am finding many people do not understand that IHE has many Implementation Guides (IHE-Profiles) that leverage FHIR. IHE has published 32 Implementation Guides that use FHIR.

There is very active implementation and testing of these at IHE-Connectathons. This graphic brings the message home


And yet, that graphic is representative of the IHE-Europe Connectathon. Last week was the IHE-USA Connectathon, so this grows even more. Here are my other FHIR articles.



Wednesday, March 3, 2021

Why use current Exchange infrastructure rather than starting over?

I proposed an agile approach to improving Healthcare Information Exchange. Why should we keep the current? I covered this mostly with simply "that it is functioning", but did not enumerate why this is such a big deal. Many will say that http RESTful is functioning on a global basis with Google, Facebook, LinkedIn, Wiki, and Blogs. This is true, but these are all monolithic servers. Healthcare is a mass of 10 thousand organizations all with different systems. So Healthcare is special. This does not diminish the benefits of http REST, just points out that Healthcare is building on-top of an important concept, but that important concept has not addressed many of the things that Healthcare has needed to to give us the Nationwide Health Exchanges that we have.
The following already exists and is functioning nation wide today. These should be leveraged going forward, not ignored and re-invented.
  • Federated infrastructure 
    • technology, 
    • domain name, 
    • directory of endpoints
  • Trust agreements  
    • legal policy language
    • evaluation of language, 
    • implementation in access rules
    • policy bridging
  • Trust infrastructure technologies 
    • Certificate Authorities
    • Revocation system
    • Proven change of CA methods
  • Identity of organizations 
    • Directory, and 
    • TLS connection authentication
    • SAML assertion mechanism
  • Identity of initiating user 
    • Directory, and 
    • SAML assertion mechanism
  • Purpose of use 
    • vocabulary, 
    • mapping to policy, and 
    • SAML assertion mechanism
  • Provenance 
    • Home Community ID
    • Registry/Repository IDs
    • SubmissionSet, DocumentEntry, and Folders - Metadata
    • CDA Content specifications
  • Patient identity discovery and management 
    • XCPD mechanism, 
    • policy on minimal elements, 
    • acceptance criteria for cross-reference match
  • Patient Privacy Consent and Authorization 
    • normal treatment use, 
    • point-of-care-Consent, 
    • access authorizations
  • Notification of patient movements 
    • XCPD, or 
    • PIX feed
  • Data content agnostic
    • supports historic data that might only be available as scanned document
    • supports CDA, CCD, C-CDA, 
    • supports FHIR
    • supports HL7 v2 like lab results
    • supports Imaging like DICOM, XDS-I, and other image formats
    • supports text formats like BlueButton
    • supports non standard such as coma-separated-values (CSV) 
    • supports future standards
  • Timeframe of service 
    • document metadata, and 
    • query parameters
  • Data integrity and signatures 
    • hash/size, 
    • transport (TLS), 
    • Document Digital Signatures
  • Static and dynamic data 
    • Static, 
    • On-Demand, and 
    • Delayed-Assembly
  • Audit logging and remediation 
    • ATNA, 
    • log characteristics, 
    • policy for incident investigation
  • Proven system for Emergency response
    • Edge system that can be deployed to natural disasters such has been seen in CA and TX
  • ValueSets and Vocabulary agreed to by the community
    • types of documents
    • types of locations
  • Various Participating Organizations
    • Major Vendors
    • Treatment Organizations
    • Regional HIE
    • Payer Organizations
    • CMS
    • Research
  • IHE-Connectathon - mature testing for the Document Sharing exchange 
    • test tool based testing
    • peer-to-peer testing
    • formal test plans/procedures
    • formal test results tracking
  • Standards deployed and in use globally
    • existing networks globally communicate likely close to a billion documents each month
    • Not just a USA effort
    • maturity benefits everyone

Are all of these perfect? No, but the infrastructure includes them, meaning they are ready to be used, rather than some future hope. 

Does that mean we don't move to nationwide http RESTful FHIR? No, we will get there. I expect, as I have said before, that the green-fields will/should use http RESTful FHIR. But this should not be a default choice, this choice should be based on evaluating the "best" solution. 

My main concern is that we are trying to apply http RESTful FHIR to the hardest problem (Treatment, Payment, and Operations) when we already have a solution there.  The use of http RESTful FHIR at the edges or point-to-point make good sense. But it is not logical to start with federated access to 10,000 organizations, while those organizations already have a network-of-networks.

I don't explain these in this article, but you likely will find that I have explained them in my other articles and the HIE-Whitepaper. That said, I am happy to have my comments challenged, or reinforced. So comments welcome.

Tuesday, March 2, 2021

COVID-19 Immunization Summary Document - use-case analysis

 I am noticing that the healthcare standards community are doing a good job of leveraging the standards we have, vs creating something new... BUT I think the COVID-19 vaccine use-case is significantly different in a very important way.

I have not been engaged in any specific project, but know of many. So it is possible that some of them are thinking about the point I bring up here.

I am hearing some promote that the International Patient Summary (IPS) should be used for the proof that individuals would present to show that they have received COVID-19 vaccine.  It is very true that this document does include a Immunizations Section. It is good that the Interop standards community wants to use standards. 


The purposeOfUse threat environment

BUT, the IPS is designed to support "Treatment" purposeOfUse. When the request is coming from a Treatment organization, or some organization that is authorized for Treatment purposeOfUse; then the full IPS is the right solution.

However when the need is for getting physical access to an event, or to Fly, or take a Train, or etc.. These are not Treatment purposeOfUse. The are to support Public Health (PUBHLTH), or a new purposeOfUse value that is not today in the vocabulary.  

So, when the purposeOfUse is public health, then it is inappropriate to expose anything other than what is minimally necessary for that public health use. So IPS can not have the required Medication Summary, Allergens and Intolerances, or the Problem List. These are not appropriate to expose to the kinds of people that the COVID-19 vaccine proof audience. The recommended and optional sections should also not be populated. I might even suggest that the Header information should also be degraded as much as possible.

The Content Profile

Although the IPS has what is needed, it has too much. We can leverage what it does have, but likely need to further constrain too:

* Composition should include only elements needed by this PurposeOfUse. Likely just the government issued identifier.

* Only one section for Immunizations -- use the Immunization profile found in the IPS implementation guide.

* Only Immunizations that are relevant to COVID-19 (some valueSet can express this subset)

* might further constraints be needed on the Immunization to eliminate privacy risk?

Lets call this the "COVID-19-Immunization-Summary-Document" (C19ISD)

YES, it is a "D" Document. Even though we have degraded the Composition, there is likely information there that is important... and...(see next section)

Digital Signature

The Document would be covered by the IHE specification for Document Digital Signature. Thus the digital signature is covering the header and immunization details. This is why the Document is a Document.

The Transport

There should be no surprise that I will recommend that the Document Sharing solution be used for Transport. But there is important profiling here too.

* Trust-Framework -- there is still a need for a trust framework. It is simply not the same as we use for Treatment. It is designed the same, and uses the same standards. It is just much broader. It would leverage organizations like airline industry, event planning industry, etc. The reason to get into the Trust-Framework might be easier, but is still needed.

* Digital-Signature support. There would need to be a Certificate Authority issuing certificates for Digital-Signatures. This would be a subset of organizations, those that are authorized to publish these COVID-19-Immunization-Summry-Documents (C19ISD). There should be infrastructure to support certificate revocation checking. And would be a good idea to have a service that can check the digital signature and just return success/failure./

* All authorized access would be based around Public Health purposeOfUse.

* All accesses will be logged, so that abuse can be investigated

* Patient lookup should only be by government issued identifier. No ability to lookup by name, phone number, etc... Not sure what the actual constraints are, but want to start constrained.

* Given a patient identity, the Document Sharing query would be for the latest IPS. Yes, I said you would ask for the latest IPS. BUT because your purposeOfUse is Public Health; you will get the degraded COVID-19-Immunization-Summary-Document

* Note that the DocumentEntry (DocumentReference) would be marked with security labels indicating the appropriate PurposeOfUse of Public Health, and the confidentiality of  Moderate

Advanced use of Document Sharing Associations

Not critical, but simply good to think about.... In Document Sharing there are "Associations" between various Document Entries. These are different kinds of links. If we consider that this COVID-19-Immunization-Summary-Document (C19ISD)  is a degraded International Patient Summary (IPS); and the Document Registry service can support request for PurposeOfUse of Public Health and also Treatment; then there could be a Document Entry for the full fidelity IPS with a "Transforms" association link to the C19ISD document. Then the system need only look at what they are authorized to receive in order to give them the full IPS or the C19ISD.

UPDATE

It was pointed out to me that this C19ISD might also need to have a constrained lab-results section for COVID-19 lab results that might indicate COVID-19 negative.