Two new IHE Profiles on #FHIR - Provider Directory and File Management

Public Comment opens for Provider Directory and File Manager --- both using FHIR STU3

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from May 17 through June 16, 2017: Mobile Care Services Discovery (mCSD) Non-patient File Sharing (NPFS) The documents are available for download at http://ihe.net/Public_Comment. Comments submitted by June 16, 2017 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at IT Infrastructure Public Comments.

FHIR OAuth scope proposal using FHIR query parameters

In FHIR STU3 there are now some common query parameters. I propose that these common query parameters can be used to advance the OAuth scopes that are defined today. The current SMART scopes are based on simple vectors:

1. Patient vs 'user' -- 
1. Where a scope of 'patient' means all results must be from that one patient
2. Where scope of 'user' means all results are relative to that user rights to data
2. fhir-resource --
1. Where a FHIR Resource named will limit results to only that Resource type
2. This is a valueset of fixed strings (e.g. "Observation", etc)
3. REST operation

Expressed in EBNF notation, the clinical scope syntax is:

clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )

To understand the current OAuth scope see a few other articles:

• SMART specification - Scopes and Launch Context
• David Hay - SMART - Scopes and Profiles
• My - alternatives to SMART scopes - FHIR Scopes
• My - Healthcare access control scope constraints on OAuth tokens

So, if the OAuth authority authorizes the user to access the patient requested, as defined in the launch context, for only Observations, and only read operations. This would be a scope of

patient/Observation.read

A problem with this is that the actual identifier of the "Patient" is undefined. For SMART this is handled by the 'launch context'.

Propose using common "patient" query parameter for patient scope

With the new FHIR STU3 common shared query parameters, we could identify the specific patient within the Scope. There is a common query parameter for "patient" against 35 different Resources. This has an advantage to be specific, but has a disadvantage that the scopes are not made up of static strings. I would like to suggest that this use of shared query parameters would be a replacement form the first part of the SMART scopes.

So, rather than relying on the SMART launch context to hold the patient identifier. The example with a patient of 'http://myserver.example/fhir/Patient/f5c7395'

patient="http://myserver.example/fhir/Patient/f5c7395"/Observation.read

or, we could add it to the end.  I think this more powerful.

Observation.read#patient="http://myserver.example/fhir/Patient/f5c7395"

Which is 

clinical-scope ::= ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' ) '#' ( query | '*')

I a proposing this without working out all the issues. I just want the scope to include the patient. 

Scope is Not Query parameters

This is NOT a proposal to force these query parameters and trust server search capability. This might be one thing done to make it efficient, but won't work perfectly as not all. The use of search parameters will just help with positive matches; but will not be perfect against false-positives or false-negatives. It will also fail when the other parts of the query are creatively authored to cause the wrong thing to happen.

The scope does need to be ENFORCED. The Resource server is expected to enforce the scope without fail. This is what I mean by more than just query. Most important is inspecting the resulting Bundle to assure that no content is contained in the Bundle that doesn't fit within the Scope.

More common query parameters

Some of the other common search parameters that might be useful:

• _id -- when the scope is restricted to exactly ONE resource
• _tag -- when the scope is restricted generally to some tag
• _profile -- when the scope is restricted to some specific _profile tag
• _security -- when the scope is restricted to some vocabulary from the HCS (e.g. confidentiality of "N" normal)
• encounter -- when the scope is restricted to a specified encounter

Clearly missing but needed

There are some important vectors in Privacy space that are missing:

• Timeframe for when the data was created - used to hide timeframe or enable a timeframe
• Authored by - used when policy allows only data authored by some org or user

Note, scope is not everything. Where the user is forbidden, they get no authorization at all.

Also, I don't propose how to use negative scopes. Such as this user (Provider) can see any data but not patient Mary.

Not Done Yet

This is not a final solution. I am just putting this out there for discussion. Simply to bring up options for discussion on how to make improvements to Scope. The unfortunate facts of healthcare is that the needs for scope is a complex of multiple vectors; and failure is severe when not appropriately protected or when not appropriately available. Both false positive and false negative can have severe effects.

See my other FHIR articles

IHE ITI on FHIR

IHE ITI has a set of profiles on FHIR existing in Trial Implementation today. These were written against FHIR DSTU2. These have been updated to STU3, now in ballot for members of the ITI Technical Committee to comment and vote on.  Details and access to the ballot drafts of these documents is available from the ballot.

• Mobile access to Health Documents (MHD) 
• DocumentReference, DocumentManifest, List, Patient, Practitioner, Binary, OperationOutcome, Bundle
• Using FHIR FMM 1-5
• Also added some options to recognize XDS-on-FHIR
• Mobile Alert Communication Management (mACM)
• CommunicationRequest, Communication, OperationOutcome, Bundle
• Using FHIR FMM 2-5
• Patient Demographics Query for Mobile (PDQm)
• Patient, OperationOutcome, Bundle
• Using FHIR FMM 5
• Patient Identifier Cross-Reference for Mobile (PIXm)
• operations, Parameters, OperationOutcome, Bundle
• Using FHIR FMM 5
• Add RESTful Query to ATNA
• AuditEvent, OperationOutcome, Bundle
• Using FHIR FMM 3-5
• Appendix Z on HL7 FHIR
• Various reusable guidance and specification
• Mobile Security Considerations

The IHE ITI Technical Committee is also working on new profiles using FHIR. These will be further discussed in later articles.

• Mobile Care Services Discovery (mCSD)
• Including Healthcare Provider Directory (HPD) capability
• Organization, Location, Practitioner, PractitionerRole,  HealthcareServices, Binary, OperationOutcome, Bundle
• Non-Patient File Sharing (NPFS)
• Sharing and Management of Files that are not associated with a patient
• For example: Stylesheets, configuration, policy definitions, workflow definitions
• DocumentReference, Binary, OperationOutcome, Bundle
• Access to Document-extracted Data-elements (ADD) 
• Formerly: Patient Centric Element Location
• This is a profile that combines XDS/MHD and QEDm to describe how a Document Sharing environment can provide more fine grain access (Resource) to data shared as documents. 
• This profile does rely on creative systems engineering to decompose the documents into the FHIR resources. This might leverage CDA-on-FHIR, or some other methodology. This methodology is not specified.
• What is specified is that the fine grain details must have Provenance pointing at the Documents from which the data came. This enables a consumer to retrieve using XDS or MHD the document from which the fine grain details came from.

The IHE ITI and PCC are working jointly on one as well:

• Query or Existing Data for mobile (QEDm)
• supporting Resource level access such as allergies, problems, medications, etc
• Observation;  AllergyIntolerance;  Condition (Problem);  Procedure;  Encounter;  DiagnosticReport;  MedicationRequest;  MedicationStatement;  Medication;  Immunization
• Provenance, OperationOutcome, Bundle

IHE ITI is also working on one non FHIR Profile

• Remove Metadata and Document (RMD)
• This is a profile on XDS for administrative ability to remove metadata entries and remove documents

Lastly IHE Document Digital Signature (DSG) Profile approved for Final Text

IHE Document Digital Signature (DSG) Profile approved for Final Text

Today the IHE ITI Technical and Planning committees approved the Document Digital Signature (DSG) Profile be moved into Final Text. This Document Profile defines a way to support Digital Signatures, including when those Documents are managed in a Document Sharing infrastructure. This DSG Profile is referenced in many places where adding a Digital Signature to a document would be beneficial, such as Consent, Legal Evidence, etc.

There is more interest in digital signatures driven by some Anti-Fraud use-cases. I think there will be more interest driven by Patient Authored content.

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.

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).

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.

DSG supports:

1. An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
2. A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing “SIGNS” relationship provide linkage.
3. A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing “SIGNS” relationship may be used but is not required.

The digital signature standard is XML-Signature using XAdES-L-T profile, 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.

Other Digital Signature Blog Posts

• IHE - Privacy and Security Profiles - Document Digital Signature
• Signing CDA Documents
• Using both Document Encryption and Document Signature
• Non-Repudiation is a very old art --- the story behind the picture which is of a signature on a receipt for goods.

Reflecting FHIR FMM in IHE Profiles

IHE is creating many Profiles using FHIR. Given that FHIR is still "Standard for Trial Use" (STU), and thus there is a "Maturity" concern. This maturity concern is communicated in FHIR STU3 through a "FHIR Maturity Model" (FMM) evaluation number on each Resource and other parts. These FMM number indicate to the FHIR audience a stability and readiness for use. This is an important communication tool.

I am proposing within IHE that they reflect these FMM to the cover page of the IHE Profile so that the reader of the IHE Profile supplement understands the stability and readiness for use evaluation.

These FMM evaluations are only a construct for the STU and "Trial Implementation" phases. The FHIR Resources used must go to Normative, before the IHE Profile can go "Final Text".

So for example PDQm is based on Bundle, OperationOutcome, and Patient. All of which are at FMM level 5. So the title page of PDQm looks like:

Where as MHD is based on a broader set of  FHIR STU3 defined resources --  DocumentReference 3, DocumentManifest 2, List 1, Patient 5, Practitioner 3, OperationOutcome 5, and Bundle 5. FHIR Maturity Level (FMM) range 1-5

These updates to the IHE profiles will soon be seen in a CP ballot, and then published on the IHE web site. Right now they are being worked by the ITI workgroup.

FHIR Security model is enterprise centric

NO! This is a false understanding. FHIR has no security model. And this is a good thing.

FHIR is designed first and most important as a data model with a few expected interaction models (REST, Messaging, Document). There is expectation that many security models exist, and application of those security models does not impact the most important priority of getting the data model correct. This is especially exercised with REST, but is not limited to REST. REST is just used as a most likely first interaction model, and one that is understood to drive for a good transport agnostic data model.

There are many workgroups working on specifications for how to apply OAuth to FHIR REST, but these are not fundamental to FHIR, they are alternatives. There are various variations of OAuth as well, those that might be more Patient centric, those that might be more enterprise centric, and those that might be cross-enterprise centric. There are work on OAuth scopes. There are others that are working on pure mutual-authenticated-TLS for organization to organization. There are others looking toward SOAP. There are others applying security to the packaging so that it can travel by many transports with end-to-end security. Others are looking to smart-contracts in blockchain. Others just focused on enabling Privacy. Others tagging data so that rules can be applied. All enabled by the very fact that FHIR is not bound to one security model. This is an important fact.

I am sorry that it seem to FHIR is bound to an enterprise OAuth security model. I suspect this impression comes from the most visible project -- SMART-on-FHIR... which is enterprise centric. SMART-on-FHIR is a fantastic project, very important, and the one that really has the necessary engagement to 'make it real'. That said, these other projects are also doing good work. Not all projects have, or could have, the marketing power that SMART has... 

FHIR has many security models, while having none. 

See all my articles on FHIR.

Stop using OPT-IN and OPT-OUT

In various conversations on Consent, including #FHIR Consent, discussions often get mixed-up because we use the terms "OPT-IN" and "OPT-OUT". These terms are trouble. We need to stop using “OPT-IN” and “OPT-OUT”.

I want to propose a set of terms. I will never get everyone to stop using opt-in and opt-out, but where better terms can be used, I propose better terms. Better, as in, more descriptive and accurate communications.

The reason is that these terms can mean very different things based on what the person listening is thinking. They can mean a consent ‘model’ or they can mean a consent ‘state’ or they can mean an 'action' by the patient. Especially confusing because there is a possibility for all thee to be the same and not the same.

State Model --

In this model we look to consent as a state-diagram, also called a finite-state-machine, or a directed-graph. In a state-diagram is made up of a finite number of 'states' diagrammed as circles, with arrows indicating events that can occur.  A state-transition-table, and uml representations can also be used.

At the most gross level of Privacy Consent we recognize that there is a 'state' where data is shared, for legitimate medical treatment purposes, with trusted partners, who are authorized by their licensing and role. And another state where data is NOT shared, except for legitimate and authorized medical emergency...

Note I am defining a Treatment purpose of use, setting parameter that indicate that the sharing would be for legitimate and authorize purposes. This is to counter distracting arguments, distracting from my point. Insert any caveats necessary, and there is still an understanding of OPT-IN and OPT-OUT as a state of consent.

as a State:

• OPT-IN state – Permitted to sharing the patient's data for Treatment purpose
• OPT-OUT state – Denied to share the patient's data for Treatment purpose

I think this is better said using the terms Permit and Deny

Event Model

This might also be called the 'action'.  It is often predominately determined by regulation. 

Some view OPT-OUT as a model where absent an indication from the Patient, their data can be used. This is to say that the patient must OPT-OUT if they don't want their data shared.

Some view OPT-IN model as one where absent an indication from the Patient, their data can not be used.

You will note that this model uses terms that are also aligned with the 'first action' that a patient can do.

I think this is better represented by the "event" or "action" of the patient giving authorization, that is to "Authorize"; or the patient revoking that authorization, that is to "Revoke".

First state

This perspective uses the term to define the starting point, as the state.

• opt-in environment, the patient is automatically put into opt-in state. 

That is improper definition, as it uses the term to define the term. So I will re-write it using the "Permit" state term

• opt-in environment, the patient is automatically put into Permit state. 

This perspective is important to understand, but does not help with any clarity. As once the patient has made that first action then the distinction is not valuable. That is to say, the second or third or fourth action just confuse the perspective.

I propose we use:

States (Leveraging these terms as used in XACML):

• Permit – a ‘state’ data is shared 
• Deny - a ‘state’ of NOT sharing 

Model - Initial State

• Implied-Consent – A ‘model’ where without a consent the patient data sharing is Permitted.
• Start in Permit state
• Explicit-Consent – A ‘model’ where without a consent the patient data sharing is Denied
• Start in Deny state

The Initial State is usually driven by regulation. Such as Such as HIPAA, which is a model where patient data is allowed to be used for Treatment, Payment, and Operations without getting a consent from the patient.  It is common for HIPAA to be called an Implied-Consent environment, for the patient has implied their consent by seeking treatment.

Where as EU has as an Explicit-Consent dominant model. That is that no action on data without consent from the individual that data is about.

Explicit-Consent is also common with sensitive topics, that are considered more sensitive than normal health topics. Likely due to stigma. These topics are often held to an Explicit Consent model, even where normal health topics follow Implied Consent.

Also some regions, or even organisations simply choose to use an Explicit-Consent model for various reasons. Explicit-Consent can be seen as more Privacy Principled, but can also impede progress that might be 'implied'

I propose a set of terms, while not defining terms for the 'actions'. This because the actions are what tends to be very realm specific. Some environments allow a verbal consent, others allow a web-form checkbox, others require digital signatures, others have very specific language, others have special technology, others allow for delegation and assignee, etc. So the actions, or 'state transitions' are much harder to agree upon.

And, there are certainly more states...

Updated: 4/6/2017 to include recommended "Event" description and diagram