Wednesday, September 21, 2022

Security Labeling Service

Data may be “Normal” medical data or “Restricted” medical data. The distinction is for this IG focused purely on data classification for sensitive topics.

The various clinical Resources in FHIR are very complex and highly variable. Although Observation is the most often used Resource, sensitive data may exist in ANY other FHIR resource including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitivity classification and placing that assessment into a well-known location found in all FHIR Resources -, the Access Control does not need to be aware of the kind of FHIR Resource, it can just process the data as a DomainResource and simply look at the element.

The classification of data into sensitive topcs is the role of the Security Labeling Service (SLS). The SLS inspects the data, and may use the context of the data to identify the sensitivity classification. It is expected that most data will not be considered sensitive, aka “Normal”.

Data tagging Considerations

Some data are direct and clearly in a sensitive category. But there can be indirect relationships, such as three medications prescribed together are a clear indication of a sensitive category but are not individually.

Some data may also not be sensitive in the coding, but rather sensitive in the narrative, this would be poor data quality but it is a reality that should be considered. Thus an SLS may need to include some Natural Language Processing to find sensitive human words in narrative.

Some approaches use well-defined ValueSets, where others use a list of words. The list of words can be search across the data without regard for the data structure, which has the benefit of not needing to have the SLS data schema aware. The list of words can be codes, such as snomed numeric codes.

Architecture approaches to data tagging

When the SLS is executed is a systems design decision. General alternatives are:

Pre Tagging data

Tagging the data as it is created, updated, or imported.

Pre categorize data within the EHR databaseEHRSLSBatch/New/Updatetagged results

Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitivity tag.

Query/Use enforcement based on pre-calculated SLSEHRAppACEQueriestagged resultsenforce rules

This solution is likely to be more performant on use of data, but may not have as accurate sensitivity tags due to the dynamic nature of policies around sensitivity, and dynamic nature of data relationships. This solution also requires that the EHR database support data tags.
Use time tagging data

Alternative is that the data are temporarily tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement

Real-Time sensitivty classification at Use/Query/ExportEHRSLSAppACEQueries/Uses/ExportQuery resultstagged resultsenforce rules

This solution does not require that the EHR database be updated to support tagging of data, but may incur a performance impact on data use.

Example ValueSets

One way to understand a very basic SLS is that it looks for clinical codes in the data. It might do this using ValueSets, but likely would need to do this in a more performing way.

There are some valueSets that were authored 9 years ago by SAMSA (requires a free login to see the details). This was during a critical point in the early development of the use of Security Labeling. These valueSets are old, but they are informative. Any standards based managed ValueSet would need to be used as input to a organizational use in an SLS. So the fact these are 9 years old is not as important as that they are a well informed base to start with. I have put the SAMSA valuesets into some ValueSets of my own. 

Tuesday, September 13, 2022

MHD Document Responder: patient.identifier chaining

This is a quick article on a requirement of the MHD Document Responder that may be less obvious to some. The specific requirement is related to chained search parameters, like `patient.identifier`;  `source.given` and ``; and `author.given` and ``. These search parameters have a `.` that indicates that one is to search deeper, aka chaining the search value to a different kind of resource and use the results in the primary search.

The requirement is hinted at being special with a mention of FHIR Chaining Parameters:

This use of patient.identifier follows the FHIR Chaining Parameters search methodology.

But these hints might not be enough, because they do not tell you how to solve the requirement, and this is because there are many ways to solve this, and the implementation details of your system are more important than any factor.

The hints just indicate that the parameter provided is to be matched in a chained way. For example with patient.identifier the parameter is an identifier that should be first looked up with the Patient Identity Manager to find the Patient resource that is then used to find the DocumentReference resources.

That hint tells the Document Responder, that when the Document Source chooses to use `patient.identifier` rather than `patient`; that the Document Source is expecting the Document Responder to do this lookup, rather than the Document Source to do that very same lookup. So, it seems reasonable that queries using chained search parameters might be slower than those that are not.

There are cases where this is inverted, such as when the MHD has an XDS or XCA backend; in these cases the use of patient.identifier that is from the Affinity Domain or Community is better than providing the Patient link. As when a Patient link is the search parameter then a MHD front end to XDS or XCA would need to convert the patient link into the Affinity Domain or Community. This case is likely to be a system such that the Document Responder can quickly do this lookup.

Another place where patient.identifier is going to be preferred are environments that have a national patient identifier. In these cases the national patient identifier is more readily available to both Document Consumer and Document Responder. In these cases it is possible that the DocumentReference.subject element could hold both the Patient id link and the national patient identifier.

The chaining of given name and last name are similar but different in how one must support them on the Document Responder given the system design you have.

Monday, August 22, 2022

eConsent standards

 As with any standard, one more is clearly needed. 

as to the different Consent Standards.. I likely don't know about all of them, but here are some. I am also not indicating that there should be no improvement or even new standards. I just don't want historic lessons-learned to be lost.

for use in Document Sharing exchanges like XDS/XCA/XDR/XDM/MHD/MHDS
This fall I hope to get a FHIR Consent - basic patient privacy project going.

There is an orchestration of various things referred to as Point-of-Care, which is an interaction model using BPPC and XUA -
- this is part of CareQuality, and is built into Epic's CareEverywhere

The FHIR Consent - FHIR Consent is rich to be profiled. 

There are some projects that claim to be profiling Consent, but they are not yet published.

There is work in FHIR to add a Permission Resource. This would possibly be used by Consent in the future, but that future is likely 5 years out -

There is also the OpenID - UMA - HEART -

There is a broader (beyond healthcare) project in Kantara to support a Consent Receipt

surely I missed something? Please comment or email me.

Saturday, August 13, 2022

IHE IT-Infrastructure Summer 2022

 Four publications released from IHE IT-Infrastructure, three in development:

  • Release for Public-Comment -- Sharing of Valuesets, Codes, and Maps (SVCM) -- This is now published in Implementation Guide format, previously in PDF supplement format. This IHE-Profile (aka Implementation Guide) provides guidance on how to implement the sharing of terminology ValueSets, CodeSystems, and ConceptMaps. It is not a full Terminology Service, just the basic starting point that can be used to get a Community aligned.
  • Release for Public-Commet -- Secure Retrieve (SeR) -- This is now a html publication, previously in PDF format. In addition to the conversion, the scope of the Access Control Decision and Enforcement is expanded beyond the Document Repository to the other services in a Health Information Exchange -- Community. 
  • Release to Trial-Implementation -- Patient Master Identity Registry (PMIR) -- This is newly converted to Implementation Guide format, previously in PDF supplement format. The release recognizes the reconciliation of public comment. This IHE-Profile (aka Implementation Guide) provides for a Health Information Exchange Community to cooperate on a golden (master) identity for the Patients. This is distinct from a PIXm, which is a Community cooperation on cross-references of many identities for each patient. The PMIR does not forbid local participants from having their own internal identifier for patients, but rather expects that organization utilize the Community agreed to Patient Identity when communicating outside the organization.
  • Release to Trial-Implementation -- Mobile Care Services Discovery (mCSD) -- This release is in Implementation Guide format, and has also been improved to support Communities using a variety of network topologies. The mCSD provides a Directory/Registry feature to enable a Community and/or Cross-Community discovery of Organizations, Facilities, Locations, and Endpoints.

These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.

In development

The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.

  • Improvement to Mobile Health Documents (MHD) to support more simple Document Source applications. Recognition that the current methods for Publishing or Pushing documents is not always needed to be fully implemented in Document Source actors. Thus there is developments to support a more Simplified Publish, an operation that will extract the metadata out of a well-formed CDA or FHIR-Document, and a few more clarifications. Current committee draft
  • New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
  • A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures.
I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.

Future projects

Some potential next projects, based on interest and resources:
  • Basic Patient Privacy Consents on FHIR
  • Profiling of $match for Patient lookup 
  • Federating MHDS communities
  • etc.

Tuesday, August 9, 2022


 I was asked to explain how Break-Glass works. There is not a solitary answer, as the context is very important.

Define Break-Glass 

A method used by authorized clinical people to gain access to information that the patient has indicated they want held more confidential, when that clinician has made a medical assessment that there is a safety concern that the confidential information may help shed light.

  • Used only in Treatment use-cases. It would be inappropriate for a Billing/Payment use-case to invoke Break-Glass. 
  • Not the Emergency-Room use-case. The Emergency-Room tends to focus on stabilizing the patient and this can often be done in complete absence of historic data. Further when data are available, the clinicians in the Emergency-Room tend to already be operating at elevated privilege.
  • Used only by authorized users. Not all clinicians are going to be given this authority.
  • Medical safety concern. The clinician is expected to be making a medical safety decision. This concern is often gathered as rational for invoking Break-Glass.
  • Post analysis. Break-Glass events should happen very rarely, but when they do the Audit Log must be relied upon to provide transparency to the activities. Thus, the Audit Log might be more detailed during a Break-Glass activity. The activity of Break-Glass should cause a post analysis, where the Audit Log is examined for if the declaration of Break-Glass was necessary and appropriate.
  • Patient Privacy Consent restricts some data for Treatment. Note that if no restrictions for Treatment are given, then Break-Glass doesn't apply as it would result in no additional data access.
    • Patient Privacy Consent does not forbid Break-Glass. There are some settings where it is allowed for a patient to indicate they would rather suffer safety concerns than have the data exposed. Most settings don't allow this kind of thing, trusting their clinicians more.

So, by this point we know there this is a use-case where break-glass applies, the patient has authorized break-glass, there is a need to blind some information from this clinician, and that the clinician does possess the permission to declare break-glass; so it is only now that we need to do something special.
historic article from 2015  

Solution Considerations:

In general there are a variety of ways to solve. 

  • Internal logic of the EHR. If the use-case does not need to extend outside of the EHR, then there is no need for a standardized solution.
  • Some workflow mechanism. It is possible for Break-Glass to be supported in ways that have nothing to do with the Security layer. These solutions tend to treat Break-Glass as a pathway thru the other clinical flows. 
Thus for Security layer solutions tend to focus on use of
  • PurposeOfUse of BTG (Break-the-Glass). Typically, clinical flows use TREAT as the PurposeOfUse to indicate the request is triggered by a normal treatment use-case and that the data returned would be used for normal treatment use-cases. The BTG would be an additional PurposeOfUse to indicate that Break-Glass has been appropriately declared.

How BTG is declared is covered below...

How does User know Break-Glass could be used?

This section is looking at how the user would know that Break-Glass 'could' be used. In theory, the non-authorized users would not be told that there are data that are blinded to them. Thus, only the users that hold the authority to declare Break-Glass would be notified that there are data that are blinded to them under normal treatment.
  • It is possible that there is no feedback mechanism. Thus, those with the authority to Break-Glass would simply declare Break-Glass when they "felt" that data might be being blinded that might have some impact on safety. 
    • The advantage of this is that the clinician is never presented with some indication. There have been incidents that some clinicians overly focus on the blinded data if they know that there are data that are blinded.
    • The disadvantage of this is that unnecessary Break-Glass events will be declared. This disrupts the clinician's flow, forcing them to detect if the Break-Glass action gave them more data or not; and causes safety / privacy investigation of many Break-Glass actions.
    • An advantage is that this does not require any additional detection logic on normal transaction requests, and does not have an atypical response.
    • This approach might be useful as a steppingstone to a more mature solution. 
  • FHIR OperationOutcome. All responses to requests in FHIR can carry a OperationOutcome. The OperationOutcome could indicate that BTG could be used. This would be indicated with an issue in the OperationOutcome that is clearly just information / informational. But would require that there be some yet-to-be-defined code to indicate that Break-Glass may be useful
  • The FHIR Bundle that is returned might have a tag that indicates that some data were redacted (REDACTED). This is a Bundle security tag, as it is about the transaction results, and not about any specific data inside the Bundle (actually about data not in the Bundle). This tag would not be included for those users not authorized to declare Break-Glass.
  • There might be a service request to see if data are blinded. Might be a simple service that returns true if some blinding rules are found in the patient's Consent. 
    • With OAuth, if the JWT was exposed (possibly thru an introspection API), then the conditions in the JWT might indicate if blinding rules are expected to be applied. This does not indicate they were needed to be applied, just that there are residual obligations to be enforced at the Resource Server / Enforcement Point.
  • ???? I don't know of another method. There might be something in http? I don't know of anything that would be linked to OAuth or any profile of OAuth.

FHIR Technical Solutions for declaring Break-Glass

At this point we know that the clinical user has the rights to declare Break-Glass, and has come to some clinical decision that it is appropriate to invoke Break-Glass. I think this looks different in the case of an end-user app accessing data via FHIR, from a clinical organization requesting healthcare data from another clinical organization.


In the case of Business-to-Business, where both businesses are part of a Trust-Framework that has enabled Federated Access Control, the initiating organization would have some logic within that organization that checks that their user is authorized to Break-Glass, and some mechanism for that user to declare Break-Glass. Thus in the Business-to-Business use-case the only thing that gets exposed at the Interoperability layer is that the requesting organization security token needs to look different for normal Treatment from Break-Glass. This nicely fits in the PurposeOfUse.
  1. OAuth. The OAuth flow could provide the User-Interface that the Clinician uses to request and get Break-Glass permission. The token issued would indicate normal or break-glass in some token opaque way (many tokens are opaque to all but the OAuth authority and the resource-service enforcement).
    • OAuth using the BTG PurposeOfUse. There are JWT mechanisms for encoding PurposeOfUse in the JWT in the IHE Implementation Guide on using OAuth with FHIR.
  2. SAML. Predating the use of OAuth is the use of SAML within nationwide health exchanges (XDS/XCA using SOAP). In the SAML flow it has always been one organization declaring the context of their request to the other organization. This SAML assertion would include the user identity that triggered the event, but the request authorization was always an organizational request. These SAML assertions relied on PurposeOfUse to set much of the context. And thus the use of BTG (or historically ETREAT) was the indicator for Break-Glass.
  3. Break-Glass service. It is possible to have a workflow mechanism that is invoked to indicate that Break-Glass is being invoked. This would not involve the security layer. This would require some state management at the server side.
    • An advantage of this is also that the declaration of Break-Glass is later followed by a return to normal. Which tends to follow the flow seen at the Clinician side, meaning the clinician is not exposed to each FHIR request/response; they are presented with a set of data retrieved over many FHIR request/responses; they then declare a Break-Glass and then more FHIR request/responses happen. 
    • It is possible this is simply an AuditEvent that indicates that Break-Glass is declared. Thus the Enforcement Point would look to AuditEvent for a Break-Glass declaration that is outstanding.
    • It is also possible that some other FHIR Resource is used.
    • It is also possible that no FHIR Resource is used, but some non-FHIR mechanism
    • Possibly OAuth Authorization Decision point 
  4. http header as outlined in FHIR Core on the Security Labels page. This mechanism uses a web category draft IETF standard. This also uses the PurposeOfUse vocabulary. 
    • This mechanism is not using security mechanism, so it should not be seen as a security solution. It would be very easy to hack the FHIR API to add this.
    • Note this solution could also be used to carry the other PurposeOfUse indiators, like TREAT


I separate this as End-User-Client often are more driven by the OAuth authorization service. I think that most of the Business-to-Business solutions can happen here. I simply think that the OAuth authorization service might get more involved in the User Experience at declaring Break-Glass, capturing the reason for the Break-Glass.  I am not clear on how the user / app would indicate to the OAuth authorization service that a Break-Glass UX should be brought forward. I look to OAuth experts on that front.


I am so sorry that there is not one solution. I assert that the reason there is not one clear solution has to do with the very fact that there is not much discussion of this flow in public spaces. I think that if there were a public discussion, we could eliminate some of these with rational as to why they are not as good as others, and likely come up with solutions I have not thought of. 

Wednesday, June 22, 2022

RESTful search using POST vs GET on #FHIR

I got a Question: 
Can you address a specific example of the intersection of FHIR standards and OWASP guidance?  
The FHIR spec allows for sensitive ids such as patient identifier to be used on the query string when searching for a patient.  See the following:
However, the folks at OWASP consider this practice a vulnerability:

Do you have any thoughts or guidance on this topic?  Break the standard (and REST) and implement these GETs as POSTs?  Create a proxy table that maps sensitive ids to external ids and require the usage of the external id on the query parameter? 

OWASP is fantastic resource. Everyone should use it. 

However on the topic of GET vs POST for search in FHIR, I do have some further emphasis and guidance:

The FHIR core specification addresses the basic support, and thus why Search is supported on POST as well as GET. All the examples are using GET, but that is just because it is easier to show in examples.

Secure Communication is a must

The OWASP article does recognize that using TLS is helpful against untrusted infrastructure. Fully protecting against them. Communications about patient data better be protected using TLS as any request (GET or POST) will be returning patient data, thus the query parameters are just as vulnerable as the query response.  So, using TLS will prevent all of the Internet infrastructure from grabbing any patient identity or sensitive data. 

The problem, as the OWASP article points out is that logging or inspection might happen on the Client or on the Server on either end of the TLS communication. What they don't say in the OWASP article is that the vulnerability is due to failure to secure the endpoints.  Again, patient data will be flowing, so to be worried about query parameters and not data is silly. Either an endpoint is designed and secured properly, or it should not be trusted with patient data. So the distinction between POST and GET is really odd. You either have control and can be trusted; or you don't have control and not trusted. If you can't be trusted with GET then you can't be trusted with POST.

Body logging

If your logging is out-of-control, then I assert you must assume your audit logs are recording the content of the body. Thus the POST body is logged, as is the Response body. 

Protect the whole System

Servers can certainly protect themselves fully. Any logging can be controlled to log high quality logs and protect the log storage and access fully, or to not log anything. We are trusting these servers to have secured patient data, so certainly they should be expected to be able to securely store log files too. Even cloud based servers that have scale functionalities can be properly secured. If you just secure your database engine, then you have not secured your server. You must secure everything, not just the easy stuff.

So, clients are the biggest exposure point. Applications (aka not browser hosted code) have full control of their environment and thus can also be designed to NOT log things. 

Browser apps that leverage the browser for display and networking are not securable, at all! They should not be trusted with patient data, say nothing about allowing them to use GET vs POST.  The exception that is often allowed is when the whole client computer is controlled, such as a Clinician application.  So, are browser apps forbidden, no. But, like Servers a whole Client can be secured. If the whole Client is secured then there is no problem, if anything in the Client isn't secured then the patient data is just as at risk as the logs.

Any service, intermediary, or client that can't be trusted to maintain secure logs should not be trusted at all. Anyone that puts patient data on a service that can't maintain logs securely is the actual problem. Anyone that allows a insecure client to gain access to patient data is the actual problem.

Patients have rights

Note one exception that as a Patient advocate I must remind everyone... Patients are empowered to make stupid decisions for themselves. It is useful to explain that the patient has chosen an insecureable client, but it is not proper to forbid using the application the patient has chosen. In this case the patient has the right. Privacy Principles favor giving the data to the patient over using security as an excuse to not give them the data. Warn the patient first, but if they say they understand and really want it to happen, then do it.

Not all of FHIR is patient data

That said, there are many uses of FHIR that are not about patient identifiable data. Infrastructure resources, Directory resources, vocabulary resources, definitional resources, etc.

And there are uses of FHIR on synthetic data, or properly de-identified data.


I have rallied against this security theatre against GET.  POST is not more secure than GET. It is not. In fact GET enables better, for example in that it supports cache control with trusted infrastructure. GET is also expressly idempotent, where POST is not explicitly (although POST search very likely is).

Comment with arguments for/against this position. I feel confident, but I also know that I don't know everything.


  • Grahame Grieve June 22, 2022 at 3:44 PM
I agree, but the way people are fixed to this speaks to a lack of confidence in managing log access. Which is typically true for general web servers, but cannot be true for servers handling PHI / Clinical data
  • Note that FHIR Paging forces the use of GET for next / previous page. So, one needs to address securing GET

  • Note that POST URL parameters are part of the http specification. So just changing to POST changes nothing. One must change to POST NOT using URL parameters, but content type application/x-www-form-urlencoded with the parameters in the body.

Friday, June 17, 2022

RelatedPerson Consent - how to record the #FHIR Consent that authorizes a #FHIR RelatedPerson

This article summarizes a concept that came from my blog reader. This is actually published in a personal Implementation Guide at -- . This concept has not been proposed as a formal work item, but I think it would fit nicely in IHE Basic Patient Privacy Consents for Mobile that I have proposed (more on that soon).

This IG focuses on a use-case where the existence of a representative (e.g. guardian) is backed by a rationale and agreement from the Patient. Specifically some cases:

  1. When the Patient is a minor and the representative is a parent.
  2. When an adult Patient is physically or mentally competent, but still wants to appoint a representative to manage his/her medical records (e.g., a Lawyer).
  3. When the Patient does not have competency to manage their medical records, thus some representative is assigned.
  4. When the courts appoint a representative.

There may be more, but this list gives us a set of perspectives upon the reason why there is a need for a Consent to back the representative.



  • Patient resource is used to identify the Patient
  • RelatedPerson resource is used to identify the representative
  • Consent resource is used to document the Patient agreement with the representative. This might further be used in advanced cases to define what the RelatedPerson is allowed to do, and thus differentiate between multiple RelatedPerson resources a division of responsibilities.

The RelatedPerson resource would be the way that most will document a relationship between a patient and a representative (e.g., guardian). It is a clear link between the Patient and the other person. However the RelatedPerson does not have anywhere to explain the details of why the relationship exists, or any conditions on the relationship. There is a RelatedPerson.relationship that can be used to differentiate some roles, but this is very coarse level.

  • RelatedPerson.relationship has a clear code for Father, Mother, etc.

It is not clear to me that the RelatedPerson needs to have some indication that there is a Consent explaining the rationale. One would determine this by searching for Consents that point at the RelatedPerson instance. It is possible that the RelatedPerson.relationship could hold normal codes explaining the relationship, and one more that indicates that a rationale is available. Not clear that is proper or needed. It is also possible that there should be an element in RelatedPerson to point at the Consent, but I am not sure yet about that either.

Thus for any given RelatedPerson, one can look for that include the value. this can be done by searching on Consent using the actor parameter:

GET [path]/Consent?actor=RelatedPerson/1234

might be good to make sure the Consent is for that patient, and that the Consent is PERMITing that RelatedPerson… etc…

There are other rules that might be possible to do with invariants, but I just itemize them:

  • The RelatedPerson.patient must be the same as the Consent.patient
  • The Consent.provision.agent.reference must be the same as the
  • The Consent is authorizing (permit) the RelatedPerson, and is not expired.

This may seem cumbersome, so I was thinking that an extension in RelatedPerson that explicitly points at the Consent would be more appropriate.

Thus in this IG there is a minimal profile on RelatedPerson that simply indicates that this extension is needed.

Note that this extension does make the creation of the Consent and RelatedPerson resources difficult as they both reference each-other. Thus from a purely REST perspective one needs to create the RelatedPerson resource, then create the Consent that points at the RelatedPerson, then UPDATE the RelatedPerson to add the extension that points back at the Consent. This kind of double pointers is discouraged in REST and in FHIR.

As with any Consent, often there is paperwork that ultimately holds the legal details. This legal paperwork is critical to overall legal precedent, and represents the ceremony of the act of consent from the patient. These details should be captured by a DocumentReference and Binary. The Consent.sourceReference would then point at that DocumentReference. (Could use Consent.sourceAttachment, but I am not a fan of bloating the Consent with that detail).

The Consent then would need to be profiled. The main difference from the FHIR core Consent I outlined in my Consent article is that this might be a specific kind of Privacy Consent delegating authority, and the RelatedPerson instance would be indicated specifically in the .provision.agent.

  • status - would indicate active
  • category - would indicate patient consent, specifically a delegation of authority
  • patient - would indicate the Patient resource reference for the given patient
  • dateTime - would indicate when the privacy policy was presented
  • performer - would indicate the Patient resource if the patient was presented, a RelatedPerson for parent or guardian
  • organization - would indicate the Organization that presented the privacy policy, and that is going to enforce that privacy policy
  • source - would point at the specific signed consent by the patient
  • policy.uri - would indicate the privacy policy that was presented. Usually, the url to the version-specific policy
  • provision.type - permit - given there is no way to deny, this would be fixed at permit.
  • provision.agent.reference - would indicate the RelatedPerson resource
  • provision.agent.role - would indicate this agent is delegated authority
  • provision.purpose - would indicate some set of authorized purposeOfUse

In the case where the court or some actor that is not the Patient is compelling the RelatedPerson relationship, then the Consent.performer would indicate that the Patient is not the one granting the relationship, but rather the guardian or the courts.

One advantage of using a Consent resource as defined here is that there would be a natural set of provisions in a Consent that would be processable by an Access Control engine that understands Consent. This Access Control engine would not need to understand RelatedPerson, other than to know that a given user is a RelatedPerson (vs Patient, Person, Practitioner, etc). Thus the Consent.permit rules are used to mediate access to that Patient’s data by that given user.


Given this setup, a newborn would need a Consent drafted as soon as that newborn has a Patient resource to enable the parents’ access. This could be done by the system creating the newborn Patient resource. This could also be done using Implied Consent mechanisms, which is a default policy that is used when no Consent exists for a given Patient->agent relationship.

Same is true for any new Patient for which there is some precedent for implied consent representative.

Forcing a Consent to exist does prove that the representative relationship is explicit, and is thus more transparent. Implied representative relationships are common, but not very transparent.

The Consent resource is not intended to be used to drive the workflow of the capturing of the Consent. The Consent is following the “Event Pattern”, which means that it is the output of an event. The workflow that preceded this event would need to be managed by other resources in the Request pattern

The Task resource is generic and can do this work. There are some specializations of Task, so we could end up at some kind of a Task derivative that is specific to the workflow leading up to a Consent. However it is first best to see if Task can be profiled to address the workflow.

For example a use-case where the Patient nominates a potential Person to become their RelatedPerson; that triggering a GP to review and approve it; that triggering some legal review and approval; resulting in a Consent instance and the creation of the RelatedPerson. This workflow could be profiled into an ActivityDefinition… I like the power of this modeling concept, but have not done it formally so am not sure of all the possible issues.

Note we have tried to keep workflow states out of the Consent.status; but some states have gotten in that I don’t think are proper. But at this time we allow them in until there is a more formal task flow.


There is a basic example of a Patient delegating their father as their RelatedPerson. The resource objects are clickable to their examples.