Wednesday, May 18, 2022

Patient data embargo management

There are legitimate reasons for data to be embargoed for some timeframe. I am not a fan of these reasons, but as a Privacy and Security subject matter expert, I get asked how to solve these business needs. Many think this is an easy problem to solve, just slap a security tag on the data, but it is a much bigger systems-engineering problem.

Embargo Use-case

The clearest embargo reason is a patient safety reason, preventing a Patient from seeing a particularly damaging observation, until their primary care physician can have a one-on-one discussion. For example, a lab result that clearly indicates cancer. The clinical expectation is that the primary care physician can break the news more carefully or provide a more complete explanation.

The timeframe is not always clear, and most timeframes get cut short when some activity happens. Such as the above example, once the primary care physician has had the conversation then the embargo should stop.

These embargo timeframes can be just a few hours but can also be many months. I understand from a discussion on FHIR chat that there are countries that have regulations. That allow for timeframe to be up to six months. 

Oh, and data embargoed from the Patient would also need to be embargoed from their delegates (parent, guardian, etc).  

I don't know of embargo use-cases for Clinicians, no idea either on Payers. I could imagine that authorized research would or should be embargoed with the same rules as for Patients.

Meta Data

The security label (.meta.security) is not a great place to handle this, due to the variability. The security label could be used to tag data as falling into the category where an embargo might apply, subject-to-embargo. This would not indicate that an embargo does apply, just that the data qualifies for a potential embargo. Not clear what initial data analysis would be able to set this tag, but it is possible that there might be some set of codes and conditions that would be detectable. It might also be that all data is presumed to be subject to an embargo until data analysis or clinician explicitly marks it as not-subject-to-embargo

So, at this point we have a tag that says the data is either subject-to-embargo, or not-subject-to-embargo. Either method gives us the same state, that of a method to determine which data needs to have some timeframe applied vs which data does not.

When a clinician has a discussion with the Patient, and thus the embargo timeframe should be cut-short, then the clinician can just remove the subject-to-embargo or change it to no-longer-subject-to-embargo. Thus, the mechanism for counting-down the timeframe no longer applies.

Preliminary data status

An alternative that does not use the .meta.security tagging is to just use the .status element on the data. Most, likely all, data that would be potential subject to an embargo has  a .status element and the vocabulary available for the .status element has a preliminary code. This alternative has all data first published as preliminary, and only after some data analysis does it get set to final. This data analysis might be automated or might be clinician driven. In this case any data marked as preliminary would be embargoed from Patient access. One might expect that a Patient might not be given any data that is not in the final status.

The benefit of this method is that it is leveraging elements that have other clinical uses, but the drawback is that the security infrastructure must be aware of specific FHIR Resources like Observation. Further this method will only work for FHIR Resources that do have a .status element. Where the .meta.security is in the exact same place in all FHIR Resources, so the security infrastructure only need to understand the most basic of FHIR Resource.

Another potential drawback is that this dual purpose of the .status element may interfere with appropriate lifecycle management of the data.

Timeframe Management

As indicated in the use-case, the timeframe for automatic expiration of the embargo often varies by setting, data type, and clinician assessment. Where any timeframe exists there needs to be some mechanism to address the timeframe, but where the length of the timeframe is not fixed this makes the problem more difficult.

Count Down Clock

First solution, come up with some set of timeframes that fit the need, and assign them a code. Use that code on the .meta.security.
  • embargo-2-hours
  • embargo-2-days
  • embargo-1-week
  • embargo-2-weeks
  • embargo-1-month
  • embargo-2-months
  • embargo-6-months
As you can see this would be possible if the number of quanta are a few. But gets out of control really quick.

Another alternative is to add an extension with an integer. The integer would be similar to the above in that it would identify some time that would need to elapse.

Both a set of codes and an integer present the problem of time-elapsed-relative-to-what? The _lastUpdated element is available, but it will get updated whenever the data change. Thus any update resets the count down clock.

You could use a Resource specific element, like Observation.issued. Like above with using the Observation.status, using the Observation.issued is elegant but does mean the security layer does need to know about Observation rather than just Resource.

End Time

I would recommend that if an extension is being added, that it rather be a datatype of dateTime, or Period. The meaning of the value would be the date/time after which the embargo is lifted. In this case there is no need to look elsewhere. 

For efficiency's sake, once the time has expired; then the .meta.security should be set back to not embargoed. Thus the date comparison only needs to be done on those with active, or about to expire, data.

Permission

The security wg is working on a Permission resource. It is very drafty at this point, not worth looking too closely at, although we are welcoming use-cases to help drive our design. Note that in this case I am going to use Permission in a negative way, that is that the Patient is Denied access while the Permission is valid. For efficiency, the use of Permission would seem tied to data with a .meta.security with subject-to-embargo. The flag would tell the security layer to go look for a Permission resource instance that applies. That Permission resource has a .validity element that would indicate when the Permission expires.

Note that although Permission has a .validity element, it does not have a way to express Deny.

Note, like the FHIR Permission, the IT Security infrastructure might be able to do everything with no evidence in the FHIR world. That is, an XACML or other access control engine could be given the embargo information for a given resource identifier, it would enforce that rule, and it would flush that rule out when it expires. Thus there would be no FHIR evidence of this rule. 

Expiring the embargo

Some of these mechanisms will automatically expire the embargo, some can have automated expiration of the embargo, but other mechanisms would require a human to disable the embargo. There should be mechanisms in place to assure that the embargo does eventually expire. Such as when status of preliminary is used, some mechanism should detect that the data was in preliminary state for too-long. This detected status might simply alert the primary care physician, or might automatically disable the embargo.

Abuse for Illegitimate reasons

The method used for these use-cases can certainly be used for illegitimate reasons. I suspect that many "data blocking" activities are using these legitimate excuses when there is not a legitimate reason. The concern of all Privacy professionals is this abuse. Many would prefer we have no mechanism for legitimate embargo, but that is not reasonable. Thus my approach is to have mechanisms that are clearly designed, and transparent. 

Transparency is key to Privacy. When a patient is allowed to know how their data are used, and why restrictions are in place, enable the Patient to be more informed. Thus I would prefer the Patient has access to an Audit Event log of all uses, or attempts to use, their data.  see IHE Basic Audit Implementation Guide

Conclusion

Given all of this. I would first look at the use-cases and see if they are always applying to Observation. If so, then I would use the Observation.status and Observation.issued. I next would ask if there is a fixed, or small number of fixed, increments. If there are, then a code could be used for that fixed time. I am familiar with a fixed 2 days timeout, after which the embargo automatically expires. I would then have a security label code for subject-to-embargo, and no-longer-subject-to-embargo. I would have the second code so that it was clear that an embargo was enforced. I would always want the subject-to-embargo code to get removed at some point so as to limit the overhead for the vast majority of data, data that has never been subject to an embargo or data that has an expired embargo.

Tuesday, May 17, 2022

Explaining #FHIR Consent examples

This article includes explanation of some example scenarios and points at example Consent resources for them. These example scenarios are provided for educational use only, they are not an endorsement of these scenarios.

Notice of Privacy Policy

Some realms only require that the patient be given access to the organizations privacy policy. In these realms the patient is not given the choice to accept, reject, or change the terms of privacy policy. The expectation is that the patient can stop the engagement with the healthcare provider if they don't like the privacy policy (yes, we know this is a fallacy in many situations).

These realms may use the Consent resource to indicate that the ceremony of providing access to the privacy policy has happened, when it happened, who presented the policy, and which version of the policy was presented. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

  • status - would indicate active
  • category - would indicate patient consent specifically a notice of privacy practices
  • subject - would indicate the Patient resource reference for the given patient
  • dateTime - would indicate when the privacy policy was presented
  • grantor - would indicate who presented the privacy policy
  • grantee - would indicate the Patient resource if the patient was presented, a RelatedPerson for parent or guardian
  • controller - would indicate the Organization who presented the privacy policy, and which is going to enforce that privacy policy
  • policyText - 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.

Other elements would not be needed.

example

Given:

  • Patient: Peter James Chalmers
  • dateTime: March 11, 2022 at 12:22 pm
  • grantee: is the patient
  • grantor: Registration Desk Clerk - John Moehrke
  • controler: Burgers MC
  • policyText: policy at https://example.org/privacy-policy-v1.html

sushi:

Instance: example-notice
InstanceOf: Consent
Title: "Example of a Notice of Privacy Policy"
* status = #active
* category[+] = https://loinc.org#59284-0 "Patient Consent"
* category[+] = http://terminology.hl7.org/CodeSystem/consentcategorycodes#npp
* dateTime = 2022-03-11T12:22
* subject = Reference(Patient/example)
* grantee = Reference(Patient/example)
* grantor = Reference(Practitioner/example-clerk)
* controller = Reference(Organization/f001)
* policyText = Reference(DocumentReference/example-privacy-policy-v1)
* provision.type = #permit

support resources

Instance: example-privacy-policy-v1
InstanceOf: DocumentReference
Title: "Burgers Organization privacy policy"
* status = #current
* docStatus = #final
* type = https://loinc.org#57017-6 "Privacy policy Organization Document"
* category = https://loinc.org#57017-6 "Privacy policy Organization Document"
* content.attachment.contentType = application-pdf
* content.attachment.url = "https://example.org/privacy-policy-v1.html

Instance: example-clerk
InstanceOf: Practitioner
Title: "Registration Desk Clerk example"
* active = true
* name.text = "John Moehrke"

Security / Privacy Considerations

Organizations that never allow a patient to be in a deny mode never need to look at Consent for access-control reasons as there is no difference if the Patient has been given notice or not. In these cases the Consent is there for record keeping only. See Change to opt-out below.

Basic signed acknowledgement

This section covers the most basic of privacy consents, that simply records an acknowledgement to a given privacy policy permitting data sharing. This is only slightly different than the Notice of Privacy Policy, in that with this example, there is some evidence captured from the ceremony. Such as a patient initialing or signing a form indicating they have received the Privacy Policy. Similar to the Notice of Privacy Policy, the Patient is not given a choice to reject or change the terms of the privacy policy. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

The Consent is the same as with Notice of Privacy Policy with the following additions:

  • sourceReference - would hold a DocumentReference that has an image of the form that the patient signed. This image may be scanned copy of the ink on paper signature from the patient, or may be a digitally captured signature from the patient.

Other elements would not be needed.

example

Given: the same example attributes as above with the addition of a signed form. Thus the only addition is the sourceReference, which points at a scanned image of the signature in a DocumentReference resource.

sushi:

Instance: example-acknowledge
InstanceOf: Consent
Title: "Example of an acknowledged Notice of Privacy Policy"
* status = #active
* category[+] = https://loinc.org#59284-0 "Patient Consent"
* category[+] = http://terminology.hl7.org/CodeSystem/consentcategorycodes#npp
* dateTime = 2022-03-11T12:22
* subject = Reference(Patient/example)
* grantee = Reference(Patient/example)
* grantor = Reference(Practitioner/example-clerk)
* controller = Reference(Organization/f001)
* policyText = Reference(DocumentReference/example-privacy-policy-v1)
* provision.type = #permit
* sourceReference = Reference(DocumentReference/example-signed-acknowledgement-20220311)

support resources

Instance: example-signed-acknowledgement
InstanceOf: DocumentReference
Title: "Patient Peter James Chalmers signed an acknowledgement of the Privacy Policy"
* status = #current
* docStatus = #final
* type = https://loinc.org#57016-8 "Privacy policy acknowledgement Document"
* content.attachment.contentType = application-pdf
* content.attachment.data =  "SGVsbG8gV29ybGQ="

Security / Privacy Considerations

Organizations that never allow a patient to be in a deny mode never need to look at Consent for access-control reasons as there is no difference if the Patient has signed a consent or not. In these cases the Consent is there for record keeping only. See Change to opt-out below.

Change to deny sharing

This section covers the case where a basic permit has been used, but for some reason the authorization is revoked or rejected. An example might be where the organization does allow the patient to reject a previously permitted action, and the patient has expressed they want to deny sharing now. Another example might be where legal action has happened compelling an organization to revoke the consent.

The example scenario here describes methods where there would be only one Consent on record for a given Patient. Thus the current status would be simply discoverable by looking for the Consent for a given Patient and checking the .status element and .provision.type. This logic presumes that where no Consent is found, that an implied permit is the default. Thus one must look for both the existence of a Consent for the given Patient, and that the Consent.provision.type is permit.

Alternatives are shown:

  1. One possibly is that the existing Consent instance is revised to change the .status to inactive. When this is done the .lastUpdated will automatically indicate the date and time this change happened.
  2. If more details are needed, this change to the Consent instance could be tracked with a Provenance resource to indicate who made the change, what change was made, why the change was made, and other details as necessary.
  3. Advanced alternative possibility is to record a new Consent with the details of the change in Consent.status, the existing Consent would be marked as inactive same as above, and the Provenance would further indicate the new Consent replaces the old Consent.

Note that at some point after this, the consent may go back to active. This transition would follow the same process with the .status changes in the other direction.

example

Alternative 1 is not shown, as it is simply changing the .status.

Alternative 2

Given:

  • existing Consent resource example-acknowledge is revised as Alternative 1
    • for visibility the examples assumes that the server supports versioning. This is not required of the alternative.
  • Provenance states
    • who - Lawyer David Pyke
    • when - March 3rd, 2022 at 4:56pm
    • why - Legal hold

sushi:

Instance: example-change-consent
InstanceOf: Provenance
Title: "Consent revoked"
* target = Reference(Consent/example-acknowledge/_history/2)
* entity.what = Reference(Consent/example-acknowledge/_history/1)
* entity.role = #revision
* dateTime = 2022-03-11T16:56
* activity = http://terminology.hl7.org/CodeSystem/iso-21089-lifecycle#hold
* patient = Reference(Patient/example)
* agent.type = http://terminology.hl7.org/CodeSystem/provenance-participant-type#enterer
* agent.who = Reference(Practitioner/example-lawyer)
 
Instance: example-lawyer
InstanceOf: Practitioner
Title: "Corporate Lawyer example"
* active = true
* name.text = "David Pyke"

Security Considerations

That organizations that never allow a patient to be in a deny mode never need to look at Consent for access control reasons as there is no difference if the Patient has been given notice, or signed anything. In these cases the Consent is there for record keeping only. With the support for Change to opt-out, there is now a need for access-control to always look for Consent status. The most simple access-control will simply look for the existence of a Consent, check that it is .status = active, and that it is .provision.type = deny; if it is anything else then the access-control rule is that which is represented by the privacy policy.

Some patient specific provisions

The above examples were recording blanket agreement or disagreement by a given patient to a given policy. This is not as flexible as the Consent resource can support. The Consent resource can also record deviations, and special cases. These are recorded in the .provisions structure. The root level .provision simply sets the context as shown above. There is nested .provision(s) that can exist within the root level .provision, and even within other nested .provisions. Each level of nesting would contain the exceptions to the rules set down in the prior level, thus each successive level of nesting reverses the permit vs deny. In this way one can encode situations where broad sharing is allowed, but not sharing with Dr. Bob. The following is an example fragment of just the .provision. Note that the second nested provision is a deny provision with the only other element populated is the actor.reference of Dr. Bob.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)

Instance: example-dr-bob
InstanceOf: Practitioner
Title: "Dr. Bob"
* active = true
* name.text = "Dr. Bob"

AND relationship between elements

Each .provision has elements that describe the setting for that permit or deny. Each element within a given .provision is in an AND relationship with the other elements in that given .provision. An element that is not populated indicates that for that kind of element there is no constraint. Thus in the above example, the deny provision for Dr. Bob has none of the other elements in that .provision filled out, so this means that Dr. Bob is forbidden access regardless of the role he might take on, or the purpose of use, or the action, or the class of data, or the dataPeriod timeframe of the data, etc.

Thus to say that Dr. Bob is not to get access to the data, except for patient directed purpose of use; one would have a Deny of all access by Dr. Bob, and a nested Permit of Dr. Bob AND patient directed purpose of use AND normal confidentiality data (not restricted). Note that it is not really necessary to repeat Dr. Bob in the third level, as logically the second level already restricted this branch to Dr. Bob.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].type = #permit
* provision.provision[0].provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].purpose = http://terminology.hl7.org/CodeSystem/v3-ActReason#PATRQT "patient requested"
* provision.provision[0].provision[0].securityLabel = http://terminology.hl7.org/CodeSystem/v3-Confidentiality#N "normal"

OR relationship within an element

Repititions within an element are in an OR relationship. Thus to say that Dr. Bob is allowed this access on not just patient requested, but also family requested, and power of attorney; one would just put them all as alternatives on the purpose element.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].type = #permit
* provision.provision[0].provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].purpose[0] = http://terminology.hl7.org/CodeSystem/v3-ActReason#PATRQT "patient requested"
* provision.provision[0].provision[0].purpose[1] = http://terminology.hl7.org/CodeSystem/v3-ActReason#FAMRQT "family requested"
* provision.provision[0].provision[0].purpose[2] = http://terminology.hl7.org/CodeSystem/v3-ActReason#PWATRNY "power of attorney"
* provision.provision[0].provision[0].securityLabel = http://terminology.hl7.org/CodeSystem/v3-Confidentiality#N "normal"

time scoped provisions

The provision.period is used to indicate that this provision is only active during a period of time. This is useful to indicate that Dr. Bob should be denied access until 2024, because I will be moving away from Dr. Bob in 2022.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].period.end = 2024
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)

timeframe for data

The provision elements are very powerful. We are not going to explain examples of all of them.

The provision.dataPeriod element is very useful, as it is not uncommon for a patient to remember a timeframe when they had a specifically sensitive healthcare episode. Thus it is easy to give a timeframe, where any data that was authored or last updated within that timeframe would be the context of that provision. The further advantage of this mechanism is that there is no indication of why or what is sensitive; just a timeframe.

For example, deny access to any data authored or last updated in 2018. This will block all data, regardless of what kind of data, or who is asking for the data.

Other examples

Not all of the examples given have been explained above.

Monday, May 2, 2022

IHE ITI Spring

The IHE domains of IT-Infrastructure, PCC, QRPH, and RAD had our workgroup meetings last week. Radiology met in-person at the RSNA, so got to socialize. I don't have details for RAD, PCC, or QRPH.

IT-Infrastructure met virtually all week. We did not make as much progress as we wanted to, due to  the lack of progress in the past few months. However we did make significant progress.

All formal publications will be available this month at https://profiles.ihe.net

Release for Trial Implementation:

  • Basic Audit Log Pattern (BALP) will be released for Trial Implementation. This release will happen over the next few weeks.
    • GitHub project - https://github.com/IHE/ITI.BasicAudit
    • Publication - https://profiles.ihe.net/ITI/BALP - Version 1.1.0, Published May 4th
    • This project focused on defining AuditEvent patterns for various general purpose auditable events. Specifically all FHIR RESTful interactions, and and Accounting of Disclosures. Augmentations of these to embellish the Patient as subject, and the user/client that is auth using SAML, or OAuth.
    • This IG can be implemented directly. This IG will more be used as a foundation of the AuditEvent profiles, such as PMIR will show. 

Release for Public Comment:

  • Mobile Care Services Discovery (mCSD) -- significant comments and changes to improve the usability and features. Because of these changes, we decided to publish for another Public Comment. 

    • Patient Master Identity Registry (PMIR) -- this is simply converting the specification from WORD/PDF into using the IG Publisher. There is no intended new feature. However given the new publication tooling there will be additional specification. One is that this IG will depend on BasicAudit as the pattern for some of the AuditEvent profiles.

    Current Projects Kanban

    • Scheduling for Patients or Providers 
    • Mobile Health Documents  - Improvements based on current feedback
    • MHD to a Federation 
      • likely will transition to a Whitepaper covering all forms of multiple-depth federation support. With a focus on use of the features that this project has added to mCSD and MHD.
        • use-cases for PUSH to a partner multiple hops away
        • use-cases for Query to a partner multiple hops away
      • Project Plan
      • GitHub project -- tbd
      • This will be a new whitepaper. 

    • Extension to Secure Retrieve (SeR) Profile to support other HIE services
      • This project will take the SAML/XACML mechanism defined for Secure Retrieve, and defined how it can be used to address other services in an XDS/XCA community such as patient lookup.
      • Project Plan
      • This will be an updated Supplement (WORD/PDF) 

    • Update publications 
      • We are now integrating the changes approved through the CP process.
      • Incremental Quality improvements have been submitted to some of the ITI Implementation Guides and Technical Framework. When these are simply cleanup the changes are accepted as github issues, and pull-requests. These changes are available in the "current" Continuous-Integration (CI) builds; and will be moved into formal publication based on need and impact.

    Next virtual Meeting is July 18-22

    Other Activities

    • The IHE profiles.ihe.net now has full analytics, so ITI can now tell specifically which parts of the technical framework are being used.
    • The IHE profiles.ihe.net now has the DEV and RAD domains represented. QRPH is coming soon.
    • Quality Improvements and templating improvements as identified.

    Thursday, March 31, 2022

    API Security conference -- on #FHIR

    Updated April 7, 2022: Here are the slides I presented.

    Join me at my presentations at #APISecure2022 where I will be surrounded by far smarter people on API security. This is a virtual event, so you should certainly be able to sign up.

     so, there is going to be just a little bit about #FHIR:

    1. On Wednesday I will be on a panel with Alissa and Grahame - The State of FHIR API Security in Healthcare
    2. On Thursday Grahame will be speaking - Securing FHIR APIs in Healthcare
    3. After Grahame I will be speaking - Designing and Implementing a FHIR API Security Plan


    BUT the more important is ALL the other sessions. Protecting a FHIR API starts with fundamentals of protecting an API. So please secure your #FHIR API and Apps. Start with good API Security fundamentals.

    Monday, March 21, 2022

    Ask, just ask

    I am short on ideas of topics that I should elaborate on in a blog article. So, I remind you all that if you thing of a topic that you think I might be able to clarify, please let me know. It costs you nothing. I might not even answer. But I certainly am not going to address the topic if you don't ask.

    I look at and respond to Comments anywhere on my blog, but I recognize that some don't like google's requirement for google account. Thus you can also send me a question to my gmail address which simply is my name - JohnMoehrke

    The rules are simple:

    • Topics I'll cover include anything in my banner specific to Healthcare Interoperability Standards  
      • Health Information Exchange, 
      • Document Exchange 
      • XDS/XCA/MHD, 
      • mHealth, 
      • Patient Identity, 
      • Provider Directories, 
      • FHIR, 
      • Consent, 
      • Access Control, 
      • Audit Control, 
      • Accounting of Disclosures, 
      • User Identity, 
      • Authorization, 
      • Authentication, 
      • Encryption, 
      • Digital Signatures, 
      • Transport/Media Security, 
      • De-Identification, Pseudonymization, Anonymization, and 
      • Blockchain.
    • All questions and suggestions posted are subject to this Blog's Policies.
    • If I don't know or cannot otherwise answer your question, I'll let you know.
    • Questions are not necessarily answered or addressed in the order received.

    Thursday, March 3, 2022

    IHE Basic Audit Implementation Guide

    Updated May 4th, 2022 -- Trial Implementation released. The Implementation Guide is now named Basic Audit Log Patterns (BALP) Version 1.1.0.

    Supporting Privacy Principles to give transparency to how a Patients data are used is one of the goals of a new Implementation Guide from IHE. The AuditEvent profiles in this guide can also be used for Security purposes.

    The Basic Audit Log Pattern (BasicAudit) Content Profile defines some basic and reusable AuditEvent patterns. Defining formally an Audit Creator and an Audit Consumer actors (similar to how IHE has Content Creator and Content Consumer in the Document space).



    The Audit Log Patterns defined here rely on the ATNA Profile for transport of the AuditEvent and query/retrieval of AuditEvents previously recorded. The patterns defined here may be used as they are, or further refined to specific use-cases. Where a more specific audit event is defined, it should be derived off of these basic patterns. Thus a more specific AuditEvent would be compliant with one or more of the AuditEvent patterns defined here.

    This implementation guide 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 ATNA and other IHE Profiles.

    This Implementation Guide is not about the "ANY request/response", this is about what should be put into an AuditEvent record that "auditable event" happened.

    Specifically, there are a set of patterns (profiles) defined for the AuditEvent content that should be recorded when any of the following happens:

    Wednesday, March 2, 2022

    IHE IT-Infrastructure - March 2022

    IHE IT-Infrastructure committee has been very busy this winter quarter. Today we release updates to 9 different publications:

    New Publication

    •  mCSD 3.5.0 - conversion from PDF to IG Publisher
    •  MHDS 2.3.0 - conversion from PDF to IG Publisher
    •  Metadata Handbook 2.1 - conversion from PDF to markdown/html

    Minor/Patch update publications

    •  MHD 4.1.0 - minor updates
    •  PDQm 2.4.0 - minor updates to fix bugs, id, and canonical uri
    •  PIXm 3.0.2 - patch update to fix id
    •  FormatCode 1.1.0 - minor updates to Rad, and canonical URI

    Public Comment

    •  Basic Audit 1.0.1 
    •  mCSD 3.6.1 - updates to support MHD-to-a-Federation work item

    Also

    • ITI Technical Framework - patch to typos
    • addition of above Basic Audit IG
    • PCC index fixes
    • experimental RSS feed for new FHIR releases

    Find all of this at https://profiles.ihe.net

    How to comment?

    • Each Implementation guide has IG specific links in the footer of each page
    • "New Issue" will take you to a github issue entry form, with the proper template for commenting (this requires a github account)
    • "Issues" will take you to the known issues, to confirm that the issue you noticed has been reported already.
    • "Propose a change" is a web form for those that don't have github accounts



    Tuesday, January 11, 2022

    IHE IT-Infrastructure January Public-Comment

    The IHE IT-Infrastructure domain has been doing some light conversion of existing IHE-Profiles and publications to the modern html publication and use of the Implementation Guide publisher format. The public-comment is focused on uncovering mistakes in this conversion. There are no intended new features in these releases. However, there are differences that are driven by the publication platform. There is expectation that these new publication formats will enable better implementations, testing, and enhancements.

    Document Sharing Metadata Handbook


    IHE Document Sharing depends on document metadata, folder metadata, and submission set metadata. This handbook guides a community at defining how they will use these metadata fields. Mostly defining the ValueSets to be used within their community. Where these ValueSets might include vocabulary from national, regional, or local domains. 

    The change expected in this publication is specifically just to move to the new html publication form. With html publication format there can be much more rich linking into and out of the text. So the text should be easier to understand, and easier to reference. 

    Mobile Health Document Sharing

    The Mobile Health Document Sharing (MHDS) shows how to build a Document Sharing Exchange using IHE-profiled FHIR® standard, rather than the legacy IHE profiles that are dominated by XDS and HL7® v2. This Implementation Guide assembles other IHE Implementation guides (Profiles) and defines a Document Registry Actor.



    Version 2.2.0 is intended to be changes to the publication mechanism from WORD/PDF to an Implementation Guide published using the IG-Publisher. However, some other changes have been necessary due to the passing of time.
    • Mentions of DocumentManifest are now List.source due to the change in MHD.
    • Mentions of the PMIR Patient Identity Manager are changed to Patient Identity Registry due to change in PMIR.
    • This version has a CapabilityStatement that was not previously published.
    • Updates due to changes in the IUA profile, such as the additional leverage of the Authorization Server Metadata Option.
    • Removed section 50.7 as the current HIE-Whitepaper contains MHD and MHDS now.
    • Diagrams have been changed to support the above changes.

    Mobile Care Services Discovery

    The Mobile Care Services Discovery (mCSD) supports RESTful queries across related care service resources. The loosely coupled design and flexible querying capability of the mCSD Profile means it can be deployed within a variety of eHealth architectures and support a wide array of care workflows.


    Version 3.4.0 is intended to be changes to publication mechanism from WORD/PDF to an Implementation Guide. 
    • Removed inline UML text and moved it to images-source/
    • Removed reference to setting meta.profile as it is redundant
    • Added sections in actor requirements describing the requirement of providing a capability statement Volume 1
    • Updated the canonical URL for the organization hierarchy extension to http://profiles.ihe.net/ITI/mCSD/StructureDefinition/IHE.mCSD.OrganizationHierarchy
    • Added links to the structure definitions for resource profiles to ITI-90 and ITI-91
    • Changed structuredefinitions for Facility and Jurisdiction to use an invariant for the type requirement instead of slicing.
    • Added in text to show that searches can use GET or POST ITI-90 Message Semantics.
    • Added in retrieve (GET RESOURCE/ID) message section starting at ITI-90
    Note, there will be further enhancements in the coming quarter to enable use-cases such as using MHD to access a federation of Communities.

    HTML navigation

    There is now also a new feature across the whole the publications. Now wherever there is a header, you will find a link icon that you can use to get the deep link to that header. This enables easier references to sections. 

    Commenting

    Public-Comment is welcome from anyone. You do not need to be a member. Comments can be submitted on these in three different ways. Comments open until February 12th. 
    1. Using the Web based form found at https://www.ihe.net/ITI_Public_Comments/
    2. Using a spreadsheet emailed to iticomments@googlegroups.com
    3. Using GitHub issue submission (provided you have a Github account and are a member of the IHE github community)
      1. Metadata Handbook Issue tracker
      2. MHDS Issue tracker
      3. mCSD Issue tracker
    I really want to encourage membership in IHE IT-Infrastructure committee.

    Wednesday, January 5, 2022

    PIXm webinar

    There is now a short webinar recording available for PIXm


    This and other IHE recorded webinars can be found on the IHE International YouTube channel.


    The PIXm implementation guide can be found on the IHE Profiles.ihe.net site where all of the IT-Infrastructure specifications are published.

    Note that PIXm and PMIR do have different feed patterns, these are intended. I explain that in this article.